Re: [GNAP] Support of FIDO

nadalin@prodigy.net Tue, 18 August 2020 17:35 UTC

Return-Path: <nadalin@prodigy.net>
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 A39E23A088A for <txauth@ietfa.amsl.com>; Tue, 18 Aug 2020 10:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=prodigy.net
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 2cAi72Rfk2ti for <txauth@ietfa.amsl.com>; Tue, 18 Aug 2020 10:35:42 -0700 (PDT)
Received: from sonic305-5.consmr.mail.bf2.yahoo.com (sonic305-5.consmr.mail.bf2.yahoo.com [74.6.133.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DAD3A0885 for <txauth@ietf.org>; Tue, 18 Aug 2020 10:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597772141; bh=8/OR34fNVkt8rClqkT8pDAl9aRfX6MgjlvQX5AyuTBA=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=CGYfbchjU5vao3GkyO2q+oUv1/6nRCXs2zZKYSap8xvCIa3rTfSKuFzsflj+7Mt8UfODCBu7dKQzs6kEdVR3AXEvQhm0TJlUNrinWajhWAs0xjok/1alMiMK9Yj+q9kRCETokfYrdQMgiUzeVw3meIhzW1fJTxlHlKr32Fl8kNWy1RNOnB71dFECeebT9g3h8p+IlQk+nbqIGepNuzDq4id0W4x4Uk2OmVLdhSRD3JH1Yz8xtMqWGXCqFFUoiP679VbHASxk8Lgl2smsiwRNl00otijqljXZ4D+N4yqJPHex+fxy0JiWXI+5qss/j8Eqb2+8zHUdm0TMqUN/3xp/rg==
X-YMail-OSG: 401wYhkVM1k.s0X9rq3zRq8i5_qNxt0mh1WgW7NYn7UdFkklS8bWOjyu9vXsb1h sHq9LCDIV.N8PeKzkQ3.WQf_r6xqM_wm7iydqkMx_z9zrh9B_ISgR4tfffp.o_qEtix54vQ0eQlR mEiC5t2ehYvWSgkMkRBWRMzVPmZ.xIFd9_D5FgEo9OluCykaqngvbNHtGkJ2Kp68DbUwdPS1A4CK TmbbKtsL9HLycopwHK4mUPqd1AVaWmGAW49_A51SIo0crr32fT__J4eICSRuPImZ7xOkwQ1aE10k GLisy.Vk60podeTfeoyHXO7zHFknD_ESvOmoaiaffRpaRAdnG3Xh7CQJnB15pCiIkL10GDu_Tkyc smjKrmoP3PBkmge2ukqhc4m6VQN7pvDqPbBeuWxtHfWCY9CRtHDm5RJTK8.ep7xoSzUQLEFtFGoP NZCz3WVM.jhA.D73C2KiR94TmAZE2seMKVyb9ReMpy9lfQSpvKrx7nKBFMq1gSatf5FsVl2tW1Ou TqY3Z9leaN5_MnVd6twmM7eQCbPnREk0It162rVziVguvunclDu3D7GZfrUhGRPsQmEdDI7zdujT tlha55NYWkl9WdwXWUC02NszuTCXesIBTp9DrPAIY5G9HwWCzuy78iMGTrGo5Hk3xgOvl_A518eX 2VGqMWK5a7.r4Srlp87E12B6udQB.hUcJWYtjPZ04gxOPJvF7ib1hvZLG2y1pglQNT7Ljtat.jf9 aQNBp0fadVxQehCRjouEoPDTpXVZe.o5iHQDZjtbZP4.lR1.Z1WqfcfDadtSCTGUFA6NExPDNENE qbl81ICX1GhLyRRzal5MmlLtKEhRYjIQRyLzwXQMZ2bJI1DJp9A7R.86sI_VqXxtCzK5gcE8Dk9_ 8tB23fI7ii5_Gbbp65fieM32z.qj29y1AAK62ESJ1XgRL83lXIsX2hSSwG1zFFD_Ee1BhY5V0IP3 Z7HFR_MKddyS9dn4ACEytnhGgaDEgxWu07ZajV5W_uZXuYSrU.nZOqnmp38fy.Jinb7MCm2LwsHN 43WgbdpNoTF1DEsJkQNeDzNye8yOs0dAQnKFfkyl3YuD5mcD9oYzEW4rEgi.9W3rzojxyp_ZKcC7 QnQOn1EtSkZD9jTsvrHAuFnXFkhT8zx5WbGDLZtnRao1qe4Q4MnjiuXhecnBRnuaiH0MdRpX.8dT lqHpoPGLBlc1jD5KBNMLWVeEJi7aJW7JRC0uRpn6qjt7N.iyi1ySecUo.cBgWj3U1eiC4VWzQ8KA c.IPZoti7wFKMfCgTaYGfQ1eZhW_jZAaIPc8zYBnJJ1NTNUeQO7jLBJf1lZoL9f9lwaNOJui1E7b tBSwOJzdMZhEKxwJdWHkn44qk7Co_cVhodB28IVEI5WKg7.8tCxsJBgxTTPstxcEUcYX89cTJ9EW 4.mfMmhU0biR0cIe5ZgSflyIb9mg6XJFk5YUS0H5ymPg7luKew.6YkSnq420X6Qzo5SzbftWJ0Fa ldGdhcBw9EpV5
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Tue, 18 Aug 2020 17:35:41 +0000
Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 546e3b06c5e933f6520ea57bf7c435b4; Tue, 18 Aug 2020 17:35:38 +0000 (UTC)
From: nadalin@prodigy.net
To: 'Denis' <denis.ietf@free.fr>, 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>
In-Reply-To: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr>
Date: Tue, 18 Aug 2020 10:35:36 -0700
Message-ID: <01fd01d67585$fca832f0$f5f898d0$@prodigy.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01D6754B.504BCBF0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAJA1Hv+AlIHM6cBpyrj7gJulDD3qUG05OA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/b7uMEa-72QmiSf9FPjVAXxYzQRA>
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: Tue, 18 Aug 2020 17:35:45 -0000

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  <mailto:txauth-bounces@ietf.org> <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  <mailto:txauth-bounces@ietf.org> <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