IETF Last Call Review of draft-ietf-ipsecme-ikev2-downgrade-prevention-05
review-ietf-ipsecme-ikev2-downgrade-prevention-05-secdir-lc-rosomakho-2026-06-12-00
| Request | Review of | draft-ietf-ipsecme-ikev2-downgrade-prevention |
|---|---|---|
| Requested revision | No specific revision (document currently at 06) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-06-12 | |
| Requested | 2026-05-29 | |
| Authors | Valery Smyslov , Christopher Patton | |
| I-D last updated | 2026-06-17 (Latest revision 2026-06-17) | |
| Completed reviews |
Genart IETF Last Call review of -05
by Linda Dunbar
(diff)
Opsdir IETF Last Call review of -05 by Dhruv Dhody (diff) Secdir IETF Last Call review of -05 by Yaroslav Rosomakho (diff) |
|
| Assignment | Reviewer | Yaroslav Rosomakho |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-ipsecme-ikev2-downgrade-prevention by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/oVtD5ImYjIG6ebxsXQSktcyos1s | |
| Reviewed revision | 05 (document currently at 06) | |
| Result | Has issues | |
| Completed | 2026-06-12 |
review-ietf-ipsecme-ikev2-downgrade-prevention-05-secdir-lc-rosomakho-2026-06-12-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This specification describes an extension to IKEv2 that prevents particular downgrade attacks. Minor issues: I found Section 7.2 incomplete. It requires the new mechanism to be used during IKE session resumption if it was used during the previous IKE SA establishment, but it does not specify the transcript to be signed or MAC'ed for the IKE_SESSION_RESUME exchange. I believe it would be beneficial to clarify the security properties when symmetric shared secrets are used for authentication. The security argument relies on at least one non-compromised authentication key being used. This is clear for asymmetric authentication, where compromise of one peer's private key does not imply compromise of the other peer's private key. However, when a single shared symmetric secret is used for authentication, compromise of that secret compromises both authentication directions. Nits: Some articles missing: Section 7.1: If peers support extension defined in this document -> If peers support the extension defined in this document Section 7.2: provides a client with session ticket -> provides a client with a session ticket Section 8: one of extensions -> one of the extensions Section 9: defines new Notify Message Type -> defines a new Notify Message Type Minor grammar: Section 7.2: each of parameter -> each parameter Section 7.2: it is RECOMMENDED that the host do not use -> it is RECOMMENDED that the host does not use Section 8: Note, that -> Note that