Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment

From: "Peck, Michael A" <[email-masked]>
Date: Fri, 15 Mar 2013 03:05:16 +0000

To explain my comment at the microphone today:

Section 8 states:

JWTs use JSON Web Signature (JWS) [JWS<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#ref-JWS>] and JSON Web Encryption (JWE)

[JWE<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#ref-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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Mar 2013 23:16:55 -0400

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
[email-masked]

On 2013-03-14, at 11:05 PM, Peck, Michael A wrote:

> 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). 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Mar 2013 03:22:47 +0000

Hi Mike.  I appreciate your comments.  Recently, Jeff Hodges and Brad Hill have made related comments about the desirability of providing additional guidance to implementers as to what security properties different choices give.  I agree with you - especially recognizing that the specs will be used by people who are not experts in the subtleties of cryptography.

I will endeavor to do this in subsequent drafts.  If you have particular text that you believe should be incorporated, that would be highly appreciated.

                                                            Best wishes,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peck, Michael A
Sent: Thursday, March 14, 2013 8:05 PM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment

Section 8 states:

The choices seem to be:

3.      JWE:

4.      JWS then JWE:

Thanks,

Mike