Re: [OAUTH-WG] draft-ietf-oauth-assertions-00

[Hannes Tschofenig <[e-mail]>]

> FYI, the Assertion ID specified in the Assertion Metamodel is used to prevent replay attacks.

There are various ways to prevent replays and having unique identifiers is one possibility. Timestamps are another one. 
In model 2 for it to work the client would have to request a new assertion from the STS every time before it presents something to the AS. 
While this is theoretically possible I doubt it will be done in practice. Consequently, there will be a certain time window for replay attacks. Depending on the application requirements that may well be fine. 

In model 1 it is very likely that one would do this. In that case, however, the security is similar (but not the same) as the HMAC based spec (when shared secrets and HMACs are used) with the only difference that the HMAC spec is far less verbose than constructing an assertion with self-constructed info. 

Ciao
Hannes

>  
>                                                             -- Mike
>  
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, October 20, 2011 12:40 PM
> To: OAuth WG
> Subject: [OAUTH-WG] draft-ietf-oauth-assertions-00
>  
> Hi all, 
> 
> at the Internet Identity Workshop this week Barry and I had a chance to meet Chuck, Mike, and Brian to talk about the content of draft-ietf-oauth-assertions-00. 
> 
> The specification provides an abstract description for two features, namely 
> a) assertion usage as client credentials, and
> b) assertion usage as authorization grants
> 
> Let me focus on (a) in this mail. 
> 
> In attempting to judge the security features I noticed that I got the impression that the description could be improved. Here is an attempt to describe the features to see whether other members have the share my understanding.  
> 
> Model 1: Self-Crafted Assertion 
> 
> In this model the client creates an assertion and signs it before sending it to the Authorization Server in a client authentication exchange. ({Assertion}Client means that the Assertion is signed with the private key of the client.)
> Of course, the authorization server has to either know the symmetric key or to be able to verify the digital signature (based on a shared trust anchor, or by trusting the public key itself).
> 
>      +--------+
>      |        | {Assertion}Client  +---------------+
>      |        |------------------->| Authorization |
>      | Client |                    |     Server    |
>      |        |<-------------------|               |
>      |        |                    +---------------+
>      +--------+
> 
> Model 2: STS issued Assertion
> 
> In this model the client obtains an assertion from another entity; we use the term STS here. 
> STS, as the issuer of the assertion, signs it. The client, on the other hand, only passes the assertion forward to the authorization server. 
>                  +--------+
>                  |        |
>                ,>| Secure |
>               /  |  Token |
>             ,' , | Server |
>            /  /  | (STS)  |
>          ,'  /   +--------+
>         /  ,'
>       ,'  /  {Assertion}STS
>      /   v
>    +--------+
>    |        |  {Assertion}STS    +---------------+
>    |        |------------------->| Authorization |
>    | Client |                    |     Server    |
>    |        |<-------------------|               |
>    |        |                    +---------------+
>    +--------+
> 
> Model 3: Co-Signed Assertion
> 
> In this third model STS creates and signs an assertion before it sends it to the client. The client instead of just passing it on to the AS it also uses a secret to sign it. By doing this the client demonstrates that it knows a secret (that is potentially associated with the assertion itself). 
> 
>                  +--------+
>                  |        |
>                ,>| Secure |
>               /  |  Token |
>             ,' , | Server |
>            /  /  | (STS)  |
>          ,'  /   +--------+
>         /  ,'
>       ,'  /  {Assertion}STS
>      /   v
>    +--------+
>    |        | {{Assertion}STS}Client  +---------------+
>    |        |------------------------>| Authorization |
>    | Client |                         |     Server    |
>    |        |<------------------------|               |
>    |        |                         +---------------+
>    +--------+
> 
> From our discussions I understood that Model 1 & 2 are currently in focus of the description but model 3 isn't. The security properties for model 1 and model 2 are quite different: in model 2 the provided security is not so much different from the client password mechanism described in Section 2.3.1 of the OAuth core specification. The client essentially sends a secret around. The secret here is the assertion. Without proper protection an adversary who is able to see that assertion is able perform a replay attack. The content of the assertion may allow the replay window to be reduced though. 
> 
> Let me know if your understanding is the same as mine. If so, then I could propose some text on how to get the security claims in the document fixed. 
> 
> Ciao
> Hannes
> 
> 
> 
>