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

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 <hannes.tschofenig@gmx.net>
To: Sergey Beryozkin <sberyozkin@gmail.com> 
Cc: oauth@ietf.org 
Sent: Monday, July 15, 2013 1:36 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac

-----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. 

> - 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

> 
> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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-----
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth