Re: [GNAP] Support of FIDO

Denis <denis.ietf@free.fr> Wed, 19 August 2020 08:39 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECE83A12D0 for <txauth@ietfa.amsl.com>; Wed, 19 Aug 2020 01:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jX6JiBWW7nw for <txauth@ietfa.amsl.com>; Wed, 19 Aug 2020 01:39:10 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E633A12C9 for <txauth@ietf.org>; Wed, 19 Aug 2020 01:39:09 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id HLf6230052bcEcA03Lf75c; Wed, 19 Aug 2020 10:39:07 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 19 Aug 2020 10:39:07 +0200
X-ME-IP: 90.79.51.120
To: nadalin@prodigy.net, txauth@ietf.org
References: <a6c47318-6f61-7fd5-6a36-c31b3b7b2ed5@free.fr> <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> <015801d67245$933b3850$b9b1a8f0$@prodigy.net> <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> <01fd01d67585$fca832f0$f5f898d0$@prodigy.net>
From: Denis <denis.ietf@free.fr>
Message-ID: <0c2e0e75-808c-2859-3bad-e1b5cadda9ee@free.fr>
Date: Wed, 19 Aug 2020 10:39:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <01fd01d67585$fca832f0$f5f898d0$@prodigy.net>
Content-Type: multipart/alternative; boundary="------------1B0AB86212F23BDF795558B9"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/3GeEZQuL8ca9IlIX-fIDgKUz9zI>
Subject: Re: [GNAP] Support of FIDO
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2020 08:39:12 -0000

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>
> *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>
>     <mailto:txauth-bounces@ietf.org> *On Behalf Of *Denis
>     *Sent:* Friday, August 14, 2020 3:04 AM
>     *To:* nadalin@prodigy.net <mailto:nadalin@prodigy.net>;
>     txauth@ietf.org <mailto: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
>
>          2. 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>
>         <mailto:txauth-bounces@ietf.org> *On Behalf Of *Denis
>         *Sent:* Thursday, August 13, 2020 10:31 AM
>         *To:* txauth@ietf.org <mailto: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
>