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

[Denis <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     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./