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

[Brian Campbell <[e-mail]>]

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]> 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?




> 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_oaut
h_asset_token_flow.htm or this one https://developer.box.com/docs
/getting-started-with-new-box-view, for example.




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




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




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


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



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



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



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




>
>
>
>
Denis
>
> All,
>
> We are starting a WGLC on the Token Exchange document:
> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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.*