Mike, It is my understanding there will be new draft (or a revision of the MAC draft) that builds on the JWT draft to define a secure (MAC) token based on the security requirements presentation I gave today.
I believe all/most of your questions should be addressed in the security draft: http://tools.ietf.org/html/draft-tschofenig-oauth-security-01. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-03-14, at 11:05 PM, Peck, Michael A wrote: > To explain my comment at the microphone today: > > Section 8 states: > > JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) > [JWE] to sign and/or encrypt the contents of the JWT. > > I believe it’d be useful to expand upon this to give guidance to those using > JWT on what they should do to cryptographically protect it. When should they > do nothing? When should they just sign? When should they just encrypt? When > should they sign and then encrypt? What security properties does each option > provide or not provide? > > The choices seem to be: > > 1. No JWS and no JWE – assumes the JWT is protected through some other > mechanism or that it doesn’t need to be protected > > 2. JWS – probably OK if confidentiality is not necessary. > > 3. JWE: > Authentication is not provided unless a shared symmetric key is used (if it’s > asymmetric encryption, only integrity protection will be provided, not > authentication). > Under what conditions is authentication necessary or not necessary? > AES-GCM may not be safe to use with a shared symmetric key (I sent feedback > on this to the jose mailing list). > > draft-ietf-oauth-v2-http-mac for example seems to currently solely use JWE > and says “this keying material is a symmetric or asymmetric long-term key > established between the resoruce server and authorization server”. If it’s > asymmetric, a JWS seems to also be necessary to authenticate the > authorization server as the source of the JWT? > > 4. JWS then JWE: > A recipient who is an attacker/who is compromised could potentially strip off > the JWE (making it just a JWS) or strip the JWE and replace it with another > JWE to cause confusion about the intended recipient of the JWT and forward it > on to another recipient. The presence of the “aud” (Audience) claim seems to > protect against this. However, the “aud” claim is optional in JWTs. > > > Thanks, > Mike > _______________________________________________ > 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
