I agree with you, Brian, that incorporating the proposed changes would not
further the goals of the document. Rather, they would detract from achieving
them.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Sunday, July 16, 2017 7:46 PM
To: Denis <denis.i...@free.fr>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08
Speaking as an individual, for a number of reasons, I do not believe that any
of the additional comments or suggestions should be incorporated into the
document.
As a document editor working within the IETF processes, my aim is for the
document to reflect the (rough) consensus of this Working Group. And I don't
get the sense that there's support, let alone consensus, for any of these
changes. However, rather than relying on my interpretation of support or lack
thereof from the WG, I'll ask more explicitly - are there other WG remembers
who are in favor of working to incorporate any of these comments or suggestions?
On Sun, Jul 16, 2017 at 8:38 AM, Denis
<denis.i...@free.fr<mailto:denis.i...@free.fr>> wrote:
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
<denis.i...@free.fr<mailto:denis.i...@free.fr>> 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 that this 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
or this one 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.0 client
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) claim in 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 that we 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 token request. 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
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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
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.
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
