Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
Vukašin Karadžić <vukasin.karadzic@gmail.com> Fri, 25 August 2023 11:11 UTC
Return-Path: <vukasin.karadzic@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C61C151077 for <ipsec@ietfa.amsl.com>; Fri, 25 Aug 2023 04:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQv6SUQ0jufq for <ipsec@ietfa.amsl.com>; Fri, 25 Aug 2023 04:11:55 -0700 (PDT)
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05490C151075 for <ipsec@ietf.org>; Fri, 25 Aug 2023 04:11:54 -0700 (PDT)
Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-5633b7e5f90so511833eaf.1 for <ipsec@ietf.org>; Fri, 25 Aug 2023 04:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692961914; x=1693566714; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=h9iJDIX6FQtBZOW76g/WKyPPB5Oz+fJU7564wndGFy4=; b=Rs986i1Rbf4zgKczVbl0ChWeO7bwWdYpqbr7SWGfoulkVH7FJYjRC5gGJeJ2Spi453 XuEc8uWvi2Fd3KPEEzeiL7oHtpz/V5Skx+yz7nhvwe5lyYYO8kbw79NbGCVHifg6bPkb EfJ/wExF6INCtoAXWV1Ac7mPibS53ul4uFerpbwsdJyfDXZs1PIoNEdi/9DWJQKWUbXU SzGup470KfhyEe3rc49vVyvWBAOilU2sr23IAlYed3/RC/Xvnq1Lt9Bq2L2RZC4nkKWQ yK7KHut1eKmXec99Dl11zbGc7HEcUKDsZRnlF0JZ7RrRVEoBCa7sfnkbSWPuMk0G3kzL rjOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692961914; x=1693566714; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h9iJDIX6FQtBZOW76g/WKyPPB5Oz+fJU7564wndGFy4=; b=SLW+ntvrqj8kXd2AakA0TURTa8ZWGSAPK6DTzoBtzQ9e14HbdxlksJ+m4X9BlK4VtC D+p3RhBzlP/3tYH5LK/olV4pfN7TKjsKDvpVsz7O6udah0m67XmtCbedcLuNiLXUfbC7 /+1CFLOl2dSbDJKWdm2zXzY482PchL42w2dGJJn3GRgWX6Sz034vfcw/TgCbVHLIGfgF kTQpugBL7HeOa9Vf5Qr91azp+cfA/JHepzcNxR1MP0Ker5ljtaDMnyoWFj6liEJ3IJqt etDKI+kCXOnANuMwm3tFgWvlLneTm6WFIxnZGEHW5Zy4rHhGabAnv/20JerEb2eZjpzG tW6g==
X-Gm-Message-State: AOJu0YyWhehwDSDobb+8SmMpMKTBsykDK3HohqxIObdTHJhQn4oLnmvG ESM+NsFCqa4mE/lFh4cCUtZTmswArG6anCRAXnjsfcpmaVs=
X-Google-Smtp-Source: AGHT+IFVGkHYphWEAVlwkfASLrhaYQJNxJ2P/Z6K+J/De8UaiF2PswHkQ6RmSJo6db2CP/RI0qMSgzUi5QznjUqFFuo=
X-Received: by 2002:a4a:91c7:0:b0:56c:cd0c:1d67 with SMTP id e7-20020a4a91c7000000b0056ccd0c1d67mr4596721ooh.7.1692961913700; Fri, 25 Aug 2023 04:11:53 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.45.1692730802.11364.ipsec@ietf.org>
In-Reply-To: <mailman.45.1692730802.11364.ipsec@ietf.org>
From: Vukašin Karadžić <vukasin.karadzic@gmail.com>
Date: Fri, 25 Aug 2023 13:11:27 +0200
Message-ID: <CAEQ8ZZfrGvUzmQFOj+_MvyKwBXb7ZQNsSEbLgiksrSrcJwi4mg@mail.gmail.com>
To: ipsec@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007c07b40603bd694e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/mM8hq7cVbHhFKFzFAxU6vX7aYiU>
Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Fri, 25 Aug 2023 11:11:55 -0000
Hi, I agree with Rebecca's suggestion. Especially the first one, regarding introducing the USE_EARLY_PPK notify, since it seems the introduction would also make the implementation of the draft (combined with RFC 8784) 'cleaner'/easier to understand and verify. BTW. I support the adoption of the draft as well (there is a newer -08 version). Regards, Vukašin Karadžić уто, 22. авг 2023. у 21:01 <ipsec-request@ietf.org> је написао/ла: > Message: 1 > Date: Mon, 21 Aug 2023 21:25:08 +0000 > From: Rebecca Guthrie <rmguthr@uwe.nsa.gov> > To: Valery Smyslov <svan@elvis.ru>, IPsecME WG <ipsec@ietf.org> > Cc: "ipsec-chairs@ietf.org" <ipsec-chairs@ietf.org> > Subject: Re: [IPsec] New Version Notification for > draft-smyslov-ipsecme-ikev2-qr-alt-07.txt > Message-ID: > < > PH8PR09MB92945FAFF119DE5ABFE3601BFC1EA@PH8PR09MB9294.namprd09.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Greetings, > > I wrote to the mail list before IETF 117 that I support adoption of > draft-smyslov-ipsecme-ikev2-qr-alt, and I have comments I would like to > make. The draft did not get discussed at 117, so I'll share my comments > here. > > Comment: I suggest that the draft define a new Notify Payload, > USE_EARLY_PPK, that uniquely specifies support for this draft, rather than > relying on USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED. > > Explanation: There was agreement at the 116 meeting that the extension > specified in this draft should not be used in conjunction with RFC 8784. > The draft does allow for a fall-back to the PSK mechanism specified in RFC > 8784 if the mechanism specified in this draft is not supported by the > responder- this necessitates USE_PPK to be used ambiguously, such that its > inclusion by the initiator in IKE_SA_INIT can represent the initiator's > intent to do either (this draft's PSK mechanism or RFC 8784). > > However, since it is still possible that RFC 8784 and RFC 9242 are used > together, the inclusion of both USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED > does not uniquely specify this draft; rather, it could mean that an IKE > peer supports RFC 8784, plans to use IKE_INTERMEDIATE for another purpose, > and does not support this draft. > > There may be a time where certain IKEv2 instances require the use of this > draft such that the peer will abort the creation of the IKE SA if the > extension specified in this draft cannot be supported. The peer may require > the use of this draft either after transitioning away from RFC 8784, or > having never supported RFC 8784 at all. In either case, the initiator and > responder must be able to negotiate the use of this extension in > IKE_SA_INIT. As the draft is currently written, depending on assumptions > made by initiator and responder and depending on what is supported, they > are able to get all the way to the end of IKE_INTERMEDIATE before realizing > requirements cannot be met. > > In the case where the Initiator requires draft-smslov-ipsecme-ikev2-qr-alt > and RFC 9370, and the Responder supports RFC 8784 and RFC 9370, both will > include USE_PPK and INTERMEDIATE_EXCHANGE_SUPPORTED in their respective > IKE_SA_INIT messages, but the Initiator will not discover that it must > abandon the SA until it has computed all of the intermediate key exchanges > only to receive no response to its PPK_IDENTITY_KEY notification(s). > > On the other hand, if the Responder requires the use of this draft and the > Initiator instead supports RFC 8784, it is unclear what the responder > should do when it does not receive a PPK negotiation message from the > Initiator in the last IKE_INTERMEDIATE exchange. It is possible that the > Responder may be expecting another IKE_INTERMEDIATE message containing PPK > negotiation information, but if the Initiator does not support this > extension, then it would instead begin the IKE_AUTH exchange. > > Defining a new Notify Payload, USE_EARLY_PPK, that uniquely specifies > support for this draft would remove the described ambiguity. In order to > indicate support for the fall-back to RFC 8784 capability, the Initiator > would send both USE_PPK and USE_EARLY_PPK Notify Payloads. It should be the > case that when these are sent together, the preference for USE_EARLY_PPK is > implicit. If the responder also supports USE_EARLY_PPK, it will ignore > USE_PPK. If the responder does not support or does not recognize > USE_EARLY_PPK, it may still support USE_PPK, and can proceed with the PSK > mechanism described in RFC 8784. > > Comment: During IKE_INTERMEDIATE, use N(PPK_IDENTITY) in initiator message > and N(PPK_IDENTITY_KEY) in responder message, only for the single PPK the > responder has selected. > > Explanation: Currently, in the last IKE_INTERMEDIATE, the initiator sends > SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1) [ , ... , N(PPK_IDENTITY_KEY, > PPK_ID_n ) ] } where PPK_IDENTITY_KEY is sent for each PPK_ID the initiator > is offering. The responder then sends SK { N(PPK_IDENTITY) } for the PPK it > selects, using the N(PPK_IDENTITY) Notify Payload specified in RFC 8784. > > It's my understanding that the initiator and responder expect the PPKs to > match for any given PPK_ID (i.e. that there is a very high likelihood that > they match). If this assumption is incorrect, please correct me, but if > this is the case, in order to perform fewer computations and shrink the > size of the initiator message, it may make sense to use N(PPK_IDENTITY) > [RFC8784] in the initiator message, and the new N(PPK_IDENTITY_KEY) in the > responder message, only for the single PPK the responder has selected. > Then, before the initiator sends IKE_AUTH, it can use the confirmation > value sent by the responder in N(PPK_IDENTITY_KEY) to check that the PPK > values the initiator and responder are using match. (If they do not match, > the initiator could send another IKE_INTERMEDIATE containing > N(PPK_IDENTITY_KEY)s for each PPK it supports, as currently specified.) > Depending on how many PPKs the initiator offers, this may not considerably > shrink the message size. > > Comment: Update Security Considerations section. > > Explanation: The Security Considerations section currently cites RFC 8784. > I'd suggest that RFC 9242's security considerations be referenced as well, > and I'd suggest repeating some of the security considerations from RFC 9370 > that are relevant here- in particular, the second paragraph of RFC 9370 > discusses how to ensure quantum resistance in Transform Types 2 and 3- this > is worth repeating here, especially in the case that this draft is used > independently (without RFC 9370) to provide QR. > > In RFC 8784 and RFC 9370, there is discussion of the security of each > extension with regard to an active attacker- it may be useful in this draft > to extend this discussion here in order to cover 1. the addition of > IKE_INTERMEDIATE, 2. the fact that QR is achieved prior to IKE_AUTH (either > if this draft is used on its own or in conjunction with RFC 9370), and 3. > the fact that authentication is QR (compared to RFC 9370 alone). > > - Rebecca > > Rebecca Guthrie > she/her > Center for Cybersecurity Standards (CCSS) > Cybersecurity Collaboration Center (CCC) > National Security Agency (NSA) >
- Re: [IPsec] New Version Notification for draft-sm… Valery Smyslov
- Re: [IPsec] New Version Notification for draft-sm… Rebecca Guthrie
- Re: [IPsec] New Version Notification for draft-sm… Vukašin Karadžić
- Re: [IPsec] New Version Notification for draft-sm… Paul Wouters
- Re: [IPsec] New Version Notification for draft-sm… Valery Smyslov