Re: [Txauth] Support of FIDO and data minimization by RSs

Dick Hardt <dick.hardt@gmail.com> Tue, 07 July 2020 23:21 UTC

Return-Path: <dick.hardt@gmail.com>
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 375C03A0BFD; Tue, 7 Jul 2020 16:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 i2prhgd7zULh; Tue, 7 Jul 2020 16:21:22 -0700 (PDT)
Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 313E03A0BFC; Tue, 7 Jul 2020 16:21:22 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id h19so52055780ljg.13; Tue, 07 Jul 2020 16:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zOtzxTmSyM1BxkBK2IaIVT0hpnvbWiSUcYaVsdQ8hsQ=; b=bO7aWBFGdsRrIdI8s9r15nID5tMP79yhnrotKC9iUCUWPPmVyk6fkkd0swn6V7SZ/D hC1JGBcuLzj7BJzGYpeedwbxoPMCGtKlPNas4zuQKS5vDwb7TB6RJH8IxgkaYJ9xa3lX nBgK+u7ng41L40TP8eI18RjC4taINcxrhnzwp47EgdE5sHrc0Sk+zyNrbfFzGsRnnrvm 4LZiDR0DdERKzyB49+0SM7W7qKpMhEeKU8dMAiARatdWr3SRPviUcMQP+qyVRWyuQGuo 1jNdZitO9TCB7nEUVeQSOPWIFKn8eEOgfF1lK1D+b4UZaYRkBAgS0cSCAGm0ZWRnXkzq Relg==
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=zOtzxTmSyM1BxkBK2IaIVT0hpnvbWiSUcYaVsdQ8hsQ=; b=uMThESsNPpbAfB0RNWcd5MYQtiOFkHdPn2qgCnkJiU71llkCdNnfGciDHJ+zAke1W1 R6v81LEtSmI4MjXtOe/vmzCxduXexNcO+rq4XLxN7uQrAruexJxHzYNAc9ImW1QE05JH UxoZnKw3KWDxsmJ0P5Mw/SIldD0ANNs/u4+Dj6TwENnalMuOkzRfYeJCXHN+xiw07xyf 8kHy23xyDTXvf0u20LxCKFOOUx8M0ck79V+MnIE5XpV2i03WhMGMKr86FKVCGqD39q5g wG8zKTCStXzuzb3Oi2mrg+xIo9GRBI6AzOSnmxjx+V76BiU1bZFwVAPg9zGFqs4XhG1N xjrQ==
X-Gm-Message-State: AOAM530DgaUumVGNlRSBdicRsrOl2Vqx+IDkObAZ595JVsShUO7/zPQc qpgGvGNo+d/fDMbe6EghQ+D1F3XjTbY7iURnGg8=
X-Google-Smtp-Source: ABdhPJyzPBj0mmVmwWsVyB+1iojH9YIHeP8CMLK8WMx9YogkZw2oml7FQHKQURdlpGe99yurIU8DMxgpftzajoe1uPU=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr8408507ljh.246.1594164080040; Tue, 07 Jul 2020 16:21:20 -0700 (PDT)
MIME-Version: 1.0
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr> <CAD9ie-uHo1hNs6Y767NHyNj1TxmfzcbDk-6iZxBT0QWtqpe+Fg@mail.gmail.com> <c91a9ecf-0f8c-a62d-aa4f-66e15cc6fba2@free.fr> <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu> <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>
In-Reply-To: <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 07 Jul 2020 16:20:43 -0700
Message-ID: <CAD9ie-tnj1ufCmiZ2MHHKPZ9kM7YQzoNMo4YErcu_coUX_35+g@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Justin Richer <jricher@mit.edu>, "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b45f6905a9e23f03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/lpS3IUrbYW2NgzAa7ckpqpv1Zdk>
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 07 Jul 2020 23:21:25 -0000

Denis: you seem to keep implying that other architectures don't preserve
privacy. A couple counterpoints:

Token opacity helps privacy in another dimension -- the client does not see
the information about the user.

Many OAuth developments have self contained tokens. There is no token
introspection call. This, coupled with opaque tokens, is more privacy
preserving than the client being able to peek in a token.

ᐧ

On Tue, Jul 7, 2020 at 5:26 AM Denis <denis.ietf@free.fr> wrote:

> Hi Justin,
>
> I think removing the opacity of access tokens to clients is going to be a
> non-starter for most of this community.
>
> Token opacity is considered as a dogma in OAuth 2.0. More explanations why
> access tokens should not be opaque in GNAP.
>
> Token introspection mandates a dialogue from the RS to the AS which allows
> the AS to know which RS
> got a given access token. So token introspection allows the AS to trace
> the client. This should be avoided.
> Using NON-OPAQUE access tokens solves the issue both for the RSs and for
> the clients. This means that
> access tokens used for GNAP shall include a version number or a format
> identifier.
>
> Applying a "security by design" approach leads to specific design
> requirements. The key question is whether
> this BoF prefers a "Privacy by design" approach or *implicitly *a "Big
> Brother by design" approach.
>
> Denis
>
>
>  — Justin
>
> On Jul 6, 2020, at 3:17 PM, Denis <denis.ietf@free.fr> wrote:
>
> Hi Dick,
>
> Congratulations ! You made a good guess (but the guess was easy): my
> approach is indeed privacy related.
>
> *Note*: Since it is close to the end of the day in my time zone (and
> since it is the last day for comments to the charter),
> I copy both the IESG and Roman so that they can know that GNAP should also
> consider a* bridge with FIDO*.
>
> I have several goals:
>
> 1 - make a bridge with FIDO U2F (I will illustrate this with a specific
> scenario).
>
> 2 - prevent every AS to know which RSs are going to be accessed or which
> kind of operation the client will be doing.
>     This is to prevent an AS to act as "Big Brother".
>
> 3 - apply both "privacy by default" and "data minimization" (when the user
> authenticates it may authenticate using FIDO or
>      by presenting one or more access tokens. Then after, the necessary
> attributes that are necessary to perform a given operation
>     are only requested and released at the time they are indeed needed to
> perform the given operation (i.e. they are not released
>     when the user logs on).
>
> 4 - the proposed RS Authorization algorithm allows a great flexibility, in
> particular it supports FIDO and different attributes
>      from different ASs may be requested by the RS.
>
> 5 - the rules associated with the RS Authorization algorithm are making
> these rules only available at the time the client indicates
>      which operation it is willing to perform (i.e. by default, they are
> not public).
>
> 6 - access tokens are NOT OPAQUE to the clients so that every client can
> make sure that their content reflects what has been requested.
>
> *A simple scenario to illustrate*
>
> A student wants to apply for a new university. He connects to the RS of
> the University. He first creates an account using FIDO.
> He then selects the button "Preliminary information for applying to the
> university". He is asked to enter two categories of information:
>
>
>    - citizenship information and
>    - prior graduations.
>
> The student can interrupt the preliminary registration procedure at any
> time and continue it at any time later on.
>
> When the student is finished, it selects the button "Application to the
> university".
>
> The university RS "reads" the citizen ship of the student and let know to
> the student whether a paper form
> and/or an electronic form of the identity of the student may be provided.
> Let us assume the later case and that
> the student is a citizen from France. Then the university RS indicates
> which French banks or other French organisations
> are trusted to provide an access token. The client checks whether this
> list fits one of the AS with which it has a relationship.
>
> The university RS "reads" the prior graduations of the student and then
> let know to the student whether a paper form
> and/or an electronic form of the last graduation of the student may be
> provided. Let us assume the later case and
> that the student is from Yale University. Then the university indicates
> the address of the AS from Yale University.
> If the student is indeed from Yale University, he should be able to
> provide the requested access token.
>
> Such scenario which follows some privacy principles cannot be constructed "*after
> the design"* (it will not happen by magic or by accident)
> This is why the approach is called "privacy by design".
>
> Denis
>
> Hi Denis
>
> Would you provide some background on what you are trying to solve with
> this? I'm guessing it is privacy related.
>
> Perhaps a use case would help make it more concrete?
>
> /Dick
>
>
> On Mon, Jul 6, 2020 at 5:39 AM Denis <denis.ietf@free.fr> wrote:
>
>> eThis is a new thread: a proposal for a RS authorization algorithm and a
>> way to support FIDO by RSs
>>
>> In order to support the privacy principle of "data minimization" by RSs,
>> only the attributes that are strictly necessary to perform
>> an operation requested by a client should be requested by the RS.
>>
>> When a client wants to authenticate, it will usually be informed by the
>> RS on how to do it (see more details about two exceptions at the end of
>> this email).
>> Which conditions are needed to perform other operations will only be
>> disclosed to authenticated users at the time they are willing to perform an
>> operation.
>>
>> Two categories of operations will be considered: authentication
>> operations and other operations.
>>
>> For the "authentication" operation, two cases will be supported:
>>
>> -          FIDO U2F or
>>
>> -          one or more attributes from one or more ASs.
>>
>> In the second case, an access will be granted by a RS based on an
>> mathematical expression which is formed using some combination of AND and
>> OR conditions.
>>
>> Examples of combinations:
>>
>> *Condition 1* AND
>> *Condition 2 Condition 1* OR *Condition 2*
>> (*Condition 1* AND *Condition 2)* OR
>> *Condition 3 (Condition 1* OR *Condition 2)* AND *Condition 3*
>>
>> The following notation is being used for *a Condition *:
>>
>> *Condition x* = { AS identifier + set of attributes types + optional
>> scope identifier }
>>
>> The presence of the *optional* scope identifier allows to provide a
>> backward compatibility with ASs from the OAuth 2.0. world:
>> the optional scope identifier is only present when a bilateral
>> relationship has been established between a RS and an AS prior
>> to any access (*and will continue to be maintained*) using
>> "out-of-bands" means.
>>
>> Each RS internally constructs an *authorization table* with the
>> following content:
>>
>> 1°  For the "authentication" operation : either FIDO U2F or a
>> mathematical expression using conditions;
>>
>> 2°  For any other operation : a mathematical expression using conditions.
>>
>> An example is used to explain the concepts.
>>
>> "Operation(s)/ Mathematical expression" pairs managed by the RO of a RS.
>>
>> *Operation*
>>
>> *Mathematical expression*
>>
>> Authentication
>>
>> *Condition 1* OR *Condition 2*
>>
>> Operation A OR Operation Z
>>
>> *Condition 3* AND *Condition 4*
>>
>> Conditions table:
>>
>> Condition 1
>>
>> FIDO U2F 1.2
>>
>> -
>>
>> -
>>
>> Condition 2
>>
>> AS 1
>>
>> set 1 of attributes types
>>
>>
>> Condition 3
>>
>> AS 4
>>
>> set 2 of attributes types
>>
>> scope identifier : 21
>>
>> Condition 4
>>
>> AS 9
>>
>> set 3 of attributes types
>>
>> -
>>
>> Given the operation selected by the client, the RS returns the
>> appropriate mathematical expression and only the associated conditions
>> used in that mathematical expression. The user may then decide whether
>> the set of attributes types which are indicated for a given AS
>> are appropriate to him or not and then select that AS if it has a
>> relationship with it.
>>
>> In this example, one mathematical expression for the combination of
>> conditions using AND and OR operators is "*Condition 3* OR *Condition
>> 4",*
>> * which means that* some types of attributes from AS 4 AND some other
>> types of attributes from AS 9 are both needed by RSx to perform on RSx
>> either the Operation A or the Operation Z.
>>
>> In this example, RS 1 and AS 4 have established a bilateral relationship
>> (and have agreed to define and use scope identifiers)
>> whereas RS 1 and AS 9 have not established any bilateral relationship
>> prior to the exchange.
>>
>> The user makes up his mind whether the attributes requested by AS 1 and
>> AS 9 are reasonable and if so, requests two access tokens:
>> one to AS 4 and another one to AS 9.
>>
>> For AS 4, the client shall use the scope identifier with the value 21.
>> For AS 9, the client shall use the set 3 of attributes types indicated in
>> the Condition 4.
>>
>> In order to save one exchange, a RS could publicly publish how its
>> clients can authenticate.
>> However,  it is also possible to consider no guidance at all: in such a
>> case, using "out-of-bands" means, the clients should know how to
>> authenticate.
>>
>> Denis
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>