[Openid-specs-ab] JWT encryption

Breno de Medeiros breno at google.com
Thu Jan 12 22:11:57 UTC 2012


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

> The new mode adds integrity to encryption.
>
> If you are using symmetric keys that provides implicit authentication.
>
> You can use it with asymmetric key wrap and that will not in itself
> authenticate the sender, only provide integrity. (Stop padding oracle
> attack)
>
> You would still need to have a separate signature step if you want to
> authenticate the sender.
>
> Using symmetric or asymmetric keys have different management overhead and
> trust models, both are supported.
>

Yes, understood.

Good news. When will there be a draft for the new version of JWT encryption?


>
> John B.
>
> On 2012-01-12, at 6:54 PM, Breno de Medeiros wrote:
>
>
>
> 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
>
>
>


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


More information about the Openid-specs-ab mailing list