During the OAuth 2nd session at IETF-86 orlando, after I mentioned the
sign-then-encrypt considerations at the mic, Brad Hill pointed out that the
below paper is perhaps an even more fundamental reference for the
sigh-then-encrypt composition than the Davis paper I pointed to in the below
attached message back in Dec-2012..
Authenticated Encryption: Relations among notions and analysis
of the generic composition paradigm (2007)
Bellare & Namprempre
http://eprint.iacr.org/2000/025.pdf
After having talked with Mike Jones f2f earlier in the week about this stuff,
during which he indicated he believed that these issues are addressed in the JWT
spec, I looked at draft-ietf-oauth-json-web-token-06 and note that the last
paragraph of the security considerations says..
While syntactically, the signing and encryption operations for Nested
JWTs may be applied in any order, normally 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. Furthermore, signatures over encrypted text are not
considered valid in many jurisdictions.
..which certainly touches upon the issue(s), but could arguably contain more
rationale. Though, if you wish the spec to be terse (as above) you should
probably at least reference Davis (which is resonably approachable) and Bellare
& Namprempre (which is a formal proof).
Also, in terms of linkages between signing and encrypting wrappers, it seems
that if one includes at least an audience claim in the JWT Claims Set, in a
signed & encrypted JWT (aka "Nested JWT"), and the receiver of the JWT checks
the audience and does not rely on the JWT if it does not identify them, then you
are arguably in ok shape. If the JWT includes both subject and audience claims,
that would be best. It may be a good idea to note this, since in the JWT spec
all claims are optional, and incorporation of (and reliance on) JWT claims is
left to JWT profiles. I.e., there arguably should be advice to JWT profile
authors regarding security properties resulting from incorporation (or not) of
various JWT claims.
HTH,
=JeffH
------
https://www.ietf.org/mail-archive/web/oauth/current/msg10326.html
[OAUTH-WG] regarding nested JWTs and security
From: =JeffH <[email protected]>
Date: Fri, 21 Dec 2012 15:07:35 -0800
To: IETF oauth WG <[email protected]>
"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]
https://www.ietf.org/mailman/listinfo/oauth
