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