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: [email protected] [mailto:[email protected]] 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
