Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt

Justin Richer <jricher@mit.edu> Mon, 11 December 2017 17:56 UTC

Return-Path: <jricher@mit.edu>
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 73B12127BA3 for <oauth@ietfa.amsl.com>; Mon, 11 Dec 2017 09:56:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham 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 zjFwFSY8s5Fi for <oauth@ietfa.amsl.com>; Mon, 11 Dec 2017 09:56:31 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5861271FD for <oauth@ietf.org>; Mon, 11 Dec 2017 09:56:30 -0800 (PST)
X-AuditID: 1209190d-b65ff70000007ce7-bb-5a2ec6cc5ef1
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 87.86.31975.CC6CE2A5; Mon, 11 Dec 2017 12:56:29 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vBBHuOeJ012136; Mon, 11 Dec 2017 12:56:25 -0500
Received: from [192.168.1.9] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBBHuLSP019509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Dec 2017 12:56:23 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <94AA427C-744B-4A33-AEFC-A5F276C911A2@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_33D54241-FB8A-4A09-AD6F-72B13AF05A17"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 11 Dec 2017 12:56:21 -0500
In-Reply-To: <CA+k3eCQdUcpQoZSFm6pivnahi-odsbwoP2TNmssXUWkxPbKXuQ@mail.gmail.com>
Cc: Denis <denis.ietf@free.fr>, "<oauth@ietf.org>" <oauth@ietf.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> <e51e90e0-ff21-511a-6635-ed42e42575be@free.fr> <CA+k3eCThLVxBarzZAxPqWhFKP-a6cdk-xXmg3droGu7QdjpCDg@mail.gmail.com> <CY4PR21MB05042AF4B393C14146411240F5300@CY4PR21MB0504.namprd21.prod.outlook.com> <9e362874-54d3-ae73-2e77-fc0eb3a98e3b@free.fr> <CA+k3eCQdUcpQoZSFm6pivnahi-odsbwoP2TNmssXUWkxPbKXuQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsUixG6nonv2mF6Uwbt1Ahar/99ktFjfZWdx 8u0rNgdmj/51n1k9liz5yeRx9+hFlgDmKC6blNSczLLUIn27BK6Mk0+eMRX0tzFVTPuwmamB se0xYxcjJ4eEgInExfcH2boYuTiEBBYzSTy5voMdwtnIKNH8p4kVwrnGJLHi2DlmkBY2AVWJ 6WtamEBsXgEriRdPtrCB2MwCSRLvrzQCxTmA4voSvc/BNggLeEm8PNHCCmKzALVunLQPLM4p EChx/Ng1RohWZ4k9E+aCjREBar39dA47iC0k0M4scWNGIMSlshK3Zl9insDIPwvJtlkI2yDC 2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwS vdSU0k2MoGDnlOTdwfjvrtchRgEORiUe3ogOvSgh1sSy4srcQ4ySHExKorwswUAhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrymfrpRQrwpiZVVqUX5MClpDhYlcV53E+0oIYH0xJLU7NTUgtQi mKwMB4eSBO/xo0BDBYtS01Mr0jJzShDSTBycIMN5gIb/A6nhLS5IzC3OTIfIn2IM5HjScuMP E8eGm3eB5D4wueH7AyD5bObrBmaOaVdbm5g55h3/1sQsxJKXn5cqJc67GWSQAMigjNI8uF2g ZOe+zs7iFaM40OvCvA7A1CfEA0yUcNteAR3CBHQI02RtkENKEhFSUg2MSnt3JUoWP1a6W7px 7vefmzrc+uLvr1Sz4/p7WlP0jfFJGb89H5tDdXXvMbg+3fb55okZ2/kin/wT17zIrjb3q8Ha 6k1vxfMe3A69dOp/U9qFBLUPm/ee77/7Q7R42o8nB0QT/Hb7z46xyfZezdF2m/Wa1c4Y8UUK 33LelaY27YvcfKqEQWZ/jxJLcUaioRZzUXEiAJsSd8dRAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qHc4sRZcJqCJl1W2vPAAwekdQu4>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt
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: Mon, 11 Dec 2017 17:56:34 -0000

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