Hi Sergey, thanks for your input.
On Feb 26, 2013, at 2:36 PM, Sergey Beryozkin wrote: > 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. 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 > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
