Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

From: Denis <[email-masked]>
Date: Sun, 16 Jul 2017 16:38:40 +0200

Hello Brian,

It took 25 days to get a response to my WGLC comments and it took me 13 
days to answer to your reply.

My responses are embedded in the text. At present, I only agree with the 
resolution of the comment numbered 6.

> Thanks for the review, Denis. And I apologize for the slow reply - 
> I've had a lot of different things on my plate recently. And, quite 
> frankly, I was sort of hoping one of the co-authors on the document 
> might respond to your comments. But hope only goes so far. So replies 
> are inline below...
>
> On Mon, Jun 5, 2017 at 5:30 AM, Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Comments on OAuth 2.0 Token Exchange
>     draft-ietf-oauth-token-exchange-08
>
>     1. The abstract states:
>
>            "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 problem is that the content of the abstract does not match
>     with the content of the document.
>
>     The abstract clearly states that all cases of token requests are
>     supported, whereas the document mandates
>     the use of a subject_token parameter which restricts the scope to
>     impersonation and delegation.
>
>     Currently the text states:
>
>        "subject_token
>     *REQUIRED*.  A security token that represents the identity of the
>           party on behalf of whom the request is being made. 
>     Typically, the
>           subject of this token will be the subject of the security token
>           issued in response to this request".
>
>     The abstract should be changed to reflect the content of the document.
>
>
> I don't see a discrepancy between the content of the abstract and the 
> content of the document.
>
> What text or changes would you suggest in the 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 when a specific 
parameter
is required to identify the party on behalf of whom the request is being 
made".

However, please read the other comments, since I am not sure thatthis 
change will be sufficient.

>
>     2. The text states on page 4:
>
>            "The scope of this specification is limited to the
>         definition of a
>            basic request and response protocol for an STS-style token
>         exchange
>            utilizing OAuth 2.0.  Although a few new JWT claims are
>         defined that
>            enable delegation semantics to be expressed, the specific
>         syntax,
>            semantics and security characteristics of the tokens
>         themselves (both
>            those presented to the AS and those obtained by the client) are
>            explicitly out of scope and no requirements are placed on
>         the trust
>            model in which an implementation might be deployed".
>
>     These statements are contradictory. One parameter of the request
>     is mandatory (i.e. subject_token)
>     but there is no indication of the kind of treatment which should
>     be done with this parameter so that
>     it will be taken into consideration one way or another in the
>     token that will be issued.
>
>     This document by itself would be insufficient to allow any kind of
>     interoperability.
>     Conformance to this document would not mean anything.
>
>
> The token exchange framework promotes interoperability in the form of 
> common patterns and parameters that can be supported in libraries, 
> products, and services. It facilitates deployments like this one 
> https://help.salesforce.com/articleView?id=remoteaccess_oauth_asset_token_flow.htm 
> <https://help.salesforce.com/articleView?id=remoteaccess_oauth_asset_token_flow.htm> 
> or this one 
> https://developer.box.com/docs/getting-started-with-new-box-view 
> <https://developer.box.com/docs/getting-started-with-new-box-view>, 
> for example.
>

This is not an adequate response to my comment. Text is currently 
missing to explain
what kind of treatment should be done with this parameter.

  What should the STS do with this parameter when it receives it ?

  How, this parameter should be processed so that it can be placed in a 
security token ?

  Is there a relationship (if any) between the "subject_token" and the 
"cid" (Client Identifier)
  that will be placed in the security token ?

  Why shall a security_token be used instead of simply an identifier of 
the OAuth 2.0client
  that requested the token ?

  The current draft cannot be understood.

>
>
>     3. On page 7, the text states:
>
>        "subject_token
>           REQUIRED.  A security token that represents the identity of the
>           party on behalf of whom the request is being made".
>
>     It is understood that one implementation is already using this
>     parameter to place in it a security token.
>     Since this parameter is indicated as REQUIRED, it is not
>     understandable why a security token shall necessarily be used.
>     There are other means for the STS to identify the "party on behalf
>     of whom the request is being made".
>
>     Please add a rational.
>
>
> I don't understand what kind of rational you are looking for here. Can 
> you suggest some specific text for the document that would address the 
> concern you have?

In order to identify "the party on behalf of whom the request is being 
made", there is no need to use a security token.
The text does not explain the benefits, if any, of using a security token.

It does not explain either the drawbacks, i.e. the complexity for using 
it, in particular, how a relying party can verify
that the security token is protected by the right key.

What kind of trust relationships would need to be pre-established is not 
explained.

I believe that using a security token to represent the identity of the 
party on behalf of whom the request is being made
adds an extra level of complexity and for that reason a security token 
should NOT be used.

If you believe that it should, then you have to explain the trust 
relationships, the benefits and the way to handle this parameter
as it is currently not the case.

>
>     In addition, what the STS will do, can do or should do with this
>     parameter is left undefined.
>
>
>     4. On page 7, the text states:
>
>        "subject_token
>           REQUIRED.  (...)  Typically, the subject of this token will be
>           the subject of the security token issued in response to this
>           request".
>
>     This sentence is quite hard to understand since the specific
>     syntax, semantics and security characteristics of the tokens
>     themselves
>     are explicitly out of scope. The key point is what the STS should
>     do with this parameter: this is left undefined.
>
>
> I don't view the sentence as difficult to understand. Maybe that's 
> because I wrote it?  But it is true that typically it is the case that 
> the subject of the inbound token will be the subject of the issued 
> token. I don't know how else to say it. Please offer suggested text, 
> if you believe there's a way to say it that is easier to understand.
>

Could we defined this parameter in the following way ?

subject_token
       REQUIRED.  An identifier of the party on behalf of whom the 
request is being made (...)
                             This identifier will be copied and pasted 
into the security token issued in response to this request
                             to designate the claimed holder of the 
issued security token designated as the "cid" (Client Identifier) 
claimin RFC 6749.

>
>     5. The text states:
>
>            " (...) Additional
>            profiles may provide more detailed requirements around the
>         specific
>            nature of the parties and trust involved, such as whether
>         signing
>            and/or encryption of tokens is needed or if
>         proof-of-possession style
>            tokens will be required or issued;
>
>     Tokens are always signed. Please modify the sentence accordingly.
>
>
> A token might well be cryptographically secure random sequence of 
> characters that reference data that can be looked up by the 
> appropriate parties. Or a token might be an AEAD symmetrically 
> encrypted JWT. So no, tokens are not always signed.

Could we rephrase in the following way?

    " (...) Additional profiles may provide more detailed requirements 
around the specific nature of the parties and trust involved,
      such as how integrity protection of the tokens shall be done and 
if proof-of-possession style tokens will be required or issued;

>
>
>     6. The following sentence is important and is being noticed.
>
>        The security tokens obtained could be used in a number of contexts,
>        the specifics of which are also beyond the scope of this
>        specification.
>
>     Changing the "could" into a "may" would however be more appropriate.
>
>
> Agreed, I'll make that change.

Thanks.

>
>
>     7. In section  2.1 request, the text defines:
>
>        resource
>           OPTIONAL.  Indicates the physical location of the target service
>           or resource where the client intends to use the requested
>     security
>           token.
>
>     and
>
>        audience
>           OPTIONAL.  The logical name of the target service where the
>     client
>           intends to use the requested security token.
>
>     If the resource or the audience parameter is being used, the STS
>     will have the ability to know exactly which individual
>     or entity has accessed which target service and may keep a log of
>     that activity. It would be in a position to act as Big Brother.
>     This should be clearly indicated in a section that is currently
>     missing : "7. Privacy Considerations". See a text proposal hereafter.
>
>     However, there is indeed the need to restrict the use of tokens to
>     specific targets. The key point is that the target service
>     must be able to recognize itself that the token is indeed targeted
>     to it. As an example, a challenge may be requested to
>     the target service and that challenge may then be placed into a
>     specific filed of the token. The target service may then verify
>     that the value included in the token is the one that has been
>     recently provided.
>
>     A parameter specifying the type of the control value and the value
>     of the control should be added.
>     This parameter would be called a target_id (tid). It would solve
>     the Big Brother case.
>
>
> That is both beyond the scope of this document and potentiality 
> applicable to a broader context of use. I'd suggest you write an 
> individual draft for the concept, if you want to pursue it.

This topic has been addressed twice by two presentations on July the 13 
th at the end of the first day of the OAuth workshop in Zürich.

During this meeting, there have been different proposals to solve the 
issue. I also said that other possibilities were possible.

The fact is that currently no technique has been agreed to solve the issue.

I see two options:

a)freeze this document and wait until a technique can be agreed within 
the WG and defined in another RFC,
so thatwe can reference it and then after continue the work on this document

b)don't wait, but mention that currently no parameter has been defined 
to address the issue.

My preference would be for option a)

What would be your preference ?

If we take option b), then take a look at a new text proposal for the 
comment numbered 10.

>
>
>     8. The Security Considerations section states:
>
>        "In addition, both delegation and impersonation introduce unique
>        security issues.  Any time one principal is delegated the rights of
>        another principal, the potential for abuse is a concern.  The
>     use of
>        the "scp" claim is suggested to mitigate potential for such
>     abuse, as
>        it restricts the contexts in which the delegated rights can be
>        exercised".
>
>     Section 4.2 defines the "scp" (Scopes) claim in the following way:
>
>        The "scp" claim is an array of strings, each of which represents an
>        OAuth scope granted for the issued security token. Each array entry
>        of the claim value is a scope-token, as defined in Section 3.3 of
>        OAuth 2.0 [RFC6749].
>
>     Section 3.3 from RFC 6749 defines the Access Token Scope as:
>
>        "The authorization and token endpoints allow the client to
>     specify the
>        scope of the access request using the "scope" request
>     parameter.  In
>        turn, the authorization server uses the "scope" response
>     parameter to
>        inform the client of the scope of the access token issued.
>        The value of the scope parameter is expressed as a list of space-
>        delimited, case-sensitive strings.  The strings are defined by the
>        authorization server".
>
>     Section 5.4.1 Registry Contents defines scp as:
>
>        o  Claim Name: "scp"
>        o  Claim Description: Scope Values
>        o  Change Controller: IESG
>        o  Specification Document(s): Section 4.2 of [[ this
>     specification ]]
>
>     Since the "strings are defined by the authorization servers", what
>     a scope may mean is subject to multiple interpretations.
>     The current definition of scp is insufficient to allow any kind of
>     interoperability, now or in the future.
>
>     It is thus unclear how the use of the "scp" claim might mitigate
>     the risk.
>
>
> Scoping the token restricts what the token can be used for which 
> limits the impact of a compromised or misused token. The scope values 
> are interpreted by the parties involved just as with regular OAuth.
>
This is not an adequate response to my comment.

You say that "scope values are interpreted by the parties involved just 
as with regular OAuth".

I suggest the following text as a full replacement of the quoted text:

    Both delegation and impersonation introduce unique security issues. 
    The potential for abuse is a concern.
    The use of the "scp" claim allows to restrict the contexts in which
    the delegated rights can be exercised.

    Strings in the "scp" claim are defined by the authorization servers.
    If the client gets some knowledge
    on how these strings will be handled both by a resource server and
    by an authorization server, then the use
    of the "scp" claim can be used to mitigate potential for such abuse.
    However, at the time of the issuance of this RFC,
    techniques for applying such restrictions are not defined in other RFCs.

    In addition, users may collude and one user might be willing to
    allow another user to make use of a security token that it has
    obtained.
    This is not a concern in the context of a delegation scheme, but may
    be a serious concern in some other contexts. Whatever kind
    of cryptography is being used, there is no way to stop collusion
    between users, unless some secure hardware is required to be used
    by a security token requester in order to obtain a security token.
    In other words, a software-only implementation is unable to prevent
    collusion between users. A hardware solution simply protecting some
    secret key or some private key will also be ineffective, since
    one user would be able to perform all the cryptographic computations
    that the other user needs.

Note: People that were present on July the 13 th on the first day of the 
OAuth workshop in Zürich may understand better what I mean.
The text and the slides of this workshop should be publicly available 
shortly.

>
>     9. This document is currently targeted to become a Standards Track
>     document.
>
>     RFC 6410 recognizes two maturity levels:
>
>        - the First Maturity Level: Proposed Standard
>        - the Second Maturity Level: Internet Standard
>
>     It is not believed that currently it is possible to construct two
>     independent interoperating implementations
>     looking at this document only. Unless more guidance is provided,
>     this document should be targeted to "Experimental".
>
>
> I completely disagree. And would also note that the the document's 
> intended status has been stable and unquestioned by this WG for 
> several years.
>

Section 2.1 from RFC 6410 states:

The stated requirements for Proposed Standard are not changed; they
remain exactly as specified in RFC 2026 [1].No new requirements are
introduced; no existing published requirements are relaxed.

Section 4.1.1 from RFC 2026 states:

A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be *well-understood*, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable.

(...)

A Proposed Standard should have *no known technical omissions* with
respect to the requirements placed upon it.

I don't believe that the current text complies with the previous statements.

One of the goals of this document is to define a new parameter called 
"subject_token".

In order to use it, we need to say how the client, the AS and the RP 
shall handle it.
The current text is insufficient to know how to handle it.

Unless additional information is provided, this document should be 
targeted to "Experimental".

>
>
>     10. Text proposal for a new section "7. Privacy Considerations".
>
>        7. Privacy Considerations
>
>        7.1. Resource and audience parameters
>
>        The use of any these two parameters allow the STS to know which
>        target servers are being accessed by any party making a token
>        request.  Any STS is then able to log token requests.  This is not
>        a problem if the resource owner and the target server are
>     collocated,
>        but this document is not restricted to that case.
>
>        For the other cases, it should be noticed that the STS will be in
>        position to act as Big Brother.  When privacy is a concern, the
>     use
>        of these parameters is deprecated and the use of a "tid" parameter
>        is recommended.
>
>
> I will add a privacy considerations with mention of being able to 
> track the target systems intended to be accessed by the party 
> requesting a token.
>

The privacy section that has been added is the following:

    Privacy Considerations

    Tokens typically carry personal information and their usage in Token
    Exchange may reveal details of the target services being accessed.
    As such, tokens should only be requested and sent according to the
    privacy policies at the respective organizations.

It does not address my concern. Hereafter is a new text proposal to 
address my concern, ... if we follow option b) as mentioned beforehand.:

    7. Privacy Considerations

    7.1. Resource and audience parameters

    The use of the resource or of the audience parameter allows the STS 
to know which target servers are being accessed
    by any party making a tokenrequest.  Any STS will then be able to 
log token requests. This is not a problem as long as
    the resource owner and the target server are collocated, but this 
document is not restricted to this case.

    For the other cases, if either the resource parameter or the 
audience parameter is being used, the STS will be in position
    to act as Big Brother. When privacy is a concern, the use of the 
resource parameter and of the audience parameter is deprecated
    and another parameter should be used to restrict the target servers 
that can use the security token. At the time of the issuance
    of this document, such a parameter was not yet defined in another RFC.

7.2. Use of RFC 7662 (OAuth 2.0 Token Introspection)

    RFC7662 defines a protocol that allows authorized protected 
resources to query the authorization server to determine the set of 
metadata
    for a given token that was presented to them by an OAuth 2.0 client.

The use of this protocol raises some privacy concerns, since the STS is 
then able to identify the clients accessing the introspection endpoint.
    This concern will remain even when the resource parameter or the 
audience parameter will not be used. Such parameters might be in the future
    replaced by another means to restrict the use of the security tokens 
to specific resource servers, but a call back to the authorization 
server would
    ruin the benefits of the use of this alternative means.

Denis

>
>
>     Denis
>
>>     All,
>>
>>     We are starting a WGLC on the Token Exchange document:
>>     https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08
>>     <https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08>
>>
>>     Please, review the document and provide feedback on any issues
>>     you see with the document.
>>
>>     The WGLC will end in two weeks, on June 17, 2017.
>>
>>     Regards,
>>      Rifaat and Hannes
>>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     [email-masked] <mailto:[email-masked]>
>     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./

---

From: Brian Campbell <[email-masked]>
Date: Sun, 16 Jul 2017 11:46:08 -0600

Speaking as an individual, for a number of reasons, I do not believe that
any of the additional comments or suggestions should be incorporated into
the document.

As a document editor working within the IETF processes, my aim is for the
document to reflect the (rough) consensus of this Working Group. And I
don't get the sense that there's support, let alone consensus, for any of
these changes. However, rather than relying on my interpretation of support
or lack thereof from the WG, I'll ask more explicitly - are there other WG
remembers who are in favor of working to incorporate any of these comments
or suggestions?

On Sun, Jul 16, 2017 at 8:38 AM, Denis <[email-masked]> wrote:

> Thanks for the review, Denis. And I apologize for the slow reply - I've
> had a lot of different things on my plate recently. And, quite frankly, I
> was sort of hoping one of the co-authors on the document might respond to
> your comments. But hope only goes so far. So replies are inline below...
>
> On Mon, Jun 5, 2017 at 5:30 AM, Denis <[email-masked]> wrote:
>
>> Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08
>>
>> 1. The abstract states:
>>
>> The problem is that the content of the abstract does not match with the
>> content of the document.
>>
>>       party on behalf of whom the request is being made.  Typically, the
> However, please read the other comments, since I am not sure that this
>>    "The scope of this specification is limited to the definition of a
>>    basic request and response protocol for an STS-style token exchange
>>    utilizing OAuth 2.0.  Although a few new JWT claims are defined that
>>    enable delegation semantics to be expressed, the specific syntax,
>>    semantics and security characteristics of the tokens themselves (both
>>    explicitly out of scope and no requirements are placed on the trust
>> These statements are contradictory. One parameter of the request is
>> mandatory (i.e. subject_token)
>> but there is no indication of the kind of treatment which should be done
>> with this parameter so that
>> it will be taken into consideration one way or another in the token that
>> will be issued.
>>
> https://help.salesforce.com/articleView?id=remoteaccess_oaut
> h_asset_token_flow.htm or this one https://developer.box.com/docs
> /getting-started-with-new-box-view, for example.
>
>
> This is not an adequate response to my comment. Text is currently missing
> to explain
>  Why shall a security_token be used instead of simply an identifier of the
> OAuth 2.0 client
>> It is understood that one implementation is already using this parameter
>> to place in it a security token.
>> Since this parameter is indicated as REQUIRED, it is not understandable
>> why a security token shall necessarily be used.
>> There are other means for the STS to identify the "party on behalf of
>> whom the request is being made".
>>
>> Please add a rational.
>>
>
> I don't understand what kind of rational you are looking for here. Can you
> suggest some specific text for the document that would address the concern
> you have?
>
>
>> This sentence is quite hard to understand since the specific syntax,
>> semantics and security characteristics of the tokens themselves
>> are explicitly out of scope. The key point is what the STS should do with
>> this parameter: this is left undefined.
>>
>
> because I wrote it?  But it is true that typically it is the case that the
> subject of the inbound token will be the subject of the issued token. I
> don't know how else to say it. Please offer suggested text, if you believe
> there's a way to say it that is easier to understand.
>
>
>       REQUIRED.  An identifier of the party on behalf of whom the request
> is being made (...)
>                             This identifier will be copied and pasted into
> the security token issued in response to this request
>                             to designate the claimed holder of the issued
> security token designated as the "cid" (Client Identifier) claim in RFC
> 6749.
>
>
>> 5. The text states:
>>
>>    " (...) Additional
>>    profiles may provide more detailed requirements around the specific
>>    nature of the parties and trust involved, such as whether signing
>>    and/or encryption of tokens is needed or if proof-of-possession style
> characters that reference data that can be looked up by the appropriate
> parties. Or a token might be an AEAD symmetrically encrypted JWT. So no,
> tokens are not always signed.
>
>
>      such as how integrity protection of the tokens shall be done and if
> proof-of-possession style tokens will be required or issued;
>
>
>
>
>>
>>
>>       or resource where the client intends to use the requested security
>>       token.
>>
>> and
>>
>>    audience
>>       OPTIONAL.  The logical name of the target service where the client
>> If the resource or the audience parameter is being used, the STS will
>> have the ability to know exactly which individual
>> or entity has accessed which target service and may keep a log of that
>> activity. It would be in a position to act as Big Brother.
>> This should be clearly indicated in a section that is currently missing :
>> "7. Privacy Considerations". See a text proposal hereafter.
>>
>> must be able to recognize itself that the token is indeed targeted to it.
>> As an example, a challenge may be requested to
>> the target service and that challenge may then be placed into a specific
>> filed of the token. The target service may then verify
>> that the value included in the token is the one that has been recently
>> provided.
>>
>> A parameter specifying the type of the control value and the value of the
>> control should be added.
>> This parameter would be called a target_id (tid). It would solve the Big
>> Brother case.
>>
>
> That is both beyond the scope of this document and potentiality applicable
> to a broader context of use. I'd suggest you write an individual draft for
> the concept, if you want to pursue it.
>
>
>
> This topic has been addressed twice by two presentations on July the 13 th
> at the end of the first day of the OAuth workshop in Zürich.
>
> a)     freeze this document and wait until a technique can be agreed
> within the WG and defined in another RFC,
> so that  we can reference it and then after continue the work on this
> document
>
> b)     don't wait, but mention that currently no parameter has been
> defined to address the issue.
>
>>    another principal, the potential for abuse is a concern.  The use of
>>    the "scp" claim is suggested to mitigate potential for such abuse, as
>>    "The authorization and token endpoints allow the client to specify the
>>    scope of the access request using the "scope" request parameter.  In
>>    turn, the authorization server uses the "scope" response parameter to
>>    o  Specification Document(s): Section 4.2 of [[ this specification ]]
>>
>> Since the "strings are defined by the authorization servers", what a
>> scope may mean is subject to multiple interpretations.
>> It is thus unclear how the use of the "scp" claim might mitigate the risk.
>>
>
> Scoping the token restricts what the token can be used for which limits
> the impact of a compromised or misused token. The scope values are
> interpreted by the parties involved just as with regular OAuth.
>
> You say that "scope values are interpreted by the parties involved just as
> with regular OAuth".
>
> Both delegation and impersonation introduce unique security issues.  The
> potential for abuse is a concern.
> The use of the "scp" claim allows to restrict the contexts in which the
> delegated rights can be exercised.
>
> Strings in the "scp" claim are defined by the authorization servers. If
> the client gets some knowledge
> on how these strings will be handled both by a resource server and by an
> authorization server, then the use
> In addition, users may collude and one user might be willing to allow
> another user to make use of a security token that it has obtained.
> This is not a concern in the context of a delegation scheme, but may be a
> serious concern in some other contexts. Whatever kind
> of cryptography is being used, there is no way to stop collusion between
> users, unless some secure hardware is required to be used
> by a security token requester in order to obtain a security token. In
> other words, a software-only implementation is unable to prevent
> collusion between users. A hardware solution simply protecting some secret
> key or some private key will also be ineffective, since
> one user would be able to perform all the cryptographic computations that
> the other user needs.
>
>> looking at this document only. Unless more guidance is provided, this
>> document should be targeted to "Experimental".
>>
>
> intended status has been stable and unquestioned by this WG for several
> years.
>
>
>    remain exactly as specified in RFC 2026 [1].  No new requirements are
> In order to use it, we need to say how the client, the AS and the RP shall
> handle it.
>>    a problem if the resource owner and the target server are collocated,
>>    position to act as Big Brother.  When privacy is a concern, the use
> I will add a privacy considerations with mention of being able to track
> the target systems intended to be accessed by the party requesting a
> token.
>
>
>    The use of the resource or of the audience parameter allows the STS to
> know which target servers are being accessed
>    by any party making a token request.  Any STS will then be able to log
> token requests. This is not a problem as long as
>    For the other cases, if either the resource parameter or the audience
> parameter is being used, the STS will be in position
>    RFC7662 defines a protocol that allows authorized protected resources
> to query the authorization server to determine the set of metadata
>    replaced by another means to restrict the use of the security tokens to
> specific resource servers, but a call back to the authorization server
> would
>> Please, review the document and provide feedback on any issues you see
>> with the document.
>>
>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> [email-masked]
> *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.*
>
>
>

-- 
*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: Sun, 16 Jul 2017 18:02:19 +0000

I agree with you, Brian, that incorporating the proposed changes would not further the goals of the document.  Rather, they would detract from achieving them.

                                                       -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Sunday, July 16, 2017 7:46 PM
To: Denis <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08

Speaking as an individual, for a number of reasons, I do not believe that any of the additional comments or suggestions should be incorporated into the document.
As a document editor working within the IETF processes, my aim is for the document to reflect the (rough) consensus of this Working Group. And I don't get the sense that there's support, let alone consensus, for any of these changes. However, rather than relying on my interpretation of support or lack thereof from the WG, I'll ask more explicitly - are there other WG remembers who are in favor of working to incorporate any of these comments or suggestions?

On Sun, Jul 16, 2017 at 8:38 AM, Denis <[email-masked]<mailto:[email-masked]>> wrote:
Hello Brian,

It took 25 days to get a response to my WGLC comments and it took me 13 days to answer to your reply.

My responses are embedded in the text. At present, I only agree with the resolution of the comment numbered 6.
Thanks for the review, Denis. And I apologize for the slow reply - I've had a lot of different things on my plate recently. And, quite frankly, I was sort of hoping one of the co-authors on the document might respond to your comments. But hope only goes so far. So replies are inline below...

On Mon, Jun 5, 2017 at 5:30 AM, Denis <[email-masked]<mailto:[email-masked]>> wrote:
Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08

1. The abstract states:
The problem is that the content of the abstract does not match with the content of the document.

The abstract clearly states that all cases of token requests are supported, whereas the document mandates
the use of a subject_token parameter which restricts the scope to impersonation and delegation.

   "subject_token

I don't see a discrepancy between the content of the abstract and the content of the document.
What text or changes would you suggest in the 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 when a specific parameter
is required to identify the party on behalf of whom the request is being made".
However, please read the other comments, since I am not sure that this change will be sufficient.

2. The text states on page 4:
   "The scope of this specification is limited to the definition of a
   basic request and response protocol for an STS-style token exchange
   utilizing OAuth 2.0.  Although a few new JWT claims are defined that
   enable delegation semantics to be expressed, the specific syntax,
   semantics and security characteristics of the tokens themselves (both
   those presented to the AS and those obtained by the client) are
   explicitly out of scope and no requirements are placed on the trust
   model in which an implementation might be deployed".
These statements are contradictory. One parameter of the request is mandatory (i.e. subject_token)
but there is no indication of the kind of treatment which should be done with this parameter so that
it will be taken into consideration one way or another in the token that will be issued.

This document by itself would be insufficient to allow any kind of interoperability.
Conformance to this document would not mean anything.

The token exchange framework promotes interoperability in the form of common patterns and parameters that can be supported in libraries, products, and services. It facilitates deployments like this one https://help.salesforce.com/articleView?id=remoteaccess_oauth_asset_token_flow.htm or this one https://developer.box.com/docs/getting-started-with-new-box-view, for example.

This is not an adequate response to my comment. Text is currently missing to explain
what kind of treatment should be done with this parameter.
 What should the STS do with this parameter when it receives it ?
 How, this parameter should be processed so that it can be placed in a security token ?
 Is there a relationship (if any) between the "subject_token" and the "cid" (Client Identifier)
 that will be placed in the security token ?
 Why shall a security_token be used instead of simply an identifier of the OAuth 2.0 client
 that requested the token ?
 The current draft cannot be understood.

   "subject_token

It is understood that one implementation is already using this parameter to place in it a security token.
Since this parameter is indicated as REQUIRED, it is not understandable why a security token shall necessarily be used.
There are other means for the STS to identify the "party on behalf of whom the request is being made".

Please add a rational.

I don't understand what kind of rational you are looking for here. Can you suggest some specific text for the document that would address the concern you have?

In order to identify "the party on behalf of whom the request is being made", there is no need to use a security token.
The text does not explain the benefits, if any, of using a security token.
It does not explain either the drawbacks, i.e. the complexity for using it, in particular, how a relying party can verify
that the security token is protected by the right key.
What kind of trust relationships would need to be pre-established is not explained.
I believe that using a security token to represent the identity of the party on behalf of whom the request is being made
adds an extra level of complexity and for that reason a security token should NOT be used.
If you believe that it should, then you have to explain the trust relationships, the benefits and the way to handle this parameter
as it is currently not the case.

In addition, what the STS will do, can do or should do with this parameter is left undefined.

   "subject_token

This sentence is quite hard to understand since the specific syntax, semantics and security characteristics of the tokens themselves
are explicitly out of scope. The key point is what the STS should do with this parameter: this is left undefined.

I don't view the sentence as difficult to understand.  Maybe that's because I wrote it?  But it is true that typically it is the case that the subject of the inbound token will be the subject of the issued token. I don't know how else to say it. Please offer suggested text, if you believe there's a way to say it that is easier to understand.

Could we defined this parameter in the following way ?
subject_token
      REQUIRED.  An identifier of the party on behalf of whom the request is being made (...)
                            This identifier will be copied and pasted into the security token issued in response to this request
                            to designate the claimed holder of the issued security token designated as the "cid" (Client Identifier) claim in RFC 6749.

5. The text states:
   " (...) Additional

A token might well be cryptographically secure random sequence of characters that reference data that can be looked up by the appropriate parties. Or a token might be an AEAD symmetrically encrypted JWT. So no, tokens are not always signed.

Could we rephrase in the following way?
   " (...) Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved,
     such as how integrity protection of the tokens shall be done and if proof-of-possession style tokens will be required or issued;

Thanks.

   resource

and

   audience

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual
or entity has accessed which target service and may keep a log of that activity. It would be in a position to act as Big Brother.
This should be clearly indicated in a section that is currently missing : "7. Privacy Considerations". See a text proposal hereafter.

However, there is indeed the need to restrict the use of tokens to specific targets. The key point is that the target service
must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to
the target service and that challenge may then be placed into a specific filed of the token. The target service may then verify
that the value included in the token is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control should be added.
This parameter would be called a target_id (tid). It would solve the Big Brother case.

That is both beyond the scope of this document and potentiality applicable to a broader context of use. I'd suggest you write an individual draft for the concept, if you want to pursue it.

This topic has been addressed twice by two presentations on July the 13 th at the end of the first day of the OAuth workshop in Zürich.
During this meeting, there have been different proposals to solve the issue. I also said that other possibilities were possible.
The fact is that currently no technique has been agreed to solve the issue.
I see two options:
a)     freeze this document and wait until a technique can be agreed within the WG and defined in another RFC,
so that  we can reference it and then after continue the work on this document
b)     don't wait, but mention that currently no parameter has been defined to address the issue.
My preference would be for option a)
What would be your preference ?
If we take option b), then take a look at a new text proposal for the comment numbered 10.

   o  Claim Name: "scp"

Since the "strings are defined by the authorization servers", what a scope may mean is subject to multiple interpretations.
The current definition of scp is insufficient to allow any kind of interoperability, now or in the future.

Scoping the token restricts what the token can be used for which limits the impact of a compromised or misused token. The scope values are interpreted by the parties involved just as with regular OAuth.
This is not an adequate response to my comment.
You say that "scope values are interpreted by the parties involved just as with regular OAuth".
I suggest the following text as a full replacement of the quoted text:
Both delegation and impersonation introduce unique security issues.  The potential for abuse is a concern.
The use of the "scp" claim allows to restrict the contexts in which the delegated rights can be exercised.

Strings in the "scp" claim are defined by the authorization servers. If the client gets some knowledge
on how these strings will be handled both by a resource server and by an authorization server, then the use
of the "scp" claim can be used to mitigate potential for such abuse. However, at the time of the issuance of this RFC,
techniques for applying such restrictions are not defined in other RFCs.
In addition, users may collude and one user might be willing to allow another user to make use of a security token that it has obtained.
This is not a concern in the context of a delegation scheme, but may be a serious concern in some other contexts. Whatever kind
of cryptography is being used, there is no way to stop collusion between users, unless some secure hardware is required to be used
by a security token requester in order to obtain a security token. In other words, a software-only implementation is unable to prevent
collusion between users. A hardware solution simply protecting some secret key or some private key will also be ineffective, since
one user would be able to perform all the cryptographic computations that the other user needs.
Note: People that were present on July the 13 th on the first day of the OAuth workshop in Zürich may understand better what I mean.
The text and the slides of this workshop should be publicly available shortly.

9. This document is currently targeted to become a Standards Track document.

It is not believed that currently it is possible to construct two independent interoperating implementations
looking at this document only. Unless more guidance is provided, this document should be targeted to "Experimental".

I completely disagree. And would also note that the the document's intended status has been stable and unquestioned by this WG for several years.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.

(...)

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.

One of the goals of this document is to define a new parameter called "subject_token".

In order to use it, we need to say how the client, the AS and the RP shall handle it.
The current text is insufficient to know how to handle it.

Unless additional information is provided, this document should be targeted to "Experimental".

I will add a privacy considerations with mention of being able to track the target systems intended to be accessed by the party requesting a token.

It does not address my concern. Hereafter is a new text proposal to address my concern, ... if we follow option b) as mentioned beforehand.:

   The use of the resource or of the audience parameter allows the STS to know which target servers are being accessed
   by any party making a token request.  Any STS will then be able to log token requests. This is not a problem as long as
   the resource owner and the target server are collocated, but this document is not restricted to this case.

   For the other cases, if either the resource parameter or the audience parameter is being used, the STS will be in position
   to act as Big Brother. When privacy is a concern, the use of the resource parameter and of the audience parameter is deprecated
   and another parameter should be used to restrict the target servers that can use the security token. At the time of the issuance
   of this document, such a parameter was not yet defined in another RFC.

   RFC7662 defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata
   for a given token that was presented to them by an OAuth 2.0 client.

   The use of this protocol raises some privacy concerns, since the STS is then able to identify the clients accessing the introspection endpoint.
   This concern will remain even when the resource parameter or the audience parameter will not be used. Such parameters might be in the future
   replaced by another means to restrict the use of the security tokens to specific resource servers, but a call back to the authorization server would
   ruin the benefits of the use of this alternative means.

Denis

Denis
All,

Please, review the document and provide feedback on any issues you see with the document.

Regards,
 Rifaat and Hannes

OAuth mailing list

[email-masked]<mailto:[email-masked]>

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

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.