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

Yes - a separate doc. Given that it is potentially useful in the context of OAuth, it might be something that the OAuth WG could consider, given that the JOSE WG is disbanded. I’ll see if I can find some time to put a draft together. (In markdown now that my mind has been blown that I don’t have to do everything in XML!)

> On 26 Mar 2019, at 16:50, Vittorio Bertocci <Vittorio@auth0.com> wrote:
> 
> 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 <neil.madden@forgerock.com> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth