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

Hi Hannes
On 25/02/13 12:46, Hannes Tschofenig wrote:
> Hi all,
>
> 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

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