Re: [GNAP] Support of FIDO

I personally like FIDO2 a lot, and think that it would serve well as an
example of how to solve authentication.
But I also think that it is just one of many examples of how authentication
can be handled, and that it should not be presented as a "preferred"
solution or any other form of tight coupling between FIDO and GNAP.
There are well founded reasons for choosing other mechanisms (e.g. national
eIDs etc).

-S

ons. 19. aug. 2020 kl. 10:39 skrev Denis <denis.ietf@free.fr>:

> Hi Tony,
>
> Functionally, private keys are stored and used by the authenticator. For
> capacity limitations, they can be stored elsewhere if both correctly
> integrity and confidentiality protected.
> That additional storage is an extension of the limited storage of the
> authenticator.
>
> I was attempting to promote the use of FIDO within this WG. Are you
> against or in favour of such a possibility ?
>
> Denis
>
> U2F is not CTAP2 or FIDO2, U2F device usually do not store the
> cryptographic material on the device as the device has limited capabilities
>
>
>
> *From:* Denis <denis.ietf@free.fr> <denis.ietf@free.fr>
> *Sent:* Tuesday, August 18, 2020 9:37 AM
> *To:* nadalin@prodigy.net; txauth@ietf.org
> *Subject:* Re: [GNAP] Support of FIDO
>
>
>
> Hi Tony,
>
> Not quite Dennis, the U2F device does not store the private key, it only
> creates the private key.
>
> Please read the Client to Authenticator Protocol (CTAP) specification from
> the FIDO Alliance:
>
>
> https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf
>
> Extract:
>
>  (...) the ASPSP  (Account Servicing Payment Service Providers) server
> sends a challenge message to the authenticator
> which is then cryptographically signed by a *private key stored in the
> authenticator.*
>
> Denis
>
>
>
> *From:* TXAuth <txauth-bounces@ietf.org> <txauth-bounces@ietf.org> *On
> Behalf Of *Denis
> *Sent:* Friday, August 14, 2020 3:04 AM
> *To:* nadalin@prodigy.net; txauth@ietf.org
> *Subject:* Re: [GNAP] Support of FIDO
>
>
>
> Hi Tony,
>
> Dennis, not all the way correct
>
>    1. 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
>
>    1. 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
>
>
>
> *From:* TXAuth <txauth-bounces@ietf.org> <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.
>
> 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
>
>
>
>
>
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |