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

[Denis <[e-mail]>]

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.


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.


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.

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.


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.


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.


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.


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.


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


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.

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