[IPsec] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org> Sat, 30 March 2024 17:37 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 324B4C14F706; Sat, 30 Mar 2024 10:37:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ipsecme-ikev2-auth-announce.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171182022719.29877.1686113240622771941@ietfa.amsl.com>
Reply-To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Sat, 30 Mar 2024 10:37:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/-hd56HCwx1XGVQ4ZZJghmnwh6Co>
Subject: [IPsec] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2024 17:37:07 -0000

Reviewer: Rifaat Shekh-Yusef
Review result: Has Issues

# Section 3.1

* The description of the exchange seems odd, as it starts with the responder,
instead of the initiator. I suggest that the description of the exchange starts
with the initiator, followed by the responder.

* I think it would make it easier for the reader if you explicitly describe the
new notify payload. How about adding the following text to the beginning of
section 3.1?

"This specification introduces a new IKE_SA_INIT packets Notify payload of type
SUPPORTED_AUTH_METHODS. This payload is utilized to convey the supported
authentication methods of the party sending the message, thereby facilitating
the negotiation of authentication mechanisms during IKE SA establishment."

* "Since the responder sends the SUPPORTED_AUTH_METHODS notification in the
IKE_SA_INIT exchange, it must take care that the size of the response message
wouldn't grow too much so that IP fragmentation takes place."

Is this limited to the responder? or should the initiator too take that into
considerations?

# Section 5

Second paragraph: I guess the potential for downgrade attack is not limited to
the NULL use case. If one of the supported methods is consider to be weaker
than the others, then an active attacker in the path could force the parties to
use that weaker method.