Re: [OAUTH-WG] regarding nested JWTs and security

Jeff - following up on one aspect of our conversation in Orlando, I'd been thinking about what additional guidance needed to be added to the JWT spec about the order of signing and encryption operations.  I've come to the conclusion that this is already handled by the JOSE layer, and so is not a JWT concern, per se.  Nonetheless, I've added the following text to my working draft of the JWT specification after the current Security Considerations about Nested JWTs:

Note that potential concerns about security issues related to the order of signing and encryption operations are already addressed by the underlying JWS and JWE specifications; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic concerns about the potential need to sign after encryption that apply in many contexts do not apply to this specification.

Please let me know if you agree with that statement or if you'd like to see any changes to it or additional statements made.

Thanks again for your diligence!

                                                                -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =JeffH
Sent: Friday, December 21, 2012 3:08 PM
To: IETF oauth WG
Subject: [OAUTH-WG] regarding nested JWTs and security

"nested JWTs" are only nominally defined in draft-ietf-oauth-json-web-token-05

(and the term is missing from the terminology section).

the JWT spec implies that "signing and then encrypting" and "encrypting and then signing" are equivalent. however they aren't in various ways.

Axel already raised this point in..

   Re: [jose] encrypting AND signing a token

  https://www.ietf.org/mail-archive/web/jose/current/msg01269.html

..and cited this paper (worth citing again)..

   Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML

   Don Davis

   http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf

One has to carefully compose signing and encryption in order to avoid various vulnerabilities detailed in the latter.

I agree with Axel that there should be one carefully designed way to craft a signed and encrypted JW*.

Note that in the JSMS draft (draft-rescorla-jsms-00; an early input into what became the JOSE WG), sign & encrypt composition is declared..

> 4.6.  Composition

>

>    This document does not specify a combination signed and encrypted

>    mode.  However, because the contents of a message can be arbitrary,

>    and encryption and data origin authentication can be provided by

>    recursively encapsulating multiple JSMS messages.  In general,

>    senders SHOULD sign the message and then encrypt the result (thus

>    encrypting the signature).  This prevents attacks in which the

>    signature is stripped, leaving just an encrypted message, as well as

>    providing privacy for the signer.

..tho that's a drafty draft and I didn't review carefully enough to determine whether it addresses the need for sign and encrypt to cross-refer (see S4.3 in the paper).

HTH,

=JeffH

_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth