Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 02 March 2015 16:03 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4171E1A1A72 for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2015 08:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=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 fuy9JdRPaHZ4 for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2015 08:03:36 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 05FFD1A1ABB for <oauth@ietf.org>; Mon, 2 Mar 2015 08:03:36 -0800 (PST)
Received: by labgd6 with SMTP id gd6so31322815lab.7 for <oauth@ietf.org>; Mon, 02 Mar 2015 08:03:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1dHF4CqBrp48EkGjiDpTEm8W/a0CP9SDYGvgIqieyI=; b=M+L1XBYosfCYBR7gWpIqiGjXWp7ISFJGXS+rjxAlGISFJxnkx/J8/aLtX9T4wvE+v0 zyemkdbGwj8bnQiclE1OWxypFrj6l30rb/dt4wmZ66qwOaGZmZzqHkdfEbwct2QlMCo9 A4t95CfnIWj4ecaAteaKeVNscnWNKzVYpufF0HyjxJVgNWVFSjasH56UChzTQLUeDBrK CxiKswZM4xdfpw8iegFRtA2mNRDN6Acpxo/oUpWALNHFXJLQcOS9zu4hq3X+r314WzIH 4CEgk7ftmAXMoKenGYAMLGlm9oaeNOJvuxajvYiq90K/YxSCoS1CRL/S+LpsIh7AzeZd ZKPw==
MIME-Version: 1.0
X-Received: by 10.112.130.39 with SMTP id ob7mr15543200lbb.32.1425312214482; Mon, 02 Mar 2015 08:03:34 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Mon, 2 Mar 2015 08:03:34 -0800 (PST)
In-Reply-To: <FCA7BAEC-1D49-4A5E-BC0E-B290B569D1D8@mit.edu>
References: <CAHbuEH587HcqaqTMrmLPXQimRAaS2j1Uv+BC-0UHeyBwC8+3Uw@mail.gmail.com> <54DC2CB1.8090400@mit.edu> <D3644538-EF35-476B-8158-270C8FC21647@oracle.com> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <CAHbuEH5NUcQ5Q30yj80OSBe4epaarpkFroyM_Yfp5-thkMJBgA@mail.gmail.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <CAHbuEH4Pa6N5YMP=5f0W24nPsQ8aGPqL8sHOaspE5A1K8Gui4Q@mail.gmail.com> <DC682515-BCFD-42B8-9765-BD8EF32DDBD2@mit.edu> <54E4D2A5.5030705@gmx.net> <CB4A9839-31F2-4B15-8E76-BC3623C8B734@ve7jtb.com> <FCA7BAEC-1D49-4A5E-BC0E-B290B569D1D8@mit.edu>
Date: Mon, 2 Mar 2015 11:03:34 -0500
Message-ID: <CAHbuEH6SLmeEyMUsC9YjHmVDSzMqF68ba89OmH0-ezjf8U1Wbw@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary=047d7b3433da3d05310510505c19
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/bm9LbjCQNtt3mXO6XRE-16WIjkQ>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2015 16:03:39 -0000

Thank you, I just reviewed the diff and the changes to the draft look good.

Best regards,
Kathleen

On Wed, Feb 25, 2015 at 11:23 AM, Justin Richer <jricher@mit.edu> wrote:

> John’s assessment is correct and this is what we’ve tried to capture in
> the privacy considerations section of the latest draft:
>
>    In general, the metadata for a client, such as the client name and
>    software identifier, are common across all instances of a piece of
>    client software and therefore pose no privacy issues for end-users.
>    Client identifiers, on the other hand, are often unique to a specific
>    instance of a client.  For clients such as web sites that are used by
>    many users, there may not be significant privacy concerns regarding
>    the client identifier, but for clients such as native applications
>    that are installed on a single end-user's device, the client
>    identifier could be uniquely tracked during OAuth 2.0 transactions
>    and its use tied to that single end-user.  However, as the client
>    software still needs to be authorized by a resource owner through an
>    OAuth 2.0 authorization grant, this type of tracking can occur
>    whether or not the client identifier is unique by correlating the
>    authenticated resource owner with the requesting client identifier.
>
>    Note that clients are forbidden by this specification from creating
>    their own client identifier.  If the client were able to do so, an
>    individual client instance could be tracked across multiple colluding
>    authorization servers, leading to privacy and security issues.
>    Additionally, client identifiers are generally issued uniquely per
>    registration request, even for the same instance of software.  In
>    this way, an application could marginally improve privacy by
>    registering multiple times and appearing to be completely separate
>    applications.  However, this technique does incur significant
>    usability cost in the form of requiring multiple authorizations per
>    resource owner and is therefore unlikely to be used in practice.
>
>
> Hopefully this is more clear now.
>
> Thanks for the feedback and close review,
>  — Justin
>
> > On Feb 24, 2015, at 8:55 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> >
> > Yes but it is authenticating the client to the AS as part of the
> resource owners consent.
> >
> > Ther eis a one to one mapping of resource owner to client in that case.
> >
> > The client ID is no more identifying than the refresh token that maps to
> the RO by design.
> >
> > Yes the grant identifies the RO in some way.  The client_id and secret
> prevent that from being used in a different client if the bearer token
> leaks.
> >
> > Remember the client_id is going to be different at different AS as each
> will have a separate registration.
> > If the client_id was fixed across multiple AS then it would be a
> correlation issue, but that is not the case.
> >
> > Perhaps I am not understanding the concern?
> >
> > John B.
> >
> >> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >>
> >> Hi Justin, Hi John,
> >>
> >> I believe that provisioning a client with a unique id (which is what a
> >> client id/client secret is) allows some form of linkability. While it
> >> may be possible to associate the client to a specific user I could very
> >> well imagine that the correlation between activities from a user and
> >> those from the client (particularly when the client is running on the
> >> user's device) is quite possible.
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 06:37 PM, Justin Richer wrote:
> >>> I’ll incorporate this feedback into another draft, to be posted by the
> >>> end of the week. Thanks everyone!
> >>>
> >>> — Justin
> >>>
> >>>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
> >>>> <kathleen.moriarty.ietf@gmail.com
> >>>> <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com
> >>>> <mailto:ve7jtb@ve7jtb.com>> wrote:
> >>>>
> >>>>   snip
> >>>>>   On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
> >>>>>   <kathleen.moriarty.ietf@gmail.com
> >>>>>   <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
> >>>>>
> >>>>>> The client_id *could* be short lived, but they usually aren't. I
> don't see any particular logging or tracking concerns using a dynamic OAuth
> client above using any other piece of software, ever. As such, I don't
> think it requires special calling out here.
> >>>>>
> >>>>>
> >>>>>   Help me understand why there should not be text that shows this
> >>>>>   is not an issue or please propose some text.  This is bound to
> >>>>>   come up in IESG reviews if not addressed up front.
> >>>>>
> >>>>>
> >>>>
> >>>>   The client_id is used to communicate to the Authorization server
> >>>>   to get a code or refresh token.  Those tokens uniquely identify
> >>>>   the user from a privacy perspective.
> >>>>   It is the access tokens that are sent to the RS and those can and
> >>>>   should be rotated, but the client)id is not sent to the RS in
> >>>>   OAuth as part of the spec.
> >>>>
> >>>>   If you did rotate the client_id then the AS would track it across
> >>>>   rotations, so it wouldn’t really achieve anything.
> >>>>
> >>>>   One thing we don’t do is allow the client to specify the
> >>>>   client_id, that could allow correlation of the client across
> >>>>   multiple AS and that might be a privacy issue, but we don’t allow
> it.
> >>>>
> >>>>
> >>>> Thanks, John.  It may be helpful to add in this explanation unless
> >>>> there is some reason not to?
> >>>>
> >>>>
> >>>>   John B.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Best regards,
> >>>> Kathleen
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
>


-- 

Best regards,
Kathleen