Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

[Nat Sakimura]

I support keeping those two in a single document.

They actually belong to a same class of problem: the problem of accepting
an input from an untrusted / un-protected source, i.e., the authorization
response.
When this vulnerability is applied to the 'state', it opens up the chance
of authorization code being stollen through a rogue token endpoint.
When it is applied to the authorization code, then it is a cut-n-paste
attack.

The reason why 'code id_token' response type is protected in OIDC is that
the authorization response is integrity protected and the origin
authenticated.

Nat


2016年2月6日(土) 23:59 John Bradley :

> I think Toresen states it well.
>
> The reason we looked at 2 again is that #1 in some of the attacks was
> being used to leak the code.
> In some of those cases the attacker had the client credentials and could
> use the directly to get access tokens.
>
> In other cases the attacker doesn’t have the client credentials, but could
> still get access to the information protected  by the API by presenting the
> code back to the client as part of a new flow, and bind it to a new account
> or if the clint is unwise and using the code for authentication,
> impersonate the user.
>
> There are certainly other ways an attacker could get code, via logs, open
> redirectors etc.
> The closest mention of this in 6819 is sec 4.4.1.13 ,  but that considered
>  two clients with two client_id.
> that was mitigated by having the client send it’s client_id with code to
> exchange it.
>
> The difference with 2 is that only one client_id is used, and that is not
> mitigated by the current counter measures in 6819.
>
> Perhaps referring to 6819 sec 4.4.1.13 is a distraction, in this case.
> We however were concerned at the time about codes leaking and being
> replayed but missed some of the ways that could happen.
>
> The two opportunities that we are leaving for attackers,  1 not knowing
> who is sending the authorization response, and not tying the authorization
> request and response to the same browser instance open a whole world of
> attacks.
>
> What we think currently is that there are two basic flaws that are being
> exploited (some attacks use one or the other and some use them together) .
>   We should probably keep the fixes separate from documents that are more
> how to guides to attack un-patched clients.
>
> Both issues are around the client being mislead or confused by an
> authorization response, in that it is coming back from the wrong place or
> in the wrong browser instance.  That is why the two mitigations probably
> belong in the same document.
>
> John B.
>
>
>
> On Feb 6, 2016, at 8:32 AM, Torsten Lodderstedt 
> wrote
>
>
> Hi Hannes,
>
> #2 is not directly described in the paper but was used to replay the
> code/token the attacker obtained via #1. In my observation, the discussion
> in Darmstadt has shown that OAuth (and its built-in mitigations) so far
> focused on preventing code/token leakage but we lake mitigation for replay
> in this particular case.
>
> #2 does not require the attacker to control the network or the victim's
> device. The attacker (using #1 or other attacks, e.g. on referrer headers
> or log files) obtains a code and injects this code into a legitimate
> OAuth/OIDC flow on its device. All she has to do is starting a authz code
> flow on the legitimate client, the particular code was issued for, and
> replace the code in the response from the AS. From the client's
> perspective, the response looks ok, since it carries the correct state
> value bound to the client in the particular user agent (since this is not a
> XSRF). But since there is no way (currently) to bind the code to a certain
> user agent, the client would accept the code and exchange it for token(s)
> on the AS. That gives the attacker access to resources of the victim and/or
> impersonates the attacker as the victim.
>
> There are several way to mitigate this issue:
> - OIDC has the "code id_token" response type, which uses nounce and c_hash
> in the id_token to bind the code to the user agent session
> - in Darmstadt we came up with the idea to utilize the state value for
> that purpose.
>
> Do we need to describe the threat and mitigation if
> draft-jones-oauth-mix-up-mitigation? I don't think so.
> We could describe the mechanisms in a different draft.
>
> I personally would prefer (and Phil already states this as well) the WG to
> work on a single draft, providing a consolidated view on all threats caused
> by the more dynamic usage of OAuth. We could also include all
> threats/mitigations/issues we have seen in the wild since RFC 6749 was
> published. This would also include stronger advice regarding XSRF
> prevention and open redirectors. I don't think we serve the community well
> be spreading those issues and mitigation over 3 or 4 drafts.
>
> best regards,
> Torsten.
>
> Am 04.02.2016 um 21:27 schrieb Hannes Tschofenig:
>
> Hi all,
>
> when I posted the call for adoption of the 'OAuth 2.0 Mix-U

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Samuel Erdtman]

Hi,

I think it is a reasonable simplification to mandate that PoP key and
(D)TLS Mode matches i.e. if the PoP keys is symmetric the (D)TLS mode would
be PSK, if the PoP key is asymmetric (D)TLS mode would be Raw Public key.

But I think there is some compelling properties of having a symmetric PoP
key and a Raw Public Key (D)TLS. In this case the Public key of the RS can
be distributed to the client in the client information (the attributes
accompanying the token) from AS and the PoP key as defined by PoP key
distribution draft. With this setup the client can authenticate the server
at connection time and then it can send its PoP token to authorization
information endpoint/resource at the RS (defined in
draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization
header) to authorize the client.

Regards
//Samuel





On Thu, Feb 4, 2016 at 10:54 AM, Ludwig Seitz  wrote:

> Hello list(s),
>
> in the process of updating our draft [1] (mainly in reaction to the
> reviewer's comments) I've come up with a question I'd like to put to the
> list (crossposting to OAuth as well, they might have considered that
> already):
>
> Assuming we are using (D)TLS to secure the connection between C and RS,
> assuming further that we are using proof-of-possession tokens [2], i.e.
> tokens linked to a key, of which the client needs to prove possession in
> order for the RS to accept the token.
>
> Do we need to support cases, where the type of key used with DTLS does not
> match the type of key in the PoP-token?
>
> Example:
>
> The client uses its raw public key as proof of possession, but the DTLS
> connection C - RS is secured with a pre-shared symmetric key.
>
> Is that a realistic use case?
>
> It would simplify the DTLS cases a lot, if I could just require the token
> and the DTLS session to use the same type of key. For starters we could use
> DTLS handshake to perform the proof-of-possession.
>
> Would there be any security issues with using the PoP key in the DTLS
> handshake?
>
> I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279
> and raw public PoP keys as client-authentication key as in
> RFC7250.
>
>
> Regards,
>
> Ludwig
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
> [2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02
>
>
> --
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
>
> Phone +46(0)70 349 9251
> http://www.sics.se
>
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Michael Richardson]

Ludwig Seitz  wrote:
> On 02/04/2016 03:31 PM, Michael Richardson wrote:
>>
>> Ludwig Seitz  wrote: > Assuming we are using (D)TLS to
>> secure the connection between C and RS, > assuming further that we are
>> using proof-of-possession tokens [2], > i.e. tokens linked to a key,
>> of which the client needs to prove possession in > order for the RS to
>> accept the token.
>>
>> > Do we need to support cases, where the type of key used with DTLS
>> does not > match the type of key in the PoP-token?
>>
>> > Example:
>>
>> > The client uses its raw public key as proof of possession, but the
>> DTLS > connection C - RS is secured with a pre-shared symmetric key.
>>
>> > Is that a realistic use case?
>>
>> Before I agree that it's unrealistic, I think it's worth going out of
>> charter scope and ask how much these two credentials were
>> created/distributed.
>>
>> I think that in this case, the pre-shared symmetric key is initialized
>> through some out-of-band (perhaps human mediated?) process, while the
>> raw public key did not need any other pre-arrangement.

> Actually even the raw public key needs to be provisioned out-of-band to
> those supposed to trust it for authentication.

First, let me say that I confused RS and RO/AS in my mind when reading before.

Starting again, I think that any PSK for authentication between C<->RS is
unrealistic.

>> So my question is then: could the out-of-band process have
>> pre-exchanged the raw public key (and the RS's key/certificate!) as
>> well?

> Short answer: Yes but only to the AS not to the client(s).

> Long answer: I am laboring under the assumption that the AS not only
> provides the OAuth token and the corresponding PoP key to the client,
> but also some information on the communication security protocols that
> the RS supports. Furthermore the AS facilitates the establishment of a
> security context between client and RS by providing things such as a
> (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode
> that the RS is going to support. Thus individual clients would not,
> a-priori, know the raw public key of a RS, but would be able to get
> that information from the AS.

That seems entirely reasonable.  Would the OAuth token not also be bound to
the Raw RSA key of C?So RS would never need to be told about C's key,
because the AS would have told it "key XYZ can access resource ABC" in the
OAuth token.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Phil Hunt (IDM)]

There is a more general problem in PaaS deployment about how RA and AS 
infrastructure discover and coordinate with each other. For the most part this 
hasn't been necessary since usually the AS and RS are controlled by the same 
admins. But in PaaS/IaaS the requirements vary widely. 

How does an RS indicate to an AS what tokens it is able to support (directly or 
indirectly via a security module). And then subsequently for the as and rs to 
let the client know?

We need to broaden discovery to cover all the scenarios so that automated and 
secure config of AS/RS/Tkn/Reg/RS entities works. 

Phil

> On Feb 8, 2016, at 07:04, John Bradley  wrote:
> 
> The RS is going to have to advertise what presentment mechanisms it supports.
> 
> We don’t have that yet.   I suspect that it might be part of OAuth Discovery. 
>  Currently that mostly cover AS discovery, but for the RS I could see doing a 
> head on the resource and getting back a link to a JSON document that would 
> contain meta-data about the RS.
> 
> The standard OAuth answer to this question is the client would get it from 
> the service documentation, but that is not really scalable.
> 
> 
>> On Feb 5, 2016, at 5:30 AM, Ludwig Seitz  wrote:
>> 
>> On 02/04/2016 05:14 PM, John Bradley wrote:
>>> In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution
>>> 
>>> The proof key is included in the access token or provided out of band.
>>> 
>>> The proof mechanism to the RS is what would determine if the key type needs 
>>> to match DTLS .
>>> If the proof is DTLS then they would need to match.
>> 
>> Thank you John, this leads me to another question (maybe I just missed it in 
>> the PoP drafts): Who decides what the proof mechanism should be? How is the 
>> proof mechanism signaled to the client (the client may support several proof 
>> mechanisms)?
>> 
>> /Ludwig
>> 
>> 
>> -- 
>> Ludwig Seitz, PhD
>> SICS Swedish ICT AB
>> Ideon Science Park
>> Building Beta 2
>> Scheelevägen 17
>> SE-223 70 Lund
>> 
>> Phone +46(0)70 349 9251
>> http://www.sics.se
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[John Bradley]

The RS is going to have to advertise what presentment mechanisms it supports.

We don’t have that yet.   I suspect that it might be part of OAuth Discovery.  
Currently that mostly cover AS discovery, but for the RS I could see doing a 
head on the resource and getting back a link to a JSON document that would 
contain meta-data about the RS.

The standard OAuth answer to this question is the client would get it from the 
service documentation, but that is not really scalable.


> On Feb 5, 2016, at 5:30 AM, Ludwig Seitz  wrote:
> 
> On 02/04/2016 05:14 PM, John Bradley wrote:
>> In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution
>> 
>> The proof key is included in the access token or provided out of band.
>> 
>> The proof mechanism to the RS is what would determine if the key type needs 
>> to match DTLS .
>> If the proof is DTLS then they would need to match.
>> 
> 
> Thank you John, this leads me to another question (maybe I just missed it in 
> the PoP drafts): Who decides what the proof mechanism should be? How is the 
> proof mechanism signaled to the client (the client may support several proof 
> mechanisms)?
> 
> /Ludwig
> 
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70 349 9251
> http://www.sics.se
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

[John Bradley]

Yes this is an example of how you could do it inside the existing specs.  

I guess you could look at it as token transformation for software statements.

This and signed state were created based on developer feedback that we tell 
them that they need to do something or that they can do something in spec 
language, but they want an example of how it can be done.

I expect may of them will look at this, and do it some other way that they 
think is better, but this gives them a start.

John B.


> On Feb 7, 2016, at 8:06 PM, Justin Richer  wrote:
> 
> There's already support for this, but just a quick reminder to the working 
> group that we already hint at this capability in RFC7951:
> 
>In some cases, authorization servers MAY choose to accept a software
>statement value directly as a client identifier in an authorization
>request, without a prior dynamic client registration having been
>performed.  The circumstances under which an authorization server
>would do so, and the specific software statement characteristics
>required in this case, are outside the scope of this specification.
> 
> (Last paragraph of section 2.3)
> 
>  -- Justin
> 
> On 2/7/2016 3:07 PM, Roland Hedberg wrote:
>> +1
>> 
>>> 6 feb 2016 kl. 19:56 skrev William Denniss  
>>> :
>>> 
>>> +1 to adopt.
>>> 
>>> I don't think we're planning to use this, but it looks useful and doesn't 
>>> harm interoperability so I support it.
>>> 
>>> On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt 
>>>   wrote:
>>> +1
>>> 
>>> 
>>> Am 04.02.2016 um 17:37 schrieb John Bradley:
>>> I support it.
>>> 
>>> I have always thought of this as informational.  It is not the only way to 
>>> do it, and has no real interoperability impact.
>>> 
>>> John B.
>>> On Feb 4, 2016, at 3:29 AM, Mike Jones  
>>>  wrote:
>>> 
>>> I support adoption of this document by the working group as either an 
>>> experimental or information specification.
>>> 
>>> -- Mike
>>> 
>>> -Original Message-
>>> From: OAuth [mailto:oauth-boun...@ietf.org ] 
>>> On Behalf Of Hannes Tschofenig
>>> Sent: Tuesday, January 19, 2016 4:05 AM
>>> To: oauth@ietf.org 
>>> Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for 
>>> OAuth 2
>>> 
>>> Hi all,
>>> 
>>> this is the call for adoption of Stateless Client Identifier for OAuth 2, 
>>> see
>>> https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02 
>>> 
>>> 
>>> Please let us know by Feb 2nd whether you accept / object to the adoption 
>>> of this document as a starting point for work in the OAuth working group.
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>> ”Everybody should be quiet near a little stream and listen."
>> >From ’Open House for Butterflies’ by Ruth Krauss
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Ludwig Seitz]

Michael,

thank you for answering, this is getting very interesting.
Comments inline.

/Ludwig


On 02/05/2016 04:26 PM, Michael Richardson wrote:


First, let me say that I confused RS and RO/AS in my mind when reading before.

Starting again, I think that any PSK for authentication between C<->RS is
unrealistic.



Actually I don't want to authenticate the client, I just want do a 
proof-of-possession for the (symmetric) key that is bound to the token. 
Wouldn't the DTLS-PSK handshake provide that proof?


Detailed scenario (skip if the above makes sense):
Client has a PoP token with a symmetric PoP key. Client wants to use 
DTLS-PSK towards the RS with the symmetric PoP key as PSK to get a.) A 
secure connection and b.) do the proof-of-possession towards the RS.




 >> So my question is then: could the out-of-band process have
 >> pre-exchanged the raw public key (and the RS's key/certificate!) as
 >> well?

 > Short answer: Yes but only to the AS not to the client(s).

 > Long answer: I am laboring under the assumption that the AS not only
 > provides the OAuth token and the corresponding PoP key to the client,
 > but also some information on the communication security protocols that
 > the RS supports. Furthermore the AS facilitates the establishment of a
 > security context between client and RS by providing things such as a
 > (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode
 > that the RS is going to support. Thus individual clients would not,
 > a-priori, know the raw public key of a RS, but would be able to get
 > that information from the AS.

That seems entirely reasonable.  Would the OAuth token not also be bound to
the Raw RSA key of C?So RS would never need to be told about C's key,
because the AS would have told it "key XYZ can access resource ABC" in the
OAuth token.

Yes if the PoP token uses a public key as PoP key. C could even generate 
an ephemeral key-pair just for this token (and the DTLS-RPK handshake).




--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth