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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
