Subject: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Feb 2013 14:46:19 +0200

Hi all, 

I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt. 

I would like to point out that this is **discussion input** -- not agreed content. Anything in the document is subject to change!
You also may notice that there are a few questions in the writeup. 

I was trying to more specific about some of the design aspects that folks had proposed during the last few months. 
I have also re-submitted the draft-tschofenig-oauth-hotk, which includes a TLS and a JSON-based solution approach. 

In general, the open questions still seem to be related to 
* Key distribution: What should be described in a document? What is mandatory to implement? 
* Selective header field protection: This is something that was brought forward in discussions and I have included a proposal of how this could look like.
* Channel Binding: Functionality is also included to deal with man-in-the-middle attacks against TLS. There are, however, two types of channel bindings defined in RFC 5929. Are both needed? If not, which one should be selected? 
* Integrity protection and data origin authentication in both directions: The current writeup allows the protection to be extended to messages beyond the initial request. This also offers key confirmation by the server and protection of any responses.  

Writing the text I also noticed that I do not quite understand how nested JWT documents are supposed to look like. For example, how do I encrypt the mac_key carried inside the JWT plus add a signature of all other fields? Currently, I have just encrypted the entire payload. 

I hope to have some discussions prior to the IETF meeting so that we have a more fruitful discussion at the face-to-face meeting.

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 26 Feb 2013 12:36:21 +0000

Hi Hannes
> I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt.

It definitely has more interesting content (about architecture, session 
keys, etc) - this is really useful IMHO.

What I'm not really understanding is why a 2-way TLS transport for the 
session key is not even considered.
Instead this uber-complex (in the context of this spec, IMHO) JWT thing 
is there once again. I appreciate why it may be the case, primarily to 
do with reusing the work done around JWT and having some 
common/recommended access token representation, but disallowing a basic 
bearer token be 'enhanced' with MAC over two-way TLS seems like not 
ideal at all IMHO.
To be honest, I'm not sure why would anyone use JWT+MAC instead of just 
JWE, in cases when people are really comfortable with doing JWT. I guess 
we may be talking now about better security characteristics, but this 
will help a very limited audience as compared to a wider one which can 
use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get 
started.

just my 2c
Thanks, Sergey

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 26 Feb 2013 12:49:24 +0000

Hi Again
> use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get
Oops, I've misread, I think I did, I was reading a Session Key Transport 
to Resource Server section [1] where using JWT seems just OK, while a 
transport to the client section [2] does not enforce the use of JWT.

Sorry for a noise :-)

By the way, should the server be able to enforce the use of MAC as 
opposed to having a client preferring it with its audience info ? If the 
client does not understand it then it does not have the capabilities to 
work with this specific server.

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.2
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.1

> just my 2c
> Thanks, Sergey
>
>> I would like to point out that this is **discussion input** -- not
>> agreed content. Anything in the document is subject to change!
>> I was trying to more specific about some of the design aspects that
>> folks had proposed during the last few months.
>> I have also re-submitted the draft-tschofenig-oauth-hotk, which
>> includes a TLS and a JSON-based solution approach.
>>
>> * Selective header field protection: This is something that was
>> brought forward in discussions and I have included a proposal of how
>> this could look like.
>> * Channel Binding: Functionality is also included to deal with
>> man-in-the-middle attacks against TLS. There are, however, two types
>> of channel bindings defined in RFC 5929. Are both needed? If not,
>> which one should be selected?
>> * Integrity protection and data origin authentication in both
>> directions: The current writeup allows the protection to be extended
>> to messages beyond the initial request. This also offers key
>> confirmation by the server and protection of any responses.
>>
>> Writing the text I also noticed that I do not quite understand how
>> nested JWT documents are supposed to look like. For example, how do I
>> encrypt the mac_key carried inside the JWT plus add a signature of all
>> other fields? Currently, I have just encrypted the entire payload.
>>
>> I hope to have some discussions prior to the IETF meeting so that we
>> have a more fruitful discussion at the face-to-face meeting.
>>
>> Ciao
>> Hannes
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Feb 2013 10:46:30 +0200

Hi Sergey, 

thanks for your input. 

On Feb 26, 2013, at 2:36 PM, Sergey Beryozkin wrote:

> It definitely has more interesting content (about architecture, session keys, etc) - this is really useful IMHO.
> 
> What I'm not really understanding is why a 2-way TLS transport for the session key is not even considered.

Could you explain how this would look like? 

> Instead this uber-complex (in the context of this spec, IMHO) JWT thing is there once again. I appreciate why it may be the case, primarily to do with reusing the work done around JWT and having some common/recommended access token representation, but disallowing a basic bearer token be 'enhanced' with MAC over two-way TLS seems like not ideal at all IMHO.

Note that JWT is used only for the access token encoding. 

> To be honest, I'm not sure why would anyone use JWT+MAC instead of just JWE,

Actually, the authorization server encrypts the access token using JWE and the client uses MAC. 
So, using JWT + MAC is actually not possible since the security mechanisms are used by different entities: the MAC is used by the client and the access token protection is accomplished by the authorization server. 

> in cases when people are really comfortable with doing JWT. I guess we may be talking now about better security characteristics, but this will help a very limited audience as compared to a wider one which can use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get started.
> 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Feb 2013 10:54:42 +0200

Hi Sergey, 

good that this issue got clarified. 

Regarding: 

> By the way, should the server be able to enforce the use of MAC as opposed to having a client preferring it with its audience info ? If the client does not understand it then it does not have the capabilities to work with this specific server.

Currently, the authorization server decides about the use of a certain token type. The audience field is used to allow the client to tell the server which resource  server it wants to talk to. This is of value not only for this specification but also for the bearer token specification. In this specification the resource server uses this audience field for selecting the appropriate key to encrypt the access token. If the client is tricked in sending the access token to a different resource server then that server will not be able to decrypt the access token and will not be able to retrieve the session key. Consequently, it will not be able to impersonate the client towards another resource server. 

Ciao
Hannes

On Feb 26, 2013, at 2:49 PM, Sergey Beryozkin wrote:

> Oops, I've misread, I think I did, I was reading a Session Key Transport to Resource Server section [1] where using JWT seems just OK, while a transport to the client section [2] does not enforce the use of JWT.
> 
> Sorry for a noise :-)
> 
> By the way, should the server be able to enforce the use of MAC as opposed to having a client preferring it with its audience info ? If the client does not understand it then it does not have the capabilities to work with this specific server.
> 
> Thanks, Sergey
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 28 Feb 2013 16:52:29 +0000

Hi Hannes

> Currently, the authorization server decides about the use of a certain token type. The audience field is used to allow the client to tell the server which resource  server it wants to talk to. This…
Thanks for the explanation, I should've read better, 'audience' is a 
useful attribute.

What confused me was this text: "Authorization servers issue MAC Tokens 
based on requests from clients." - it kind of reads to me that the 
clients drive whether it is MAC or some other token type is issued in 
exchange for a grant while I'd expect the AS administrators deciding on 
what sort of token type is used.

As for "MUST" and audience - might it make sense to replace it with 
SHOULD or RECOMMENDED ? I wonder if some issues like port number of 
individual resource servers comprising the bigger resource server 
application, etc, might make it difficult to use 'audience' - not sure 
if it of real concern or not :-)

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 28 Feb 2013 17:00:20 +0000

Hi Hannes
> Could you explain how this would look like?
Given my earlier confusion, and knowing it is a path between AS and RS, 
what would prevent RS and AS exchanging their certificates and admins 
configuring both to require a client certificate authentication ?

and then basically use some simple name/value exchange ? I don't mind 
against having a JWT profile supported at the AS-to-RS path

What I find a bit unusual is the fact that this AS to RS path is even 
covered - this is probably the first attempt AFAIK :-), though I guess 
it must be important to do it

> So, using JWT + MAC is actually not possible since the security mechanisms are used by different entities: the MAC is used by the client and the access token protection is accomplished by the autho…
Sorry, I got confused earlier :-)
thanks, Sergey