Hi folks,
Several new Key Exchange methods were defined after RFC 7296 was published.
(See
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8)
For example, RFC 8031 introduced two new KE methods, Curve25519 (KE Method ID =
31) and Curve448 (KE Method ID = 32). There may be more new KE methods defined
in the future, e.g., the PQC KEM may be introduced into IKEv2.
Regarding how the responder handles the request containing the new Key Exchange
methods (old name was DH Group) that it doesn’t understand, I’ve had a
discussion with someone, but we failed to agree with each other due to
different interpretations of RFC 7296. I’d like to hear more opinions from you
experts.
The handling I suggest is as follows:
1) if all KE methods proposed by the initiator are unknown to the
responder, i.e., no KE method is acceptable, then the responder replies
NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload.
2) if at least one acceptable KE method is included in the initiator’s
proposals, the responder can select one acceptable KE method, ignore the
unknown KE methods, and perform the next step of KE Payload processing.
2.1) if the KE method used in the KE payload happens to be the same as
this selected KE method, then the responder normally replies with this selected
KE method and the corresponding KE payload.
2.2) if the KE method used in the KE payload is different from this
selected KE method, then the responder replies INVALID_KE_PAYLOAD with this
selected KE method, regardless of whether the KE method used in the KE payload
is known or unknown to the responder.
My logic is as follows:
In section 3.3.6 Attribute Negotiation of RFC 7296, it says:
Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand, it MUST consider this transform unacceptable; other
transforms with the same Transform Type are processed as usual. This
allows new Transform Types and Transform Attributes to be defined in
the future.
This paragraph indicates that the responder should ignore the unknown KE
methods in the SA payload because the new KE methods can be considered as new
Transform Attributes.
Also in section 3.3.6, it says:
Negotiating Diffie-Hellman groups presents some special challenges.
SA offers include proposed attributes and a Diffie-Hellman public
number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and
include a KE corresponding to that group. If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the
initiator SHOULD pick an element of that group for its KE value when
retrying the first message.
This paragraph indicates that the initiator can suggest a KE method regardless
of whether it is known to the responder. The latter sentence indicates that the
responder can continue the negotiation when the KE method in the KE payload is
unknown and just needs to reply INVALID_KE_PAYLOAD with the correct KE method.
However, others suggest that the responder should terminate the IKE exchange
without reply, when the KE method used in the KE payload is unknown to the
responder, even if there are other acceptable KE methods proposed in the SA
payload.
Because they feel the unknown KE method in the KE payload means that the whole
packet is an invalid packet, and discarding this packet is the thing to do.
I’d like to hear more opinions from you experts.
Regards & Thanks！
Wei PAN (潘伟)
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
