Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell)

William Denniss <wdenniss@google.com> Thu, 14 December 2017 23:03 UTC

Return-Path: <wdenniss@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E471E126CBF for <oauth@ietfa.amsl.com>; Thu, 14 Dec 2017 15:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=google.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 q840i0FhiJnX for <oauth@ietfa.amsl.com>; Thu, 14 Dec 2017 15:03:56 -0800 (PST)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 DEF891205F0 for <oauth@ietf.org>; Thu, 14 Dec 2017 15:03:55 -0800 (PST)
Received: by mail-yb0-x233.google.com with SMTP id r4so4765304ybd.12 for <oauth@ietf.org>; Thu, 14 Dec 2017 15:03:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9uCQZ3uBfCC16Tgv17rqmNhG66X2gd6BAwPyjdixeUI=; b=vThNtliUf5K4LCMod1npLUR59NPhgFqy/ik6/uDoPlhziiRxdcto4kQ+yOsAnUdTGj vVwfoeXGPQ63wI6hA4Q+OTKXGZ3J4Yh4mC5xLnXuoXCF86nv1wF0rWMQqIRvLVFbVZHr bO2TfQG0Pqjzy9d64m2jx5miFww8hijtQlzipQe/tg0leOEqCOaIz6uhlhS6XLoeB7Zs X3+CKKeBp3q9C0Jg4aU8R43kYA9CKwGjeFe7L2KDyzYRsXXzhkqv4dOXUmGQWO/Xv3rL /xcbNSZgaVaEPJgXEBW5v8I+vxhf9y5rkoP0mwBEvA6KOMA100IQl9bIHZr6Jz53ypU6 kCXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9uCQZ3uBfCC16Tgv17rqmNhG66X2gd6BAwPyjdixeUI=; b=sOxjctuVu8dxMhcPu+DqNAxfAKc6sS4pgr7a2I70eE1QJ9FWuxcMTF+FZL4zVuX+6L SzqWyrJZpj62/yv1HseKwhEp+4olHvdgkHaGSqUv8MOfnuYoQoTlHL+Z0OJGykjQ4PjW BFXb12fiUud1hC9vMohSduizPysDWpMC/WrIDvdTmmKoZwBxGlJdM+3DBFY4FC1kuTqp AodnmmU2CyzCz7wBKYWdvXarw2iL2saBKf52BbCOX7dgQZS+By/1Lg6fr2iqMlYUzaYE uJRFtKOff0/dRlB1oxwxKsHLI34DlzAUVHQGlB2wEltdJKutSzJ0uGVnfGGkjmIlL9tm CkBA==
X-Gm-Message-State: AKGB3mKe4XtU3uv/Z4ZqMYd6HyBgq1tiEX/LD17ZVI9GmGciULfWfyjr ryQlFKv9j9wrMDm8pKAnfprkESvIkNcgVWrO51Nsng/d
X-Google-Smtp-Source: ACJfBoskPgAerKq+IIzPW71UY+rFU5yZRZA3jXh+Xs6IMuU5Zkm5BY01g8fOraE//RKaesN9aFX6b8s5x6T+PfACsgg=
X-Received: by 10.37.172.212 with SMTP id x20mr5619512ybd.512.1513292634567; Thu, 14 Dec 2017 15:03:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.146 with HTTP; Thu, 14 Dec 2017 15:03:34 -0800 (PST)
In-Reply-To: <B25A78BF-4BDD-49E4-99DC-B728BF401309@mit.edu>
References: <mailman.3552.1513014995.4036.oauth@ietf.org> <B017F0AB-BBEC-4198-9C80-A1103F566F42@iwelcome.com> <B25A78BF-4BDD-49E4-99DC-B728BF401309@mit.edu>
From: William Denniss <wdenniss@google.com>
Date: Thu, 14 Dec 2017 15:03:34 -0800
Message-ID: <CAAP42hCABr=0NN1dikv1kRJB7+FxAzN1eoHbe0=WdxpY_=mReQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Jaap Francke <jaap.francke@iwelcome.com>, "<oauth@ietf.org>" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="f403045ec2d4ed698b056054e53d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VI7bzIvw0KdwrKjiM4SJfwQVnbc>
Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 14 Dec 2017 23:04:00 -0000

This suggestion was considered by the working group, I raised the proposal
at IETF98, you can see the recording <https://youtu.be/kBEwdSKHLCA?t=49m54s>
.

The WG rejected the inclusion of this construct in the device flow
specification, but as Justin suggested, the door is open for a standalone
document so that it could be useful for *all* OAuth clients, not just
device flow ones.

On Mon, Dec 11, 2017 at 12:41 PM, Justin Richer <jricher@mit.edu> wrote:

> This could be useful but shouldn’t be done in a way that’s tied to the
> device flow — any public client would suffer from the same fate.
>
>  — Justin
>
> > On Dec 11, 2017, at 3:19 PM, Jaap Francke <jaap.francke@iwelcome.com>
> wrote:
> >
> > Hi all,
> >
> > I have previously made the following suggestion which still makes sense
> to me.
> >
> > […]we were working with one of our customers to implement the device
> flow as part of our IDaaS.
> > One of the requirements was the ability to revoke tokens for one of the
> devices at the Resource Server.
> >
> > In our use case, we used the terminolgy ‘pairing a device to the
> enduser’s account’ to describe the process of authorising a device to
> access the resource owner’s resources.
> > The resource owner may want to ‘unpair’ a device from a list of paired
> devices without having access to the device itself (anymore). Think about a
> stolen/lost kind of situation.
> > We are looking for ways to allow the user to unpair one of his devices
> at the Authorisation Server.
> > Since the Device Flow exchanges only the ‘generic’ client_id with the
> Authorisation Server, there is no logical way at the Resource Server to
> make a distinction between various devices (having the same client_id) that
> may be paired to the same Resource Owner.
> >
> > My suggestion is the following
> > - add an optional parameter to the device authorisation request (or
> device access token request): 'device_identifier'. A device can use this to
> make (for example) its serial-number known at the Resource Server.
> > - add an optional parameter to the device access token response that
> allows to communicate a name for the device as may have been given to it by
> the resource owner while allowing the clients access (E). This parameter
> could be something like ‘device_name’. The device may be able to display
> this ‘device_name’ on its display.
> >
> > Please consider this as a suggested enhancement of the Device Flow
> specifications.
> >
> >
> > Kind regards,
> >
> > Jaap
> >> On 11 Dec 2017, at 18:56, oauth-request@ietf.org wrote:
> >>
> >> Send OAuth mailing list submissions to
> >>      oauth@ietf.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>      https://www.ietf.org/mailman/listinfo/oauth
> >> or, via email, send a message with subject or body 'help' to
> >>      oauth-request@ietf.org
> >>
> >> You can reach the person managing the list at
> >>      oauth-owner@ietf.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of OAuth digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>  1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and Input
> >>     Constrained Devices (Brian Campbell)
> >>  2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.txt
> >>     (Justin Richer)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Mon, 11 Dec 2017 09:46:09 -0700
> >> From: Brian Campbell <bcampbell@pingidentity.com>
> >> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> >> Cc: oauth <oauth@ietf.org>
> >> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless
> >>      and Input Constrained Devices
> >> Message-ID:
> >>      <CA+k3eCRzTe2Xt_N-9mwsnc4WCdyWo3UTRe=UUnzcgidGpq
> mW_A@mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> I couldn't get the QR code to work... ;)
> >>
> >> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef <
> rifaat.ietf@gmail.com>
> >> wrote:
> >>
> >>> All,
> >>>
> >>> As discussed in Singapore, we are starting a WGLC for the
> >>> *draft-ietf-oauth-device-flow-07* document, starting today and ending
> on
> >>> December 11, 2018.
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
> >>>
> >>> Please, review the document and provide feedback on the list.
> >>>
> >>> Regards,
> >>> Rifaat & Hannes
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >>
> >> --
> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> >> material for the sole use of the intended recipient(s). Any review, use,
> >> distribution or disclosure by others is strictly prohibited.  If you
> have
> >> received this communication in error, please notify the sender
> immediately
> >> by e-mail and delete the message and any file attachments from your
> >> computer. Thank you.*
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/
> 20171211/119c614c/attachment.html>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Mon, 11 Dec 2017 12:56:21 -0500
> >> From: Justin Richer <jricher@mit.edu>
> >> To: Brian Campbell <bcampbell@pingidentity.com>
> >> Cc: Denis <denis.ietf@free.fr>fr>, "<oauth@ietf.org>" <oauth@ietf.org>
> >> Subject: Re: [OAUTH-WG] I-D Action:
> >>      draft-ietf-oauth-token-exchange-10.txt
> >> Message-ID: <94AA427C-744B-4A33-AEFC-A5F276C911A2@mit.edu>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> +1 to Brian
> >>
> >> -1 to the proposed text from Denis
> >>
> >>
> >>> On Dec 8, 2017, at 8:48 PM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
> >>>
> >>> The privacy matter is already mentioned. Despite your many messages to
> this WG and others about the so called ABC attack, I do not believe it
> warrants treatment in this document or others. And your continued proposals
> to have it included in documents have not gotten support.
> >>>
> >>> On Fri, Dec 8, 2017 at 2:46 PM, Denis <denis.ietf@free.fr <mailto:
> denis.ietf@free.fr>> wrote:
> >>> RFC 3552 (Guidelines for Writing RFC Text on Security Considerations)
> states:
> >>>
> >>>  All RFCs are required by RFC 2223 to contain a Security
> >>>  Considerations section.  The purpose of this is both to encourage
> >>>  document authors to consider security in their designs and to inform
> >>>  the reader of relevant security issues.  This memo is intended to
> >>>  provide guidance to RFC authors in service of both ends.
> >>>
> >>> Section 5 (Writing Security Considerations Sections) of RFC 3552
> states:
> >>>
> >>>  While it is not a requirement that any given protocol or system be
> >>>  immune to all forms of attack, it is still necessary for authors to
> >>>  consider as many forms as possible.  Part of the purpose of the
> >>>  Security Considerations section is to explain what attacks are out of
> >>>  scope and what countermeasures can be applied to defend against them
> >>>
> >>>  There should be a clear description of the kinds of threats on the
> >>>  described protocol or technology.
> >>>
> >>> It is important to mention the threat related to collusion attacks. A
> different wording could be used,
> >>> but the threat should be mentioned one way or another.
> >>>
> >>> RFC 6973 (Privacy Considerations for Internet Protocols) intends to
> provide a similar set of guidelines
> >>> for considering privacy in protocol design.
> >>>
> >>> It is important to mention a current threat related to privacy. A
> different wording could be used,
> >>> e.g. using the word "surveillance" as mentioned in 5.1.1 :
> "Surveillance is the observation or monitoring
> >>> of an individual?s communications or activities", but the threat
> should be mentioned one way or another.
> >>>
> >>> Denis
> >>>
> >>>> I believe the text would detract from the document.
> >>>> From: OAuth <oauth-bounces@ietf.org> <mailto:oauth-bounces@ietf.org>
> on behalf of Brian Campbell <bcampbell@pingidentity.com> <mailto:
> bcampbell@pingidentity.com>
> >>>> Sent: Friday, December 8, 2017 3:47:32 PM
> >>>> To: Denis
> >>>> Cc: oauth
> >>>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-
> exchange-10.txt
> >>>>
> >>>> As an individual, I do not believe that the proposed text should be
> incorporated into the draft.
> >>>>
> >>>> As one of the document editors, my responsibility is for the document
> to be of reasonable quality and to reflect the rough consensus of this
> Working Group. So I should ask the list more explicitly - are there other
> WG remembers who are in favor of the proposed text here (the text would
> have to be fixed up some too)?
> >>>>
> >>>> On Fri, Dec 1, 2017 at 11:12 AM, Denis <denis.ietf@free.fr <mailto:
> denis.ietf@free.fr>> wrote:
> >>>> Comments on draft-ietf-oauth-token-exchange-10
> >>>>
> >>>> I propose the following rephrasing for sections 6 and 7:
> >>>>
> >>>> 6 . Security Considerations
> >>>>
> >>>> All of the normal security issues that are discussed in
> [JWT],especially in relationship to comparing URIs
> >>>> and dealing with unrecognized values, also apply here.  In addition,
> both delegation and impersonation introduce
> >>>> unique security issues. Any time one user receives a token, the
> potential for abuse is a concern,
> >>>> since that user might be willing to collude with another user so that
> other user could use the token.
> >>>>
> >>>> Techniques like the binding of an access token to a TLS channel
> described elsewhere are ineffective since
> >>>> the legitimate user would be able to perform all the cryptographic
> computations that the other user would need
> >>>> to demonstrate the ownership of the token. The use of the "scp" claim
> is suggested to mitigate potential for
> >>>> such abuse, as it restricts the contexts in which the token can be
> exercised.  If the issued access token scope
> >>>> allows to unambiguously identify the user, then that user is likely
> to be reluctant to collude with another user.
> >>>> However, if the issued access token scope only indicates that the
> user is over 18, then there is no risk
> >>>> for the original user to be discovered and in such a context a
> collusion may easily take place.
> >>>> This document does not specify techniques to prevent such a collusion
> to be successful.
> >>>>
> >>>> 7 . Privacy Considerations
> >>>>
> >>>> Tokens typically carry personal information and their usage in Token
> Exchange may reveal details of the target services
> >>>> being accessed. The resource and the audience parameters allow
> authorization servers to know where the issued access token
> >>>> will be used.  This may be a privacy concern for some users. This
> document does not specify techniques to prevent
> >>>> authorization servers to know where the access tokens they issue will
> be used.
> >>>>
> >>>> Denis
> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>>>> This draft is a work item of the Web Authorization Protocol WG of
> the IETF.
> >>>>>
> >>>>>       Title           : OAuth 2.0 Token Exchange
> >>>>>       Authors         : Michael B. Jones
> >>>>>                         Anthony Nadalin
> >>>>>                         Brian Campbell
> >>>>>                         John Bradley
> >>>>>                         Chuck Mortimore
> >>>>>   Filename        : draft-ietf-oauth-token-exchange-10.txt
> >>>>>   Pages           : 32
> >>>>>   Date            : 2017-11-30
> >>>>>
> >>>>> Abstract:
> >>>>>  This specification defines a protocol for an HTTP- and JSON- based
> >>>>>  Security Token Service (STS) by defining how to request and obtain
> >>>>>  security tokens from OAuth 2.0 authorization servers, including
> >>>>>  security tokens employing impersonation and delegation.
> >>>>>
> >>>>>
> >>>>> The IETF datatracker status page for this draft is:
> >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
> >>>>>
> >>>>> There are also htmlized versions available at:
> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 <
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10>
> >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
> token-exchange-10 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
> token-exchange-10>
> >>>>>
> >>>>> A diff from the previous version is available at:
> >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10
> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10>
> >>>>>
> >>>>>
> >>>>> Please note that it may take a couple of minutes from the time of
> submission
> >>>>> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org/>.
> >>>>>
> >>>>> Internet-Drafts are also available by anonymous FTP at:
> >>>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-
> drafts/>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>
> >>>>
> >>>>
> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.
> >>>
> >>>
> >>>
> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth>
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/
> 20171211/dbd247f6/attachment.html>
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >> ------------------------------
> >>
> >> End of OAuth Digest, Vol 110, Issue 8
> >> *************************************
> >
> > _______________________________________________
> > 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
>