Re: [OAUTH-WG] Public key authenticated encryption for JWTs [Was Re: JWT ATs and authenticated encryption]

[Neil Madden <[e-mail]>]

I have published a -01 version with example computations for both ECDH-1PU over P-256 and also a two-way interactive handshake using it with X448 keys. I also fleshed out the security considerations and added a “skid” (Sender Key ID) header parameter.

I think this is potentially very useful in OAuth/OIDC for JWT-based access tokens, encrypted request parameters, ID tokens, and maybe also PoP.


A new version of I-D, draft-madden-jose-ecdh-1pu-01.txt
has been successfully submitted by Neil Madden and posted to the
IETF repository.

Name:		draft-madden-jose-ecdh-1pu
Revision:	01
Title:		Public Key Authenticated Encryption for JOSE: ECDH-1PU
Document date:	2019-05-10
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-madden-jose-ecdh-1pu-01.txt <https://www.ietf.org/internet-drafts/draft-madden-jose-ecdh-1pu-01.txt>
Status:         https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ <https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/>
Htmlized:       https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01 <https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu <https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-madden-jose-ecdh-1pu-01 <https://www.ietf.org/rfcdiff?url2=draft-madden-jose-ecdh-1pu-01>

Abstract:
  This document describes the ECDH-1PU public key authenticated
  encryption algorithm for JWE.  The algorithm is similar to the
  existing ECDH-ES encryption algorithm, but adds an additional ECDH
  key agreement between static keys of the sender and recipient.  This
  additional step allows the recipient to be assured of sender
  authenticity without requiring a nested signed-then-encrypted message
  structure.  The mode is also a useful building block for constructing
  interactive handshake protocols on top of JOSE.

Cheers,

Neil

> On 9 May 2019, at 17:15, Neil Madden <[e-mail]> wrote:
> 
> OK, I have put together a (very) rough first draft here - https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ <https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/>
> 
> I have an implementation so I will try to find some time to generate some test vectors, but essentially you do exactly the same as for ECDH-ES but you derive a second shared secret between the sender’s static private key and the recipient’s static private key, then concatenate them together and run it through Concat-KDF as before.
> 
> I also have a GitHub for the draft https://github.com/NeilMadden/jose-ecdh-1pu <https://github.com/NeilMadden/jose-ecdh-1pu> that has a README with some more informal discussion.
> 
> I think this is potentially a very useful mode for JWT access tokens in particular where you want to encrypt and authenticate the AT to pass through the client to the RS without the overhead of nested signed+encrypted JWTs or the security risks of shared secrets.
> 
> Cheers,
> 
> Neil
> 
>> On 27 Mar 2019, at 13:51, Neil Madden <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[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/ <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 <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf>
>>> [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns <https://noiseprotocol.org/noise.html#one-way-handshake-patterns> 
>>> [4] https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundamental <https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundamental> 
>>> [5] https://noiseexplorer.com <https://noiseexplorer.com/>
>>> 
>>> Cheers,
>>> 
>>> Neil
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth