Re: [GNAP] Support of FIDO

Steinar Noem <steinar@udelt.no> Fri, 14 August 2020 13:23 UTC

Return-Path: <steinar@udelt.no>
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 AB04E3A1109 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 06:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=udelt-no.20150623.gappssmtp.com
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 EzJPWd0kghi4 for <txauth@ietfa.amsl.com>; Fri, 14 Aug 2020 06:23:50 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 0FC3B3A1120 for <txauth@ietf.org>; Fri, 14 Aug 2020 06:23:49 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id z18so7537556otk.6 for <txauth@ietf.org>; Fri, 14 Aug 2020 06:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJ0TB3U1783dDJ1rXsd2Gy5mnUWZf4d6XXsPX/JKqCg=; b=CEo+dgUu+Drcy/uzEz5vwEzd67NPLmZBmEaxrQE9EnHELpE+pa0mzIOyaOVlgMG/dP 0p3U7mWU4J7q1oJwjRszZuzQh5RW50Ke4Sze3tuxoRba/ZkVQDHKanODN1DkzE/zcri8 zVlpvtv+FgtGbmajiTqZtye3gtUjvvkODQSXIi2BR13qMo0eEr8UHw+XvnAIajS02FKH +TMnSDrN7KztNzcM+7CvBpP1PD2jkrOWzxZjDxgC4PUZXcHm7rorS1aSZi623RIQ/jAQ XCdVVFKkzzn4X3EY6HKrBqTNfPGzh3cXb5MnbGlXbdNtrdb9JBovx1ynxIVg4j5bHN+l GLlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DJ0TB3U1783dDJ1rXsd2Gy5mnUWZf4d6XXsPX/JKqCg=; b=j9l5stsFMIyA0DEIK9qjveBQvhvQ7d28aDljByNqGibS5xVSSh1RqwmQva+Dv6kxLr KZJSjkht8W79jdCXZQS/ZopiPgDO200KjmeMaEEue0BSuhSszND4g/R1lJ+nsqajgLi1 yDfwbuFttojKLpJ0dlvLXAOaLd04SoVEiT6qZHKXAWrcU7cK0eHEKM1LlKq4VvOOJxs+ U+9JxSsHOhNHlZcOTAGz18dQ4D1SEITy/U435Jdr3grCkGPIly3QScQR7qk+Z55v4jhC nbkMGDZdg1DkR0LbxqmLMXZ8XL4q85m5R9pQ4Xean6tDKkQYTNvct/gZogblg0oMbxfG 7gOA==
X-Gm-Message-State: AOAM532gWXBUgtV1PCqoPf9N2VMpxBLeC1U2FXN/iXFmSB/A0DAqWk5v NFROJOsjazDAWgWV4NbTC4MaaQkEnf/uuKcst3sq2A==
X-Google-Smtp-Source: ABdhPJyoLDUu3MYK5ehXGXXBGG47IA59c5Llv/J+czE1XmmebhABT/uHlulD9LxR8X6jYndDq+7uuIh0udTWaH+Qbgg=
X-Received: by 2002:a9d:19a3:: with SMTP id k32mr1916908otk.273.1597411428488; Fri, 14 Aug 2020 06:23:48 -0700 (PDT)
MIME-Version: 1.0
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>
From: Steinar Noem <steinar@udelt.no>
Date: Fri, 14 Aug 2020 15:23:38 +0200
Message-ID: <CAHsNOKeqMhnL639v3DrfL9mG6Tsjunk8tq5QSV513ECRHVVyhA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: nadalin@prodigy.net, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c16c7e05acd65401"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9qBOCBxUyDttWNVGK7rbD4yK1bI>
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 13:23:53 -0000

Hi Denis, I have always perceived U2F (which I think has been replaced by
FIDO2/CTAP/WebAuthn) as just a pure second factor and not an authentication
in itself.
I may be wrong, but from my understanding U2F makes sense in combination
with user authentication, but not as a stand-alone solution.

<mvh>Steinar</mvh>

fre. 14. aug. 2020 kl. 12:04 skrev Denis <denis.ietf@free.fr>fr>:

> 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 <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 |