Difference between revisions of "Web Authentication"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Other Materiel)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
A standard<ref> Dirk Balfanz +11, ''Web Authentication: An API for accessing Public Key Credentials Level 1.'' for editors draft https://w3c.github.io/webauthn/</ref><ref>W3C ''Web Authentication: An API for accessing Public Key Credentials Level 1'' For current date, see latest published version: https://www.w3.org/TR/webauthn/</ref> for adding more factors to a [[Web Authentication]] that is occasionaly referred to as FIDO2.
+
A general problem for users on the web that was addressed by some attribute claims of the [[OIDC]] but is now extended by a W3C standard<ref> Dirk Balfanz +11, ''Web Authentication: An API for accessing Public Key Credentials Level 1.'' for editors' draft https://w3c.github.io/webauthn/</ref><ref>W3C ''Web Authentication: An API for accessing Public Key Credentials Level 1'' For current date, see latest published version: https://www.w3.org/TR/webauthn/</ref> for adding more factors to a [[Web Authentication]] second factor process that was initiated with [[FIDO 2.0]].
  
 
==Context==
 
==Context==
* Past This is, in effect, a follow-on to the [[FIDO U2F]] standard and maintains some back-wards compatibility with it.
+
* Past = [[Web Authentication]] is, in effect, a follow-on to the [[FIDO U2F]] standard and maintains some back-wards compatibility with it.
* Future - This is also a prelude to [[Web Authentication Level 2]] which enable the creation and use of strong, attested, scoped, public key cred by web applications for strongly authenticating users.
+
* Future = [[Web Authentication]] is a process that is tracked in the wiki page [[Web Authentication Levels]] which enables the creation and use of a strong, attested, scoped, public key cred by web applications for strongly authenticating users.
  
 
==Problems==
 
==Problems==
Line 10: Line 10:
  
 
==Solutions==
 
==Solutions==
* [https://webauthn.io Demostration of Web AuthN I] by Duo labs.
+
* [https://webauthn.io Demonstration of Web AuthN I] by Duo labs.
 
* [https://codelabs.developers.google.com/codelabs/webauthn-reauth/#0 code lab implementation from Google.]
 
* [https://codelabs.developers.google.com/codelabs/webauthn-reauth/#0 code lab implementation from Google.]
  
==+Web AuthN===
+
===Web AuthN===
 
Provides these protections.
 
Provides these protections.
 
* Protection against phishing: An attacker who creates a fake login website can't login as the user because the signature changes with the origin of the website.
 
* Protection against phishing: An attacker who creates a fake login website can't login as the user because the signature changes with the origin of the website.
 
*Reduced impact of data breaches: Developers don't need to hash the public key, and if an attacker gets access to the public key used to verify the authentication, it can't authenticate because it needs the private key.
 
*Reduced impact of data breaches: Developers don't need to hash the public key, and if an attacker gets access to the public key used to verify the authentication, it can't authenticate because it needs the private key.
* Invulnerable to password attacks: Some users might reuse passwords, and an attacker may obtain the user's password for another website (e.g. via a data breach). Also, text passwords are much easier to brute-force than a digital signature.
+
* Invulnerable to password attacks: Some users might reuse passwords, and an attacker may obtain the user's password for another website (e.g. via a data breach). Also, text passwords are much easier to brute-force than a [[Digital Signature]].
===Web AuthN 2===
+
 
# [[WebAuthn 2]] <ref>Dirk Balfanz + 8, ''Web Authentication: An API for accessing Public Key Credentials Level ''. (2020-11-16) World Wide Web Consortium (W3C) https://www.w3.org/TR/webauthn-2/</ref> is now in development. The case of a web Authenticator integrated into the client device seems to be the most interesting possibility.
+
===Web AuthN levels ===
 +
# [[WebAuthn 2]] <ref>Dirk Balfanz + 8, ''Web Authentication: An API for accessing Public Key Credentials Level ''. (2020-11-16) World Wide Web Consortium (W3C) https://www.w3.org/TR/webauthn-2/</ref> has been released. The case of a web Authenticator integrated into the client device seems to be the most interesting possibility.
 +
# [[WebAuthn 3]] is in first draft on 2021-09 to add support for [[Secure Payment Confirmation]].
 +
# The Wiki page [[Web Authentication Levels]] discusses the differences.
  
 
===Web Browsers that support Web Authn===
 
===Web Browsers that support Web Authn===
Line 29: Line 32:
 
In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
 
In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
 
there have been used everywhere, even when they were not strictly needed.
 
there have been used everywhere, even when they were not strictly needed.
 
  
 
It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
 
It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
Line 45: Line 47:
  
 
In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
 
In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
+
while in the other case (i.e., using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.
+
(i.e., not supporting OAuth) that is using the same globally unique identifier.
  
  
Line 67: Line 69:
  
 
== From Denis
 
== From Denis
 
Hi Tony,
 
Dennis, not all the way correct
 
 
 
 
 
It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
 
It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
 
and no trust relationships need to be defined since there is no AS
 
and no trust relationships need to be defined since there is no AS
Line 78: Line 74:
 
Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK
 
Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK
  
 
  
 
None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
 
None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
 
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible
 
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible
 
   
 
   
 
 
There is nothing that prohibits the RS from sharing registration information between RS
 
There is nothing that prohibits the RS from sharing registration information between RS
  
Line 95: Line 89:
 
There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.
 
There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.
  
Denis
+
Denis in W3C GNAP (then TXAuth) m/l
 
 
  
+
----
 
 
From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
 
Sent: Thursday, August 13, 2020 10:31 AM
 
To: txauth@ietf.org
 
Subject: [GNAP] Support of FIDO
 
 
 
 
  
 
This topic has already been tackled on the list, but I open a new thread for it.
 
This topic has already been tackled on the list, but I open a new thread for it.
Line 118: Line 104:
  
 
FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
 
FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.
+
specific to the RS. It may be observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.
  
  
Line 127: Line 113:
  
 
In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
 
In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
+
while in the other case (i.e., using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.
+
(i.e., not supporting OAuth) that is using the same globally unique identifier.
  
  
Line 134: Line 120:
  
 
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.
 
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.
 
  
 
There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.
 
There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.
Line 144: Line 129:
 
Not quite Dennis, the U2F device does not store the private key, it only creates the private key.
 
Not quite Dennis, the U2F device does not store the private key, it only creates the private key.
  
nadalin@prodigy.net
 
Aug 13, 2020, 11:25 AM (1 day ago)
 
Dennis, not all the way correct
 
 
 
 
It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
 
and no trust relationships need to be defined since there is no AS
 
 
Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK
 
 
 
 
None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
 
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible
 
 
 
There is nothing that prohibits the RS from sharing registration information between RS
 
 
  * Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.
 
 
 
Agree, this can be done now, we are also looking at some delegation mechanisms in WebAuthn to accomplish this
 
  
 
Mike Varley via ietf.org  
 
Mike Varley via ietf.org  
Line 185: Line 147:
  
  
[[Category:Standard]]
+
[[Category: Standard]]
[[Category:Glossary]]
+
[[Category: Glossary]]
 
+
[[Category: Browser]]
[[Category:Authentication]]
+
[[Category: Authentication]]

Latest revision as of 17:10, 26 May 2022

Full Title or Meme

A general problem for users on the web that was addressed by some attribute claims of the OIDC but is now extended by a W3C standard[1][2] for adding more factors to a Web Authentication second factor process that was initiated with FIDO 2.0.

Context

  • Past = Web Authentication is, in effect, a follow-on to the FIDO U2F standard and maintains some back-wards compatibility with it.
  • Future = Web Authentication is a process that is tracked in the wiki page Web Authentication Levels which enables the creation and use of a strong, attested, scoped, public key cred by web applications for strongly authenticating users.

Problems

  1. Web AuthN requires updates to the user's browsers to function.

Solutions

Web AuthN

Provides these protections.

  • Protection against phishing: An attacker who creates a fake login website can't login as the user because the signature changes with the origin of the website.
  • Reduced impact of data breaches: Developers don't need to hash the public key, and if an attacker gets access to the public key used to verify the authentication, it can't authenticate because it needs the private key.
  • Invulnerable to password attacks: Some users might reuse passwords, and an attacker may obtain the user's password for another website (e.g. via a data breach). Also, text passwords are much easier to brute-force than a Digital Signature.

Web AuthN levels

  1. WebAuthn 2 [3] has been released. The case of a web Authenticator integrated into the client device seems to be the most interesting possibility.
  2. WebAuthn 3 is in first draft on 2021-09 to add support for Secure Payment Confirmation.
  3. The Wiki page Web Authentication Levels discusses the differences.

Web Browsers that support Web Authn

  • Microsoft Edge[4]

Comments from IETF GNAP

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens, there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user and no trust relationships need to be defined since there is no AS.


FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.


RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer) while in the other case (i.e., using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server (i.e., not supporting OAuth) that is using the same globally unique identifier.


None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.


There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis

== From Dick hardt

OAuth 2.0 goal was not to get rid of usernames and passwords. It was to stop site A from asking for the user's username and password at site B so that site A could access resources at site B.

How the AS authenticates the User is out of scope, and I think should be out of scope. There are a plethora of authentication mechanisms, and standardizing how the user authenticates is not required for interop. Sharing the "quality" of the authentication is an area of standardization that has been done in OpenID Connect, and I think should be included in GNAP.

Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.

== From Denis It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user and no trust relationships need to be defined since there is no AS

Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK


None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS. Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible

There is nothing that prohibits the RS from sharing registration information between RS

I am speaking of FIDO U2F where there are two main phases: registration and authentication.

The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step. Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

Denis in W3C GNAP (then TXAuth) m/l


This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens, there have been used everywhere, even when they were not strictly needed.


It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user and no trust relationships need to be defined since there is no AS.


FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym specific to the RS. It may be observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.


RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer) while in the other case (i.e., using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server (i.e., not supporting OAuth) that is using the same globally unique identifier.


None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis

==From Tony Correct U2F is not passwordless like FIDO2 or UAF Not quite Dennis, the U2F device does not store the private key, it only creates the private key.


Mike Varley via ietf.org 6:05 AM (10 hours ago) to Denis, Dick, txauth@ietf.org

I think allowing a trusted Client to authN the end user and have the AS trust that authentication is an important feature, especially for mobile client or in the example of FIDO/WebAuthN.

I have captured the use case here:

https://github.com/ietf-wg-gnap/general/wiki/Client-can-AuthN-End-User

References

  1. Dirk Balfanz +11, Web Authentication: An API for accessing Public Key Credentials Level 1. for editors' draft https://w3c.github.io/webauthn/
  2. W3C Web Authentication: An API for accessing Public Key Credentials Level 1 For current date, see latest published version: https://www.w3.org/TR/webauthn/
  3. Dirk Balfanz + 8, Web Authentication: An API for accessing Public Key Credentials Level . (2020-11-16) World Wide Web Consortium (W3C) https://www.w3.org/TR/webauthn-2/
  4. Angelo Liao +1, Introducing Web Authentication in Microsoft Edge. (2018-07-30) Microsoft https://blogs.windows.com/msedgedev/2018/07/30/introducing-web-authentication-microsoft-edge/

Other Materiel