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 <neil.mad...@forgerock.com> 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 <vitto...@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.mad...@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
