[Openid-specs-ab] JWT encryption

[Breno de Medeiros]

On Thu, Jan 12, 2012 at 13:49, John Bradley <ve7jtb at ve7jtb.com> wrote:

> The plan is to have a encryption with integrity mode that doesn't require
> GCM.
>
> You create a content master key and key wrap that (Symmetric or
> Asymmetric).  That key is used with a KDF to crate 2 keys,  a content
> encryption key and a integrity key.
> The content is AES CBC 128 encrypted (as an example).  Then a HMAC is
> calculated over the encrypted body using the integrity key.
>

Excellent.


>
> To decrypt the process is reversed.
>
> Assuming that you are using symmetric keys the one composite operation
> gets you encryption integrity and verification of the sender.
>
> This will be added to a upcoming draft of JOSE (if there is support).
> The fist JOSE draft will not have normative changes from the existing input
> specs.
>

Again, our assessment is that we don't see any safe usage of JWT encryption
that is not an authenticated encryption mode. I assume that means we fully
support these changes.


>
> If you want to use asymmetric keys you will still need to do a separate
> signing step.  It can be inside or outside the encryption depending on use
> case.
>
> John B.
> On 2012-01-12, at 6:29 PM, Breno de Medeiros wrote:
>
> > 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 encryption.
> >
> > 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
> signatures:
> >
> > "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.
> >
> > --
> > --Breno
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


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