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

From: Denis <[email-masked]>
Date: Fri, 1 Dec 2017 19:12:30 +0100

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/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/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
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Dec 2017 13:47:32 -0700

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 <[email-masked]> wrote:

> 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,
> Techniques like the binding of an access token to a TLS channel described
> elsewhere are ineffective since
> 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
> The IETF datatracker status page for this draft is: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-10https://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
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
> OAuth mailing [email-masked]://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.*

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Dec 2017 20:55:53 +0000

I believe the text would detract from the document.
________________________________
From: OAuth <[email-masked]> on behalf of Brian Campbell <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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

Abstract:

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

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: Denis <[email-masked]>
Date: Fri, 8 Dec 2017 22:46:25 +0100

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

> ------------------------------------------------------------------------
> *From:* OAuth <[email-masked]> on behalf of Brian Campbell 
> <[email-masked]>
> *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 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)?
>
>     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
>     to demonstrate the ownership of the token. The use of the "scp"
>     claim is suggested to mitigate potential for
>     allows to unambiguously identify the user, then that user is
>     likely to be reluctant to collude with another user.
>     Tokens typically carry personal information and their usage in
>     Token Exchange may reveal details of the target services
>>     <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
>>
>>     <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10>
>>     <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10>
>>
>>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10>
>>
>>
>>     until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>>
>>     <ftp://ftp.ietf.org/internet-drafts/>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <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./

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Dec 2017 18:48:09 -0700

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 <[email-masked]> wrote:

>    Considerations section.  The purpose of this is both to encourage
>    the reader of relevant security issues.  This memo is intended to
>    consider as many forms as possible.  Part of the purpose of the
> but the threat should be mentioned one way or another.
> 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
>
> ------------------------------
> *From:* OAuth <[email-masked]> <[email-masked]> on behalf
> of Brian Campbell <[email-masked]>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-
> exchange-10.txt
>
> 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
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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.*
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 11 Dec 2017 12:56:21 -0500

+1 to Brian

-1 to the proposed text from Denis

> On Dec 8, 2017, at 8:48 PM, Brian Campbell <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) states: 
> 
> It is important to mention the threat related to collusion attacks. A different wording could be used, 
> RFC 6973 (Privacy Considerations for Internet Protocols) intends to provide a similar set of guidelines 
> 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
> 
>> From: OAuth <[email-masked]> <mailto:[email-masked]> on behalf of Brian Campbell <[email-masked]> <mailto:[email-masked]>
>> On Fri, Dec 1, 2017 at 11:12 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
>>> 
>>> 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>
>>> 
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10>
>>> 
>>> 
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 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._______________________________________________
> OAuth mailing list
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>