Subject: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

From: Josh Mandel <[email-masked]>
Date: Tue, 3 Mar 2015 09:27:31 -0800

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 15 Mar 2015 18:18:13 +0100

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:
>
> *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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Sun, 15 Mar 2015 14:34:40 -0300

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 <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-masked]> 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 <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 <http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture> and further drafts on this topic.
> 
> kind regards,
> Torsten.
> 
>> 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 <https://auth-server/authorize>?
>> response_type=code&
>> client_id=123&
>> state=456&
>> scope=read-all&
>> redirect_uri=https://app-server/after-auth& <https://app-server/after-auth&>
>> resource_server_that_told_me_to_authorize_here=https://attacker.com <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 <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
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 16 Mar 2015 07:43:42 -0600

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-masked]> 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.
>
> 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
> <https://attacker.com/>*
> it is useful anytime there's a discovery process by which apps learn about
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 16 Mar 2015 18:40:04 +0100

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-masked]>:
> 
> 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-masked]> 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. 
>> 
>>> 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
>>> 
>>>> 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.
>>>> 
>>>>> resource_server_that_told_me_to_authorize_here=https://attacker.com
>>>>> 
>>>>> 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.)
>>>>>

---

From: Josh Mandel <[email-masked]>
Date: Mon, 16 Mar 2015 10:47:42 -0700

Hi Torsten,

You're absolutely correct. The implementation we're contemplating for SMART
Platforms does indeed derive the "aud" parameter from the actual URL that
the client used to communicate with the RS. Very briefly, the flow is:

1. Electronic Health Record system tells an app to launch, passing the app
its RS endpoint as an issuer (iss) URL parameter.
2. App queries the RS's issuer URL to learn what AS to talk to
3. App contacts AS's authorize endpoint, passing an "aud" param that was
the same as the issuer from step 1.
4. After obtaining a token, app talks to the RS using that token.

  -Josh

On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt <
[email-masked]> 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-masked]
> >:
>
>> Resource Server"), RFC6819 describes a threat where a counterfeit resource
>> server tricks a client into obtaining and sharing an access token from a
>> at
>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml

---

From: Phil Hunt <[email-masked]>
Date: Mon, 16 Mar 2015 10:59:07 -0700

Josh,

I’m not sure this helps. It seems to me, a phishing link could tell your app to launch and pass in any RS value could it not?

Phil

@independentid
www.independentid.com
[email-masked]

> On Mar 16, 2015, at 10:47 AM, Josh Mandel <[email-masked]> wrote:
> 
> Hi Torsten,
> 
> You're absolutely correct. The implementation we're contemplating for SMART Platforms does indeed derive the "aud" parameter from the actual URL that the client used to communicate with the RS. Very briefly, the flow is:
> 
> 1. Electronic Health Record system tells an app to launch, passing the app its RS endpoint as an issuer (iss) URL parameter.
> 3. App contacts AS's authorize endpoint, passing an "aud" param that was the same as the issuer from step 1.
> On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Am 16.03.2015 um 17:40 schrieb Dixie Baker <[email-masked] <mailto:[email-masked]>>:
> 
>> Office (Redondo Beach, CA):  310-791-9671 <tel:310-791-9671>
>> Mobile:  310-279-2579 <tel:310-279-2579>
>> On Mar 16, 2015, at 6:43 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi Josh,
>>>>

---

From: Josh Mandel <[email-masked]>
Date: Mon, 16 Mar 2015 11:12:56 -0700

Hi Phil,

It might help me if you spelled out the phishing scenario you have in mind.
The key threat we're attempting to mitigate against with an "aud" param is:

1. Phishing link tells app to launch against RS at https://attacker.com
2. App queries https://attacker.com/metadata (this is a healthcare API
called FHIR, which exposes server metadata) to discover which authorization
server to talk to. Attacker lies and tells app to authorize at "
https://my-real-hospital.com/authorize".
3. App attempts to authorize against "
https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com
"
4. The hospital's authorization server rejects the authorization request
because https://attacker.com is not a legitimate resource server.

Now you may be describing a different attacker where in step #2 the
attacker tells the app to authorize against "https://attacker.com/authorize",
and this page asks a user to sign in with her hospital credentials. That's
indeed a phishing attack that we need separate mitigation against. Happy to
think through other mitigations on this front, but it's a separate issue
than what I was trying to address with this thread. (Today our primary
mitigation for this kind of phishing threat, where attacker.com asks the
user to enter her EHR credentials, is user training.)

  -J

On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <[email-masked]> wrote:

> Josh,
>
> I'm not sure this helps. It seems to me, a phishing link could tell your
> app to launch and pass in any RS value could it not?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
> You're absolutely correct. The implementation we're contemplating for
> SMART Platforms does indeed derive the "aud" parameter from the actual URL
> that the client used to communicate with the RS. Very briefly, the flow is:
>
>>> 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.
>>>
>>> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and
>>> further drafts on this topic.
>>>
>>> kind regards,
>>> Torsten.
>>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 16 Mar 2015 11:16:44 -0700

Josh,

I was curious how you secure the first step.  If your client app is started by invoking a custom URL, what’s to stop the attacker using that and passing in https://attacker.com as the desired RS and audience?

Phil

@independentid
www.independentid.com
[email-masked]

> On Mar 16, 2015, at 11:12 AM, Josh Mandel <[email-masked]> wrote:
> 
> Hi Phil,
> 
> It might help me if you spelled out the phishing scenario you have in mind. The key threat we're attempting to mitigate against with an "aud" param is:
> 
> 1. Phishing link tells app to launch against RS at https://attacker.com <https://attacker.com/>
> 2. App queries https://attacker.com/metadata <https://attacker.com/metadata> (this is a healthcare API called FHIR, which exposes server metadata) to discover which authorization server to talk to. Attacker lies and tells app to authorize at "https://my-real-hospital.com/authorize <https://my-real-hospital.com/authorize>".
> 3. App attempts to authorize against "https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com <https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com>"
> 4. The hospital's authorization server rejects the authorization request because https://attacker.com <https://attacker.com/> is not a legitimate resource server.
> 
> Now you may be describing a different attacker where in step #2 the attacker tells the app to authorize against "https://attacker.com/authorize <https://attacker.com/authorize>", and this page asks a user to sign in with her hospital credentials. That's indeed a phishing attack that we need separate mitigation against. Happy to think through other mitigations on this front, but it's a separate issue than what I was trying to address with this thread. (Today our primary mitigation for this kind of phishing threat, where attacker.com <http://attacker.com/> asks the user to enter her EHR credentials, is user training.)
> 
>   -J
> 
> On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Josh,
> 
> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> 
>> On Mar 16, 2015, at 10:47 AM, Josh Mandel <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Torsten,
>>

---

From: Josh Mandel <[email-masked]>
Date: Mon, 16 Mar 2015 11:26:55 -0700

Hi Phil,

I was curious how you secure the first step.  If your client app is started
> by invoking a custom URL, what's to stop the attacker using that and
> passing in https://attacker.com as the desired RS and audience?

An attacker can do just as you've said -- but you didn't say which AS is
involved. The goal is that:

1. If the attacker.com RS asks the app to authorize with a *legitimate* AS,
that AS will reject the request upon seeing the "aud=https://attacker.com"
parameter in the request. This was the main threat I wanted to address with
this thread.

2. If the attacker.com RS asks the app to authorize against a *phony* AS,
then the end-user is looking at a "classic" phishing attack where the
browser is open to "https://attacker.com" and displaying a web page that
says "please enter your hospital credentials here". Here, the key
mitigation is training end-users not to enter their electronic health
record credentials into any site other than the legitimate EHR's
authorization server.

Again, if you have stronger ideas about how to mitigate #2 we'd love to
discuss. But the reason I started this thread was to address #1. One
alternative we recognzie is just to ask each client to maintain an explicit
whitelist of RS's that it will talk to. We're happy to have this as an
option, but 1) this puts a burden on the client, and a client can get it
wrong, and 2) we wanted to describe a protocol that allows more dynamic
connections. It's certainly a trade-off.

  -Josh

On Mon, Mar 16, 2015 at 11:16 AM, Phil Hunt <[email-masked]> wrote:

> Josh,
>
> I was curious how you secure the first step.  If your client app is
> started by invoking a custom URL, what's to stop the attacker using that
> and passing in https://attacker.com as the desired RS and audience?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
> It might help me if you spelled out the phishing scenario you have in
> mind. The key threat we're attempting to mitigate against with an "aud"
> param is:
>
> attacker tells the app to authorize against "
> https://attacker.com/authorize", and this page asks a user to sign in
> with her hospital credentials. That's indeed a phishing attack that we need
> separate mitigation against. Happy to think through other mitigations on
> this front, but it's a separate issue than what I was trying to address
> with this thread. (Today our primary mitigation for this kind of phishing
> threat, where attacker.com asks the user to enter her EHR credentials, is
> user training.)
>
>   -J
>
>> 1. Electronic Health Record system tells an app to launch, passing the
>> app its RS endpoint as an issuer (iss) URL parameter.
>>>>  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

---

From: John Bradley <[email-masked]>
Date: Mon, 16 Mar 2015 15:39:25 -0300

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-masked]> wrote:
>

---

From: Dixie Baker <[email-masked]>
Date: Mon, 16 Mar 2015 19:27:19 -0400

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

On Mar 16, 2015, at 11:39 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

kind regards,
Torsten.

Am 16.03.2015 um 17:40 schrieb Dixie Baker <[email-masked]<mailto:[email-masked]>>:

-Dixie

Dixie B. Baker, Ph.D.
Senior Partner

On Mar 16, 2015, at 6:43 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <[email-masked]<mailto:[email-masked]>> 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

John B.

On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Josh,

kind regards,
Torsten.

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<https://attacker.com/>

Best,

  Josh

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Tue, 17 Mar 2015 08:30:43 -0700

Providing an “aud” doesn’t really secure the use of the token by the client at the RS. It really only helps the RS to know “is this token for me?”  If the RS is bad, it doesn’t care because it knows it plans to use the “acquired” token with the legit RS anyway.

That said, by having the client provide the “aud” to the AS, the AS can check if the resource server makes sense for the scope requested.

In RFC6819, we were getting at having some kind binding model that associates the client to the correct RS as part of the token. For example, some form of proof-of-posession (see oauth-pop-architecture) that enables mutual authentication of both client and resource server.  E.g. a token might be encrypted so that only the approved RS can decrypt it. 

Phil

@independentid
www.independentid.com
[email-masked]

> On Mar 16, 2015, at 4:27 PM, Dixie Baker <[email-masked]> wrote:
> 
> On Mar 16, 2015, at 11:39 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 12:49:33 -0300

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-masked]> wrote:
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Mar 2015 19:10:43 +0000 (UTC)

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-masked]> wrote:

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-masked]> wrote:

kind regards,Torsten.

 
Dixie B. Baker, Ph.D.
Senior Partner

 

 kind regards,
 Torsten.

  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

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 16:40:55 -0300

People have been overloading scope names to create implicit audience.   

The problem is that clients need to know via some magic method that you need to ask for scope "purple" to get write access to RS 2.

Having an explicit "aud" parameter gives clients a way to communicate to the AS what RS they are asking for a token for. 

the security issue is that if a client discovers a API out via some out of band mechanism the OAuth error code can tell the client go to AS X and ask for Scope Y.  

Unfortunately without POP tokens or at-least passing the URI of the RS to the AS via "aud", a bad RS could get a legitimate client to give it a token that can be replayed at a legitimate RS.

This was one of the issues that Eran Hammer-Lahav was particularly concerned about.  

I think I proposed a "aud" parameter to the token endpoint back then as a alternative to requiring HMAC tokens, but that got lost in the confusion at the time.

At that time though people were not yet thinking about interoperable OAuth API,  only relatively tightly bound clients that were preconfigured for the API endpoints they were using.

In Health and other places we are starting to see standard clients that discover API endpoints and configure themselves based on a users Identity to use a arbitrary OAuth AS, moving into federation of AT.

That is one of the reasons POP will be important, as it prevents RS from misusing federated tokens by presenting them at other RS.

The simplest thing to do is have the client say what RS it is trying to access explicitly (The "aud" parameter), and including an audience in the AT.  to protect against malicious RS.

PoP is the step up that also protects against tokens being intercepted and replayed by another client.

John B.

> On Mar 17, 2015, at 4:10 PM, Bill Mills <[email-masked]> wrote:
> 
>> On Mar 16, 2015, at 8:27 PM, Dixie Baker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Mar 2015 20:39:44 +0000 (UTC)

I don't think it's "overloading scope names" to use them that way.  The aud value(s) could as easily be carried in scope as anywhere.  Nothing says a scope can't be "https://foo.com", and that Foo.com requires that scope to be present for a token to be accepted.  I would not make it foo.com-read-mail for example.
If it's more convenient to put it in aud I can accept that, but it's the same functionality and can be implemented in scopes now. 

     On Tuesday, March 17, 2015 12:41 PM, John Bradley <[email-masked]> wrote:

Dixie B. Baker, Ph.D.
Senior Partner

 
Dixie B. Baker, Ph.D.
Senior Partner

 

 kind regards,
 Torsten.

  Hi All,

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 17:53:53 -0300

Yes but it is custom.  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS.

The client then potentially needs to understand the custom structures scopes of every AS it might deal with.

I think that would lead to lots of problems trying to make that a pattern long term.   At teh moment yes you can do it with a scope as long as the client and AS both understand what is going on.

We added "aud" as a separate parameter for PoP as the token format for different RS might be different as well as the symmetric  pop keys needing to be encrypted with different keys.
Yes we could have invented a special scope to carry the audience but a separate parameter was much cleaner.

I know some people have started using "aud" as a way to communicate the resource when a scope applies to multiple RS but they may take different token formats JWT vs opaque etc.

Brian commented that the "aud" parameter may be useful beyond PoP so we might want to think about documenting it in it's own mini spec, if I understood him correctly.

I think that may not be a bad idea as we are also planning on using it in NAPPS.

John B.

> On Mar 17, 2015, at 5:39 PM, Bill Mills <[email-masked]> wrote:
> 
>> On Mar 17, 2015, at 4:10 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tuesday, March 17, 2015 8:50 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Mar 2015 21:00:17 +0000 (UTC)

"Yes but it is custom.  People are inventing structured scopes like "aud:https://foo.com", and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS."
This isn't solved by "aud", it is solved by OAuth 1.0a though....  

     On Tuesday, March 17, 2015 1:54 PM, John Bradley <[email-masked]> wrote:

We added "aud" as a separate parameter for PoP as the token format for different RS might be different as well as the symmetric  pop keys needing to be encrypted with different keys.Yes we could have invented a special scope to carry the audience but a separate parameter was much cleaner.
I know some people have started using "aud" as a way to communicate the resource when a scope applies to multiple RS but they may take different token formats JWT vs opaque etc.
Brian commented that the "aud" parameter may be useful beyond PoP so we might want to think about documenting it in it's own mini spec, if I understood him correctly.
I think that may not be a bad idea as we are also planning on using it in NAPPS.
John B.

Dixie B. Baker, Ph.D.
Senior Partner

 
Dixie B. Baker, Ph.D.
Senior Partner

 

 kind regards,
 Torsten.

  Hi All,

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 18:11:56 -0300

Or by OAuth 2 PoP.    

> On Mar 17, 2015, at 6:00 PM, Bill Mills <[email-masked]> wrote:
> 
> "Yes but it is custom.  People are inventing structured scopes like "aud:https://foo.com <http://foo.com/>", and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS."
> 
> Yes but it is custom.  People are inventing structured scopes like "aud:https://foo.com <http://foo.com/>", and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS.
> 
>> On Mar 17, 2015, at 5:39 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> I don't think it's "overloading scope names" to use them that way.  The aud value(s) could as easily be carried in scope as anywhere.  Nothing says a scope can't be "https://foo.com <https://foo.com/>", and that Foo.com <http://foo.com/> requires that scope to be present for a token to be accepted.  I would not make it foo.com <http://foo.com/>-read-mail for example.
>> 
>> On Tuesday, March 17, 2015 12:41 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Mar 2015 21:14:59 +0000 (UTC)

Yes.  There's still the open question of whether/how PoP tokens can be proxied internally within a site though.  If they can be proxied then it goes back to unsolved. 

     On Tuesday, March 17, 2015 2:12 PM, John Bradley <[email-masked]> wrote:

 Or by OAuth 2 PoP.    

Dixie B. Baker, Ph.D.
Senior Partner

 
Dixie B. Baker, Ph.D.
Senior Partner

 

 kind regards,
 Torsten.

  Hi All,

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 18:26:36 -0300

PoP tokens need to be presented with a proof the presenter knows the secret.  That is the same principal as in OAuth 1.0a with needing to show knowledge of the "token secret".

I don't know what you mean by proxies internally.   If the RS needs another token to access a resource it should use the assertion flow and authenticate itself to get another token based on the access token.
Passing around a PoP token as a bearer token is insecure/bad.

In OAuth 1.0a because of the tight relationship between the "Service Provider" and the "Protected Resource" people would be less likely to try it but because the protected resource knows the "token secret" it could still do lots of unexpected bad things.

Proxying access tokens is not something RS should do, they need to be exchanged at a AS for a new AT with the correct rights and optionally binding it to a new PoP key.

John B.

On Mar 17, 2015, at 6:14 PM, Bill Mills <[email-masked]> wrote:
>> On Mar 17, 2015, at 6:00 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tuesday, March 17, 2015 1:54 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Mar 2015 21:32:24 +0000 (UTC)

In practice one of the drawbacks of the Oauth 1.0a tokens was that they were not proxyable and so a connection to the edge then means you have to unwrap that and make a new internal token to be usedwhich isn't as good as the actual user credential.  

     On Tuesday, March 17, 2015 2:26 PM, John Bradley <[email-masked]> wrote:

 PoP tokens need to be presented with a proof the presenter knows the secret.  That is the same principal as in OAuth 1.0a with needing to show knowledge of the "token secret".
I don't know what you mean by proxies internally.   If the RS needs another token to access a resource it should use the assertion flow and authenticate itself to get another token based on the access token.Passing around a PoP token as a bearer token is insecure/bad.
In OAuth 1.0a because of the tight relationship between the "Service Provider" and the "Protected Resource" people would be less likely to try it but because the protected resource knows the "token secret" it could still do lots of unexpected bad things.
Proxying access tokens is not something RS should do, they need to be exchanged at a AS for a new AT with the correct rights and optionally binding it to a new PoP key.
John B.

 Or by OAuth 2 PoP.    

Dixie B. Baker, Ph.D.
Senior Partner

 
Dixie B. Baker, Ph.D.
Senior Partner

 

 kind regards,
 Torsten.

  Hi All,

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 18:40:42 -0300

This is fun:)

I might ask what part of a OAuth 1.0a token is the user credential.   That is a slippery idea in itself.  The token is a reference to some notion of identity (in some cases) that needs to be dereferenced anyway.

So in the same way a POP JWT access token in OAuth 2 that may indeed contain claims about the subject would need to be exchanged at a AS for a new token containing claims about the subject and the new presenter, or depending on the security model it could be included directly in a new self signed AT.

From a enterprise policy point of view having a REST like STS functionality is I think the right long term answer.

John B.

> On Mar 17, 2015, at 6:32 PM, Bill Mills <[email-masked]> wrote:
> 
> On Mar 17, 2015, at 6:14 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tuesday, March 17, 2015 2:12 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Or by OAuth 2 PoP.    
>> 
>>

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Mar 2015 23:01:42 +0000 (UTC)

STS? 

     On Tuesday, March 17, 2015 2:40 PM, John Bradley <[email-masked]> wrote:

 This is fun:)
John B.

 Or by OAuth 2 PoP.    

Dixie B. Baker, Ph.D.
Senior Partner

 
Dixie B. Baker, Ph.D.
Senior Partner

 

 kind regards,
 Torsten.

  Hi All,

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Mar 2015 21:28:26 -0300

Security Token Service (STS)   Sorry it is WS-* speak http://en.wikipedia.org/wiki/Security_token_service

You can emulate some of it with the assertions extension. 

The WG has a document as a starting position for a more general approach.
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01

Brian Campbell and I also documented our take on it for discussion.
https://tools.ietf.org/html/draft-campbell-oauth-sts-01

At the moment they don't really take into account issuing PoP tokens in exchange but I expect that would be added as a WG document progresses.

It is on the WG to do list.

John B.

> On Mar 17, 2015, at 8:01 PM, Bill Mills <[email-masked]> wrote:
> 
> STS?
> 
> 
> 
>> On Mar 17, 2015, at 6:32 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tuesday, March 17, 2015 2:26 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Mar 2015 21:31:22 -0400

I also drafted a more generalized mechanism (that was much less WS-*-y) for doing an arbitrary token swap:

https://tools.ietf.org/html/draft-richer-oauth-chain-00 <https://tools.ietf.org/html/draft-richer-oauth-chain-00>

Phil had pretty much the same idea separately.

Personally, I still think that the token-exchange draft needs to use a syntactical mechanism like this instead of something so strictly tied to the assertion formats.

 — Justin

> On Mar 17, 2015, at 8:28 PM, John Bradley <[email-masked]> wrote:
> 
> Security Token Service (STS)   Sorry it is WS-* speak http://en.wikipedia.org/wiki/Security_token_service <http://en.wikipedia.org/wiki/Security_token_service>
> 
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01>
> 
> 
> https://tools.ietf.org/html/draft-campbell-oauth-sts-01 <https://tools.ietf.org/html/draft-campbell-oauth-sts-01>
> 
>> On Mar 17, 2015, at 8:01 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> STS?
>> 
>> 
>> 
>> On Tuesday, March 17, 2015 2:40 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> This is fun:)
>>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 23 Mar 2015 14:44:12 +0900

Sorry to come in so late, and I admit that I have just skimmed the thread,
but if the concern was the client C,  presenting a legitimate AT (ATr),
which was issued to for the client to access to a resource R, to an
attacker's resource S, that can be used for S to access R, then would not
having the aud in the AT and have the client verify the peer would thwart
the attack in the first place?

If the request to AT starts with S and the AS issues ATs, then it would not
be useful for anything but to access S, so it is not super useful to access
other resource - though it can be used to trick the user to do all sort of
other stuff.

If the concern was that after the token has been obtained by the attacker,
how to prevent it from being used, then notion of named/registered token
(in contrast with bearer token) is needed. PoP is one way of doing it.

Am I missing something?

Nat

2015-03-18 10:31 GMT+09:00 Justin Richer <[email-masked]>:

> https://tools.ietf.org/html/draft-richer-oauth-chain-00
>
> Personally, I still think that the token-exchange draft needs to use a
> syntactical mechanism like this instead of something so strictly tied to
> the assertion formats.
>
>  — Justin
>
> Security Token Service (STS)   Sorry it is WS-* speak
> http://en.wikipedia.org/wiki/Security_token_service
>
> At the moment they don't really take into account issuing PoP tokens in
> exchange but I expect that would be added as a WG document progresses.
>
> I might ask what part of a OAuth 1.0a token is the user credential.   That
> is a slippery idea in itself.  The token is a reference to some notion of
> identity (in some cases) that needs to be dereferenced anyway.
>
> So in the same way a POP JWT access token in OAuth 2 that may indeed
> contain claims about the subject would need to be exchanged at a AS for a
> new token containing claims about the subject and the new presenter, or
> depending on the security model it could be included directly in a new self
> signed AT.
>
> From a enterprise policy point of view having a REST like STS
> functionality is I think the right long term answer.
>
> John B.
>
>
>
> In practice one of the drawbacks of the Oauth 1.0a tokens was that they
> were not proxyable and so a connection to the edge then means you have to
> unwrap that and make a new internal token to be usedwhich isn't as good as
> the actual user credential.
>
>
>
> PoP tokens need to be presented with a proof the presenter knows the
> secret.  That is the same principal as in OAuth 1.0a with needing to show
> knowledge of the "token secret".
>
> I don't know what you mean by proxies internally.   If the RS needs
> another token to access a resource it should use the assertion flow and
> authenticate itself to get another token based on the access token.
> In OAuth 1.0a because of the tight relationship between the "Service
> Provider" and the "Protected Resource" people would be less likely to try
> it but because the protected resource knows the "token secret" it could
> still do lots of unexpected bad things.
>
> Proxying access tokens is not something RS should do, they need to be
> exchanged at a AS for a new AT with the correct rights and optionally
> binding it to a new PoP key.
>
> John B.
>
>
>
> Yes.  There's still the open question of whether/how PoP tokens can be
> proxied internally within a site though.  If they can be proxied then it
> goes back to unsolved.
>
>
>
> "Yes but it is custom.  People are inventing structured scopes like
> "aud:https://foo.com", and that potentially doesn't solve the security
> issue if a client just passes on the scopes it receives in the error
> response, the bad RS just adds a scope for the good RS."
>
> Yes but it is custom.  People are inventing structured scopes like
> "aud:https://foo.com", and that potentially doesn't solve the security
> issue if a client just passes on the scopes it receives in the error
> response, the bad RS just adds a scope for the good RS.
>
> I think that would lead to lots of problems trying to make that a pattern
> long term.   At teh moment yes you can do it with a scope as long as the
> client and AS both understand what is going on.
>
>
> We added "aud" as a separate parameter for PoP as the token format for
> different RS might be different as well as the symmetric  pop keys needing
> to be encrypted with different keys.
> I know some people have started using "aud" as a way to communicate the
> resource when a scope applies to multiple RS but they may take different
> token formats JWT vs opaque etc.
>
> Brian commented that the "aud" parameter may be useful beyond PoP so we
> might want to think about documenting it in it's own mini spec, if I
> understood him correctly.
>
> I don't think it's "overloading scope names" to use them that way.  The
> aud value(s) could as easily be carried in scope as anywhere.  Nothing says
> a scope can't be "https://foo.com", and that Foo.com <http://foo.com/>
> requires that scope to be present for a token to be accepted.  I would not
> make it foo.com-read-mail for example.
>
> If it's more convenient to put it in aud I can accept that, but it's the
> same functionality and can be implemented in scopes now.
>
>
>
> The problem is that clients need to know via some magic method that you
> need to ask for scope "purple" to get write access to RS 2.
>
> Having an explicit "aud" parameter gives clients a way to communicate to
> the AS what RS they are asking for a token for.
>
> the security issue is that if a client discovers a API out via some out of
> band mechanism the OAuth error code can tell the client go to AS X and ask
> for Scope Y.
>
> Unfortunately without POP tokens or at-least passing the URI of the RS to
> the AS via "aud", a bad RS could get a legitimate client to give it a token
> that can be replayed at a legitimate RS.
>
> I think I proposed a "aud" parameter to the token endpoint back then as a
> alternative to requiring HMAC tokens, but that got lost in the confusion at
> the time.
>
> At that time though people were not yet thinking about interoperable OAuth
> API,  only relatively tightly bound clients that were preconfigured for the
> API endpoints they were using.
>
> In Health and other places we are starting to see standard clients that
> discover API endpoints and configure themselves based on a users Identity
> to use a arbitrary OAuth AS, moving into federation of AT.
>
> That is one of the reasons POP will be important, as it prevents RS from
> misusing federated tokens by presenting them at other RS.
>
> The simplest thing to do is have the client say what RS it is trying to
> access explicitly (The "aud" parameter), and including an audience in the
> AT.  to protect against malicious RS.
>
> 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.
>
> 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
> 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
> 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.
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en