Re: [Txauth] Registered Clients and Dynamic Clients

Denis <denis.ietf@free.fr> Fri, 17 July 2020 16:09 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 807453A0829 for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 09:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level:
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 Pkf8zZQVwdGh for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 09:09:05 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3C43A0822 for <txauth@ietf.org>; Fri, 17 Jul 2020 09:09:04 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d85 with ME id 4G92230054FMSmm03G92Nn; Fri, 17 Jul 2020 18:09:02 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 17 Jul 2020 18:09:02 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr> <CAD9ie-v5cXxbJrRi7V1v52F5SpUkdbaZZ7Twb0DYREK1CMku3Q@mail.gmail.com> <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr> <CAD9ie-tif8Pfj3pOoMVNrUFt5GCRFh12E_mOE22NPEvwuZkcdw@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <87fe40e8-7e00-3684-ce12-3ec28fd69c28@free.fr>
Date: Fri, 17 Jul 2020 18:09:00 +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: <CAD9ie-tif8Pfj3pOoMVNrUFt5GCRFh12E_mOE22NPEvwuZkcdw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B4D33F1A130C7C2358C3792B"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/sMfZw2ejwGqe4GM4MHVfcmwZr0g>
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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, 17 Jul 2020 16:09:08 -0000

Hi Dick,

I picked three of your sentences below :

    It appears you are mixing client identifiers and user identifiers,
    as well as user authentication at a AS, and client authentication at
    an AS.
    User authentication at the AS is out of scope of GNAP as I
    understand it (there are lots of existing mechanisms that work fine).
    Client authentication to the AS is in scope.

An AS needs to authenticate users in order to relate them to their 
attributes: there is a user account at the AS for each registered user.
So user authentication is one important step in the protocol. It shall 
be handled using an asymmetric key pair.

A client is a piece of software and/or hardware trusted either by an 
application or by a user that interfaces on their behalf with ASs and RSs.

An AS usually does not handle clients accounts. It may be interesting in 
some cases to make sure, from an AS point of view, that a user is indeed
using a secure element with some specific properties. But at this time 
the wording "secure element" has not been pronounced. If we would like
to go in that direction we would need to describe APDUs (Application 
Protocol Data Units) but at this time I am not aware that the IETF has 
already
addressed such topic.

However, I got the impression that the real need is not "entity 
authentication" for the client.
Would you explain the rational for your need, instead of the solution ?

I picked another sentence:

    A challenge with FIDO is portability across devices, as a binding is
    usually tied to a specific device.

This is currently true with what the FIDO Alliance has currently 
published, but this can be solved.
Denis

> inline ...
>
> On Thu, Jul 16, 2020 at 5:37 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     Hi Dick,
>
>>     On Wed, Jul 15, 2020 at 10:04 AM Denis <denis.ietf@free.fr
>>     <mailto:denis.ietf@free.fr>> wrote:
>>
>>         Hello Dick,
>>
>>         I am puzzled with the two following definitions in
>>         draft-hardt-xauth-protocol-13 :
>>
>>               *Registered Client* - a Client that has registered with
>>         the GS and has a Client ID to identify itself, and
>>                can prove it possesses a key that is linked to the
>>         Client ID.The GS may have different policies for what
>>                different Registered Clients can request.A Registered
>>         Client MAY be interacting with a User.
>>
>>         [Denis]  I interpret the last sentence in the following way:
>>         A Registered Client may be either an Application or a User.
>>                      Is it correct ?
>>
>>
>>     No. A Registered Client MAY be interacting with a User, or it MAY
>>     not. IE, a Registered Client may be a service.
>
>     It seems that what I call an Application is what you call a
>     service. Usually a service may be supported by multiple servers,
>     so I get the impression that my terminology is better suited. If
>     not, would you be able to explain ?
>
>
> A Client could be an application the User is using, or it could be a 
> service with no specific User.
>
>>         *Dynamic Client* - a Client that has not been previously
>>         registered with the GS, and each instance will generate
>>                it’s own asymmetric key pair so it can prove it is the
>>         same instance of the Client on subsequent requests. The GS
>>                MAY return a Dynamic Client a Client Handle for the
>>         Client to identify itself in subsequent requests. A single-page
>>                application with no active server component is an
>>         example of a Dynamic Client. A Dynamic Client MUST be
>>         interacting
>>                with a User.
>>
>>         [Denis] The draft does not include any other explanation for
>>         the reason to support the so-called "Dynamic Clients".
>>         While I can understand the value to use a temporary key pair
>>         for a given RS, I can't understand the value for a GS
>>                     to support unknown clients. If a GS knows nothing
>>         about a so-called "Dynamic Client", then it will not be able
>>         to deliver
>>                     any user attribute into an access token to such
>>         client.
>>
>>
>>     More of an explanation of Dynamic Clients is a good call out, thanks!
>>
>>     A Dynamic Client MUST be interacting with a User, as "trust" of
>>     the Client is done by the User.
>>     A Single Page Application (SPA) or a mobile app are examples of
>>     clients that cannot have a shared secret, but can generate and
>>     keep secure their own key pair..
>>
>>     As suggested in another thread, GNAP could support Clients that
>>     are between these two extremes.
>>     Mike called out automatic registration per OpenID Connect
>>     Federation as one example. Other options include a "software
>>     statement" passed from the Client to the GS.
>>
>>     We may want to revisit the terms "Registered Client" and "Dynamic
>>     Client" as we broaden the mechanisms for Clients to "register"
>>     with a GS, but these are the common cases today, so I picked them.
>
>     It seems that the intent is to support both a client registration
>     protocol and a client operational protocol with the GS/AS.
>
>     Client registration may be done in many ways until the user is
>     able to get a /both an identifier/ and private key
>     usable for an AS, and the AS is able to use /t//he same
>     identifier/ and the corresponding public key to authenticate the user.
>
> It appears you are mixing client identifiers and user identifiers, as 
> well as user authentication at a AS, and client authentication at an 
> AS. User authentication at the AS is out of scope of GNAP as I 
> understand it (there are lots of existing mechanisms that work fine). 
> Client authentication to the AS is in scope.
>
>     For example, draft-hardt-xauth-protocol-13 states: "The Client
>     always uses a private asymmetric key to authenticate to the GS".
>
>     This should be the start of the story with an important
>     observation: the client always uses /an identifier/, in particular
>     to allow to gracefully change that private key.
>
> The challenge is that the client needs a unique identifier for the GS, 
> which is why in both XYZ, and XAuth, the GS generates the identifier 
> for dynamic clients, and the generally also generates the identifier 
> for registered clients.
>
>     One way to register and then to authenticate to a GS may simply be
>     to use FIDO.FIDO is currently supported by many web browsers.
>
>
> Technically, the web browsers support WebAuthN. While FIDO is great 
> technology, I would see it as an authentication choice between the GS 
> and the User, and out of scope of GNAP. A challenge with FIDO is 
> portability across devices, as a binding is usually tied to a specific 
> device.
>
>
>     If/once we will be finished with the main topic, then why not
>     address client registration but there is no strong adherence with
>     our main topic.
>     Hence, client registration should not be on the list of our top
>     priorities.
>
>     If we define one /or more/ client registration schemes, then this
>     should better be in a separate and independent RFC.
>
> Maybe, maybe not.
>
> My preference is to have a larger document that covers inter-related 
> topics than a bunch of smaller documents that an implementer has to 
> bounce around between.
>
> /Dick