If you make a KEM authenticated method for EDHOC, you get an EAP method (EAP-EDHOC) with very little overhead for free, and can use that in IKEv2 :)
Which probably can work. I don’t think I fully understand what would happen with IKE_AUTH phase in that case – but I’m sure others more knowledgeable could explain. Sent from Commodore VIC-20 😊 ________________________________________ From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Sent: Monday, June 30, 2025 9:06:19 PM To: Valery Smyslov <[email protected]>; [email protected] <[email protected]> Cc: Wilson, David - 0553 - MITLL <[email protected]>; Luo, Brandon - 0553 - MITLL <[email protected]>; [email protected] <[email protected]> Subject: [Lake] Re: [EXT] Re: Proposing Authenticated Key Exchange for adoption consideration Hi Uri, thank you for this draft. My pleasure – and I appreciate you reviewing it. I think that it is better to split it into two – for EDHOC and for IKEv2. We’re still toying with this idea. Thing is, we see the following options: 1. We describe the AKE protocol , and give some semi-hand-waving illustration how to incorporate it into “real” protocols that need/(can-)use Authenticated Key Exchange. Such as IKEv2, EAP, EDHOC, etc. (Note: TLS is explicitly excluded from our list, because there already is a proposal to use implicit authentication, which is much better tailored to the TLS specifics than ours.) 2. We provide a series of RFCs, each dedicated to a single “real” protocol, defining PQuAKE in it, and providing nitty-gritty details of how to integrate PQuAKE into it. While (1) and (2) are not mutually-exclusive, we decided that since having a single “point of reference” for the PQuAKE would be preferred, we’ll start with (1). But to show people that it’s feasible to integrate it into their favorite protocols, we added sections on IPsec, and are planning to add EDHOC and some others. In its current form the integration with IKEv2 looks far from perfect – you seem to not use AUTH and KE payloads at all. Well, if PQuAKE is integrated into IKEv2 as-described in (or closely enough to) our draft – then my personal preference would be to replace with explicit signature payloads of AUTH with Key Confirmation messages from PQuAKE. Somewhat same purpose, much smaller messages. In addition, it is my impression that you actually try to run your protocol inside IKEv2 (with its own data structures). In this case perhaps you can define your protocol as an EAP method, that can be then used in IKEv2. Yes, absolutely! That’s one possibility that we’re actively considering/pursuing – and most likely will present at the EMU on IETF-123 (unless the heat wave kills us before we present 😉). Alternatively, you can re-define your protocol to be better integrated into existing IKEv2 payloads and exchanges (for example, see how it is done for PAKE protocols in RFC 6467). Certainly! As I said, the “integration” sections are now merely to show that it’s possible to do in a reasonable way. Hoping that once the consensus is achieved that such an option is beneficial (for at least some users!), people like yourself would propose improvements (like you just did) to advance the design from “conceptual” to “good”. I also didn’t find info about the way authentication blobs are constructed and how keys are derived in case your protocol is used in IKEv2, so that I only have to guess this. Yet another thing we left out in our haste to actually publish and present. ☹ We’re trying to convince that integrating PQuAKE into the IKE exchanges is feasible, with the exact details to be worked out by us in collaboration with the WG members . Once a targeted draft for IKEv2 with more details is written it will be easier to advise how your protocol is best to be integrated into the IKEv2 protocol. I hear you. Based on my answers, comments, and explanations above – what would you say? Thanks! From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Sent: Friday, June 13, 2025 7:29 PM To: [email protected] Cc: Wilson, David - 0553 - MITLL <[email protected]>; Luo, Brandon - 0553 - MITLL <[email protected]>; [email protected] Subject: [Lake] Re: Proposing Authenticated Key Exchange for adoption consideration Guys, it’s been a bit more than a month since our response was posted – would greatly appreciate your feedback: Are you satisfied with the answers we provided? Are there any more questions? Are there any suggestions/recommendations regarding the protocol itself, or its areas of application? Would appreciate your response! Thank you! P.S. Copying to LAKE WG, because this protocol may be useful to them as well – and they may benefit from following our discussion in IPSECME. -- V/R, Uri From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Date: Monday, May 5, 2025 at 13:17 To: [email protected] <[email protected]> Cc: Wilson, David - 0553 - MITLL <[email protected]>, Luo, Brandon - 0553 - MITLL <[email protected]> Subject: [EXT] [IPsec] Re: Proposing Authenticated Key Exchange for adoption consideration Responding on behalf of our Design Team. Scott and Panos, thank you for pointing out the extra round-trip times in our protocol, and rising other questions about the design. We would like to mention a few points to address your concerns: At first glance, this (from section 5.1, 5.2) appears to be a five-round protocol. That is, each side sends five messages (and wait for five responses). Currently, IKEv2 negotiation is a three-round protocol (counting the intermediate exchange you need with ML-KEM). You are correct, though in practice, IKEv2 does tend to involve more than the pure “three rounds”, e.g., when it wants to use “other” mechanisms: https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/images/g039013.png <https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/images/g039013.png> Now, regarding The protocol diagram we show presents a simplified and more symmetric version of the protocol. We can reduce the number of exchanges by combining the responder’s hello message with the responder’s certificate exchange message and by combining the initiator’s certificate exchange message with the initiator’s first key encapsulation message. If you agree with this approach, we’ll need to clarify this in the RFC draft. We use the extra round-trip time to establish strong security properties such as post-quantum forward secrecy, identity hiding, and stronger mutual authentication via key confirmation: for some, the improved security may be worth the extra round-trip time. While the total time to complete the exchange may be longer on links which have a larger bandwidth, for some uses cases reducing the extra computation and bandwidth needed would be more important, such as for servers or for embedded systems with slow links or limited computing power. Now, ML-KEM is computationally and bandwidth cheaper than ML-DSA - however adding two additional rounds is also expensive (and while it obviously would be implementation dependent, my feeling is that that expense may be greater than the computation/bandwidth costs). What I think you’re saying is that additional exchanges, while lighter on computation and bandwidth, add extra time to the total handshake duration. This is not only implementation-specific – e.g., see above for one way to reduce that by combining messages together – but application/use-case-specific. In some cases, the existing paradigm is good enough. In others (like ours), our paradigm works better overall. Are there any other reasons you believe that it might be "better" than the current proposed approach? Ours formally proves several important properties (see above: (2)): Post-Quantum Perfect Forward Security; Post-Quantum Identity Hiding; Stronger mutual authentication via Key Confirmation. Interesting proposal. It reminds me of KEMTLS. It certainly does (and we are familiar with it, though as you see, ours is simpler – bare-bones, while theirs is fully geared towards TLS) – and both of them remind (or, at least should remind) of MQV and its children HMQV, FHMQV, and a couple more in the same key. I am not sure if there are many IKEv2 negotiations taking place under <2MBps connections. Let me know if there is an issue in this logic. Admittedly, even then, the speed will not matter for these negotiations because the tunnels stay up for a long time. While we cannot speak for all the IPsec users – there is a large enough community that operates over constrained/austere links. So, many as in “percent of the total IPsec users”? Don’t know, can’t claim. Many as in “enough to choose to accommodate them”? Yes. Re. tunnels “staying up for a long time” – some do (e.g., my home VPN 😉), and some don’t. As Scott asked, could there be more motivations for such a drastic change in ikEv2? The proofs, anything else? Advantages of our proposal include: (a) formal proofs, (b) avoiding computation of digital signature (instead of one signing and two verifications by each peer ), we only need one verification by each peer), (c) saving on computation and bandwidth (which may matter much more to the server that deals with many IPsec connections simultaneously, than to a client that needs to perform IKEv2 handshake once in a while/rarely). Also, we are not proposing to change IKEv2, in the sense of “replacing what it does”. We propose an alternative, a complementary path , that can be negotiated and accepted or declined during IKE_INIT. Some user communities (that I know of) are likely to appreciate and accept this option, others (e.g., those that rarely need to establish a new SA, and when they do – it’s over 10+Mbps reliable link) would simply say “Thanks, but no”. And that’s fine with us. 😉 Fragmented UDP, 10K is no more likely to avoid a fragment drop than 15KB in my opinion. More round trips with smaller packets is probably a win in my opinion. (It might push us back to thinking about the puzzles/RFC8019 again) Exactly! Also, depends on the specific use case. E.g., are larger packets more likely to get corrupted by the medium? If it’s a fiber link, probably not. But my users employ other links. 😉 But, probably draft-smyslov-ipsecme-ikev2-reliable-transport is the better answer. For some users – absolutely. For others, that cannot offload everything to TCP – maybe not so… As in the medical science, the correct answer is – it depends. 😉 Thank you!
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
