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