[Openid-specs-ab] JWT encryption

Breno de Medeiros breno at google.com
Thu Jan 12 21:29:46 UTC 2012

This is feedback related to the JWT Encryption/JWS specs. I am submitting
this here because we're reviewing the whole stack. Independently of the
Connect implementation, we are working on a different project that uses JWT

In this first usage of JWT encryption, we need integrity-protected
encrypted payloads. We do not need non-repudiation. The underlying
libraries do not have support for AES-GCM. We don't expect the latter
reality to change for a number of years since the clients have a slow
update cycle.

The JWT Encryption/JWS spec do appear to support this use case. Note that
to have integrity encrypted data, one needs to perform
encryption-then-authentication, since that is the correct order to compose
these primitives. So my first observation is that this security
recommendation in the JWT encryption spec is factually incorrect when
referring to symmetric authentication schemes as opposed to public key

"This document does not specify a combination signed and encrypted
  mode.  However, because the contents of a message can be arbitrary,
  encryption and data origin authentication can be provided by
  recursively encapsulating multiple JWE and JWS 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."

In addition, the JWT Encryption/JWS recommends Sign-then-encrypt, which
provides confidentiality of signed data, but does not provide integrity of
the encrypted data. So in some scenarios you could attack the
encryption layer by sending random data and forcing it to decrypt blindly.
The signature verification step performed after the decryption may be
too late.
Again, to protect the encryption layer, one should encrypt then
sign/authenticate.  So if one wants to have both confidentiality and
non-repudiation which the JWT/JWS specs are designed to support) and
AES-GCM is not available (as the case in the next few years depending on
which environment you're targeting), the only way to use the JWT/JWS
specs securely is to sign, then encrypt,
then sign (or authenticate) again. Which is terribly inefficient.

In other words, in our security review, the only usable mode for JWT encryption
defined today is AES-GCM. Which is not generally available.

Is that the desirable state of things? Because if so, we plan to define
some other way to use encryption with JWT instead.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120112/460b42e6/attachment.html>

More information about the Openid-specs-ab mailing list