Re: [OAUTH-WG] JWT ATs and authenticated encryption

[Vittorio Bertocci <[e-mail]>]

Hi Neil,
thanks! This does sound very interesting. Just to clarify, you would
document this in a separate doc extending JOSE?
We could then mention it from the JWT AT profile, whihc would remain
lightweight and implementation independent.
thanks
V.

On Tue, Mar 26, 2019 at 3:11 AM Neil Madden <[e-mail]>
wrote:

> There was a brief discussion at OSW about signing vs encryption for
> JWT-based access tokens. I think it was Brian Campbell that pointed out
> that you often want authenticated encryption rather than signing, and I
> agree with this.
>
> Currently JOSE only supports authenticated encryption for symmetric
> cryptography, which means that the AS and RS must agree a shared secret key
> beforehand. (Or else the RS uses the token introspection endpoint and
> doesn’t decrypt the token itself). Symmetric cryptography is less than
> ideal when the AS and RS are in separate trust boundaries (e.g., different
> companies).
>
> There are actually ways to do *public key* authenticated encryption, but
> JOSE doesn’t support them yet. I wrote a 3-part blog series about this
> recently [1], but I’ll summarise the tl;dr version here. I think for
> JWT-based access tokens that contain identity assertions, this is probably
> what you want in most cases as it provides both confidentiality and
> authenticity without needing a bulky nested signed-then-encrypted JWT. Is
> this something people would be interested in, if I propose a draft?
>
> Details:
>
> The basic idea is to introduce one or more variants on ECDH-ES that
> provide sender authentication. The most straightforward is to use ECDH-SS —
> i.e., Diffie-Hellman between two static key pairs, one for the sender and
> one for the recipient, with no ephemeral keys. This provides authenticated
> encryption so long as the content encryption method is authenticated (which
> they all are in JOSE). But it has a number of security downsides, which I
> describe in more detail in the blog. (It might be useful in some IoT
> scenarios though).
>
> The better variant is to instead do ECDH-ESSS. That is, we generate a
> random ephemeral key pair and do an agreement with the recipient’s static
> public key, just like in ECDH-ES, but then we do another key agreement
> between the sender’s static private key and the recipient’s static private
> key. We then concatenate the two shared secrets and feed them into
> ConcatKDF just like you would for ECDH-ES. This is what NIST SP.800-56A [2]
> calls the “one-pass unified model” (section 6.2.1.2). If you squint a bit
> then it is also very similar to the “K” one-way pattern in the Noise
> protocol framework [3].
>
> To spell it out, the process for encrypting a JWE with this new scheme is
> as follows:
>
> Sender has long-term “static” key pair: ssk,_spk (ssk = sender secret key,
> etc)
> Recipient has long-term static key pair: rsk, rpk
>
> 1. Sender generates a random ephemeral key pair: esk, epk
> 2. Calculate Ze := ecdh(esk, rpk)  — just like in ECDH-ES
> 3. Calculate Zs := ecdh(ssk, rpk)
> 4. Let Z = Ze || Zs where || is concatenation
> 5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in ECDH-ES
> 6. Encrypt the message using the chosen “enc” encryption method using the
> key derived in step 5.
>
> On its own ECDH-ESSS has some decent security properties (including
> authenticated encryption), but it is especially good when you want to
> exchange lots of messages with the recipient. If the recipient replies to
> your initial message using ECDH-ESSS but using the ephemeral public key you
> sent in the first message as if it was your static public key, then what
> you get is an interactive handshake very similar to the Noise KK pattern
> [4] (squinting quite hard at this point). Both parties can then use the
> derived key from step 5 of the second message as a shared session key and
> send “direct” encrypted JWEs to each other from that point on. This
> provides very strong security properties listed later in the Noise spec,
> including forward secrecy and both sender and recipient authentication with
> resistance to key compromise impersonation. So beyond its usefulness for
> Access Token JWTs, this scheme is a really versatile building block that
> you can use for lots of advanced use-cases (e.g., PoP schemes).
>
> There are even nice formal models of the Noise handshake patterns in
> ProVerif [5], but I think they are only valid for the specific details of
> how Noise performs key derivation and transcript hashing so they wouldn’t
> directly apply to a JOSE version.
>
> [1]
> https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and-why-you-want-it-part-i/
> [2]
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
> [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns
> [4]
> https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundamental
>
> [5] https://noiseexplorer.com
>
> Cheers,
>
> Neil
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>