This may have been hashed out already and I missed it, but "aud" just becomes
another kind of scope, correct?
On Tuesday, March 17, 2015 8:50 AM, John Bradley <[email protected]> wrote:
You could do that, but it is probably safer for the AS to know what RS it can
issue tokens for and refuse to issue a token for RS A to a client asking for a
token with RS X as the aud.
John B.
On Mar 16, 2015, at 8:27 PM, Dixie Baker <[email protected]> wrote:
The threat that RFC6819 4.6.4 describes is when a client obtains an AT and then
sends it to a counterfeit RS, which then uses the AT to access resources from a
legitimate RS, on the end-user's behalf.
The suggested countermeasure is a bit difficult to interpret: "Associate the
endpoint URL of the resource server the client talked to with the access token
(e.g., in an audience field) and validate the association at a legitimate
resource server. The endpoint URL validation policy may be strict (exact
match) or more relaxed (e.g., same host). This would require telling the
authorization server about the resource server endpoint URL in the
authorization process."
As I read this, the suggestion is to have the client pass the URL of the bad RS
in the request to the AS (using the audience field). The AS then would include
that RS URL in the AT. Then, when the client passes the AT to the bad RS, and
it passes it on to the good RS, the good RS will check the audience field,
compare that URL with its own, and refuse the request.
-Dixie
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): 310-791-9671
Mobile: 310-279-2579
On Mar 16, 2015, at 11:39 AM, John Bradley <[email protected]> wrote:
Brian and I were talking about "aud" used as a parameter to the token endpoint
when using a code or refresh token to indicate what RS the resulting AT will be
used at.
Sending a audience in the AT wouldn't help prevent the attack being discussed,
though it may stop other sorts of attacks if the RS can tell if a AT was issued
for it or another RS.
In PoP having the AS check that you are sending the AT to the correct RS is
less important as the AT if stolen can't be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info may
well be a problem as well.
John B.
On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <[email protected]>
wrote:
I don't think putting an aud into an AT will help to prevent counterfeit RSs
(as long as the aud is nit directly derived from the original URL used by the
client to invoke the counterfeit RS. as long as the aud is a symbolic name of
any kind, the counterfeit RS will accept ATs for the legitimate RS and just
(ab)use it.
POP on the contrary helps since the counterfeit RS, in order to send a message
to the legitimate RS, needs to produce a new digitally signed message using the
correct secret, which it doesn't know.
kind regards,Torsten.
Am 16.03.2015 um 17:40 schrieb Dixie Baker <[email protected]>:
Using the "aud" parameter makes sense to me. Good suggestion.
Authenticating the client to the RS would not address the counterfeit RS
threat.
-Dixie
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA): 310-791-9671
Mobile: 310-279-2579
On Mar 16, 2015, at 6:43 AM, Brian Campbell <[email protected]> wrote:
We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identify
the RS to whom the AT should be issued. It is useful but it's mostly about
getting format/content/etc of the AT correct for the RS rather than it is about
preventing possible AT leaks.
I do think an "aud(iance)" parameter at both token and authorization endpoints
would have utility beyond the POP work. So defining it independently might make
sense.
On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <[email protected]> wrote:
In POP key distribution we do introduce a "audiance" parameter to the
token_endpoint.
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1
It would be possible to have a small spec to define using "aud" with bearer
tokens, however that would be undefined behaviour at this point.
I don't know of any clients that would try to access a RS server and then besed
on the error response try and get a access token from the AS specified in the
error.
In POP we are trying to both protect agains that attack and more common ones
like doing a MiM to intercept the AT or the RS being hacked and leaking the
token.
Using "aud" with bearer tokens would be useful, but probably won't stop the
majority of possible AT leaks.
John B.
On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <[email protected]>
wrote:
Hi Josh,
I'm not aware of a common practice to use such a parameter. The WG is instead
heading towards authenticated requests to the resource server (see
https://tools.ietf.org/html/rfc6819#section-5.4.2).
Please take a look onto
http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts
on this topic.
kind regards,
Torsten.
Am 03.03.2015 um 18:27 schrieb Josh Mandel:
Hi All,
In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource
Server"), RFC6819 describes a threat where a counterfeit resource server tricks
a client into obtaining and sharing an access token from a legitimate
authorization server. One of the proposed mitigations involves: "telling the
authorization server about the resource server endpoint URL in the
authorization process."
In other words, this mitigation would ask the client to pass an additional
parameter when redirecting to the Authorization server's "authorize" URL,
effectively something like:
https://auth-server/authorize? response_type=code& client_id=123& state=456&
scope=read-all& redirect_uri=https://app-server/after-auth&;
resource_server_that_told_me_to_authorize_here=https://attacker.com
(And if the authorization server saw a value it didn't like in the final
parameter, it would reject the request.)
This is obviously not appropriate in every authorization scenario, but it is
useful anytime there's a discovery process by which apps learn about
authorization servers from resource servers. Since it's something of a common
need, I wanted to see if there was any common practice in how to name this
parameter, or whether it's worth registering a standard extension at
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml . (I
don't see one there now -- possibly I'm just missing it.)
If so, what should it be called? The name I used in the example above is a
bit verbose :-)
Best,
Josh
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
