Hi Uri,
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?
I think that you basically have 3 options with regard to IKEv2.
1. Define new EAP method (even EAP-EDHOC, as John suggested) and use it in
IKEv2. In this case you will get integration
with IKEv2 for free. Moreover, you can use existing off-the-shelf IKEv2
implementations, since using EAP is
present in core IKEv2 spec (RFC 7296) and most vendors support it. Provided
your new EAP method is a “key generating” one
(it must be in my understanding), the security properties of IKEv2 will not
degrade. You even don’t need to publish an
IKEv2-related RFC in this case – only RFC defining this new EAP method. The
downside of this approach is that
using your protocol in IKEv2 (via EAP) will be sub-optimal in terms of round
trips and message size.
2. Use framework defined in RFC 6467. It was designed for integration of
any PAKE protocol into IKEv2, thus
re-using it for certificate-based authentication looks like a bit of hacking.
In this case you will have to
write a small RFC describing how your protocol fits into this framework. The
downside of this approach
is that RFC 6467 is Experimental and (to my best knowledge) is not widely
supported in implementations.
3. Define more tight integration of your protocol with IKEv2. This will
allow you to save a couple of round trips,
and to make the messages smaller and more elegant (by re-using the information
that IKEv2 exchanges anyway).
An example of such approach is RFC 8784 and draft-ietf-ipsecme-ikev2-qr-alt,
both defining
how additional PSK can be used in IKEv2 to protect it against quantum computers.
This is the approach you are currently following in your draft. I think that in
this case a dedicated IKEv2-related draft
is needed and it should go the whole way of the IPsecME WG adoption and review.
Which way to go depends on your goals. I personally don’t recommend option 2 (I
included it for completeness),
since RFC 6467 is not well supported and this would be a protocol hack, since
it was intended only for PAKEs integration.
Among options 1 and 3, the former will give you most quick result with least
efforts, but the integration
with IKEv2 will be not perfect (in terms of efficiency). The latter will give
you a chance to get most efficient
integration, but requires much more efforts and time.
Regards,
Valery.
Thanks!
From: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
Sent: Friday, June 13, 2025 7:29 PM
To: ipsec@ietf.org
Cc: Wilson, David - 0553 - MITLL <david.wil...@ll.mit.edu>; Luo, Brandon - 0553
- MITLL <brandon....@ll.mit.edu>; l...@ietf.org
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 <u...@ll.mit.edu>
Date: Monday, May 5, 2025 at 13:17
To: ipsec@ietf.org <ipsec@ietf.org>
Cc: Wilson, David - 0553 - MITLL <david.wil...@ll.mit.edu>, Luo, Brandon - 0553
- MITLL <brandon....@ll.mit.edu>
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
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!
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
