Subject: [OAUTH-WG] draft-ietf-oauth-v2-http-mac

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Jul 2013 19:29:29 +0200

Hi all, 

we have submitted an update to the MAC token document. From the changes to the previous version you will see that we have incorporated text written during the design team discussions earlier this year into the appendix. I hope that this provides additional background about the threats, use cases, and security requirements. Phil has joined us as a co-author (since he was heavily involved in the work on the incorporated text). 

There is, however, still work to be done. The body of the document still needs a lot of work to get the specification to level of detail that we can start the WGLC. 

Anyway, here is the updated  document: 
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 15 Jul 2013 21:20:36 +0100

Hi Hannes, All,

Thanks for the update.

I asked last time but did not get an answer:
- why the use of access token is mandated to be 'conditional' - if you 
think I need to read the text more carefully, then please do not 
hesitate to say so :-), I'll give it a try

- Reading "Session Key Transport to Resource Server" section makes me 
nervous. May be I'm missing the point, but I wonder, what happened to 
that draft which had a chance to go mainstream ? Do editors target a new 
MAC token at large OAuth2 implementers only ? It appears to me the focus 
is more on getting JWT more recognized as opposed to making a simple MAC 
scheme working...I'm sorry if I sound like I've no clue what I'm talking 
about, but please make this section read such that people can implement 
the scheme without having to know what JWT or a dynamic introspection 
mechanism is

Best Regards
Sergey

On 15/07/13 18:29, Hannes Tschofenig wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi all,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBCgAGBQJR5DF6AAoJEGhJURNOOiAtD1YIAKZYojwcZ1H8MqWtvJTv9/81
> YLIW7kUraNlwUelTRu4WoakYDGmcG8gPHr4LjbVWhhtcSOIHqDsEYeCuEqPTBPbZ
> Gv5tG7B5SKS7Cn540f5ZVGNsIhGqSdpBpdRau2o8WKlD3HwgOHKeLgBfhF7fkWhc
> 3xDo2lS3Q6khwPW2VrnP1fpUS2vs2sMq+zWBYwk0+onHcdSVsonF0+gPkg0aaXnO
> gMZML5KecISt7UHI8r4ZduCkPq1Hhk3Rdp7XW3KOnJRO1DNeShjI20k52sU6Y33Q
> mmATLQoqyb9ld2gZIspS3w0eGfKkO843ImwTCjtLMHWH50rYGuv0oue5Lf0x0n8=
> =fDtL
> -----END PGP SIGNATURE-----
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Jul 2013 22:36:32 +0200

Hi Sergey, 

sorry that I missed your earlier questions. 

On Jul 15, 2013, at 10:20 PM, Sergey Beryozkin wrote:

> - why the use of access token is mandated to be 'conditional' - if you think I need to read the text more carefully, then please do not hesitate to say so :-), I'll give it a try
> 
The reason is that the keying material associated with the access token may be cached by client and the resource server. Hence, you may not need to send the access token with every request. 

I am working on some examples that will illustrate this nicely. 

> - Reading "Session Key Transport to Resource Server" section makes me nervous. May be I'm missing the point, but I wonder, what happened to that draft which had a chance to go mainstream ? Do editors target a new MAC token at large OAuth2 implementers only ? It appears to me the focus is more on getting JWT more recognized as opposed to making a simple MAC scheme working...I'm sorry if I sound like I've no clue what I'm talking about, but please make this section read such that people can implement the scheme without having to know what JWT or a dynamic introspection mechanism is

In Section 4 we discuss different key distribution mechanisms. There has to be a story for how the session key gets from the Authorization Server securely to the Resource Server. 
Not discussing that topic (like done before) does not make the issue go away and so we describe the options. We will not get through the IETF process without having an answer to that question. 

Hence, the only question is: which key distribution mechanism do you like most? I had asked that question to the group before and the consensus so far was "stick the key in the access token".  This is what Section 4.2 currently describes. 

I am happy to describe that in a better way in the document if you think that the story does not get across well. 

Ciao
Hannes

---

From: Bill Mills <[email-masked]>
Date: Mon, 15 Jul 2013 18:23:58 -0700 (PDT)

Section 4.2:

"accomplished by conveying the encrypting mac_key inside the access token" the use of "encrypting" is wrong there I think did you mean encrypted?

Section 5.1:  The BNF is wrong I think:

-"id" is underfined, instead you define kid
-where is a field separator defined?
-whitespace is just bad news here I think, there's no requirement in the BNF to quote strings with whitespace.

Additional comments:

0) Section 5.2 needs a lot more, yes?

1) timestamp isn't great for replay protection, if strong replay protection is needed we should require a nonce or sequence number.

2) why does kid need to be in the MAC header?  In fact, why is it required at all?

-bill

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: Sergey Beryozkin <[email-masked]> 
Cc: [email-masked] 
Sent: Monday, July 15, 2013 1:36 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac

Hi Sergey, 

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 17 Jul 2013 10:33:52 +0100

Hi Hannes,

Sorry for a delay and thanks for your patient answer,
Comments below,
> I am working on some examples that will illustrate this nicely.
Sounds good, will be useful.

I wonder if the approach of sending the token on the 1st call only may 
have effectively lead to a given access token 'expiring' earlier than is 
intended by AS, not sure, what happens if the client does not receive a 
response from server, will it break it sequence calculation algorithm ?

I'd prefer to make what appears to be an optimization optional.
In fact it seems to me that the optimization is there because the 
current draft effectively assumes that we have a self-contained, 
encrypted JWT access token, the long base64 encoding sequences opposite 
to an 'access token' in the example makes me think it is case :-). If so 
then the concern is that users will think unless we have JWT we can not 
do MAC and this will be a problem - and so far JWT features prominently 
in the text.

I'm keen to see the text which would also assume that access token may 
be effectively a bearer-like key, with RS/AS storing the session keys 
alongside access token details - may not scale very well but it lowers 
the entry barrier a lot for people who may want to do a quick test, POC, 
with MAC tokens, without getting an immediate concern of having to 
support a JWT 'container' for sending the keys from AS to RS.

IMHO the text should make it possible for users to assume that AS & RS 
might be collocated in basic/demo cases, same as it is possible to do 
with bearer tokens. The entry barrier should be low, and do not require 
the expertize of a big company's security experts to get MAC tokens 
floating around.

So, Re the Session Transport from AS to RS: thanks for clarifying it is 
important to have this text but IMHO it needs to read less mandatory 
(not sure of the better word), i.e, as I said above, people should be 
able to assume that AS & RS are collocated. It is really important IMHO.

Speaking of using JWT container in this transport, it opens up another 
question: what is the actual protocol which will be used to convey JWT 
between AS & RS - which is a new and possibly big spec effort on its 
own, so perhaps defaulting to the Token Introspection mechanism will 
have a better chance.

May be it makes no sense, but these are my thoughts anyway.

Thanks, Sergey

> I am happy to describe that in a better way in the document if you think that the story does not get across well.
Well, I guess what I'm looking

> iQEcBAEBCgAGBQJR5F1RAAoJEGhJURNOOiAteosIAJx3WPuvRgMLkal1S+8yNYZa
> OXkBwDBW9bik0FX683Dw7HFzAoTuGyGuV1mb6oUIsd2NZfBgN4l9Gs24VrUlbndh
> MjZRJ9+23NrZd/uVo0t3w3eEdTS0OjKGz8j9AO+gFBFDCtoqTu8CSmbi2hG9v/j0
> tn7891snryz77Gg/D1zlkSS4njt0M9Gl5eaMmU5R13p2wbfpL0k2Qqs3XumAeSSO
> y/jgCJ4lXaLp2HepdfEvjdYwCM8cOzYJ2vvePJ/39jYNMqifmJfk3hVHcFTP4TM4
> ers2hZBe0iTkc0aICmdtwyK0VtFPGGa4XvfHGTWQ+g0hBZxmfLxIY3VGZVun4Q8=
> =677/

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Jul 2013 11:42:30 +0200

Hi Sergey, 

thanks for your response. Comments inline 

On Jul 17, 2013, at 11:33 AM, Sergey Beryozkin wrote:

> I wonder if the approach of sending the token on the 1st call only may have effectively lead to a given access token 'expiring' earlier than is intended by AS, not sure, what happens if the client does not receive a response from server, will it break it sequence calculation algorithm ?

Not sure I fully understand that remark. 

Why would a token expire earlier by sending it from the client to the RS? The token expiry date is indicated in the token itself. 

> I'd prefer to make what appears to be an optimization optional.

It certainly makes sense to allow the client to always send the token. Sometimes these tokens may, however, be fairly big. If client makes regular calls to a resource server this can certainly make a difference. 

> In fact it seems to me that the optimization is there because the current draft effectively assumes that we have a self-contained, encrypted JWT access token, the long base64 encoding sequences opposite to an 'access token' in the example makes me think it is case :-). If so then the concern is that users will think unless we have JWT we can not do MAC and this will be a problem - and so far JWT features prominently in the text.

It is true that the key exchange protocol has an impact on the overall message size/communication patterns here. When I asked the group for their preference at the last IETF meeting, see http://www.ietf.org/proceedings/86/minutes/minutes-86-oauth, I presented a three choices, namely

Option 1 - Key Transport
Option 2 - Key Retrieval
Option 3 - Key Agreement

Option #1 & #2 were hot candidates but the preference went for #1. We will still standardize #2 as well since the token introspection is a useful mechanism for other use cases but we have to pick something as mandatory to implement. 

> 
> I'm keen to see the text which would also assume that access token may be effectively a bearer-like key, with RS/AS storing the session keys alongside access token details - may not scale very well but it lowers the entry barrier a lot for people who may want to do a quick test, POC, with MAC tokens, without getting an immediate concern of having to support a JWT 'container' for sending the keys from AS to RS.

Regardless what you actually do to obtain the key you want to make sure that you generic fresh and unique session keys, as the document discussed in great detail in the appendix. 

You are more looking into a version with key retrieval but you don't want to use a standardized protocol, like the token introspection, but rather a proprietary mechanism. That may well be fine (with the downside that the AS and the RS will have to come from the same vendor). 

So, the only challenge for you is the mandatory-to-implement aspect. If you also develop the implementation you would have to implement a key transport mechanism that you are not going to use, which may be an issue for you. 

This is an aspect we should discuss on the list and also the next meeting because it may interest a couple of folks. 

> 
> IMHO the text should make it possible for users to assume that AS & RS might be collocated in basic/demo cases, same as it is possible to do with bearer tokens. The entry barrier should be low, and do not require the expertize of a big company's security experts to get MAC tokens floating around.

Got your point. In the most simplistic case you might even have the AS and the RS in the same box and you just do a local database dip. 

> 
> So, Re the Session Transport from AS to RS: thanks for clarifying it is important to have this text but IMHO it needs to read less mandatory (not sure of the better word), i.e, as I said above, people should be able to assume that AS & RS are collocated. It is really important IMHO.

Will include a discussion about this aspect in the next version of the document. 

> 
> Speaking of using JWT container in this transport, it opens up another question: what is the actual protocol which will be used to convey JWT between AS & RS - which is a new and possibly big spec effort on its own, so perhaps defaulting to the Token Introspection mechanism will have a better chance.

For the key transport mechanism the access token is the JWT. The access token travels from the AS to the client and then to the RS. 
For the key retrieval mechanism there is no JWT - the plain JSON data is fetched by the RS from the AS. A promising version of that work can be found with the token introspection: 
http://tools.ietf.org/html/draft-richer-oauth-introspection-04 

> May be it makes no sense, but these are my thoughts anyway.

Makes a lot of sense. Thanks for the feedback. 
Once I updated the document I will ask you to double-check it to see whether I covered the feedback appropriately. 

Ciao
Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 23 Jul 2013 22:07:16 +0100

Hi Hannes,
thanks for the clarifications (can't guarantee I've a totally clear 
picture still :-)), please see comments below
> Why would a token expire earlier by sending it from the client to the RS? The token expiry date is indicated in the token itself.
I was implying that if it is important for the client to get a response 
to the current invocation delivered to it for the next invocation with 
the next sequence number to succeed, then if we have a response failure 
then a client would likely need to do a token refresh, earlier than it 
would typically do (ex, when AT expires). May be this is unfounded, the 
example will help :-)

> It certainly makes sense to allow the client to always send the token. Sometimes these tokens may, however, be fairly big. If client makes regular calls to a resource server this can certainly make…
Agreed; would be just good to let the clients (optionally) simply send 
AT on every request - I can imagine it can be tricky to do, the 
optimization, in certain environments (example, a client created within 
a tooling studio, etc)
> http://tools.ietf.org/html/draft-richer-oauth-introspection-04

You mean an out-of-band long term key retrieval mechanism  ? The text 
mentions the introspection mechanism in scope of handling an AT to RS 
session key transmission...

Either way, thanks for all the above text, I'm afraid I'm still somewhat 
unclear on the following.

The draft says that a client gets access token + mac_key from the 
authorization server. You say that a key transport (from AT to client) 
is actually JWT, but this session key (inside that token) is 
interchangeable with a 'mac_key' term. So we have AT sending the key to 
the client inside AT and as a regular parameter, 'mac_key'.

Am I right so far ? So why a session key is included inside the access 
token if it is available as a mac_key parameter ? And, in a case of AT & 
RS being non collocated we have the text talking about a session key 
delivered to RS so no need for a client to present it to RS. Is it the 
same session key or we are talking different keys here (apart from the 
long term keys)

Can you please clarify again on the last question ?

Many thanks, Sergey

> iQEcBAEBCgAGBQJR7P6GAAoJEGhJURNOOiAttW8H/RO5g1IcDxPHdiClOzmZDRFT
> lHV7x7bUFLaWJslvcQAYj5KBKYMCH5ar96se7gz8KDlqlhWkl7RoZYPZ+ya2MnXZ
> cHinVeOXIU+bzSib9Y+Nq8cZK31vtf2zrQQ9dxJV2w42ebLNRYfLL6KKNQvt+Mho
> Czsy7R3insRiRQ0LOOFW4RFCm3bNUtaufimdPjhyv1p5EQPX+OD+Ack4jXu5C7Th
> JwUW8B74I5oWFMTV5ohAxIUwS5n0pYOtHs0X22+Hpl3yEON38niTiwXa4E/+iUOr
> TAFE22xNM4d8bSZU1y8tgg1LPjliaWYVdfif4r3ix+mzd/XV5sdyQFm8TdP+V3s=
> =2IHL