Re: [GNAP] Support of FIDO

nadalin@prodigy.net Fri, 14 August 2020 14:17 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 7068E3A1142 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 07:17:04 -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 vpCtzPb9C2h2 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 07:17:02 -0700 (PDT)
Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (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 9FBB13A113B for <txauth@ietf.org>; Fri, 14 Aug 2020 07:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597414621; bh=5WW8FRJAIEC9nAGq5SPvPBnTOJphhyMZ8fUTeg0+m/U=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=d7Nc+iN4gYl3yL3KshCeyH+TQaFUUPuFPKt66CNLabcOfDxW7u8q09HwibjIsf3YHJeyM3OehMkaeo/ZHmCIlUH+iZAwVySr26pg3PD3NOy2Y7gcmCF8iM+7c1uv5o0zuZfCjEaYn7+XVzcJuSbZAxnngg1P/awQ2+JAeQ2LTWb9jehPPCI+K5uc98HKAxs1GXJh5XvcOwXLrgiMm5laYijt4VXn9SrGg7ppgEPsbpJcR5vvX/qtAT2PveAv3YLlCHalTYky2dc4R8oaHYaxMTn4y30rg/UqD3c2ZW1DBpyrsADHOGPOmCznCPUmqgF7LWG8I92MnlIfO03oTZEj5w==
X-YMail-OSG: 86vqSrAVM1nDU2BXgCU1AMvDVbFmzeqF0n_Fz7QtBnyyV6Sto0EWbLpL5P2uhGM gGzuQPEJd8aoekv68aIsRySisd1lPIMF9qgXQeib.WPNCtG2qHfpZVWFL8MyfW5U7vUMo7crJnO2 9OHFt.gKl7kGi6I8YQM7ewHbxHN_pAB1OoRz0Ig6OwpLdpXbhylKB8Yj212neoQK4pYJggYINhT5 2sPbws78iFSPQ3VzRmbiNvYlaX3gJ8QT9JDd6JgZTanDJ.TenNTvAQqDGKTnxhExvVo5UCOImhLG Qjv2pH2HwK.X4k3nheC_tYjWtaff3VEorfqsAGx83L6.OXLzE.He7gJfcIAI1PSzaqQWg6TXI8zU n.b00AapvhRj0wjAK5UxaoDQVR6mXBl8cdYGHU8tyezefTgDASicsPed64_xCMvVku4EBjjIcGZ. eaDecs_2jJKXLGAczjCMV4uMsbqTKOtP_mEkReX7.i5u2MNWywkzeWj.vhlHVM454tBG_tYVpXFV brttDy1TAd9O7V3HXDeh3Kr6c6T50Tb8Hlt4gXrYyeMnYKnVa6fk7UQDakdFSH_MIUwlEB.4bcXJ HS_7CvCWu_6KWsHfyBZW3muXu4Q3Fd6lsuasNBD_euGe6XfNgemHN8lWsKe4Romg_SPlQlmuF.B. .Gwwh8bSQobDURiXjiH73Ql9FVLQdllAKYBrxfKqVwqQq7AdPftT6pBGYhSvWTagOlsEpKNZBfKk AYrI.Ui.Y0rEwfIT.nb3y8e8STKdqZGoVBUvZTJ8HGp2EJTE6mVB1GE.nxWq.F1pCmwJAgc9Xx0G 4HBofOuwLZOItVXKM723vsriQXiWmlNbBxFWBaaT7cqBZmzGRhkP83L7O4WItv2e3rmhb9.h6tnD 2t1k97sgFCt30KTc3YVE.8njcry4GpuOu8KYFrp0WwPyUB2qzZBtCJumn1Z29Z8fJZOZfZqmBSRk Mo5ZZuy1bmUUohPCJyOZ0XqL69Vl72MDJeNcEVHjVBKN8rOnNC3BpzHxABIv1OsKcJZG6y4s5o3h FAypG7T3kdbv5g98KWUqSVttAylzYTmcJ7z7sgdvkNnMwAoj5BoQswDcA1V0SemUcOwN7UacwOio W0LZs9NlqOsXZ9Rr_i4BI1k6I3fvomcg_VScO5rvms7t3pLofF7u2MWTPfrybnhZF4Db3Mr8qq3x uMDNhaSdCbdrpvylxSE2Yqy0eQIzEtl6cIpoYZSqI6URYUM4KnVnObP7whcTFz1LlD.MZsLLKkJA kpqQU1RI.4K7aiTke_v_yulnTgO25imsijXUsY2Hj3sX37txPVAt92h47vd9cjNVFo0GrlngpJg5 LoogMoken6zlauGCMxwIS5IeDzLi7HzqbYTbOL8RIN7ZOaOLPu8_zFkHHGFchcovbgZudMrvggez dp6gP9W8fCQIZ877APT9mW8tWn8AJlvL4TtjT6gUg613Kz5W5KQ2TLprN7gajTlf.KTn_aQItRmz dCw8b1ymMbYw-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 14 Aug 2020 14:17:01 +0000
Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 39be61271e146f68dc9dfe94d7bb7bd0; Fri, 14 Aug 2020 14:17:00 +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>
In-Reply-To: <9db6ee29-9e43-5893-6779-e5f863418890@free.fr>
Date: Fri, 14 Aug 2020 07:16:58 -0700
Message-ID: <015801d67245$933b3850$b9b1a8f0$@prodigy.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0159_01D6720A.E6DE0E00"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAJA1Hv+AlIHM6epW+IgIA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/CyqEZfb1-IiSlKP6aB7lS72q7Ls>
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: Fri, 14 Aug 2020 14:17:04 -0000

Not quite Dennis, the U2F device does not store the private key, it only creates the private key.

 

From: TXAuth <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

 

*	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

 

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