Mahesh Jethanandani has entered the following ballot position for draft-ietf-ipsecme-ikev2-downgrade-prevention-07: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with both of Boucadair's DISCUSS points. RFC 9242 is a normative dependency because Section 7.1 contains a MUST that depends on the IntAuth term defined in RFC 9242, and the entire IKE_INTERMEDIATE interaction is meaningless without reading that RFC. RFC 5723 is a normative dependency because Section 7.2 contains two MUSTs ("MUST be stored in the ticket" and "MUST act the same way when doing resumption") that depend on the ticket mechanism defined in RFC 5723. Both should be listed as normative references. Section 9, first paragraph — incomplete statement: 433 > The IKEv2 extension defined in this document protects against 434 > downgrade attacks on IKEv2 described in Section 4. It only provides 435 > this protection when both peers implement the extension. In my view, the second sentence is an incomplete statement. Section 5 correctly identifies two conditions: both peers must support the extension AND at least one non-compromised authentication key must be used in the protocol run. The opening of Section 9 omits the second condition, which is the substantive one that the rest of Section 9 spends several paragraphs analyzing (PSK, EAP, etc.). I would suggest aligning it with the Section 5 language. --- Section 5 note — important limitation not cross-referenced in Section 9: 318 > | This mechanism only detects tampering with the IKE_SA_INIT 319 > | transcript. It does not change the transform-selection rules 320 > | for the responder. In particular, it does not by itself prove 321 > | that the strongest mutually supported cryptographic algorithms 322 > | were selected. That property depends on responder selection 323 > | policy, which remains governed by [RFC7296] and local 324 > | configuration. This limitation — that the extension authenticates the final IKE_SA_INIT transcript, but cannot prevent an attacker from first using a forged INVALID_KE_PAYLOAD to force a retry on a weaker key exchange, thereby influencing what that final transcript contains — is security-relevant and belongs in Section 9. Readers who consult Security Considerations directly to assess the residual attack surface will miss this caveat entirely. I would suggest adding a paragraph in Section 9 that summarizes this limitation and cross-references Section 5. --- Section 8 — attack indistinguishability not noted: 427 > Deployments that rely on this mechanism for downgrade resistance 428 > should provide a local policy to require successful negotiation of 429 > this extension and to abort the connection otherwise. This section is the entirety of the operational guidance. In my view, it would benefit from noting — consistent with what Section 5 says — that when the mechanism detects a downgrade attempt, the resulting authentication failure is indistinguishable from any other authentication failure (incorrect credential, configuration mismatch, and so on). This has direct operational consequence: operators cannot distinguish a downgrade attack from a misconfiguration, so logging and alerting on these failures carries limited diagnostic value. _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
