From nobody Mon Jan 3 12:50:47 2022 Return-Path: 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 604FC3A0CAB for ; Mon, 3 Jan 2022 12:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlpfXzWcVics for ; Mon, 3 Jan 2022 12:50:37 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720173A0C6D for ; Mon, 3 Jan 2022 12:50:36 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 9FB981B00220; Mon, 3 Jan 2022 22:50:32 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1641243032; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=+BHP4nNTNzBrdIF2miMZcsqzPH7r4BEaR7Z6EMPBaTc=; b=BEbv2gQ+cN1WdaBU7x+6IWWZv6gkItXOQ4wcGF4c0vsk1djvueZ2J5SClwoZ7IbqaWfiWd sVhrIBEVBKNuppsgv5EeRH41uHqmNZI9fw+enmf3+XuhOpiN3HOesSwrwABCcQ7KlJVzzu jvw334oe1Mutj2egJt2ssj0RfssBhaJmhA92eRUKuwb3bPDvzbvuCBqS3vOjcyTAACqZ/m qRiYJOsDxupli6fRFwZxIXtLV+I0SFppJaHN9J8pCjI7KZY8aI18D8vng5DURK8jCu3gTv ganVK2FQ/oEqFrsXdrXa/20MBtIbrTkT4pRh8wozvjbIVDLn7Fh8UBWFIxofyg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 46FE525C12E5; Mon, 3 Jan 2022 22:50:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25043.24983.210315.889945@fireball.acr.fi> Date: Mon, 3 Jan 2022 22:50:31 +0200 From: Tero Kivinen To: draft-corcoran-cnsa-ipsec-profile.all@datatracker.ietf.org, ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 42 min X-Total-Time: 47 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1641243032; a=rsa-sha256; cv=none; b=YJuySWxSgRZnNx+pqepM5/bpyoI7K/Ze4vyXhn0y6dT90ndSyqLLT6ZbienWznB0w9RUSk yeIUenHVcX7pT7m69lCLHomEZ++KVbT8ApqIkXFp0oW0iXT962FjWqJ8AZZrGvzq4Sf9kf OgXKbr5E1ZvxzaaMfcJHFwz6EiTwMxSnH60b6MDf7Rxl8wKYk8Uqso5Fd3p6oQ/LgjGmTe vRfN2/cNJ2cqOJ8d0PcFFjgcIdqpH+jWROgbOTNNF/NgcAvGUHRGlVyjDXhRcHKb/v4M4i aF9Iva8rURYcuvrHA61Y/34WnRnot+ukeAFRoQeB1erYzRP2QY1qsCCd4W9zUg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1641243032; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=+BHP4nNTNzBrdIF2miMZcsqzPH7r4BEaR7Z6EMPBaTc=; b=pWlbDaktCX0qoOW5FGxmn35pVd1XZ2oxOx+U2NoT28lccijhTRQAaprSi1cZvd20ctadCb WVUdwidMC7J0CsXFeAEeQVIjqABoTODlK06uCePZt9Anb+VOPuxhlZHk8taukT/TcMysYu AaMZUdE1MeHsQaXGTGzIZfnkccvzw2XXjZlB8gKoMNp4QESlyorPO301DgBZODz9rOXNLJ E3DspCfKzbAE6SWkAMwTPu2fyKRCKD9m9WSl4dLKaQ2a6AizE++SxqTVmeZeFuRftg+I2I K+dKtglnAVW+wXOGxbMQEjDbB+05m6Hhc8SVS2MzCpkWIDb80JLr9HcJfKbLMg== Archived-At: Subject: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 20:50:46 -0000 While doing IANA expert review on the document I found some issues with this document, so here are my comments to it. In section 5 there is text which says: In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST indicate the integrity algorithm NONE. [RFC7296] This does not match the recommendation for the RFC7296 which says in section 3.3: Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and MUST either offer no integrity algorithm or a single integrity algorithm of "NONE", with no integrity algorithm being the RECOMMENDED method. This would mean that this document if approved would make the recommended method of RFC7296 of no integrity algorithm not allowed by this draft. I do not think it is appropriate to this draft make such change, and I would propose to change the wording on the section 5 to match the RFC7296, i.e., say that it is RECOMMENDED that no integrity algorithm is being sent in proposal at all, but it is also allowed to send single integrity algorithm of "NONE". -- And then some nits: -- In the abstract there is unexpanded acronym NSA on first line. On the introduction this is spelled out but there is acronym (NSA) listed there, it is only included on the first line of section 3. Usually it would be best to include the full expanded version of the acronym on the first use, and then use the acronym, and also expand all acronyms in the abstract. -- >From section 5 forward the references to RFCs use bit funny format, where the reference is AFTER the period of the sentence. This makes it hard to parse the text, as some times you could assume that the reference refers to the next sentence not the previous one. For example the text: User Interface (UI) suites are named suites that cover some typical security policy options for IPsec. [RFC4308] Use of UI suites does not change the IPsec protocol in any way. does not make clear where the RFC4308 reference belongs. Looking that the text I think it belongs to the first sentence, so better format would be: User Interface (UI) suites are named suites that cover some typical security policy options for IPsec ([RFC4308]). Use of UI suites does not change the IPsec protocol in any way. (with or without parenthesis). Same with some other references in the document. -- In section 5.1, 5.2, 5.3, it would be good idea to explictly mention that ENCR_AES_GCM_16 is to be used with key size of 256 bits. This is already mentioned in the section 4, but implementors might just jump to section 5 and define suites from there, so changing: Encryption: ENCR_AES_GCM_16 to Encryption: ENCR_AES_GCM_16 (with key size of 256 bits) would make all information needed available in that section. -- I think we can still keep the Integrity: NONE even if we fix the section 5 to use the recommended way of not including integrity algorithm at all, as this should be clear enough. -- Section 6 is not really part of the UI suites, as they authentication is separate from the algorithm negotiation in the IKEv2, but I think including it here will make sense, but I wonder why text is written in such way that RSA with 3072-bit or 4096-bit modulus using SHA-512 is not allowed? I would have assumed that either SHA-384 or SHA-512 would have been good enough for RSA. With ECDSA I can see that match hash length with the group length, but that does not really apply with RSA. -- Section 7 has again text that changes RFC7296. RFC7296 section 3.5 explictly says that: This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; Text in section 7 says that: The identity authentication method MUST use an end-entity certificate provided by the authenticating party and MUST NOT use the Identification Payload for policy lookup. Usually implementations do so that they use the Identification Payload to find the matching Peer Authorization Database (PAD) entry and from there they can then find the rules how the certificates needs to be matched. The problem is that there is general way of taking certificate and getting some information there and matching that to PAD. The information in certificate can come from multiple locations, i.e., it might be Subject or from SubjectAltName etc. Usually what field is used depends on the policy, and the identification payload is used to find the PAD entry, and then PAD entry will tell that end entity certificate must have matching entry in for example SubjectAltName if the Identification payload happened to be ID_RFC822_ADDR. I have no idea how to implement section 7, i.e., how do I use the end-entity certificate provided by the authentication party to find policy... -- In section 11 there is bit more of this Identification payloads text, but I do not think it helps at all, just repeats the confusion: For CNSA compliant systems, the IKEv2 authentication method MUST use an end-entity certificate provided by the authenticating party. Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST NOT be used for the IKEv2 authentication method , but may be used for policy lookup. here it actually contradicts the section 7, which said "MUST NOT use the Identification Payload for policy lookup". -- In section 12 there is text: For all applications to which this section applies, PSK authentication MUST be performed using HMAC-SHA-384 [RFC4868]. which is contradicting section 6 which says that For CNSA compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. thus PSK is not allowed authentication method, so why specify MUST use HMAC-SHA-384 for authentication method which is not allowed? -- I do not think any of the issues affect the IANA allocations, thus I will go forward with that, but I would prefer that the authors would fix at least the issues where this document is not matching RFC7296, and perhaps clarify how the implementations are supposed to use the Identification payload and end entity certificate. -- kivinen@iki.fi From nobody Tue Jan 4 00:31:18 2022 Return-Path: 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 5F9233A1931 for ; Tue, 4 Jan 2022 00:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7W0NKCcA4Pt for ; Tue, 4 Jan 2022 00:31:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF0D3A192E for ; Tue, 4 Jan 2022 00:31:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 7FFE635223; Tue, 4 Jan 2022 00:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxhSv_5-uaXp; Tue, 4 Jan 2022 00:31:08 -0800 (PST) Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 7F94E35220; Tue, 4 Jan 2022 00:31:08 -0800 (PST) Received: from 148.252.133.182 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Tue, 4 Jan 2022 08:31:08 -0000 Message-ID: <9fd1c9c7369d5635ad2187e30c9771ff.squirrel@www.rfc-editor.org> Date: Tue, 4 Jan 2022 08:31:08 -0000 From: "RFC ISE (Adrian Farrel)" To: "Tero Kivinen" Cc: draft-corcoran-cnsa-ipsec-profile.all@datatracker.ietf.org, ipsec@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 08:31:15 -0000 Thanks Tero, much appreciated. I will discuss this with the authors. It is sometimes the case that this type of document (i.e. an NSA profile), tightens the 2119 language from the referenced RFCs or removes options. The argument in the past has been that, while the base spec gives some degree of permissible variance, the specific deployment environment requires particular behavior. (FYI, these documents *never* relax the 2119 language.) Nevertheless, I will check that the authors intended this behavior and flag it to the responsible AD for confirmation. Best, Adrian Tero Kivinen wrote: > While doing IANA expert review on the document I found some issues > with this document, so here are my comments to it. > > In section 5 there is text which says: > > In particular, since AES-GCM is an AEAD > algorithm, ESP implementing AES-GCM MUST indicate the integrity > algorithm NONE. [RFC7296] > > This does not match the recommendation for the RFC7296 which says in > section 3.3: > > Combined-mode ciphers include > both integrity and encryption in a single encryption algorithm, and > MUST either offer no integrity algorithm or a single integrity > algorithm of "NONE", with no integrity algorithm being the > RECOMMENDED method. > > This would mean that this document if approved would make the > recommended method of RFC7296 of no integrity algorithm not allowed by > this draft. > > I do not think it is appropriate to this draft make such change, and I > would propose to change the wording on the section 5 to match the > RFC7296, i.e., say that it is RECOMMENDED that no integrity algorithm > is being sent in proposal at all, but it is also allowed to send > single integrity algorithm of "NONE". > > -- > > And then some nits: > > -- > > In the abstract there is unexpanded acronym NSA on first line. On the > introduction this is spelled out but there is acronym (NSA) listed > there, it is only included on the first line of section 3. Usually it > would be best to include the full expanded version of the acronym on > the first use, and then use the acronym, and also expand all acronyms > in the abstract. > > -- > >>From section 5 forward the references to RFCs use bit funny format, > where the reference is AFTER the period of the sentence. This makes it > hard to parse the text, as some times you could assume that the > reference refers to the next sentence not the previous one. > > For example the text: > > User Interface (UI) suites are named suites that cover some typical > security policy options for IPsec. [RFC4308] Use of UI suites does > not change the IPsec protocol in any way. > > does not make clear where the RFC4308 reference belongs. Looking that > the text I think it belongs to the first sentence, so better format > would be: > > > User Interface (UI) suites are named suites that cover some typical > security policy options for IPsec ([RFC4308]). Use of UI suites does > not change the IPsec protocol in any way. > > (with or without parenthesis). > > Same with some other references in the document. > > -- > > In section 5.1, 5.2, 5.3, it would be good idea to explictly mention > that ENCR_AES_GCM_16 is to be used with key size of 256 bits. This is > already mentioned in the section 4, but implementors might just jump > to section 5 and define suites from there, so changing: > > Encryption: ENCR_AES_GCM_16 > > to > > Encryption: ENCR_AES_GCM_16 (with key size of 256 bits) > > would make all information needed available in that section. > > -- > > I think we can still keep the > > Integrity: NONE > > even if we fix the section 5 to use the recommended way of not > including integrity algorithm at all, as this should be clear enough. > > -- > > Section 6 is not really part of the UI suites, as they authentication > is separate from the algorithm negotiation in the IKEv2, but I think > including it here will make sense, but I wonder why text is written in > such way that RSA with 3072-bit or 4096-bit modulus using SHA-512 is > not allowed? I would have assumed that either SHA-384 or SHA-512 would > have been good enough for RSA. > > With ECDSA I can see that match hash length with the group length, but > that does not really apply with RSA. > > -- > > Section 7 has again text that changes RFC7296. > > RFC7296 section 3.5 explictly says that: > > This identity may > be used for policy lookup, but does not necessarily have to match > anything in the CERT payload; > > Text in section 7 says that: > > The identity authentication > method MUST use an end-entity certificate provided by the > authenticating party and MUST NOT use the Identification Payload for > policy lookup. > > > Usually implementations do so that they use the Identification Payload > to find the matching Peer Authorization Database (PAD) entry and from > there they can then find the rules how the certificates needs to be > matched. > > The problem is that there is general way of taking certificate and > getting some information there and matching that to PAD. The > information in certificate can come from multiple locations, i.e., it > might be Subject or from SubjectAltName etc. Usually what field is > used depends on the policy, and the identification payload is used to > find the PAD entry, and then PAD entry will tell that end entity > certificate must have matching entry in for example SubjectAltName if > the Identification payload happened to be ID_RFC822_ADDR. > > I have no idea how to implement section 7, i.e., how do I use the > end-entity certificate provided by the authentication party to find > policy... > > -- > > In section 11 there is bit more of this Identification payloads text, > but I do not think it helps at all, just repeats the confusion: > > For CNSA compliant systems, the IKEv2 authentication method MUST use > an end-entity certificate provided by the authenticating party. > Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST > NOT be used for the IKEv2 authentication method , but may be used for > policy lookup. > > here it actually contradicts the section 7, which said "MUST NOT use > the Identification Payload for policy lookup". > > -- > > In section 12 there is text: > > For all applications to which this section applies, PSK > authentication MUST be performed using HMAC-SHA-384 [RFC4868]. > > which is contradicting section 6 which says that > > > For CNSA compliant systems, authentication methods other than > ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. > > thus PSK is not allowed authentication method, so why specify MUST use > HMAC-SHA-384 for authentication method which is not allowed? > > -- > > I do not think any of the issues affect the IANA allocations, thus I > will go forward with that, but I would prefer that the authors would > fix at least the issues where this document is not matching RFC7296, > and perhaps clarify how the implementations are supposed to use the > Identification payload and end entity certificate. > -- > kivinen@iki.fi > -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Tue Jan 4 00:32:46 2022 Return-Path: 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 7E8143A193A; Tue, 4 Jan 2022 00:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zEYV5gnf_2I; Tue, 4 Jan 2022 00:32:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AF63A1936; Tue, 4 Jan 2022 00:32:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4573235223; Tue, 4 Jan 2022 00:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHPeLT1TOveQ; Tue, 4 Jan 2022 00:32:39 -0800 (PST) Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 6C1FB35220; Tue, 4 Jan 2022 00:32:39 -0800 (PST) Received: from 148.252.133.182 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Tue, 4 Jan 2022 08:32:39 -0000 Message-ID: In-Reply-To: <9fd1c9c7369d5635ad2187e30c9771ff.squirrel@www.rfc-editor.org> References: <9fd1c9c7369d5635ad2187e30c9771ff.squirrel@www.rfc-editor.org> Date: Tue, 4 Jan 2022 08:32:39 -0000 From: "RFC ISE (Adrian Farrel)" To: rfc-ise@rfc-editor.org Cc: "Tero Kivinen" , draft-corcoran-cnsa-ipsec-profile.all@ietf.org, ipsec@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 08:32:45 -0000 Resend with corrected email alias Adrian RFC ISE (Adrian Farrel) wrote: > Thanks Tero, much appreciated. > > I will discuss this with the authors. > > It is sometimes the case that this type of document (i.e. an NSA profile), > tightens the 2119 language from the referenced RFCs or removes options. > The argument in the past has been that, while the base spec gives some > degree of permissible variance, the specific deployment environment > requires particular behavior. > > (FYI, these documents *never* relax the 2119 language.) > > Nevertheless, I will check that the authors intended this behavior and > flag it to the responsible AD for confirmation. > > Best, > Adrian > > > Tero Kivinen wrote: >> While doing IANA expert review on the document I found some issues >> with this document, so here are my comments to it. >> >> In section 5 there is text which says: >> >> In particular, since AES-GCM is an AEAD >> algorithm, ESP implementing AES-GCM MUST indicate the integrity >> algorithm NONE. [RFC7296] >> >> This does not match the recommendation for the RFC7296 which says in >> section 3.3: >> >> Combined-mode ciphers include >> both integrity and encryption in a single encryption algorithm, and >> MUST either offer no integrity algorithm or a single integrity >> algorithm of "NONE", with no integrity algorithm being the >> RECOMMENDED method. >> >> This would mean that this document if approved would make the >> recommended method of RFC7296 of no integrity algorithm not allowed by >> this draft. >> >> I do not think it is appropriate to this draft make such change, and I >> would propose to change the wording on the section 5 to match the >> RFC7296, i.e., say that it is RECOMMENDED that no integrity algorithm >> is being sent in proposal at all, but it is also allowed to send >> single integrity algorithm of "NONE". >> >> -- >> >> And then some nits: >> >> -- >> >> In the abstract there is unexpanded acronym NSA on first line. On the >> introduction this is spelled out but there is acronym (NSA) listed >> there, it is only included on the first line of section 3. Usually it >> would be best to include the full expanded version of the acronym on >> the first use, and then use the acronym, and also expand all acronyms >> in the abstract. >> >> -- >> >>>From section 5 forward the references to RFCs use bit funny format, >> where the reference is AFTER the period of the sentence. This makes it >> hard to parse the text, as some times you could assume that the >> reference refers to the next sentence not the previous one. >> >> For example the text: >> >> User Interface (UI) suites are named suites that cover some typical >> security policy options for IPsec. [RFC4308] Use of UI suites does >> not change the IPsec protocol in any way. >> >> does not make clear where the RFC4308 reference belongs. Looking that >> the text I think it belongs to the first sentence, so better format >> would be: >> >> >> User Interface (UI) suites are named suites that cover some typical >> security policy options for IPsec ([RFC4308]). Use of UI suites does >> not change the IPsec protocol in any way. >> >> (with or without parenthesis). >> >> Same with some other references in the document. >> >> -- >> >> In section 5.1, 5.2, 5.3, it would be good idea to explictly mention >> that ENCR_AES_GCM_16 is to be used with key size of 256 bits. This is >> already mentioned in the section 4, but implementors might just jump >> to section 5 and define suites from there, so changing: >> >> Encryption: ENCR_AES_GCM_16 >> >> to >> >> Encryption: ENCR_AES_GCM_16 (with key size of 256 bits) >> >> would make all information needed available in that section. >> >> -- >> >> I think we can still keep the >> >> Integrity: NONE >> >> even if we fix the section 5 to use the recommended way of not >> including integrity algorithm at all, as this should be clear enough. >> >> -- >> >> Section 6 is not really part of the UI suites, as they authentication >> is separate from the algorithm negotiation in the IKEv2, but I think >> including it here will make sense, but I wonder why text is written in >> such way that RSA with 3072-bit or 4096-bit modulus using SHA-512 is >> not allowed? I would have assumed that either SHA-384 or SHA-512 would >> have been good enough for RSA. >> >> With ECDSA I can see that match hash length with the group length, but >> that does not really apply with RSA. >> >> -- >> >> Section 7 has again text that changes RFC7296. >> >> RFC7296 section 3.5 explictly says that: >> >> This identity may >> be used for policy lookup, but does not necessarily have to match >> anything in the CERT payload; >> >> Text in section 7 says that: >> >> The identity authentication >> method MUST use an end-entity certificate provided by the >> authenticating party and MUST NOT use the Identification Payload for >> policy lookup. >> >> >> Usually implementations do so that they use the Identification Payload >> to find the matching Peer Authorization Database (PAD) entry and from >> there they can then find the rules how the certificates needs to be >> matched. >> >> The problem is that there is general way of taking certificate and >> getting some information there and matching that to PAD. The >> information in certificate can come from multiple locations, i.e., it >> might be Subject or from SubjectAltName etc. Usually what field is >> used depends on the policy, and the identification payload is used to >> find the PAD entry, and then PAD entry will tell that end entity >> certificate must have matching entry in for example SubjectAltName if >> the Identification payload happened to be ID_RFC822_ADDR. >> >> I have no idea how to implement section 7, i.e., how do I use the >> end-entity certificate provided by the authentication party to find >> policy... >> >> -- >> >> In section 11 there is bit more of this Identification payloads text, >> but I do not think it helps at all, just repeats the confusion: >> >> For CNSA compliant systems, the IKEv2 authentication method MUST use >> an end-entity certificate provided by the authenticating party. >> Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST >> NOT be used for the IKEv2 authentication method , but may be used for >> policy lookup. >> >> here it actually contradicts the section 7, which said "MUST NOT use >> the Identification Payload for policy lookup". >> >> -- >> >> In section 12 there is text: >> >> For all applications to which this section applies, PSK >> authentication MUST be performed using HMAC-SHA-384 [RFC4868]. >> >> which is contradicting section 6 which says that >> >> >> For CNSA compliant systems, authentication methods other than >> ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. >> >> thus PSK is not allowed authentication method, so why specify MUST use >> HMAC-SHA-384 for authentication method which is not allowed? >> >> -- >> >> I do not think any of the issues affect the IANA allocations, thus I >> will go forward with that, but I would prefer that the authors would >> fix at least the issues where this document is not matching RFC7296, >> and perhaps clarify how the implementations are supposed to use the >> Identification payload and end entity certificate. >> -- >> kivinen@iki.fi >> > > > -- > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org > -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Tue Jan 4 12:14:04 2022 Return-Path: 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 D1F3F3A0AEF for ; Tue, 4 Jan 2022 12:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfkgVQM6VaEm for ; Tue, 4 Jan 2022 12:13:58 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFA03A0AB9 for ; Tue, 4 Jan 2022 12:13:58 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0R570NMFUC79YH@wwwlocal.goatley.com> for ipsec@ietf.org; Tue, 04 Jan 2022 14:13:57 -0600 (CST) Received: from [10.74.74.210] (69-12-173-8.static.dsltransport.net [69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0R5700J5JC27LD@trixy.bergandi.net> for ipsec@ietf.org; Tue, 04 Jan 2022 12:10:56 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO [10.74.74.210]) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 04 Jan 2022 12:10:56 -0800 Date: Tue, 04 Jan 2022 12:13:55 -0800 From: Dan Harkins In-reply-to: To: ipsec@ietf.org Message-id: <93173a3f-4954-09b6-cca3-b7f984e7daa1@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO [10.74.74.210]) References: <9fd1c9c7369d5635ad2187e30c9771ff.squirrel@www.rfc-editor.org> X-PMAS-Software: PreciseMail V3.3 [211223] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 20:14:03 -0000   Hello,   I agree with Tero here. This "tightening" is not necessary. There's no security benefit by disallowing the RFC 7296 RECOMMENDED method of treating AEAD ciphers. The only thing this will do is require pointless changes to existing RFC 7296 compliant implementations.   regards,   Dan. On 1/4/22 12:32 AM, RFC ISE (Adrian Farrel) wrote: > Resend with corrected email alias > > Adrian > > RFC ISE (Adrian Farrel) wrote: >> Thanks Tero, much appreciated. >> >> I will discuss this with the authors. >> >> It is sometimes the case that this type of document (i.e. an NSA profile), >> tightens the 2119 language from the referenced RFCs or removes options. >> The argument in the past has been that, while the base spec gives some >> degree of permissible variance, the specific deployment environment >> requires particular behavior. >> >> (FYI, these documents *never* relax the 2119 language.) >> >> Nevertheless, I will check that the authors intended this behavior and >> flag it to the responsible AD for confirmation. >> >> Best, >> Adrian >> >> >> Tero Kivinen wrote: >>> While doing IANA expert review on the document I found some issues >>> with this document, so here are my comments to it. >>> >>> In section 5 there is text which says: >>> >>> In particular, since AES-GCM is an AEAD >>> algorithm, ESP implementing AES-GCM MUST indicate the integrity >>> algorithm NONE. [RFC7296] >>> >>> This does not match the recommendation for the RFC7296 which says in >>> section 3.3: >>> >>> Combined-mode ciphers include >>> both integrity and encryption in a single encryption algorithm, and >>> MUST either offer no integrity algorithm or a single integrity >>> algorithm of "NONE", with no integrity algorithm being the >>> RECOMMENDED method. >>> >>> This would mean that this document if approved would make the >>> recommended method of RFC7296 of no integrity algorithm not allowed by >>> this draft. >>> >>> I do not think it is appropriate to this draft make such change, and I >>> would propose to change the wording on the section 5 to match the >>> RFC7296, i.e., say that it is RECOMMENDED that no integrity algorithm >>> is being sent in proposal at all, but it is also allowed to send >>> single integrity algorithm of "NONE". >>> >>> -- >>> >>> And then some nits: >>> >>> -- >>> >>> In the abstract there is unexpanded acronym NSA on first line. On the >>> introduction this is spelled out but there is acronym (NSA) listed >>> there, it is only included on the first line of section 3. Usually it >>> would be best to include the full expanded version of the acronym on >>> the first use, and then use the acronym, and also expand all acronyms >>> in the abstract. >>> >>> -- >>> >>> >From section 5 forward the references to RFCs use bit funny format, >>> where the reference is AFTER the period of the sentence. This makes it >>> hard to parse the text, as some times you could assume that the >>> reference refers to the next sentence not the previous one. >>> >>> For example the text: >>> >>> User Interface (UI) suites are named suites that cover some typical >>> security policy options for IPsec. [RFC4308] Use of UI suites does >>> not change the IPsec protocol in any way. >>> >>> does not make clear where the RFC4308 reference belongs. Looking that >>> the text I think it belongs to the first sentence, so better format >>> would be: >>> >>> >>> User Interface (UI) suites are named suites that cover some typical >>> security policy options for IPsec ([RFC4308]). Use of UI suites does >>> not change the IPsec protocol in any way. >>> >>> (with or without parenthesis). >>> >>> Same with some other references in the document. >>> >>> -- >>> >>> In section 5.1, 5.2, 5.3, it would be good idea to explictly mention >>> that ENCR_AES_GCM_16 is to be used with key size of 256 bits. This is >>> already mentioned in the section 4, but implementors might just jump >>> to section 5 and define suites from there, so changing: >>> >>> Encryption: ENCR_AES_GCM_16 >>> >>> to >>> >>> Encryption: ENCR_AES_GCM_16 (with key size of 256 bits) >>> >>> would make all information needed available in that section. >>> >>> -- >>> >>> I think we can still keep the >>> >>> Integrity: NONE >>> >>> even if we fix the section 5 to use the recommended way of not >>> including integrity algorithm at all, as this should be clear enough. >>> >>> -- >>> >>> Section 6 is not really part of the UI suites, as they authentication >>> is separate from the algorithm negotiation in the IKEv2, but I think >>> including it here will make sense, but I wonder why text is written in >>> such way that RSA with 3072-bit or 4096-bit modulus using SHA-512 is >>> not allowed? I would have assumed that either SHA-384 or SHA-512 would >>> have been good enough for RSA. >>> >>> With ECDSA I can see that match hash length with the group length, but >>> that does not really apply with RSA. >>> >>> -- >>> >>> Section 7 has again text that changes RFC7296. >>> >>> RFC7296 section 3.5 explictly says that: >>> >>> This identity may >>> be used for policy lookup, but does not necessarily have to match >>> anything in the CERT payload; >>> >>> Text in section 7 says that: >>> >>> The identity authentication >>> method MUST use an end-entity certificate provided by the >>> authenticating party and MUST NOT use the Identification Payload for >>> policy lookup. >>> >>> >>> Usually implementations do so that they use the Identification Payload >>> to find the matching Peer Authorization Database (PAD) entry and from >>> there they can then find the rules how the certificates needs to be >>> matched. >>> >>> The problem is that there is general way of taking certificate and >>> getting some information there and matching that to PAD. The >>> information in certificate can come from multiple locations, i.e., it >>> might be Subject or from SubjectAltName etc. Usually what field is >>> used depends on the policy, and the identification payload is used to >>> find the PAD entry, and then PAD entry will tell that end entity >>> certificate must have matching entry in for example SubjectAltName if >>> the Identification payload happened to be ID_RFC822_ADDR. >>> >>> I have no idea how to implement section 7, i.e., how do I use the >>> end-entity certificate provided by the authentication party to find >>> policy... >>> >>> -- >>> >>> In section 11 there is bit more of this Identification payloads text, >>> but I do not think it helps at all, just repeats the confusion: >>> >>> For CNSA compliant systems, the IKEv2 authentication method MUST use >>> an end-entity certificate provided by the authenticating party. >>> Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST >>> NOT be used for the IKEv2 authentication method , but may be used for >>> policy lookup. >>> >>> here it actually contradicts the section 7, which said "MUST NOT use >>> the Identification Payload for policy lookup". >>> >>> -- >>> >>> In section 12 there is text: >>> >>> For all applications to which this section applies, PSK >>> authentication MUST be performed using HMAC-SHA-384 [RFC4868]. >>> >>> which is contradicting section 6 which says that >>> >>> >>> For CNSA compliant systems, authentication methods other than >>> ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. >>> >>> thus PSK is not allowed authentication method, so why specify MUST use >>> HMAC-SHA-384 for authentication method which is not allowed? >>> >>> -- >>> >>> I do not think any of the issues affect the IANA allocations, thus I >>> will go forward with that, but I would prefer that the authors would >>> fix at least the issues where this document is not matching RFC7296, >>> and perhaps clarify how the implementations are supposed to use the >>> Identification payload and end entity certificate. >>> -- >>> kivinen@iki.fi >>> >> >> -- >> Adrian Farrel (ISE), >> rfc-ise@rfc-editor.org >> > -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Wed Jan 5 07:01:35 2022 Return-Path: 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 27BCD3A0B3C for ; Wed, 5 Jan 2022 07:01:34 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG57fgt3FA6i for ; Wed, 5 Jan 2022 07:01:29 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7B53A0B3D for ; Wed, 5 Jan 2022 07:01:29 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JTXkG6G9Jz35D for ; Wed, 5 Jan 2022 16:01:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1641394886; bh=4vu5YvqvvjVg4QljSIHR/4XpS2YKtI+J0FhauNxhhDY=; h=Date:From:To:Subject:In-Reply-To:References; b=BIVwg7cRcr9sKqMHd74RAL1G+folqfb90I+DmeSOw8TssHObbABDxq0egez48SImJ Q6nhLTqM23n+/GQqAyQtGWqCcKum7VWYZcf3rGHofLQHoPoIaGicwG3P+G+u37KKOX X1tLLpnp7NrvHLkXt+vCXvZJtBW+QKjYEchEgB1o= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gkAA_cMaezwA for ; Wed, 5 Jan 2022 16:01:24 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 5 Jan 2022 16:01:24 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6CCDC1E95D1; Wed, 5 Jan 2022 10:01:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6B9CA1E95D0 for ; Wed, 5 Jan 2022 10:01:23 -0500 (EST) Date: Wed, 5 Jan 2022 10:01:23 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <93173a3f-4954-09b6-cca3-b7f984e7daa1@lounge.org> Message-ID: <9679f119-378a-f750-f019-5b21388e1@nohats.ca> References: <9fd1c9c7369d5635ad2187e30c9771ff.squirrel@www.rfc-editor.org> <93173a3f-4954-09b6-cca3-b7f984e7daa1@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 15:01:34 -0000 On Tue, 4 Jan 2022, Dan Harkins wrote: >   I agree with Tero here. This "tightening" is not necessary. There's no > security > benefit by disallowing the RFC 7296 RECOMMENDED method of treating AEAD > ciphers. > The only thing this will do is require pointless changes to existing RFC 7296 > compliant implementations. I also agree. While I wish we had only one way of specifing an AEAD without integrity algorithm instead of two, the ship sailed long ago and code is there do deal with both of these. There is no gain from restricting it. Paul From nobody Sun Jan 9 19:42:59 2022 Return-Path: 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 2711A3A0C40 for ; Sun, 9 Jan 2022 19:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFsV-f4sbG7Y for ; Sun, 9 Jan 2022 19:42:53 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714FA3A0C3B for ; Sun, 9 Jan 2022 19:42:53 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id u21so25653882edd.5 for ; Sun, 09 Jan 2022 19:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:subject:message-id:mime-version; bh=TUKRETawA0wCSXWMjZsg2BHif4kiaE73omjfgFNmw3g=; b=bocEArDLr2aClRfmyaoA0Q3ab6LwVMQF5s9k5mXoT1MqXIRzbuMXrLhp/X20BzPX9C q3sbyOZVY2E64QYopC/u4YEhMK/NRRqieWbGJ/HIUht3gD8kWQaYzy9eC2pwYN6QJ9LR HI9qZJ+//JbthOPzySz/yIII5WWbRMSI1ARnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version; bh=TUKRETawA0wCSXWMjZsg2BHif4kiaE73omjfgFNmw3g=; b=44+GBZ5vJxdgbuv7ydXGAmubOz6VZS73oxG8qljkC7i8aa+jiNfW3rs2Bqup0/1Nd5 OM8C/1aFNe8TreEML3H2TRbl5ny7Us4xAgKft4x7IT47wPi2yM4+ZbbLvlkOLZ8sd6he AglYVweSLP0XHzVBRekPSOpwtKarOdbq2AUSg0l1YRNdopgeelDEkVL9q34SEv8Yr0/Z Z6ClNZoxgciFV8Cd4L9HUXwq/LroEIsnw7ttNlksRcbNBaw0SEh7zKkZUnW5HN7Xe0Qm pVo/lwTGlin/tFAK/GZmva4zrNP2GzKAHfZdN4RAac10swCmHFsf8WecyarHotfQIq5T yeyg== X-Gm-Message-State: AOAM532EYjHPUz973XvfnPzsZaDZnFfAyWcSYbwyNpyaMpIJYdYibsF+ LCHiRiMYbAmR0sY9tldfKK1UTXIPWVlIGGhe/HA= X-Google-Smtp-Source: ABdhPJzGeeRhG3iIgqfL2n+420sOcK+P0jPv4WxBX772TkraZb19lx2VlacVT+zjNTIIPBTAJmxZ/A== X-Received: by 2002:a17:906:35db:: with SMTP id p27mr6520386ejb.143.1641786169774; Sun, 09 Jan 2022 19:42:49 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id eb14sm2867237edb.16.2022.01.09.19.42.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jan 2022 19:42:49 -0800 (PST) Date: Sun, 9 Jan 2022 22:42:43 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 03:42:58 -0000 I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and RFC 8229. I agree with most of these changes. I have some comments below. If others want to compare the draft with the RFC, see: https://nohats.ca/draft-ietf-ipsecme-rfc8229bis-01-from-rfc8229.diff.html that may block IKE negotiation over UDP. I would say: that may not transport IKE negotiation over UDP. Blocking sounds like an active administrative action. Most networks just accidentally happen to not pass UDP. I might also change "for traversing network middleboxes" to be more neutral, eg "in case routers or network middleboxes do not handle UDP". o if the Responder chooses to send Cookie request (possibly along with Puzzle request), then the TCP connection that the IKE_SA_INIT request message was received over SHOULD be closed, so that the Responder remains stateless at least until the Cookie (or Puzzle Solution) is returned. Note that if this TCP connection is closed, the Responder MUST NOT include the Initiator's TCP port into the Cookie calculation (*), since the Cookie will be returned over a new TCP connection with a different port. I am not sure this is a good idea. Tearing down and requiring a new 3way handshake just to deliver the cookie seems useless. What is wrong with using the existing TCP stream to reply? This might also make the code more complex, as currently, the TCP state is kept during the entire negotiation. Additionally, a NAT router could give the client a different IP address for a new TCP stream, making the COOKIE invalid. Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for additional messages in case it receives error notification from the Responder in the IKE_SA_INIT exchange. This is true, but the code handlling this might not be aware of the transport used. I'd rather see "an Initiator MAY skip the waiting time for additional messages" so that this advice becomes "a good idea" and not a "RFC violation" if not done. 7.6. Keep-Alives and Dead Peer Detection This section tells us to not send NAT keepalives. It also tells us to not rely on TCP keepalives. That left me puzzled on how to ensure the peer is alive until I remembered that NAT keepalives are not the same as IKE keepalives. I would briefly mention in this section that IKE keepalives should be used "as normal". Implementations that implement both MOBIKE and TCP encapsulation MUST support dynamically enabling and disabling TCP encapsulation as interfaces change. I'm not sure of the MUST here. Nice for sure, but perhaps the implementation supports MOBIKE or TCP and not both at once ? Perhaps restate as "if MOBIKE and TCP encapsulation are allowed for a configuration, the implementation MUST support ...... In case of TCP the NO_NATS_ALLOWED notification SHOULD be ignored because TCP generally has no problems with NAT boxes. I would re-state it as: In case of TCP the NO_NATS_ALLOWED notification MUST be ignored. Although, re-reading why NO_NATS_ALLOWED was introduced, I think in general this payload should be retired entirely, both for UDP and TCP. (disclosure: libreswan completely ignores it) 8.3. IKEv2 Session Resumption This section says that if a TCP encap session was suspended, that the client MUST use TCP to resume this. I don't understand why. It is likely that a resuming client has moved networks, and might be on a network that would properly support ESP or ESPinUDP. The resumption is really mostly meant to skip over DH and AUTH phases as these are costly. I see no reason to tie the transport to this. If I missed a valid reason for this to be needed, clarify what needs to happen when the server no longer can or wants to resume the session. Does the client close the TCP and go back to UDP? NITS: This document updates specification for change to: This document updates the specification for MOBIKE protocol, that allows IKEv2 SA change to: The MOBIKE protocol that allows SA's New INFORMATIONAL exchange MUST NOT bestarted in this situation. change to: A new INFORMATIONAL exchange MUST NOT bestarted in this situation. (or maybe say something like "the INFORMATIONAL exchange is then retransmitted over TCP") Since switching from UDP to TCP happens can occur during a single INFORMATIONAL message exchange, change to: Since switching from UDP to TCP can happen during a single INFORMATIONAL message exchange, MOBIKE protocol defined the NO_NATS_ALLOWED change to: The MOBIKE protocol defines the NO_NATS_ALLOWED From nobody Mon Jan 10 01:03:05 2022 Return-Path: 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 C2D273A08BF; Mon, 10 Jan 2022 01:02:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <164180537869.14649.10907386259780191988@ietfa.amsl.com> Date: Mon, 10 Jan 2022 01:02:58 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 09:02:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Group Key Management using IKEv2 Authors : Valery Smyslov Brian Weis Filename : draft-ietf-ipsecme-g-ikev2-04.txt Pages : 60 Date : 2022-01-10 Abstract: This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Jan 10 01:05:55 2022 Return-Path: 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 417C83A08D2 for ; Mon, 10 Jan 2022 01:05:53 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JznlI07fHk5O for ; Mon, 10 Jan 2022 01:05:48 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBD93A08D6 for ; Mon, 10 Jan 2022 01:05:48 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id g26so41830121lfv.11 for ; Mon, 10 Jan 2022 01:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=SP0EO6+1bubTVuTisJO59QjmJs15RfocIl94NwhYTZc=; b=UCmFV6JmdOQE7/Pi0beVEalOKo5Yk3eB9K2LqbmEWI2SAydR+pVpjQo8k7EmHWUYL2 X9YGF2u1p2joFQmtembFwuzq8+zsmXgkYbwxyYvFn21bnpQ0nABnSBJHlHTGR/7FUSOT I8WS6TRqG5JCW6/pOpgS+csb0Bf1RIeXLuGreRmGAUcx+O/8itJ9NFXArlihF1F13VPU arI4XAH9j42Fl+/1dCu7PVaaXDoXj8Y/vC43ThHgLNbkta9OS+VHxt7edl23RcSj5Bzc e+qOmeJfKgDBwVS1HY91C4wRwy65MjTUrGXCzqTXPXqnMUAoUPHQinanbKIdcJ17OAtl kDeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=SP0EO6+1bubTVuTisJO59QjmJs15RfocIl94NwhYTZc=; b=w+EPlw3cBgFKegXAyT8ZwjLVIU7HXVrtDO9Eojwm4vzpTc57YrLZxp0YNqIWfL+P2S 8P23iRJz1ZbejwzPN5AMu3dML10Qzkm0VnMHB+HRS7og8OjKTn5TyP5acAmJ4Gi6EmLg B2K22gUkpO5mX5oPdAV8vnmh5TghG4psK2uIlzd45KhcSBoS3nhN87aRTF4FD/timctC mfjGIOrc6AIoaxdFI+oXXkL6Oso4y2z8o1fh8SvsVIqGNUTvMSXGUCgIwj8ykfSes5QT D0TIX1dV/Tz4VHEcJa4Vg1DdN1vOlvNT/JsER7uKOh4vmt6nIofH4wvKiJS//K8w70uZ lReg== X-Gm-Message-State: AOAM532h/TaKFQghqqcSsai4CKO99qHjkjJSDBBfS+1gPmPpsoNIrQpT 1VqmdkPtATgPMLcW3QM/prGYUptbh3k= X-Google-Smtp-Source: ABdhPJwzq6m8CXchtAvPBACaU/0i5tT7hdrYUE6/YRwMMNSVcd2GjRn634UvXVIj/C3ILkvM95H5tQ== X-Received: by 2002:a2e:9e86:: with SMTP id f6mr26831ljk.428.1641805545473; Mon, 10 Jan 2022 01:05:45 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id bu10sm961789lfb.145.2022.01.10.01.05.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jan 2022 01:05:45 -0800 (PST) From: "Valery Smyslov" To: References: <164180537869.14649.10907386259780191988@ietfa.amsl.com> In-Reply-To: <164180537869.14649.10907386259780191988@ietfa.amsl.com> Date: Mon, 10 Jan 2022 12:05:44 +0300 Message-ID: <023401d80601$407d7f50$c1787df0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHb1YAPj6qUGZCDuEfQ8LZho2osMqxUVzWA Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 09:05:53 -0000 Hi, a new version of the draft contains no changes - just to prevent draft expiration. Regards, Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Group Key Management using IKEv2 > Authors : Valery Smyslov > Brian Weis > Filename : draft-ietf-ipsecme-g-ikev2-04.txt > Pages : 60 > Date : 2022-01-10 > > Abstract: > This document presents an extension to the Internet Key Exchange > version 2 (IKEv2) protocol for the purpose of a group key management. > The protocol is in conformance with the Multicast Security (MSEC) key > management architecture, which contains two components: member > registration and group rekeying. Both components require a Group > Controller/Key Server to download IPsec group security associations > to authorized members of a group. The group members then exchange IP > multicast or other group traffic as IPsec packets. This document > obsoletes RFC 6407. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-04 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 10 05:38:29 2022 Return-Path: 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 CA37E3A09AC for ; Mon, 10 Jan 2022 05:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyP59NKjXsw7 for ; Mon, 10 Jan 2022 05:38:24 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434263A09A3 for ; Mon, 10 Jan 2022 05:38:24 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id c71so42123337edf.6 for ; Mon, 10 Jan 2022 05:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Llp16WDcN1kWhgBurFy0ltAVC8C9N+9MtNYTL8Any6E=; b=YZDxowR/ITuf6Fm51deUfSxOVpZEWy9zAbCr9I1kDH4dbW9Pz43LJIHR6AlOhNJ4Tr lD8AdidAm7Du/jgbuT3QDpJFFLuti2ex6E3Lsor3hA9B3yV0S7SeOTV7hEjPXc9jvY+i gjVKVP+RACgzIwsderoIYYOHooY4CWp7nQRpbmDNsTURjDipmTzULYacmIb3+1xMrpsK KQPc9dlWn7s7WOYouvv68m4Xq1sQUBMUPQ9leQdebhDVAXf0nrDJvTI7XNuqmKegRAH+ i05yX/utgqGQH/vjEvpC5mURkwFzyYARC04omn/bZjdMwOZOLgEUoypsMLopnM8hpDgB KJxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Llp16WDcN1kWhgBurFy0ltAVC8C9N+9MtNYTL8Any6E=; b=i9jqm6OtI3ocQMuKeYHut65y+rLS54+ElKZYdypQ5fD95L4z890WIu2sbc5iiUJhuO 4bib8VmAn1V2jNhXnCRCIIooExyMMLjo0yze352X3ktuQhGuEAzgwHpfs7Z9ekIEVMcT FtnrBUS/1U1ySUH/C7uw8g7ZHjGEDcwRIPyHhhemEZ6A9cmJ8XdvcSrCM8rK0X4KjUnP iHefM5czIV1Zwh1TDVuWsxmevgrotUPIbVHlQ1zPyz8yf6fFmQQo7waed6sc1DqasSfu NeSSKzdZJEhLCbsuY3zAYv50qljz4dLRCIma7MSmba025F2a5dk51tG1SaidPNcxhfbd HNKg== X-Gm-Message-State: AOAM532xC57FgexfgltrlUZ0q+y/+uaxQA3dwJRWAl2R439UDSM1D7cb iQPx8IfW7ev6flWazTYIMCRaGKFvY+g= X-Google-Smtp-Source: ABdhPJzZzLs3W6JRSaO9FwVzjbYq5NYo8YnWmYU716PytRinLw5oVSGrHV3Vm77fG37GrSUtcQGsuA== X-Received: by 2002:a17:906:f54:: with SMTP id h20mr2241258ejj.201.1641821901999; Mon, 10 Jan 2022 05:38:21 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id p16sm2489722ejn.76.2022.01.10.05.38.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jan 2022 05:38:21 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: References: In-Reply-To: Date: Mon, 10 Jan 2022 16:38:20 +0300 Message-ID: <026601d80627$55c05970$01410c50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINrN/IdsOuc0WzOJRkkxx4Plg45qvw1S0A Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 13:38:29 -0000 Hi Paul, thanks a lot for your review. > I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and > RFC 8229. I agree with most of these changes. I have some comments > below. If others want to compare the draft with the RFC, see: > > https://nohats.ca/draft-ietf-ipsecme-rfc8229bis-01-from-rfc8229.diff.html > > > > > that may block IKE negotiation over UDP. > > I would say: > > that may not transport IKE negotiation over UDP. > > Blocking sounds like an active administrative action. Most networks just > accidentally happen to not pass UDP. I think both cases are possible. How about: that may block IKE negotiation over UDP either deliberately or inadvertently. > I might also change "for traversing network middleboxes" to be more neutral, > eg "in case routers or network middleboxes do not handle UDP". OK. So, the whole sentence (assuming my proposal above) would look like: This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection in case routers or network middleboxes do not handle UDP either deliberately or inadvertently. Is it OK? > o if the Responder chooses to send Cookie request (possibly along > with Puzzle request), then the TCP connection that the IKE_SA_INIT > request message was received over SHOULD be closed, so that the > Responder remains stateless at least until the Cookie (or Puzzle > Solution) is returned. Note that if this TCP connection is > closed, the Responder MUST NOT include the Initiator's TCP port > into the Cookie calculation (*), since the Cookie will be returned > over a new TCP connection with a different port. > > I am not sure this is a good idea. Tearing down and requiring a new 3way > handshake just to deliver the cookie seems useless. What is wrong with > using the existing TCP stream to reply? The responder does use an existing TCP connection to reply, but once it replies with cookie request, it should close this connection. If it keeps this connection, then it keeps TCP state until the client resends IKE_SA_INIT request (if ever) and thus thwarts the idea of being stateless. This is probably not so important for cookies, because the client has already proved during TCP handshake, that its IP is a real IP address, but it is more important in case of puzzles. But in both cases I think that keeping responder stateless is a good idea. > This might also make the code more complex, as currently, the TCP state > is kept during the entire negotiation. No, RFC 8229 allows the responder to close TCP session at any time (Section 6). Moreover, an attacker may reset TCP connection on its will. In this case the TCP originator would restore it. So, no additional code complexity, you must already be able to handle this situation. > Additionally, a NAT router could give the client a different IP address > for a new TCP stream, making the COOKIE invalid. Yes, it is possible and this situation is covered in the draft. But if we choose between keeping the responder stateless and the possibility of occasional failure of cookie verification, I'd choose the former as more important. I think we can slightly change this recommendation: o if the Responder chooses to send Cookie request (possibly along with Puzzle request), then the TCP connection that the IKE_SA_INIT request message was received over SHOULD be closed after the Responder sends its reply and no repeated requests are received within some short period of time, so that the Responder remains stateless. Note that if this TCP connection is closed, the Responder MUST NOT include the Initiator's TCP port into the Cookie calculation (*), since the Cookie will be returned over a new TCP connection with a different port. Does it address your concern? > Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for > additional messages in case it receives error notification from the > Responder in the IKE_SA_INIT exchange. > > This is true, but the code handlling this might not be aware of the > transport used. I'd rather see "an Initiator MAY skip the waiting time > for additional messages" so that this advice becomes "a good idea" and > not a "RFC violation" if not done. Hmm, I think that "SHOULD NOT wait" leaves you a possibility to wait if you have good reasons for it, without being accused in "RFC violation" :-) I have no problems with MAY in general, but I think that it's better to encourage implementers to make this optimization (which MAY does not). > 7.6. Keep-Alives and Dead Peer Detection > > This section tells us to not send NAT keepalives. It also tells us to > not rely on TCP keepalives. That left me puzzled on how to ensure the > peer is alive until I remembered that NAT keepalives are not the same > as IKE keepalives. I would briefly mention in this section that IKE > keepalives should be used "as normal". OK. > Implementations that implement > both MOBIKE and TCP encapsulation MUST support dynamically enabling > and disabling TCP encapsulation as interfaces change. > > I'm not sure of the MUST here. Nice for sure, but perhaps the > implementation supports MOBIKE or TCP and not both at once ? > Perhaps restate as "if MOBIKE and TCP encapsulation are allowed for a > configuration, the implementation MUST support ...... OK. So, the text would look like: Implementations that implement both MOBIKE and TCP encapsulation and both are allowed for a configuration MUST support dynamically enabling and disabling TCP encapsulation as interfaces change. > In case of TCP the NO_NATS_ALLOWED > notification SHOULD be ignored because TCP generally has no problems > with NAT boxes. > > I would re-state it as: > > In case of TCP the NO_NATS_ALLOWED notification MUST be ignored. > > Although, re-reading why NO_NATS_ALLOWED was introduced, I think in > general this payload should be retired entirely, both for UDP and TCP. > (disclosure: libreswan completely ignores it) I think "MUST be ignored" is quite a radical change to RFC 4555. I prefer the current text since it leaves a possibility to not ignore this notification , thus be compliant with RFC 4555. Otherwise we would need to update it with this draft... > 8.3. IKEv2 Session Resumption > > This section says that if a TCP encap session was suspended, that the > client MUST use TCP to resume this. I don't understand why. It is likely > that a resuming client has moved networks, and might be on a network > that would properly support ESP or ESPinUDP. The resumption is really > mostly meant to skip over DH and AUTH phases as these are costly. I see > no reason to tie the transport to this. If I missed a valid reason > for this to be needed, clarify what needs to happen when the server no > longer can or wants to resume the session. Does the client close the TCP > and go back to UDP? I believe you are correct. The idea was to speed up SA resumption (we know that this responder didn't support UDP, but worked with UDP), however you are right that the situation may change. So the correct recommendation for the client would be - act as if this is the IKE_SA_INIT exchange. > NITS: > > This document updates specification for > change to: > This document updates the specification for > > > MOBIKE protocol, that allows IKEv2 SA > change to: > The MOBIKE protocol that allows SA's Why "SA's"? Shouldn't it be " SAs"? > New INFORMATIONAL exchange MUST NOT bestarted in this situation. > change to: > A new INFORMATIONAL exchange MUST NOT bestarted in this situation. > (or maybe say something like "the INFORMATIONAL exchange is then > retransmitted over TCP") > > > Since switching from UDP to TCP happens can occur during a single > INFORMATIONAL message exchange, > change to: > Since switching from UDP to TCP can happen during a single > INFORMATIONAL message exchange, > > MOBIKE protocol defined the NO_NATS_ALLOWED > change to: > The MOBIKE protocol defines the NO_NATS_ALLOWED Fixed in the local copy, thank you. Regards, Valery. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 10 06:58:24 2022 Return-Path: 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 7603D3A11F9 for ; Mon, 10 Jan 2022 06:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOaDkWSzbiJY for ; Mon, 10 Jan 2022 06:58:18 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB763A11F6 for ; Mon, 10 Jan 2022 06:58:17 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id k15so54486022edk.13 for ; Mon, 10 Jan 2022 06:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=fC2YDKEgrY5iAPNN5TN8G7azRRXJ9i2VJ5oxCXEvy2k=; b=Ol81BqAFIRp3Jqc8v+e4SOPcLXfvts2YdWjZOvNmfCM4HGAS6zddhkgleGUla0vC3f mSaa/yvXUG/hvf9xClFherNep/duxIotvcKUkNbZ/My6NqBaSAkJ2KJixm5jeRkl4I+o KjwP99K3IZXhvP9FRO5sLpbPhZvS+W4gPauDY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=fC2YDKEgrY5iAPNN5TN8G7azRRXJ9i2VJ5oxCXEvy2k=; b=y45VfmJCzoqCDvNQml3Dx/r8LbO0QDStu3OeEXSJaZsNc0OGs8WACF44ZYHZxKKJay OIxpBLxtVugUJB431jJnkX8xvwUD7JRzFWH0GL7nLSAammRc4i3RKVkmSYHuwONXbyz2 wm+NLS/T7J/XQxWIANoXTFc0eKZpQZ4bNT+ptIzmm0cGRjHTKU09wbBQBx1BJAMzA05C z/rc6m1orIU3whXXtIA3wtPsTpXUWRiSTdUyr0mLYuIArxAEo3JkfXy4L0XsyEiity7e WbVfJ+0aitI4a1mMa6NQNaNSLhN6sREVafVNMCOkj+p7z/UtwLPiiFzKGEdZ4TB0J8Pp BTOg== X-Gm-Message-State: AOAM533FvIXZFFI53p+996KcDm3eITy6qRvOPRMxwyftnqUSjssCPH0L JJYEpXD+pLgVUoDmon/b9ebMlyC1h9nQf2J+PXk= X-Google-Smtp-Source: ABdhPJzskf6ne9c6qiVRYUAwwFRZMw4gFg6HyIm5UFB4tt6Kd/rqQpSyRPFvwejt+bFCOUmGE9UbdA== X-Received: by 2002:a17:906:3e8a:: with SMTP id a10mr111091ejj.612.1641826693976; Mon, 10 Jan 2022 06:58:13 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id e4sm2508068eje.103.2022.01.10.06.58.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 06:58:13 -0800 (PST) Date: Mon, 10 Jan 2022 09:58:10 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" , Tommy Pauly In-Reply-To: <026601d80627$55c05970$01410c50$@gmail.com> Message-ID: References: <026601d80627$55c05970$01410c50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 14:58:23 -0000 On Mon, 10 Jan 2022, Valery Smyslov wrote: >> I am not sure this is a good idea. Tearing down and requiring a new 3way >> handshake just to deliver the cookie seems useless. What is wrong with >> using the existing TCP stream to reply? > > The responder does use an existing TCP connection to reply, > but once it replies with cookie request, it should close this connection. > If it keeps this connection, then it keeps TCP state until the client > resends IKE_SA_INIT request (if ever) and thus thwarts the idea of being stateless. > > This is probably not so important for cookies, because the client > has already proved during TCP handshake, that its IP is a real IP address, > but it is more important in case of puzzles. But in both cases > I think that keeping responder stateless is a good idea. Yes, stateless is good in those cases, but reality is we already used state to setup the TCP connection. So why drop all that state now. It is in a way too late for the "state creation savings". Instead, you are now creating _more_ work for a server that might be under a DoS attack. >> This might also make the code more complex, as currently, the TCP state >> is kept during the entire negotiation. > > No, RFC 8229 allows the responder to close TCP session at any time (Section 6). > Moreover, an attacker may reset TCP connection on its will. > In this case the TCP originator would restore it. So, no additional code complexity, > you must already be able to handle this situation. That's fair. I guess I have to test this on our code base :) >> Additionally, a NAT router could give the client a different IP address >> for a new TCP stream, making the COOKIE invalid. > > Yes, it is possible and this situation is covered in the draft. > But if we choose between keeping the responder stateless and > the possibility of occasional failure of cookie verification, > I'd choose the former as more important. I am choosing the other way around :) > I think we can slightly change this recommendation: > > o if the Responder chooses to send Cookie request (possibly along > with Puzzle request), then the TCP connection that the IKE_SA_INIT > request message was received over SHOULD be closed after the Responder sends its reply > and no repeated requests are received within some short period of time, so that the > Responder remains stateless. Note that if this TCP connection is > closed, the Responder MUST NOT include the Initiator's TCP port > into the Cookie calculation (*), since the Cookie will be returned > over a new TCP connection with a different port. > > Does it address your concern? I don't really see much difference. If the attacker can setup a TCP session, surely it can write 15 lines of python to replay the cookie back as well. The question is really whether the responder under attack is better of not needing as many TCP 3way handshakes versus keeping some state. Since the document says to basically ignore cookies as much as possible, it seems inline to just keep the TCP connection. >> Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for >> additional messages in case it receives error notification from the >> Responder in the IKE_SA_INIT exchange. >> >> This is true, but the code handlling this might not be aware of the >> transport used. I'd rather see "an Initiator MAY skip the waiting time >> for additional messages" so that this advice becomes "a good idea" and >> not a "RFC violation" if not done. > > Hmm, I think that "SHOULD NOT wait" leaves you a possibility to wait > if you have good reasons for it, without being accused in "RFC violation" :-) > > I have no problems with MAY in general, but I think that it's better > to encourage implementers to make this optimization > (which MAY does not). I'm looking at the damage here. There is again no good reason to tear down the TCP connection for an INVALID_KE, so why tell implementations to do that. Even if simple implementations might do that just because that's how they do it for UDP (kill entire exchange, start a fresh one) But I'd like to see us re-using the same TCP when receiving INVALID_KE, even if it was only for the reduced latency of another 3way handshake. >> Implementations that implement >> both MOBIKE and TCP encapsulation MUST support dynamically enabling >> and disabling TCP encapsulation as interfaces change. >> >> I'm not sure of the MUST here. Nice for sure, but perhaps the >> implementation supports MOBIKE or TCP and not both at once ? >> Perhaps restate as "if MOBIKE and TCP encapsulation are allowed for a >> configuration, the implementation MUST support ...... > > OK. So, the text would look like: > > Implementations that implement both MOBIKE and TCP > encapsulation and both are allowed for a configuration > MUST support dynamically enabling and disabling TCP > encapsulation as interfaces change. sure, just slightly different start: Implementations that implement both MOBIKE and TCP encapsulation within the same connection configuration MUST .... >> In case of TCP the NO_NATS_ALLOWED >> notification SHOULD be ignored because TCP generally has no problems >> with NAT boxes. >> >> I would re-state it as: >> >> In case of TCP the NO_NATS_ALLOWED notification MUST be ignored. >> >> Although, re-reading why NO_NATS_ALLOWED was introduced, I think in >> general this payload should be retired entirely, both for UDP and TCP. >> (disclosure: libreswan completely ignores it) > > I think "MUST be ignored" is quite a radical change to RFC 4555. > I prefer the current text since it leaves a possibility to not ignore > this notification , thus be compliant with RFC 4555. Otherwise > we would need to update it with this draft... Fair enough. >> 8.3. IKEv2 Session Resumption >> >> This section says that if a TCP encap session was suspended, that the >> client MUST use TCP to resume this. I don't understand why. It is likely >> that a resuming client has moved networks, and might be on a network >> that would properly support ESP or ESPinUDP. The resumption is really >> mostly meant to skip over DH and AUTH phases as these are costly. I see >> no reason to tie the transport to this. If I missed a valid reason >> for this to be needed, clarify what needs to happen when the server no >> longer can or wants to resume the session. Does the client close the TCP >> and go back to UDP? > > I believe you are correct. The idea was to speed up SA resumption > (we know that this responder didn't support UDP, but worked with UDP), > however you are right that the situation may change. > > So the correct recommendation for the client would be - act as if this is the IKE_SA_INIT exchange. Yes, perfect. Paul From nobody Mon Jan 10 14:45:44 2022 Return-Path: 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 BC8C43A13FF; Mon, 10 Jan 2022 14:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzy2Ga200WJE; Mon, 10 Jan 2022 14:45:39 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439553A13FE; Mon, 10 Jan 2022 14:45:29 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id E03E82005B; Tue, 11 Jan 2022 00:45:25 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641854726; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=8n35/JlUJhm/42b7yhsu8umUHDrpn/gR0Qc5iuVkaNU=; b=Fnz/wck9bbFcwAnaglrHasYnyTRTdr4VGPyRMlYzDIvgGdRfJ9hKFgyRGvcLJYaWOYe2KX Cvdx35BrhtR/WfHIRhPWpwixKVJL+Pzp1t2EgfXPQ/nHevW8TukuThu2deeaP1IpfQuKH+ d8GF/yR3DzCFjrgu+deZrqEow2VUVj0= Received: by fireball.acr.fi (Postfix, from userid 15204) id 3912825C12E1; Tue, 11 Jan 2022 00:45:25 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25052.46852.971778.754673@fireball.acr.fi> Date: Tue, 11 Jan 2022 00:45:24 +0200 From: Tero Kivinen To: ipsec@ietf.org CC: draft-ietf-ipsecme-g-ikev2@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 113 min X-Total-Time: 637 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1641854726; a=rsa-sha256; cv=none; b=GVWAAPYA8VJyl4JoG6pxF1UZW11tM6Seq6TFYCf8+7PxtH3ZIGUxjHrhly5St1PzDBK5lX lhRhCfgShfg0XuA+SKu/frUu+QI66wM2duflLc+DAhoB7de+Lz34SR3NmlWslWAhK0HrC1 UyJRCipUeozbzCeVyowvB49Gz0ceP2U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641854726; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=8n35/JlUJhm/42b7yhsu8umUHDrpn/gR0Qc5iuVkaNU=; b=ak1CR1XJDXyT3wQ5VPo+/AUKUx6PbAGjmDi5M545xaE7tFWMG5ODTicYsplFi89W21watI M0Im7GCS5whCzyQAUdE6eF+FK2YJEDbhrn2znDrV6Jo/oxssgl+oAeD8xqbOESEXRSeqdK KpXh+3qtSFQ8uHyqUvSgNF1Fd1pSJHM= Archived-At: Subject: [IPsec] Comments to the g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 22:45:42 -0000 While reading the draft-ietf-ipsecme-g-ikev2-04 draft I started to thinking whether we should get rid of the GSA_AUTH completely? We have several extensions or enhancements that change the way IKE_SA_INIT and IKE_AUTH are done, and porting those changes to the GSA_AUTH is going to require extra work, and looking how little interest this draft has been receiving, I am wondering if we have enough people to do that work. Those things include Intermediate Exchange, Multiple Key Exchanges, Announcing Supported Authentication Methods, EAP-Only Authentication (RFC5998), Signature Authentication in IKEv2 (RFC7427), NULL authentication method (RFC7619), Mixing Preshared keys for Post-Quantum security (RFC8784), etc.. My understanding is that we could simply remove the GSA_AUTH completely, and say that g-ikev2 always uses normal IKE_SA_INIT, and IKE_AUTH (with CHILDLESS_IKEV2_SUPPORTED from RFC6023) and then do GSA_REGISTRATION as separate step. This would allow us to reuse all of the extensions and enhancements we are working on for IKE_AUTH with this g-ikev2 protocol for free, with cost of one extra round trip. Another option is to rewrite section 1.4.1 in such way that it is clear that GSA_AUTH and IKE_AUTH are identical except that GSA_AUTH does not include payloads for creating Child SA for unicast traffic (SA*, TS*), but do include payloads for group keying (IDg, SAg, N, GSA, KD, D). If it is clear that GSA_AUTH and IKE_AUTH use exactly same processing from the authentication point of view, all the work above should work without changes. The section 1.4.3/1.4.4 mostly already hints to that, but 1.4.1 is more vague about it. -- We should add following terms to the terminology section: GM, GCKS, KEK, TEK, Rekey SA, Data-Security SA, LKH, GSA_a, GSA_e, Group SA, registration SA, and add bit more explansion what they are than just expanding the acronym, i.e., explain that Rekey SA is equivalent of IKE SA of the IKEv2, but over the multicast GSA_REKEY operations and is keyed by the KEKs sent from the GCKS etc. The Rekey SA uses the current KEK that provides the GSA_a and GSA_e used to protect GSA_REKEY. (and I have no idea what is some of the SAs are supposed to mean) -- In section 1.4.5.1. GSA_REKEY the text: G-IKEv2 rekeying MUST NOT support IKE SA windowing. is wrong, the implementations might support IKE SA windowing, but MUST NOT use it... -- I assume that in section 1.4.5.1. GSA_REKEY the text: If implicit authentication is used, then AUTH_KEY MUST NOT be sent to GMs. is trying to say that AUTH_KEY MUST NOT be sent to the GMs using GSA_REKEY, it was sent during the GSA_AUTH or GSA_REGISTRATION to each member separately, and will not be changed during the lifetime of the multicast flow. -- In section 1.4.5.1.1 it says: the content of the Encrypted payload is encrypted and the ICV is computed using the current SKe/SKa keys. which is confusing as SKe and SKa keys are never defined. The RFC7296 defines SK_a* and SK_e* keys, but those cannot be used for GSA_REKEY, as GSA_REKEY is multicast message, and SK_a* and SK_e* from the RFC7296 are generated per peer. I assume those SKe and SKa are keys transmitted from the GCKS to GM inside KD payloads or something. On the other hand section 2.4 defines SK_e and SK_a, which are really bad names, as they might get confused with RFC7296 SK_ei, SK_er, SK_ai, and SK_ar. It we are supposed to use those SK_e and SK_a keys here, then they needs to be renamed to something more distinct, like GSK_e and GSK_a or something. The sections 1.4.5.1.2 and 1.4.5.1.3 talk about the "new KEK", and the "current KEK", i.e., it does not talk about SKa/SK_a/SKe/SK_e, so it is not clear how those are supposed to match. -- In section 1.4.5.1.3 there is text: When a group member receives the Rekey Message from the GCKS it decrypts the message using the current KEK, validates its authenticity using the key retrieved in a previous G-IKEv2 exchange if AUTH payload is present, verifies the Message ID, and processes the GSA and KD payloads. The text "if AUTH payload is present" in the middle is bit funny, I would assume we need to validate the authenticaty of the message regardless whether the AUTH payload is present by checking the ICV value. When we check the ICV value we do know that the message is from someone who knows the current KEK, i.e., at least someone in the group, so that somewhat authenticates the message. Of course having digital signature AUTH payload authenticates the message originating from the GCKS. On the other having AUTH payload PSK does not provide any new information over the ICV, anybody who knows the PSK (i.e., everybody in the group) and generate AUTH payloads using shared keys. I would actually explictly forbid using shared key authentication in the AUTH payload of the GSA_REKEY, and only allow digital signature methods. -- In section 1.4.6.1. text says: 5. When the SID-counter maintained by the GCKS reaches its final SID value, no more SID values can be distributed. Before distributing any new SID values, the GCKS MUST delete the Data- Security SAs for the group, followed by creation of new Data- Security SAs, and resetting the SID-counter to its initial value. but earlied in the section it said: The group member uses the same SID for each Data-Security SA specifying the use of a counter-based mode of operation. I.e., the deteing the Data-Security SA does not reset SID, as the group member will simply use same sid for newly created Data-Security SA. Yes, the newly created Data-Security SA does have different key, and there will not be nonce overlap with the previously used Data-Security SA, but the GCKS does not get any SIDs it can give out. I think only way to reset SIDs is to remove all KEKs, i.e., forcing everybody to do IKE_SA_INIT and GSA_AUTH/GSA_REGISTRATION again. In bullet 6 this is explained but only by with SHOULD. I think the text should be rewritten to say that GCKS MUST delete the Rekey SA to force all members to register. -- Section 1.4.6.2 should explictly mention that all SIDs are reset when the Rekey SA is deleted. And also that deleting the IKE SA does NOT remove SIDs, i.e., even when using GSA_INBAND_REKEY the GCKS need to explictly delete Rekey SA using Delete payload having protocol ID of GIKE_REKEY. -- In section 1.4.5.3 the text talks about the SPI value equal to zero, but I think it is trying to say that the SPI Size field is zero and SPI field is empty. -- In section 2.1.1 we could add note that if the RFC8784 is used then the SK_d used is the one was already PRFed with PPK, thus the generated SK_w will be quantum resistant. -- Section 2.1.1. says that SK_w = prf+(SK_d, "Key Wrap for G-IKEv2") but then section 2.4 says: SK_e | SK_a | SK_w = KEYMAT I do not understand when section 2.4 is used? What is the KEYMAT in that formula? Which SK_w is used for the GSA_AUTH or GSA_REGISTRATION for encrypting keys with key wrap key of 0? -- In section 3.4.2 the SPI size and SPI fields for the GIKE_REKEY is set to include the IKEv2 SPIs? Why is this? In RFC7296 we usually use SPI size of 0, and empty SPI when we are talking about the IKE SA, and I would have assumed that GIKE_REKEY protocol number is identically identifying the Rekey SA. Ah, now I understand this is supposed to match the GSA_REKEY pseudo exchange message SPIs. I think this text should be clarified about this, and perhaps we need to add more text to the Rekey SA terminology definition saying that where the IKE SPIs for that SA comes from. Btw, can we have multiple GSA_REKEY pseudo exchange SAs? I.e., can GCSK send multiple Group Security Association Policy substructures, and send out multiple SPIs for those GSA_REKEY messages, so it can use use different GSA_REKEY SPIs to send key updated to only some of the SAs etc? I.e., one of those could use the Digital signatures and another one could use NULL authentication? -- In section 3.4.2.1.1 I have no idea what is security difference between the Shared Key Message Integrity Code and NULL authentication? Both of them are using group keys that are distributed to everybody in the group, so what is the security benefits from the Shared Key Message Integrity Code? -- I do not like the GAP format specified in the 3.4.3. Having the first 2 octes of zero overlapping the Protocol and SPI Size fields of the normal substructures inside GSA is a hack, and I think it would be better to simply allocate one protocol number for sending GAP. At least change the figure 16 so that first 8-bits of the substructure is Protocol, and that MUST be zero for the GAP, and next 8-bits are reserved... Same for the Member Key Packet Substructure in section 3.5.3... -- In section 3.7.1 the described behavior is different than what is defined in the RFC7296. RFC7296 sends USE_TRASPORT_MODE notification with protocol number 0, spi size of zero, and without SPI field. Section 3.10 of RFC7296 says: Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. and as USE_TRASPORT_MODE is defined in the RFC7296 it uses this method, and does not include SPI. I.e., sending multiple USE_TRASPORT_MODE notifications as specified in the section 3.7.1 does not work. One way to fix this is to say that if GCKS wants to use both transport mode and tunnel mode, it MUST use separate exchanges to do that, i.e, first include one GSA_INBAND_REKEY / GSA_REKEY to send information about tunnel mode SAs, and then do another GSA_INBAND_REKEY / GSA_REKEY with USE_TRASPORT_MODE notification to send transport mode SAs (and after doing the GSA_AUTH or GSA_REGISTRATION with tunnel or transport mode, it needs to do extra GSA_INBAND_REKEY for other mode). -- Section 4.1. is not correct. The SK_w used to encrypt the keys inside the KD payloads is protected by PPK, as it is derived from the SK_d which is protected, thus all keying material transported in the initial IKE SA is protected. As such I think all of the section 4.1 can be removed, the mandatory or not example does not really belong to this document, as my understanding is that this is default RFC8784 behavior. -- Section 5.2.1 requires more text about the case where GSA_REKEY does not use AUTH payload. -- Section 5.2.2 should include the fact that if RFC8784 is used then the SK_w depends on the PPK, and all keying material wrapped inside the G-IKEv2 are encrypted with either that key, or key encrypted depending on that key. -- I do not really understand what section 5.2.3 is trying to say? The normal GSA_AUTH is protected against the Man-in-the-middle by using normal authentication either shared keys or signatures. The GSA_REKEY is protected by the man in the middle by the fact that the keys used in to encrypt and authenticate it are only known by the members of the group. Note that group members do not have any need to be a man in the middle, as they can generate GSA_REKEY unless digital signature AUTH payloads are used. -- kivinen@iki.fi From nobody Mon Jan 10 14:59:55 2022 Return-Path: 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 4297C3A14F8 for ; Mon, 10 Jan 2022 14:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIM64m0iYGp7 for ; Mon, 10 Jan 2022 14:59:47 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C3D3A14F5 for ; Mon, 10 Jan 2022 14:59:47 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 525361B0024D; Tue, 11 Jan 2022 00:59:43 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1641855583; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/l2P/JjOB7aL4FtMtNRsN8Vip6VDWJGAewopuYJ9j3k=; b=WG2cFuDl/tWCEyRii6mIVc4KgKYdoKcC/4nu7uU95ja+BoF6WOTzevBDR6x/gDo5BOpQUE Vn29Ji6x4newAlIycQNmVjmQRSbkfk0r6GWcfeKPRh112yd45mBRQeOx5heiz4vGkV7dK0 vOS014IQpKuGvQ7dTWD+SpzbTYSFdfJLkw76+3eEw3ceucE5YY2KEYlMJxBHebZBF2zsiD 8WKmdntf8gKz0D4ZOXYIdl6XKAph8obNvEDdHiDB/B+6tvQYbU9McwrN0fp2C6qJ8a5VE0 pv68SkdvtypQmcUYkHUzd4qtDAsLsZyBVH09AF2l4vCDhSXGZOpkhfbVzRDfEQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 31D2B25C12E1; Tue, 11 Jan 2022 00:59:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25052.47710.148277.213677@fireball.acr.fi> Date: Tue, 11 Jan 2022 00:59:42 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Paul Wouters'" , , tpauly@apple.com In-Reply-To: <026601d80627$55c05970$01410c50$@gmail.com> References: <026601d80627$55c05970$01410c50$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 8 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1641855583; a=rsa-sha256; cv=none; b=YYNf48rhOs01K0VlpaMA+KLxA5awHcwf+Kaihm5Y1a0MQmFtaoj2yNHuLjSjeLz9gafnGT u3xqkytHa4C0ITvKMdK5RFlqnbPnEOBUDsHfZXCNVwNg7ejJAERW44YVcP1wzDY9mmdOIW yWrkDKeDARQ7jbgP0q+UqAibIO/3veU2oLiM+kfgclDW3Yf08HB/ErUEkkTr1ujWHIvC+p JFZdWu8rtMjkqwv/dRxz3Ucg5kW6JjZoSZY/adKjfvtwnz4xsjv2jDREZqfXP+b/JcAii5 rwbpRT0edzPPx1weGBu+UOZmqDFcDWDEa1P3BKKHq3mmdNNlqVvKXxVFUKAeEA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1641855583; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/l2P/JjOB7aL4FtMtNRsN8Vip6VDWJGAewopuYJ9j3k=; b=O+UX8EMYmuRqJbPRMJYKJ2KbS1DOwMH/8RYMX5EquZXOR2KPGK1oWI5MjM/oRqLV8ifGxp WQfUMGgSf3qiBCDXqVAVufMdAkyQfkUNA4ToXlCtRT0D53361Qcb06LABZVO92z5T4ydbq Cvxwuf19VTYIVujI0d9dNxFIhcJ6iv76Fu+g4Dkx11UG85361O06A7aSVDB6BNYDTvyzrG vPFfCz5Na4JGq6RIXtiniunYSNlTFmhBh951643pFypZ3T29f9DhcLcqCRbTQ9O4o5JS9T /Du5BuUK0LHaboNFn/KcbRlFMbnKo/8muq0PWPn7XPKrW/TvBiPA8aG1vt5+vg== Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 22:59:53 -0000 Valery Smyslov writes: > The responder does use an existing TCP connection to reply, but once > it replies with cookie request, it should close this connection. If > it keeps this connection, then it keeps TCP state until the client > resends IKE_SA_INIT request (if ever) and thus thwarts the idea of > being stateless. > > This is probably not so important for cookies, because the client > has already proved during TCP handshake, that its IP is a real IP > address, but it is more important in case of puzzles. But in both > cases I think that keeping responder stateless is a good idea. I think it is important not to close the TCP immediately after the sending out cookie request, as proper initiator will most likely respond it in one round trip, thus forcing initiator to restart TCP handshake wastes lots of resources. On the other hand it might be useful for puzzles, depending on the expected solving time. Note, that when the responder closes the TCP connection the connection goes to the TCP TIME_WAIT state, where it will still waste resources for a minute or so, thus closing TCP session will NOT free resources immediately, thus closing TCP session too quickly will waste much more resources than keeping it open for 10 seconds or so. If responder keeps the TCP session open for 10 seconds, and initiator comes back during that time with cookie or solved puzzle it can save 6 packets between the peers, and one set of buffers used for TCP send/receive windows. If initiator does not come back after 10 second wait, then it only extends the resource use from 60 seconds to 70 seconds or so... -- kivinen@iki.fi From nobody Mon Jan 10 15:04:20 2022 Return-Path: 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 5B32D3A1529; Mon, 10 Jan 2022 15:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQNvDaH-zLez; Mon, 10 Jan 2022 15:04:16 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19723A1518; Mon, 10 Jan 2022 15:04:12 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20AN44GL001292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Jan 2022 18:04:10 -0500 Date: Mon, 10 Jan 2022 15:04:04 -0800 From: Benjamin Kaduk To: draft-ietf-ipsecme-ikev2-intermediate.all@ietf.org Cc: ipsec@ietf.org Message-ID: <20220110230404.GB11486@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 23:04:18 -0000 Hi all, The core mechanisms here seem in good shape. My main area of uncertainty relates to how much analysis, and with what degree of formalism, has been applied to the updated IKE_AUTH procedures that are supposed to authenticate the intermediate exchange(s). My comments on §3.3.2 have more details, but key questions include how we authenticate how many rounds of IKE_INTERMEDIATE were performed, whether using the plaintext of the Encrypted payload gives an attacker too much flexibility, and whether we want to make any tweaks to "future-proof" the construction in case we need some other exchange that occurs prior to IKE_AUTH. I'd also like to confirm that the current (lack of) Updates: relationship between this document and RFC 7296 is correct. In §3.2, we reaffirm that the normal IKE rules for assigning Message IDs apply, so "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next (if any) and so on". But in §2.2 of RFC 7296 it is claimed that "the first pair of IKE_AUTH messages will have an ID of 1, the second (when EAP is used) will be 2, and so on", where we now have competing claims about what exchange will get Message ID 1. I can see a case to be made that neither of these statements is intended to be normative, and thus that there is no conflict, but wanted to confirm that the WG had considered this topic. I see the shepherd writeup mentioned some missing articles ('a', 'the', etc.). I took the liberty of making some edits in that space to a local copy of the draft, which I will send to the author directly for him to incorporate or ignore. Section 3.2 If the presence of NAT is detected in the IKE_SA_INIT exchange via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications, then the peers MUST switch to port 4500 and send all IKE_INTERMEDIATE exchanges using port 4500. I think I see an equivalent requirement in §2.23 of RFC 7296 ("The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP payloads if present, and if they do not match the addresses in the outer packet, MUST tunnel all future IKE and ESP packets associated with this IKE SA over UDP port 4500."), since the IKE_INTERMEDIATE exchanges would fall under "all future IKE packets". So, does this need to be written in this was with normative MUST as if it is a new requirement? Or should we rephrase slightly to reaffirm that the existing requirement applies in this case? Section 3.3.2 The requirement to support this behavior makes authentication challenging: it is not appropriate to add on-the-wire content of the IKE_INTERMEDIATE messages into the AUTH payload calculation, because peers generally are unaware in which form other side has received them. Instead, a more complex scheme is used - authentication is performed by adding content of these messages before their encryption and possible fragmentation, so that data to be authenticated doesn't depend on the form the messages are delivered in. The behavior of using the pre-encryption form of the messages in the authentication seems to merit some closer inspection, as it opens up an avenue for the attacker to modify what bits are authenticated as they traverse the network. On first look, since the encryption is done using keys negotiated in the IKE_SA_INIT exchange, which is itself subject to IKE_AUTH authentication, any tampering with the encrypted payloads would require tampering with the IKE_SA_INIT exchange (so as to have access to the key material needed), which would in turn be detected at time of IKE_AUTH. But it would be reassuring to know that some more formal analysis has been performed on this scenario. In a similar vein, it would be good to see some more formal analysis that confirms that this construction authenticates the number of intermediate exchanges that have occurred. I am not sure that I could sketch an attack that uses such a mismatch, but if we are using a threat model where IKE_INTERMEDIATE is used to provide protection against a quantum computer that could break the initial IKE_SA_INIT key exchange, it seems like we need to be sure to protect against "truncation" attacks that cut the quantum-resistant key-exchange out of the authenticated transcript. If any IKE_INTERMEDIATE exchange took place, the definition of the blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is modified as follows: InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth This sort of construction invites ambiguity if there is ever some other future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. This seems like a strong argument in support of the approach this draft takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize the chance of needing such an additional future exchange. That said, it might be possible to slightly improve the future-proofing if we included an indicator of what the "next content" after MACedIDFor[IR] is, such as the one-octet encoding of the exchange type. (I think it would have to be part of IntAuth_N, not IntAuth itself.) I don't have a great sense for whether the value this adds would be worth the disruption to existing implementations, though. IKE_INTERMEDIATE exchanges took place). The prf is applied to the the concatenation of two chunks of data: mandatory IntAuth_*_[I/R]_A optionally followed by IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A chunk lasts from the first octet of the IKE Header (not including prepended four octets of zeros, if port 4500 is used) to the last octet of the Encrypted payload header. The IntAuth_*_[I/R]_P chunk I think this would be more precise as "the last octet of the generic payload header of the Encrypted payload". We do go on to say that the IV/etc. are not included, but that seems to be in the context of computing the _P chunk, and may or may not be saying anything about excluding it from the _A calculation. is present if the Encrypted payload is not empty. It consists of the (editorial) I'd recommend including some keyword to provide a mnemonic for the _A and _P suffixes for these intermediate values. Section 3.4 DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how errors are handled in initial IKEv2 exchanges, these considerations are also applied to the IKE_INTERMEDIATE exchange. While the translation of the IKE_SA_INIT error handling to IKE_INTERMEDIATE seems pretty straightforward, I wonder if we want to say a little more about how the IKE_AUTH error handling applies. In particular, I'm not sure if the portions about sending an AUTHENTICATION_FAILED notification will ever apply. (The handling of messages that contain an unsupported critical payload, on the other hand, does seem like it would apply in a fairly straightforward manner.) Section 5 Do we think there's a risk of IKE_INTERMEDIATE being used as a DoS vector by way of causing a peer to retain a lot of state prior to authentication? Perhaps that is more appropriate for the other specifications that consume IKE_INTERMEDIATE. attacker to mount Denial-of-Service attack. Moreover, if in this situation the negotiated prf was not secure against preimage attack with known key, then the attacker could forge the IKE_INTERMEDIATE I think this would need to be a second-preimage attack, right? It's probably worth clarifying. Thanks, Ben From nobody Tue Jan 11 03:58:21 2022 Return-Path: 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 B43163A095D for ; Tue, 11 Jan 2022 03:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cepRSi8SJ7Fl for ; Tue, 11 Jan 2022 03:58:17 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A36B3A0955 for ; Tue, 11 Jan 2022 03:58:17 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id s30so27607055lfo.7 for ; Tue, 11 Jan 2022 03:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=wc6IiN2G4mFwpOe4rQ2h879Xe/mu7O5laJPzqoFizZo=; b=YIaBNcxEg2Jrpe8kYVV0E7jsRSvLsQB6kLa/bX6+nh2oLsN5RyKrduovpRm6p/9NGa uYuXE0b0nSTJi3MnVHtoMMB2HrmazusvD0ZQEKh0UDsx7gxCyVsDFl4XM8hF2CLP0v2m xieHFsfizmr3WRxYbGzhQ/K03d00nOfmBOJ162Y+wCu1nDZCEKHs5sZh0FUzU/8CMBqX 5gSuYsEWNqSGDhBOe+I7YpjcG41AMlKhznNaZTCha4X7BEbMWjci9m+l4b7PeKn+0+wV lOoh7OqYfFxwHgRudvRVIo7qri/y+dR+YB6pvDtiJiH/joRIVC2cbE7rAV8BLWlYTWWp M/Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=wc6IiN2G4mFwpOe4rQ2h879Xe/mu7O5laJPzqoFizZo=; b=fFSKHhozo/5hyf+2yozMr4KVH3Fjl7sUXEpKWn9DyKr0wdc6UsnkgHozyOBW3MiOXX +Po/6A0S1cJR4F5vj0tBYaLOZxQYwS9ZufxAIxVQf0vNhhxbCbzx8dWlYK+8IrKKxI5j 4dpKWy3Q4eWlWs+jMm8mka5OsdbnaEL6g3MikKTpw8QkKHqjiLq9B3mFVXmWA6aPvw5j DQQTz8qdfjwic6gWQEgaygAtDFT0WCMnW2+vYT7BaRYAabS2bc107Z0971bCpspUn3/m cjk5WEWt5jwcAu+ywcu7kK/mwvm6igqRz+o6uVa38/uJSK/j/CgZRVlcp1qBDPod2zT1 Dl3g== X-Gm-Message-State: AOAM5304i1VBKdD7Tsdwq/SN9OSgoYLvjpYdN4is1x9nge9olBdyWrml yELdp+UQ9RX6CuSGZLp5hkS74CDSgQs= X-Google-Smtp-Source: ABdhPJxz5yrvh16WlBNvVW5TYgM+65K1ZFp36lTNr5UAtoWQZKri1ekX+eM4oHcdOfREgjg9yKbjFw== X-Received: by 2002:a2e:96d0:: with SMTP id d16mr2768567ljj.330.1641902294301; Tue, 11 Jan 2022 03:58:14 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id a12sm1276636ljp.59.2022.01.11.03.58.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 03:58:13 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Paul Wouters'" , , References: <026601d80627$55c05970$01410c50$@gmail.com> <25052.47710.148277.213677@fireball.acr.fi> In-Reply-To: <25052.47710.148277.213677@fireball.acr.fi> Date: Tue, 11 Jan 2022 14:58:13 +0300 Message-ID: <02f301d806e2$83b74030$8b25c090$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINrN/IdsOuc0WzOJRkkxx4Plg45gI1M6jVAd9ejX6r0cMAsA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 11:58:20 -0000 Hi Tero, > Valery Smyslov writes: > > The responder does use an existing TCP connection to reply, but once > > it replies with cookie request, it should close this connection. If > > it keeps this connection, then it keeps TCP state until the client > > resends IKE_SA_INIT request (if ever) and thus thwarts the idea of > > being stateless. > > > > This is probably not so important for cookies, because the client > > has already proved during TCP handshake, that its IP is a real IP > > address, but it is more important in case of puzzles. But in both > > cases I think that keeping responder stateless is a good idea. > > I think it is important not to close the TCP immediately after the > sending out cookie request, as proper initiator will most likely > respond it in one round trip, thus forcing initiator to restart TCP > handshake wastes lots of resources. On the other hand it might be > useful for puzzles, depending on the expected solving time. > > Note, that when the responder closes the TCP connection the connection > goes to the TCP TIME_WAIT state, where it will still waste resources > for a minute or so, thus closing TCP session will NOT free resources > immediately, thus closing TCP session too quickly will waste much more > resources than keeping it open for 10 seconds or so. Good point. > If responder keeps the TCP session open for 10 seconds, and initiator > comes back during that time with cookie or solved puzzle it can save 6 > packets between the peers, and one set of buffers used for TCP > send/receive windows. If initiator does not come back after 10 second > wait, then it only extends the resource use from 60 seconds to 70 > seconds or so... The latest text I proposed in reply to Paul's comments incorporates this strategy: o if the Responder chooses to send Cookie request (possibly along with Puzzle request), then the TCP connection that the IKE_SA_INIT request message was received over SHOULD be closed after the Responder sends its reply and no repeated requests are received within some short period of time, so that the Responder remains stateless. Note that if this TCP connection is closed, the Responder MUST NOT include the Initiator's TCP port into the Cookie calculation (*), since the Cookie will be returned over a new TCP connection with a different port. The text doesn't specify what "some short period of time" is. I don't think we should do it (it may be 10 sec as you suggested or 5 sec or 20 sec). Is it OK? Or should we probably change SHOULD to MAY here? Regards, Valery. > -- > kivinen@iki.fi From nobody Tue Jan 11 04:23:35 2022 Return-Path: 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 EABE03A0BC5; Tue, 11 Jan 2022 04:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efwhJBLtAPts; Tue, 11 Jan 2022 04:23:31 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518D43A0BD2; Tue, 11 Jan 2022 04:23:30 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 0A64320048; Tue, 11 Jan 2022 14:23:26 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641903806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y6j6mKWUtFsGt3tmhlUSYuYgA/hi2wMw20IKHgST9rs=; b=mrhHABcYhjyk7xj9GqO0e3iUF8KLSIJO8oMuM7LvIrib59NsHtihj9FaIRjADN+SqYOtdQ 7BbFqOhUhAQQm8kIqJyjeJZ2iJ58xGowxLougySFojhPP4XdBNHKd9Dt7jePDHM7MFCX0j n0oedHxMzXKpIatAWIQha+slOhHnTe0= Received: by fireball.acr.fi (Postfix, from userid 15204) id DE65C25C12E1; Tue, 11 Jan 2022 14:22:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <25053.30365.853374.402503@fireball.acr.fi> Date: Tue, 11 Jan 2022 14:22:53 +0200 From: Tero Kivinen To: Benjamin Kaduk Cc: draft-ietf-ipsecme-ikev2-intermediate.all@ietf.org, ipsec@ietf.org In-Reply-To: <20220110230404.GB11486@mit.edu> References: <20220110230404.GB11486@mit.edu> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 25 min X-Total-Time: 34 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1641903806; a=rsa-sha256; cv=none; b=O21Equ4ZgLw0mtWg19B2wqSsu68ZP5mxnx3jEglbEUetenWlM8/3bzvIgzOYfGYdGuTCAB oNUuNsEZrCcOxWu6E2Tj2+Balc9PU5DSeGF+T6ogX47VBzlzunCc5mmSWNWIDPwkv/r+x5 YqVyBK9uZ/XecG/Q5j9XT0RO5aFOPEM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641903806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y6j6mKWUtFsGt3tmhlUSYuYgA/hi2wMw20IKHgST9rs=; b=DO+UU03oqbVaZmiDP1Cmt4b1d3J0O5R22z6hsG780VxwifLPEdcqflN3V3PuY684oZ46fU uKkxMauVUAJBvb4Y6yHxHRExT7aGPuIzkra12nRhOCs6hUrLo7UoGMjJvH2kbEvgfM2j16 SAvHayOkiXoF295yefPhO9VYo3IJ5MA= Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 12:23:34 -0000 Benjamin Kaduk writes: > I'd also like to confirm that the current (lack of) Updates: > relationship between this document and RFC 7296 is correct. In =A73.= 2, we > reaffirm that the normal IKE rules for assigning Message IDs apply, s= o > "it is set to 1 for the first IKE=5FINTERMEDIATE exchange, 2 for the = next > (if any) and so on". But in =A72.2 of RFC 7296 it is claimed that "t= he > first pair of IKE=5FAUTH messages will have an ID of 1, the second (w= hen > EAP is used) will be 2, and so on", where we now have competing claim= s > about what exchange will get Message ID 1. I can see a case to be ma= de > that neither of these statements is intended to be normative, and thu= s > that there is no conflict, but wanted to confirm that the WG had > considered this topic. The text in RFC7296 section 2.2 is not normative, it is example of what will happen when the normal case. I.e., first exchange will have message id 0, and second exchange will have message id 1 etc, for normal use of IKEv2 the first exchange will be IKE=5FSA=5FINIT and seco= nd exchange will be IKE=5FAUTH. In case IKE=5FINTERMEDIATE, the first exchange (message id 0) will be IKE=5FSA=5FINIT, and second exchange (message id 1) will be IKE=5FINTERMEDIATE. For the G-ikev2 the first exchange (message id 0) will be IKE=5FSA=5FINIT and second exchange (message id 1) will be GSA=5FAUTH. For RFC5723 (Resumption) the first exchange (message id 0) will be IKE=5FSESSION=5FRESUMPTION, and second exchange (message id 1) will be IKE=5FAUTH. > In a similar vein, it would be good to see some more formal analysis > that confirms that this construction authenticates the number of > intermediate exchanges that have occurred. I am not sure that I coul= d > sketch an attack that uses such a mismatch, but if we are using a thr= eat > model where IKE=5FINTERMEDIATE is used to provide protection against = a > quantum computer that could break the initial IKE=5FSA=5FINIT key exc= hange, > it seems like we need to be sure to protect against "truncation" atta= cks > that cut the quantum-resistant key-exchange out of the authenticated > transcript. Note, that you are here mixing properties from two different protocols, ikev2 intermediate and ikev2 multiple ke. IKEv2 intermediate is supposed to be used to transport large data between IKE=5FSA=5FINIT and IKE=5FAUTH. It is not supposed to be quantum resist= ant by itself. Quantum resistant part is provided by the multiple key exchanges. I.e., every single key exchange run between IKE=5FSA=5FINIT and IKE=5FA= UTH will provide new cryptographic keys to be used for all future IKE=5FINTERMEDIATE exchanges and those new keys depends on all previous= key exchanges done. I.e., when using multiple ke only the first IKE=5FINTERMEDIATE exchange= uses the diffie-hellman from the IKE=5FSA=5FINIT. The end result of the= that IKE=5FINTERMEDIATE is to generate new cryptographic keys using the= fomula from 3.2.2 of draft-ietf-ipsecme-ikev2-multiple-ke: SKEYSEED(n) =3D prf(SK=5Fd(n-1), SK(n) | Ni | Nr) and {SK=5Fd(n) | SK=5Fai(n) | SK=5Far(n) | SK=5Fei(n) | SK=5Fer(n) | S= K=5Fpi(n) | SK=5Fpr(n)} =3D prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) where the SK=5Fd(n-1) is the key derivation key generated by the previous step, i.e., in this case the Diffie-Hellman of the IKE=5FSA=5FINIT. So every single multiple key exchange run between the IKE=5FSA=5FINIT a= nd IKE=5FAUTH will contribute to the final encryption and authentication keys used for IKE=5FAUTH. This protects against attacks where attacker tries to remove any of the multiple key exchanges from the transcript. On the other hand IKE=5FINTERMEDIATE might also be used for use cases which do not generate keys, for example to transfer some kind of policy configuration information before IKE=5FAUTH etc. The IKE=5FINTERMEDIATE needs to provide the protection against those exchanges too, and adding them to the signed data should provide protection against attackers. If I remember correct TLS does the same, the final transcript hash is hash of all messages concatenated together including the handshake message header, but exlucing record layer headers... --=20 kivinen@iki.fi From nobody Tue Jan 11 04:31:13 2022 Return-Path: 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 6D7CF3A0113 for ; Tue, 11 Jan 2022 04:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83pvw8lmkKIM for ; Tue, 11 Jan 2022 04:31:10 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F2D3A0105 for ; Tue, 11 Jan 2022 04:31:10 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id d3so29406090lfv.13 for ; Tue, 11 Jan 2022 04:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=J0xrR+HkK810ZUnjh28zchUg66MFJkDMeUpq2rAP4WI=; b=d42GJLPt+B0iP9VTL7Ml8Kw5cW1w3cCurgArs6LAkKqZpEpef01kJzkrzX8DJEIUNG wTuMZLQgN/jigirTuDZtGg8XIQ9P7JBcV+C2s5d2ZwFSAto6ctgt1qglVgtVpN56Bys+ cWP1cXhqdxsO7Cxiec6STn8bjStoCFQM3kjHBMq6lqyCJzclqkttm1FkmqePthoVcWuh mj621fRwEnMBM7jq7qQ4zOO+spJI2FSTJzZI820yI9oEV+lfyYtBUPFw+Y7SkIi1ljTP 3Bt+Q+hvIxSxHpvSl+0atPwGGKLh306KN2fj+6wR/fmxCLsahib5Gwc92lBOYbHTXDGi 5QNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=J0xrR+HkK810ZUnjh28zchUg66MFJkDMeUpq2rAP4WI=; b=Z2vg9WuXnbuyxqVXz1pXec0Xiih1g9Y0jVHh3aHk9mfsYxXtcAFM66eFc1L7MQmIan ql1YpcOYjjA7ZIMmMwT6SSzEDyRuZy9rBS+Ln1ms97kZGS/lqDlrhjjTyfxbqQFf6KVt H6YkMHMzndK3eUb9lRCpHcUlOgsUMV+pxch8OnIm0Tw+y0P9M2iQLKoibHgu1MQUwPlu ALztHVtemtLRZ37i59KKB4ZE37YYlIPUczaOYzpGUuokHAVxK67IbT0OOTukaGiEmfBX 73B6kLI8OJOmYN1Wbz7DZ39pFEHxB68DVAr544NI2jNaOaMUEepZd6nGsGHku7DV6yA3 ottA== X-Gm-Message-State: AOAM5312Lfw7c2pMTqYkwN9hd0OiacupeGHVfHq6Kpp4RTC+vrTFryuW rQmVj9ngyKfIfUZOwvmorb4CUBxAvoI= X-Google-Smtp-Source: ABdhPJwWiFYZr3Q5fbofRzljRJxAj1m+16WwyxG+BH/oLNedUf/yhxGtwvPBxeLidDU9D7Ifwa1p0A== X-Received: by 2002:a05:651c:154:: with SMTP id c20mr2730355ljd.448.1641904266811; Tue, 11 Jan 2022 04:31:06 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id f19sm1319641lfg.298.2022.01.11.04.31.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 04:31:06 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: , "'Tommy Pauly'" References: <026601d80627$55c05970$01410c50$@gmail.com> In-Reply-To: Date: Tue, 11 Jan 2022 15:31:06 +0300 Message-ID: <02f401d806e7$1b5be950$5213bbf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINrN/IdsOuc0WzOJRkkxx4Plg45gI1M6jVAn97uTWrzMMDgA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 12:31:12 -0000 Hi Paul, > On Mon, 10 Jan 2022, Valery Smyslov wrote: > > > The responder does use an existing TCP connection to reply, > > but once it replies with cookie request, it should close this connection. > > If it keeps this connection, then it keeps TCP state until the client > > resends IKE_SA_INIT request (if ever) and thus thwarts the idea of being stateless. > > > > This is probably not so important for cookies, because the client > > has already proved during TCP handshake, that its IP is a real IP address, > > but it is more important in case of puzzles. But in both cases > > I think that keeping responder stateless is a good idea. > > Yes, stateless is good in those cases, but reality is we already used > state to setup the TCP connection. So why drop all that state now. It is > in a way too late for the "state creation savings". Instead, you are now > creating _more_ work for a server that might be under a DoS attack. I agree. That's why I added a clarification that TCP state SHOULD be closed if no repeated requests are received within some short period of time. > >> Additionally, a NAT router could give the client a different IP address > >> for a new TCP stream, making the COOKIE invalid. > > > > Yes, it is possible and this situation is covered in the draft. > > But if we choose between keeping the responder stateless and > > the possibility of occasional failure of cookie verification, > > I'd choose the former as more important. > > I am choosing the other way around :) That is that :-) > > I think we can slightly change this recommendation: > > > > o if the Responder chooses to send Cookie request (possibly along > > with Puzzle request), then the TCP connection that the IKE_SA_INIT > > request message was received over SHOULD be closed after the Responder sends its reply > > and no repeated requests are received within some short period of time, so that the > > Responder remains stateless. Note that if this TCP connection is > > closed, the Responder MUST NOT include the Initiator's TCP port > > into the Cookie calculation (*), since the Cookie will be returned > > over a new TCP connection with a different port. > > > > Does it address your concern? > > I don't really see much difference. If the attacker can setup a TCP > session, surely it can write 15 lines of python to replay the cookie > back as well. The question is really whether the responder under attack > is better of not needing as many TCP 3way handshakes versus keeping some > state. Since the document says to basically ignore cookies as much as > possible, it seems inline to just keep the TCP connection. It should be eventually closed in case the initiator never comes back. So, the question is - what time we consider appropriate for waiting the initiator's repeated request? The text above specify it as "some short period of time" and you may interpret it at your will. > >> Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for > >> additional messages in case it receives error notification from the > >> Responder in the IKE_SA_INIT exchange. > >> > >> This is true, but the code handlling this might not be aware of the > >> transport used. I'd rather see "an Initiator MAY skip the waiting time > >> for additional messages" so that this advice becomes "a good idea" and > >> not a "RFC violation" if not done. > > > > Hmm, I think that "SHOULD NOT wait" leaves you a possibility to wait > > if you have good reasons for it, without being accused in "RFC violation" :-) > > > > I have no problems with MAY in general, but I think that it's better > > to encourage implementers to make this optimization > > (which MAY does not). > > I'm looking at the damage here. There is again no good reason to tear > down the TCP connection for an INVALID_KE, so why tell implementations > to do that. Even if simple implementations might do that just because > that's how they do it for UDP (kill entire exchange, start a fresh one) This section is not about how you handle error notifications. It only tells that there is no reason to wait for another (probably good) response if error notification is received, it never comes (unlike UDP, when it is possible). How you handle error notification is out of scope of this section. > But I'd like to see us re-using the same TCP when receiving INVALID_KE, > even if it was only for the reduced latency of another 3way handshake. You may do it and by no means the draft suggests the opposite. Tearing down TCP is only advised in case of COOKIE (or PUZZLE) to keep the statelessness of the responder. And only if the client didn't immediately repeat its request. > >> Implementations that implement > >> both MOBIKE and TCP encapsulation MUST support dynamically enabling > >> and disabling TCP encapsulation as interfaces change. > >> > >> I'm not sure of the MUST here. Nice for sure, but perhaps the > >> implementation supports MOBIKE or TCP and not both at once ? > >> Perhaps restate as "if MOBIKE and TCP encapsulation are allowed for a > >> configuration, the implementation MUST support ...... > > > > OK. So, the text would look like: > > > > Implementations that implement both MOBIKE and TCP > > encapsulation and both are allowed for a configuration > > MUST support dynamically enabling and disabling TCP > > encapsulation as interfaces change. > > sure, just slightly different start: > > Implementations that implement both MOBIKE and TCP > encapsulation within the same connection configuration > MUST .... OK. > >> 8.3. IKEv2 Session Resumption > >> > >> This section says that if a TCP encap session was suspended, that the > >> client MUST use TCP to resume this. I don't understand why. It is likely > >> that a resuming client has moved networks, and might be on a network > >> that would properly support ESP or ESPinUDP. The resumption is really > >> mostly meant to skip over DH and AUTH phases as these are costly. I see > >> no reason to tie the transport to this. If I missed a valid reason > >> for this to be needed, clarify what needs to happen when the server no > >> longer can or wants to resume the session. Does the client close the TCP > >> and go back to UDP? > > > > I believe you are correct. The idea was to speed up SA resumption > > (we know that this responder didn't support UDP, but worked with UDP), > > however you are right that the situation may change. > > > > So the correct recommendation for the client would be - act as if this is the IKE_SA_INIT exchange. > > Yes, perfect. Great :-) Regards, Valery. > Paul From nobody Tue Jan 11 04:43:06 2022 Return-Path: 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 6C4913A084D for ; Tue, 11 Jan 2022 04:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjqGAyGvf8iW for ; Tue, 11 Jan 2022 04:42:59 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2713A083B for ; Tue, 11 Jan 2022 04:42:59 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id CCD362004E; Tue, 11 Jan 2022 14:42:56 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641904976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Oek0FlUpe4Hy4UHZkT0xGUQZLo5oBqtsiy/3f2cVlpE=; b=RnMhC87xn0QWOYSseIuzhkE8jiPwrt1TnFmi16XVHX0pKS7wdg0b39SDI9Zss/WO0sXgym JRpDP3+KtHxitb+OptOvCIqjPNjGPRcqOSMYsFu9FMYmImWhah+DTiB8ArcXdZKI1IOfaH FJA186NU1kmZ+/RCR0Dy5ck9ERaoric= Received: by fireball.acr.fi (Postfix, from userid 15204) id 85FD225C12E1; Tue, 11 Jan 2022 14:42:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25053.31538.461435.873239@fireball.acr.fi> Date: Tue, 11 Jan 2022 14:42:26 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Paul Wouters'" , , In-Reply-To: <02f301d806e2$83b74030$8b25c090$@gmail.com> References: <026601d80627$55c05970$01410c50$@gmail.com> <25052.47710.148277.213677@fireball.acr.fi> <02f301d806e2$83b74030$8b25c090$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1641904976; a=rsa-sha256; cv=none; b=LaSfleYZIWU9Lo6pGsBXJBQRNdlKLtm2/hbiCc6xL+ddicnaxPJCF8EHIiHqPeK5A82e7i eeHyxpy85xIIa1bmXm2WtHmy7phSNdNuanS1fg/ptcFhauoEJRJ+nGJa5XasurH9xeuY5u 59Oa+W5+O34gHlHArRPorqqA8UxryBA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641904976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Oek0FlUpe4Hy4UHZkT0xGUQZLo5oBqtsiy/3f2cVlpE=; b=gbvP759rurZjkO1n7XJ/uEUPEZ4Z83uHSnm5tcmnr6EVIIKUWVcEek+FWSd/8STGXISaX0 hmfNgVClkob6jRija7t7Hh1CL7eu8N49XllkPyTbVszV6IeX9cVI6PmmAOwx/DiTFrqsJt t1j5q4Fgn05gxOxrGEHBnecEFEpWyUc= Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 12:43:05 -0000 Valery Smyslov writes: > The latest text I proposed in reply to Paul's comments incorporates > this strategy: > > o if the Responder chooses to send Cookie request (possibly along > with Puzzle request), then the TCP connection that the IKE_SA_INIT > request message was received over SHOULD be closed after the Responder sends its reply > and no repeated requests are received within some short period of time, so that the > Responder remains stateless. Note that if this TCP connection is > closed, the Responder MUST NOT include the Initiator's TCP port > into the Cookie calculation (*), since the Cookie will be returned > over a new TCP connection with a different port. > > The text doesn't specify what "some short period of time" is. > I don't think we should do it (it may be 10 sec as you suggested > or 5 sec or 20 sec). > > Is it OK? Or should we probably change SHOULD to MAY here? I think it would be best to explain that valid clients usually return back almost immediately, so responders should keep tcp connection open for at least 10 seconds to receive the cookie responses, and after that SHOULD close the connection after some timeout. And perhaps add some words that depending on the puzzle difficulty level the timers might be modified (i.e., if you give puzzle that will require several minutes to solve, there is no point of waiting any more than the few seconds, but if you expect initiator to solve the puzzle in 5 seconds, then waiting 20 seconds is good thing). -- kivinen@iki.fi From nobody Tue Jan 11 04:53:49 2022 Return-Path: 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 7D7263A0949 for ; Tue, 11 Jan 2022 04:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKESXyvh_p-r for ; Tue, 11 Jan 2022 04:53:46 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF3F3A0923 for ; Tue, 11 Jan 2022 04:53:46 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id j11so55931835lfg.3 for ; Tue, 11 Jan 2022 04:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=io3Ch29dbMMTLg+nWkRRBQ+7FYu79ypTjvvfN3Ym0lM=; b=n2xa/dRre9K6E5mBpFG4Y7nXTAdoWNe18gZ9BU0oX/TvsIm5hthUO6llUa5WBE4YxF q4q4TVkCz8k/aEBd/HZ+oabeWqXLrS0OL/43kEgnkbS9NgzNF7Wmj4mr4OtQmcG1RfZF yyqw6PYvUVTLfcwVLA1UxkDYTlMvg1ZCU9sdopf4acrNlApy4fUX/LR8xDB3GwSc9Jjv fCu9e2EubM/eFSKi4+PPlAu2Rex0GKXqJcOzw+cNigqQDH0YcygKEzjdtoYCoOCPtSPm 3YkZXHZfqhMxOzHedh/v9B351s/XPf4pBkMno3lf7uwQPrvUTMNStFXEIewpHKuMdVOK u7VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=io3Ch29dbMMTLg+nWkRRBQ+7FYu79ypTjvvfN3Ym0lM=; b=cVBGqrzSlR3ahFRrgA+nu4/MXwTrZLjdLS29wg+62C90m+FhN4rQ+BMhpVbLKy5fiJ DBLfvxIOzZU8MUnt2zAyxRxYZksuiwgE5mjRf0kYq8Rwnja4t7gCa3TwTGtfLH6kWt+c OHU7uRGBTCtgFL2JA2EeMHZCUG/jDVDzOkLh30e5babis52+1UgKOCaebo69cuLQMpLN mLzNallPHHXNW2nU/tK2EMXiHLn/5p+8kCbVfvGWOwG99WUWAl/swy/9LtNabVyr2T2n UvJEhj7452eC9/rk6QEPF7V0w3EHXGyzpyANdidrMexIMyYtH4dEa4wqNcPeffmAXEbD xGEQ== X-Gm-Message-State: AOAM530avorLzYFS8AXJ7R32umIQbduZcCjZyID597u4owfeuyD07JWF EYvJPTClp07xpFXCye+WCP6VEPS5gOk= X-Google-Smtp-Source: ABdhPJw3kH8Jl2zuWhIZ0pAdpqNs6y0gLzeXNsb4B8JR3IoZzDGFszelF0iF62uEU+d62gh+3n1G8Q== X-Received: by 2002:a05:6512:1115:: with SMTP id l21mr3239347lfg.600.1641905623675; Tue, 11 Jan 2022 04:53:43 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id bi16sm1326452lfb.81.2022.01.11.04.53.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 04:53:43 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Paul Wouters'" , , References: <026601d80627$55c05970$01410c50$@gmail.com> <25052.47710.148277.213677@fireball.acr.fi> <02f301d806e2$83b74030$8b25c090$@gmail.com> <25053.31538.461435.873239@fireball.acr.fi> In-Reply-To: <25053.31538.461435.873239@fireball.acr.fi> Date: Tue, 11 Jan 2022 15:53:43 +0300 Message-ID: <02f901d806ea$44444b70$cccce250$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINrN/IdsOuc0WzOJRkkxx4Plg45gI1M6jVAd9ejX4CghRNFQHj45Mvq66k7FA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 12:53:49 -0000 > > o if the Responder chooses to send Cookie request (possibly along > > with Puzzle request), then the TCP connection that the IKE_SA_INIT > > request message was received over SHOULD be closed after the Responder sends its reply > > and no repeated requests are received within some short period of time, so that the > > Responder remains stateless. Note that if this TCP connection is > > closed, the Responder MUST NOT include the Initiator's TCP port > > into the Cookie calculation (*), since the Cookie will be returned > > over a new TCP connection with a different port. > > > > The text doesn't specify what "some short period of time" is. > > I don't think we should do it (it may be 10 sec as you suggested > > or 5 sec or 20 sec). > > > > Is it OK? Or should we probably change SHOULD to MAY here? > > I think it would be best to explain that valid clients usually return > back almost immediately, so responders should keep tcp connection open > for at least 10 seconds to receive the cookie responses, and after > that SHOULD close the connection after some timeout. I don't think we should advise any concrete values here, following RFC 7296 practice which deliberately avoided specifying concrete timeouts and also because they don't affect interoperability. But I agree that some explanations can be added and we can mention concrete values (say 10 secs) as examples. > And perhaps add some words that depending on the puzzle difficulty > level the timers might be modified (i.e., if you give puzzle that will > require several minutes to solve, there is no point of waiting any > more than the few seconds, but if you expect initiator to solve the > puzzle in 5 seconds, then waiting 20 seconds is good thing). OK, good idea to add some clarifications. Regards, Valery. > -- > kivinen@iki.fi From nobody Tue Jan 11 06:56:37 2022 Return-Path: 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 461E13A13C1; Tue, 11 Jan 2022 06:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShRRHLGyWBLO; Tue, 11 Jan 2022 06:56:28 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1DA3A143E; Tue, 11 Jan 2022 06:55:49 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id x7so57205682lfu.8; Tue, 11 Jan 2022 06:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=wkMmxGnQCTS/jnkUx5sq7aIhoXOtwHZ2Or9K/2qgZn4=; b=L8TnIJhgeSkd3f30jwvyWqxnOpJBP3D8cve9QTqTcjOV8FPQK12XpgBSuv05y33niq ZfjpYYRCkVdL3btv6VjOQtxyaEe90HTfuCNTqRyOjKlKa23PGF+N9Yzwtj1iUlct8nxJ Mamw3Lg1IWr5zJrU6B4QFPVsAyyUmnMgygEr5F54K0lq6k1TxJqxrxPz6BAyN9sWt7+Z 1k6nt1gxeb8SXvvbzWvsZ4kQhIpehHh9X6+1WwyLjXT/El8CIc7Y2csDJGoj0/Qu5q/Q jN4lzzSyf2YT7k+2h2hp4yjqNBpOfYaO6Z8o1wpIE24n2cK0OiLPUzumy3Z3xx6rnqKG TOTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=wkMmxGnQCTS/jnkUx5sq7aIhoXOtwHZ2Or9K/2qgZn4=; b=SZEpurWOJgF3dWzFO0AbGM9SyrITRlfGZXaC7CMbPksVj2fxmWGIMQl3jrQNr+qk+h paAgQZJ/v6TODrWSeWoNE2JduBmjlOftgEaMUep3BJo2mZ6Lquw23oeLiW77ThBaC9ks RXJp0riMy8O8WOwNA4T0bNVgt1F9KnIfz74LoSNVkyXDOley1hYUNcs4HpTrpAwkG1jn LcQ+UyEDAOkm8PVMRSN2Xa9P02UzHYBXVtGelvUHjiBR9FyLq7/dU2VJi8+94Si3GkHW 0eac57w68vuRm1oUo5q310LhqxJMs941gTh+eTOUkvieSuPfKg2uqRxMiG06w/akJX2j wd4g== X-Gm-Message-State: AOAM533G1TUIUlmYWaGBu/l7RmxwRHHYHb+BeTcXZPMMSHmZTxd0/1GG YYvD4UNfvidKFxYnr18jkftaeoY3clY= X-Google-Smtp-Source: ABdhPJyvCKtgPuxtPdAcWNtwgnAz49++jn9YTaue6kiIMnMozsB4ngKTDFEX3XDJjG8brrzH/EWzQQ== X-Received: by 2002:a2e:86da:: with SMTP id n26mr2243608ljj.232.1641912945574; Tue, 11 Jan 2022 06:55:45 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id t12sm1352963lfe.205.2022.01.11.06.55.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 06:55:45 -0800 (PST) From: "Valery Smyslov" To: "'Benjamin Kaduk'" , Cc: References: <20220110230404.GB11486@mit.edu> In-Reply-To: <20220110230404.GB11486@mit.edu> Date: Tue, 11 Jan 2022 17:55:45 +0300 Message-ID: <030701d806fb$50762e70$f1628b50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM59IL23922+PvL4U1LhgHv6EnHiamZ5oTQ Content-Language: ru Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 14:56:36 -0000 HI Ben, thank you for your review. > Hi all, >=20 > The core mechanisms here seem in good shape. My main area of > uncertainty relates to how much analysis, and with what degree of > formalism, has been applied to the updated IKE_AUTH procedures that = are > supposed to authenticate the intermediate exchange(s). My comments on > =A73.3.2 have more details, but key questions include how we = authenticate > how many rounds of IKE_INTERMEDIATE were performed, whether using the > plaintext of the Encrypted payload gives an attacker too much > flexibility, and whether we want to make any tweaks to "future-proof" > the construction in case we need some other exchange that occurs prior > to IKE_AUTH. >=20 > I'd also like to confirm that the current (lack of) Updates: > relationship between this document and RFC 7296 is correct. In = =A73.2, we > reaffirm that the normal IKE rules for assigning Message IDs apply, so > "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the = next > (if any) and so on". But in =A72.2 of RFC 7296 it is claimed that = "the > first pair of IKE_AUTH messages will have an ID of 1, the second (when > EAP is used) will be 2, and so on", where we now have competing claims > about what exchange will get Message ID 1. I can see a case to be = made > that neither of these statements is intended to be normative, and thus > that there is no conflict, but wanted to confirm that the WG had > considered this topic. Tero has already replied and I agree that we don't need to update RFC = 7296 -=20 the generic rule from Section 2.2 of RFC 7296 states: The Message ID is a 32-bit quantity, which is zero for the = IKE_SA_INIT messages ...=20 and incremented for each subsequent exchange. and this document doesn't violate it. > I see the shepherd writeup mentioned some missing articles ('a', = 'the', > etc.). I took the liberty of making some edits in that space to a = local > copy of the draft, which I will send to the author directly for him to > incorporate or ignore. Many thanks for this, really appreciated. > Section 3.2 >=20 > If the presence of NAT is detected in the IKE_SA_INIT exchange via > NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP > notifications, then the peers MUST switch to port 4500 and send all > IKE_INTERMEDIATE exchanges using port 4500. >=20 > I think I see an equivalent requirement in =A72.23 of RFC 7296 ("The = IKE > initiator MUST check the NAT_DETECTION_SOURCE_IP or > NAT_DETECTION_DESTINATION_IP payloads if present, and if they do not > match the addresses in the outer packet, MUST tunnel all future IKE = and > ESP packets associated with this IKE SA over UDP port 4500."), since = the > IKE_INTERMEDIATE exchanges would fall under "all future IKE packets". > So, does this need to be written in this was with normative MUST as if > it is a new requirement? Or should we rephrase slightly to reaffirm > that the existing requirement applies in this case? Good point. Will rephrase. > Section 3.3.2 >=20 > The requirement to support this behavior makes authentication > challenging: it is not appropriate to add on-the-wire content of = the > IKE_INTERMEDIATE messages into the AUTH payload calculation, = because > peers generally are unaware in which form other side has received > them. Instead, a more complex scheme is used - authentication is > performed by adding content of these messages before their = encryption > and possible fragmentation, so that data to be authenticated = doesn't > depend on the form the messages are delivered in. >=20 > The behavior of using the pre-encryption form of the messages in the > authentication seems to merit some closer inspection, as it opens up = an > avenue for the attacker to modify what bits are authenticated as they > traverse the network. >=20 > On first look, since the encryption is done using keys negotiated in = the > IKE_SA_INIT exchange, which is itself subject to IKE_AUTH > authentication, any tampering with the encrypted payloads would = require > tampering with the IKE_SA_INIT exchange (so as to have access to the = key > material needed), which would in turn be detected at time of IKE_AUTH. > But it would be reassuring to know that some more formal analysis has > been performed on this scenario. I'm not aware of any formal analysis (nor did it myself).=20 Some analysis and vetting of the current construction was done by Scott = Fluhrer and Daniel Van Geest: https://mailarchive.ietf.org/arch/msg/ipsec/n0QysCUXfgYUddrtWxtiEKvLqh4/ > In a similar vein, it would be good to see some more formal analysis > that confirms that this construction authenticates the number of > intermediate exchanges that have occurred. I am not sure that I could > sketch an attack that uses such a mismatch, but if we are using a = threat > model where IKE_INTERMEDIATE is used to provide protection against a > quantum computer that could break the initial IKE_SA_INIT key = exchange, > it seems like we need to be sure to protect against "truncation" = attacks > that cut the quantum-resistant key-exchange out of the authenticated > transcript. I agree that formal analysis would be good to have for this situation. Informally, if we are talking about = draft-ietf-ipsecme-ikev2-multiple-ke, then the SK_p* keys used for calculation of AUTH payload will depend not only on IKE_SA_INT, but on all subsequent (presumably quantum safe) key exchanges. And the peers always know how many IKE_INTERMEDIATE exchanges should take place (as a result of negotiation done in the = IKE_SA_INIT). Of course, an attacker in the middle can play a downgrade attack by modifying IKE_SA_INT so, that no quantum safe key exchanges are proposed = (or accepted), but in this case the peers will follow local policy - if it allows = quantum unsafe key exchanges to take place, then it cannot be helped. If we are talking about other applications of IKE_INTERMEDIATE (not = concerned with quantum safe cryptography), then it is possible that an attacker=20 equipped with quantum computer to break the authentication, but this is = also true for the current IKEv2 specification, when IKE_INTERMEDIATE is not = used. > If any IKE_INTERMEDIATE exchange took place, the definition of the > blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is > modified as follows: >=20 > InitiatorSignedOctets =3D RealMsg1 | NonceRData | MACedIDForI | = IntAuth > ResponderSignedOctets =3D RealMsg2 | NonceIData | MACedIDForR | = IntAuth >=20 > This sort of construction invites ambiguity if there is ever some = other > future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. = This > seems like a strong argument in support of the approach this draft > takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize = the > chance of needing such an additional future exchange. That said, it > might be possible to slightly improve the future-proofing if we = included > an indicator of what the "next content" after MACedIDFor[IR] is, such = as > the one-octet encoding of the exchange type. (I think it would have = to > be part of IntAuth_N, not IntAuth itself.) I don't have a great sense > for whether the value this adds would be worth the disruption to > existing implementations, though. If the WG thinks that it's worth to do this modification, then we may also consider addressing the following issue, raised past WGLC by Tobias Brunner: https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/ The WG reaction at that time was that the issue is minor and=20 no modification is needed, but _if_ we decide to incorporate Ben's modification, then we can address this issue too. And even if we decide to leave it out, some words should be added to=20 Security Considerations section anyway, I'll do it. > IKE_INTERMEDIATE exchanges took place). The prf is applied to the > the concatenation of two chunks of data: mandatory = IntAuth_*_[I/R]_A > optionally followed by IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A > chunk lasts from the first octet of the IKE Header (not including > prepended four octets of zeros, if port 4500 is used) to the last > octet of the Encrypted payload header. The IntAuth_*_[I/R]_P chunk >=20 > I think this would be more precise as "the last octet of the generic > payload header of the Encrypted payload". We do go on to say that the > IV/etc. are not included, but that seems to be in the context of > computing the _P chunk, and may or may not be saying anything about > excluding it from the _A calculation. The IV is not included, as with all AEAD algorithms defined for use with = IKEv2 so far. I'll add clarifications as you suggested. > is present if the Encrypted payload is not empty. It consists of = the >=20 > (editorial) I'd recommend including some keyword to provide a mnemonic > for the _A and _P suffixes for these intermediate values. The initial idea behind _A and _P was _A[AD] and _P[AYLOAD]. The _A chunk scope is equal to AAD for AEAD algorithms=20 and the _P scope is just a content of Encrypted Payload before encryption. But then it was figured out that the lines with formulas become too long and don't fit into RFC text format limitations. So, the names were truncated in favor of formulas = readability. If you have good suggestions how to make these values look more friendly, it'll be great. > Section 3.4 >=20 > DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe = how > errors are handled in initial IKEv2 exchanges, these considerations > are also applied to the IKE_INTERMEDIATE exchange. >=20 > While the translation of the IKE_SA_INIT error handling to > IKE_INTERMEDIATE seems pretty straightforward, I wonder if we want to > say a little more about how the IKE_AUTH error handling applies. In > particular, I'm not sure if the portions about sending an > AUTHENTICATION_FAILED notification will ever apply. (The handling of > messages that contain an unsupported critical payload, on the other > hand, does seem like it would apply in a fairly straightforward = manner.) This is a good point. Will clarify. > Section 5 >=20 > Do we think there's a risk of IKE_INTERMEDIATE being used as a DoS > vector by way of causing a peer to retain a lot of state prior to > authentication? Perhaps that is more appropriate for the other > specifications that consume IKE_INTERMEDIATE. >=20 > attacker to mount Denial-of-Service attack. Moreover, if in this > situation the negotiated prf was not secure against preimage attack > with known key, then the attacker could forge the IKE_INTERMEDIATE >=20 > I think this would need to be a second-preimage attack, right? It's > probably worth clarifying. Yes, a second-preimage attack was meant. Fixed. Thank you, Valery. > Thanks, >=20 > Ben >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 11 19:53:29 2022 Return-Path: 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 39D0A3A076F; Tue, 11 Jan 2022 19:53:28 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAYsAuDwafP2; Tue, 11 Jan 2022 19:53:23 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E9F3A11B4; Tue, 11 Jan 2022 19:53:22 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JYYZ81tGVz3Gh; Wed, 12 Jan 2022 04:53:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1641959600; bh=RZ7lzddA73Im3DSc0gtDQp8DSGb/jY08h1SyQoJDuew=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OtWF8f0e3HQNxhcmgIfzxPGZh4UzqMam/fudSSSeBYN0agJBL1x/33xVl55WRCBG3 AFW43xaQjNL7ysbJzKY6aMcCsi8loK/f+JXPpsIL4gzu7x3VbjTjZNuAj7SYE7SwWh +pCmAnT6KZ1YKlJ/nu2LD38++KL/sqX2VsqKDVM4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LBZFXdZVdfGJ; Wed, 12 Jan 2022 04:53:19 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 12 Jan 2022 04:53:19 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E909E1EDCD2; Tue, 11 Jan 2022 22:53:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E64D61EDCD1; Tue, 11 Jan 2022 22:53:17 -0500 (EST) Date: Tue, 11 Jan 2022 22:53:17 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'Benjamin Kaduk' , draft-ietf-ipsecme-ikev2-intermediate.all@ietf.org, ipsec@ietf.org In-Reply-To: <030701d806fb$50762e70$f1628b50$@gmail.com> Message-ID: <2d5ea75-3a9-b788-4eb3-a24dcb258c9@nohats.ca> References: <20220110230404.GB11486@mit.edu> <030701d806fb$50762e70$f1628b50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 03:53:28 -0000 On Tue, 11 Jan 2022, Valery Smyslov wrote: >> This sort of construction invites ambiguity if there is ever some other >> future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. This >> seems like a strong argument in support of the approach this draft >> takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize the >> chance of needing such an additional future exchange. That said, it >> might be possible to slightly improve the future-proofing if we included >> an indicator of what the "next content" after MACedIDFor[IR] is, such as >> the one-octet encoding of the exchange type. (I think it would have to >> be part of IntAuth_N, not IntAuth itself.) I don't have a great sense >> for whether the value this adds would be worth the disruption to >> existing implementations, though. I think this makes sense, and I would be okay with such a change. > If the WG thinks that it's worth to do this modification, then > we may also consider addressing the following issue, > raised past WGLC by Tobias Brunner: > https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/ > The WG reaction at that time was that the issue is minor and > no modification is needed, but _if_ we decide to incorporate > Ben's modification, then we can address this issue too. I'm not sure this is needed. Implementations will anyway limit the number of IKE_INTERMEDIATE exchanges they are willing to accept to some reasonably very low number. Although if others want this, I won't object. > And even if we decide to leave it out, some words should be added to > Security Considerations section anyway, I'll do it. That makes sense. Paul From nobody Wed Jan 12 15:39:35 2022 Return-Path: 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 3DC323A0B0D; Wed, 12 Jan 2022 15:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgJP_yowYYUW; Wed, 12 Jan 2022 15:39:31 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E0E3A0B0C; Wed, 12 Jan 2022 15:39:31 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20CNdMbT006739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jan 2022 18:39:28 -0500 Date: Wed, 12 Jan 2022 15:39:21 -0800 From: Benjamin Kaduk To: Tero Kivinen Cc: draft-ietf-ipsecme-ikev2-intermediate.all@ietf.org, ipsec@ietf.org Message-ID: <20220112233921.GH11486@mit.edu> References: <20220110230404.GB11486@mit.edu> <25053.30365.853374.402503@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <25053.30365.853374.402503@fireball.acr.fi> Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 23:39:33 -0000 Hi Tero, On Tue, Jan 11, 2022 at 02:22:53PM +0200, Tero Kivinen wrote: > Benjamin Kaduk writes: > > I'd also like to confirm that the current (lack of) Updates: > > relationship between this document and RFC 7296 is correct. In §3.2, we > > reaffirm that the normal IKE rules for assigning Message IDs apply, so > > "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next > > (if any) and so on". But in §2.2 of RFC 7296 it is claimed that "the > > first pair of IKE_AUTH messages will have an ID of 1, the second (when > > EAP is used) will be 2, and so on", where we now have competing claims > > about what exchange will get Message ID 1. I can see a case to be made > > that neither of these statements is intended to be normative, and thus > > that there is no conflict, but wanted to confirm that the WG had > > considered this topic. > > The text in RFC7296 section 2.2 is not normative, it is example of > what will happen when the normal case. I.e., first exchange will have > message id 0, and second exchange will have message id 1 etc, for > normal use of IKEv2 the first exchange will be IKE_SA_INIT and second > exchange will be IKE_AUTH. > > In case IKE_INTERMEDIATE, the first exchange (message id 0) will be > IKE_SA_INIT, and second exchange (message id 1) will be > IKE_INTERMEDIATE. For the G-ikev2 the first exchange (message id 0) > will be IKE_SA_INIT and second exchange (message id 1) will be > GSA_AUTH. For RFC5723 (Resumption) the first exchange (message id 0) > will be IKE_SESSION_RESUMPTION, and second exchange (message id 1) > will be IKE_AUTH. Thanks for confirming! > > In a similar vein, it would be good to see some more formal analysis > > that confirms that this construction authenticates the number of > > intermediate exchanges that have occurred. I am not sure that I could > > sketch an attack that uses such a mismatch, but if we are using a threat > > model where IKE_INTERMEDIATE is used to provide protection against a > > quantum computer that could break the initial IKE_SA_INIT key exchange, > > it seems like we need to be sure to protect against "truncation" attacks > > that cut the quantum-resistant key-exchange out of the authenticated > > transcript. > > Note, that you are here mixing properties from two different > protocols, ikev2 intermediate and ikev2 multiple ke. IKEv2 > intermediate is supposed to be used to transport large data between > IKE_SA_INIT and IKE_AUTH. It is not supposed to be quantum resistant > by itself. Agreed. This was just an attempt to motivate a sketch of a scenario where the "truncation attack" might be relevant. > Quantum resistant part is provided by the multiple key exchanges. > I.e., every single key exchange run between IKE_SA_INIT and IKE_AUTH > will provide new cryptographic keys to be used for all future > IKE_INTERMEDIATE exchanges and those new keys depends on all previous > key exchanges done. > > I.e., when using multiple ke only the first IKE_INTERMEDIATE exchange > uses the diffie-hellman from the IKE_SA_INIT. The end result of the > that IKE_INTERMEDIATE is to generate new cryptographic keys using the > fomula from 3.2.2 of draft-ietf-ipsecme-ikev2-multiple-ke: > > SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) > > and > > {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | > SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) > > where the SK_d(n-1) is the key derivation key generated by the > previous step, i.e., in this case the Diffie-Hellman of the > IKE_SA_INIT. > > So every single multiple key exchange run between the IKE_SA_INIT and > IKE_AUTH will contribute to the final encryption and authentication > keys used for IKE_AUTH. Agreed. But prior to that point, the Nth IKE_INTERMEDIATE exchange can be attacked if the initial IKE_SA_INIT exchange and all IKE_INTERMEDIATE exchanges prior to the Nth are compromised in realtime. (Admittedly a strong assumption.) > This protects against attacks where attacker tries to remove any of > the multiple key exchanges from the transcript. > > On the other hand IKE_INTERMEDIATE might also be used for use cases > which do not generate keys, for example to transfer some kind of > policy configuration information before IKE_AUTH etc. The > IKE_INTERMEDIATE needs to provide the protection against those > exchanges too, and adding them to the signed data should provide > protection against attackers. The question I want to probe here focuses more on the non-cryptographic input to the signature/MAC, as distinct from the actual key used to make the MacedIDfor* input. This question remains relevant even if we have some uses of IKE_INTERMEDIATE other than multiple-ke. In short, I expect that we have defense in depth, and one part of that (for multiple-ke) is the actual key used for the MACedIDFor* MAC. Is there another part of that defense in depth that, say, authenticates the Message ID of the AUTH message? I think that there are new avenues for attack available if the attacker is able to cause the initiator and responder to use InitiatorSignedOctets/ResponderSignedOctets that are of different lengths on the two parties. (These are not complete attacks on their own, of course, due to the defense in depth.) > If I remember correct TLS does the same, the final transcript hash is > hash of all messages concatenated together including the handshake > message header, but exlucing record layer headers... Yes, the TLS transcript hashes all messages concatenated together, but in TLS there's a clear "end" signal in the Finished message (and the pretty static handshake structure). Any new messages added to the handshake by extensions are explicitly negotiated, and that negotiation itself is protected by the transcript hash. Here, we just have "the usual stuff, followed by one or more IntAuth_N chunks", with no clear "end" marker. -Ben From nobody Wed Jan 12 16:18:14 2022 Return-Path: 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 6B6983A0ED7; Wed, 12 Jan 2022 16:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4RtgY-Ve6Gj; Wed, 12 Jan 2022 16:18:09 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4880A3A0ED6; Wed, 12 Jan 2022 16:18:09 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20D0Hxjf017662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jan 2022 19:18:05 -0500 Date: Wed, 12 Jan 2022 16:17:59 -0800 From: Benjamin Kaduk To: Valery Smyslov Cc: draft-ietf-ipsecme-ikev2-intermediate.all@ietf.org, ipsec@ietf.org Message-ID: <20220113001759.GI11486@mit.edu> References: <20220110230404.GB11486@mit.edu> <030701d806fb$50762e70$f1628b50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <030701d806fb$50762e70$f1628b50$@gmail.com> Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 00:18:13 -0000 Hi Valery, Trimming as appropriate... On Tue, Jan 11, 2022 at 05:55:45PM +0300, Valery Smyslov wrote: > > > Section 3.3.2 > > > > The requirement to support this behavior makes authentication > > challenging: it is not appropriate to add on-the-wire content of the > > IKE_INTERMEDIATE messages into the AUTH payload calculation, because > > peers generally are unaware in which form other side has received > > them. Instead, a more complex scheme is used - authentication is > > performed by adding content of these messages before their encryption > > and possible fragmentation, so that data to be authenticated doesn't > > depend on the form the messages are delivered in. > > > > The behavior of using the pre-encryption form of the messages in the > > authentication seems to merit some closer inspection, as it opens up an > > avenue for the attacker to modify what bits are authenticated as they > > traverse the network. > > > > On first look, since the encryption is done using keys negotiated in the > > IKE_SA_INIT exchange, which is itself subject to IKE_AUTH > > authentication, any tampering with the encrypted payloads would require > > tampering with the IKE_SA_INIT exchange (so as to have access to the key > > material needed), which would in turn be detected at time of IKE_AUTH. > > But it would be reassuring to know that some more formal analysis has > > been performed on this scenario. > > I'm not aware of any formal analysis (nor did it myself). > Some analysis and vetting of the current construction was done by Scott Fluhrer and Daniel Van Geest: > https://mailarchive.ietf.org/arch/msg/ipsec/n0QysCUXfgYUddrtWxtiEKvLqh4/ Thanks for the link! Yoav, could you update the shepherd writeup to mention this thread? > > In a similar vein, it would be good to see some more formal analysis > > that confirms that this construction authenticates the number of > > intermediate exchanges that have occurred. I am not sure that I could > > sketch an attack that uses such a mismatch, but if we are using a threat > > model where IKE_INTERMEDIATE is used to provide protection against a > > quantum computer that could break the initial IKE_SA_INIT key exchange, > > it seems like we need to be sure to protect against "truncation" attacks > > that cut the quantum-resistant key-exchange out of the authenticated > > transcript. > > I agree that formal analysis would be good to have for this situation. > > Informally, if we are talking about draft-ietf-ipsecme-ikev2-multiple-ke, > then the SK_p* keys used for calculation of AUTH payload will depend > not only on IKE_SA_INT, but on all subsequent (presumably quantum safe) > key exchanges. And the peers always know how many IKE_INTERMEDIATE > exchanges should take place (as a result of negotiation done in the IKE_SA_INIT). > Of course, an attacker in the middle can play a downgrade attack by > modifying IKE_SA_INT so, that no quantum safe key exchanges are proposed (or accepted), > but in this case the peers will follow local policy - if it allows quantum unsafe > key exchanges to take place, then it cannot be helped. Just to confirm: the peers negotiate how many additional KEs to run, which is expected to also be the number of IKE_INTERMEDIATE exchanges, but could be smaller if IKE_INTERMEDIATE is also used for some other (as-yet-undefined) purpose in the same association. > If we are talking about other applications of IKE_INTERMEDIATE (not concerned > with quantum safe cryptography), then it is possible that an attacker > equipped with quantum computer to break the authentication, but this is also > true for the current IKEv2 specification, when IKE_INTERMEDIATE is not used. To reiterate on my reply to Tero, I'm thinking about the robustness of the system overall -- e.g., if we assume a highly capable attacker that can do many things we don't currently believe possible, like break DH and find certain types of hash collision, do we have a mechanism in place to ensure that the initiator and responder use transcripts of the same length? The point is not that we expect an attacker with such capabilities to appear, but rather to consider various aspects of the negotiation and confirm that we have a specific mechanism in the AUTH construction that protects that aspect of the negotiation. > > If any IKE_INTERMEDIATE exchange took place, the definition of the > > blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is > > modified as follows: > > > > InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth > > ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth > > > > This sort of construction invites ambiguity if there is ever some other > > future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. This > > seems like a strong argument in support of the approach this draft > > takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize the > > chance of needing such an additional future exchange. That said, it > > might be possible to slightly improve the future-proofing if we included > > an indicator of what the "next content" after MACedIDFor[IR] is, such as > > the one-octet encoding of the exchange type. (I think it would have to > > be part of IntAuth_N, not IntAuth itself.) I don't have a great sense > > for whether the value this adds would be worth the disruption to > > existing implementations, though. > > If the WG thinks that it's worth to do this modification, then > we may also consider addressing the following issue, > raised past WGLC by Tobias Brunner: > https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/ > > The WG reaction at that time was that the issue is minor and > no modification is needed, but _if_ we decide to incorporate > Ben's modification, then we can address this issue too. My instinct is to retain the current construction, but I don't remember enough about previous times that this class of construction has come up to be able to give a good reasoning for why. (I don't even remember if this type of thing came up in TLS, or SAAG, or elsewhere.) Perhaps there was some concern about some intermediate step being flawed or attacked so as to bias the distribution of that intermediate value, thereby weakening the authentication of the previous iterations, but I really don't remember for sure. > And even if we decide to leave it out, some words should be added to > Security Considerations section anyway, I'll do it. Sounds good. > > is present if the Encrypted payload is not empty. It consists of the > > > > (editorial) I'd recommend including some keyword to provide a mnemonic > > for the _A and _P suffixes for these intermediate values. > > The initial idea behind _A and _P was _A[AD] and _P[AYLOAD]. > The _A chunk scope is equal to AAD for AEAD algorithms > and the _P scope is just a content of Encrypted Payload > before encryption. But then it was figured out that the lines > with formulas become too long and don't fit into RFC text format > limitations. So, the names were truncated in favor of formulas readability. > If you have good suggestions how to make these values > look more friendly, it'll be great. My suggestion would just be to add a new sentence (before "The IntAuth_*_[I/R]_A chunk lasts from [...]"): "The IntAuth_*_[I/R]_A chunk covers the data that is the AAD input to AEAD algorithms protecting the Encrypted Payload, and the IntAuth_*_[I/R]_P chunk covers the plaintext input to such algorithms. It's not great writing, but it will probably get the job done. Thanks, Ben From nobody Thu Jan 13 05:41:19 2022 Return-Path: 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 8D0EC3A10E8; Thu, 13 Jan 2022 05:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJZzW9sq_N-N; Thu, 13 Jan 2022 05:41:14 -0800 (PST) Received: from dpmail.elvis.ru (dpmail.elvis.ru [93.188.44.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548A53A10FE; Thu, 13 Jan 2022 05:41:11 -0800 (PST) Received: from kmail.elvis.ru ([93.188.44.208]) by dpmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1n80Lh-0004uc-7p; Thu, 13 Jan 2022 16:41:07 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail.elvis.ru with esmtp (Exim 4.92) (envelope-from ) id 1n80Lh-0001ni-1Y; Thu, 13 Jan 2022 16:41:05 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Thu, 13 Jan 2022 16:41:04 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Thu, 13 Jan 2022 16:41:04 +0300 From: Valery Smyslov To: 'Benjamin Kaduk' , 'Valery Smyslov' CC: , References: <20220110230404.GB11486@mit.edu> <030701d806fb$50762e70$f1628b50$@gmail.com> <20220113001759.GI11486@mit.edu> In-Reply-To: <20220113001759.GI11486@mit.edu> Date: Thu, 13 Jan 2022 16:41:07 +0300 Message-ID: <045d01d80883$37c428d0$a74c7a70$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM59IL23922+PvL4U1LhgHv6EnHiQJI1OZrAkrT4vWpeG8u0A== Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-KLMS-AntiSpam-Interceptor-Info: not scanned X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2022/01/13 13:16:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2022/01/13 11:09:00 #18294613 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in dpmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 13:41:18 -0000 Hi Ben, > Trimming as appropriate... Further trimming... > > > In a similar vein, it would be good to see some more formal analysis > > > that confirms that this construction authenticates the number of > > > intermediate exchanges that have occurred. I am not sure that I could > > > sketch an attack that uses such a mismatch, but if we are using a threat > > > model where IKE_INTERMEDIATE is used to provide protection against a > > > quantum computer that could break the initial IKE_SA_INIT key exchange, > > > it seems like we need to be sure to protect against "truncation" attacks > > > that cut the quantum-resistant key-exchange out of the authenticated > > > transcript. > > > > I agree that formal analysis would be good to have for this situation. > > > > Informally, if we are talking about draft-ietf-ipsecme-ikev2-multiple-ke, > > then the SK_p* keys used for calculation of AUTH payload will depend > > not only on IKE_SA_INT, but on all subsequent (presumably quantum safe) > > key exchanges. And the peers always know how many IKE_INTERMEDIATE > > exchanges should take place (as a result of negotiation done in the IKE_SA_INIT). > > Of course, an attacker in the middle can play a downgrade attack by > > modifying IKE_SA_INT so, that no quantum safe key exchanges are proposed (or accepted), > > but in this case the peers will follow local policy - if it allows quantum unsafe > > key exchanges to take place, then it cannot be helped. > > Just to confirm: the peers negotiate how many additional KEs to run, which > is expected to also be the number of IKE_INTERMEDIATE exchanges, but could > be smaller if IKE_INTERMEDIATE is also used for some other > (as-yet-undefined) purpose in the same association. Yes, exactly. > > If we are talking about other applications of IKE_INTERMEDIATE (not concerned > > with quantum safe cryptography), then it is possible that an attacker > > equipped with quantum computer to break the authentication, but this is also > > true for the current IKEv2 specification, when IKE_INTERMEDIATE is not used. > > To reiterate on my reply to Tero, I'm thinking about the robustness of the > system overall -- e.g., if we assume a highly capable attacker that can do > many things we don't currently believe possible, like break DH and find > certain types of hash collision, do we have a mechanism in place to ensure > that the initiator and responder use transcripts of the same length? > The point is not that we expect an attacker with such capabilities to > appear, but rather to consider various aspects of the negotiation and > confirm that we have a specific mechanism in the AUTH construction that > protects that aspect of the negotiation. It is expected, that peers will negotiate new extensions which make use of IKE_INTERMEDIATE, so in general they will know how many the IKE_INTERMEDIATE exchanges would take place. However, I'd rather leave some flexibility here. See for example draft-smyslov-ipsecme-ikev2-qr-alt, where using IKE_INTERMEDIATE is optional on the Initiator's discretion. We can modify the calculation as you suggested in reply to Tero by appending MessageID of IKE_AUTH exchange at the IntAuth: IntAuth = IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]] | MID_IKE_AUTH Do you think it is enough? > > If the WG thinks that it's worth to do this modification, then > > we may also consider addressing the following issue, > > raised past WGLC by Tobias Brunner: > > https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/ > > > > The WG reaction at that time was that the issue is minor and > > no modification is needed, but _if_ we decide to incorporate > > Ben's modification, then we can address this issue too. > > My instinct is to retain the current construction, but I don't remember > enough about previous times that this class of construction has come up to > be able to give a good reasoning for why. (I don't even remember if this > type of thing came up in TLS, or SAAG, or elsewhere.) Perhaps there was > some concern about some intermediate step being flawed or attacked so as to > bias the distribution of that intermediate value, thereby weakening the > authentication of the previous iterations, but I really don't remember for > sure. Should we ask cryptographers to review it? > > > is present if the Encrypted payload is not empty. It consists of the > > > > > > (editorial) I'd recommend including some keyword to provide a mnemonic > > > for the _A and _P suffixes for these intermediate values. > > > > The initial idea behind _A and _P was _A[AD] and _P[AYLOAD]. > > The _A chunk scope is equal to AAD for AEAD algorithms > > and the _P scope is just a content of Encrypted Payload > > before encryption. But then it was figured out that the lines > > with formulas become too long and don't fit into RFC text format > > limitations. So, the names were truncated in favor of formulas readability. > > If you have good suggestions how to make these values > > look more friendly, it'll be great. > > My suggestion would just be to add a new sentence (before "The > IntAuth_*_[I/R]_A chunk lasts from [...]"): "The IntAuth_*_[I/R]_A chunk > covers the data that is the AAD input to AEAD algorithms protecting the > Encrypted Payload, and the IntAuth_*_[I/R]_P chunk covers the plaintext > input to such algorithms. It's not great writing, but it will probably get > the job done. This is not accurate wording. First, although AEAD algorithms are in fashion now, the IntAuth_*_* construction doesn't rely on them, so it's not correct in my opinion to mention AAD here. Yes, IntAuth_*_[I/R]_A covers what AAD for AEAD is, but if non-AEAD algorithm is used, then AAD is undefined, but IntAuth_*_[I/R]_A still have the same scope. And second, IntAuth_*_[I/R]_P is not equal to the plaintext for AEAD, since the plaintext would also include Padding and Pad Length fields which are excluded from IntAuth_*_[I/R]_P. How about: The IntAuth_*_[I/R]_A chunk covers the data that would be the AAD input to AEAD algorithms should they be used for protecting the Encrypted Payload (regardless of whether they are actually used), and the IntAuth_*_[I/R]_P chunk covers the plaintext input to such algorithms stripped of the Padding and the Pad Length fields. Does this text helps or only adds confusion? Regards, Valery. > Thanks, > > Ben From nobody Fri Jan 14 06:10:54 2022 Return-Path: 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 3A20E3A25A8; Fri, 14 Jan 2022 06:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGB70vXJYkHA; Fri, 14 Jan 2022 06:10:50 -0800 (PST) Received: from dpmail.elvis.ru (dpmail.elvis.ru [93.188.44.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCD43A25A7; Fri, 14 Jan 2022 06:10:47 -0800 (PST) Received: from kmail.elvis.ru ([93.188.44.208]) by dpmail.elvis.ru with esmtp (Exim 4.89) (envelope-from ) id 1n8NHt-0006JV-Il; Fri, 14 Jan 2022 17:10:44 +0300 Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail.elvis.ru with esmtp (Exim 4.92) (envelope-from ) id 1n8NHt-0000Dl-6x; Fri, 14 Jan 2022 17:10:41 +0300 Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 14 Jan 2022 17:10:41 +0300 Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Fri, 14 Jan 2022 17:10:41 +0300 From: Valery Smyslov To: 'Tero Kivinen' , CC: References: <25052.46852.971778.754673@fireball.acr.fi> In-Reply-To: <25052.46852.971778.754673@fireball.acr.fi> Date: Fri, 14 Jan 2022 17:10:44 +0300 Message-ID: <057b01d80950$854ba330$8fe2e990$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKWsEeKezoguBlVT9K+waDov0sD46rjq7RA Content-Language: ru X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru X-KLMS-AntiSpam-Interceptor-Info: not scanned X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: Clean, bases: 2022/01/14 13:22:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2022/01/14 04:58:00 #18303089 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Scanner: Rspamd work in dpmail.elvis.ru, WHITELIST Archived-At: Subject: Re: [IPsec] Comments to the g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 14:10:53 -0000 Hi Tero, many thanks for your review. > While reading the draft-ietf-ipsecme-g-ikev2-04 draft I started to > thinking whether we should get rid of the GSA_AUTH completely? > > We have several extensions or enhancements that change the way > IKE_SA_INIT and IKE_AUTH are done, and porting those changes to the > GSA_AUTH is going to require extra work, and looking how little > interest this draft has been receiving, I am wondering if we have > enough people to do that work. Those things include Intermediate > Exchange, Multiple Key Exchanges, Announcing Supported Authentication > Methods, EAP-Only Authentication (RFC5998), Signature Authentication > in IKEv2 (RFC7427), NULL authentication method (RFC7619), Mixing > Preshared keys for Post-Quantum security (RFC8784), etc.. > > My understanding is that we could simply remove the GSA_AUTH > completely, and say that g-ikev2 always uses normal IKE_SA_INIT, and > IKE_AUTH (with CHILDLESS_IKEV2_SUPPORTED from RFC6023) and then do > GSA_REGISTRATION as separate step. This would allow us to reuse all of > the extensions and enhancements we are working on for IKE_AUTH with > this g-ikev2 protocol for free, with cost of one extra round trip. > > Another option is to rewrite section 1.4.1 in such way that it is > clear that GSA_AUTH and IKE_AUTH are identical except that GSA_AUTH > does not include payloads for creating Child SA for unicast traffic > (SA*, TS*), but do include payloads for group keying (IDg, SAg, N, > GSA, KD, D). If it is clear that GSA_AUTH and IKE_AUTH use exactly > same processing from the authentication point of view, all the work > above should work without changes. It is my understanding that G-IKEv2 should inherit all extensions defined for IKEv2, so that GSA_AUTH and IKE_AUTH are almost the same. In fact, in my implementation they share a single code with small number of "if" statements making them behave a bit different. > The section 1.4.3/1.4.4 mostly already hints to that, but 1.4.1 is > more vague about it. We can make this more explicit by writing that GSA_AUTH is a variant of IKE_AUTH with different exchange type and slightly different properties and that G-IKEv2 implicitly inherits any extension defined in IKEv2 for use while IKE SA is being established (this includes, for example using IKE_INTERMEDIATE) unless an extension explicitly states the opposite. I think eliminating GSA_AUTH completely is also an option, but in this case some indication of the purpose of the IKE SA being created should be introduced, since there may be different policies at GCKS for IKEv2 and G-IKEv2 clients. > -- > > We should add following terms to the terminology section: > > GM, GCKS, KEK, TEK, Rekey SA, Data-Security SA, LKH, GSA_a, GSA_e, > Group SA, registration SA, Agree, will do. > and add bit more explansion what they are than just expanding the > acronym, i.e., explain that Rekey SA is equivalent of IKE SA of the > IKEv2, but over the multicast GSA_REKEY operations and is keyed by the > KEKs sent from the GCKS etc. The Rekey SA uses the current KEK that > provides the GSA_a and GSA_e used to protect GSA_REKEY. > > (and I have no idea what is some of the SAs are supposed to mean) OK. > -- > > In section 1.4.5.1. GSA_REKEY the text: > > G-IKEv2 rekeying MUST NOT support IKE SA windowing. > > is wrong, the implementations might support IKE SA windowing, but MUST > NOT use it... Fixed. > -- > > I assume that in section 1.4.5.1. GSA_REKEY the text: > > If implicit authentication is used, then AUTH_KEY MUST > NOT be sent to GMs. > > is trying to say that AUTH_KEY MUST NOT be sent to the GMs using > GSA_REKEY, it was sent during the GSA_AUTH or GSA_REGISTRATION to each > member separately, and will not be changed during the lifetime of the > multicast flow. No. If implicit authentication of GSA_REKEY messages is used, then they are authenticated by the fact that GMs verify their ICV. Since we assume that only GCKS (and other GMs in the group) knows the current SK_a, we implicitly authenticate it (no origin authentication is provided as with any symmetric key authentication). In this case no keys dedicated only for authentication (these keys are conveyed in the AUTH_KEY attribute during GM registration) are needed. > -- > > In section 1.4.5.1.1 it says: > > the content of the Encrypted payload is > encrypted and the ICV is computed using the current SKe/SKa keys. > > which is confusing as SKe and SKa keys are never defined. The RFC7296 > defines SK_a* and SK_e* keys, but those cannot be used for GSA_REKEY, > as GSA_REKEY is multicast message, and SK_a* and SK_e* from the > RFC7296 are generated per peer. They were meant to be SK_e/SK_a (typo, fixed) and the way they are obtained is defined in Section 2.4. > I assume those SKe and SKa are keys transmitted from the GCKS to GM > inside KD payloads or something. Yes, see Section 2.3. > On the other hand section 2.4 defines SK_e and SK_a, which are really > bad names, as they might get confused with RFC7296 SK_ei, SK_er, > SK_ai, and SK_ar. It we are supposed to use those SK_e and SK_a keys > here, then they needs to be renamed to something more distinct, like > GSK_e and GSK_a or something. I used these names so that they resemble SK_ei. SK_er and SK_ai, SK_ar and removing trailing "i" and "r" should have made them distinct from those. But I have no problem renaming them if they are still too similar. > The sections 1.4.5.1.2 and 1.4.5.1.3 talk about the "new KEK", and the > "current KEK", i.e., it does not talk about SKa/SK_a/SKe/SK_e, so it > is not clear how those are supposed to match. Oh, these are left over from terminology used in previous versions of the draft. They must be clarified. > -- > > In section 1.4.5.1.3 there is text: > > When a group member receives the Rekey Message from the GCKS it > decrypts the message using the current KEK, validates its > authenticity using the key retrieved in a previous G-IKEv2 exchange > if AUTH payload is present, verifies the Message ID, and processes > the GSA and KD payloads. > > The text "if AUTH payload is present" in the middle is bit funny, I > would assume we need to validate the authenticaty of the message > regardless whether the AUTH payload is present by checking the ICV > value. Sure. > When we check the ICV value we do know that the message is from > someone who knows the current KEK, i.e., at least someone in the > group, so that somewhat authenticates the message. Yes, and this is called "implicit authentication" in the draft. In case only implicit authentication is needed, AUTH payload may be omitted. > Of course having > digital signature AUTH payload authenticates the message originating > from the GCKS. On the other having AUTH payload PSK does not provide > any new information over the ICV, anybody who knows the PSK (i.e., > everybody in the group) and generate AUTH payloads using shared keys. Exactly. > I would actually explictly forbid using shared key authentication in > the AUTH payload of the GSA_REKEY, and only allow digital signature > methods. This idea is worth to think about. Implicit authentication appeared only in recent version of the draft and explicit one was left over not to break things. But you are right that there is no much value in using it. One possible reason is that in this case authentication key may be long lived and specifically generated with the desired security properties, while with implicit authentication keys are usually auto-generated and are changed with every rekey. Don't know how much this matters. system administers may have better control over the key used for authentication. I mean that this key may be generated with some desired security properties, that may differ from those of SK_a used for implicit authentication. > -- > > In section 1.4.6.1. text says: > > 5. When the SID-counter maintained by the GCKS reaches its final SID > value, no more SID values can be distributed. Before > distributing any new SID values, the GCKS MUST delete the Data- > Security SAs for the group, followed by creation of new Data- > Security SAs, and resetting the SID-counter to its initial > value. > > but earlied in the section it said: > > The group > member uses the same SID for each Data-Security SA specifying the use > of a counter-based mode of operation. > > I.e., the deteing the Data-Security SA does not reset SID, as the > group member will simply use same sid for newly created Data-Security > SA. Yes, the newly created Data-Security SA does have different key, > and there will not be nonce overlap with the previously used > Data-Security SA, but the GCKS does not get any SIDs it can give out. > > I think only way to reset SIDs is to remove all KEKs, i.e., forcing > everybody to do IKE_SA_INIT and GSA_AUTH/GSA_REGISTRATION again. Good catch. > In bullet 6 this is explained but only by with SHOULD. I think the > text should be rewritten to say that GCKS MUST delete the Rekey SA to > force all members to register. I tend to agree. > -- > > Section 1.4.6.2 should explictly mention that all SIDs are reset when > the Rekey SA is deleted. And also that deleting the IKE SA does NOT > remove SIDs, i.e., even when using GSA_INBAND_REKEY the GCKS need to > explictly delete Rekey SA using Delete payload having protocol ID of > GIKE_REKEY. It is a bit complex than that. Note, that using Rekey SA (rekeying over multicast) is optional. The GCKS may do rekeying over unicast SAs with each GM (using GSA_INBAND_REKEY), in this case Rekey SA is not installed. It is also possible not to rekey at all, so that data security SAs expires and GMs will re-register. But I agree that all these nuances should be clarified here. > -- > > In section 1.4.5.3 the text talks about the SPI value equal to zero, > but I think it is trying to say that the SPI Size field is zero and > SPI field is empty. No, it is not a typo, the text explicitly use zero SPI to indicate that all SAs for the particular protocol are deleted. I agree that it is possible to change the way to indicate this by sending zero-length SPI. This would save few bytes, but the question is - how it is handled in the code? In IKEv2 zero length SPI (along with zero protocol) is traditionally associated with IKE SA, but here the protocol field will be non-zero. It seems to me that semantically having zero SPI (and SPI length corresponding to the protocol) looks more appropriate. > -- > > In section 2.1.1 we could add note that if the RFC8784 is used then > the SK_d used is the one was already PRFed with PPK, thus the > generated SK_w will be quantum resistant. Will clarify. > -- > > Section 2.1.1. says that > > SK_w = prf+(SK_d, "Key Wrap for G-IKEv2") > > but then section 2.4 says: > > SK_e | SK_a | SK_w = KEYMAT > > I do not understand when section 2.4 is used? What is the KEYMAT in > that formula? Which SK_w is used for the GSA_AUTH or GSA_REGISTRATION > for encrypting keys with key wrap key of 0? I admit that text is not clear enough and I'll try to improve it. Section 2.1.1 defines how SK_w is obtained in the unicast IKE SA, when GM registers to the group. Section 2.4 defines how SK_e, SK_a , SK_w are obtained in the multicast Rekey SA when GCKS rekeys this SA. So, when GM is first contacted GCKS, the unicast IKE SA is created. For this SA SK_* are generated as defined in RFC 7296, the only key that is lacking is SK_w and it is calculated as defined in 2.1.1. SK_w allows GM to unwrap keys sent over this unicast SA. If GCKS is going to use multicast Rekey SA for rekeys, then among these keys will be keys for this multicast SA, so that GM is able to decrypt, authenticate its messages and unwrap new keys that will later be sent over it. The keys for multicast SA are sent (initially over unicast SA and lately may be sent over multicast SA) in the form of KEYMAT wrapped using the current SK_w. So, initially (in unicast SA) they are wrapped with SK_w from 2.1.1. The GM unwraps them and gets a new SK_w (and SK_a, SK_e) that it will use when it receives new keys over multicast Rekey SA. If multicast SA is rekeyed later, then GM will receive new keys in the form defined in 2.4 and use them for the new multicast SA. The things are a bit more complicated if LKH strategy is used. > -- > > In section 3.4.2 the SPI size and SPI fields for the GIKE_REKEY is set > to include the IKEv2 SPIs? Why is this? In RFC7296 we usually use SPI > size of 0, and empty SPI when we are talking about the IKE SA, and I > would have assumed that GIKE_REKEY protocol number is identically > identifying the Rekey SA. > > Ah, now I understand this is supposed to match the GSA_REKEY pseudo > exchange message SPIs. I think this text should be clarified about > this, and perhaps we need to add more text to the Rekey SA terminology > definition saying that where the IKE SPIs for that SA comes from. OK, will clarify. > Btw, can we have multiple GSA_REKEY pseudo exchange SAs? I.e., can > GCSK send multiple Group Security Association Policy substructures, > and send out multiple SPIs for those GSA_REKEY messages, so it can use > use different GSA_REKEY SPIs to send key updated to only some of the > SAs etc? > > I.e., one of those could use the Digital signatures and another one > could use NULL authentication? Current draft doesn't allow this. It is assumed that only one Rekey SA exists in every single period of time, but it can rekey itself over time in which case it is replaced with a new one. I think this design was chosen for simplicity. > -- > > In section 3.4.2.1.1 I have no idea what is security difference > between the Shared Key Message Integrity Code and NULL authentication? > Both of them are using group keys that are distributed to everybody in > the group, so what is the security benefits from the Shared Key > Message Integrity Code? There is not much difference. The primary difference is that with Shared Key Message Integrity Code the authentication key can be specifically generated and be long lived, so that the authentication key persisted between rekeys. > -- > > I do not like the GAP format specified in the 3.4.3. Having the first > 2 octes of zero overlapping the Protocol and SPI Size fields of the > normal substructures inside GSA is a hack, and I think it would be > better to simply allocate one protocol number for sending GAP. At > least change the figure 16 so that first 8-bits of the substructure is > Protocol, and that MUST be zero for the GAP, and next 8-bits are > reserved... > > Same for the Member Key Packet Substructure in section 3.5.3... It use protocol 0, no need for fake protocol to allocate :-) Yes, it's a bit of hack, but permissible in my opinion. Zero always mean "all", so in this case it means "for all protocols". I can change figures, no problem. > -- > > In section 3.7.1 the described behavior is different than what is > defined in the RFC7296. RFC7296 sends USE_TRASPORT_MODE notification > with protocol number 0, spi size of zero, and without SPI field. > > Section 3.10 of RFC7296 says: > > Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS, REKEY_SA, and > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > sent as zero and MUST be ignored on receipt. > > and as USE_TRASPORT_MODE is defined in the RFC7296 it uses this > method, and does not include SPI. I.e., sending multiple > USE_TRASPORT_MODE notifications as specified in the section 3.7.1 does > not work. I know this, and this is where G-IKEv2 behaves differently from IKEv2 (note, that sending Delete Payload with protocol 0 is also not allowed in IKEv2m but is used in G-IKEv2). > One way to fix this is to say that if GCKS wants to use both transport > mode and tunnel mode, it MUST use separate exchanges to do that, i.e, > first include one GSA_INBAND_REKEY / GSA_REKEY to send information > about tunnel mode SAs, and then do another GSA_INBAND_REKEY / > GSA_REKEY with USE_TRASPORT_MODE notification to send transport mode > SAs (and after doing the GSA_AUTH or GSA_REGISTRATION with tunnel or > transport mode, it needs to do extra GSA_INBAND_REKEY for other mode). I think it complicates things more than redefining USE_TRANSPORT_MODE for G-IKEv2 purposes. Alternatively we can allocate a new notify, say USE_MCAST_TRANSPORT_MODE with a different semantics. > -- > > Section 4.1. is not correct. The SK_w used to encrypt the keys inside > the KD payloads is protected by PPK, as it is derived from the SK_d > which is protected, thus all keying material transported in the > initial IKE SA is protected. As such I think all of the section 4.1 > can be removed, the mandatory or not example does not really belong to > this document, as my understanding is that this is default RFC8784 > behavior. I think you are correct. This section was written before the way keys are transported in the SA was completely redesigned and SK_w keys were introduced. Since then I didn't revise it and overlooked that the protection against QC is now achieved "for free". My bad. I don't think the section should be removed, since some information is still visible to an attacker equipped with QC, e.g. the parameters of the multicast SAs. The section should be rewritten instead. > -- > > Section 5.2.1 requires more text about the case where GSA_REKEY does > not use AUTH payload. Agree. Again, implicit authentication was introduced only recently, and this section was written long before. > -- > > Section 5.2.2 should include the fact that if RFC8784 is used then the > SK_w depends on the PPK, and all keying material wrapped inside the > G-IKEv2 are encrypted with either that key, or key encrypted depending > on that key. OK. > -- > > I do not really understand what section 5.2.3 is trying to say? The > normal GSA_AUTH is protected against the Man-in-the-middle by using > normal authentication either shared keys or signatures. The GSA_REKEY > is protected by the man in the middle by the fact that the keys used > in to encrypt and authenticate it are only known by the members of the > group. Note that group members do not have any need to be a man in the > middle, as they can generate GSA_REKEY unless digital signature AUTH > payloads are used. I agree that the current text is very formal. Will try to elaborate. Thank you again for the detailed review! Regards, Valery. > -- > kivinen@iki.fi From nobody Sat Jan 15 09:24:43 2022 Return-Path: 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 A4B963A0912; Sat, 15 Jan 2022 09:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv_seFf9Camg; Sat, 15 Jan 2022 09:24:38 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C57E3A090F; Sat, 15 Jan 2022 09:24:37 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id D524F1B002F7; Sat, 15 Jan 2022 19:24:33 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1642267474; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qGSqr7qvhlHkvua6aBIZyAhmyleMMeNyzLzs5cLbrbU=; b=Rq54Za8SDCz12o2kDm2y97kZ+1ECo+DEUi8plSnz29c9FcjrOAMYQ50bmYF++jo4vAHLEq G/JRj2PDC515NH6HiIkuVoz1iU5kpuDPKk6cPUz3x19qsdGYpTcb1NrD3vGEV0yFuOv8kN L80lSBeFv36LhD7QZQ8hwyE97eUrOachabLc/4DEMw7A/DJ8PAAYl9o/qpiS9ZDczT9Q71 oBx0zK8gCUtpVwu4cvyoU/QdNikOdoR3EgAP4e7SmDGHyt8p7BV0uJ3YGVS8stWcIaImY6 GF4lTCxOppTvavGwgmVDc+fICRWuNgTMI9tvjToX6LSIGJHCFs0EBgHYyRnwLA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 562D025C12E5; Sat, 15 Jan 2022 19:24:33 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25059.849.299801.984109@fireball.acr.fi> Date: Sat, 15 Jan 2022 19:24:33 +0200 From: Tero Kivinen To: Valery Smyslov Cc: , In-Reply-To: <057b01d80950$854ba330$8fe2e990$@elvis.ru> References: <25052.46852.971778.754673@fireball.acr.fi> <057b01d80950$854ba330$8fe2e990$@elvis.ru> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 33 min X-Total-Time: 160 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1642267474; a=rsa-sha256; cv=none; b=CnNDA4a0AEm7zF6xDT2XAEb16oPXbvabMI8jOWs+7I8Fk2voiEAsprLFsWDAq8Uthlnm1+ 528gtb+4w+8eQBQVb2G6Q6QPHiBSlbWcqVTTxmo+SOFNAOb+zDBIck/48/WNWfZiI7RpeC iWoKQ6qZBWh7oWWkJVx41w51JSoN3o0reyXFTVcbm5eaIWGmhxUZbXRRBBK/q007e/Imk6 5k0a440C0YUoRdb0MWSDAM+f6JUPyICGhigbWzkJwjgayWJ0ndWIAYF0vKiDBYXgFhaFjJ MFC1jHcmJeno0v83YfdsZXrkUtQRbUK5l9J9ajCPy3cL8DMsIwGIXmb9QJ0+cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1642267474; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qGSqr7qvhlHkvua6aBIZyAhmyleMMeNyzLzs5cLbrbU=; b=VBXO4UNmIcqxT0I7e4bXuwTmg4PwgheGBfKaw0xmarHf0fu8qI7TSACkT3MCY/yMcxyzi5 Je6+SMPJxX8+axcvudUYkFij1Xq4Y25xuYtO8kn8XTUK9SkiFIBRjfXEpeYRES0gg6lYZD 0eMBRZ501bwoVxNHjmEIr0Qvz8G1Uizpb8yr0hSMp5yD2YbCRoiSzTSoPf74t4KL9Yt3+M c7CdP7Abftq6kYwkXBb6pANeTmjC/p6H57MS7eQwtC4LDJi6s7BzVVz/Ig8S+PZKHMldA6 M6+nZ0tyYbJR0qEtxrOO+APYG4Cd6X6993nAkATg5i8SPUOT65HRDqMGGPN/Ag== Archived-At: Subject: Re: [IPsec] Comments to the g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2022 17:24:41 -0000 Valery Smyslov writes: > > The section 1.4.3/1.4.4 mostly already hints to that, but 1.4.1 is > > more vague about it. > > We can make this more explicit by writing that > GSA_AUTH is a variant of IKE_AUTH with different exchange type > and slightly different properties and that G-IKEv2 implicitly inherits > any extension defined in IKEv2 for use while IKE SA is being established > (this includes, for example using IKE_INTERMEDIATE) unless > an extension explicitly states the opposite. Now, after some time of thinking about this I think we should exactly that, i.e., explain that GSA_AUTH is exactly same as IKE_AUTH except it does not have payloads for creating IPsec unicast SA, but will add payloads for creating multicast SAs. I.e., add text to the 1.4.1 which explicitly says that. > I think eliminating GSA_AUTH completely is also an option, but > in this case some indication of the purpose of the IKE SA being created > should be introduced, since there may be different policies > at GCKS for IKEv2 and G-IKEv2 clients. I think if we can share everything between IKE_AUTH and GSA_AUTH and we are carefull with how we defined future extesions we should probably keep the GSA_AUTH, as it does save one round trip... > > I assume that in section 1.4.5.1. GSA_REKEY the text: > > > > If implicit authentication is used, then AUTH_KEY MUST > > NOT be sent to GMs. > > > > is trying to say that AUTH_KEY MUST NOT be sent to the GMs using > > GSA_REKEY, it was sent during the GSA_AUTH or GSA_REGISTRATION to each > > member separately, and will not be changed during the lifetime of the > > multicast flow. > > No. If implicit authentication of GSA_REKEY messages is used, then > they are authenticated by the fact that GMs verify their ICV. > Since we assume that only GCKS (and other GMs in the group) > knows the current SK_a, we implicitly authenticate it (no origin > authentication is provided as with any symmetric key authentication). > In this case no keys dedicated only for authentication > (these keys are conveyed in the AUTH_KEY attribute during GM registration) > are needed. Ok. The next question is we most likely want to make sure that one Rekey SA can't update the AUTH_KEY for another rekey SA? I.e., the SPIs inside the SA payload must match this Rekey SA if it contains AUTH_KEY payloads to upda the authentication key of this rekey SA? Or do we disallow multicast AUTH_KEY completely? We must not allow one shared key rekey SA to update another rekey sa using public key signatures, but we might want to allow GCKS to update its public key by sending new AUTH_KEY for this rekey SA. Do we have some text somewhere that explictly allows/forbids that. I assume we disallow changing authentication method using GSA_REKEY, i.e., there is no way for moving from implicit authentication (or shared key authentication) to public key signatures? As there is no origin authentication in implicit authentication or shared key authentication we do not want to use them to update the rekey sa to public key signatures. > > I would actually explictly forbid using shared key authentication in > > the AUTH payload of the GSA_REKEY, and only allow digital signature > > methods. > > This idea is worth to think about. Implicit authentication appeared > only in recent version of the draft and explicit one was left over > not to break things. But you are right that there is no much value > in using it. One possible reason is that in this case authentication > key may be long lived and specifically generated with the desired > security properties, while with implicit authentication keys are > usually auto-generated and are changed with every rekey. Don't know > how much this matters. I would asume auto-generated keys are most likely much more secure than shared keys used by the adminstrators.... > system administers may have better control over the key used for > authentication. I mean that this key may be generated with some > desired security properties, that may differ from those of SK_a used > for implicit authentication. There is already pairwise authentication key used in the GSA_AUTH, and not sure if there is any reason to have another long lived authentication shared key for specific SAs, explictly one that is shared with lots of clients. > > In section 1.4.5.3 the text talks about the SPI value equal to zero, > > but I think it is trying to say that the SPI Size field is zero and > > SPI field is empty. > > No, it is not a typo, the text explicitly use zero SPI to indicate > that all SAs for the particular protocol are deleted. I agree that > it is possible to change the way to indicate this by sending > zero-length SPI. This would save few bytes, but the question is - > how it is handled in the code? In IKEv2 zero length SPI (along with > zero protocol) is traditionally associated with IKE SA, but here the > protocol field will be non-zero. It seems to me that semantically > having zero SPI (and SPI length corresponding to the protocol) looks > more appropriate. Ok. For special SPI value that indicates all possible SAs, I agree that having some reserved SPI value (like zero), makes more sense. > > Btw, can we have multiple GSA_REKEY pseudo exchange SAs? I.e., can > > GCSK send multiple Group Security Association Policy substructures, > > and send out multiple SPIs for those GSA_REKEY messages, so it can use > > use different GSA_REKEY SPIs to send key updated to only some of the > > SAs etc? > > > > I.e., one of those could use the Digital signatures and another one > > could use NULL authentication? > > Current draft doesn't allow this. It is assumed that only one Rekey SA exists > in every single period of time, but it can rekey itself over time in which > case it is replaced with a new one. I think this design was chosen > for simplicity. Ok. As I said there are so many different types of SAs there and I am not really sure their relations to each other. Clarifying that in the beginning in the terminology section may make things easier to understand. > > In section 3.7.1 the described behavior is different than what is > > defined in the RFC7296. RFC7296 sends USE_TRASPORT_MODE notification > > with protocol number 0, spi size of zero, and without SPI field. > > > > Section 3.10 of RFC7296 says: > > > > Of the notifications defined in this document, the SPI is > > included only with INVALID_SELECTORS, REKEY_SA, and > > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > > sent as zero and MUST be ignored on receipt. > > > > and as USE_TRASPORT_MODE is defined in the RFC7296 it uses this > > method, and does not include SPI. I.e., sending multiple > > USE_TRASPORT_MODE notifications as specified in the section 3.7.1 does > > not work. > > I know this, and this is where G-IKEv2 behaves differently from IKEv2 > (note, that sending Delete Payload with protocol 0 is also not allowed > in IKEv2m but is used in G-IKEv2). > > > One way to fix this is to say that if GCKS wants to use both transport > > mode and tunnel mode, it MUST use separate exchanges to do that, i.e, > > first include one GSA_INBAND_REKEY / GSA_REKEY to send information > > about tunnel mode SAs, and then do another GSA_INBAND_REKEY / > > GSA_REKEY with USE_TRASPORT_MODE notification to send transport mode > > SAs (and after doing the GSA_AUTH or GSA_REGISTRATION with tunnel or > > transport mode, it needs to do extra GSA_INBAND_REKEY for other mode). > > I think it complicates things more than redefining USE_TRANSPORT_MODE > for G-IKEv2 purposes. Alternatively we can allocate a new notify, say > USE_MCAST_TRANSPORT_MODE with a different semantics. We need to point this out much more strongly, i.e., explain that behavior is different from the RFC7296. Allocating new notify just for that might be even better, as then we do no need to "Update" 7296... > > Section 4.1. is not correct. The SK_w used to encrypt the keys inside > > the KD payloads is protected by PPK, as it is derived from the SK_d > > which is protected, thus all keying material transported in the > > initial IKE SA is protected. As such I think all of the section 4.1 > > can be removed, the mandatory or not example does not really belong to > > this document, as my understanding is that this is default RFC8784 > > behavior. > > I think you are correct. This section was written before the way > keys are transported in the SA was completely redesigned and SK_w > keys were introduced. Since then I didn't revise it and overlooked that > the protection against QC is now achieved "for free". My bad. > > I don't think the section should be removed, since some > information is still visible to an attacker equipped with QC, > e.g. the parameters of the multicast SAs. The section > should be rewritten instead. Works for me. > Thank you again for the detailed review! I just want to get this document out also, and there does not seem to be that many people interested in it, so I had to do my review of it already now. Usually I do my full reviews only after WGLC while doing shephard writeup, but moved it bit earlier now just to get things going forward. -- kivinen@iki.fi From nobody Sat Jan 15 09:27:31 2022 Return-Path: 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 454893A0955; Sat, 15 Jan 2022 09:27:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164226764919.4078.8366815758637038734@ietfa.amsl.com> Date: Sat, 15 Jan 2022 09:27:29 -0800 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 113 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2022 17:27:29 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): unspecified Number of Attendees: 30 Conflicts to Avoid: Chair conflict: tls acme Technology overlap: cfrg curdle lamps tls People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jan 17 04:34:34 2022 Return-Path: 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 BD37A3A1065; Mon, 17 Jan 2022 04:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vkrNiKM3u-9; Mon, 17 Jan 2022 04:34:28 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62C13A1067; Mon, 17 Jan 2022 04:34:27 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id m1so57048953lfq.4; Mon, 17 Jan 2022 04:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=4ZGqd3k4qLShh4knLNuFqhddqXsr6UHcgRPvCVBOsRk=; b=m5DHyKgfrk2T7hIrWgv1/QpowoCoTDpkBCbjkrOQPAPVWbUuQv6l5z+csy9F431P/F cHkj9SJYbcjadz2oS6ytIvDGOpZOAkpIUUhmwvfeaf/1VgO2Pn2vA5yBKNsHEn/nlyaD Cn9dg1gIKcMfB4OZ9HTuXXGDYthZ8jdEhbISGFd85TJCwg6NePskaPUCMmDK9rUhplxt 8QwiiSIPuLNeMMQalX1aQZT0ZHqgEqT1wd5fHy66M7RI1YrlUL0Rs7n4jzwMnhFjqNju IE5rMzkvSoOTeCZIWIhF88/xC6pFYU5CDM7lx/lOZ5KTPgFOX83q5WKdorrFgUY/gjQE 2jeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=4ZGqd3k4qLShh4knLNuFqhddqXsr6UHcgRPvCVBOsRk=; b=lIYjarm2ZsxEWukHWvd2fkspd8K4Yqm1llAxxihiUrA60r7OU6+cswYg7IWep95Jwz qRsSes5OaQw3dzWf/GSjaX89zf6HL2kx0y4Ns4ahHvqhm0hJ7VPsWTiXsHNHQT1DwkFl rgTMhxUjUuyKDywJJwxpbB9c4mYYu1D4Ty8DbCNapglRRLWj8ifp8CXg3f5CcBc89ICw QuFh4I++oBv04gvn9Z+7eKDvCLfF3XjC2QWBLWdR/HDenJwZoFMK97mU2ZaYXIIA59oc 6nxvnSq3qFVaoIRdLFpI6dHmalDeNNgtTLsZpKWCraeZzUvIyw7rL88XwVZcwV8JIFmq Zavg== X-Gm-Message-State: AOAM532YQlWZB93dl8tp72KL56aNPK3kS/ATmgbCBQVHVvgW3+jNHa67 TCW8ImOXQ0OKyU3l05yXIHqIWWNcQCg= X-Google-Smtp-Source: ABdhPJz/lK3o3wT/ApovP3+BxOucBybPmAWA3VMJH+6c38l1SmUNke2MwmTxWcnVaiKoxYHfssdcEA== X-Received: by 2002:a2e:8817:: with SMTP id x23mr123270ljh.59.1642422863984; Mon, 17 Jan 2022 04:34:23 -0800 (PST) Received: from svannotebook (78-107-207-25.broadband.corbina.ru. [78.107.207.25]) by smtp.gmail.com with ESMTPSA id t21sm687116lji.52.2022.01.17.04.34.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jan 2022 04:34:23 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Valery Smyslov'" Cc: , References: <25052.46852.971778.754673@fireball.acr.fi> <057b01d80950$854ba330$8fe2e990$@elvis.ru> <25059.849.299801.984109@fireball.acr.fi> In-Reply-To: <25059.849.299801.984109@fireball.acr.fi> Date: Mon, 17 Jan 2022 15:34:20 +0300 Message-ID: <060301d80b9e$8dfc2540$a9f46fc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: ru Thread-Index: AQKWsEeKezoguBlVT9K+waDov0sD4wI1sDoLAR5kN6GqzxEpAA== Archived-At: Subject: Re: [IPsec] Comments to the g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 12:34:33 -0000 > > We can make this more explicit by writing that GSA_AUTH is a variant > > of IKE_AUTH with different exchange type and slightly different > > properties and that G-IKEv2 implicitly inherits any extension defined > > in IKEv2 for use while IKE SA is being established (this includes, for > > example using IKE_INTERMEDIATE) unless an extension explicitly states > > the opposite. > > Now, after some time of thinking about this I think we should exactly that, i.e., > explain that GSA_AUTH is exactly same as IKE_AUTH except it does not have > payloads for creating IPsec unicast SA, but will add payloads for creating > multicast SAs. OK. > I.e., add text to the 1.4.1 which explicitly says that. > > > I think eliminating GSA_AUTH completely is also an option, but in this > > case some indication of the purpose of the IKE SA being created should > > be introduced, since there may be different policies at GCKS for IKEv2 > > and G-IKEv2 clients. > > I think if we can share everything between IKE_AUTH and GSA_AUTH and we > are carefull with how we defined future extesions we should probably keep > the GSA_AUTH, as it does save one round trip... OK, let's keep it and add more clarifications. > > > I assume that in section 1.4.5.1. GSA_REKEY the text: > > > > > > If implicit authentication is used, then AUTH_KEY MUST > > > NOT be sent to GMs. > > > > > > is trying to say that AUTH_KEY MUST NOT be sent to the GMs using > > > GSA_REKEY, it was sent during the GSA_AUTH or GSA_REGISTRATION to > > > each member separately, and will not be changed during the lifetime > > > of the multicast flow. > > > > No. If implicit authentication of GSA_REKEY messages is used, then > > they are authenticated by the fact that GMs verify their ICV. > > Since we assume that only GCKS (and other GMs in the group) knows the > > current SK_a, we implicitly authenticate it (no origin authentication > > is provided as with any symmetric key authentication). > > In this case no keys dedicated only for authentication (these keys are > > conveyed in the AUTH_KEY attribute during GM registration) are needed. > > Ok. The next question is we most likely want to make sure that one Rekey SA > can't update the AUTH_KEY for another rekey SA? I.e., the SPIs inside the SA > payload must match this Rekey SA if it contains AUTH_KEY payloads to upda > the authentication key of this rekey SA? There is only one Rekey SA active at any given period of time. There is no way to update AUTH_KEY in the current draft (the text at the end of 1.4.5.1 contradicts to the text in 3.5.3 and is a left-over from previous version of the document, but 3.5.3 is wrong too, since Member Packet can be sent in multicast rekey...). So, the AUTH_KEY is kind of constant. If GCKS wants to change it, all group SAs must be deleted causing GMs to re-register. If this is too restrictive, we can make this possible. > Or do we disallow multicast AUTH_KEY completely? We must not allow one > shared key rekey SA to update another rekey sa using public key signatures, > but we might want to allow GCKS to update its public key by sending new > AUTH_KEY for this rekey SA. Do we have some text somewhere that explictly > allows/forbids that. See above. > I assume we disallow changing authentication method using GSA_REKEY, i.e., > there is no way for moving from implicit authentication (or shared key > authentication) to public key signatures? As there is no origin authentication in > implicit authentication or shared key authentication we do not want to use > them to update the rekey sa to public key signatures. Makes sense, but see above. > > > I would actually explictly forbid using shared key authentication in > > > the AUTH payload of the GSA_REKEY, and only allow digital signature > > > methods. > > > > This idea is worth to think about. Implicit authentication appeared > > only in recent version of the draft and explicit one was left over not > > to break things. But you are right that there is no much value in > > using it. One possible reason is that in this case authentication key > > may be long lived and specifically generated with the desired security > > properties, while with implicit authentication keys are usually > > auto-generated and are changed with every rekey. Don't know how much > > this matters. > > I would asume auto-generated keys are most likely much more secure than > shared keys used by the adminstrators.... Shared key authentication with explicit key is mostly there because I didn't want to break things after adding implicit authentication. Since they provide mostly the same properties, I think we can get rid of one of them, unless someone disagrees. > > system administers may have better control over the key used for > > authentication. I mean that this key may be generated with some > > desired security properties, that may differ from those of SK_a used > > for implicit authentication. > > There is already pairwise authentication key used in the GSA_AUTH, and not > sure if there is any reason to have another long lived authentication shared > key for specific SAs, explictly one that is shared with lots of clients. I tend to agree. > > > Btw, can we have multiple GSA_REKEY pseudo exchange SAs? I.e., can > > > GCSK send multiple Group Security Association Policy substructures, > > > and send out multiple SPIs for those GSA_REKEY messages, so it can > > > use use different GSA_REKEY SPIs to send key updated to only some of > > > the SAs etc? > > > > > > I.e., one of those could use the Digital signatures and another one > > > could use NULL authentication? > > > > Current draft doesn't allow this. It is assumed that only one Rekey SA > > exists in every single period of time, but it can rekey itself over > > time in which case it is replaced with a new one. I think this design > > was chosen for simplicity. > > Ok. As I said there are so many different types of SAs there and I am not really > sure their relations to each other. Clarifying that in the beginning in the > terminology section may make things easier to understand. Will do. > > > One way to fix this is to say that if GCKS wants to use both > > > transport mode and tunnel mode, it MUST use separate exchanges to do > > > that, i.e, first include one GSA_INBAND_REKEY / GSA_REKEY to send > > > information about tunnel mode SAs, and then do another > > > GSA_INBAND_REKEY / GSA_REKEY with USE_TRASPORT_MODE > notification to > > > send transport mode SAs (and after doing the GSA_AUTH or > > > GSA_REGISTRATION with tunnel or transport mode, it needs to do extra > GSA_INBAND_REKEY for other mode). > > > > I think it complicates things more than redefining USE_TRANSPORT_MODE > > for G-IKEv2 purposes. Alternatively we can allocate a new notify, say > > USE_MCAST_TRANSPORT_MODE with a different semantics. > > We need to point this out much more strongly, i.e., explain that behavior is > different from the RFC7296. Allocating new notify just for that might be even > better, as then we do no need to "Update" 7296... I don't think we need to update RFC7296 in any case, since this new semantics would work only in the context of G-IKEv2. So, no update to existing IKEv2 implementations is needed. I don't have strong preference here. Allocating a new notify is a possible alternative too. > > > Section 4.1. is not correct. The SK_w used to encrypt the keys > > > inside the KD payloads is protected by PPK, as it is derived from > > > the SK_d which is protected, thus all keying material transported in > > > the initial IKE SA is protected. As such I think all of the section > > > 4.1 can be removed, the mandatory or not example does not really > > > belong to this document, as my understanding is that this is default > > > RFC8784 behavior. > > > > I think you are correct. This section was written before the way keys > > are transported in the SA was completely redesigned and SK_w keys were > > introduced. Since then I didn't revise it and overlooked that the > > protection against QC is now achieved "for free". My bad. > > > > I don't think the section should be removed, since some information is > > still visible to an attacker equipped with QC, e.g. the parameters of > > the multicast SAs. The section should be rewritten instead. > > Works for me. After some thinking and recollecting I realized, that things are not that simple. It's true that SK_w is derived in QC-resistant way, but it is only used for providing confidentiality of the wrapped keys. Note, that their authenticity and integrity is provided only on G-IKEv2 message level, so it is SK_a[i/r] that are responsible for these properties, and these keys are not QC-resistant. So, a QC-equipped attacker cannot learn the keys, but can substitute them if they are transferred in GSA_AUTH. The design choice was mostly driven by the desire to keep messages small. It is not a problem for GSA_AUTH, but may be a problem for GIKE_REKEY in case LKH is used and the GCKS wants to exclude a GM from the group. In this case the rekey message would contain keys for all other GMs. If the size of the group is about 2^n, then the number of keys sent during excluding the GM is about n (if memory saves me). Each Wrapped key structure contains 8 bytes header and IV in addition to the encypted key. If the key size is 256 bits and the IV size (AES-GCM) is 126 bits, then we have 56 bytes per structure. Adding ICV to this would increase the size by additional 12-16 bytes. For million size group the size of the rekey message would be close to 1500 bytes, causing IP fragmentation, that is not good. We can work out this in some ways. For example, we can authenticate only KD payload with some key derived from SK_d... Regards, Valery. > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 18 07:49:10 2022 Return-Path: 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 6A6583A167E; Tue, 18 Jan 2022 07:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJPdWIR5TyMR; Tue, 18 Jan 2022 07:49:05 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855EF3A1681; Tue, 18 Jan 2022 07:49:04 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id C85D020151; Tue, 18 Jan 2022 17:49:00 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1642520941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dIFKOC0T11/qbKWPKkM5TzWajG59Da1G7/yjA58Nl3c=; b=A5VldfnjvDTNVAPoGBI+eVUI3ygh7IU5WxKxcyceWGLLTzACYXeTRfe8WtX95gUZQ3+jZR 8pjUwGrBSYqA6yMl2k/2jjKrQM7BNvMQl2ADDTs8cqFXnUCsWev7RAX/oyoHQgq0OXuNPA os7JSLwb5Zf6MM38Boqy2/MXu07pItI= Received: by fireball.acr.fi (Postfix, from userid 15204) id 4F2D325C12E5; Tue, 18 Jan 2022 17:49:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25062.57708.269429.346988@fireball.acr.fi> Date: Tue, 18 Jan 2022 17:49:00 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Valery Smyslov'" , , In-Reply-To: <060301d80b9e$8dfc2540$a9f46fc0$@gmail.com> References: <25052.46852.971778.754673@fireball.acr.fi> <057b01d80950$854ba330$8fe2e990$@elvis.ru> <25059.849.299801.984109@fireball.acr.fi> <060301d80b9e$8dfc2540$a9f46fc0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1642520941; a=rsa-sha256; cv=none; b=JMHJoHe0bNwZO4Sh+qrLx0z8xs9+sP3aa/QL5XhBSLwDKuvHRY1VdVcM/1hiMEvDgPdHPd PGdY/lUDn29fA86pv0Hmv5NdxaC08bBUb5JxqjJ3CwrgYXSDZ+7ptZ3gAUGRjnXdOX467y jaJHLPQIpeW3luA45FUUKlvXUPEUcfg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1642520941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dIFKOC0T11/qbKWPKkM5TzWajG59Da1G7/yjA58Nl3c=; b=kX0+ZsE/7YY21Ji19Mn36XzV9BtA1bv+byyQrz5ihnph52z6wENVDOXpxdjug6iyyZ9oBz iZOfPkxn4EjyB30Obdai+n45wzYpR9BTKsIzBFyM0oFK5jZ+tkXOIoN/Q6zRtMoWFqL3Kb 1QqvSZDyJunIewfgopVhM4jlNLVFcDE= Archived-At: Subject: Re: [IPsec] Comments to the g-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2022 15:49:09 -0000 Valery Smyslov writes: > After some thinking and recollecting I realized, that things are not that > simple. > It's true that SK_w is derived in QC-resistant way, but it is only used > for providing confidentiality of the wrapped keys. Note, that their > authenticity and integrity is provided only on G-IKEv2 message level, > so it is SK_a[i/r] that are responsible for these properties, and > these keys are not QC-resistant. So, a QC-equipped attacker > cannot learn the keys, but can substitute them if they are > transferred in GSA_AUTH. True, but note, that this requires active attack with real time attack against the IKEv2 Diffie-Hellman. The main reason for PPK is to provide protection against the store and attack later cases, i.e., where attackers store all traffic now, and then later break the Diffie-Hellman and then can see the traffic keys and then will be able to decrypt the traffic protected by those keys. I.e. PPK is not properly trying to protect against the cases where there is real time quantum computers, for that we most likely need to have quantum safe key exchange, and authentication algorithms too, i.e., multiple-ke and ikev2 intermediate... I think we can simply document this to the security considerations section saying that if that kind of protection against real time attacks is needed then quantum safe key exchange is needed, and most likely also quantum safe authentication algorithms... -- kivinen@iki.fi From nobody Wed Jan 19 10:27:24 2022 Return-Path: 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 DE1A53A091C; Wed, 19 Jan 2022 10:27:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <164261683185.22666.14070059512551794072@ietfa.amsl.com> Date: Wed, 19 Jan 2022 10:27:11 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 18:27:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Valery Smyslov Tommy Pauly Filename : draft-ietf-ipsecme-rfc8229bis-02.txt Pages : 30 Date : 2022-01-19 Abstract: This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This document updates the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents makes RFC8229 obsolete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc8229bis-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Jan 19 10:38:45 2022 Return-Path: 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 6C8243A1738 for ; Wed, 19 Jan 2022 10:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-qkC1iuSXW8 for ; Wed, 19 Jan 2022 10:38:31 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5CB3A1736 for ; Wed, 19 Jan 2022 10:38:30 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id y15so3492146lfa.9 for ; Wed, 19 Jan 2022 10:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=EWDun+mwE4teXj7YZTwvCcCyQ+ahg0ggOTPXv4XFinM=; b=db3t/DfU1nORF8KaOg7qIYmpS7678Vm1glkQwL9nfm6VOY6KlL+eaYkl7BlOdxGmPy 5ZW8PkLZXI44lv11Rg20O4yp0L6F6ZV2sZ3cdoGXOTxP0VJS05eeGHamNJvWm7FEqcO9 s0J83n0rMxZEjEGclcBcSWxHk+AxvIS7q21C8NekN/TWCk+Q/qXetnpXdftS+jDDmtDv f33pgCFQ7icDmnMs540wUuz3yP3RFTkShbQzDZSd2kk8t4iw0S3xE2+d4v7vROSXkauz kDdg1QAEJr5lRu0t5GuTOcr00XlrtVdkTP3drTQ3sBhFDkDAFkxJvaf//hJIVDYmxEGI Drvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=EWDun+mwE4teXj7YZTwvCcCyQ+ahg0ggOTPXv4XFinM=; b=UvD4LV5D/jjQh74xHmMvnNSeHYYn165zk3cBSF+rj0KHH8IlsYZvou3lHQlJUpmHnh sS8Ityljx42KxfBICFpXhFSAvPOCVokdWijSH9JgARChZUkJoLp0yTEZ6aMpLkDOx5WS C0c/X2FM/0ByMb1Yx8kHfhPBEI7dThybdM3VVOqtFKXFWyjfMG60BJD61TaDuwidb23Z WSibJKu0VEMzbhS5lX03+hb1fcCwTuYoXEk2MMVZ8a0JFG+H7Msg8uIM7JFNWLipU75G 0oTiGVOOfDoFtmYg6Sgd3iU2v7mFbZydehJcB9SPF+fhrzLN5yNs2Qg1WPNaj6bH+9kk Mejw== X-Gm-Message-State: AOAM53208jByXNWAiAL9wKRrCfqY1JFrCu4vsMfP5Duw3w2DJAWghVF5 AqcBxrgmG8pnWFECq7ph11kVVg75Euk= X-Google-Smtp-Source: ABdhPJxkgiFUI6oBbKJCj5yhmzDnicGndmVBnopFYkLYY/McUK/RTQczLDDKzwAp9O12v+5tsZzk/Q== X-Received: by 2002:a05:6512:1588:: with SMTP id bp8mr28296635lfb.407.1642617507779; Wed, 19 Jan 2022 10:38:27 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id d26sm33157lfm.209.2022.01.19.10.38.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jan 2022 10:38:27 -0800 (PST) From: "Valery Smyslov" To: Cc: References: <164261683185.22666.14070059512551794072@ietfa.amsl.com> In-Reply-To: <164261683185.22666.14070059512551794072@ietfa.amsl.com> Date: Wed, 19 Jan 2022 21:38:28 +0300 Message-ID: <087d01d80d63$c0add210$42097630$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcIHFQxTFfqEmKCgQ197Na6dA2cqzihhPA Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 18:38:44 -0000 Hi, we published a new version of the draft, that addresses WGLC comments. Regards, Tommy & Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Valery Smyslov > Tommy Pauly > Filename : draft-ietf-ipsecme-rfc8229bis-02.txt > Pages : 30 > Date : 2022-01-19 > > Abstract: > This document describes a method to transport Internet Key Exchange > Protocol (IKE) and IPsec packets over a TCP connection for traversing > network middleboxes that may block IKE negotiation over UDP. This > method, referred to as "TCP encapsulation", involves sending both IKE > packets for Security Association establishment and Encapsulating > Security Payload (ESP) packets over a TCP connection. This method is > intended to be used as a fallback option when IKE cannot be > negotiated over UDP. > > TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This > document updates the specification for TCP encapsulation by including > additional clarifications obtained during implementation and > deployment of this method. This documents makes RFC8229 obsolete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc8229bis-02 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 19 10:45:59 2022 Return-Path: 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 EF2093A1746 for ; Wed, 19 Jan 2022 10:45:57 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyw7xrl3Kf0X for ; Wed, 19 Jan 2022 10:45:53 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4893A1743 for ; Wed, 19 Jan 2022 10:45:53 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id br17so11857715lfb.6 for ; Wed, 19 Jan 2022 10:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=B+vn7L/eCUI5oiudY7JPDKB3HiSkXnNjPVPiKA1psY8=; b=fXxP53TaM1qDYhKbKJtZbC9yn9VA6xN45AOt6n/PvYrHH2uRFE6HQuuorA9ET8fpu5 D+2FQx3ID/Awu+fqXnt83cEQQYUfifA4aDnzfOtq5wmPCnbRkRzhMKFyTPATWcGK+CLi YbqR/oIPBciiT7FAHea/mszDT5ArDOYXH62cmYoirknc9DtW6TtzItImkr86jsBtUFXR csP9k7yB1jDCYRuUvwNqoZq9Jn9Oyf4j+RFrxHE4yQQwwThFGGZ8uJaePfaISdwDIzOH Ay1cGitW7LJE79edPhuCxIap0/RCfiES4V/O6bvddDxxG5o2OucADz+Xnu5dOoWBygKo jvgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=B+vn7L/eCUI5oiudY7JPDKB3HiSkXnNjPVPiKA1psY8=; b=w66WAvGoWTxVciz7twRTk5QfO1TGI4P7iTt1UlOyQbSTx+Z/YkQE8CZFoycV/PL+sL OHanLx35sXPhzgO5uEYMl6E4RPzXc2snNUFoVZpuFJNE8k7g+ou/4eCHP1VIC1qj6Fh1 V0zeaFBmmAAmPCK+Y2yXMl5zuswmtIdijamIZabToiOAIayiPAT6lLpCAkhUGuaLaK0r rGEC0JMDhngRaTkPd30Hhhv1v1rIE/zyts2nLytnWSikrrc+6DlZIaw8B0VCkDFKWI1U AUMPHwtkN3/wzzGZBngZgGKe/GmludeaInteGsWTxg9sAXUDIxDg9TtBUyYdJ1SIoRzu Z4Uw== X-Gm-Message-State: AOAM532qNUnfAj2WphVF0edpdxZ4HrmbInmF5SPms0DLhEVcgkC1/3Lp 62O6lZ05YcZ0CI32k3JIcZuUjjhT8qo= X-Google-Smtp-Source: ABdhPJy/qeTUpiQVLtYNRHKo8BY9em6KlLdNw5ApNvcpY57ykue4PoaaMi9mFlY2J7EqRkNZVdaqYQ== X-Received: by 2002:a2e:c42:: with SMTP id o2mr25123901ljd.389.1642617950614; Wed, 19 Jan 2022 10:45:50 -0800 (PST) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id t10sm53191lfl.78.2022.01.19.10.45.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jan 2022 10:45:50 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: References: In-Reply-To: Date: Wed, 19 Jan 2022 21:45:51 +0300 Message-ID: <087e01d80d64$c8ab4d70$5a01e850$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINrN/IdsOuc0WzOJRkkxx4Plg45qv/bdsQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 18:45:58 -0000 Hi Paul, a new -02 version of the draft is published. We believe it addressed your comments, except for one, see below. > I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and > RFC 8229. I agree with most of these changes. I have some comments > below. If others want to compare the draft with the RFC, see: > > https://nohats.ca/draft-ietf-ipsecme-rfc8229bis-01-from-rfc8229.diff.html > > > > > that may block IKE negotiation over UDP. > > I would say: > > that may not transport IKE negotiation over UDP. > > Blocking sounds like an active administrative action. Most networks just > accidentally happen to not pass UDP. > > I might also change "for traversing network middleboxes" to be more neutral, > eg "in case routers or network middleboxes do not handle UDP". After some discussion between the authors we decided to keep the original text, because it was in the RFC8229 and caused no problems. Regards, Tommy & Valery. [sniped] From nobody Wed Jan 19 11:02:43 2022 Return-Path: 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 169A63A09D4 for ; Wed, 19 Jan 2022 11:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN-00ntq-zwL for ; Wed, 19 Jan 2022 11:02:36 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822293A17F8 for ; Wed, 19 Jan 2022 11:02:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JfFQ16v32zCLK; Wed, 19 Jan 2022 20:02:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1642618953; bh=pKATOajkLc6cTWdsHJzCcqq8q4EZbVB1Yz/Cc8dXhCk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eTPYTv8MmBZ2m9znYutgFsyvuDTp2CH8YRs2E7qI0MhFJEXSD5FtJMIVWThc+f5XZ BjY5mBJmIQr1n06W4mbEAxNxdQaVTfpFJuaYpoqoVwUU/xh0Ygq81oN7WfZzC/vhCI K5Zkh9myt/BtAv05IB5F4+H8peFyk157DGnYm5rw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1JeDr2ZsSP21; Wed, 19 Jan 2022 20:02:33 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 19 Jan 2022 20:02:32 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 959671F2F4C; Wed, 19 Jan 2022 14:02:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 923381F2F4B; Wed, 19 Jan 2022 14:02:31 -0500 (EST) Date: Wed, 19 Jan 2022 14:02:31 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'Paul Wouters' , ipsec@ietf.org, tpauly@apple.com In-Reply-To: <087e01d80d64$c8ab4d70$5a01e850$@gmail.com> Message-ID: References: <087e01d80d64$c8ab4d70$5a01e850$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 19:02:41 -0000 On Wed, 19 Jan 2022, Valery Smyslov wrote: > a new -02 version of the draft is published. We believe it addressed your comments, > except for one, see below. > After some discussion between the authors we decided to keep the > original text, because it was in the RFC8229 and caused no problems. Ok. Let's hope past performance _is_ indicative of future results :) Paul