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

[=JeffH <[e-mail]>]

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 <[e-mail]>
Date: Fri, 21 Dec 2012 15:07:35 -0800
To: IETF oauth WG <[e-mail]>

"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