Skip to main content

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