From nobody Tue Jan 1 05:23:19 2019 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 B5CC412F1A5 for ; Tue, 1 Jan 2019 05:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g47Jee9BjLEX for ; Tue, 1 Jan 2019 05:23:15 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 3E23012426A for ; Tue, 1 Jan 2019 05:23:15 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id v1-v6so25153903ljd.0 for ; Tue, 01 Jan 2019 05:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=HD/5nu8VKEvXk90ToKYHpnHQ9np28P6JgrCDOD9ayho=; b=huIXbz+MRVbPj1hJWDVlbQepzY/dR9JgqFCTYAeatdSiCMYyzYmdvE/h/mVjElzOxM 02obZvwLRSpNPepWk8WGKTFE5cUbtLFLd462KsXeaM33HDY0G2n3sr/2Ogykv+TmKWgg sZPaM47Cv/s7pKgZTQQ41OZn+tOIRx0YK+B/tWxnNpaxFWT9Bdr6Es+ZUQgXrXRv5YFp kb13eIWgZLD/SamGtS3okkoMYSQixrBqIt74Tvv0JfKvDSTchDAwWY8uIe6dQSD8/+tL 68qA7vTZuMPbwbT1Q1VhuHDqS7jPX1s9wYGAJ+80HpXnrUtc6L5ym6ErgBII0NJCt4Uv /wpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=HD/5nu8VKEvXk90ToKYHpnHQ9np28P6JgrCDOD9ayho=; b=Apc902A3Uc8p4ZN9Hwg/NGpfzRDsMTf7GyjfixQiwp8N7GZ1OUOFSN2InYerCy188Z O4mstHBDLczPF5538p/BF/OQ6LBrv5w2DqRJF0XY62VZyaf1oiUUJdOLo3+Abo8TSPs+ NNtfdD5xNF/tO/7lLMUFJnYKnB9NzFx7JriKYlpZgrSpl8L3cMbWHdzD0Y3FnGM24b2X 4C2v2fjeRJBDBc0JaoqCvkHk3QJhM5tNkseo5EgbP6W1Xs4ga4M8RmrwYY9FyWxgoIU0 Fg+O3Xc1XqBniTWaGPcvZh4rz9CM//ZRnG3XI8laEp72nppEhyuyCrvRUq/5Z69pf5rf Y6nA== X-Gm-Message-State: AJcUukdyJwvriTRGiJok+dLL/O/C0TOyY9EAJBD6aWUrlxosv6dKVGUY ITnWt0nqebuti+OFIMPqPQM= X-Google-Smtp-Source: ALg8bN4z4hX+RZb5FidPe46eO66rfPyp8spz/NuknAdRqvnlFGJ2/xBWImFE3CKqD8B+5bDltEf5sA== X-Received: by 2002:a2e:2b85:: with SMTP id r5-v6mr22205112ljr.91.1546348993294; Tue, 01 Jan 2019 05:23:13 -0800 (PST) Received: from chichi (95-27-156-51.broadband.corbina.ru. [95.27.156.51]) by smtp.gmail.com with ESMTPSA id e14-v6sm10517454ljb.31.2019.01.01.05.23.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Jan 2019 05:23:12 -0800 (PST) Message-ID: <523914FE74054C1CB4C095B3E7D1BB46@chichi> From: "Valery Smyslov" To: "Paul Wouters" , "IPsecme WG" Cc: "Scott Fluhrer \(sfluhrer\)" , References: <154575066894.24030.13252361041324294083@ietfa.amsl.com> <004601d49c65$23561120$6a023360$@gmail.com> <012b01d49e79$93c68780$bb539680$@gmail.com> In-Reply-To: Date: Tue, 1 Jan 2019 16:23:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.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: Tue, 01 Jan 2019 13:23:18 -0000 Hi Paul, first, I believe this discussion must be public, so I've added ipsec@ietf.org. >>> If there is IKE traffic other >>> than the identities that need to be protected against such an >>> adversary, implementations MAY rekey the initial IKE SA immediately >>> after negotiating it to generate a new SKEYSEED from the postquantum >>> SK_d. This would reduce the amount of data available to an attacker >>> with a Quantum Computer. > > How does an immediate rekey of the IKE SA help hide some of the information, > like TS? I think we need to be more clear. So how about: > > An attacker with a Quantum Computer that can read the decrypted > IKE SA from the initial exchanges has access to all the > configuration parameters exchanged via the IKE SA including > all negotiated IPsec SAs information with the exception of the > cryptographics keys used by those IPsec SAs which are protected > by the PPK. IKE SA information available to such an attacker > includes the traffic selectors that can expose the network > architecture and IP address ranges that are in use. Deployments > that are concerned with this MUST initiate a childless IKE SA > [RFC6023] using PPKs and immediately rekey the IKE SA so it gains > PPK protection before sending any other IKE messages such as > CREATE_CHILD_SA or Informational exchange. If other sensitive > information such as third party cryptographic keys for other > protocols are transmited via IKE, implementations MUST rekey > the IKE SA before sending those payloads over IKE to ensure this > information is protected by the PPK. I think that the text is OK, however I'd replace "third party cryptographic keys" with just "cryptographic keys". In G-IKEv2 the keys transferred are not "thirs party". But I'd rather hear more from my co-authors and the WG. > It replaces the two old paragraphs? On the other hand, perhaps instead > of this being hidden in the Security Considerations section, it deserves > its own regular section? Not sure. It was a WG's decision that the information exchanged over IKE SA is less important, so we can live with the ability for an attacker to recover it. That's why the text is in the Security Considerations. >>> What is not obvious from this text, is that it exposes information of >>> the first IPsec SA as well, such as traffic selectors used. > > And actually not just the first IPsec SA, but all of them. And PFS would > not help here. PFS is irrelevant here. > I wonder if we need to talk about RFC 4739 here? like: > > If multiple authentication exchanges [RFC 4739] are required > for the IKE SA, the IKE SA MUST rekey before sending the second > IKE_AUTH exchange in response to the initial IKE_AUTH's ANOTHER_AUTH_FOLLOWS > payload to avoid exposing the second authentication form to a quantum > capable attacker. > > But this would really complicate the state machine? You can't do it. There is a single IKE_AUTH exchange with multiple messages (like in EAP case). You can't do any rekeys until the IKE_AUTH exchange (which in case of RFC4739 includes multiple authentications) completes. Regards, Valery. > Paul From nobody Tue Jan 1 18:38:21 2019 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 E2FD7124B0C for ; Tue, 1 Jan 2019 18:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 864iv-RkRcG8 for ; Tue, 1 Jan 2019 18:38:16 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 5FC1D124BAA for ; Tue, 1 Jan 2019 18:38:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43TwFs53lSz1Kg; Wed, 2 Jan 2019 03:38:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1546396689; bh=PW7wDzZEPRLcFsQpnhsR8iTSY45ODUrdycnl1Fi4ocU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VPZ2c1G8BJ7xdLPiKtngSKSSGl6eVfd3XKfQOm9T+9jFSpQF5L211j3maH/VDRNS3 EtZKv4MQ+kddhvM9zHZ8tCPIPasICxIn0JJvaJIpvFcPBkm0/NzUot5T81cOOKe8Iw T7PX/JJkYXZ9RQUoOGBDag1GySscbenPCmcng/Ag= 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 J8KePzXqCQXD; Wed, 2 Jan 2019 03:38:07 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Jan 2019 03:38:07 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E30AF31940C; Tue, 1 Jan 2019 21:38:05 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E30AF31940C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D9A3C4187620; Tue, 1 Jan 2019 21:38:05 -0500 (EST) Date: Tue, 1 Jan 2019 21:38:05 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: IPsecme WG , "Scott Fluhrer (sfluhrer)" , pkampana@cisco.com In-Reply-To: <523914FE74054C1CB4C095B3E7D1BB46@chichi> Message-ID: References: <154575066894.24030.13252361041324294083@ietfa.amsl.com> <004601d49c65$23561120$6a023360$@gmail.com> <012b01d49e79$93c68780$bb539680$@gmail.com> <523914FE74054C1CB4C095B3E7D1BB46@chichi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.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, 02 Jan 2019 02:38:19 -0000 On Tue, 1 Jan 2019, Valery Smyslov wrote: > first, I believe this discussion must be public, so I've added Sure. >> information, >> like TS? I think we need to be more clear. So how about: >> >> An attacker with a Quantum Computer that can read the decrypted >> IKE SA from the initial exchanges has access to all the >> configuration parameters exchanged via the IKE SA including >> all negotiated IPsec SAs information with the exception of the >> cryptographics keys used by those IPsec SAs which are protected >> by the PPK. IKE SA information available to such an attacker >> includes the traffic selectors that can expose the network >> architecture and IP address ranges that are in use. Deployments >> that are concerned with this MUST initiate a childless IKE SA >> [RFC6023] using PPKs and immediately rekey the IKE SA so it gains >> PPK protection before sending any other IKE messages such as >> CREATE_CHILD_SA or Informational exchange. If other sensitive >> information such as third party cryptographic keys for other >> protocols are transmited via IKE, implementations MUST rekey >> the IKE SA before sending those payloads over IKE to ensure this >> information is protected by the PPK. > > I think that the text is OK, however I'd replace "third party cryptographic keys" > with just "cryptographic keys". In G-IKEv2 the keys transferred are not "thirs party". > But I'd rather hear more from my co-authors and the WG. Sounds good to me. >> It replaces the two old paragraphs? On the other hand, perhaps instead >> of this being hidden in the Security Considerations section, it deserves >> its own regular section? > > Not sure. It was a WG's decision that the information exchanged over IKE SA > is less important, so we can live with the ability for an attacker to recover > it. > That's why the text is in the Security Considerations. Okay. >> I wonder if we need to talk about RFC 4739 here? like: >> >> If multiple authentication exchanges [RFC 4739] are required >> for the IKE SA, the IKE SA MUST rekey before sending the second >> IKE_AUTH exchange in response to the initial IKE_AUTH's >> ANOTHER_AUTH_FOLLOWS >> payload to avoid exposing the second authentication form to a quantum >> capable attacker. >> >> But this would really complicate the state machine? > > You can't do it. There is a single IKE_AUTH exchange with multiple messages > (like in EAP case). You can't do any rekeys until the IKE_AUTH exchange > (which in case of RFC4739 includes multiple authentications) completes. We can't, you prefer not to? You _can_ protect the identities of the second authentication if you would first rekey. I agree it is tricky in a state machine because right now it is easy to state an unauthenticated IKE SA can never rekey. But it is possible. It might not be worth the complication. Paul From nobody Tue Jan 1 23:26:34 2019 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 279B1126DBF for ; Tue, 1 Jan 2019 23:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RwPM7Ld7IEJl for ; Tue, 1 Jan 2019 23:26:31 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 0620F12426E for ; Tue, 1 Jan 2019 23:26:30 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id u89-v6so26339563lje.1 for ; Tue, 01 Jan 2019 23:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=8Gb8VL3tqaNRlmBZV792ZTsy3+nuXWcqqtQ4RzxP0d8=; b=i9cxVDryxVkdUdyVoc40SBrh4tUJbyaMyG/EYyAPE0KU16zOuGl26BoFe2W0KKzfDo AxO0y7fjIgxN++KkE5NJoYp1Ici89kWSXcVGTZurXBUWCVMUmowg8bdVGzy6Kcn/8M/a oPWcXlF25eGoVGEW0kieSEhVD4vCOUReFoyhXAGLwqGsIfQo7kRLl7abDGkFoRR2I9Su 2d+TqnDAUbXaI3Ci1L0hWZGqGZ8f8cFGZyAOUqqEc586AySHHDNVRHdQOJ2QVX615qxh 5G2fzvHIPz3Y/zFisDgZmSnhixOeUcxkm0YrWCeuqH5Ur8FXDdwufmOVr5RqAVoQNF5H l8/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=8Gb8VL3tqaNRlmBZV792ZTsy3+nuXWcqqtQ4RzxP0d8=; b=FItYMclpoQn1KX0WF7fmqTA/iRiyZJLhXni8iwRogHnLOKVGVo9/qImhJEKM2mOZbi v7UsJVph8IDZ4o33dnFd6EoQD4BbVv6tUdT3IEv9xnUPn6FRqJaBj6bw/YrZwWJkfShD XEW9TrVSKulAifRes0X8XhM6koJilW9NdGQP6win0qmwN+ZJb67UOwUVJI0PGAiHJLhZ lCPC6Y6CIox6TFnqV0o//mE7Qz7ELS+cKLKzWHwKDlrfhaF/emNdvBIidBfm6VuhQ/rP wbR0Fr6OX2X09rlSEpzErL28S93jAbKx2X6ZUlo/vBldq55uMw25SULd2/kgIXxM9xkL 9JjA== X-Gm-Message-State: AA+aEWY932iPFFDBu86MszeRzlDToHFw7yfxKDQhS4fMIgATDcadIaJ4 c0zhiaq1MoJTlPJC/h1o7l5lcJcv X-Google-Smtp-Source: ALg8bN56Gga5hQbULnnPAB63pmsvKLEmeL1LSmD43ko8Acoxzpxo4UvsiqHb8pDR2rGtDOAQwciCcw== X-Received: by 2002:a2e:868c:: with SMTP id l12-v6mr26856906lji.90.1546413989087; Tue, 01 Jan 2019 23:26:29 -0800 (PST) Received: from chichi (95-27-156-51.broadband.corbina.ru. [95.27.156.51]) by smtp.gmail.com with ESMTPSA id w16-v6sm11210508ljw.11.2019.01.01.23.26.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Jan 2019 23:26:28 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" Cc: "IPsecme WG" , "Scott Fluhrer \(sfluhrer\)" , References: <154575066894.24030.13252361041324294083@ietfa.amsl.com> <004601d49c65$23561120$6a023360$@gmail.com> <012b01d49e79$93c68780$bb539680$@gmail.com> <523914FE74054C1CB4C095B3E7D1BB46@chichi> In-Reply-To: Date: Wed, 2 Jan 2019 10:26:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.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, 02 Jan 2019 07:26:33 -0000 >>> I wonder if we need to talk about RFC 4739 here? like: >>> >>> If multiple authentication exchanges [RFC 4739] are required >>> for the IKE SA, the IKE SA MUST rekey before sending the second >>> IKE_AUTH exchange in response to the initial IKE_AUTH's >>> ANOTHER_AUTH_FOLLOWS >>> payload to avoid exposing the second authentication form to a quantum >>> capable attacker. >>> >>> But this would really complicate the state machine? >> >> You can't do it. There is a single IKE_AUTH exchange with multiple messages >> (like in EAP case). You can't do any rekeys until the IKE_AUTH exchange >> (which in case of RFC4739 includes multiple authentications) completes. > > We can't, you prefer not to? > > You _can_ protect the identities of the second authentication if you > would first rekey. I agree it is tricky in a state machine because right > now it is easy to state an unauthenticated IKE SA can never rekey. But > it is possible. It might not be worth the complication. Well, _technically_ you can do it. But you can't do it if you follow IKEv2 rules. Because in case of multiple authentications there is no multiple IKE_AUTH exchanges, there is a single IKE_AUTH exchange with multiple rounds [1], and you suggest to insert a new exchange in the middle of the running IKE_AUTH exchange. It is not state machine issue, it would be violating of very basic IKEv2 rules: you cannot perform any actions on IKEv2 SA until the IKE_AUTH exchange completes successfully, you cannot run multiple exchanges if your window size is 1, etc. Reductio ad absurdum: technically you can rekey right after IKE_SA_INIT completes, no need to wait for IKE_AUTH :-) [1] At least it is my reading of RFC4739. Actually, it is not very explicit about this, but the phrase from it "The IKE_AUTH phase is considered successful only if all the individual authentication exchanges complete successfully." seems to imply that IKE_AUTH phase cannot be interrupted with any other exchanges. Regards, Valery. > Paul From nobody Mon Jan 7 09:24:06 2019 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 4D4A5130F93 for ; Mon, 7 Jan 2019 09:24:04 -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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 glyaDpdXkOvc for ; Mon, 7 Jan 2019 09:24:01 -0800 (PST) Received: from beechnut.cse-cst.gc.ca (beechnut.cse-cst.gc.ca [205.193.218.37]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54731130F90 for ; Mon, 7 Jan 2019 09:24:00 -0800 (PST) From: "Hammell, Jonathan F" To: "ipsec@ietf.org" , 'Valery Smyslov' CC: "'sfluhrer@cisco.com'" , "'mcgrew@cisco.com'" , "'pkampana@cisco.com'" , "'david.waltermire@nist.gov'" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.txt Thread-Index: AdSmrTTZ4AnIneKjTyOqg29RVBqz4Q== Date: Mon, 7 Jan 2019 17:22:53 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-classification: UNCLASSIFIED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20190107172401.54731130F90@ietfa.amsl.com> Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.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, 07 Jan 2019 17:24:04 -0000 Classification: UNCLASSIFIED Thanks Valery. This update addresses my WGLC comments. Best regards, Jonathan -----Original Message----- Date: Tue, 25 Dec 2018 18:18:49 +0300 From: "Valery Smyslov" To: , Cc: "'Scott Fluhrer'" , "'David McGrew'" , "'Panos Kampanakis'" , Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.txt Message-ID: <004601d49c65$23561120$6a023360$@gmail.com> Content-Type: text/plain; charset=3D"us-ascii" Hi, a new (-05) version of the "Postquantum Preshared Keys for IKEv2" draft has= been posted. The draft contains minor text improvements that addresses com= ments received during WGLC. Regards, Valery (for the authors). P.S. Merry Christmas (a bit late) and Happy New Year (a bit early)! > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IP Security Maintenance and Extensions W= G of the IETF. >=20 > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-05.txt > Pages : 18 > Date : 2018-12-25 >=20 > Abstract: > The possibility of Quantum Computers pose a serious challenge to > cryptography algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-qr-ikev2-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 15 23:16:12 2019 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 AABAC12F1AC; Tue, 15 Jan 2019 23:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4qinJQ9TcrsY; Tue, 15 Jan 2019 23:16:09 -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 DE6A51310ED; Tue, 15 Jan 2019 23:16:08 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id a8so4056062lfk.5; Tue, 15 Jan 2019 23:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=piVOh8AKLa1MdQaFgufOD4W20wxwaMtPzQxnifnte4o=; b=kgh6S24ZHc2Z/T9GpDy+wIGP8SiVh2ulRW3mNKZcCgv345hLmSvRQoHoyroFQec0Ok 8g4f3c4Hb4+R89fSP/nxL2STmCPIjrbxYucqF0NVTlS0G+gtwfY/ZPNNsd5j70FRQ890 PX9QdDLYoPFoYe/B3wWMBqU6/omcOkRWQdk43Ykbq76bNkYUiQDxWdJUyq19FrvUWO5L KTvmxXq1pc3T8rz6+VCrktoX1XREyzda+hJ36ie4mginmvwzqv83X2/RJktUeEJ5Kbmp R5iKx2XFVcUkH6dOLvyTqOw/pbBJB2Ej6wMLQmxlatB3yvmE6RqvnO3KWRdqo8kz8Eqg v+jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=piVOh8AKLa1MdQaFgufOD4W20wxwaMtPzQxnifnte4o=; b=eN3uOztC0ib9bQYromDPt/kwcB0uajFNb8u9/1snzaQl6a15pFECgqhZYL3lj09Kyq Y+BJqG93EPiGBSvL3z0IhMq0jxNyZ5cq7bQn1an5xQoJ4XT8qiXNjTXzBiqe3R+bzCnc 9HcTB5yJxXEYBU6uI7CIf9LVmUmtRJKQD2d+5mX5JiubcZajYuGNPaez96KAzfgKRk2A iKYkvuzgNOxHXINdHQB9BZ1mrZ9EdJlXHfF+bYdcedoEhyqZIdKEQBokcDDg3pfKQURU w6kmtEQ3pCK+ANBPWz0fCg+RluhxXsnGXC2dnLT+FxZtKglWrh/yHaxDSg2nTOfzmOzi K5UQ== X-Gm-Message-State: AJcUukdTT+1JM89nwrBfDtTgiuWEUX7HMX0ftz7mPoyMEupAwlCTYcTJ /iBCqxrwpxGa8aWOYjKr6LAPbzfx X-Google-Smtp-Source: ALg8bN7KknWIwiM6KBwvbhxnOExe0UOi7XoQ2cubtOWupFJ/ztguVAB/gF/p7qmMm89+A2oZCFo0fg== X-Received: by 2002:a19:4849:: with SMTP id v70mr5633093lfa.62.1547622966527; Tue, 15 Jan 2019 23:16:06 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o17sm1012116lff.77.2019.01.15.23.16.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Jan 2019 23:16:05 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Cc: References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> In-Reply-To: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> Date: Wed, 16 Jan 2019 10:15:41 +0300 Message-ID: <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvn6V9+0SA Content-Language: ru Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.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, 16 Jan 2019 07:16:11 -0000 Hi, a new version (-03) of the QSKE draft is published. It contains quite a lot of changes from the -02 version: 1. Negotiation method is changed to standard (via new Transform Types in SA payload) 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is addressed 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the draft-smyslov-ipsecme-ikev2-aux-02) 4. IANA considerations section is added 5. Temporary IDs for PQ KE methods (using VendorID) are removed Please, review the draft. Some issues have already been discussed and the changes reflect the WG consensus, some are new and the text reflects only the authors' current opinion. Regards, Valery (for the authors) > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > has been successfully submitted by C. Tjhai and posted to the > IETF repository. > > Name: draft-tjhai-ipsecme-hybrid-qske-ikev2 > Revision: 03 > Title: Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol > Version 2 (IKEv2) > Document date: 2019-01-14 > Group: Individual Submission > Pages: 19 > URL: https://www.ietf.org/internet-drafts/draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt > Status: https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid-qske-ikev2/ > Htmlized: https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme-hybrid-qske-ikev2 > Diff: https://www.ietf.org/rfcdiff?url2=draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > > Abstract: > This document describes how to extend Internet Key Exchange Protocol > Version 2 (IKEv2) so that the shared secret exchanged between peers > has resistance against quantum computer attacks. The basic idea is > to exchange one or more post-quantum key exchange payloads in > conjunction with the existing (Elliptic Curve) Diffie-Hellman > payload. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Jan 18 03:32:47 2019 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 EB8F3130F4D; Fri, 18 Jan 2019 03:32:40 -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: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154781116093.17402.6640039061059778673@ietfa.amsl.com> Date: Fri, 18 Jan 2019 03:32:40 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-06.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: Fri, 18 Jan 2019 11:32:41 -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 : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-06.txt Pages : 18 Date : 2019-01-18 Abstract: The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 18 03:37:38 2019 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 3DAB1131195; Fri, 18 Jan 2019 03:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 n4HtiYG5509p; Fri, 18 Jan 2019 03:37:35 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 962D2130F4D; Fri, 18 Jan 2019 03:37:34 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id t9-v6so11357023ljh.6; Fri, 18 Jan 2019 03:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=8fooSicxTgVlf1nuAxgjIly/XuFRLMhy5DI496ksXYs=; b=PKbgl2wU6MKSNKD1fMOqDt2MZqskDXbnM1Acpq4jJawaRhJPIYnZ10qBpRIpzGXO13 w7XAqr2nJ77UbQmjluX82kq+kltKwS6EA6LbLoY8l+CC1pc3VUrDDqG8acMSjrP2Vcwo FAn7s7qG1L/oiUqN+qgVWgCsEqpWP96xAvlojp/lSvMqM09rHbvA/qB6w32kxxoMwQUM Tirdd073g/wiHbmYCPqynWi5uuVwqz4cPeA4xdFJ/j4agN2GGWJdo0Q46jOy8T3rSW5r j+ZZJY4uuPHDpbmPGwzhlZ8qxeP9x/YuMZuR9Klc28+VPFAKryUpzU4BFGeneDGmlE7c Sb/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=8fooSicxTgVlf1nuAxgjIly/XuFRLMhy5DI496ksXYs=; b=WpRwQ30T7nni9bvqxS0axJF2madgRLbvk9ZrYM3rBT0qYfrvPNDyVRFW9jIi9+JF2k g1sMjsI236orD8l66ZDbQtF/A5UuRgorCq02P1JB+qhRPNPKClcdERexfGBdBu3KvxGt xFi7CNm6oRVqTAluyD5b/rowkhh7QsXQRQnAkVyeScdxJw3JrgVIjjJWnc1IBvsNTX7j Q9ux6pFMs2WmroY7hKvuziISHbfPNpXFkjrhPGZy7NLmJQ3XWJhGf8g9xlJtCV7Unlgk 0QL4y0vK6WbGSTqA6hqHS+5wFf95oqcu9ocszlxPy60xVDCXRwIJ7zZFyTlKzY+uQUBC CkZA== X-Gm-Message-State: AJcUukfEcbxDo2xj01d8VD4LLK1/C4YQVOG7NVLOSIEBWwKVMBfNuf1T INlYY5VE+DMR2Sop2Zn5nIOlz1NI X-Google-Smtp-Source: ALg8bN7Ql/bKHK7PMitWhTXHYxqTbyDcgzw1etkdb3d9YC9VGOvTEOB4cPNKqTuWTqZeJyKnriFW/g== X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr11978674ljm.72.1547811452729; Fri, 18 Jan 2019 03:37:32 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s24sm759017lfc.30.2019.01.18.03.37.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Jan 2019 03:37:32 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Cc: , References: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> In-Reply-To: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2019 14:37:09 +0300 Message-ID: <012f01d4af22$25cb8230$71628690$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLO7pSYle5thR7Mqlsq+R/BHQ+FzaPAZkiA Content-Language: ru Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.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: Fri, 18 Jan 2019 11:37:36 -0000 Hi, a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted. It addresses Paul Wouters' comment about the Security Considerations text. Regards, Valery (for the authors). > A new version of I-D, draft-ietf-ipsecme-qr-ikev2-06.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-ietf-ipsecme-qr-ikev2 > Revision: 06 > Title: Postquantum Preshared Keys for IKEv2 > Document date: 2019-01-18 > Group: ipsecme > Pages: 18 > URL: https://www.ietf.org/internet-drafts/draft-ietf-ipsecme-qr-ikev2-06.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > Htmlized: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-06 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-06 > > Abstract: > The possibility of Quantum Computers pose a serious challenge to > cryptography algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Jan 18 07:22:22 2019 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 14456130DCB; Fri, 18 Jan 2019 07:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 OPmKFg-Iv2Qw; Fri, 18 Jan 2019 07:22:18 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 0C885128B14; Fri, 18 Jan 2019 07:22:18 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43h4S32HgFzpK; Fri, 18 Jan 2019 16:22:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1547824931; bh=gWIINZzMRqvh81enAodS5b+gMokvT0+SsKaNOOMePcg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rPfo5SzevfB6xkXLmPDkaEUQce5VnK82M0whQTFcoK9hEf7cMeTrKIpa8E6Ilahx/ vRS/YzQmj3lujPCBWl/ehXfYdPlwjhHILgPWY0Ey3DoCaq7U4qQ/1UIooA2tNRtFxW qVbgeyMmK2mc7hhVXT1mzxMOdRYf9N5gAG//Fvh8= 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 A2joRkrya-aH; Fri, 18 Jan 2019 16:22:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 18 Jan 2019 16:22:08 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C1387379D; Fri, 18 Jan 2019 10:22:07 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C1387379D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B026C40D358A; Fri, 18 Jan 2019 10:22:07 -0500 (EST) Date: Fri, 18 Jan 2019 10:22:07 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: IPsecME WG , ipsecme-chairs@ietf.org, david.waltermire@nist.gov In-Reply-To: <012f01d4af22$25cb8230$71628690$@gmail.com> Message-ID: References: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> <012f01d4af22$25cb8230$71628690$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.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: Fri, 18 Jan 2019 15:22:20 -0000 On Fri, 18 Jan 2019, Valery Smyslov wrote: > a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted. > It addresses Paul Wouters' comment about the Security Considerations text. Thanks! I have another minor suggested change :) current: Note that [RFC6023] allows to skip creating Child SA in the IKE_AUTH exchange, so that the supporting peers can rekey the IKE SA before any Child SA is created. Note also that some information (identities of the peers, feature negotiation notifications, Vendor IDs etc.) is always exchanged in initial exchanges and thus cannot be protected from the attack described above by performing an IKE SA rekey. new: It is possible to create a childless IKE SA in IKE_AUTH as specified in [RFC6023]. This prevents Child SA configuration information from being transmited in the original IKE SA that is not protected by a PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges, such as peer identities, feature notifications and Vendor ID's cannot be hidden from the attack described above, even if the additional IKE SA rekey is performed. Although this information would also be available to a Man-in-the-middle attacker without a quantum computer. This removes the two "note" from sentences which make them less easy to read, and quantifies the leaked information a bit in the context of a simple MITM, non-quantum attack. It explains a bit better why there isn't a strong reason to try and hide the peer identities and VIDs from attackers with quantum computers. Paul From nobody Fri Jan 18 08:38:40 2019 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 C69A4129AB8; Fri, 18 Jan 2019 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.642 X-Spam-Level: X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RdODhMKDyF08; Fri, 18 Jan 2019 08:38:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E5B13117B; Fri, 18 Jan 2019 08:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2409; q=dns/txt; s=iport; t=1547829515; x=1549039115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OXY3MwxcoKC2vMj23nbT0qpZlL4N2I+eqhXomEqYgDk=; b=EpGF3twZC1W4/vfEtGG27xHv05Jpb7s/zL+jO6Vs9LenJAasKq67d9N5 ZsHIp9ZxS06CNfE/rd84A1RuBjXstaElaT2DWRzHp1PE/UPzLqMHUc2Ia Dm7OhJIuo+HxlupvsiJVZRgMuoZs7XRjv2z71V6z/VSgw7H4nNo/UXyDq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADN/0Fc/51dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBggNmgQInCpd6gg2JJY5cgXsLAQEYC4R?= =?us-ascii?q?JAoJcIjYHDQEDAQECAQECbRwMhUoBAQEDAQEBODQJAgUHBAIBCBEEAQEfECE?= =?us-ascii?q?GCx0IAgQBDQUIgxuBaQMNCA+tCogQDYIYBYl5gkgXgUA/gRGDEoJXRwEBh0E?= =?us-ascii?q?CihaMS4sMMwkCjmCDMSCBZohmh0iKBIY0ij4CERSBJyYGK4FWcBU7gmyLHYU?= =?us-ascii?q?/QTGIdYEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,491,1539648000"; d="scan'208";a="496679318" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2019 16:38:34 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x0IGcXIB001227 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Jan 2019 16:38:33 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 18 Jan 2019 10:38:32 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Fri, 18 Jan 2019 10:38:33 -0600 From: "Panos Kampanakis (pkampana)" To: Paul Wouters , Valery Smyslov CC: IPsecME WG , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" Thread-Topic: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.txt Thread-Index: AQHUryGJlLv8tXviVkezsf76eQzu3qW1JQRegAAUKQA= Date: Fri, 18 Jan 2019 16:38:33 +0000 Message-ID: References: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> <012f01d4af22$25cb8230$71628690$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.245.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.19, xch-aln-009.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.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: Fri, 18 Jan 2019 16:38:39 -0000 Thanks for the detailed reviews Paul. I don't think the new text is changin= g the meaning of the text that is already there. Anyone reading either of t= he two, would be able to understand the point. Thus, I feel there is no nee= d to make the new change this late in WGLC process.=20 Panos -----Original Message----- From: IPsec On Behalf Of Paul Wouters Sent: Friday, January 18, 2019 10:22 AM To: Valery Smyslov Cc: IPsecME WG ; ipsecme-chairs@ietf.org; david.waltermire@= nist.gov Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ike= v2-06.txt On Fri, 18 Jan 2019, Valery Smyslov wrote: > a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted. > It addresses Paul Wouters' comment about the Security Considerations text= . Thanks! I have another minor suggested change :) current: Note that [RFC6023] allows to skip creating Child SA in the IKE_AUTH exchange, so that the supporting peers can rekey the IKE SA before any Child SA is created. Note also that some information (identities of the peers, feature negotiation notifications, Vendor IDs etc.) is always exchanged in initial exchanges and thus cannot be protected from the attack described above by performing an IKE SA rekey. new: It is possible to create a childless IKE SA in IKE_AUTH as specified in [RF= C6023]. This prevents Child SA configuration information from being transmi= ted in the original IKE SA that is not protected by a PPK. Information in t= he initial IKE_INIT and IKE_AUTH exchanges, such as peer identities, featur= e notifications and Vendor ID's cannot be hidden from the attack described = above, even if the additional IKE SA rekey is performed. Although this info= rmation would also be available to a Man-in-the-middle attacker without a q= uantum computer. This removes the two "note" from sentences which make them less easy to rea= d, and quantifies the leaked information a bit in the context of a simple M= ITM, non-quantum attack. It explains a bit better why there isn't a strong = reason to try and hide the peer identities and VIDs from attackers with qua= ntum computers. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jan 18 10:24:54 2019 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 58C45131290; Fri, 18 Jan 2019 10:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 npXnIdtxNOmJ; Fri, 18 Jan 2019 10:24:50 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 9A9B4130F94; Fri, 18 Jan 2019 10:24:49 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id v5so11170727lfe.7; Fri, 18 Jan 2019 10:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=hl+dI6PAvp0vsXlGLcAwQ0zSbXUBE3FjbQw5dQWPajc=; b=WYyJ8pTN+rHwuaq3SFWTKkBzE3ZIGhWE0Juth+Vt7BdW0PP/kgc0+/frwukF1BGO4u bCxZEymXMWPQKOMsJSPR9Ld5i/oK+jXUzVnXliRNHtTJxk967YJI9h+FhkOlYGoY7eSe k4vWhHDbb9aLP0a2DGlYE0TmcE4UQwWgBhePattE/7k5jXUCnEjcGU4Sc5SqIf6roZ7z l6hk8pUnAyoe9rg/P+y/GH8fcWvjfqnETRmNjR1GeIkus75XOkEwtt0cMtvsewZqZoHt LqPq6giMNzfFM0v31UM0+HR5FofXpriy83d1GVeM5gAG+e3ftAG7cYXICERqKa96VGHH xtOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=hl+dI6PAvp0vsXlGLcAwQ0zSbXUBE3FjbQw5dQWPajc=; b=Xp7teNYcGtfPnrbCt4Y0LtularX/vQI312WN9KUlPuNj69/yqGaqjbJuyTWPVBacCj 3joa9lrpsOHbxIpMDesZJykOWJOB8uKSNPHYoQbI02aXqgKgFzWSiL7dFLof9RuPJxxX McE5usMMtS1GLG4G/lTSWzf/lDIXorX1kuff0ozqcG4R1IIVyeAqwYlpDQ7Hhx7o8EkA p3I587A/ay92fQ1PIDn8EHU94OYcpcoaiviVtTCUWBhakITcN9PTDgRBQVXG4mfpnXne A8AzCkTiQDhtP5GlOxpG+u5mz4O8NUaHo1hsl7fcvOCaqbqMFqy45ErwzZvkV06QuI6v NueA== X-Gm-Message-State: AJcUukc6yUln1XN3vX8GC5POrBrT/DL9FE5ECawO0M5zcMUPFPqy57E3 0FnMzoJD66FcvXrFNjmpIAA= X-Google-Smtp-Source: ALg8bN41QGH7NNLnoebDz0got6bC9rx8mRN/3FbV6GBV89an03Cr/LTHGumUhyqinDX5F5JTiT4+Vw== X-Received: by 2002:a19:a84e:: with SMTP id r75mr13687148lfe.45.1547835887674; Fri, 18 Jan 2019 10:24:47 -0800 (PST) Received: from chichi (95-27-156-51.broadband.corbina.ru. [95.27.156.51]) by smtp.gmail.com with ESMTPSA id q23sm903679lfm.82.2019.01.18.10.24.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Jan 2019 10:24:47 -0800 (PST) Message-ID: <29AE1F8B2B77427E934251BDC8CEEE06@chichi> From: "Valery Smyslov" To: "Paul Wouters" Cc: "IPsecME WG" , , References: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> <012f01d4af22$25cb8230$71628690$@gmail.com> In-Reply-To: Date: Fri, 18 Jan 2019 21:24:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.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: Fri, 18 Jan 2019 18:24:53 -0000 Hi Paul, I think that comparing QC-based attack with MITM is a bit incorrect, since Man-in-the-Middle can only learn what the Initiator sends, while an attacker equipeed with QC can also learn what the Responder replyis. Besides, unlike Man-in-the-Middle, this is a passive attack and the peers could never know that their conversation is revealed. Anyway, I think that MITM in IKEv2 is covered in enough detail in RFC7296, so I don't see the need to mention it here. Otherwise, the two texts basically say the same. I admit that yours is easier to read :-), but let's see what the RFC says :-) Regards, Valery. > On Fri, 18 Jan 2019, Valery Smyslov wrote: > > > a new version of draft-ietf-ipsecme-qr-ikev2 (-06) has been posted. > > It addresses Paul Wouters' comment about the Security Considerations text. > > Thanks! > > I have another minor suggested change :) > > current: > > Note that [RFC6023] allows to > skip creating Child SA in the IKE_AUTH exchange, so that the > supporting peers can rekey the IKE SA before any Child SA is created. > Note also that some information (identities of the peers, feature > negotiation notifications, Vendor IDs etc.) is always exchanged in > initial exchanges and thus cannot be protected from the attack > described above by performing an IKE SA rekey. > > new: > > It is possible to create a childless IKE SA in IKE_AUTH as specified > in [RFC6023]. This prevents Child SA configuration information from > being transmited in the original IKE SA that is not protected by > a PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges, > such as peer identities, feature notifications and Vendor ID's cannot > be hidden from the attack described above, even if the additional IKE > SA rekey is performed. Although this information would also be available > to a Man-in-the-middle attacker without a quantum computer. > > This removes the two "note" from sentences which make them less easy > to read, and quantifies the leaked information a bit in the context of > a simple MITM, non-quantum attack. It explains a bit better why there > isn't a strong reason to try and hide the peer identities and VIDs from > attackers with quantum computers. > > Paul From nobody Fri Jan 18 11:01:13 2019 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 DAF54131311; Fri, 18 Jan 2019 11:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 oVYq6DLdv6D1; Fri, 18 Jan 2019 11:01:10 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 DD501131315; Fri, 18 Jan 2019 11:00:59 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43h9JR58w5zHVj; Fri, 18 Jan 2019 20:00:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1547838055; bh=5mOhO5AFWGgQaeAXRYP0AI74WxyVxsrqRtkSeY86GuI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B3VYKz4xtQUUqA7s3NeYN+iMTeN5516igmNLwJHmWnjQU+9LeiixkvRxXkbKLOyYC SjhPWaFLVV7csMdGn6JMCcsesyRZL42InAlYf7k6vIa2NIhwycVBMr2es1sAGC6FRv Mh1IqhhtdJE6BmshOFj0qxXIlQKQGCQBojSb2XgE= 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 4WHUxHZH-K6E; Fri, 18 Jan 2019 20:00:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 18 Jan 2019 20:00:52 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8BCF1372C; Fri, 18 Jan 2019 14:00:51 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8BCF1372C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7B14940D358A; Fri, 18 Jan 2019 14:00:51 -0500 (EST) Date: Fri, 18 Jan 2019 14:00:51 -0500 (EST) From: Paul Wouters To: "Panos Kampanakis (pkampana)" cc: Valery Smyslov , IPsecME WG , "ipsecme-chairs@ietf.org" , "david.waltermire@nist.gov" In-Reply-To: Message-ID: References: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> <012f01d4af22$25cb8230$71628690$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.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: Fri, 18 Jan 2019 19:01:12 -0000 On Fri, 18 Jan 2019, Panos Kampanakis (pkampana) wrote: > Thanks for the detailed reviews Paul. I don't think the new text is changing the meaning of the text that is already there. Anyone reading either of the two, would be able to understand the point. Thus, I feel there is no need to make the new change this late in WGLC process. This statement is incorrect from a procedural point of view. It is never too late in the WGLC for the WG to make the document better if everyone agrees. Clarifying the text before sending in onto the rest of the IETF for LC is what is supposed to happen in a working group. Especially since this was new text, and not text that has resided in many revisions before the last one. Revision numbers are cheap. Let's make our documents easier to read. I'm okay with Valerie's comment about not introducing MITM in the change. But I'd really like to say the two sentences that start with "note" to be rewritten for easier reading. Paul From nobody Fri Jan 18 14:53:02 2019 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 5B58713144C; Fri, 18 Jan 2019 14:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 c9anM_N3456d; Fri, 18 Jan 2019 14:52:59 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 4367E12872C; Fri, 18 Jan 2019 14:52:59 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7A4399868BFAED8D6288; Fri, 18 Jan 2019 22:52:56 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Jan 2019 22:52:56 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.237]) by SJCEML703-CHM.china.huawei.com ([169.254.5.133]) with mapi id 14.03.0415.000; Fri, 18 Jan 2019 14:52:51 -0800 From: Linda Dunbar To: "draft-carrel-ipsecme-controller-ike@ietf.org" , "David Carrel (carrel)" , "Brian Weis (bew)" CC: "i2nsf@ietf.org" , "ipsec@ietf.org WG" Thread-Topic: Policy distributed by the controller Thread-Index: AdSveXpiKSjwHSmpRJuy2uzBIUTadA== Date: Fri, 18 Jan 2019 22:52:50 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B24D4A1@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.80] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B24D4A1sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] Policy distributed by the controller 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, 18 Jan 2019 22:53:01 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B24D4A1sjceml521mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave and Brian, The first sentence of the Section 6 of draft-carrel-ipsecme-controller-ike-= 00 states that IPsec device distributes to a controller the associated poli= cy to create IPsec. In a SD-WAN deployment with Controller Managed IPsec, i.e. all SD-WAN edges= being controlled by the Controller (which includes the "IPsec Configuratio= n Server"), can we eliminate the step for Devices to "choose the correct po= licy" and to distribute DIM? Basically eliminate the step of requiring SD-WAN edges to distribute the IK= Ev2 payloads of [ID, [N(INITIAL_CONTACT),] KE, Ni]? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F66B24D4A1sjceml521mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave and Brian,

 

The first sentence of the Section 6 of draft-carrel-= ipsecme-controller-ike-00 states that IPsec device distributes to a control= ler the associated policy to create IPsec.

 

In a SD-WAN deployment with Controller Managed IPsec= , i.e. all SD-WAN edges being controlled by the Controller (which includes = the “IPsec Configuration Server”), can we eliminate the step fo= r Devices to “choose the correct policy” and to distribute DIM?

Basically eliminate the step of requiring SD-WAN edg= es to distribute the IKEv2 payloads of [ID, [N(INITIAL_CONTACT),] KE, Ni]?

 

 

Thanks, Linda Dunbar

 

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F66B24D4A1sjceml521mbschi_-- From nobody Mon Jan 21 06:01:27 2019 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 9FD35130F86 for ; Mon, 21 Jan 2019 06:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 RvktfLMfjn6C for ; Mon, 21 Jan 2019 06:01:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 4BADA130ECD for ; Mon, 21 Jan 2019 06:01:20 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0LE0qWf005297 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Jan 2019 16:00:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0LE0oSM026396; Mon, 21 Jan 2019 16:00:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23621.53394.686567.253287@fireball.acr.fi> Date: Mon, 21 Jan 2019 16:00:50 +0200 From: Tero Kivinen To: "Panos Kampanakis \(pkampana\)" Cc: Paul Wouters , Valery Smyslov , IPsecME WG , "david.waltermire\@nist.gov" In-Reply-To: References: <154781116115.17402.13780278168942489653.idtracker@ietfa.amsl.com> <012f01d4af22$25cb8230$71628690$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 10 min Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-qr-ikev2-06.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, 21 Jan 2019 14:01:26 -0000 Panos Kampanakis (pkampana) writes: > Thanks for the detailed reviews Paul. I don't think the new text is > changing the meaning of the text that is already there. Anyone > reading either of the two, would be able to understand the point. > Thus, I feel there is no need to make the new change this late in > WGLC process. WGLC is not late, it is early... Paul's text is easier to read, and I think that pointing out that initiators Peer identity, feature negotiatons, vendor ids are already available for active attacker doing man in the middle of the connection is good point. Usually the responder already has static address, thus most of this information is already known to everybody, so initiators information is more important. Also we can later add protection for both peer identities if we like, i.e. use random one use pseudonyms in the initial exchange. Paul Wouters writes: > I have another minor suggested change :) > > current: > > Note that [RFC6023] allows to > skip creating Child SA in the IKE_AUTH exchange, so that the > supporting peers can rekey the IKE SA before any Child SA is created. > Note also that some information (identities of the peers, feature > negotiation notifications, Vendor IDs etc.) is always exchanged in > initial exchanges and thus cannot be protected from the attack > described above by performing an IKE SA rekey. > > new: > > It is possible to create a childless IKE SA in IKE_AUTH as specified > in [RFC6023]. This prevents Child SA configuration information from > being transmited in the original IKE SA that is not protected by a > PPK. Information in the initial IKE_INIT and IKE_AUTH exchanges, > such as peer identities, feature notifications and Vendor ID's > cannot be hidden from the attack described above, even if the > additional IKE SA rekey is performed. Although this information > would also be available to a Man-in-the-middle attacker without a > quantum computer. This last sentence should probably be rewritten to be more accurate, i.e.: Although initiators information would also be available to a Man-in-the-middle attacker without a quantum computer. > This removes the two "note" from sentences which make them less easy > to read, and quantifies the leaked information a bit in the context > of a simple MITM, non-quantum attack. It explains a bit better why > there isn't a strong reason to try and hide the peer identities and > VIDs from attackers with quantum computers. -- kivinen@iki.fi From nobody Mon Jan 21 22:37:52 2019 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 75B9B12D84D; Mon, 21 Jan 2019 22:37:51 -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: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154813907142.8182.9864665806182381739@ietfa.amsl.com> Date: Mon, 21 Jan 2019 22:37:51 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-07.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: Tue, 22 Jan 2019 06:37:51 -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 : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-07.txt Pages : 18 Date : 2019-01-21 Abstract: The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-07 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 21 22:42:18 2019 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 E19461310BD; Mon, 21 Jan 2019 22:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7F8GlYIE6Qjx; Mon, 21 Jan 2019 22:42:15 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 C6B0012D84D; Mon, 21 Jan 2019 22:42:14 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id e26so17225633lfc.2; Mon, 21 Jan 2019 22:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=VtyLxoweUzX1b5oj2di/TTXIJcdIzvtxKP97CB9UxXU=; b=vZblkPWGSA+qMA5vd/W5UuS5aDEcz/cEBV4InrbiC9BubOviheithhUNrrWuC2USmL KK9BuxIgfLfjkwA4gZzSLRTitlNKDmQnV99TvCTVM43nV23incalfYOhnBBg9jnc+F/A yqwT5+C1rYhpbs6AoliI/4NrLc4A8cV7zaTZr98l3bJuB+YmkRaL7tfamC6O7Dcdpiqx v3d5lpRHUSFEUddYXRZbcqRL5T0sY5ZvDXbvruwowHABcCxF01OhtxFz0nT3ayY5AySE vN++tleKjrjeBezMHyEtiLGSRiI5urkjKGEjeZH2LKM1qf9WxxnCNz7M9L31jN3JGMyb HIYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=VtyLxoweUzX1b5oj2di/TTXIJcdIzvtxKP97CB9UxXU=; b=mdYOvFhmVYqpYQZrV04QFvdxI1sfB1KmRpTGDozSBFovM/xxq71mfb+K02jsxdU6x+ gt3ZHtmuHooDEHCx6n6pA6vX6/BsszIDPck5Quh7C8MirPkR0SQpXnrdsG+qQQxwvMpS o8iLJ9J5a6EmX29MTzxgqT3jGm5uKvaizLDbfCypuCHgE9TNzzEWdaTeZnHMBRuH2lV5 4jUUTKvjIzMFaAtmCLL+4iizCHVyfNfAuoDrjKxogzWjpxA4P9eQUO+IS/9q81CWwt0g KyQszflntrWsi+c9l0e8S5bIFTwnMNU8m/VMTPHpWKhEbA+8BUkwrWcJNSy2KumftMwo fxnw== X-Gm-Message-State: AJcUukdQQ3cZ1/fyLX3ZF3zKMRoYqIyXUzQyTRSxdv/C5ukpv6galAGW URak03OjLUv4DeMYTjLAv/IYKAw1 X-Google-Smtp-Source: ALg8bN6W5S6DQCYIk7+fV6qdGfPcllOupeRzvGuc1UOpTolmzVPQO1p7SdlI/lZPvcbFYStBPwib5A== X-Received: by 2002:a19:5ad0:: with SMTP id y77mr20792776lfk.109.1548139332952; Mon, 21 Jan 2019 22:42:12 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h3sm2683187lfb.49.2019.01.21.22.42.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Jan 2019 22:42:12 -0800 (PST) From: "Valery Smyslov" To: Cc: , References: <154813907142.8182.9864665806182381739@ietfa.amsl.com> In-Reply-To: <154813907142.8182.9864665806182381739@ietfa.amsl.com> Date: Tue, 22 Jan 2019 09:42:12 +0300 Message-ID: <017301d4b21d$9b9c6260$d2d52720$@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: AQJQhjBsiUxfaGw1h50PfgFxwOaazqTDLcnA Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-07.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: Tue, 22 Jan 2019 06:42:17 -0000 Hi, a new version of draft-ietf-ipsecme-qr-ikev2 (-07) has been posted. It addresses Paul Wouters' second comment about the Security Considerations text. Regards, Valery (for the authors). > 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 : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-07.txt > Pages : 18 > Date : 2019-01-21 > > Abstract: > The possibility of Quantum Computers pose a serious challenge to > cryptography algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-07 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jan 23 22:44:37 2019 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 564DE1310AC for ; Wed, 23 Jan 2019 22:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 0TL9PZqPUhb5 for ; Wed, 23 Jan 2019 22:44:32 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 008D412D4EF for ; Wed, 23 Jan 2019 22:44:31 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id s5-v6so4186619ljd.12 for ; Wed, 23 Jan 2019 22:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=b0HeWqgKerKtPRylfTZhm1ccSKA0V76nqIniTNqqaNU=; b=J3oayx07NvQC1qwXnveVZFHO2HvrJmf14bedmxTGN1gO+IkKcBYo/nUVUysuG3kJc6 PAc/V+89rdOuIiVC8l6ZHaoPdZ4rWV+RQ/NID5hdA1iZEHRVeaA/rsQiJf1KF7VwT+xQ OsxxEqjT5KIOw2ZPfYaXnKUvjFFb+HffI//vrJNsT37U0M6KqlUSyKAkFBv8N1zzGnbo 9nX19Tv+8EP7tp3QYkbQhoS2/uSCaClwX0XdX2GaLOL3FFGdbNc/Nv+K0+IQKDZ122y4 xQJ2bsIVUEI8JtHNytIsF5mRJf3piM35Ii/pW39UkDIQ1KOIFON/4TflP7fc4IBOGRL5 bMoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=b0HeWqgKerKtPRylfTZhm1ccSKA0V76nqIniTNqqaNU=; b=gSvIaCIS4q+knj6mxvxkLn2aUdLi+tYPxmrWDmQaL38jJFVx/bPBGMNBYEK61bkBI0 4bK/YB+5tfTdSnb4jBBVN+/J1bJY4UuS5SAYhdOEG1uIl4pn/fXYZs030AziLzvqz6Ep /NUliopLjUFM6N6gPvJmb04MNez1qsNPMacF/+YtzQpQxZYYEs4Ns2pkHBHOIwY8RsRV y2km9Mg3FHhOVaEMFtxTpkLXnUTl+CVnDRKzjKaXCpk/6ihVl+uuvLPq8Sxqa0QEOqX2 jk0TobN7hvKeqJTCYE0tl/hTWv/LQ95gdBydGqT7ScH84/XLmPeBGWuox36sUdTCK2QR pwRA== X-Gm-Message-State: AJcUuke4QJ8n5yGhUbCFRVk+T9SuLmm1fwfRyPTbmHlTMW9ZtzgBdP89 0fi1QxlTTQmBqC7r3yrdTOPYwUvr X-Google-Smtp-Source: ALg8bN6M7vq8j4tDvyrEs3NY7gCv4i8H2kNqP4mE8PqjUARk3Dvih/tQgQt61xlFR/2a+dFK3paI6g== X-Received: by 2002:a2e:744:: with SMTP id i4-v6mr4489446ljd.140.1548312269826; Wed, 23 Jan 2019 22:44:29 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u26-v6sm837128lji.22.2019.01.23.22.44.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Jan 2019 22:44:29 -0800 (PST) From: "Valery Smyslov" To: "'Tobias Heider'" Cc: References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <20190123160531.GB27561@genua.de> In-Reply-To: <20190123160531.GB27561@genua.de> Date: Thu, 24 Jan 2019 09:44:19 +0300 Message-ID: <000b01d4b3b0$3c22da00$b4688e00$@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: AQHua0po1SQdv3p8eF/bRngBUmtvnwHW2sz0AW7+ouelcFoysA== Content-Language: ru Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.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: Thu, 24 Jan 2019 06:44:35 -0000 Hi Tobias, thank you for catching this up. It's a leftover from previous version that somehow escaped our attention. We'll fix it in the next version of the draft. Thank you for careful reading, Valery (for the authors). > Hi Valery, > > i think i just found a minor flaw reading through the new version. > The current draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-03) says in > section 3.1: > > > In order to achieve this, the > > IKE_SA_INIT exchange now includes notify payloads that negotiate the > > extra key exchanges to be used. The initiator IKE_SA_INIT message > > includes a notify that lists the extra key exchange policy required > > by the initiator; the responder selects one of the listed policies, > > and includes that as a notify in the response IKE_SA_INIT message. > > I believe this is obsolete and was overlooked in the last change since the > negotiation of additional KEs is now done in the SA payload. > > Regards, > Tobias From nobody Tue Jan 29 06:21:34 2019 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 8BF2612F18C for ; Tue, 29 Jan 2019 06:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 MEBT54Zv4JMG for ; Tue, 29 Jan 2019 06:21:31 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 9952712D7EA for ; Tue, 29 Jan 2019 06:21:30 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0TELQqI025471 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jan 2019 16:21:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0TELQvE021032; Tue, 29 Jan 2019 16:21:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23632.24934.655381.307535@fireball.acr.fi> Date: Tue, 29 Jan 2019 16:21:26 +0200 From: Tero Kivinen To: Cc: IPsecME WG In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 22 min Archived-At: Subject: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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: Tue, 29 Jan 2019 14:21:34 -0000 mohamed.boucadair@orange.com writes: > First of all, I'd like to thank all those of you who commented > during the ipsecme meeting on this draft. This is exactly the > feedback I was looking for. > > The message I got from the WG after watching the recording is to > reduce the number of requested codes which I did in -02. This is > almost close to what is suggested by Valery and Tero. I hope that > this issue is now closed. Sorry, for taking this long to come back to this, but I think it is still too complicated. We have following cases: 1) Initiator only supports/wants one address family, and it requests it. If responder supports that address family it will give address from that address family. If it also supports another family it may return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. If responder does not support address family requested it will return INTERNAL_ADDRESS_FAILURE (and perhaps include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with another address family). 2) Initiator is dual stack and requests both address families. If responder support both in same IKE SA, it will return address for both. If it only supports one at time then it returns address for that and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that making another IKE SA will allow asking another set addresses. Also I do not think making it MUST to include those notifications is something we want to do here. I think the responder MAY include them if it feels like, but of course 3gpp can then make their own requirements that this feature must be supported there... I.e., ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification indicates that regardless whether your request succeeded or failed, the responder would support another address family than what you asked (if request failed), or what was returned (if request succeeded). As addresses are part of the IKE SA, I guess that if initiator asks for both, but do get only one of them and also got status of ADDITIONAL_ADDRESS_FAMILY_POSSIBLE, then it needs to make new IKE SA and request that another address family in that another IKE SA. -- kivinen@iki.fi From nobody Tue Jan 29 06:39:13 2019 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 0A45012F295 for ; Tue, 29 Jan 2019 06:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 eMvfPXe1fpEF for ; Tue, 29 Jan 2019 06:39:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 6B8E312F1AC for ; Tue, 29 Jan 2019 06:39:09 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0TEd72I018884 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 29 Jan 2019 16:39:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0TEd7X5019705; Tue, 29 Jan 2019 16:39:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23632.25995.122235.479522@fireball.acr.fi> Date: Tue, 29 Jan 2019 16:39:07 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 15 min Archived-At: Subject: [IPsec] Extra note to IKEv2 Transform registries 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, 29 Jan 2019 14:39:12 -0000 Talking as IANA expert, I am planning to send following email to iana. We did discuss this in the Bangkok IETF, and as an IANA export for the IKEv2 registries think this is much better idea, than to copy the recommendations from the RFC8221 an RFC8247 to the iana registry. Does anybody have any comments or objections of doing this? The Note will be part of the per registry header in the IANA page. An example can be seen in the "IKEv2 Configuration Payload Attribute Types" registry, which has note which explains the meaining of "*" in Multi-Valued column. Email to be sent to iana@iana.org next week: ---------------------------------------------------------------------- In Bangkok we discussed that I would like to put reference to RFC8221 and RFC8247 to IKEv2 cryptographic algorithms registries. This would include notes as follows: -- In "Transform Type 1 - Encryption Algorithm Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for encryption algorithms for ESP see RFC 8221, and for IKEv2 see RFC 8247. -- In "Transform Type 2 - Pseudorandom Function Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for PRFs for IKEv2 see RFC 8247. -- In "Transform Type 3 - Integrity Algorithm Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for encryption algorithms for ESP/AH see RFC 8221, and for IKEv2 see RFC 8247. -- In "Transform Type 4 - Diffie-Hellman Group Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for Diffie-Hellman groups for IKEv2 see RFC 8247. -- In "IKEv2 Authentication Method" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for IKEv2 authentication methods see RFC 8247. -- In "IKEv2 Notification IPCOMP Transform IDs (Value 16387)" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for IPCOMP methods see RFC 8221. -- In "IKEv2 Hash Algorithms" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for IKEv2 hash algorithms see RFC 8247. -- kivinen@iki.fi From nobody Tue Jan 29 06:45:41 2019 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 58CEC12F295 for ; Tue, 29 Jan 2019 06:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 TclSBxsLqZuG for ; Tue, 29 Jan 2019 06:45:39 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 CA7A612F1AC for ; Tue, 29 Jan 2019 06:45:38 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0TEjaNK029809 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jan 2019 16:45:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0TEjakI027873; Tue, 29 Jan 2019 16:45:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23632.26384.204074.617309@fireball.acr.fi> Date: Tue, 29 Jan 2019 16:45:36 +0200 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Subject: [IPsec] On marking algorithms obsolete in IANA registries 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, 29 Jan 2019 14:45:40 -0000 Paul Wouters writes: > > Recently we had a discussion about mapping IANA entries to a yang model, > and the question came up whether we sould add a deprecated marker to the > IKE/ESP registries for algorithms. > > I thought it was a good idea, but not everyone agreed. > > I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms > > > Section 2.1: Algorithm Identifiers > > In the IPsec protocol suite, the Internet Key Exchange Protocol > version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the > Authentication Header (AH) [RFC4302] and the Encapsulating Security > Payload (ESP) [RFC4303]. Such separation is a completely fine design > choice. [...] > > An IANA registry SHOULD be used for these algorithm or suite > identifiers. Once an algorithm identifier is added to the registry, > it should not be changed or removed. However, it is desirable to > mark a registry entry as deprecated when implementation is no longer > advisable. > > So there is even an RFC stating that we should really do this :) > > I guess the main question is, can we add these via a request to IANA > based on RFC 8221 and 8247, or do we need to write a short RFC with > requests to IANA? Mostly you would need to convince me as an IANA expert to do that, and I do think it is wrong place to store that information and will make registry confusing and messy, so I do not want to do it. If (when?) you fail to do that then you would need to write draft and try to get WG consensus on that (and then David would take care of that draft). The problem is that to be really usuful we would need to include similar text we already have in RFC8247 for example, i.e., explain where ENCR_AES_CCM_8 is useful and why it is SHOULD for some environments, but not SHOULD for others etc. I still think adding notes (as I explained in my other email sent few minutes ago) is better option, and I plan to do that regardless... -- kivinen@iki.fi From nobody Tue Jan 29 07:01:42 2019 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 3F73F130DBE for ; Tue, 29 Jan 2019 07:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1sfj6ORImcdU for ; Tue, 29 Jan 2019 07:01:33 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8986512F1AC for ; Tue, 29 Jan 2019 07:01:33 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 43pqT768ZPz10fg; Tue, 29 Jan 2019 16:01:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 43pqT75Rcsz8sYc; Tue, 29 Jan 2019 16:01:31 +0100 (CET) Received: from OPEXCAUBM5F.corporate.adroot.infra.ftgroup (10.114.13.104) by OPEXCLILMA4.corporate.adroot.infra.ftgroup (10.114.31.75) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 29 Jan 2019 16:01:31 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup ([fe80::193b:bc32:1ad3:362d%22]) with mapi id 14.03.0415.000; Tue, 29 Jan 2019 16:01:31 +0100 From: To: Tero Kivinen CC: IPsecME WG Thread-Topic: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt Thread-Index: AQHUt93vkjK8YIf+HEWKhvCwg/8K86XGTTbQ Date: Tue, 29 Jan 2019 15:01:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23632.24934.655381.307535@fireball.acr.fi> In-Reply-To: <23632.24934.655381.307535@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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: Tue, 29 Jan 2019 15:01:40 -0000 Hi Tero,=20 Thank you for the comments.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Tero Kivinen [mailto:kivinen@iki.fi] > Envoy=E9=A0: mardi 29 janvier 2019 15:21 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: IPsecME WG > Objet=A0: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.t= xt >=20 > mohamed.boucadair@orange.com writes: > > First of all, I'd like to thank all those of you who commented > > during the ipsecme meeting on this draft. This is exactly the > > feedback I was looking for. > > > > The message I got from the WG after watching the recording is to > > reduce the number of requested codes which I did in -02. This is > > almost close to what is suggested by Valery and Tero. I hope that > > this issue is now closed. >=20 > Sorry, for taking this long to come back to this, but I think it is > still too complicated. >=20 [Med] Let's see what is complicated with these two codes.=20 > We have following cases: >=20 > 1) Initiator only supports/wants one address family, and it requests > it. If responder supports that address family it will give address > from that address family. [Med] Yes. If it also supports another family it may > return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. [Med] An initiator which is interested to receive both would naturally inc= lude both in its initial request. =20 If responder does not > support address family requested it will return > INTERNAL_ADDRESS_FAILURE (and perhaps include > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with > another address family). [Med] This is more complicated compared to the current design in the draft = which allows to return a status code. The initiator will then know whether = it has to retry with another address family.=20 >=20 > 2) Initiator is dual stack and requests both address families. If > responder support both in same IKE SA, it will return address for > both. [Med] Yes, but we need also to cover this case:=20 o An initiator asks for both IPv4 and IPv6 addresses, but only one address family can be assigned by the responder for policy reasons. The initiator needs to know why only one address is assigned so that it doe= s not retry; hence the two separate codes.=20 If it only supports one at time then it returns address for that > and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that making > another IKE SA will allow asking another set addresses. [Med] I'm afraid this is more complicated compared with the current design = which assumes that an initiator which interested to receive both AFs will i= nclude both in the initial request. >=20 > Also I do not think making it MUST to include those notifications is > something we want to do here. [Med] From an interoperability standpoint, MUST is justified here. No?=20 I think the responder MAY include them > if it feels like, but of course 3gpp can then make their own > requirements that this feature must be supported there... >=20 > I.e., ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification indicates > that regardless whether your request succeeded or failed, the > responder would support another address family than what you asked (if > request failed), or what was returned (if request succeeded). >=20 > As addresses are part of the IKE SA, I guess that if initiator asks > for both, but do get only one of them and also got status of > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE, then it needs to make new IKE SA > and request that another address family in that another IKE SA. > -- > kivinen@iki.fi From nobody Tue Jan 29 07:09:04 2019 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 BA7DE126F72 for ; Tue, 29 Jan 2019 07:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 KrQ2cGGBpFb4 for ; Tue, 29 Jan 2019 07:09:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 06A2212D84D for ; Tue, 29 Jan 2019 07:09:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43pqdk6X0Xz7c0; Tue, 29 Jan 2019 16:08:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548774538; bh=P4WE1l/hpJJ0c3hlIdlSOqoE/t6ATt/UmwdFWOx3dRk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FIAoz7RKqBpbzX5U1c4CGJVFmyMuQgyoMeSNztMPigctVNiRGTei3EtLXdOSkntvq rWoa/2FQ/5fas7fQ5fcm9M4v5vQptJUevqQlowdFzjGq9ofUeM/sYt9mK7f/I5IY7d B74WnswayLPMpQ7xK/Z3bhXooKlEdgvtRkObDUqg= 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 aPylwsIRkTVQ; Tue, 29 Jan 2019 16:08:57 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 29 Jan 2019 16:08:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BD769373B; Tue, 29 Jan 2019 10:08:55 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BD769373B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B0F3840D358A; Tue, 29 Jan 2019 10:08:55 -0500 (EST) Date: Tue, 29 Jan 2019 10:08:55 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23632.25995.122235.479522@fireball.acr.fi> Message-ID: References: <23632.25995.122235.479522@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries 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, 29 Jan 2019 15:09:04 -0000 On Tue, 29 Jan 2019, Tero Kivinen wrote: > In "Transform Type 2 - Pseudorandom Function Transform IDs" of > "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as > follows: > > To find out requirement levels for PRFs for IKEv2 see RFC > 8247. Requirement for what? I don't think the IANA reader will know these are vendor build support requirements, and not default case runtime requirements ? I don't object, but I obviously think it is better for implementers to be able to look at the IANA registry with clickable references to the RFC that obsoleted/deprecated an algorithm. Paul From nobody Tue Jan 29 07:12:06 2019 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 7A50F12426A for ; Tue, 29 Jan 2019 07:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 7Z_I9m2qlyBD for ; Tue, 29 Jan 2019 07:12:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C038B123FFD for ; Tue, 29 Jan 2019 07:12:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43pqjG2Vgrz1mf; Tue, 29 Jan 2019 16:12:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548774722; bh=sACja2QDaOwVpX7DhVu6+0ZqwS32yxY1vYU+stM/TNs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pB0tiEglaTjmwPooIdLcURHSJHUdpPB1I4Pwk3qD9bjvBGq40xe9CYT69iK+2E9BL CDWstUc8NLP2epOiz00Y7ijU0oYr4+gW4Z870/3/Nrhb/YcnFKqq/CMsMCkwcVQTdY gf112jMwPkehGGAgAsLlxXLLZof+dr5YEGhWZkdY= 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 eeP02nx25dkA; Tue, 29 Jan 2019 16:12:00 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 29 Jan 2019 16:12:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BF2D9373B; Tue, 29 Jan 2019 10:11:59 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BF2D9373B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B87C540D358A; Tue, 29 Jan 2019 10:11:59 -0500 (EST) Date: Tue, 29 Jan 2019 10:11:59 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <23632.26384.204074.617309@fireball.acr.fi> Message-ID: References: <23632.26384.204074.617309@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries 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, 29 Jan 2019 15:12:05 -0000 On Tue, 29 Jan 2019, Tero Kivinen wrote: > The problem is that to be really usuful we would need to include > similar text we already have in RFC8247 for example, i.e., explain > where ENCR_AES_CCM_8 is useful and why it is SHOULD for some > environments, but not SHOULD for others etc. I explained before that only MUST NOT entries would be marked in the registry along with SHOULD NOT entries qualifying for deprecation due to disuse (eg CAST). Anything with a "qualifier" would not be marked in the registry as obsolete/deprecated. Paul From nobody Tue Jan 29 10:37:03 2019 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 3ED54130FB4 for ; Tue, 29 Jan 2019 10:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 nzA1oqxnnulk for ; Tue, 29 Jan 2019 10:36:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 B9ECB130F88 for ; Tue, 29 Jan 2019 10:36:58 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0TIatuA004896 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jan 2019 20:36:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0TIatV1026178; Tue, 29 Jan 2019 20:36:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23632.40263.252953.62010@fireball.acr.fi> Date: Tue, 29 Jan 2019 20:36:55 +0200 From: Tero Kivinen To: Cc: IPsecME WG In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23632.24934.655381.307535@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 15 min Archived-At: Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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: Tue, 29 Jan 2019 18:37:02 -0000 mohamed.boucadair@orange.com writes: > > We have following cases: > > > > 1) Initiator only supports/wants one address family, and it requests > > it. If responder supports that address family it will give address > > from that address family. > > [Med] Yes. > > If it also supports another family it may > > return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. > > [Med] An initiator which is interested to receive both would > naturally include both in its initial request. This was case 1, where the initiator does not want two, it only wants one in this IKE SA, and if it supports two, it wants to make them separate IKE SAs because of policy reasons. The case 2 is when initiator asks for both. > > > If responder does not support address family requested it will > > return INTERNAL_ADDRESS_FAILURE (and perhaps include > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with > > another address family). > > [Med] This is more complicated compared to the current design in the > draft which allows to return a status code. The initiator will then > know whether it has to retry with another address family. I do no see any difference here. Only thing is that we do not have two status codes (IP6_ONLY_ALLOWED, IP4_ONLY_ALLOWED), we have only one (ADDITIONAL_ADDRESS_FAMILY_POSSIBLE), and that the logic is reversed. I.e., in your case you return one of the two possible status codes if no other address family than what was requested can be given, in my proposal I would return the address of requested address family and status notification telling that another address family would also be possible. In both cases if the responder can return some address family it will return that in configuration payload, if not it will return INTERNAL_ADDRESS_FAILURE. As there can only be IP4_ONLY_ALLOWED or IP6_ONLY_ALLOWED but never both, what is the point of having two status codes? > > 2) Initiator is dual stack and requests both address families. If > > responder support both in same IKE SA, it will return address for > > both. > > [Med] Yes, but we need also to cover this case: > > o An initiator asks for both IPv4 and IPv6 addresses, but only one > address family can be assigned by the responder for policy > reasons. > > The initiator needs to know why only one address is assigned so that > it does not retry; hence the two separate codes. Initiator will know that it can get the address from the family that the responder returned. If there is no ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no other family is possible, thus there is no point of trying to retry. If ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is returned (along with the actual ip addresses from one address family), then initiator knows it can retry. > > If it only supports one at time then it returns address for that > > and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that > > making another IKE SA will allow asking another set addresses. > > [Med] I'm afraid this is more complicated compared with the current > design which assumes that an initiator which interested to receive > both AFs will include both in the initial request. If Initiator and responder both support both address families, then no special status codes are needed, normal RFC7296 processing is fine. Only case where special status cases are needed in this case 2 (where initiator requests both address familieis), is when responder only supports two address families as separate IKE SAs. In that case for first request it will return addresses from one of the address familiies, and indicate that another address family would also be possible by adding ADDITIONAL_ADDRESS_FAMILY_POSSIBLE. When initiator sees that it can create another IKE SA, and request addresses from that other address family over that. This is similar than ADDITIONAL_TS_POSSIBLE in RFC7296. I.e., responder narrowed things down in traffic selectors because of policy reasons, but there would be another possible set of traffic selectors which could be used if requested separately. > > Also I do not think making it MUST to include those notifications is > > something we want to do here. > > [Med] From an interoperability standpoint, MUST is justified here. No? No, as current implementations do not do that, thus this would make all existing implementations not conforming to this, and would most likely also require version number upgrade from the 2.0 to something larger, so other end would know whether other end supports this new MUST or not. Anyways we always leave that kind of decisions to the policy, i.e., even if the implementation is dual-stack, it might not want to request both addresses, if it only needs one. Also you cannot really have MUST do xxx, except yyy. That would be SHOULD, but in this case I think MAY is better. -- kivinen@iki.fi From nobody Tue Jan 29 10:56:03 2019 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 800B1130FC7 for ; Tue, 29 Jan 2019 10:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 SZmgXNu6jN-8 for ; Tue, 29 Jan 2019 10:56:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 94764130FC5 for ; Tue, 29 Jan 2019 10:55:59 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0TItvae000122 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jan 2019 20:55:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0TItvgx028628; Tue, 29 Jan 2019 20:55:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23632.41405.35211.261763@fireball.acr.fi> Date: Tue, 29 Jan 2019 20:55:57 +0200 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <23632.25995.122235.479522@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 18 min Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries 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, 29 Jan 2019 18:56:02 -0000 Paul Wouters writes: > On Tue, 29 Jan 2019, Tero Kivinen wrote: > > > In "Transform Type 2 - Pseudorandom Function Transform IDs" of > > "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as > > follows: > > > > To find out requirement levels for PRFs for IKEv2 see RFC > > 8247. > > Requirement for what? I don't think the IANA reader will know these > are vendor build support requirements, and not default case runtime > requirements ? Iana registry is only for vendors, normal users should ever need to check them ever. Why would some user need to know that PRF_HMAC_SHA1 maps to number 2 on the wire? Only vendors need that information. If users require that information there is something seriously wrong with the user interface of the implementation. Anyways RFC8247 do explain that already: ---------------------------------------------------------------------- 1.4. Document Audience The recommendations of this document mostly target IKEv2 implementers who need to create implementations that meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations regarding implementations. The use of algorithms by a specific user is dictated by their own security policy requirements, which are outside the scope of this document. ---------------------------------------------------------------------- If we add any recommendations for algoritms in the IANA registry we would also need to include such explination there and I do not think we want to copy RFC8247 to iana registry. > I don't object, but I obviously think it is better for implementers > to be able to look at the IANA registry with clickable references > to the RFC that obsoleted/deprecated an algorithm. Sure. Write draft-ietf-ipsecme-ikev2-des-md5-die-die-die and we can use that RFC number for them. Or we can change the reference column for those to point to RFC8221/RFC8247 for those where they say it is MUST NOT. That is something that is easy to do with just sending request to iana. Earlier I understood that you wanted to add some new column there which would add new information that is copied from RFC8221/8247. -- kivinen@iki.fi From nobody Tue Jan 29 11:38:33 2019 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 B24E5130FE6 for ; Tue, 29 Jan 2019 11:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 DmcLKvMfTftP for ; Tue, 29 Jan 2019 11:38:30 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C660C130FD9 for ; Tue, 29 Jan 2019 11:38:29 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43pxcg0xrkzJlZ; Tue, 29 Jan 2019 20:38:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548790707; bh=2l3txB0+YaiqCxJebheYhnfM+mRdp1RLwYmthjNHmnA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=U8x+c9OzHj4ot/I5pUvs5yE8k+yhfRXv5Uol1NrDOCyPGXuxMIt9IGkqUyURlZxIp IROlahRUjgCIRVrLMDSnQS8bBMDZsQAOCFke3jTfblMojOJqj1qJpyfHaYFBMEzOFn vTGK06BwyI/r2+0IJ0V7r6qQM/e61vk+PpdyTylw= 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 4ggRm2imzIh8; Tue, 29 Jan 2019 20:38:26 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 29 Jan 2019 20:38:25 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 55DFA79AB9; Tue, 29 Jan 2019 14:38:24 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 55DFA79AB9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5111D40D358A; Tue, 29 Jan 2019 14:38:24 -0500 (EST) Date: Tue, 29 Jan 2019 14:38:24 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23632.41405.35211.261763@fireball.acr.fi> Message-ID: References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries 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, 29 Jan 2019 19:38:32 -0000 On Tue, 29 Jan 2019, Tero Kivinen wrote: >> Requirement for what? I don't think the IANA reader will know these >> are vendor build support requirements, and not default case runtime >> requirements ? > > Iana registry is only for vendors, normal users should ever need to > check them ever. Fair enough. > Sure. Write draft-ietf-ipsecme-ikev2-des-md5-die-die-die and we can > use that RFC number for them. > > Or we can change the reference column for those to point to > RFC8221/RFC8247 for those where they say it is MUST NOT. > That is something that is easy to do with just sending request to > iana. Either works, that was what we were trying to do :) > Earlier I understood that you wanted to add some new column there > which would add new information that is copied from RFC8221/8247. No, just having the registry confirm which things you should not implement is what I was looking for. Although there is one important difference with 8221/8246, which is what to do with MAY algorithms that we found no strong reason for to MUST NOT, but which should really be retired too. Like CAST for example. But I guess formally, a bis document should move those MAY's to MUST NOT. Paul From nobody Wed Jan 30 01:30:41 2019 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 4449C128CB7 for ; Wed, 30 Jan 2019 01:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cf5QF_tKD9xv for ; Wed, 30 Jan 2019 01:30:38 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2104130F21 for ; Wed, 30 Jan 2019 01:30:37 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 43qJ4r1126z4wTd; Wed, 30 Jan 2019 10:30:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 43qJ4q6tvzzDq7B; Wed, 30 Jan 2019 10:30:35 +0100 (CET) Received: from OPEXCAUBM42.corporate.adroot.infra.ftgroup (10.114.13.45) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 30 Jan 2019 10:30:35 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Wed, 30 Jan 2019 10:30:35 +0100 From: To: Tero Kivinen CC: IPsecME WG Thread-Topic: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt Thread-Index: AQHUt93vkjK8YIf+HEWKhvCwg/8K86XGTTbQgAA1goCAAPj2EA== Date: Wed, 30 Jan 2019 09:30:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0F6C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23632.24934.655381.307535@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <23632.40263.252953.62010@fireball.acr.fi> In-Reply-To: <23632.40263.252953.62010@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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, 30 Jan 2019 09:30:40 -0000 Hi Tero,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Tero Kivinen [mailto:kivinen@iki.fi] > Envoy=E9=A0: mardi 29 janvier 2019 19:37 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: IPsecME WG > Objet=A0: RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-= 02.txt >=20 > mohamed.boucadair@orange.com writes: > > > We have following cases: > > > > > > 1) Initiator only supports/wants one address family, and it requests > > > it. If responder supports that address family it will give address > > > from that address family. > > > > [Med] Yes. > > > > If it also supports another family it may > > > return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. > > > > [Med] An initiator which is interested to receive both would > > naturally include both in its initial request. >=20 > This was case 1, where the initiator does not want two, it only wants > one in this IKE SA, and if it supports two, it wants to make them > separate IKE SAs because of policy reasons. The case 2 is when > initiator asks for both. >=20 > > > > > If responder does not support address family requested it will > > > return INTERNAL_ADDRESS_FAILURE (and perhaps include > > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with > > > another address family). > > > > [Med] This is more complicated compared to the current design in the > > draft which allows to return a status code. The initiator will then > > know whether it has to retry with another address family. >=20 > I do no see any difference here. [Med] The difference is that the status codes in the draft reflect the capa= bilities of the responder independently of the address assignment.=20 Only thing is that we do not have two > status codes (IP6_ONLY_ALLOWED, IP4_ONLY_ALLOWED), we have only one > (ADDITIONAL_ADDRESS_FAMILY_POSSIBLE), and that the logic is reversed. > I.e., in your case you return one of the two possible status codes if > no other address family than what was requested can be given, in my > proposal I would return the address of requested address family and > status notification telling that another address family would also be > possible. >=20 > In both cases if the responder can return some address family it will > return that in configuration payload, if not it will return > INTERNAL_ADDRESS_FAILURE. >=20 > As there can only be IP4_ONLY_ALLOWED or IP6_ONLY_ALLOWED but never > both, what is the point of having two status codes? [Med] If we reason in terms of AF capabilities/policies, codes for each AF = is straightforward. >=20 > > > 2) Initiator is dual stack and requests both address families. If > > > responder support both in same IKE SA, it will return address for > > > both. > > > > [Med] Yes, but we need also to cover this case: > > > > o An initiator asks for both IPv4 and IPv6 addresses, but only one > > address family can be assigned by the responder for policy > > reasons. > > > > The initiator needs to know why only one address is assigned so that > > it does not retry; hence the two separate codes. >=20 > Initiator will know that it can get the address from the family that > the responder returned. If there is no > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no > other family is possible, thus there is no point of trying to retry. [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a request = which already asked for both AFs? >=20 > If ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is returned (along with the > actual ip addresses from one address family), then initiator knows it > can retry. >=20 > > > If it only supports one at time then it returns address for that > > > and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that > > > making another IKE SA will allow asking another set addresses. > > > > [Med] I'm afraid this is more complicated compared with the current > > design which assumes that an initiator which interested to receive > > both AFs will include both in the initial request. >=20 > If Initiator and responder both support both address families, then no > special status codes are needed, normal RFC7296 processing is fine. >=20 > Only case where special status cases are needed in this case 2 (where > initiator requests both address familieis), is when responder only > supports two address families as separate IKE SAs. In that case for > first request it will return addresses from one of the address > familiies, and indicate that another address family would also be > possible by adding ADDITIONAL_ADDRESS_FAMILY_POSSIBLE. When initiator > sees that it can create another IKE SA, and request addresses from > that other address family over that. >=20 > This is similar than ADDITIONAL_TS_POSSIBLE in RFC7296. I.e., > responder narrowed things down in traffic selectors because of policy > reasons, but there would be another possible set of traffic selectors > which could be used if requested separately. >=20 > > > Also I do not think making it MUST to include those notifications is > > > something we want to do here. > > > > [Med] From an interoperability standpoint, MUST is justified here. No? >=20 > No, as current implementations do not do that, thus this would make > all existing implementations not conforming to this, and would most > likely also require version number upgrade from the 2.0 to something > larger, so other end would know whether other end supports this > new MUST or not. >=20 > Anyways we always leave that kind of decisions to the policy, i.e., > even if the implementation is dual-stack, it might not want to request > both addresses, if it only needs one. >=20 > Also you cannot really have MUST do xxx, except yyy. That would be > SHOULD, but in this case I think MAY is better. [Med] If we want more deterministic behaviors of initiators and more intero= perability, MAY is too weak. SHOULD would be OK.=20 > -- > kivinen@iki.fi From nobody Wed Jan 30 12:24:27 2019 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 0700C130E92 for ; Wed, 30 Jan 2019 12:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 v_6fChv0g2wI for ; Wed, 30 Jan 2019 12:24:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 97B85130EC9 for ; Wed, 30 Jan 2019 12:24:21 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0UKOH9l007308 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Jan 2019 22:24:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0UKOHkl019277; Wed, 30 Jan 2019 22:24:17 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23634.2033.574105.617057@fireball.acr.fi> Date: Wed, 30 Jan 2019 22:24:17 +0200 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 9 min Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries 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, 30 Jan 2019 20:24:25 -0000 Paul Wouters writes: > > Or we can change the reference column for those to point to > > RFC8221/RFC8247 for those where they say it is MUST NOT. > > That is something that is easy to do with just sending request to > > iana. > > Either works, that was what we were trying to do :) Ok, then I misunderstood what people were saying earlier, I understood some people wanted to have similar new column that TLS had.. > > Earlier I understood that you wanted to add some new column there > > which would add new information that is copied from RFC8221/8247. > > No, just having the registry confirm which things you should not > implement is what I was looking for. Although there is one important > difference with 8221/8246, which is what to do with MAY algorithms > that we found no strong reason for to MUST NOT, but which should really > be retired too. Like CAST for example. But I guess formally, a bis > document should move those MAY's to MUST NOT. Ok, so the following change would be better: ---------------------------------------------------------------------- In Bangkok we discussed that I would like to put reference to RFC8221 and RFC8247 to IKEv2 cryptographic algorithms registries. This would include notes as follows: -- In "Transform Type 1 - Encryption Algorithm Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for encryption algorithms for ESP see RFC 8221, and for IKEv2 see RFC 8247. Also as RFC8221 and RFC8247 marked some of those documents as MUST NOT, we need to change the reference for those algorithms to refer to those documents instead of the original documents. I.e., change following algorithm references as follows: ESP Reference IKEv2 reference ENCR_DES_IV64 [RFC8221] - ENCR_DES [RFC8221] [RFC8247] ENCR_BLOWFISH [RFC8221] [RFC7296] ENCR_3IDEA [RFC8221] [RFC7296] ENCR_DES_IV32 [RFC8221] - I.e., for all of those algorithms change the ESP refence to RFC8221 which marks those algorithms as MUST NOT for ESP, and for ENCR_DES change the refence for IKEv2 to RFC8247. For ENCR_DES_IV64, ENCR_BLOWFISH, ENCR_3IDEA and ENCR_DES_IV32 keep the IKEv2 references as they are now. -- In "Transform Type 2 - Pseudorandom Function Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for PRFs for IKEv2 see RFC 8247. Also as RFC8247 marked PRF_HMAC_MD5 as MUST NOT, we need to change the reference for that to refer to RFC8247 instead of the original documents. I.e., change following algorithm references as follows: Reference PRF_HMAC_MD5 [RFC8247] -- In "Transform Type 3 - Integrity Algorithm Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for encryption algorithms for ESP/AH see RFC 8221, and for IKEv2 see RFC 8247. Also as RFC8221 and RFC8247 marked some of those documents as MUST NOT, we need to change the reference for those algorithms to refer to those documents instead of the original documents. I.e., change following algorithm references as follows: Reference AUTH_HMAC_MD5_96 [RFC8221][RFC8247] AUTH_DES_MAC [RFC8221][RFC8247] AUTH_KPDK_MD5 [RFC8221][RFC8247] -- In "Transform Type 4 - Diffie-Hellman Group Transform IDs" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for Diffie-Hellman groups for IKEv2 see RFC 8247. Also as RFC8247 marked some of those algorithms as MUST NOT, we need to change the reference for those algorithms to refer to RFC8247 instead of the original documents. I.e., change following algorithm references as follows: Reference 768-bit MODP Group [RFC8247] 1024-bit MODP Group with 160-bit Prime Order Subgroup [RFC8247] -- In "IKEv2 Authentication Method" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for IKEv2 authentication methods see RFC 8247. -- In "IKEv2 Notification IPCOMP Transform IDs (Value 16387)" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for IPCOMP methods see RFC 8221. Also as RFC8221 marked IPCOMP_OUI as MUST NOT, we need to change the reference for that to refer to RFC8221 instead of UNSPECIFIED. I.e., change following algorithm references as follows: Reference IPCOMP_OUI [RFC8221] -- In "IKEv2 Hash Algorithms" of "Internet Key Exchange Version 2 (IKEv2) Parameters" add note as follows: To find out requirement levels for IKEv2 hash algorithms see RFC 8247. Also as RFC8247 marked SHA1 as MUST NOT, we need to change the reference for that to refer to RFC8247 instead of the original documents. I.e., change following algorithm references as follows: Reference SHA1 [RFC8247] -- kivinen@iki.fi From nobody Wed Jan 30 12:36:06 2019 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 659D41312A5 for ; Wed, 30 Jan 2019 12:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 hyXSCwJEq8rS for ; Wed, 30 Jan 2019 12:36:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 37CAB130FEC for ; Wed, 30 Jan 2019 12:36:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43qZrb1wRKzJlx; Wed, 30 Jan 2019 21:35:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548880559; bh=/7QtKMsYWFCEJHPbSzNRTTmXn0Y/p9RLv+yqT4Dyqdk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bYFSWyBc3A1w0txZ4/tX8WZoZr3dz4qVjUNx5XSH26I4d+bxnJZ+Exwtc85lcbj9x A0ubFujMloJ9RL0ritnwp3NIw2pkdNbSMGAQeCb49os3Kbg3zadV7JpDWMWb+Y1GeI XhaNwvWr1y9Huw4XoezdtRcvBEmfc4qWxdLoVeKc= 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 fvjC-_5sEdQm; Wed, 30 Jan 2019 21:35:58 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 30 Jan 2019 21:35:58 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EB8AFA43; Wed, 30 Jan 2019 15:35:56 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EB8AFA43 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DECEF40D358A; Wed, 30 Jan 2019 15:35:56 -0500 (EST) Date: Wed, 30 Jan 2019 15:35:56 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23634.2033.574105.617057@fireball.acr.fi> Message-ID: References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> <23634.2033.574105.617057@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries 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, 30 Jan 2019 20:36:05 -0000 On Wed, 30 Jan 2019, Tero Kivinen wrote: >> Either works, that was what we were trying to do :) > > Ok, then I misunderstood what people were saying earlier, I understood > some people wanted to have similar new column that TLS had.. But your proposed changes does not add "obsolete" or "deprecated" to the IANA registry entries? Paul From nobody Wed Jan 30 12:42:32 2019 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 03372130FFF for ; Wed, 30 Jan 2019 12:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 lqwyz1uzxSKm for ; Wed, 30 Jan 2019 12:42:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 09BA3130FE6 for ; Wed, 30 Jan 2019 12:42:28 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0UKgQ27008120 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Jan 2019 22:42:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0UKgQgc004077; Wed, 30 Jan 2019 22:42:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23634.3122.644454.54601@fireball.acr.fi> Date: Wed, 30 Jan 2019 22:42:26 +0200 From: Tero Kivinen To: Cc: IPsecME WG In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0F6C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23632.24934.655381.307535@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <23632.40263.252953.62010@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0F6C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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, 30 Jan 2019 20:42:31 -0000 mohamed.boucadair@orange.com writes: > > > [Med] This is more complicated compared to the current design in the > > > draft which allows to return a status code. The initiator will then > > > know whether it has to retry with another address family. > > > > I do no see any difference here. > > [Med] The difference is that the status codes in the draft reflect > the capabilities of the responder independently of the address > assignment. That would be fine, if the responder could return this information before the initiator would do configuration request, so initiator could adjusts its request accordingly, but that would require moving those status notifications to IKE_SA_INIT, and for various reasons we try to keep that as small as possible, so I do not think that is correct place for those notifications. > > > > 2) Initiator is dual stack and requests both address families. If > > > > responder support both in same IKE SA, it will return address for > > > > both. > > > > > > [Med] Yes, but we need also to cover this case: > > > > > > o An initiator asks for both IPv4 and IPv6 addresses, but only one > > > address family can be assigned by the responder for policy > > > reasons. > > > > > > The initiator needs to know why only one address is assigned so that > > > it does not retry; hence the two separate codes. > > > > Initiator will know that it can get the address from the family that > > the responder returned. If there is no > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no > > other family is possible, thus there is no point of trying to retry. > > [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a > request which already asked for both AFs? Nope. We do that with other cases too. I.e., initiator did request for both address families, but responder said he want to do those as separate IKE SAs, and returned addresses for only one address family. The status notification indicates that initiator might create another IKE SA and request another address family in there. If it is not there, it will just have to cope with the address family it got in the response. This is same as what we do with ADDITIONAL_TS_POSSIBLE. > > > > Also I do not think making it MUST to include those notifications is > > > > something we want to do here. > > > > > > [Med] From an interoperability standpoint, MUST is justified here. No? > > > > No, as current implementations do not do that, thus this would make > > all existing implementations not conforming to this, and would most > > likely also require version number upgrade from the 2.0 to something > > larger, so other end would know whether other end supports this > > new MUST or not. > > > > Anyways we always leave that kind of decisions to the policy, i.e., > > even if the implementation is dual-stack, it might not want to request > > both addresses, if it only needs one. > > > > Also you cannot really have MUST do xxx, except yyy. That would be > > SHOULD, but in this case I think MAY is better. > > [Med] If we want more deterministic behaviors of initiators and more > interoperability, MAY is too weak. SHOULD would be OK. I would expect this is something that will be dictated by policy anyways, and unless policy says otherwise implementation that will support both address families always asks for both (I mean why not). So I do not think there is any real difference in MAY or SHOULD. Neither one of them can give any suggestion to the adminstrator making the policy, he will decided what to configure regardless what we do here in our documents. I still think MAY would be correct, but I do not complain if people in the WG think SHOULD is better. -- kivinen@iki.fi From nobody Wed Jan 30 12:57:46 2019 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 6B15B130FEC for ; Wed, 30 Jan 2019 12:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 GGcp-T6VhrON for ; Wed, 30 Jan 2019 12:57:43 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 B4E1C130FEB for ; Wed, 30 Jan 2019 12:57:42 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x0UKvdH8006971 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Jan 2019 22:57:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x0UKvdqs010956; Wed, 30 Jan 2019 22:57:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23634.4035.789424.105343@fireball.acr.fi> Date: Wed, 30 Jan 2019 22:57:39 +0200 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <23632.25995.122235.479522@fireball.acr.fi> <23632.41405.35211.261763@fireball.acr.fi> <23634.2033.574105.617057@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] Extra note to IKEv2 Transform registries 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, 30 Jan 2019 20:57:44 -0000 Paul Wouters writes: > On Wed, 30 Jan 2019, Tero Kivinen wrote: > > >> Either works, that was what we were trying to do :) > > > > Ok, then I misunderstood what people were saying earlier, I understood > > some people wanted to have similar new column that TLS had.. > > But your proposed changes does not add "obsolete" or "deprecated" to > the IANA registry entries? No. Only change the reference to the document that says those algorithms are MUST NOT. You wanted clickable link to document that will tell the status. This results in what you asked for.... Having obsolete or deprecated in reference column in addition to the RFC8221/8247 reference would be bigger change, and then I think die-die-die document would be better reference and that document could ask IANA to make the changes. -- kivinen@iki.fi From nobody Wed Jan 30 23:17:13 2019 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 1D239128AFB for ; Wed, 30 Jan 2019 23:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 685qHhHnT3d4 for ; Wed, 30 Jan 2019 23:17:09 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA418129B88 for ; Wed, 30 Jan 2019 23:17:08 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 43qs4L6Mfpz20Dq; Thu, 31 Jan 2019 08:17:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 43qs4L5MMgzDq7h; Thu, 31 Jan 2019 08:17:06 +0100 (CET) Received: from OPEXCAUBM42.corporate.adroot.infra.ftgroup (10.114.13.45) by OPEXCLILM31.corporate.adroot.infra.ftgroup (10.114.31.41) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 31 Jan 2019 08:17:06 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Thu, 31 Jan 2019 08:17:06 +0100 From: To: Tero Kivinen CC: IPsecME WG Thread-Topic: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt Thread-Index: AQHUt93vkjK8YIf+HEWKhvCwg/8K86XGTTbQgAA1goCAAPj2EIAAvHAAgACvqQA= Date: Thu, 31 Jan 2019 07:17:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0FE43@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23632.24934.655381.307535@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <23632.40263.252953.62010@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0F6C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <23634.3122.644454.54601@fireball.acr.fi> In-Reply-To: <23634.3122.644454.54601@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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: Thu, 31 Jan 2019 07:17:11 -0000 Hi Tero,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Tero Kivinen [mailto:kivinen@iki.fi] > Envoy=E9=A0: mercredi 30 janvier 2019 21:42 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: IPsecME WG > Objet=A0: RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-= 02.txt >=20 > mohamed.boucadair@orange.com writes: > > > > [Med] This is more complicated compared to the current design in th= e > > > > draft which allows to return a status code. The initiator will then > > > > know whether it has to retry with another address family. > > > > > > I do no see any difference here. > > > > [Med] The difference is that the status codes in the draft reflect > > the capabilities of the responder independently of the address > > assignment. >=20 > That would be fine, if the responder could return this information > before the initiator would do configuration request, so initiator > could adjusts its request accordingly, but that would require moving > those status notifications to IKE_SA_INIT, and for various reasons we > try to keep that as small as possible, so I do not think that is > correct place for those notifications. [Med] That wasn't my point. My comment is that the codes are static even if= they are made during address configuration. That is:=20 (1) An IPv4-only responder will always include IP4_ONLY_ALLOWED independent= ly of the request (IPv4, IPv6, IPv4 and IPv6). (2) An IPv6-only responder will always include IP6_ONLY_ALLOWED independent= ly of the request. (3) A dual-stack responder configured with an IPv4 preference will always i= nclude IP4_ONLY_ALLOWED in a response to a dual-stack request. (4) A dual-stack responder configured with an IPv6 preference will always i= nclude IP6_ONLY_ALLOWED in a response to a dual-stack request.=20 The behavior of the initiator is more deterministic, e.g., when case (1) is= encountered: - An IPv6 initiator will stop trying asking for IPv6 addresses. - A dual-stack initiator who asked for both won't try with a separate r= equest for IPv6 - A dual-stack initiator who asked first for IPv4 won't sent a request = for IPv6 - A dual-stack initiator who asked first for IPv6 will send a request f= or IPv4 Now consider that ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is to be defined, this= code will returned with the following conditions:=20 (a) An IPv4-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE = only if the initiator asked for IPv6. (b) An IPv6-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE = only if the initiator asked for IPv4. (c) A dual-stack responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE = if the initiator asked for both, but for policy matters only one AF can be = assigned per request.=20 The behavior of the initiator is less deterministic, e.g., case (c): A dual= -stack initiator who asked for both but got only IPv6 or IPv4 does not know= why the other address is not assigned. It will then send a request to try = to get an address.=20 Protocols with rich error codes makes it easier to adjust the behavior, to = diagnostic, etc.=20 >=20 > > > > > 2) Initiator is dual stack and requests both address families. If > > > > > responder support both in same IKE SA, it will return address for > > > > > both. > > > > > > > > [Med] Yes, but we need also to cover this case: > > > > > > > > o An initiator asks for both IPv4 and IPv6 addresses, but only = one > > > > address family can be assigned by the responder for policy > > > > reasons. > > > > > > > > The initiator needs to know why only one address is assigned so tha= t > > > > it does not retry; hence the two separate codes. > > > > > > Initiator will know that it can get the address from the family that > > > the responder returned. If there is no > > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no > > > other family is possible, thus there is no point of trying to retry. > > > > [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a > > request which already asked for both AFs? >=20 > Nope. We do that with other cases too. I.e., initiator did request for > both address families, but responder said he want to do those as > separate IKE SAs, and returned addresses for only one address family. [Med] OK, I see, this is doing the same job as what we used to have in -01: o SINGLE_AF_SUPPORTED: This status type indicates that only a single address family can be assigned per request, not both. This status type is returned when an initiator requested both IPv4 and IPv6 addresses/prefixes in the same request, but only a single address family can be assigned per request by the responder. The address family preference is defined by a policy that is local to the responder. If a responder receives a request for both IPv4 and IPv6 address families, it replies with the preferred address family and includes SINGLE_AF_SUPPORTED notification status type. Upon receipt of this status type, the initiator MAY re-issue another configuration request to ask for an additional address family. =20 I have removed that code because the message I got from the working group i= s to reduce the number of codes.=20 > The status notification indicates that initiator might create another > IKE SA and request another address family in there. >=20 > If it is not there, it will just have to cope with the address family > it got in the response. >=20 > This is same as what we do with ADDITIONAL_TS_POSSIBLE. >=20 > > > > > Also I do not think making it MUST to include those notifications= is > > > > > something we want to do here. > > > > > > > > [Med] From an interoperability standpoint, MUST is justified here. = No? > > > > > > No, as current implementations do not do that, thus this would make > > > all existing implementations not conforming to this, and would most > > > likely also require version number upgrade from the 2.0 to something > > > larger, so other end would know whether other end supports this > > > new MUST or not. > > > > > > Anyways we always leave that kind of decisions to the policy, i.e., > > > even if the implementation is dual-stack, it might not want to reques= t > > > both addresses, if it only needs one. > > > > > > Also you cannot really have MUST do xxx, except yyy. That would be > > > SHOULD, but in this case I think MAY is better. > > > > [Med] If we want more deterministic behaviors of initiators and more > > interoperability, MAY is too weak. SHOULD would be OK. >=20 > I would expect this is something that will be dictated by policy > anyways, and unless policy says otherwise implementation that will > support both address families always asks for both (I mean why not). > So I do not think there is any real difference in MAY or SHOULD. > Neither one of them can give any suggestion to the adminstrator making > the policy, he will decided what to configure regardless what we do > here in our documents. >=20 > I still think MAY would be correct, but I do not complain if people in > the WG think SHOULD is better. > -- > kivinen@iki.fi From nobody Thu Jan 31 10:11:20 2019 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 01BA5130E7B for ; Thu, 31 Jan 2019 10:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 6dRasgb9Sfqu for ; Thu, 31 Jan 2019 10:11:16 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 96B00130E09 for ; Thu, 31 Jan 2019 10:11:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43r7b65tWMz37c; Thu, 31 Jan 2019 19:11:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548958274; bh=aTS1Z6XW1e69D8njHuoLo/4Z7Jkuod2cyKJtxHYpZnw=; h=Date:From:To:Subject; b=PnIO/uPtYp4USPRRZjlCSwbtdJcQuD/sqYyzNoeA/T/aBP47/OYcV++PVE6LQsMgd p4xnKXYWER5xo5RmZVbBUf1UsMzh8VLpAL3bXgTS80SPUsJ4QNQTk7xI4L1FE4eXXx 4A1u9C8/3F/wGaERW3oCkV2+gL78D7302purhJbA= 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 H3thn_YFwIw9; Thu, 31 Jan 2019 19:11:12 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 31 Jan 2019 19:11:11 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1DD02A7E0C; Thu, 31 Jan 2019 13:11:10 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1DD02A7E0C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 147D440D358A; Thu, 31 Jan 2019 13:11:10 -0500 (EST) Date: Thu, 31 Jan 2019 13:11:10 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] RFC 4945 IPsec profiles and foot^W text bullets 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, 31 Jan 2019 18:11:19 -0000 https://tools.ietf.org/html/rfc4945#section-5 ExecSum: Should a certificate with serverAuth marked Critical be rejected by IKE or not? Relevant sections of the RFC: 5.1.3. X.509 Certificate Extensions Conforming IKE implementations MUST recognize extensions that must or may be marked critical according to this specification. These extensions are: KeyUsage, SubjectAltName, and BasicConstraints. [...] With respect to compliance with the PKIX certificate profile, IKE implementations processing certificates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the criticality bit for extensions that are not supported by that implementation. That is, a relying party SHOULD processes all the extensions it is aware of whether the bit is true or false -- the bit says what happens when a relying party cannot process an extension. [...] 5.1.3.2. KeyUsage IKE uses an end-entity certificate in the authentication process. The end-entity certificate may be used for multiple applications. As such, the CA can impose some constraints on the manner that a public key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) extensions apply in this situation. Since we are talking about using the public key to validate a signature, if the KeyUsage extension is present, then at least one of the digitalSignature or the nonRepudiation bits in the KeyUsage extension MUST be set (both can be set as well). It is also fine if other KeyUsage bits are set. [...] 5.1.3.12. ExtendedKeyUsage The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates for use with IKE. [...] If a certificate is intended to be used with both IKE and other applications, and one of the other applications requires use of an EKU value, then such certificates MUST contain either the keyPurposeID id-kp-ipsecIKE or anyExtendedKeyUsage [5], as well as the keyPurposeID values associated with the other applications. Similarly, if a CA issues multiple otherwise-similar certificates for multiple applications including IKE, and it is intended that the IKE certificate NOT be used with another application, the IKE certificate MAY contain an EKU extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with the other application. Recall, however, that EKU extensions in certificates meant for use in IKE are NOT RECOMMENDED. Conforming IKE implementations are not required to support EKU. If a critical EKU extension appears in a certificate and EKU is not supported by the implementation, then RFC 3280 requires that the certificate be rejected. Implementations that do support EKU MUST support the following logic for certificate validation: o If no EKU extension, continue. o If EKU present AND contains either id-kp-ipsecIKE or anyExtendedKeyUsage, continue. o Otherwise, reject cert. I guess confusion arises from the term "supporting the EKU". If a crypto library supports the EKU for TLS, but not for IKE, is this "supported" or not? Furthermore, it seems if you want to use a certificate for TLS and IKE, it seems technically you need to set keyPurposeID id-kp-ipsecIKE or anyExtendedKeyUsage but in practise I've never seen these (I hadn't even heard of it until I read this RFC yesterday) So what happened that bit me. Libreswan uses the NSS library, and it did not have an IPsec profile for certificate validation. So it assumed a TLS profile for validation. This meant IKE certificates were forced to have serverAuth or clientAuth. And we tried verification as server, and on failure tried as client. But if none of these were present, NSS would always fail validation. So we wanted a real IPsec profile, and the NSS people implemented RFC 4945 for us. Then we found a deployment that had set the critical bit for the serverAuth and NSS followed the above, rejected validation, causing regression. What's confusing to me is: Conforming IKE implementations are not required to support EKU. So what should a crypto library do? - Ignore all EKU's in IPsec profile mode? - Ignore the critical flag in all EKU's in IPsec profile mode? - Consider serverAuth as "supported" or "unsupported" for the IPsec profile? - If "supported", should it ignore the critical flag in IPsec profile mode? - Should it consider the above differently depending on id-kp-ipsecIKE or anyExtendedKeyUsage being present? As for the last question, that is theoretical. This usage is simply not used in the wild and requiring it is not going to help anyone at this point. Chairs: I think this is a topic worth discussing, because it might make sense to update 4945 to reflect the reality of dual use certificates that only have the serverAuth EKU. Paul From nobody Thu Jan 31 12:30:08 2019 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 52413130EBE for ; Thu, 31 Jan 2019 12:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SJj/YxOj; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ea8YB1UK 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 zO3TjgthsyrI for ; Thu, 31 Jan 2019 12:30:03 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 277A9130EEA for ; Thu, 31 Jan 2019 12:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548966601; x=1551558601; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dp2dSBWB3Kb5DbggvLtzJNOMvLWq4PMo00121BoYhSs=; b=SJj/YxOjyem071L0t+ufb5VwySCHLZLzoDwIetrX6MD6eKN0GZecNvfwj+m92YrY HVVo/EuOno2mzicbl/Nawel8/sZR4F3pzPuazTnpxKA8AvAAXspREHDFGTrYFuVq oDQXmkOr5Tl1I2QNvDrVMqsu6KOhudcy2se5WUmJAtg=; X-AuditID: c1b4fb25-209009e000005ff7-5f-5c535ac9bdff Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 27.A3.24567.9CA535C5; Thu, 31 Jan 2019 21:30:01 +0100 (CET) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESSMB501.ericsson.se (153.88.183.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 Jan 2019 21:30:00 +0100 Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 Jan 2019 21:30:00 +0100 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 31 Jan 2019 21:30:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dp2dSBWB3Kb5DbggvLtzJNOMvLWq4PMo00121BoYhSs=; b=ea8YB1UKN+qSrclNaD7en7/Sq6NBnlkZYMZJPBQDqGzF/iJa3yTOLYnCKNrbPJMD9VgPQyfhSqyPhKScY+w4z33cOd+vwBxHIJi5Hnp2LKik1GpU+wkteD0CDS7rFq56W/D10EfzHoTrIQ0QiyKbYtx/XgNQ0fY6OVaY4py/Rig= Received: from BN8PR15MB3090.namprd15.prod.outlook.com (20.178.221.213) by BN8PR15MB2691.namprd15.prod.outlook.com (20.179.138.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.21; Thu, 31 Jan 2019 20:29:58 +0000 Received: from BN8PR15MB3090.namprd15.prod.outlook.com ([fe80::592:2ca9:ed41:b420]) by BN8PR15MB3090.namprd15.prod.outlook.com ([fe80::592:2ca9:ed41:b420%3]) with mapi id 15.20.1558.025; Thu, 31 Jan 2019 20:29:58 +0000 From: Daniel Migault To: IPsecME WG Thread-Topic: [NetDev-People] 0x13: Registration is now open Thread-Index: AQHUtKEDsTg1nHO+40+XKuewJeTUfaXAApAggAnayiA= Date: Thu, 31 Jan 2019 20:29:57 +0000 Message-ID: References: <4dbb7543.AM8AACssimIAAAAAAAAAAAKNIe4AAAAz7hMAAAAAAAwWzABcSvKh@mailjet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN8PR15MB2691; 6:oox2G4LA5XRP+9zq6Ovm3enOUlQ0X08bSQqy6MrYHjHHs7EZF9Wllww1fUdZVHcq5cy1vnowjF5q1sjUicm/niRaHKm0+i8H1Bg+EknELK4u71nxQ+1RXa77QaemiQed5Q0I/OpA8N4SgE/bnEipPz+ZFfJrKvioncH86jNTxeBqAv5Ij84G8xVYhLXvaesNEto5xfVnap3MqrA8L7AqXtMfz39/gKjbq2ZS3Ev+f9eCIV/KKbOVwvzmzCxIf9u0/qUMdI+ZSU5rLgLMCIk0t67apKY4LuIvbzqtRNX9pOthPQVRTHt0DMUPj3XikBtpm9G5HFGGTE1paS4uHKSHR3UwYW9n5OCoX0BmIH35mpwwOFgzdr3stve8nkDznHV5Ld55WQkuz0cpYVJmdZPq3adprUs5Vp5hn7Ijxsm9OSrDESafsnECxkQcdbFYp8IxCUF1ET3LWWIFScTd52p65g==; 5:AEyy0k1Lvkgyn0aJ1ApwZmDwQ71lzC+u6brungKyRNiluDWvK0PeCHJhCYg4tCRsMoK9OcSBkT5BOSFUu+nrTSnyouRrqZHTqy1ZKZZujPYlQKKoziSpGu5rGT1R+3edPxEI0DSYlMBMKp+02FVnGvqnHxSoOnaffyYEzlcpmu1Xvq0zuVm6lhqq11DAdXMoGowJkj4t5/suZBc+vq8g7w==; 7:Yq+hqM03EZRQuseY7aTZCPD63dPuoGo0gAAHGJV8y9a0rc6QNhBbmFAuc6eGWtYFAABIcDurF6CpNwaBPAdj9fcw+yeWG9yMw9l+0IZmTjK4B35tGcfaLCwoE2SnXsv4xTtIu4QrTiXd4n2dJVloiQ== x-ms-office365-filtering-correlation-id: 83f0fcdf-c4a4-43c2-320c-08d687bade2b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BN8PR15MB2691; x-ms-traffictypediagnostic: BN8PR15MB2691: x-microsoft-antispam-prvs: x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(396003)(376002)(366004)(84614002)(13464003)(50854003)(189003)(199004)(6306002)(316002)(229853002)(6436002)(53936002)(256004)(6506007)(6916009)(2473003)(44832011)(68736007)(55016002)(74316002)(6116002)(25786009)(486006)(3846002)(86362001)(53546011)(66066001)(11346002)(106356001)(966005)(305945005)(99286004)(7696005)(9686003)(446003)(105586002)(478600001)(2906002)(76176011)(476003)(8676002)(81166006)(186003)(102836004)(7736002)(71190400001)(71200400001)(8936002)(33656002)(14454004)(97736004)(81156014)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB2691; H:BN8PR15MB3090.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uTGwR2Wwi1QmZESZiT0rM5+nAXS9zKWQ87jATxlPo5ODFclk6rovz70dHdTNkT57jWsWNcgi9iVDpGre1WAxz5//c7ykuB+OqOFgKGKGMd5Ia40mBQa4sosiEXBAVI2GO4lH2gUNlS4pAXsoy3N03HJ89xBvRJq+6mvJkEqcRf4nH9el1IaveWwCGjPxicSPeci+1WYVxmOTlfJ4MP0OyIS0NSzMc0WBLaao/Zijr3+KX4lga76QFyPFq9RuR8owhdrRHybCnptTTBMwsKk+MU2JkTLH14RmGaamxyNy1yTSfQ8Y3W/6VDW6mT2RwHHdV9EozKs4476dVlKTdBVybbbsSggmSixZ9n8foUWFXMJvoW2KIoAlj1Y1mx0uWRDr3v6R7OOFQ3fI+PdfK5np1qWPBk+XcReGj0HW14aM9us= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 83f0fcdf-c4a4-43c2-320c-08d687bade2b X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2019 20:29:57.8824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2691 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUyM2J7ue7JqOAYgxNruSz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH0bm1kKvohVvHiwgrGBcYVYFyMnh4SAicSF9xPZuhi5OIQE jjBKTLnZwQrhfGOUuLN7JyOcc6ZxLTuEs4RJ4tXLg0wgDovABGaJluetrCDDhASmMkk8fsgO YT9glOjp4AKx2QSMJNoO9QPFOThEBOQlZt7IBAkLC1hLPJh2HqxcRMBGYnnjNyjbSuL7wU4m EJtFQFXi7f59zCA2r0CMxMk/S6HOW8UosWxjL1gRp0CsxL237WA3MAqISXw/tQYsziwgLnHr yXwmiEcFJJbsOc8MYYtKvHz8D6o+TuLbxx6ouKLEwR0bWCFsWYlL87vB3pcQaGKX+NSzkR0i 4StxZP4pJojETUaJ0586oTq0JJ68vAm1LVviQWcbI4QtI9H39jPUpOusElu/7GCDBFGqxPK1 rYwTGHVmIbl2FjCUmAU0Jdbv0ocIK0pM6X7IPgscAoISJ2c+YVnAyLKKUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzBNHNzyW3UH4+U3jocYBTgYlXh4dcKDY4RYE8uKK3MPMUpwMCuJ8F6N BArxpiRWVqUW5ccXleakFh9ilOZgURLn/SMkGCMkkJ5YkpqdmlqQWgSTZeLglGpgtLM+eS9t 6bZZHMurrAovCocu+fCwd8F87dwL8/6eTD21/o3H1v5J529VcohvCk/fy6rBmehfKhFu036U o2Oq9sWedgsVz69Xam62buipfaMWzDStqGJJLMs9badFGsdjotw9V0pZSPMlB+3fOdcxJcRj xZctoptfxrdfmzpZ/O4KtjxJG91ZSizFGYmGWsxFxYkAGB8Prw8DAAA= Archived-At: Subject: [IPsec] FW: [NetDev-People] 0x13: Registration is now open 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, 31 Jan 2019 20:30:07 -0000 SGksIA0KDQpKdXN0IHRvIGxldCB5b3Uga25vdyB0aGF0IG5ldGRldjB4MTMgaXMgdGFraW5nIHBs YWNlIGp1c3QgYmVmb3JlIHRoZSBJRVRGLiBJUHNlYyBpcyBuZXZlciBmYXIgYXdheSBmcm9tIGEg a2VybmVsIGNvbmZlcmVuY2UsIHNvIGl0IG1pZ2h0IHdvcnRoIGF0dGVuZGluZyB0aGUgY29uZmVy ZW5jZS4gSWYgeW91IGFyZSBwcmVzZW50aW5nLCBmZWVsIGZyZWUgdG8gbGV0IHVzIGtub3cgb24g dGhhdCB0aHJlYWQhDQoNCllvdXJzLCANCkRhbmllbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogSmFtYWwgSGFkaSBTYWxpbSB2aWEgcGVvcGxlIDxwZW9wbGVAbGlzdHMubmV0 ZGV2Y29uZi5vcmc+IA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDI1LCAyMDE5IDY6MjcgQU0NClRv OiBwZW9wbGUgPHBlb3BsZUBuZXRkZXZjb25mLm9yZz4NCkNjOiBwcm9ncmFtLWNvbW1pdHRlZUBu ZXRkZXZjb25mLm9yZw0KU3ViamVjdDogW05ldERldi1QZW9wbGVdIDB4MTM6IFJlZ2lzdHJhdGlv biBpcyBub3cgb3Blbg0KDQoNCldlIGFyZSBwbGVhc2VkIHRvIGFubm91bmNlIHRoZSBvcGVuaW5n IG9mIHJlZ2lzdHJhdGlvbiBmb3IgTmV0ZGV2IDB4MTMuDQpOZXRkZXYgMHgxMyBjb25mZXJlbmNl IHdpbGwgYmUgaGVsZCBvbiBNYXJjaCAyMHRoLTIybmQgYXQgdGhlIEhvdGVsIEdyYW5kaXVtIGlu IFByYWd1ZSwgQ3plY2ggUmVwdWJsaWMuDQpodHRwczovL3d3dy5ob3RlbC1ncmFuZGl1bS5jei9l bi8NCg0KQXMgYWx3YXlzOg0KT3VyIG1haW4gbW90aXZhdGlvbiBpcyB0byBicmluZyB0aGUgY29t bXVuaXR5IHRvZ2V0aGVyIHRvIHRoZSBpZGVhIGV4Y2hhbmdlIGZvdW50YWluIHdlIGNhbGwgTmV0 ZGV2IGNvbmYuDQpXZSBoYXZlIGEgbGFyZ2UgYW1vdW50IG9mIGdvb2Qgc3VibWlzc2lvbnMgdGhp cyB0aW1lIGFuZCB3ZSBhcmUgZ29pbmcgdG8gYmUgb24gYSB0aWdodCBzY2hlZHVsZS4NCkZvciB0 aGF0IHJlYXNvbiwgaW4gYWRkaXRpb24gdG8gc2V2ZXJhbCBicmVha3MsIHdlIGhhdmUgZGVjaWRl ZCB0byBwcm92aWRlIGx1bmNoIGFzIHdlbGwuDQpXZSBkbyBub3QgYWltIHRvIG1ha2UgcHJvZml0 IGZyb20gdGhlIGV2ZW50OyBob3dldmVyLCB0byByZWNvdXAgc29tZSBvZiB0aGUgY29zdCB3ZSBo YXZlIHJhaXNlZCBvdXIgcmVnaXN0cmF0aW9uIGZlZSBieSBDRE4gJDEwL2RheS4NCg0KQ29zdCBp czoNCkNETiAkMzUwICsgMjElIFZBVCAoQ0ROICQ0MjMuNTApIGZvciBlYXJseSBiaXJkIHJlZ2lz dHJhdGlvbiB3aGljaCBleHBpcmVzIG9uIEZlYnJ1YXJ5IDIwdGggMTE6NTlQTSBFYXN0ZXJuIHRp bWUuDQpTdGFydGluZyBGZWIgMjFzdCBvbndhcmRzLCB0aGUgcHJpY2UgZ29lcyB1cCB0byAkNDMw Q0FEICsgVGF4ZXMgKFZBVCkgPSAkNTIwLjMwIENBRCBTdHVkZW50cyBhcmUgNTAlIG9mZiAoSUQg cmVxdWlyZWQpDQoNCkVVIGxhd3MgcmVxdWlyZSB3ZSBjaGFyZ2UgVmFsdWUgQWRkZWQgVGF4IChW QVQpIG9uIHRoZSByZWdpc3RyYXRpb24gZmVlLiBWQVQgbXVzdCBiZSBwYWlkIG9uIHRoZSByZWdp c3RyYXRpb24gZmVlcyBpbiB0aGUgY291bnRyeSB3aGVyZSB0aGUgY29uZmVyZW5jZSBpcyBoZWxk Lg0KDQpXZSB3aWxsIGJlIHBvc3RpbmcgbW9yZSBpbmZvIG9uIHRoZSB3ZWJzaXRlLCBmb3Igbm93 IHRvIHJlZ2lzdGVyIGdvIHRvOg0KaHR0cHM6Ly93d3cub25saW5lcmVnaXN0cmF0aW9ucy5jYS9O ZXRkZXYweDEzLw0KDQpXaGVyZSB0byBzdGF5Og0KVGhlIGNvbmZlcmVuY2UgaXMgYXQgdGhlIEhv dGVsIEdyYW5kaXVtIGluIFByYWd1ZS4NCmh0dHBzOi8vd3d3LmhvdGVsLWdyYW5kaXVtLmN6L2Vu Lw0KV2Ugd2lsbCBwcm92aWRlIHlvdSB3aXRoIGEgZGlzY291bnQgY29kZSBmb3IgdGhhdCBob3Rl bCBpbiB0aGUgbmV4dCBkYXkgb3Igc28uIEFubm91bmNlbWVudCB3aWxsIGJlIHNlbnQgdmlhIGVt YWlsIGFuZCBwb3N0ZWQgb24gdGhlIHdlYnNpdGUNCg0KY2hlZXJzLA0KamFtYWwNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwZW9wbGUgbWFpbGluZyBs aXN0DQpwZW9wbGVAbmV0ZGV2Y29uZi5vcmcNCmh0dHBzOi8vbGlzdHMubmV0ZGV2Y29uZi5vcmcv Y2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3Blb3BsZQ0K From nobody Thu Jan 31 12:38:44 2019 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 D018A130EF3 for ; Thu, 31 Jan 2019 12:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 nRQjNfLYmT5I for ; Thu, 31 Jan 2019 12:38:40 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 CC0C1130EEC for ; Thu, 31 Jan 2019 12:38:39 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43rBs85Yr8zChr; Thu, 31 Jan 2019 21:38:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548967116; bh=5E8I4iZBkkpjPslKtNa/4nH4809U2YM+rHnzMW5S7uU=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=GvwBGwTuK6WsgoIBWyhkLK+2Ln0b5Poffslq87l02BAa2aUKJy9FyN1mEflq19uE+ TLSku2r01uUqgrys3AtQd0b0Ty0TSn0F1gepWaF+XvHln5PquZubwZGigBOGkOCO/q 5fA4i1FkBFxYAT/1sqqCqTdLVAWj7X442/5xbgJw= 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 ICb1i6BNX8LC; Thu, 31 Jan 2019 21:38:35 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 31 Jan 2019 21:38:34 +0100 (CET) Received: from [193.111.228.93] (unknown [193.111.228.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 11B5531ED71; Thu, 31 Jan 2019 15:38:33 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 11B5531ED71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Thu, 31 Jan 2019 15:32:27 -0500 Message-Id: <1B64EBAB-BF81-423C-8292-6A081C0E0918@nohats.ca> References: <4dbb7543.AM8AACssimIAAAAAAAAAAAKNIe4AAAAz7hMAAAAAAAwWzABcSvKh@mailjet.com> Cc: IPsecME WG In-Reply-To: To: Daniel Migault X-Mailer: iPhone Mail (16C101) Archived-At: Subject: Re: [IPsec] FW: [NetDev-People] 0x13: Registration is now open 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, 31 Jan 2019 20:38:43 -0000 And the days before netdev is the Linux kernel IPsec meeting. We try to keep= the group small and manageable but let me know if you are interested and we= can see if there is space. Paul Sent from mobile device > On Jan 31, 2019, at 15:29, Daniel Migault wr= ote: >=20 > Hi,=20 >=20 > Just to let you know that netdev0x13 is taking place just before the IETF.= IPsec is never far away from a kernel conference, so it might worth attendi= ng the conference. If you are presenting, feel free to let us know on that t= hread! >=20 > Yours,=20 > Daniel >=20 > -----Original Message----- > From: Jamal Hadi Salim via people =20 > Sent: Friday, January 25, 2019 6:27 AM > To: people > Cc: program-committee@netdevconf.org > Subject: [NetDev-People] 0x13: Registration is now open >=20 >=20 > We are pleased to announce the opening of registration for Netdev 0x13. > Netdev 0x13 conference will be held on March 20th-22nd at the Hotel Grandi= um in Prague, Czech Republic. > https://www.hotel-grandium.cz/en/ >=20 > As always: > Our main motivation is to bring the community together to the idea exchang= e fountain we call Netdev conf. > We have a large amount of good submissions this time and we are going to b= e on a tight schedule. > For that reason, in addition to several breaks, we have decided to provide= lunch as well. > We do not aim to make profit from the event; however, to recoup some of th= e cost we have raised our registration fee by CDN $10/day. >=20 > Cost is: > CDN $350 + 21% VAT (CDN $423.50) for early bird registration which expires= on February 20th 11:59PM Eastern time. > Starting Feb 21st onwards, the price goes up to $430CAD + Taxes (VAT) =3D $= 520.30 CAD Students are 50% off (ID required) >=20 > EU laws require we charge Value Added Tax (VAT) on the registration fee. V= AT must be paid on the registration fees in the country where the conference= is held. >=20 > We will be posting more info on the website, for now to register go to: > https://www.onlineregistrations.ca/Netdev0x13/ >=20 > Where to stay: > The conference is at the Hotel Grandium in Prague. > https://www.hotel-grandium.cz/en/ > We will provide you with a discount code for that hotel in the next day or= so. Announcement will be sent via email and posted on the website >=20 > cheers, > jamal > _______________________________________________ > people mailing list > people@netdevconf.org > https://lists.netdevconf.org/cgi-bin/mailman/listinfo/people > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jan 31 13:36:29 2019 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 256D4130F6C for ; Thu, 31 Jan 2019 13:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tN1pajFc3BRy for ; Thu, 31 Jan 2019 13:36:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134AC130F88 for ; Thu, 31 Jan 2019 13:36:23 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DFC338267 for ; Thu, 31 Jan 2019 16:33:32 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7D6E2AA4; Thu, 31 Jan 2019 16:36:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7B10211C for ; Thu, 31 Jan 2019 16:36:21 -0500 (EST) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] RFC 4945 IPsec profiles and foot^W text bullets 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, 31 Jan 2019 21:36:28 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > https://tools.ietf.org/html/rfc4945#section-5 > ExecSum: Should a certificate with serverAuth marked Critical be > rejected by IKE or not? It depends upon how it arrives. My position is that any certificate pinned into a config file should always be valid, it's just a container for a public key. If it arrives via a protocol, and must be validated, then all sorts of checks are reasonable, but in general, I dislike checks that reject certificates because they contain *more* than is expected. I don't think it helps anyone, not even the lawyers, and contributes to widespread (weak) PSK usage. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxTalUACgkQgItw+93Q 3WVnnwf/Q/nWWDDlTV1sgd0uU8LJpi8y9yLfu+DuxqCIDqtTVLNZpz3evsYe853k 8vjP+DA9tK7Bk1VXiBj6dyTv2MgWchGVgWWg79xdgUUFoP7uCYbhUwp21Yxij6bb gtRodxud6FJuRBvJp8x1b1uon1jPH9R31IFn3ZJhN7icAcYyFuXM0G7CED+lZBhv 03K8qM2zjr0mTly8x8Ls/3yDmfjdm1W0IxEqWzb5dCIpcIULXRehdWkutP3BCrMk zoUR2BV/6xSYpk+pDEA+oZy7w57kN0Hj0fK98oChBDjEpgREViKCEe/2L4fl5/bq N5H9dyFmoOwhH5MOsOPthO89q8yY9g== =qgCm -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 31 20:05:33 2019 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 CD0C7131202 for ; Thu, 31 Jan 2019 20:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 fNiftZgICAH1 for ; Thu, 31 Jan 2019 20:05:30 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 2EC8F131203 for ; Thu, 31 Jan 2019 20:05:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43rNmk3F9yz3CK; Fri, 1 Feb 2019 05:05:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1548993926; bh=UXL1lJyGsCfiOJCrzorRkWhipKCRH0PX0tHvPFWzksw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KjjeqO3N0tAr+PMeokc5O4VXnZGPLNaOiP8WpvdnYffWh0z4Cir+PdjsuxpKruFzS Md234NgmjpCbGx6O8yGqFam+uZnw9WALmET2tjm80qu4cmWDws+yavGLFYWA6kbnpJ rHdF35er7YF5evJ+xZ/qGZZCpTTMjQ4rst7ETRxk= 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 DCNq6cIwAgIA; Fri, 1 Feb 2019 05:05:24 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 1 Feb 2019 05:05:23 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D1CCE31ED71; Thu, 31 Jan 2019 23:05:22 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D1CCE31ED71 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C569240D358A; Thu, 31 Jan 2019 23:05:22 -0500 (EST) Date: Thu, 31 Jan 2019 23:05:22 -0500 (EST) From: Paul Wouters To: Michael Richardson cc: "ipsec@ietf.org WG" In-Reply-To: <22096.1548970581@localhost> Message-ID: References: <22096.1548970581@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] RFC 4945 IPsec profiles and foot^W text bullets 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, 01 Feb 2019 04:05:32 -0000 On Thu, 31 Jan 2019, Michael Richardson wrote: > If it arrives via a protocol, and must be validated, then all sorts of checks > are reasonable, but in general, I dislike checks that reject certificates > because they contain *more* than is expected. The trouble seems to be that IKE implementations did accept more (like serverAuth) and some did accept weird things like critical bit with EKU's unrelated to IKE/IPsec. > I don't think it helps anyone, not even the lawyers, and contributes to > widespread (weak) PSK usage. I think that was more openssl being the only crappy tool that there was fault :P It's entertaining to see WireGuard go through the same. Certificates are too complex and annoying, lets only support raw keys. We tried that 25 years ago :) So the issue we have now is that we have an RFC with requirements and the real world not following these requirements at all. For example, do you accept a subjectAltName of type dNSName with an IP address in text form. If you are strict on the CA flag, then self-signed certs have to be rejected. And the other issue is that if you want to use a certificate for IKE and TLS (eg an SSL VPN), then you have two PKIX profiles that might actually have contractory constrains or requirements. Additionally, whether you like it or not such a combined certificate will be forced to comply to CAB/forum. As an expale, loading your LetsEncrypt certificate into IKE to use it for SSL-VPN and IPsec VPNs. I think actual deployment, and what is specified in RFCs, at least in RFC 4945, has diverted quite a bit. I think 4945 needs to be updated. But that update would almost have to be "TLS compliant", so it basically comes down to "ignore all the 4945 stuff". Paul