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

[Sergey Beryozkin <[e-mail]>]

Hi Hannes,

Sorry for a delay and thanks for your patient answer,
Comments below,
On 15/07/13 21:36, Hannes Tschofenig wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi Sergey,
>
> sorry that I missed your earlier questions.
>
> On Jul 15, 2013, at 10:20 PM, Sergey Beryozkin wrote:
>
>> 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
>>
> 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.
>
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

>> - 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.
>
Well, I guess what I'm looking

> Ciao
> Hannes
>
>>
>> Best Regards
>> Sergey
>>
>> On 15/07/13 18:29, Hannes Tschofenig wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> 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
>>>
>>> -----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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBCgAGBQJR5F1RAAoJEGhJURNOOiAteosIAJx3WPuvRgMLkal1S+8yNYZa
> OXkBwDBW9bik0FX683Dw7HFzAoTuGyGuV1mb6oUIsd2NZfBgN4l9Gs24VrUlbndh
> MjZRJ9+23NrZd/uVo0t3w3eEdTS0OjKGz8j9AO+gFBFDCtoqTu8CSmbi2hG9v/j0
> tn7891snryz77Gg/D1zlkSS4njt0M9Gl5eaMmU5R13p2wbfpL0k2Qqs3XumAeSSO
> y/jgCJ4lXaLp2HepdfEvjdYwCM8cOzYJ2vvePJ/39jYNMqifmJfk3hVHcFTP4TM4
> ers2hZBe0iTkc0aICmdtwyK0VtFPGGa4XvfHGTWQ+g0hBZxmfLxIY3VGZVun4Q8=
> =677/
> -----END PGP SIGNATURE-----
>


-- 
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com