From nobody Sun Dec 4 15:04:17 2016 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 E9E1A129626; Sun, 4 Dec 2016 15:04:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148089265595.5531.2220473726694989505.idtracker@ietfa.amsl.com> Date: Sun, 04 Dec 2016 15:04:15 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 23:04:16 -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 of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-04.txt Pages : 21 Date : 2016-12-04 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04 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 Sun Dec 4 15:06:34 2016 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 18FF4129620 for ; Sun, 4 Dec 2016 15:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 uRGxdnqznNKv for ; Sun, 4 Dec 2016 15:06:31 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 425A012958E for ; Sun, 4 Dec 2016 15:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1480892791; 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=FPPoMbA1Ws13pI6CJPEmKs91YxDJ+w88813X77au76k=; b=dRz7ptZPwXtPUfcvTct5L9bkVB2iMIlrz9Y6NQefZcODL2GbX682SSVuNAIo710/ Kem6Yj3FvuUD9wrI7KvyGpcEAZp7xukRRTeflACBOUHbw5GCx7o6vY/Z8Q9lkrDO ipLvtw0+F06mRMadu0SnG2LAUODXfb9u+JjlBdmp77wb14J8Rlh2/w2r4IpqEsf+ hRErGIJut48rtFQt75eXEPE5U9TVnd8xjvoQSJyHqwHl9vm56qvrMjzmmvkfwQZw mAbTYtr2Rb355Dc2jXfuCHm0A40Hmd9kRfTZ7NUYLgVFIan60c3iWWc6Fv2TofO9 C2QCdyWbRvKLp2cLXdc5gw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 83.9F.19113.671A4485; Sun, 4 Dec 2016 15:06:31 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-96-5844a177c379 Received: from nwk-mmpp-sz06.apple.com (nwk-mmpp-sz06.apple.com [17.128.115.234]) by relay5.apple.com (Apple SCV relay) with SMTP id 95.65.27929.671A4485; Sun, 4 Dec 2016 15:06:30 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.28.219] (unknown [17.153.28.219]) by nwk-mmpp-sz06.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHO00IVOO6UY040@nwk-mmpp-sz06.apple.com> for ipsec@ietf.org; Sun, 04 Dec 2016 15:06:30 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Date: Sun, 04 Dec 2016 15:06:30 -0800 References: <148089265595.5531.2220473726694989505.idtracker@ietfa.amsl.com> To: IPsecME WG In-reply-to: <148089265595.5531.2220473726694989505.idtracker@ietfa.amsl.com> Message-id: <3E7ABAD5-8657-49E9-9648-0B23DAA927FA@apple.com> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAYoVu+0CXCYMosVov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8m3jcwFnyQqLk7bztzA2CfcxcjJISFgIvFn5V7WLkYuDiGB vYwSu6ZdYYFJrD88hREicYhRYkfLO2aQBK+AoMSPyfeAijg4mAXkJQ6elwUJMwtoSXx/1ArW KyQwl0ni11t/kBJhAQmJzXsSQcJsAioSx79tAJsiLKArcWD3YbByFgFViZ6/G5ggWn0knszd yQbSKgI0feaNTJAwp4CvxMnNfSwQB9hIbO5YzwpxpazEyqcbwc6XEJjBJtF6YRvjBEahWUgO nYVw6Cwkhy5gZF7FKJSbmJmjm5lnrpdYUJCTqpecn7uJERSo0+3EdjA+XGV1iFGAg1GJhzdC yiVCiDWxrLgy9xCjNAeLkjjvlWagkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZTjc0bl3hN FNWaWFf5MMbp7OMifacPm4uOuBoK97vMOee2w26nYmfcbCldsydb9xp3FlsFdqcfnfdsk11F yF3fD/NOfI25xvD1kcX7rfYzXde8vhaUqPShcimbVGU8w1KLZuHFE6w11k5f9kWNUaZdZMK9 zwdV1K41XWVqDTg+51h26/s767cqsRRnJBpqMRcVJwIAD2zYODUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FD8SrdsoUuEwcfv5hb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpJvG5kLPklUXJy2nbmBsU+4i5GTQ0LARGL94SmMELaYxIV7 69m6GLk4hAQOMUrsaHnHDJLgFRCU+DH5HksXIwcHs4C8xMHzsiBhZgEtie+PWllAbCGBuUwS v976g5QIC0hIbN6TCBJmE1CROP5tA9gUYQFdiQO7D4OVswioSvT83cAE0eoj8WTuTjaQVhGg 6TNvZIKEOQV8JU5u7mOBOMBGYnPHelaIK2UlVj7dyDqBUWAWkttmIdw2C8ltCxiZVzEKFKXm JFaa6iUWFOSk6iXn525iBAdcYcQOxv/LrA4xCnAwKvHwbpBxiRBiTSwrrswFep6DWUmE9/Nc oBBvSmJlVWpRfnxRaU5q8SHGZKDzJzJLiSbnA6MhryTe0MTEwMTY2MzY2NzEnDRhJXHeKFan CCGB9MSS1OzU1ILUIpgtTBycUg2Mm6JWutz+vON+8jytRYrz9Av4X5zwW7n77PdeW5l2z/4j s/OlhbJncUxZ+dlUUKTr/+01XDWt/99IeHUzsWvbWjzTbLoisnzO5KZvQie1/qWJPSyv2cYj x/F90pZ5O/tDWJSrZszbvoFZTvr6m2WmiTlahw75J7ExKnPJH/TW3CJbeiN+W9cqJZbijERD Leai4kQAEG0alXwCAAA= Archived-At: Subject: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 23:06:33 -0000 Hello all, I've updated the TCP Encapsulation draft with new recommendations around handling the mapping between IKE SAs and TCP Connections based on the conversation at the Seoul meeting. The relevant new text in section 6 is: An initiator SHOULD only open one TCP connection per IKE SA, over which it sends all of the corresponding IKE and ESP messages. This helps ensure that any firewall or NAT mappings allocated for the TCP connection apply to all of the traffic associated with the IKE SA equally. A responder SHOULD at any given time send packets for an IKE SA and its Child SAs over only one TCP connection. It should choose the TCP connection on which it last received a valid and decryptable IKE or ESP message. Since a connection may be broken and a new connection re-established by the initiator without the responder being aware, a responder SHOULD accept receiving IKE and ESP messages on a new connection. It will then use that connection for all subsequent responses. A responder MAY close a TCP connection that it perceives as idle and extraneous (one previously used for IKE and ESP messages that has been replaced by a new connection). Multiple IKE SAs SHOULD NOT share a single TCP connection. Please respond to indicate your thoughts on this! Thanks, Tommy > On Dec 4, 2016, at 3:04 PM, internet-drafts@ietf.org wrote: > > > 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 of the IETF. > > Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename : draft-ietf-ipsecme-tcp-encaps-04.txt > Pages : 21 > Date : 2016-12-04 > > Abstract: > This document describes a method to transport IKE and IPsec packets > over a TCP connection for traversing network middleboxes that may > block IKE negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending both IKE packets for tunnel > establishment as well as tunneled packets using ESP over a TCP > connection. This method is intended to be used as a fallback option > when IKE cannot be negotiated over UDP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04 > > > 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 Tue Dec 6 13:32:16 2016 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 D2471129CA6 for ; Tue, 6 Dec 2016 13:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ew93rEwvCWSP for ; Tue, 6 Dec 2016 13:32:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44525129568 for ; Tue, 6 Dec 2016 13:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14692; q=dns/txt; s=iport; t=1481059917; x=1482269517; h=from:to:subject:date:message-id:mime-version; bh=Njf1D591+ADOv6pShEZAUrgdZBtyOBPDKry6PL+JMgs=; b=cSEUOOY74lG9yGP3NvDrk0YaVNIzG3BoAH9myKev8GWE0j8V8obxgFqo g2zevdOexgqU11j+EnJMpaLS6jOZ9u0geaIdlF76W+a/CiCV6e0HkefbO xbrJAjFFVcaDhkRvJlG+p5Kwd0bysmVh9NTxv/KiBDjtHI0qQhlopwgIG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAQC0LUdY/4wNJK1VCRsBAQEDAQEBC?= =?us-ascii?q?QEBAYJzRgEBAQEBH1qBDY1ApmmFIoIHiEo/FAECAQEBAQEBAWIohG8tXgGBACY?= =?us-ascii?q?BBBuIZ5lBkiSLQQEBAQcCASSEHYIhiHyGCAWaZgGRDoF8jkyHYYovAR83gRmFV?= =?us-ascii?q?YhzgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208,217";a="180214622" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2016 21:31:55 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uB6LVtEK012828 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Dec 2016 21:31:55 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Dec 2016 16:31:54 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 6 Dec 2016 16:31:54 -0500 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Quantum Resistant IKEv2 Thread-Index: AdJQCCXgkOeGxGfPROWQbtulvkq0wA== Date: Tue, 6 Dec 2016 21:31:54 +0000 Message-ID: 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.98.2.57] Content-Type: multipart/alternative; boundary="_000_e0efac6dd30345b9893963a6f1889963XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 21:32:13 -0000 --_000_e0efac6dd30345b9893963a6f1889963XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for= IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) a= s work item. During the discussion, two items were raised, and I would like to hear how = the wider WG feels about these two items: - The first item is "how exactly do we stir in the preshared key (= PPK) into the keying material". By my count, three options were on the tab= le: o There is the option listed in the draft, where we modify both the KEYMA= T and SKEYSEED computations; stirring it into the KEYMAT implies that the I= Psec SAs are generated with QR-resistant keying material, while stirring it= into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (= other than the initial one) also has QR-resistant keying material. This la= tter was done specifically so that an implementation can have protected IKE= SAs (by negotiating a child SA immediately) o Dan Harkins suggested that we modify only the KEYMAT. This is a simple= r option, and will continue to protect the IPsec SAs; however this implies = that any data protected by the IKE SA could potentially be recovered by a Q= uantum Computer. o Valery Smyslov gave a suggestion that we instead stir in the PPK into t= he initial SK_d; as all keying material is generated based on that, this wo= uld also mean that IPsec SAs and any child IKE SAs are also protected. Thi= s also means that an implementation would not need to remember the PPK afte= r the initial negotiation. The only downside I can see is that we would ha= ve to be a bit careful about when we update the SK_d (obviously, before we = actually use it). To me, all three strike me as reasonable ideas (unless we decide that we wi= ll need to protect the real identity data encrypted via the IKE SA; in that= case, Dan's idea doesn't protect that). Can I get opinions as to which st= rikes the group as the best? Are there any fourth options that people woul= d want to put on the table? - The second item is anonymity; some people were interested in pre= serving anonymity (however, not at the expense of excessive complexity). O= ne idea that was brought up was that the initial exchange would be done usi= ng pseudonyms (which would be sufficient for the responder to identity the = PPK), and then once initial IKE SAs have been established (in a QR form), e= xchange the real identities. My questions: o Would this idea of pseudonyms actually give any real identity protectio= n? Wouldn't that assume that several initiators use the same PPK (so they = could use the same pseudonym)? Is that the sort of thing we should be enco= uraging? o Should this be addressed in this draft, or could it be addressed in a f= ollow-up draft? o If it would be addressed in a follow-up, would any hooks be required? = For example, would we want to introduce an opaque bit in a notify message t= o indicate this? o Would we be happy with always negotiating a child SA (as none of the th= ree proposals for stirring in the PPK attempt to protect the initial IKE SA= )? My opinion is that this could be placed in a follow-up draft. Thoughts??? --_000_e0efac6dd30345b9893963a6f1889963XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the WG meeting in Seoul, we discussed the Quantum= Resistant proposal for IKEv2, and decided to make the current draft (draft= -fluhrer-qr-ikev2-03) as work item.

 

During the discussion, two items were raised, and I = would like to hear how the wider WG feels about these two items:=

 

-     &= nbsp;    The first item is “how exactly do we stir in = the preshared key (PPK) into the keying material”.  By my count,= three options were on the table:

o   There is the option listed in the draft, whe= re we modify both the KEYMAT and SKEYSEED computations; stirring it into th= e KEYMAT implies that the IPsec SAs are generated with QR-resistant keying = material, while stirring it into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (other= than the initial one) also has QR-resistant keying material.  This la= tter was done specifically so that an implementation can have protected IKE= SAs (by negotiating a child SA immediately)

o   Dan Harkins suggested that we modify only th= e KEYMAT.  This is a simpler option, and will continue to protect the = IPsec SAs; however this implies that any data protected by the IKE SA could= potentially be recovered by a Quantum Computer.

o   Valery Smyslov gave a suggestion that we ins= tead stir in the PPK into the initial SK_d; as all keying material is gener= ated based on that, this would also mean that IPsec SAs and any child IKE S= As are also protected.  This also means that an implementation would not need to remember the PPK after the = initial negotiation.  The only downside I can see is that we would hav= e to be a bit careful about when we update the SK_d (obviously, before we a= ctually use it).

To me, all three strike m= e as reasonable ideas (unless we decide that we will need to protect the re= al identity data encrypted via the IKE SA; in that case, Dan’s idea d= oesn’t protect that).  Can I get opinions as to which strikes the group as the best?  Are there any fourth opti= ons that people would want to put on the table?

 

-     &= nbsp;    The second item is anonymity; some people were inte= rested in preserving anonymity (however, not at the expense of excessive co= mplexity).  One idea that was brought up was that the initial exchange= would be done using pseudonyms (which would be sufficient for the responder to identity the PPK), and then once = initial IKE SAs have been established (in a QR form), exchange the real ide= ntities.  My questions:

o   Would this idea of pseudonyms actually give = any real identity protection?  Wouldn’t that assume that several= initiators use the same PPK (so they could use the same pseudonym)?  = Is that the sort of thing we should be encouraging?

o   Should this be addressed in this draft, or c= ould it be addressed in a follow-up draft?

o   If it would be addressed in a follow-up, wou= ld any hooks be required?  For example, would we want to introduce an = opaque bit in a notify message to indicate this?

o   Would we be happy with always negotiating a = child SA (as none of the three proposals for stirring in the PPK attempt to= protect the initial IKE SA)?

My opinion is that this c= ould be placed in a follow-up draft.

 

Thoughts???

--_000_e0efac6dd30345b9893963a6f1889963XCHRTP006ciscocom_-- From nobody Wed Dec 7 08:11:30 2016 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 AF4D21299FB for ; Wed, 7 Dec 2016 08:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajjRgrB47PRh for ; Wed, 7 Dec 2016 08:11:28 -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 CEDD51294EF for ; Wed, 7 Dec 2016 08:11:19 -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 uB7GBFjg003228 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 Dec 2016 18:11:15 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB7GBFMs001963; Wed, 7 Dec 2016 18:11:15 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22600.13475.748226.49629@fireball.acr.fi> Date: Wed, 7 Dec 2016 18:11:15 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 69 min X-Total-Time: 26 min Archived-At: Subject: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:11:29 -0000 The RFC4301 requires support for manual keys (section 4.5), but I hope nobody really uses them. The rfc7321bis provides mandatory to implement algorithms for the IKEv2 use, and does not really specifically cover manual keys cases, but it does not really say that manual keyed SAs are out of scope either (like it does say for IKEv1). The issue is that some of the conformance logo documents actually do require manual keys, and to gain those logos implementors need to add support for manual keyed SAs even when nobody is really going to use them (i.e., adding support for manual keys for android VPN client seems little stupid). On the other hand if you use the rfc7321bis requirements for also manual keys, there is only one suggested cipher that can be used, namely ENCR_AES_CBC. None of the counter mode ciphers are safe to use with manual keys, and for example RFC4106 (AES-GCM) requires using automated key management. The RFC4309 (AES-CCM) says that it "should not be used with statically configured keys", and that "MUST use fress keys". RFC7634 (Chacha20-poly1305) does not explictly say anything about manual keys, but says it gets bitstring called KEYMAT from IKE... If we assume rfc7431bis can be used with manual keys too, we need to add some more text saying these ciphers cannot be used with manual keys. Anyways, I think it should be time to mark manual keys as SHOULD NOT. We had it in 4301 as MUST to implement as we assumed that it could be used to fill in keying material from other source than IKE to the IPsec architecture. I do not think that is really happening, I think those other automated key management systems will also generate dynamic keys, and are feeding them in using similar APIs we have for IKEv2. Also manual keys were useful when doing initial IPsec testing in interops, but I have not used them for that purposes in last decade or so... Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT be used, and mark it as updating RFC4301? Or should we have separate RFC stating that? I do not want to change it to MUST NOT as that would require people to remove parts of their implementations to stay complient, but on the other hand I do not want people to wasting their time to implenting interface to configure manual keys when nobody is going to use them. -- kivinen@iki.fi From nobody Wed Dec 7 08:24:23 2016 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 542B912973A for ; Wed, 7 Dec 2016 08:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 wlNRTnhOiAyX for ; Wed, 7 Dec 2016 08:24:15 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8561E129A22 for ; Wed, 7 Dec 2016 08:23:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E5C0D300272 for ; Wed, 7 Dec 2016 11:13:36 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YfVIqnGOlXee for ; Wed, 7 Dec 2016 11:13:34 -0500 (EST) Received: from russellsleysmbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E6AEB3000DC; Wed, 7 Dec 2016 11:13:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <22600.13475.748226.49629@fireball.acr.fi> Date: Wed, 7 Dec 2016 11:23:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22600.13475.748226.49629@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:24:22 -0000 I can see that manual keys are helpful for debugging, but otherwise I = think they SHOULD NOT be used. Russ On Dec 7, 2016, at 11:11 AM, Tero Kivinen wrote: > The RFC4301 requires support for manual keys (section 4.5), but I hope > nobody really uses them. The rfc7321bis provides mandatory to > implement algorithms for the IKEv2 use, and does not really > specifically cover manual keys cases, but it does not really say that > manual keyed SAs are out of scope either (like it does say for IKEv1).=20= >=20 > The issue is that some of the conformance logo documents actually do > require manual keys, and to gain those logos implementors need to add > support for manual keyed SAs even when nobody is really going to use > them (i.e., adding support for manual keys for android VPN client > seems little stupid). >=20 > On the other hand if you use the rfc7321bis requirements for also > manual keys, there is only one suggested cipher that can be used, > namely ENCR_AES_CBC. >=20 > None of the counter mode ciphers are safe to use with manual keys, and > for example RFC4106 (AES-GCM) requires using automated key management. > The RFC4309 (AES-CCM) says that it "should not be used with statically > configured keys", and that "MUST use fress keys". RFC7634 > (Chacha20-poly1305) does not explictly say anything about manual keys, > but says it gets bitstring called KEYMAT from IKE... >=20 > If we assume rfc7431bis can be used with manual keys too, we need to > add some more text saying these ciphers cannot be used with manual > keys.=20 >=20 > Anyways, I think it should be time to mark manual keys as SHOULD NOT. > We had it in 4301 as MUST to implement as we assumed that it could be > used to fill in keying material from other source than IKE to the > IPsec architecture. I do not think that is really happening, I think > those other automated key management systems will also generate > dynamic keys, and are feeding them in using similar APIs we have for > IKEv2. Also manual keys were useful when doing initial IPsec testing > in interops, but I have not used them for that purposes in last > decade or so... >=20 > Perhaps we should add note to the rfc7431bis that manual keys SHOULD > NOT be used, and mark it as updating RFC4301? >=20 > Or should we have separate RFC stating that? >=20 > I do not want to change it to MUST NOT as that would require people to > remove parts of their implementations to stay complient, but on the > other hand I do not want people to wasting their time to implenting > interface to configure manual keys when nobody is going to use them. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 7 11:32:00 2016 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 303901296E4 for ; Wed, 7 Dec 2016 11:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7PA9pAqJMXl for ; Wed, 7 Dec 2016 11:31:57 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 AEFBD1298CF for ; Wed, 7 Dec 2016 11:31:54 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 252E173BE3B34; Wed, 7 Dec 2016 19:31:51 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id uB7JVrnd014789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Dec 2016 19:31:53 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id uB7JVqWt015316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Dec 2016 19:31:53 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Wed, 7 Dec 2016 14:31:52 -0500 From: "Hu, Jun (Nokia - US)" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] RFC4301, rfc7321bis and Manual keys Thread-Index: AQHSUKSyQMlVi5R0E0ivHul/4ll1eqD82+uA Date: Wed, 7 Dec 2016 19:31:51 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <22600.13475.748226.49629@fireball.acr.fi> In-Reply-To: <22600.13475.748226.49629@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:31:59 -0000 OSPFv3 authentication (RFC4552) mandate to use manual key, the reason is OS= PFv3 uses multicast.=20 So I could see manual key IPsec could be needed in any multicast applicatio= ns since group key management is not widely available=20 For above reason, I think it should be "MAY" instead of "SHOULD NOT" > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Wednesday, December 07, 2016 8:11 AM > To: ipsec@ietf.org > Subject: [IPsec] RFC4301, rfc7321bis and Manual keys >=20 > The RFC4301 requires support for manual keys (section 4.5), but I hope > nobody really uses them. The rfc7321bis provides mandatory to implement > algorithms for the IKEv2 use, and does not really specifically cover manu= al keys > cases, but it does not really say that manual keyed SAs are out of scope = either > (like it does say for IKEv1). >=20 > The issue is that some of the conformance logo documents actually do requ= ire > manual keys, and to gain those logos implementors need to add support for > manual keyed SAs even when nobody is really going to use them (i.e., addi= ng > support for manual keys for android VPN client seems little stupid). >=20 > On the other hand if you use the rfc7321bis requirements for also manual = keys, > there is only one suggested cipher that can be used, namely ENCR_AES_CBC. >=20 > None of the counter mode ciphers are safe to use with manual keys, and fo= r > example RFC4106 (AES-GCM) requires using automated key management. > The RFC4309 (AES-CCM) says that it "should not be used with statically > configured keys", and that "MUST use fress keys". RFC7634 > (Chacha20-poly1305) does not explictly say anything about manual keys, bu= t > says it gets bitstring called KEYMAT from IKE... >=20 > If we assume rfc7431bis can be used with manual keys too, we need to add > some more text saying these ciphers cannot be used with manual keys. >=20 > Anyways, I think it should be time to mark manual keys as SHOULD NOT. > We had it in 4301 as MUST to implement as we assumed that it could be use= d > to fill in keying material from other source than IKE to the IPsec archit= ecture. I > do not think that is really happening, I think those other automated key > management systems will also generate dynamic keys, and are feeding them = in > using similar APIs we have for IKEv2. Also manual keys were useful when d= oing > initial IPsec testing in interops, but I have not used them for that purp= oses in > last decade or so... >=20 > Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT > be used, and mark it as updating RFC4301? >=20 > Or should we have separate RFC stating that? >=20 > I do not want to change it to MUST NOT as that would require people to > remove parts of their implementations to stay complient, but on the other > hand I do not want people to wasting their time to implenting interface t= o > configure manual keys when nobody is going to use them. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 7 11:52:51 2016 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 839EA129B36 for ; Wed, 7 Dec 2016 11:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 g1PJLGcVfhxi for ; Wed, 7 Dec 2016 11:52:48 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 08FB3129579 for ; Wed, 7 Dec 2016 11:52:38 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 3ADC1B2CA41F; Wed, 7 Dec 2016 19:52:34 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id uB7Jqbxm019248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Dec 2016 19:52:38 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id uB7JqWEv025427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Dec 2016 19:52:37 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Wed, 7 Dec 2016 14:52:34 -0500 From: "Hu, Jun (Nokia - US)" To: Tommy Pauly , IPsecME WG Thread-Topic: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt Thread-Index: AQHSToMTP2kkxaVk50OAtwc32wFFyKD86dVw Date: Wed, 7 Dec 2016 19:52:33 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB50E34@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <148089265595.5531.2220473726694989505.idtracker@ietfa.amsl.com> <3E7ABAD5-8657-49E9-9648-0B23DAA927FA@apple.com> In-Reply-To: <3E7ABAD5-8657-49E9-9648-0B23DAA927FA@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:52:50 -0000 Looks good to me > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly > Sent: Sunday, December 04, 2016 3:07 PM > To: IPsecME WG > Subject: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt >=20 > Hello all, >=20 > I've updated the TCP Encapsulation draft with new recommendations around > handling the mapping between IKE SAs and TCP Connections based on the > conversation at the Seoul meeting. The relevant new text in section 6 is: >=20 >=20 > An initiator SHOULD only open one TCP connection per IKE SA, over > which it sends all of the corresponding IKE and ESP messages. This > helps ensure that any firewall or NAT mappings allocated for the TCP > connection apply to all of the traffic associated with the IKE SA > equally. >=20 > A responder SHOULD at any given time send packets for an IKE SA and > its Child SAs over only one TCP connection. It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message. Since a connection may be broken and a new connection > re-established by the initiator without the responder being aware, a > responder SHOULD accept receiving IKE and ESP messages on a new > connection. It will then use that connection for all subsequent > responses. A responder MAY close a TCP connection that it perceives > as idle and extraneous (one previously used for IKE and ESP messages > that has been replaced by a new connection). >=20 > Multiple IKE SAs SHOULD NOT share a single TCP connection. >=20 > Please respond to indicate your thoughts on this! >=20 > Thanks, > Tommy >=20 >=20 > > On Dec 4, 2016, at 3:04 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the IP Security Maintenance and Extensions= of the > IETF. > > > > Title : TCP Encapsulation of IKE and IPsec Packets > > Authors : Tommy Pauly > > Samy Touati > > Ravi Mantha > > Filename : draft-ietf-ipsecme-tcp-encaps-04.txt > > Pages : 21 > > Date : 2016-12-04 > > > > Abstract: > > This document describes a method to transport IKE and IPsec packets > > over a TCP connection for traversing network middleboxes that may > > block IKE negotiation over UDP. This method, referred to as TCP > > encapsulation, involves sending both IKE packets for tunnel > > establishment as well as tunneled packets using ESP over a TCP > > connection. This method is intended to be used as a fallback option > > when IKE cannot be negotiated over UDP. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-04 > > > > > > 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.i= etf.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 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 7 13:41:51 2016 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 D61B21296CA for ; Wed, 7 Dec 2016 13:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896] 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 o6sTKH0D5RS7 for ; Wed, 7 Dec 2016 13:41:47 -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 1BFE21295E0 for ; Wed, 7 Dec 2016 13:41:47 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tYsQH6N5HzCZn; Wed, 7 Dec 2016 22:41:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1481146903; bh=TPqUly4GpI6ZWwddcULngUj+/oDBa5vb4+Vb2qIHAys=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XlREzKnCSgf6YhFH/d+fhyMuhEpb2LGuPISdCQCh5Om/0d34U3mSSUBzIm0jkm0Vw rjce4BEpuTS57owf09kIbRab6zBnSvyOwdO0yA/hpw6kuNq2LxIruMlN8mbfgr4JqR VIGZ2tERn5AzT8LlTb6Lkpv/NoNXqT/xvDqHL+Uk= 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 ArBYM25Wl0-s; Wed, 7 Dec 2016 22:41:42 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 7 Dec 2016 22:41:41 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 503FD5C83B; Wed, 7 Dec 2016 16:41:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 503FD5C83B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3BFEA422A3E5; Wed, 7 Dec 2016 16:41:30 -0500 (EST) Date: Wed, 7 Dec 2016 16:41:30 -0500 (EST) From: Paul Wouters To: "Hu, Jun (Nokia - US)" In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> Message-ID: References: <22600.13475.748226.49629@fireball.acr.fi> <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 21:41:50 -0000 On Wed, 7 Dec 2016, Hu, Jun (Nokia - US) wrote: > OSPFv3 authentication (RFC4552) mandate to use manual key, the reason is OSPFv3 uses multicast. > So I could see manual key IPsec could be needed in any multicast applications since group key management is not widely available > For above reason, I think it should be "MAY" instead of "SHOULD NOT" Reading that RFC, it is really cracking on all sides. You even need to use the same SPIs and ENC keys for inbound and outbound SA's. I really don't think this is a very well thought out use case for IPsec. Are people actually deploying this? How long are these static SPIs/keys used for? forever? I don't think we need to take those requirements into consideration. If anything, someone needs to update RFC4552 to allow for a more modern use of IKEv2 and multicast (RFC5374) >> The RFC4301 requires support for manual keys (section 4.5), but I hope >> nobody really uses them. I have hoped that for many years. And like Transport Mode and IPCOMP, these things refuse to die. Anyways, we are not updating 4301, so I think this part is out of scope, but: >> The rfc7321bis provides mandatory to implement >> algorithms for the IKEv2 use, and does not really specifically cover manual keys >> cases, but it does not really say that manual keyed SAs are out of scope either >> (like it does say for IKEv1). I guess 7321 should have had a note about manual keying in it, and it does not. We can surely add a note about manual keying. >> The issue is that some of the conformance logo documents actually do require >> manual keys, and to gain those logos implementors need to add support for >> manual keyed SAs even when nobody is really going to use them (i.e., adding >> support for manual keys for android VPN client seems little stupid). 7321bis should not change the requirement for manual keying. It should only talk about algorithms. >> On the other hand if you use the rfc7321bis requirements for also manual keys, >> there is only one suggested cipher that can be used, namely ENCR_AES_CBC. >> >> None of the counter mode ciphers are safe to use with manual keys, and for >> example RFC4106 (AES-GCM) requires using automated key management. >> The RFC4309 (AES-CCM) says that it "should not be used with statically >> configured keys", and that "MUST use fress keys". RFC7634 >> (Chacha20-poly1305) does not explictly say anything about manual keys, but >> says it gets bitstring called KEYMAT from IKE... >> >> If we assume rfc7431bis can be used with manual keys too, we need to add >> some more text saying these ciphers cannot be used with manual keys. >> Anyways, I think it should be time to mark manual keys as SHOULD NOT. While I agree, I don't think 7321bis should do that. How about a new section between section 2 and 3: Manual Keying Manual Keying should not be used as it is inherently dangerous. Without any keying protocol, it does not offer Perfect Forward Secrecy protection. Deployments tend to never be reconfigured with fresh session keys. It also fails to scale and keeping SPI's unique amongst many servers is impractical. This document was written for deploying ESP/AH using IKE (RFC7298) and assumes that keying happens using IKEv2. If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. [note the first "should not" is in lower case in purpose, so we don't actually need to update 4301] >> Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT >> be used, and mark it as updating RFC4301? >> >> Or should we have separate RFC stating that? draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipcomp :) Seriously though, I don't think writing a document like that will change anything. And at least on Linux, the ip xfrm command allows for manual keying and therefor assist with testing, but the IKE daemons (libreswan, strongswan and openswan) do not support manual keying anymore. Paul From nobody Wed Dec 7 14:01:39 2016 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 6EDC7129597 for ; Wed, 7 Dec 2016 14:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 UXEJUt7GM1uF for ; Wed, 7 Dec 2016 14:01:34 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 70FFC129591 for ; Wed, 7 Dec 2016 14:01:34 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x186so219923852vkd.1 for ; Wed, 07 Dec 2016 14:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EjPpIya8VLtCiu8HVTG+Tzubj5MRSzAOGUFbtNaMaVM=; b=RMWzEiFlt9ihSkT2qYDOpvlo//16Q7B38V4KDh6LOlJRSe3MtJy11YfevjbY2D8r3o Yj3m0B7nQUk+WPWQ4DPlwzA9stMffwUMa1Aq7a2vbCNFS+HeShEl3dJKZJ0KOhTwVGiF D56+H7fEwtgoiF20u9V0P02Z0dXZkok3gwotU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EjPpIya8VLtCiu8HVTG+Tzubj5MRSzAOGUFbtNaMaVM=; b=MvYitIPnYcJT9Q48NiMs+W9OPCxyY6x/meOYxz/3d8WygoLoAIMm1BUp3CeAToKYb+ TzwyRdS9682jqQQBOgc8/ook35QJmwcK9KN4X/SjiESnB9pDoEb6i/SND268+KHjaXlT 8InZ9276SmIGPNphmOIMDix1mEad7IT24vu/u/Wo4+Cl+MfCt0BuF6qAjV3B3yTM2cXQ AHWqrSvHBHCtaGzugI0tDo1N+gmyUjIfrNrdF2+CgkvK9G3RglGennr2OB4clUn7YJ7v bsxJ1Vb9s7/M8ZHPP5hvmb0XOw/lHqAplYx5+wQMcGg4TCh6wOGk2q6EDLTBkQDwPzy6 9RkQ== X-Gm-Message-State: AKaTC00NUuqCGRmTGWOs8BYF6RTiVV6QyThjbA37SWBj0Bup8kbKCG5TS3LRp9xAP79BaCXf/C8laZj8FhP0NfNi X-Received: by 10.31.97.1 with SMTP id v1mr27093286vkb.108.1481148093580; Wed, 07 Dec 2016 14:01:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.7.102 with HTTP; Wed, 7 Dec 2016 14:00:53 -0800 (PST) In-Reply-To: References: <22600.13475.748226.49629@fireball.acr.fi> <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> From: Timothy Carlin Date: Wed, 7 Dec 2016 17:00:53 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a114da510fa893c054318a99f Archived-At: Cc: "ipsec@ietf.org" , "Hu, Jun \(Nokia - US\)" , Tero Kivinen Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 22:01:37 -0000 --001a114da510fa893c054318a99f Content-Type: text/plain; charset=UTF-8 Hello All, I have some comments inline. On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters wrote: > On Wed, 7 Dec 2016, Hu, Jun (Nokia - US) wrote: > > OSPFv3 authentication (RFC4552) mandate to use manual key, the reason is >> OSPFv3 uses multicast. >> So I could see manual key IPsec could be needed in any multicast >> applications since group key management is not widely available >> For above reason, I think it should be "MAY" instead of "SHOULD NOT" >> > > Reading that RFC, it is really cracking on all sides. You even need to > use the same SPIs and ENC keys for inbound and outbound SA's. I really > don't think this is a very well thought out use case for IPsec. > > Are people actually deploying this? > > The NIST USGv6 Profile current mandates RFC4552 and as such manual keys. > How long are these static SPIs/keys used for? forever? > > I don't think we need to take those requirements into consideration. If > anything, someone needs to update RFC4552 to allow for a more modern use > of IKEv2 and multicast (RFC5374) > > The RFC4301 requires support for manual keys (section 4.5), but I hope >>> nobody really uses them. >>> >> > I have hoped that for many years. And like Transport Mode and IPCOMP, > these things refuse to die. Anyways, we are not updating 4301, so I > think this part is out of scope, but: > > The rfc7321bis provides mandatory to implement >>> algorithms for the IKEv2 use, and does not really specifically cover >>> manual keys >>> cases, but it does not really say that manual keyed SAs are out of scope >>> either >>> (like it does say for IKEv1). >>> >> > I guess 7321 should have had a note about manual keying in it, and it > does not. We can surely add a note about manual keying. > > The issue is that some of the conformance logo documents actually do >>> require >>> manual keys, and to gain those logos implementors need to add support for >>> manual keyed SAs even when nobody is really going to use them (i.e., >>> adding >>> support for manual keys for android VPN client seems little stupid). >>> >> > 7321bis should not change the requirement for manual keying. It should > only talk about algorithms. > > On the other hand if you use the rfc7321bis requirements for also manual >>> keys, >>> there is only one suggested cipher that can be used, namely ENCR_AES_CBC. >>> >>> None of the counter mode ciphers are safe to use with manual keys, and >>> for >>> example RFC4106 (AES-GCM) requires using automated key management. >>> The RFC4309 (AES-CCM) says that it "should not be used with statically >>> configured keys", and that "MUST use fress keys". RFC7634 >>> (Chacha20-poly1305) does not explictly say anything about manual keys, >>> but >>> says it gets bitstring called KEYMAT from IKE... >>> >>> If we assume rfc7431bis can be used with manual keys too, we need to add >>> some more text saying these ciphers cannot be used with manual keys. >>> >> > Anyways, I think it should be time to mark manual keys as SHOULD NOT. >>> >> > While I agree, I don't think 7321bis should do that. > > How about a new section between section 2 and 3: > > Manual Keying > > Manual Keying should not be used as it is inherently dangerous. Without > any keying protocol, it does not offer Perfect Forward Secrecy > protection. Deployments tend to never be reconfigured with fresh session > keys. It also fails to scale and keeping SPI's unique amongst many servers > is impractical. This document was written for deploying ESP/AH using IKE > (RFC7298) and assumes that keying happens using IKEv2. > > If manual keying is used anyway, ENCR_AES_CBC MUST be used, and > ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT > be used as these algorithms require IKE. > > [note the first "should not" is in lower case in purpose, so we don't > actually need to update 4301] > > I agree with the sentiment that Manual Keys should be avoided. However for the conformance logo documents it would be helpful to have RFC2119 language to point to when setting the requirements for testing. Tim Carlin UNH-IOL > Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT >>> be used, and mark it as updating RFC4301? >>> >>> Or should we have separate RFC stating that? >>> >> > draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipcomp :) > > Seriously though, I don't think writing a document like that will change > anything. And at least on Linux, the ip xfrm command allows for manual > keying and therefor assist with testing, but the IKE daemons (libreswan, > strongswan and openswan) do not support manual keying anymore. > > Paul > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a114da510fa893c054318a99f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hell= o =C2=A0All,

I have some comments inline.

On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters = <p= aul@nohats.ca> wrote:
On Wed, 7 Dec 2016, Hu, Jun (Nokia - US) wrote:

OSPFv3 authentication (RFC4552) mandate to use manual key, the reason is OS= PFv3 uses multicast.
So I could see manual key IPsec could be needed in any multicast applicatio= ns since group key management is not widely available
For above reason, I think it should be "MAY" instead of "SHO= ULD NOT"

Reading that RFC, it is really cracking on all sides. You even need to
use the same SPIs and ENC keys for inbound and outbound SA's. I really<= br> don't think this is a very well thought out use case for IPsec.

Are people actually deploying this?


The NIST USGv6 Profile current mandate= s RFC4552 and as such manual keys.
=C2=A0
How long are these static SPIs/keys used for? forever?

I don't think we need to take those requirements into consideration. If=
anything, someone needs to update RFC4552 to allow for a more modern use of IKEv2 and multicast (RFC5374)

The RFC4301 requires support for manual keys (section 4.5), but I hope
nobody really uses them.

 I have hoped that for many years. And like Transport Mode and IPCOMP,
these things refuse to die. Anyways, we are not updating 4301, so I
think this part is out of scope, but:

The rfc7321bis provides mandatory to implement
algorithms for the IKEv2 use, and does not really specifically cover manual= keys
cases, but it does not really say that manual keyed SAs are out of scope ei= ther
(like it does say for IKEv1).

 I guess 7321 should have had a note about manual keying in it, and it
does not. We can surely add a note about manual keying.
The issue is that some of the conformance logo documents actually do requir= e
manual keys, and to gain those logos implementors need to add support for manual keyed SAs even when nobody is really going to use them (i.e., adding=
support for manual keys for android VPN client seems little stupid).

 7321bis should not change the requirement for manual keying. It should
only talk about algorithms.

On the other hand if you use the rfc7321bis requirements for also manual ke= ys,
there is only one suggested cipher that can be used, namely ENCR_AES_CBC.
None of the counter mode ciphers are safe to use with manual keys, and for<= br> example RFC4106 (AES-GCM) requires using automated key management.
The RFC4309 (AES-CCM) says that it "should not be used with statically=
configured keys", and that "MUST use fress keys". RFC7634 (Chacha20-poly1305) does not explictly say anything about manual keys, but<= br> says it gets bitstring called KEYMAT from IKE...

If we assume rfc7431bis can be used with manual keys too, we need to add some more text saying these ciphers cannot be used with manual keys.

Anyways, I think it should be time to mark manual keys as SHOULD NOT.

 While I agree, I don't think 7321bis should do that.

How about a new section between section 2 and 3:

Manual Keying

Manual Keying should not be used as it is inherently dangerous. Without
any keying protocol, it does not offer Perfect Forward Secrecy
protection. Deployments tend to never be reconfigured with fresh session keys. It also fails to scale and keeping SPI's unique amongst many serv= ers
is impractical. This document was written for deploying ESP/AH using IKE (RFC7298) and assumes that keying happens using IKEv2.

If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT
be used as these algorithms require IKE.

[note the first "should not" is in lower case in purpose, so we d= on't
=C2=A0actually need to update 4301]


I agree with the sentiment that= Manual Keys should be avoided.=C2=A0 However for the conformance logo docu= ments it would be helpful to have RFC2119 language to point to when setting= the requirements for testing.

Tim Carlin
UNH-IOL
=C2=A0
Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT be used, and mark it as updating RFC4301?

Or should we have separate RFC stating that?

 draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipco= mp :)

Seriously though, I don't think writing a document like that will chang= e
anything. And at least on Linux, the ip xfrm command allows for manual
keying and therefor assist with testing, but the IKE daemons (libreswan, strongswan and openswan) do not support manual keying anymore.

Paul


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--001a114da510fa893c054318a99f-- From nobody Wed Dec 7 14:11:57 2016 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 AA57B129571 for ; Wed, 7 Dec 2016 14:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNMBVUMIrjZG for ; Wed, 7 Dec 2016 14:11:54 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 0478312952C for ; Wed, 7 Dec 2016 14:11:54 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 44EE4ED22D689; Wed, 7 Dec 2016 22:11:50 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id uB7MBpU5032602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Dec 2016 22:11:52 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id uB7MBpKk014414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Dec 2016 22:11:51 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Wed, 7 Dec 2016 17:11:51 -0500 From: "Hu, Jun (Nokia - US)" To: Paul Wouters Thread-Topic: [IPsec] RFC4301, rfc7321bis and Manual keys Thread-Index: AQHSUKSyQMlVi5R0E0ivHul/4ll1eqD82+uAgAB79AD//7D3gA== Date: Wed, 7 Dec 2016 22:11:51 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB51221@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <22600.13475.748226.49629@fireball.acr.fi> <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 22:11:56 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Wednesday, December 07, 2016 1:42 PM > To: Hu, Jun (Nokia - US) > Cc: Tero Kivinen ; ipsec@ietf.org > Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys >=20 > On Wed, 7 Dec 2016, Hu, Jun (Nokia - US) wrote: >=20 > > OSPFv3 authentication (RFC4552) mandate to use manual key, the reason i= s > OSPFv3 uses multicast. > > So I could see manual key IPsec could be needed in any multicast > > applications since group key management is not widely available For abo= ve > reason, I think it should be "MAY" instead of "SHOULD NOT" >=20 > Reading that RFC, it is really cracking on all sides. You even need to us= e the > same SPIs and ENC keys for inbound and outbound SA's. I really don't thin= k this > is a very well thought out use case for IPsec. >=20 > Are people actually deploying this? >=20 > How long are these static SPIs/keys used for? forever? >=20 > I don't think we need to take those requirements into consideration. If a= nything, > someone needs to update RFC4552 to allow for a more modern use of IKEv2 > and multicast (RFC5374) >=20 [HJ] OSPFv3 has been implemented on almost all IPv6 capable enterprise/carr= ier level routers for long time, and as only standard auth method, RFC4552= was also implemented along with OSPFv3; So I think I could say RFC4552 has been already deployed widely for long ti= me, We can't ignore this just because manual key is less secure; in fact using = IKEv2 and RFC5374 is almost impractical for a IGP routing protocol, because= when deployed, OSPFv3 is an part of network routing infrastructure; adding= IKEv2 and RFC5374 not only add lots additional complexity to the routing p= lane (it gona be a non-starter already for many people), but also using RFC= 5374 require to use a central key server, it means the key server need to b= e reachable before OSPFv3 is up and running, which might not be feasible;=20 From nobody Wed Dec 7 14:40:06 2016 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 06E43129C49 for ; Wed, 7 Dec 2016 14:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 hyXOmRxb5_lB for ; Wed, 7 Dec 2016 14:40:03 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 1B846129B3D for ; Wed, 7 Dec 2016 14:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481150403; 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=u6Ox2jU3tKG54dU5Z01V+q3v8+f5N4nScw31U+pm8kg=; b=CerrXSyEvSdUKfJGh2kx+Dp4Z71AbBDhXCTl39FPFp2xvCkf8oJM9L+liY9KATrm hqQCNeC1ogTFFfUVmBMGpnWQdENDj+8qIVPD2YBQj9f3gWlattoqP92lvjKis299 p5h6p4ENYfAKxj9uJLd8iiKRxuhltnpLCchC6d7Hrdu944HO9ucIdas9nDwBgCF1 TSCbrh9anKYCCglANm6/FWuxrJXhdTiWd+zzMlUsBpjR1WDt+u+ohwCevZCpUByB aiPeqdzVdOrTGUeCjQJ2RjfFbyEU2JhSDE3DZctJxnkgqN874yRXuiuZ6qhaVfAS ELIiwFIVnY5cBKsgUMjHHw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 5F.12.22504.2CF88485; Wed, 7 Dec 2016 14:40:02 -0800 (PST) X-AuditID: 11973e13-89bff700000057e8-96-58488fc24c1a Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id B3.26.09148.2CF88485; Wed, 7 Dec 2016 14:40:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from da0602a-dhcp105.apple.com (da0602a-dhcp105.apple.com [17.226.23.105]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHU001ZP6XZS580@nwk-mmpp-sz12.apple.com>; Wed, 07 Dec 2016 14:40:02 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <876523B00C3F9D47BFD2B654D63DBF92BEB50E34@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Wed, 07 Dec 2016 14:40:02 -0800 Message-id: References: <148089265595.5531.2220473726694989505.idtracker@ietfa.amsl.com> <3E7ABAD5-8657-49E9-9648-0B23DAA927FA@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB50E34@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Hu, Jun (Nokia - US)" X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FDorHuo3yPC4Ea/jcX+LS/YLD78ncDo wOSxZMlPJo+7ty4xBTBFcdmkpOZklqUW6dslcGVM3/GdseCzfMWxzdOYGxj7JLsYOTkkBEwk 9nSfZu9i5OIQEtjLKDG95wkTTGLdok5WEFtI4BCjxPc/YiA2r4CgxI/J91i6GDk4mAXkJQ6e lwUJMwtoSXx/1MoCMWcZk8SJc9+ZQGqEBSQkNu9JBKkRFrCUaHk6gwXEZhNQkTj+bQMziM0p EC9x5uZmdhCbRUBV4nbbA3aImfISvf83MkKstZHovL0J6pxLjBJ9Z6RBbBEBXYnvp1+yQZws K7Hy6UZWCHsLm8T+QzYTGIVnIbl6FsLVs5BcvYCReRWjUG5iZo5uZp6pXmJBQU6qXnJ+7iZG UFBPtxPewXh6ldUhRgEORiUeXgd5jwgh1sSy4srcQ4zSHCxK4rxHLYFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGHd8a8rLbY0pj357vl/yqkf/AjGGBQqHwm7n3Qz+EpCUF1wZELpu79cN X5VUJHfLF74zapHz4shL52O68+z9z887j1dmrH7f/ujgjt2sCuZBR2ffDfu/OeFu8fRPIdyP qoNqXwZ+NbDfkTNb2/fNxpvLlzEK3nbf2FL/4X3SzsPb0jWzelr0ryixFGckGmoxFxUnAgC4 piAuSwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42IRbCg+o3uo3yPC4P5BLYv9W16wWXz4O4HR gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4MqYvuM7Y8Fn+Ypjm6cxNzD2SXYxcnJICJhI rFvUyQphi0lcuLeeDcQWEjjEKPH9jxiIzSsgKPFj8j2WLkYODmYBeYmD52VBwswCWhLfH7UC hbmAypcxSZw4950JpEZYQEJi855EkBphAUuJlqczWEBsNgEViePfNjCD2JwC8RJnbm5mB7FZ BFQlbrc9YIeYKS/R+38jI8RaG4nO25tYIc65xCjRd0YaxBYR0JX4fvolG8TJshIrn25kncAo OAvJpbMQLp2F5NIFjMyrGAWKUnMSK430EgsKclL1kvNzNzGCw7PQeQfjsWVWhxgFOBiVeHgd 5D0ihFgTy4orc4EhwcGsJMLr2gcU4k1JrKxKLcqPLyrNSS0+xJgMdP9EZinR5Hxg7OSVxBua mBiYGBubGRubm5iTJqwkzhvF6hQhJJCeWJKanZpakFoEs4WJg1OqgfH0xZ7iP6xix5+K1K/0 fXdAkEc0hv/Ewks8busbb3VbxrZflamaX7HX7on68qbAfvl4JZs/s19Ocdq/cuPV94Lzb3NX abEalE6sP3Dk+tr9nx+8ND672Ufb5e6r/StExA9+2FU6cZFQtlMuX/5rp6tSqcU27pMZrNZX ts6axCPD++RIdNDc3EIlluKMREMt5qLiRACNIpyZkwIAAA== Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 22:40:05 -0000 Thanks for confirming! I appreciate all of your help in cleaning this part up! Tommy > On Dec 7, 2016, at 11:52 AM, Hu, Jun (Nokia - US) wrote: > > Looks good to me > >> -----Original Message----- >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly >> Sent: Sunday, December 04, 2016 3:07 PM >> To: IPsecME WG >> Subject: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt >> >> Hello all, >> >> I've updated the TCP Encapsulation draft with new recommendations around >> handling the mapping between IKE SAs and TCP Connections based on the >> conversation at the Seoul meeting. The relevant new text in section 6 is: >> >> >> An initiator SHOULD only open one TCP connection per IKE SA, over >> which it sends all of the corresponding IKE and ESP messages. This >> helps ensure that any firewall or NAT mappings allocated for the TCP >> connection apply to all of the traffic associated with the IKE SA >> equally. >> >> A responder SHOULD at any given time send packets for an IKE SA and >> its Child SAs over only one TCP connection. It should choose the TCP >> connection on which it last received a valid and decryptable IKE or >> ESP message. Since a connection may be broken and a new connection >> re-established by the initiator without the responder being aware, a >> responder SHOULD accept receiving IKE and ESP messages on a new >> connection. It will then use that connection for all subsequent >> responses. A responder MAY close a TCP connection that it perceives >> as idle and extraneous (one previously used for IKE and ESP messages >> that has been replaced by a new connection). >> >> Multiple IKE SAs SHOULD NOT share a single TCP connection. >> >> Please respond to indicate your thoughts on this! >> >> Thanks, >> Tommy >> >> >>> On Dec 4, 2016, at 3:04 PM, internet-drafts@ietf.org wrote: >>> >>> >>> 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 of the >> IETF. >>> >>> Title : TCP Encapsulation of IKE and IPsec Packets >>> Authors : Tommy Pauly >>> Samy Touati >>> Ravi Mantha >>> Filename : draft-ietf-ipsecme-tcp-encaps-04.txt >>> Pages : 21 >>> Date : 2016-12-04 >>> >>> Abstract: >>> This document describes a method to transport IKE and IPsec packets >>> over a TCP connection for traversing network middleboxes that may >>> block IKE negotiation over UDP. This method, referred to as TCP >>> encapsulation, involves sending both IKE packets for tunnel >>> establishment as well as tunneled packets using ESP over a TCP >>> connection. This method is intended to be used as a fallback option >>> when IKE cannot be negotiated over UDP. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04 >>> >>> >>> 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 >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 7 15:43:56 2016 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 7A0A01295D2 for ; Wed, 7 Dec 2016 15:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 8BeQuMHw2huj for ; Wed, 7 Dec 2016 15:43:53 -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 E7D771295BE for ; Wed, 7 Dec 2016 15:43:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 250D5E00B; Wed, 7 Dec 2016 19:01:20 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E44DA63768; Wed, 7 Dec 2016 18:43:51 -0500 (EST) From: Michael Richardson To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 23:43:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scott Fluhrer (sfluhrer) wrote: > o There is the option listed in the draft, where we modify both the > KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies I read through the three options, and I have difficulty picking. ... > o Valery Smyslov gave a suggestion that we instead stir in the PPK > into the initial SK_d; as all keying material is generated based on > that, this would also mean that IPsec SAs and any child IKE SAs are > also protected. This also means that an implementation would not need > to remember the PPK after the initial negotiation. The only downside I > can see is that we would have to be a bit careful about when we update > the SK_d (obviously, before we actually use it). If we can make this work, it seems like the best, as it means we can forget more things sooner. > o Would this idea of pseudonyms actually give any real identity > protection? Wouldn=E2=80=99t that assume that several initiators use = the same > PPK (so they could use the same pseudonym)? Is that the sort of thing > we should be encouraging? I need to think about this. It only matters to "road warriors", i.e. remote access situations where the end user can move around. This includes many more site to site VPNs these days due to CGN and just poor network architecture, such as the Cloud operators' baked in NAT44. I'm concerned that we would wind up with a new Group PSK like we had with I= KEv1. > o Would we be happy with always negotiating a child SA (as none of the > three proposals for stirring in the PPK attempt to protect the initial > IKE SA)? I wonder if this might be simpler and more reliable to just always do it, a= nd specify it up front. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhInqkACgkQgItw+93Q 3WX5KQgAvvuq4zbTJfGnAioxbpfq3dGwWDtLGU6POqUXcQLMHaskXqpFRapKipdg rKMWRwtsdg1r6VtJlnom7QBMH96+SRE8038eY+IIHx9iLharq2onpAPHvEZPJ8V+ v7YiApvsW6AG0Crgnunvff3eQI/dgJhX1lLljWnxVyX46dY3VbY4+DNT6ddJYyzo UmIis8OChkYYz3OPnJZD6CdJwNIzRiKzmcUdZelGkgM1tUBihmzG3i1Ptx5uQRHC LM/U2CbftMSK7R2oDuVF2uWMis87r5DAweHy4XrOiuGulO4MlYwbl82S8pOgihKA xd4x6kJCpVFQTUqcaJWPhuylyKi39A== =CQK0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 7 17:34:37 2016 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 A6DAC12960F for ; Wed, 7 Dec 2016 17:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=Paul.Koning@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.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 c6Z1GOr_YFVw for ; Wed, 7 Dec 2016 17:34:33 -0800 (PST) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 CB610129601 for ; Wed, 7 Dec 2016 17:34:33 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:X-LoopCount0:X-IronPort-AV:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=ha7JdlfcR8USVP747NDivORCx4Ob4OJp7kYx3aX7JxLazQSAw51+PIyY 9vk2T7crjgskgJHwmZmuF0u6LknPM+SsDPYQF4YRgNZN8qsnEWJhal6+1 wz07Q8LRzrepXwQF200TVNprGcrzq3F6FzH1oH8bYuhuVV2mhqXttYDaI k=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1481160873; x=1512696873; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6/HxTjwqKcDpH9nxUZ1xAV2I0FpMDHXu0Fa03O91Rms=; b=jc9gFpOLYrsI3ixQlFR475f/otkS9/zkRiCDeCq6RhJr3Ar5UMqfIYSK 6dmxLzXlUH/QMvIracCi1kLw/ACmu6NWaxRMkpUSquatbo2smJ+H0Qttb q/GEsZ5XHnRMARz3jCk5RX02o0obF0e86qhF4DeE/QhGdvfHQcTIdpIdJ Q=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 19:34:33 -0600 From: Received: from ausxipps306.us.dell.com ([143.166.148.156]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2016 07:34:33 +0600 X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos; i="5.33,316,1477976400"; d="scan'208,217"; a="44150572" To: Thread-Topic: [IPsec] RFC4301, rfc7321bis and Manual keys Thread-Index: AQHSUKTA4UnFqHDH1kqsFlwd3r3jaqD9RGmAgAAkOQCAAAVrgIAAO68A Date: Thu, 8 Dec 2016 01:34:31 +0000 Message-ID: References: <22600.13475.748226.49629@fireball.acr.fi> <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.178.128.194] Content-Type: multipart/alternative; boundary="_000_A88D695BBD66477598966150CE88835Bdellcom_" MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, jun.hu@nokia.com, paul@nohats.ca, kivinen@iki.fi Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 01:34:36 -0000 --_000_A88D695BBD66477598966150CE88835Bdellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 7, 2016, at 5:00 PM, Timothy Carlin > wrote: Hello All, I have some comments inline. On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters > wrote: ... Are people actually deploying this? The NIST USGv6 Profile current mandates RFC4552 and as such manual keys. Yes, that's PRECISELY the issue. Presumably NIST put it into the profile b= ecause manual keys are mentioned in the RFC, not realizing how bad an error= that is. ... I agree with the sentiment that Manual Keys should be avoided. However for= the conformance logo documents it would be helpful to have RFC2119 languag= e to point to when setting the requirements for testing. That is the main reason I argued for MUST NOT. By way of illustration: in an IPSec-enabled product I work on, we implement= ed manual keying only to be able to pass the USGv6 tests. The manual state= s that the feature [sic] exists only for that reason and that manual keys s= hould never be used. When we submitted the product for Common Criteria eva= luation, the evaluators told us we needed to strengthen that statement, so = it now says that manual keys "exist only because of certification requireme= nts and must never be used". This is clearly absurd. A feature in a security protocol that has always = been known to be a hazard to security needs to be removed. It's been far t= oo long already. paul --_000_A88D695BBD66477598966150CE88835Bdellcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <507AD5E3D9889A4E841BE82E32298AC9@dell.com> Content-Transfer-Encoding: quoted-printable
On Dec 7, 2016, at 5:00 PM, Timothy Carlin <tjcarlin@iol.unh.edu> wrote:<= /div>
Hello  All,

I have some comments inline.

On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters <paul@no= hats.ca> wr= ote:
...

Are people actually deploying this?


The NIST USGv6 Profile current mandates RFC4552 and as such= manual keys.

Yes, that's PRECISELY the issue.  Presumably NIST put it into the prof= ile because manual keys are mentioned in the RFC, not realizing how bad an = error that is.


...

I agree with the sentiment that Manual Keys should be avoid= ed.  However for the conformance logo documents it would be helpful to= have RFC2119 language to point to when setting the requirements for testin= g.

That is the main reason I argued for MUST NOT.

By way of illustration: in an IPSec-enabled product I work on, we impl= emented manual keying only to be able to pass the USGv6 tests.  The ma= nual states that the feature [sic] exists only for that reason and that man= ual keys should never be used.  When we submitted the product for Common Criteria evaluation, the evaluators to= ld us we needed to strengthen that statement, so it now says that manual ke= ys "exist only because of certification requirements and must never be= used".

This is clearly absurd.  A feature in a security protocol that ha= s always  been known to be a hazard to security needs to be removed. &= nbsp;It's been far too long already.

paul


--_000_A88D695BBD66477598966150CE88835Bdellcom_-- From nobody Wed Dec 7 18:45:47 2016 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 3841712960F for ; Wed, 7 Dec 2016 18:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 PUu9PfQADhjs for ; Wed, 7 Dec 2016 18:45:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444021295F3 for ; Wed, 7 Dec 2016 18:45:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C5818203AE for ; Wed, 7 Dec 2016 22:03:11 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3446D63768 for ; Wed, 7 Dec 2016 21:45:43 -0500 (EST) From: Michael Richardson To: IETF IPsec In-Reply-To: References: <22600.13475.748226.49629@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+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] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 02:45:46 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > I can see that manual keys are helpful for debugging, but otherwise I > think they SHOULD NOT be used. Exactly. I would like to have a SHOULD provide an interface (without which, I can't determine why I can't interoperate with product FOO), but I agree with Tero, I really don't want logos/etc. to be dependant on it. >> Perhaps we should add note to the rfc7431bis that manual keys SHOULD >> NOT be used, and mark it as updating RFC4301? Yes. >> Or should we have separate RFC stating that? >> >> I do not want to change it to MUST NOT as that would require people to >> remove parts of their implementations to stay complient, but on the >> other hand I do not want people to wasting their time to implenting >> interface to configure manual keys when nobody is going to use them. I would like people to document an interface, but I have no desire to expose it to users. In your Android example, I'm perfectly happy with having a shell and a netlink/pfkey socket as the "interface". -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhIyVYACgkQgItw+93Q 3WU41gf+NomDAHLUuCHPeVd7ritQbhiPHJnQbgcGEzjJpJuwQU5iQ0Pl3JCyhag6 q1rNNEoRW+WBlyXowzNQAseoGPkdwvo+fRm+KrpnlzHNlQ69ftq8UuuZo9aVCeeA v9li2066e61xVPpf7/9v7UHNS4bTgFhD9cEjpJlk6siSvjQ+0cLqeojZh2svsAep XG9k6H6V8NDMOv0PBEUUFlNuODCENcD+96BjHS9dJXyMmS/zVfw9QZ/WQECy/fWj 2Hvuho2r57vbxZwGPvV9mGWZrb1SGvS4XuUbrzNAJUQvVAWAlMP0BrM7pM79TV/U 9fXFr44cGHU0JTC+VN13T//ycU5fJw== =Ewwz -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 7 22:48:38 2016 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 E58DA12967B for ; Wed, 7 Dec 2016 22:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GAMMT0h4TVs8 for ; Wed, 7 Dec 2016 22:48:35 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 03540129674 for ; Wed, 7 Dec 2016 22:48:35 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id t79so10178327wmt.0 for ; Wed, 07 Dec 2016 22:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=h4+F+Uy2edLQgNmzWZtU6O7Q/1St6hdb0pXe9IynZCY=; b=McWtkkb2cz7QkKWs53lLVC8EQ5ImpV9P91u5kbN8j8Hk8ReHimylZzD+lt3OtPSCQH p80AiEVElDhrtZGi5Qo1F2KmT+fFKsZw6f+08VdmsvUcNFG561+UCbVq0I7Rjr3+nw8R svBcf+yaJM1AC0IwDYE1Z33mORM1JDZmUWDZA5tK7PyX8zj/cNLty/osLNv1mrTikR5j rDHw73NOk2qzRKbaIq0qq/w2DtUpDc4QXdLpsg8fqJBExPdW2mDbbRH4Mg2Gf9LqeBkf lgPWQilpthvwy12yN0UhupHXuGnTQGvEdbFKLhd4sW+Ir6ZebgLCcwHCfbUZqU5ve9jt /T8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=h4+F+Uy2edLQgNmzWZtU6O7Q/1St6hdb0pXe9IynZCY=; b=dfii6orr1mKZhqYg0HL+7F3fQvkCIhlA64zQa6/ETuU+Dn2w1KujXHDr6lngqviK/C /2EjiM5QOEDsbE/c5WboGwexhP7cnxVAnupUCnea9NsE1GgGr9rfrhVUDSJk2iMW69Le CxTopXiLBnuyfDkc5a/h9Mxz+bBo8oRoTnZPukN2o2tFoUciNLDUgoOesC4zXVgcJuw2 ChgFA+n94Ui8S+BRB9bEaiFc851fO/jti00vKt5cTLjezG4qut6r4f7sWcKc5R/hU2e5 2iJnSiNZ1cJdYxp6gkVIYT9t/AxFAwgOnzqSzYNItEwglobLW3joq9KCskdUzQuN1Opt CfUA== X-Gm-Message-State: AKaTC02NZ41nnHUS72Tae2Ns0jZrt1v76Y9ki2A7oToZDrjkZ1xW6ToRgDlIu/YVgw8UgQ== X-Received: by 10.28.208.203 with SMTP id h194mr591487wmg.45.1481179713516; Wed, 07 Dec 2016 22:48:33 -0800 (PST) Received: from macbook-pro-2.mshome.net ([176.13.8.26]) by smtp.gmail.com with ESMTPSA id b15sm13555822wma.5.2016.12.07.22.48.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2016 22:48:32 -0800 (PST) From: Yoav Nir Message-Id: <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28206BC4-F6D1-41D7-8AA7-8CF5FA4441C3" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 8 Dec 2016 08:48:24 +0200 In-Reply-To: <8843.1481154231@obiwan.sandelman.ca> To: Michael Richardson References: <8843.1481154231@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 06:48:37 -0000 --Apple-Mail=_28206BC4-F6D1-41D7-8AA7-8CF5FA4441C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Dec 2016, at 1:43, Michael Richardson = wrote: >=20 >=20 > Scott Fluhrer (sfluhrer) wrote: >> o There is the option listed in the draft, where we modify both the >> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies >=20 > I read through the three options, and I have difficulty picking. Me too. I=E2=80=99m not too worried about information in the IKE SA, so = I wouldn=E2=80=99t disqualify Dan=E2=80=99t on that basis. >> o Valery Smyslov gave a suggestion that we instead stir in the PPK >> into the initial SK_d; as all keying material is generated based on >> that, this would also mean that IPsec SAs and any child IKE SAs are >> also protected. This also means that an implementation would not need >> to remember the PPK after the initial negotiation. The only downside = I >> can see is that we would have to be a bit careful about when we = update >> the SK_d (obviously, before we actually use it). >=20 > If we can make this work, it seems like the best, as it means we can = forget > more things sooner. I=E2=80=99m guessing this would be something along these lines: OLD: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) NEW: {SK_proto_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )n SK_d =3D prf(PPK, SK_proto_d} So assuming this works and is secure, it seems like an easy change. >> o Would this idea of pseudonyms actually give any real identity >> protection? Wouldn=E2=80=99t that assume that several initiators use = the same >> PPK (so they could use the same pseudonym)? Is that the sort of thing >> we should be encouraging? >=20 > I need to think about this. >=20 > It only matters to "road warriors", i.e. remote access situations = where the > end user can move around. This includes many more site to site VPNs = these > days due to CGN and just poor network architecture, such as the Cloud > operators' baked in NAT44. >=20 > I'm concerned that we would wind up with a new Group PSK like we had = with IKEv1. Pseudonyms are not too difficult on the protocol level, but managing = them makes products and configuration very difficult. So you=E2=80=99re = giving groups of people the same pseudonym and the same PPK? How do you = group people together? With non-careful grouping of users you can make = it worse than exposing real names (not =E2=80=9Cynir=E2=80=9D, but = =E2=80=9CRND_ACCESS_GROUP=E2=80=9D, which is more useful to an = attacker). And that is the kind of exposure that we can=E2=80=99t fix in = protocol - we=E2=80=99re trusting administrators to balance convenience, = privacy and corporate information security. I think they=E2=80=99ll all = choose a single PPK and single pseudonym for everybody. >> o Would we be happy with always negotiating a child SA (as none of = the >> three proposals for stirring in the PPK attempt to protect the = initial >> IKE SA)? >=20 > I wonder if this might be simpler and more reliable to just always do = it, and > specify it up front. Simple, yes. Reliable, yes. Necessary? IDK Yoav --Apple-Mail=_28206BC4-F6D1-41D7-8AA7-8CF5FA4441C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Dec 2016, at 1:43, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:
o There is the = option listed in the draft, where we modify both the
KEYMAT = and SKEYSEED computations; stirring it into the KEYMAT implies

I read through the three options, = and I have difficulty picking.

Me too. = I=E2=80=99m not too worried about information in the IKE SA, so I = wouldn=E2=80=99t disqualify Dan=E2=80=99t on that basis.

o Valery Smyslov gave a = suggestion that we instead stir in the PPK
into the = initial SK_d; as all keying material is generated based on
that, this would also mean that IPsec SAs and any child IKE = SAs are
also protected. This also means that an = implementation would not need
to remember the PPK after = the initial negotiation. The only downside I
can see is = that we would have to be a bit careful about when we update
the SK_d (obviously, before we actually use it).

If we can make this work, it = seems like the best, as it means we can forget
more things = sooner.

I=E2=80=99m guessing this would be something along = these lines:

OLD:
   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | =
SK_pi | SK_pr }
                   =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr =
)

NEW:
   {SK_proto_d | SK_ai | SK_ar | SK_ei | SK_er =
| SK_pi | SK_pr }
                   =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr =
)n

 =
  SK_d =3D prf(PPK, SK_proto_d}

So assuming this works and is secure, = it seems like an easy change.

o Would this idea of = pseudonyms actually give any real identity
protection? = Wouldn=E2=80=99t that assume that several initiators use the same
PPK (so they could use the same pseudonym)? Is that the sort = of thing
we should be encouraging?

I need to think about this.

It only matters to "road warriors", i.e. = remote access situations where the
end user can move = around.  This includes many more site to site VPNs these
days due to CGN and just poor network architecture, such as = the Cloud
operators' baked in NAT44.

I'm concerned that we would wind up with a new Group PSK like = we had with IKEv1.

Pseudonyms are not too difficult on the protocol = level, but managing them makes products and configuration very = difficult. So you=E2=80=99re giving groups of people the same pseudonym = and the same PPK? How do you group people together? With non-careful = grouping of users you can make it worse than exposing real names (not = =E2=80=9Cynir=E2=80=9D, but =E2=80=9CRND_ACCESS_GROUP=E2=80=9D, which is = more useful to an attacker). And that is the kind of exposure that we = can=E2=80=99t fix in protocol - we=E2=80=99re trusting administrators to = balance convenience, privacy and corporate information security. I think = they=E2=80=99ll all choose a single PPK and single pseudonym for = everybody.

o Would = we be happy with always negotiating a child SA (as none of the
three proposals for stirring in the PPK attempt to protect = the initial
IKE SA)?

I wonder if this might be simpler and more reliable to just = always do it, and
specify it up front.

Simple, yes. Reliable, yes. Necessary? IDK

Yoav

= --Apple-Mail=_28206BC4-F6D1-41D7-8AA7-8CF5FA4441C3-- From nobody Thu Dec 8 00:29:39 2016 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 E383D129CB8 for ; Thu, 8 Dec 2016 00:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.595, 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 9qKV1D8zqlJg for ; Thu, 8 Dec 2016 00:29:35 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5C01C129CB0 for ; Thu, 8 Dec 2016 00:29:35 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id t79so13628158wmt.0 for ; Thu, 08 Dec 2016 00:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=K5/9lNXhC3+lAOUpgvSy34Lre8CirAZXzTUqSt6Ge/E=; b=UiqdRNY6EGzV9vKrzIZJaxGKEqqtMg85nb7JJX0JgN4YIdopBUgtwRn71n5r3je61r UTPzZnivxmhlY732RyWxeYpD7qSVmf4LksEAFVgiR4g+f9NWUJDr6Y7tAG72DoQ1V5n/ MdXHWYrMgAnVSk2x+N+D4PcXPGIhnn/PhwDbeu4eduHPNS3gC2KzHdR/PBRde704PkWn ei203ABvAYZ8eODvZau3gIWT8bxtqxpxaGcnCCSDgHaLKvxtUD8h9kclGCaR+02eT8Yf Pm+e5FLZLB1HRkif/0OfXtCeOxWlExFIxMjZu0zRecVH/Oyzg8t01z05zmWzQiV55Qbx nEXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=K5/9lNXhC3+lAOUpgvSy34Lre8CirAZXzTUqSt6Ge/E=; b=TgIz97WZz797ZX5Pl/NOSgvARiWZksp9FFi4aWSPItNRIPP9up/hUnaSfNvEllgNdF 4Hr6Cevwks3COjMVWfhBlPoEOPvsuD+eB+zO8qSOQHXr/3uXXucFBvi8sFSDkQQDW4B2 qqBB1ZXA29jocf1WNUtktEoUGAXTTg1Xr1oMFqJ155VSO8JrGUp6DnqKvk0FBbu3urrv RO+kdBI/Wg5zSIhcV3LzxQ/ptoKbpauDBDt3Y4GVzFpVkK5u1UUGOpWgiAwiA9QZ9NwB hblXujd/NJqbyByzI7GLk5TyBU8YcPJnWk5MMbvByvL6H3si96GYawUKBUWwAUcUdysM rzrA== X-Gm-Message-State: AKaTC00rHO1fIpRpGzxNaurYNjjqjmEp9nZUuqESg0fWFoihow8es4O/xf6AIyhaSPRIlA== X-Received: by 10.46.0.137 with SMTP id e9mr30619934lji.11.1481185773650; Thu, 08 Dec 2016 00:29:33 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 23sm5495694ljf.48.2016.12.08.00.29.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 00:29:32 -0800 (PST) From: "Valery Smyslov" To: "'Yoav Nir'" , "'Michael Richardson'" References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> In-Reply-To: <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> Date: Thu, 8 Dec 2016 11:29:26 +0300 Message-ID: <008901d2512d$305b6580$91123080$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01D25146.55AD5870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGf0y3ElAb1MY6fIaqsOC5fSHHzigJCwQTLAXo2HB2hRL/lQA== Content-Language: ru Archived-At: Cc: 'IPsecme WG' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 08:29:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01D25146.55AD5870 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 o Valery Smyslov gave a suggestion that we instead stir in the PPK into the initial SK_d; as all keying material is generated based on that, this would also mean that IPsec SAs and any child IKE SAs are also protected. This also means that an implementation would not need to remember the PPK after the initial negotiation. The only downside I can see is that we would have to be a bit careful about when we update the SK_d (obviously, before we actually use it). If we can make this work, it seems like the best, as it means we can = forget more things sooner. =20 I=E2=80=99m guessing this would be something along these lines: =20 OLD: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) =20 NEW: {SK_proto_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )n SK_d =3D prf(PPK, SK_proto_d} =20 =20 I also thought of something like this. =20 =20 So assuming this works and is secure, it seems like an easy change. =20 =20 Yes, and the simplicity was the main reason I suggested this variant. It allows to have the only place in the code where you have to change key derivation logic and to deal with PPK. Obviously, I vote for it. o Would this idea of pseudonyms actually give any real identity protection? Wouldn=E2=80=99t that assume that several initiators use the = same PPK (so they could use the same pseudonym)? Is that the sort of thing we should be encouraging? I need to think about this. It only matters to "road warriors", i.e. remote access situations where = the end user can move around. This includes many more site to site VPNs = these days due to CGN and just poor network architecture, such as the Cloud operators' baked in NAT44. I'm concerned that we would wind up with a new Group PSK like we had = with IKEv1. =20 Pseudonyms are not too difficult on the protocol level, but managing = them makes products and configuration very difficult. So you=E2=80=99re = giving groups of people the same pseudonym and the same PPK? How do you = group people together? With non-careful grouping of users you can make = it worse than exposing real names (not =E2=80=9Cynir=E2=80=9D, but = =E2=80=9CRND_ACCESS_GROUP=E2=80=9D, which is more useful to an = attacker). And that is the kind of exposure that we can=E2=80=99t fix in = protocol - we=E2=80=99re trusting administrators to balance convenience, = privacy and corporate information security. I think they=E2=80=99ll all = choose a single PPK and single pseudonym for everybody. o Would we be happy with always negotiating a child SA (as none of the three proposals for stirring in the PPK attempt to protect the initial IKE SA)? I wonder if this might be simpler and more reliable to just always do = it, and specify it up front. =20 Simple, yes. Reliable, yes. Necessary? IDK =20 =20 I fail to understand how mandating to always negotiate Child SA helps = protect anonymity. The only place where IKEv2 peers exchange identities is currently = IKE_AUTH exchange. The current draft suggests that in case of PPK the peers should = immediately initiate=20 CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But = CREATE_CHILD_SA doesn=E2=80=99t allow to exchange identities. So, if pseudonyms were = used in IKE_AUTH, how are you going to exchange real identities? Even if we modify = CREATE_CHILD_SA to optionally include IDi & IDr, this won=E2=80=99t be enough, because = the first CREATE_CHILD_SA (right after IKE_AUTH is finished) will have no protection against QC = (since PPK is not used in original IKE SA and the first CREATE_CHILD_SA will be protected = using keys created during initial exchange). So, to protect identities from QC = the peers need to initiate the second CREATE_CHILD_SA (or INFORMATIONAL) exchange. = And the peers must also somehow prove their real identities, so AUTH = payloads=20 must also be included, and we end up with something like full IKE_AUTH = exchange... =20 Isn=E2=80=99t it too complex?=20 =20 If protecting identities is so much a concern, then we=E2=80=99d = probably rather go back to original draft, where PPK was used in initial exchanges and the identities were protected by it. =20 So, I think that the problem of protecting anonymity cannot be easily = solved now without substantial complicating of the protocol (unless I = misunderstood something very obvious). My vote is for follow-up draft (if it happen to appear at = all) or for going back to original QR proposal.=20 =20 Regards, Valery. =20 =20 Yoav =20 ------=_NextPart_000_008A_01D25146.55AD5870 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

o Valery Smyslov gave a suggestion = that we instead stir in the PPK
into the initial SK_d; as all keying = material is generated based on
that, this would also mean that IPsec = SAs and any child IKE SAs are
also protected. This also means = that an implementation would not need
to remember the PPK after the = initial negotiation. The only downside I
can see is that we would = have to be a bit careful about when we update
the SK_d (obviously, = before we actually use it).


If we can make this work, it seems like the best, = as it means we can forget
more things = sooner.

 

I=E2=80=99m guessing this would be something along = these lines:

 

OLD:

=C2=A0=C2=A0 {SK_d | SK_ai | SK_ar | SK_ei | =
SK_er | SK_pi | SK_pr }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D prf+ =
(SKEYSEED, Ni | Nr | SPIi | SPIr )

 

NEW:

=C2=A0=C2=A0 {SK_proto_d | SK_ai | SK_ar | =
SK_ei | SK_er | SK_pi | SK_pr }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D prf+ =
(SKEYSEED, Ni | Nr | SPIi | SPIr )n

=C2=A0=C2=A0 SK_d =3D prf(PPK, =
SK_proto_d}
 
 
I also thought of something like this.
 

 

So assuming this works and is secure, it seems like an = easy change.

 

 

Yes, and the simplicity was the main reason I suggested this = variant.

It allows to have the only place in the code where you have to = change

key derivation logic and to deal with PPK. Obviously, I vote for = it.



o = Would this idea of pseudonyms actually give any real = identity
protection? Wouldn=E2=80=99t that assume that several = initiators use the same
PPK (so they could use the same pseudonym)? = Is that the sort of thing
we should be = encouraging?


I need = to think about this.

It only matters to "road = warriors", i.e. remote access situations where the
end user can = move around.  This includes many more site to site VPNs = these
days due to CGN and just poor network architecture, such as the = Cloud
operators' baked in NAT44.

I'm concerned that we would = wind up with a new Group PSK like we had with = IKEv1.

 

Pseudonyms are not too difficult on the protocol = level, but managing them makes products and configuration very = difficult. So you=E2=80=99re giving groups of people the same pseudonym = and the same PPK? How do you group people together? With non-careful = grouping of users you can make it worse than exposing real names (not = =E2=80=9Cynir=E2=80=9D, but =E2=80=9CRND_ACCESS_GROUP=E2=80=9D, which is = more useful to an attacker). And that is the kind of exposure that we = can=E2=80=99t fix in protocol - we=E2=80=99re trusting administrators to = balance convenience, privacy and corporate information security. I think = they=E2=80=99ll all choose a single PPK and single pseudonym for = everybody.



o = Would we be happy with always negotiating a child SA (as none of = the
three proposals for stirring in the PPK attempt to protect the = initial
IKE SA)?


I wonder if this might be simpler and more = reliable to just always do it, and
specify it up = front.

 

Simple, yes. Reliable, yes. Necessary? IDK

 

 

I fail to understand how mandating to always negotiate Child SA helps = protect anonymity.

The only place where IKEv2 peers exchange identities is currently = IKE_AUTH exchange.

The current draft suggests that in case of PPK the peers should = immediately initiate

CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But = CREATE_CHILD_SA

doesn=E2=80=99t allow to exchange identities. So, if pseudonyms were = used in IKE_AUTH,

how are you going to exchange real identities? Even if we modify = CREATE_CHILD_SA

to optionally include IDi & IDr, this won=E2=80=99t be enough, = because the first CREATE_CHILD_SA

(right after IKE_AUTH is finished) will have no protection against QC = (since PPK is not

used in original IKE SA and the first CREATE_CHILD_SA will be = protected using

keys created during initial exchange). So, to protect identities from = QC the peers

need to initiate the second CREATE_CHILD_SA (or INFORMATIONAL) = exchange.

And the peers must also somehow prove their real identities, so AUTH = payloads

must also be included, and we end up with something like full = IKE_AUTH exchange...

 

Isn=E2=80=99t it too complex?

 

If protecting identities is so much a concern, then we=E2=80=99d = probably rather

go back to original draft, where PPK was used in initial = exchanges

and the identities were protected by it.

 

So, I think that the problem of protecting anonymity cannot be easily = solved

now without substantial complicating of the protocol (unless I = misunderstood something

very obvious). My vote is for follow-up draft (if it happen to appear = at all) or

for going back to original QR proposal.

 

Regards,

Valery.

 

 

Yoav

 

------=_NextPart_000_008A_01D25146.55AD5870-- From nobody Thu Dec 8 04:44:48 2016 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 D142012987C for ; Thu, 8 Dec 2016 04:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 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_LOW=-0.7, RCVD_IN_SORBS_WEB=3.595, 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 D9oiPa3c4vDO for ; Thu, 8 Dec 2016 04:44:45 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 3D3B5129DDD for ; Thu, 8 Dec 2016 04:44:28 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id a197so215147455wmd.0 for ; Thu, 08 Dec 2016 04:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Zo5Y49wtmsSO2UHgtdCxsFDxkqP4CxgM3K8bVFOKC88=; b=dyPrY/Sl9krJe38bZ0SHfBR/UL0CfGRpmQYXpWX2M0mO0yXvbtNDAXz3oCPUJYhofM BY2z9SNx1KTF2aoQILwphCRy+jquiLyIM0ga4w1pOaFkvOq8RTcS5kdggGoEzYn90krG /8lCDo2M3NSbJUD7sfbZijY4btEzY8ORUEQnlaFcDFZ3jn9w3ZmR2C8uq3mX3T768PC+ FpCxxXYJdvlkY+owEnjK7mzxz/mgpl2nnWzdvfhgbDU0S3L3v+VyCkMXBfDf8HjFsKqv R3bDQLvUjzaXSXGZKmM9A20cgug1QATUVlIhkup3eMJfqrE1AQELkIA2p2Ulo69UZTxo xudQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Zo5Y49wtmsSO2UHgtdCxsFDxkqP4CxgM3K8bVFOKC88=; b=OtyyK/vQNUTYp2o5FGGs5jSUyyeb2NAelzxeZpQzgUQottDPmRma4TZ6zs2cmiJu8a 7koESftRl8ivWnZFnC2p0ijDGN89MRSc5mcVnU5+nsqMwvC5uq1wmKTLkNNvp9Fye/8z IzCFsdo52Bq1jPOqlksDzU1AScF2e5t1uO7MHifcIf1HZtedjURnkz9QzwtOvUoUmY+S lqysc9rF0dUfw5DK2slMcsEAJ4sPLXzvp8DJAMaLhSCs3OrMQvk7JyaG/QEpEb4g/lk/ f7LAICDtdyLCYJ4yKs6kbsH6ZzfQTU5dstKLzu0yfvaqeQx7EFF7YBHxsMds22dwf9w5 0Ffw== X-Gm-Message-State: AKaTC01Uq+7deQUsyPb4NAqBTbM4WDEQIA8JCJ+h3HPMH2LGw8zmrWeTx6+jRDub8hDXlQ== X-Received: by 10.25.166.207 with SMTP id p198mr26818966lfe.83.1481201066125; Thu, 08 Dec 2016 04:44:26 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id v9sm5646626lja.0.2016.12.08.04.44.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 04:44:25 -0800 (PST) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" Date: Thu, 8 Dec 2016 15:44:19 +0300 Message-ID: <009101d25150$cb999800$62ccc800$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJRSoANBOFNDgHoTgmUjI6dICqblQ== Content-Language: ru Archived-At: Cc: 'IPsecme WG' Subject: [IPsec] Quantum Resistant IKEv2 - mismatched PPKs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 12:44:47 -0000 Hi, I have one concern with the current draft: how to gracefully handle the = situation when PPKs on initiator and responder don't match (due to configuration = error=20 or PPK update). With the current draft this situation isn't handled at = all: after creating Child IKE SA both peers will end up with new SA having different SK_* values on each side. As a result - the new SA won't be = operable and the peers won't be even able to send back SYNTAX_ERROR notification over it (very similar to the same situation in IKEv1). My idea to gracefully handle this situation is to use PPK_NOTIFY = notification. Currently it contains no data, but it is possible to put something like = prf(PPK, Nr) for initiator and=20 prf(PPK, Ni) for responder in PPK_NOTIFY notification [0]. This would = allow peers to verify=20 that the other side does have the same key before actually using it. In = case the check fails a peer can return AUTHENTICATION_FAILED over initial IKE SA. I only concern whether this would open some new attacks (like providing = an oracle). Regards, Valery. [0] So that each side proves possession of PPK by applying it to random = data, generated by peer. From nobody Thu Dec 8 04:51:04 2016 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 88DEA12987D for ; Thu, 8 Dec 2016 04:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFVgKgW40AWW for ; Thu, 8 Dec 2016 04:51:01 -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 23E8F12951F for ; Thu, 8 Dec 2016 04:41:13 -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 uB8Cf6kN003523 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Dec 2016 14:41:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB8Cf6DQ004827; Thu, 8 Dec 2016 14:41:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22601.21730.53034.495290@fireball.acr.fi> Date: Thu, 8 Dec 2016 14:41:06 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <22600.13475.748226.49629@fireball.acr.fi> <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 6 min Archived-At: Cc: "ipsec@ietf.org" , "Hu, Jun \(Nokia - US\)" Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 12:51:02 -0000 Paul Wouters writes: > >> If we assume rfc7431bis can be used with manual keys too, we need to add > >> some more text saying these ciphers cannot be used with manual keys. > > >> Anyways, I think it should be time to mark manual keys as SHOULD NOT. > > While I agree, I don't think 7321bis should do that. > > How about a new section between section 2 and 3: > > Manual Keying > > Manual Keying should not be used as it is inherently dangerous. Without > any keying protocol, it does not offer Perfect Forward Secrecy > protection. Deployments tend to never be reconfigured with fresh session > keys. It also fails to scale and keeping SPI's unique amongst many servers > is impractical. This document was written for deploying ESP/AH using IKE > (RFC7298) and assumes that keying happens using IKEv2. > > If manual keying is used anyway, ENCR_AES_CBC MUST be used, and > ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT > be used as these algorithms require IKE. I think that kind of addition the rfc7321bis would be in order. Can you add that text and resubmit? > [note the first "should not" is in lower case in purpose, so we don't > actually need to update 4301] Perhaps not using word "should" is better. Something like "Manual Keying is not to be used as ...". Then we do not need to explain why it is not uppercase SHOULD... > >> Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT > >> be used, and mark it as updating RFC4301? > >> > >> Or should we have separate RFC stating that? > > draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipcomp :) > > Seriously though, I don't think writing a document like that will change > anything. And at least on Linux, the ip xfrm command allows for manual > keying and therefor assist with testing, but the IKE daemons (libreswan, > strongswan and openswan) do not support manual keying anymore. Now seeing that there is things that require manual keys and which might be in use, I agree that we do not want to delay rfc7321bis because of this, and I think adding just the not above is correct solution. Then we might start new draft like you proposed and make that to update RFC4301, and that draft can then provide more text how to fix those protocols using manual keying... -- kivinen@iki.fi From nobody Thu Dec 8 05:01:20 2016 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 F262B12996D for ; Thu, 8 Dec 2016 05:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 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_LOW=-0.7, RCVD_IN_SORBS_WEB=3.595, 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 3gISN_zqhu-5 for ; Thu, 8 Dec 2016 05:01:16 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5424D129881 for ; Thu, 8 Dec 2016 05:01:15 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id t79so24395948wmt.0 for ; Thu, 08 Dec 2016 05:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=nXm7LnVl1lnDSsB9XrIk8IcsuRbGEu54SPeHGNOKpQA=; b=P3uZpeRMPuXxe36YWjvBkZSDT0fK3175zsQu26PNQ6Tgld1JN4ql6KkhPozIH7cFUx KHD6+WKV8FgiNwSbjnxSaHWtkKlSQxKvzMxFSd0hNQXfJLaJ8HeZRRXc1VvTkiQHBW38 KKCeVI9Wb/UYOWzfMQ5JxPu6XRo7iCk/02RmDAua9ZVQgtSXDV/8ZJGOiNeUUcZQ+Jkv cNzIgRtBhXDnqsISJkhJCEyeXmsolypUS0RfXt5VNSs1OIjfZY50MRurqot+rZV+S4jN WMoRr6eT8+Q+qCxblshVlSu4HUueM+EVTulBetBC8fGPxXb6do2235hyFGGM5aJhPJBF 98AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=nXm7LnVl1lnDSsB9XrIk8IcsuRbGEu54SPeHGNOKpQA=; b=jenuWXdfaLiYfo1xGgDN90uJJqw3305e4XD9wLQ7k+pbJDSXUffn6tAfPBVAscWU9H jU8F6uy0diKRAAJ7nGfglLFWRgXNHn7wSTJAiaYVUrK4atOFmD0dDKmSXfj8/SS/IVkP B0ZUUa4CEEOL+1xldYITLW9D9OU0suT72vdFx5UOECydMCXsym+bNLFHib6EsvDAy1Kp vXrd/1XLUbKCdU9tDxZ2YDqMuZkWPcM7xDmXy55Vmo92bpCVqPgT9iI8nulz8PhGadth cI1mWvbA1P1CfVwcj+SCRvi0iNoOu/XIyHxH5X8Frs7iBMmAlz/9Y65GfR+hlUkvzaHN a3Dg== X-Gm-Message-State: AKaTC03+KfFX4w2hqNejY61cQk7mCx57oQjFAGn/6isVtCW5IA6tisVYinjr3JNoQ+eeAA== X-Received: by 10.46.13.26 with SMTP id 26mr14939173ljn.53.1481202073656; Thu, 08 Dec 2016 05:01:13 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id z2sm5648327lja.10.2016.12.08.05.01.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 05:01:12 -0800 (PST) From: "Valery Smyslov" To: "'Tommy Pauly'" , "'IPsecME WG'" References: <148089265595.5531.2220473726694989505.idtracker@ietfa.amsl.com> <3E7ABAD5-8657-49E9-9648-0B23DAA927FA@apple.com> In-Reply-To: <3E7ABAD5-8657-49E9-9648-0B23DAA927FA@apple.com> Date: Thu, 8 Dec 2016 16:01:07 +0300 Message-ID: <009201d25153$23fbddd0$6bf39970$@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: AQJ/tOXEu28vslL+fEsWWyB3/gfa0AI4b+HWn5F3WJA= Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 13:01:18 -0000 Hi Tommy, I think the new text substantially simplifies implementations. Thank you, Valery. > Hello all, > > I've updated the TCP Encapsulation draft with new recommendations around handling the mapping > between IKE SAs and TCP Connections based on the conversation at the Seoul meeting. The relevant new > text in section 6 is: > > > An initiator SHOULD only open one TCP connection per IKE SA, over > which it sends all of the corresponding IKE and ESP messages. This > helps ensure that any firewall or NAT mappings allocated for the TCP > connection apply to all of the traffic associated with the IKE SA > equally. > > A responder SHOULD at any given time send packets for an IKE SA and > its Child SAs over only one TCP connection. It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message. Since a connection may be broken and a new connection > re-established by the initiator without the responder being aware, a > responder SHOULD accept receiving IKE and ESP messages on a new > connection. It will then use that connection for all subsequent > responses. A responder MAY close a TCP connection that it perceives > as idle and extraneous (one previously used for IKE and ESP messages > that has been replaced by a new connection). > > Multiple IKE SAs SHOULD NOT share a single TCP connection. > > Please respond to indicate your thoughts on this! > > Thanks, > Tommy > > > > On Dec 4, 2016, at 3:04 PM, internet-drafts@ietf.org wrote: > > > > > > 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 of the IETF. > > > > Title : TCP Encapsulation of IKE and IPsec Packets > > Authors : Tommy Pauly > > Samy Touati > > Ravi Mantha > > Filename : draft-ietf-ipsecme-tcp-encaps-04.txt > > Pages : 21 > > Date : 2016-12-04 > > > > Abstract: > > This document describes a method to transport IKE and IPsec packets > > over a TCP connection for traversing network middleboxes that may > > block IKE negotiation over UDP. This method, referred to as TCP > > encapsulation, involves sending both IKE packets for tunnel > > establishment as well as tunneled packets using ESP over a TCP > > connection. This method is intended to be used as a fallback option > > when IKE cannot be negotiated over UDP. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04 > > > > > > 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 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Dec 8 05:07:15 2016 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 35647129DCC for ; Thu, 8 Dec 2016 05:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXUDLaFkYYon for ; Thu, 8 Dec 2016 05:07:08 -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 749E4129956 for ; Thu, 8 Dec 2016 05:07:00 -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 uB8D6pbX027976 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Dec 2016 15:06:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB8D6pMW005444; Thu, 8 Dec 2016 15:06:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22601.23275.262032.679735@fireball.acr.fi> Date: Thu, 8 Dec 2016 15:06:51 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <8843.1481154231@obiwan.sandelman.ca> References: <8843.1481154231@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 61 min X-Total-Time: 19 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 13:07:15 -0000 Michael Richardson writes: > > o Valery Smyslov gave a suggestion that we instead stir in the = PPK > > into the initial SK=5Fd; as all keying material is generated ba= sed on > > that, this would also mean that IPsec SAs and any child IKE SAs= are > > also protected. This also means that an implementation would no= t need > > to remember the PPK after the initial negotiation. The only dow= nside I > > can see is that we would have to be a bit careful about when we= update > > the SK=5Fd (obviously, before we actually use it). >=20 > If we can make this work, it seems like the best, as it means we can = forget > more things sooner. I agree on that, and I really like the fact that we can remove PPK from the memory immediately after the initial exchange is finished. > > o Would this idea of pseudonyms actually give any real identity= > > protection=3F Wouldn=E2=80=99t that assume that several initiat= ors use the same > > PPK (so they could use the same pseudonym)=3F Is that the sort = of thing > > we should be encouraging=3F >=20 > I need to think about this. >=20 > It only matters to "road warriors", i.e. remote access situations whe= re the > end user can move around. This includes many more site to site VPNs = these > days due to CGN and just poor network architecture, such as the Cloud= > operators' baked in NAT44. >=20 > I'm concerned that we would wind up with a new Group PSK like we had > with IKEv1. The issue with Group PSK was that any client could fake to be server, and if the next authentication in IKEv1 was normal password authentication where password was sent from the client to the server for verification protected by the group PSK, which meant anybody in group could steal other peoples passwords. Here we will be doing normal IKEv2 authentication in addition to the PPK, so even if the PPK is shared between people, if the server and client use proper authentication (cert + eap for exmple), then they are not vulnerable for this kind of attacks. My take on the proposed protocol would be same as in the draft-fluhrer-qr-ikev2-03: Initiator Responder ------------------------------------------------------------------ HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TS, TSr, N(PPK=5FNOTIFY)} ---> <--- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, N(PPK=5FNOTIFY)} but instead of the PPK=5FNOTIFY to be empty, I would say that the PPK=5FNOTIFY contains the opaque binary object identifying the PPK that= will be used in the exchange, i.e., PPK=5FID. The actual format of the PPK=5FID is implementation dependant, and it could be static, or it could contain some changeable parts. Some examples could be: =09PPK=5FID =3D kivinen@iki.fi =09 =09 (unique id for each user) =09PPK=5FID =3D \x1234 =09 =09 (unique id number for each user) =09PPK=5FID =3D \x0001 =09=09 (group id or version number of the PPK) =09PPK=5FID =3D \x00001234\x00000001 =09 (user id 0x1234 and version number 0x1 for him). =09PPK=5FID =3D asn1 blob identifying file name, and offset in file etc... The client would send the PPK=5FID, and server would either accept it o= r not, and if server accepts PPK=5FID, it will reply with its own PPK=5FNOTIFY, which may contain anything (i.e., it can be used to backchannel from server to client, for example server could send PPK=5FID saying next number to use in the list is \x0002). For the pseudonyms, we do not really need to do anything, we can simply say that IDi can be ID=5FKEY=5FID and contain random opaque octe= t stream identifying the user pseudonym. Then later we can make protocol that says that we do IKEv2 SA rekey to gain QR for the IKEv2 SA, and then we simply send CFG=5FSET to pseudony= m configuration attribute which indiates the next random ID=5FKEY=5FID object we are going to be using next time we log in... For now we do not need to do anything yet, it is simply enough that we do have clear way of forward in the future, and we do not limit our options unnecessarily.=20 > > o Would we be happy with always negotiating a child SA (as none= of the > > three proposals for stirring in the PPK attempt to protect the = initial > > IKE SA)=3F If you do not want to have the child sa, just use the RFC6023. > I wonder if this might be simpler and more reliable to just always > do it, and specify it up front. --=20 kivinen@iki.fi From nobody Thu Dec 8 05:21:30 2016 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 80537129CB0 for ; Thu, 8 Dec 2016 05:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6rt0K_a2uzm for ; Thu, 8 Dec 2016 05:21:28 -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 340761298A8 for ; Thu, 8 Dec 2016 05:21:03 -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 uB8DKtCH018000 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Dec 2016 15:20:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB8DKtGB029674; Thu, 8 Dec 2016 15:20:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22601.24119.100454.380354@fireball.acr.fi> Date: Thu, 8 Dec 2016 15:20:55 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <008901d2512d$305b6580$91123080$@gmail.com> References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 43 min X-Total-Time: 11 min Archived-At: Cc: 'IPsecme WG' , 'Michael Richardson' , 'Yoav Nir' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 13:21:29 -0000 Valery Smyslov writes: > CREATE=5FCHILD=5FSA exchange and rekey the IKE SA using PPK. But > CREATE=5FCHILD=5FSA doesn=E2=80=99t allow to exchange identities. So,= if > pseudonyms were used in IKE=5FAUTH, how are you going to exchange rea= l > identities=3F Real IDs are never exchanged over wire. The server sees pseudonym ID=5FKEY=5FID \x1c747c060d209a223d1f9f51b0351b54, it looks it up from i= ts table and finds a mapping from there to kivinen@iki.fi. From then on it uses kivinen@iki.fi as authenticated identifier, and verifies that the raw public key, or shared key used to authenticate the user actually matches the one configured to the kivinen@iki.fi. Using certificates in this case would leak out the identity anyways, so they cannot be used, or at least transmitted over wire. Even if using raw public keys, the actual public keys must not be sent over wire, it needs to be taken from the configuration. > And the peers must also somehow prove their real identities, so AUTH > payloads must also be included, and we end up with something like > full IKE=5FAUTH exchange... This all is done in the server, i.e. instead of using the ID sent over the wire, the server uses the ID sent over wire as handle to the table, and fetches the real ID to be used for policy decisions and authentication from the that table. Then psedonym update protocol is run later, after we have done IKEv2 SA rekey to gain QR for IKEv2 SA too, and that would say update the ID=5FKEY=5FID from \x1c747c060d209a223d1f9f51b0351b54 to \x7ca765c1972372cecf78184d1a628d05, and next time client comes in he does not use the ID=5FKEYID of \x1c747c060d209a223d1f9f51b0351b54, but he uses the new ID=5FKEY=5FID \x7ca765c1972372cecf78184d1a628d05 instea= d. Note, again that how those pseudonyms are generated and what kind of format they have is outside the scope of this protocol. Of course the pseudonum protocol most likely would need some kind of safe guards against getting out of sync in client and server, for example client could send 10 next pseudonyms, and server could allow any one of them to be used. > So, I think that the problem of protecting anonymity cannot be > easily solved now without substantial complicating of the protocol > (unless I misunderstood something very obvious). My vote is for > follow-up draft (if it happen to appear at all) or > for going back to original QR proposal. I disagree on, that but that does not matter, as we do not need to specify it now. I am convinced that we can do it separately provided we have a way to making IKEv2 SA also protected against QR attacks somehow (i.e., make IKEv2 SA rekey to provide IKEv2 SA QR properties). --=20 kivinen@iki.fi From nobody Thu Dec 8 05:31:17 2016 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 04D4C1299AF for ; Thu, 8 Dec 2016 05:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 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_LOW=-0.7, RCVD_IN_SORBS_WEB=3.595, 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 87bFRhR0IQjh for ; Thu, 8 Dec 2016 05:31:14 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 B4CA0129FF2 for ; Thu, 8 Dec 2016 05:30:54 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id g23so217444594wme.1 for ; Thu, 08 Dec 2016 05:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=dv2kyj5n+28K9RugdV7Pj8BxOpGqLtKkjZOJvfh+gMc=; b=tARanIc7G5i2YWd30tb5pNXZjURS2OOXTR1y179VCg5Sal869yJdC0qgd3GbbevqL0 vaUYv6f3FU/z+Il1SdQAUvJ9LsmHnI6pLFXLVSud+JR512gQ78aybbW8yStQdR4pCX9L vSr7atYsTPWYI6hpfEXnbmVh69diLrviyz9Mr6xUJ9IylMyIGU1djffU8FLmhM6DuEPP oyRFzBKtsVR/C8CG6t75GSReoghrXIVqLxntFvtekgkc3lfWA6cTCzG7AN+1tQEkwNiP YSeuucV17kPQNwYwl5oaRgx7ZwlmllOm0/Hr5GJ0Cfn/JmLlE0nUH1f2J+yP8Z5GLWiv 30YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=dv2kyj5n+28K9RugdV7Pj8BxOpGqLtKkjZOJvfh+gMc=; b=jd0jkTf31QySXAYe+/AzYHXIQwlcbeujrZN9VBYUyeNal15Y4wF8ztI09dKKSRnc6+ M6vfANyBoxBz51li6fEhhFwblDKFhf7nYfK5OqWof+lCNconfLfXjNhTZOWu0uvZXX76 cXDOwrszJroPeU+dDJBWzBTN04LXtaAo+N9UCC5hI+W2yBahDnA1pG6tgLWBfdGSAODd wl+vLPF9OUKKr4JSiCfJ97DKk6SE0vH3vJ7CQ4lfGzBcCLkj3/vnxZsATb+ZQwgCNEu5 9S0FyP2DJwdjcoMbQxiO7zzu+HbJ4+wituEYtKeufxBFj/0WZ6+JXrpsWtLgR/OoaAKP 07oQ== X-Gm-Message-State: AKaTC013P5zcFDjDYM+MZYasOiTe0tl0dPooWNkK9XboSAX8U7lBxYQmnBxZt2DVy1bH2A== X-Received: by 10.25.20.38 with SMTP id k38mr25781437lfi.139.1481203853081; Thu, 08 Dec 2016 05:30:53 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k7sm3642609lfe.37.2016.12.08.05.30.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 05:30:52 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> <22601.24119.100454.380354@fireball.acr.fi> In-Reply-To: <22601.24119.100454.380354@fireball.acr.fi> Date: Thu, 8 Dec 2016 16:30:46 +0300 Message-ID: <00a101d25157$48cbb500$da631f00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGf0y3ElAb1MY6fIaqsOC5fSHHzigJCwQTLAXo2HB0CWUj3FAHh1UoroSNF57A= Content-Language: ru Archived-At: Cc: 'IPsecme WG' , 'Michael Richardson' , 'Yoav Nir' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 13:31:16 -0000 Hi Tero, > > CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But > > CREATE_CHILD_SA doesn=E2=80=99t allow to exchange identities. So, if > > pseudonyms were used in IKE_AUTH, how are you going to exchange real > > identities? >=20 > Real IDs are never exchanged over wire. The server sees pseudonym Then what is the content of IDi and IDr in IKE_AUTH in this case? > ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54, it looks it up from its > table and finds a mapping from there to kivinen@iki.fi. From then on > it uses kivinen@iki.fi as authenticated identifier, and verifies that > the raw public key, or shared key used to authenticate the user > actually matches the one configured to the kivinen@iki.fi. >=20 > Using certificates in this case would leak out the identity anyways, > so they cannot be used, or at least transmitted over wire. Even if > using raw public keys, the actual public keys must not be sent over > wire, it needs to be taken from the configuration. >=20 > > And the peers must also somehow prove their real identities, so AUTH > > payloads must also be included, and we end up with something like > > full IKE_AUTH exchange... >=20 > This all is done in the server, i.e. instead of using the ID sent over > the wire, the server uses the ID sent over wire as handle to the > table, and fetches the real ID to be used for policy decisions and > authentication from the that table. Again, what role the usual authentication (in IKE_AUTH) and usual IKE Identities play in this scenario? Regards, Valery. From nobody Thu Dec 8 08:00:08 2016 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 B4169129F25 for ; Thu, 8 Dec 2016 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 gQQ-mgk9_Jx2 for ; Thu, 8 Dec 2016 08:00:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F200B129EC3 for ; Thu, 8 Dec 2016 08:00:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E15D203AE for ; Thu, 8 Dec 2016 11:17:32 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0FF0663782 for ; Thu, 8 Dec 2016 11:00:02 -0500 (EST) From: Michael Richardson To: "'IPsecme WG'" In-Reply-To: <22601.24119.100454.380354@fireball.acr.fi> References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> <22601.24119.100454.380354@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+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] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 16:00:06 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > This all is done in the server, i.e. instead of using the ID sent over > the wire, the server uses the ID sent over wire as handle to the > table, and fetches the real ID to be used for policy decisions and > authentication from the that table. > Then psedonym update protocol is run later, after we have done IKEv2 > SA rekey to gain QR for IKEv2 SA too, and that would say update the > ID_KEY_ID from \x1c747c060d209a223d1f9f51b0351b54 to > \x7ca765c1972372cecf78184d1a628d05, and next time client comes in he > does not use the ID_KEYID of \x1c747c060d209a223d1f9f51b0351b54, but > he uses the new ID_KEY_ID \x7ca765c1972372cecf78184d1a628d05 instead. I can buy this. It seems independantly useful to me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhJg4EACgkQgItw+93Q 3WUKrgf+Pimf6z5zdbEmWTy8wh363xlB7LZubtGah/+I60GoLS+5mqVjBr+tuLDa r1TLqmojECaUz6sUx1hDa1ZYajeIGeBpZwDskWid4yhc2AxBOjemKbY7i5QT7WOQ iFrAiOXISpSopd3/srCjPdS6KKfBEm7IFneHZX5IoH3wHkVhlcSom35ryNlR2NaD rVB3T4ABiWmiuquQsur68WPQ8FB2R8jic8ibclXvg6zuUPAVHCpUX4uNQBFfiud7 YK92pDaJGCgzq0lsK9MYjrTVZeCtmdCh1CqRmyMF8biIikv0i/n5ZQjZ7zuzGquJ ebUoMucCfnnrSxRNay2f0TXXMB8nqA== =Kmyg -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 8 08:44:56 2016 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 92598129859; Thu, 8 Dec 2016 08:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 T6pTv7Wqaf4O; Thu, 8 Dec 2016 08:44:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9851C129442; Thu, 8 Dec 2016 08:44:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8CE5DB8023B; Thu, 8 Dec 2016 08:44:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161208164452.8CE5DB8023B@rfc-editor.org> Date: Thu, 8 Dec 2016 08:44:52 -0800 (PST) Archived-At: Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 8031 on Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 16:44:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8031 Title: Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement Author: Y. Nir, S. Josefsson Status: Standards Track Stream: IETF Date: December 2016 Mailbox: ynir.ietf@gmail.com, simon@josefsson.org Pages: 8 Characters: 14969 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-safecurves-05.txt URL: https://www.rfc-editor.org/info/rfc8031 DOI: 10.17487/RFC8031 This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2). This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 8 09:02:52 2016 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 D5C681294EE for ; Thu, 8 Dec 2016 09:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 tDUPQbXRFJWs for ; Thu, 8 Dec 2016 09:02:49 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D628E1293D9 for ; Thu, 8 Dec 2016 09:02:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AE9C3300269 for ; Thu, 8 Dec 2016 11:52:31 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5rFjzpowN_qT for ; Thu, 8 Dec 2016 11:52:29 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A670530004F; Thu, 8 Dec 2016 11:52:29 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B98C457-36F8-4816-9A0C-0502A934994B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 8 Dec 2016 12:02:46 -0500 Message-Id: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> References: To: Scott Fluhrer X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 17:02:51 -0000 --Apple-Mail=_6B98C457-36F8-4816-9A0C-0502A934994B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Scott: > In the WG meeting in Seoul, we discussed the Quantum Resistant = proposal for IKEv2, and decided to make the current draft = (draft-fluhrer-qr-ikev2-03) as work item. > =20 > During the discussion, two items were raised, and I would like to hear = how the wider WG feels about these two items: > =20 > - The first item is =93how exactly do we stir in the = preshared key (PPK) into the keying material=94. By my count, three = options were on the table: > o There is the option listed in the draft, where we modify both the = KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies = that the IPsec SAs are generated with QR-resistant keying material, = while stirring it into the SKEYSEED implies that any child IKE SAs = implies that any IKE SA (other than the initial one) also has = QR-resistant keying material. This latter was done specifically so that = an implementation can have protected IKE SAs (by negotiating a child SA = immediately) > o Dan Harkins suggested that we modify only the KEYMAT. This is a = simpler option, and will continue to protect the IPsec SAs; however this = implies that any data protected by the IKE SA could potentially be = recovered by a Quantum Computer. > o Valery Smyslov gave a suggestion that we instead stir in the PPK = into the initial SK_d; as all keying material is generated based on = that, this would also mean that IPsec SAs and any child IKE SAs are also = protected. This also means that an implementation would not need to = remember the PPK after the initial negotiation. The only downside I can = see is that we would have to be a bit careful about when we update the = SK_d (obviously, before we actually use it). > To me, all three strike me as reasonable ideas (unless we decide that = we will need to protect the real identity data encrypted via the IKE SA; = in that case, Dan=92s idea doesn=92t protect that). Can I get opinions = as to which strikes the group as the best? Are there any fourth options = that people would want to put on the table? I would like to see the preshared key used in a manner that protects the = IKE SA as well as the child SA. I have a mild preference for the third = alternative over the first one. > - The second item is anonymity; some people were interested = in preserving anonymity (however, not at the expense of excessive = complexity). One idea that was brought up was that the initial exchange = would be done using pseudonyms (which would be sufficient for the = responder to identity the PPK), and then once initial IKE SAs have been = established (in a QR form), exchange the real identities. My questions: > o Would this idea of pseudonyms actually give any real identity = protection? Wouldn=92t that assume that several initiators use the same = PPK (so they could use the same pseudonym)? Is that the sort of thing = we should be encouraging? > o Should this be addressed in this draft, or could it be addressed = in a follow-up draft? > o If it would be addressed in a follow-up, would any hooks be = required? For example, would we want to introduce an opaque bit in a = notify message to indicate this? > o Would we be happy with always negotiating a child SA (as none of = the three proposals for stirring in the PPK attempt to protect the = initial IKE SA)? > My opinion is that this could be placed in a follow-up draft. +1. Please do not delay the quantum resistant work while this gets = sorted out. In the past, the discussions of identity protection have = not been short. Russ --Apple-Mail=_6B98C457-36F8-4816-9A0C-0502A934994B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Scott:

In the WG meeting in = Seoul, we discussed the Quantum Resistant proposal for IKEv2, and = decided to make the current draft (draft-fluhrer-qr-ikev2-03) as work = item.
 
During the discussion, two items were raised, and = I would like to hear how the wider WG feels about these two = items:
 
-          The first = item is =93how exactly do we stir in the preshared key (PPK) into the = keying material=94.  By my count, three options were on the = table:
o   There = is the option listed in the draft, where we modify both the KEYMAT and = SKEYSEED computations; stirring it into the KEYMAT implies that the = IPsec SAs are generated with QR-resistant keying material, while = stirring it into the SKEYSEED implies that any child IKE SAs implies = that any IKE SA (other than the initial one) also has QR-resistant = keying material.  This latter was done specifically so that an = implementation can have protected IKE SAs (by negotiating a child SA = immediately)
o   Dan = Harkins suggested that we modify only the KEYMAT.  This is a = simpler option, and will continue to protect the IPsec SAs; however this = implies that any data protected by the IKE SA could potentially be = recovered by a Quantum Computer.
o   Valery = Smyslov gave a suggestion that we instead stir in the PPK into the = initial SK_d; as all keying material is generated based on that, this = would also mean that IPsec SAs and any child IKE SAs are also = protected.  This also means that an implementation would not need = to remember the PPK after the initial negotiation.  The only = downside I can see is that we would have to be a bit careful about when = we update the SK_d (obviously, before we actually use = it).
To me, all three = strike me as reasonable ideas (unless we decide that we will need to = protect the real identity data encrypted via the IKE SA; in that case, = Dan=92s idea doesn=92t protect that).  Can I get opinions as to = which strikes the group as the best?  Are there any fourth options = that people would want to put on the = table?

I would like to see = the preshared key used in a manner that protects the IKE SA as well as = the child SA.  I have a mild preference for the third alternative = over the first one.


-          The second = item is anonymity; some people were interested in preserving anonymity = (however, not at the expense of excessive complexity).  One idea = that was brought up was that the initial exchange would be done using = pseudonyms (which would be sufficient for the responder to identity the = PPK), and then once initial IKE SAs have been established (in a QR = form), exchange the real identities.  My = questions:
o   Would = this idea of pseudonyms actually give any real identity = protection?  Wouldn=92t that assume that several initiators use the = same PPK (so they could use the same pseudonym)?  Is that the sort = of thing we should be encouraging?
o   Should = this be addressed in this draft, or could it be addressed in a follow-up = draft?
o   If it = would be addressed in a follow-up, would any hooks be required?  = For example, would we want to introduce an opaque bit in a notify = message to indicate this?
o   Would = we be happy with always negotiating a child SA (as none of the three = proposals for stirring in the PPK attempt to protect the initial IKE = SA)?
My opinion is that = this could be placed in a follow-up = draft.

+1. =  Please do not delay the quantum resistant work while this gets = sorted out.  In the past, the discussions of identity protection = have not been = short.

Russ


= --Apple-Mail=_6B98C457-36F8-4816-9A0C-0502A934994B-- From nobody Thu Dec 8 13:26:39 2016 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 30BA5129534 for ; Thu, 8 Dec 2016 13:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qNTGclheB0rd for ; Thu, 8 Dec 2016 13:26:35 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6768E129563 for ; Thu, 8 Dec 2016 13:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18524; q=dns/txt; s=iport; t=1481232394; x=1482441994; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jGKIOgv7CzsjlzaWOKnKPrNWUCV+eINbjx89zGQCkUI=; b=hPWViV98tTUbkA0z8bLKBGoBM7U/JdaNiOrxgVk0cgyT/s0VBzIrOXH1 qzH3Hc6cPGHZVY7TeerjgMmj0i3KP9iMerGvUHCiJhqhWDkq+fZArqsti eEWglfQD1j2nLW4TjA0bmchovvepD/xhV14CSh90th4GJ5z/QSAG+2c2e Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCYz0lY/5ldJa1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzRAEBAQEBH1qBBgeNRJcTlQGCCIYhAoF6PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBC1MEAIBCBEEAQEoBzIUCQgBAQQOBQiIY6l8iy0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhB2CIYRbhCFdhSsFiUqRIAGRFYF8hH2JUYdlhiOEDQEfN4E?= =?us-ascii?q?ZhVZyiAyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208,217";a="358520337" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2016 21:26:32 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB8LQWl0012371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Dec 2016 21:26:32 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Dec 2016 16:26:31 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Thu, 8 Dec 2016 16:26:31 -0500 From: "Scott Fluhrer (sfluhrer)" To: Russ Housley Thread-Topic: [IPsec] Quantum Resistant IKEv2 Thread-Index: AdJQCCXgkOeGxGfPROWQbtulvkq0wABlqi4AAAGlCXA= Date: Thu, 8 Dec 2016 21:26:31 +0000 Message-ID: References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> In-Reply-To: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> 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.98.2.57] Content-Type: multipart/alternative; boundary="_000_a2dbed00b2274f4bae852f275afeb6f0XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:26:38 -0000 --_000_a2dbed00b2274f4bae852f275afeb6f0XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, December 08, 2016 12:03 PM To: Scott Fluhrer (sfluhrer) Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 Scott: In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for= IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) a= s work item. During the discussion, two items were raised, and I would like to hear how = the wider WG feels about these two items: - The first item is "how exactly do we stir in the preshared key (= PPK) into the keying material". By my count, three options were on the tab= le: o There is the option listed in the draft, where we modify both the KEYMA= T and SKEYSEED computations; stirring it into the KEYMAT implies that the I= Psec SAs are generated with QR-resistant keying material, while stirring it= into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (= other than the initial one) also has QR-resistant keying material. This la= tter was done specifically so that an implementation can have protected IKE= SAs (by negotiating a child SA immediately) o Dan Harkins suggested that we modify only the KEYMAT. This is a simple= r option, and will continue to protect the IPsec SAs; however this implies = that any data protected by the IKE SA could potentially be recovered by a Q= uantum Computer. o Valery Smyslov gave a suggestion that we instead stir in the PPK into t= he initial SK_d; as all keying material is generated based on that, this wo= uld also mean that IPsec SAs and any child IKE SAs are also protected. Thi= s also means that an implementation would not need to remember the PPK afte= r the initial negotiation. The only downside I can see is that we would ha= ve to be a bit careful about when we update the SK_d (obviously, before we = actually use it). To me, all three strike me as reasonable ideas (unless we decide that we wi= ll need to protect the real identity data encrypted via the IKE SA; in that= case, Dan's idea doesn't protect that). Can I get opinions as to which st= rikes the group as the best? Are there any fourth options that people woul= d want to put on the table? I would like to see the preshared key used in a manner that protects the IK= E SA as well as the child SA. I have a mild preference for the third alter= native over the first one. Actually, in terms of what IPsec/IKE traffic is immune from recovery from a= n adversary with a Quantum Computer, the first and third options are identi= cal. In both cases, the traffic that is protected by the initial IKE SA can be r= ecovered; that's because that traffic is encrypted by the initial SK_ei, SK= _er keys, and those would be recoverable. In both cases, any IPsec traffic= and any traffic protected by a child IKE SA would be safe (in the first op= tion, because we deliberately stir in the ppk when we generate them; in the= third option, because we stir in the ppk to form the updated SK_d, and the= n we use that SK_d to generate those keys). - The second item is anonymity; some people were interested in pre= serving anonymity (however, not at the expense of excessive complexity). O= ne idea that was brought up was that the initial exchange would be done usi= ng pseudonyms (which would be sufficient for the responder to identity the = PPK), and then once initial IKE SAs have been established (in a QR form), e= xchange the real identities. My questions: o Would this idea of pseudonyms actually give any real identity protectio= n? Wouldn't that assume that several initiators use the same PPK (so they = could use the same pseudonym)? Is that the sort of thing we should be enco= uraging? o Should this be addressed in this draft, or could it be addressed in a f= ollow-up draft? o If it would be addressed in a follow-up, would any hooks be required? = For example, would we want to introduce an opaque bit in a notify message t= o indicate this? o Would we be happy with always negotiating a child SA (as none of the th= ree proposals for stirring in the PPK attempt to protect the initial IKE SA= )? My opinion is that this could be placed in a follow-up draft. +1. Please do not delay the quantum resistant work while this gets sorted = out. In the past, the discussions of identity protection have not been sho= rt. Russ --_000_a2dbed00b2274f4bae852f275afeb6f0XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 <= /p>

From: IPsec [m= ailto:ipsec-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Thursday, December 08, 2016 12:03 PM
To: Scott Fluhrer (sfluhrer)
Cc: IETF IPsec
Subject: Re: [IPsec] Quantum Resistant IKEv2

 

Scott:



In the WG meeting in Seoul, we discusse= d the Quantum Resistant proposal for IKEv2, and decided to make the current= draft (draft-fluhrer-qr-ikev2-03) as work item.

 

During the discussion, two items were r= aised, and I would like to hear how the wider WG feels about these two item= s:

 

-       &nb= sp;  The first item is “how exactly do we stir in the preshared key (PPK) int= o the keying material”.  By my count, three options were on the = table:

o   <= /span>There is the option listed in the draft, where we modify both the KEYMAT and SKE= YSEED computations; stirring it into the KEYMAT implies that the IPsec SAs = are generated with QR-resistant keying material, while stirring it into the= SKEYSEED implies that any child IKE SAs implies that any IKE SA (other than the initial one) also has QR-r= esistant keying material.  This latter was done specifically so that a= n implementation can have protected IKE SAs (by negotiating a child SA imme= diately)

o   <= /span>Dan Harkins suggested that we modify only the KEYMAT.  This is a simpler = option, and will continue to protect the IPsec SAs; however this implies th= at any data protected by the IKE SA could potentially be recovered by a Qua= ntum Computer.

o   <= /span>Valery Smyslov gave a suggestion that we instead stir in the PPK into the initial= SK_d; as all keying material is generated based on that, this would also m= ean that IPsec SAs and any child IKE SAs are also protected.  This als= o means that an implementation would not need to remember the PPK after the initial negotiation.  The only= downside I can see is that we would have to be a bit careful about when we= update the SK_d (obviously, before we actually use it).<= /p>

To me, all three strike me as reasonabl= e ideas (unless we decide that we will need to protect the real identity da= ta encrypted via the IKE SA; in that case, Dan’s idea doesn’t protect that).  Can I get opinions as to which strikes the group as t= he best?  Are there any fourth options that people would want to put o= n the table?

 

I would like to see the preshared key used in a mann= er that protects the IKE SA as well as the child SA.  I have a mild pr= eference for the third alternative over the first one.

 <= /p>

Actually, in terms of wha= t IPsec/IKE traffic is immune from recovery from an adversary with a Quantu= m Computer, the first and third options are identical.

 <= /p>

In both cases, the traffi= c that is protected by the initial IKE SA can be recovered; that’s be= cause that traffic is encrypted by the initial SK_ei, SK_er keys, and those would be recoverable.  In both cases, any IPsec traffic and= any traffic protected by a child IKE SA would be safe (in the first option= , because we deliberately stir in the ppk when we generate them; in the thi= rd option, because we stir in the ppk to form the updated SK_d, and then we use that SK_d to generate those keys= ).

 



-       &nb= sp;  The second item is anonymity; some people were interested in preserving anonym= ity (however, not at the expense of excessive complexity).  One idea t= hat was brought up was that the initial exchange would be done using pseudo= nyms (which would be sufficient for the responder to identity the PPK), and then once initial IKE SAs have been es= tablished (in a QR form), exchange the real identities.  My questions:=

o   <= /span>Would this idea of pseudonyms actually give any real identity protection?  = Wouldn’t that assume that several initiators use the same PPK (so the= y could use the same pseudonym)?  Is that the sort of thing we should = be encouraging?

o   <= /span>Should this be addressed in this draft, or could it be addressed in a follow-up d= raft?

o   <= /span>If it would be addressed in a follow-up, would any hooks be required?  F= or example, would we want to introduce an opaque bit in a notify message to= indicate this?

o   <= /span>Would we be happy with always negotiating a child SA (as none of the three propo= sals for stirring in the PPK attempt to protect the initial IKE SA)?

My opinion is that this could be placed= in a follow-up draft.

 

+1.  Please do not delay the quantum resist= ant work while this gets sorted out.  In the past, the discussions of = identity protection have not been short.

 

Russ

 

 

--_000_a2dbed00b2274f4bae852f275afeb6f0XCHRTP006ciscocom_-- From nobody Thu Dec 8 14:03:06 2016 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 D8CF6129A98 for ; Thu, 8 Dec 2016 14:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 4bSsDWMDdTMh for ; Thu, 8 Dec 2016 14:03:03 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE376128E19 for ; Thu, 8 Dec 2016 14:02:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 825C6300261 for ; Thu, 8 Dec 2016 16:52:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q3mx7k7wXIAA for ; Thu, 8 Dec 2016 16:52:07 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id AB0C730009C; Thu, 8 Dec 2016 16:52:07 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_91C420E0-FEDE-4552-AC49-214AE1CFA4FD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 8 Dec 2016 17:02:24 -0500 Message-Id: <53359E5B-D598-4766-81CE-390137BD3DE9@vigilsec.com> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> To: Scott Fluhrer X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:03:05 -0000 --Apple-Mail=_91C420E0-FEDE-4552-AC49-214AE1CFA4FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Scott: >> During the discussion, two items were raised, and I would like to = hear how the wider WG feels about these two items: >> =20 >> - The first item is =93how exactly do we stir in the = preshared key (PPK) into the keying material=94. By my count, three = options were on the table: >> o There is the option listed in the draft, where we modify both the = KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies = that the IPsec SAs are generated with QR-resistant keying material, = while stirring it into the SKEYSEED implies that any child IKE SAs = implies that any IKE SA (other than the initial one) also has = QR-resistant keying material. This latter was done specifically so that = an implementation can have protected IKE SAs (by negotiating a child SA = immediately) >> o Dan Harkins suggested that we modify only the KEYMAT. This is a = simpler option, and will continue to protect the IPsec SAs; however this = implies that any data protected by the IKE SA could potentially be = recovered by a Quantum Computer. >> o Valery Smyslov gave a suggestion that we instead stir in the PPK = into the initial SK_d; as all keying material is generated based on = that, this would also mean that IPsec SAs and any child IKE SAs are also = protected. This also means that an implementation would not need to = remember the PPK after the initial negotiation. The only downside I can = see is that we would have to be a bit careful about when we update the = SK_d (obviously, before we actually use it). >> To me, all three strike me as reasonable ideas (unless we decide that = we will need to protect the real identity data encrypted via the IKE SA; = in that case, Dan=92s idea doesn=92t protect that). Can I get opinions = as to which strikes the group as the best? Are there any fourth options = that people would want to put on the table? >> =20 >> I would like to see the preshared key used in a manner that protects = the IKE SA as well as the child SA. I have a mild preference for the = third alternative over the first one. > =20 > Actually, in terms of what IPsec/IKE traffic is immune from recovery = from an adversary with a Quantum Computer, the first and third options = are identical. I recognize that. I would like to see the preshared key used in a manner that protects the = IKE SA as well as the child SA, and between the two alternatives that = offer that, I have a mild preference for the third alternative. Russ --Apple-Mail=_91C420E0-FEDE-4552-AC49-214AE1CFA4FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Scott:

During the discussion, two items were = raised, and I would like to hear how the wider WG feels about these two = items:
 
-          The first = item is =93how exactly do we stir in the preshared key (PPK) into the = keying material=94.  By my count, three options were on the = table:
o   There is = the option listed in the draft, where we modify both the KEYMAT and = SKEYSEED computations; stirring it into the KEYMAT implies that the = IPsec SAs are generated with QR-resistant keying material, while = stirring it into the SKEYSEED implies that any child IKE SAs implies = that any IKE SA (other than the initial one) also has QR-resistant = keying material.  This latter was done specifically so that an = implementation can have protected IKE SAs (by negotiating a child SA = immediately)
o   Dan Harkins = suggested that we modify only the KEYMAT.  This is a simpler = option, and will continue to protect the IPsec SAs; however this implies = that any data protected by the IKE SA could potentially be recovered by = a Quantum Computer.
o   Valery = Smyslov gave a suggestion that we instead stir in the PPK into the = initial SK_d; as all keying material is generated based on that, this = would also mean that IPsec SAs and any child IKE SAs are also = protected.  This also means that an implementation would not need = to remember the PPK after the initial negotiation.  The only = downside I can see is that we would have to be a bit careful about when = we update the SK_d (obviously, before we actually use = it).
To me, all three strike me as = reasonable ideas (unless we decide that we will need to protect the real = identity data encrypted via the IKE SA; in that case, Dan=92s idea = doesn=92t protect that).  Can I get opinions as to which strikes = the group as the best?  Are there any fourth options that people = would want to put on the table?
 
I = would like to see the preshared key used in a manner that protects the = IKE SA as well as the child SA.  I have a mild preference for the = third alternative over the first = one.
 
Actually, in terms of what IPsec/IKE traffic is = immune from recovery from an adversary with a Quantum Computer, the = first and third options are = identical.

I recognize = that.

I would like to see the preshared key = used in a manner that protects the IKE SA as well as the child SA, and = between the two alternatives that offer that, I have a mild preference = for the third = alternative.

Russ



= --Apple-Mail=_91C420E0-FEDE-4552-AC49-214AE1CFA4FD-- From nobody Fri Dec 9 08:32:49 2016 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 7017412940D; Fri, 9 Dec 2016 08:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fqpbo3h85UWc; Fri, 9 Dec 2016 08:32:42 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D54129485; Fri, 9 Dec 2016 08:32:41 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D0DCF25D387C; Fri, 9 Dec 2016 16:32:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 092FFD1F7EE; Fri, 9 Dec 2016 16:32:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id uWRbqjhMdrq7; Fri, 9 Dec 2016 16:32:37 +0000 (UTC) Received: from [10.248.108.210] (fresh-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4920:2ef0:eeff:fe03:ee34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C446FD1F7E3; Fri, 9 Dec 2016 16:32:35 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Bill Fenner" Date: Fri, 09 Dec 2016 16:32:34 +0000 Message-ID: In-Reply-To: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6069) Archived-At: Cc: ipsec@ietf.org, "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:32:44 -0000 On 9 Dec 2016, at 16:07, Bill Fenner wrote: > On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick > wrote: > >> Hi All, >> >> The sunset4 minutes suggest NAT64 SSID to become the default? >> >> Just checking, is there any summary on how VPN clients behaved on the >> nat64 SSID following the event? >> > > Just an anecdote, not actual information: I have two different ways to > contact my office VPN server (SSL VPN and IPSEC); neither one worked > from > NAT64. The vendor documentation says that they don't support IPv6 > transport for the SSL VPN; I do not know what went wrong with the > IPSEC > VPN. The vendor introduced support for IPSEC with v6 transport in > their > newest software, to which we'll upgrade soon; perhaps that upgrade > will > include whatever is required for it to work through NAT64 too. Their > support matrix still says that even the newest software does not > support > SSL VPN over IPv6. That’s maybe for the ipsec wg but while native IPv6 VPN has been working fine for me for ages, how would a NAT64 policy exchange actually look like (I am thinking about what is done for IPv4 NAT or double NAT within the same address family); I doubt that different AFs on each end as part of the policy are specified to work, so I’d not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 endpoint); someone surprise me and say with IKEv2 you can? Someone surprise me and say with a double NAT64 it can work? /bz From nobody Fri Dec 9 09:04:14 2016 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 294AF1298C3; Fri, 9 Dec 2016 09:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45ntKxN2R7hi; Fri, 9 Dec 2016 09:04:11 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) (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 905991298CE; Fri, 9 Dec 2016 09:03:42 -0800 (PST) Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id B4/53-23231-CE3EA485; Fri, 09 Dec 2016 17:03:40 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRWlGSWpSXmKPExsUy9d9HH903j70 iDF4+VLe4vszd4v2tPWwW+7e8YLNYuWc/uwOLR/v2b6weS5b8ZPLo/u8dwBzFmpmXlF+RwJrR sHc/U8E72Yq9PfOYGxj3yHYxcnEICWxhlLjbfY4NwjnAKNH+ZhKUc5xR4l3XL/YuRk4ONgFdi fZZq5i7GDk4RATCJY5+0QQJMwv4SKx9vosRxBYWsJDon7mYBcQWEbCUePZvOSuE7Scx+c1Jdp BWFgEViZWdxiBhXoFQiQvrp4JNFxI4yiQxd4sXiM0p4Cbxo+Um2BhGAVmJL42rmSFWiUvcejK fCcSWEBCQWLLnPDOELSrx8vE/VghbQeLSoi5WkFXMApoS63fpQ7QqSkzpfsgOsVZQ4uTMJywT GEVnIZk6C6FjFpKOWUg6FjCyrGLUKE4tKkst0jU00EsqykzPKMlNzMwB8oz1clOLixPTU3MSk 4r1kvNzNzECI6uegYFxB+O2LudDjJIcTEqivMVMXhFCfEn5KZUZicUZ8UWlOanFhxhlODiUJH i3PALKCRalpqdWpGXmAGMcJi3BwaMkwpsOkuYtLkjMLc5Mh0idYtTlOLZy7VMmIZa8/LxUKXH etSBFAiBFGaV5cCNg6eYSo6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWFeB5ApPJl5JXCbXgEd wQR0xLwb7iBHlCQipKQaGJuve11n//T+o4RmSe6xmWlzo5l+u0T9vBulJzxV4E+EU8vOPR3BT MuaHsp46riYHgq9OONHyK4JmRW/98uqZv7vLbx9c9qC2VvVZ+i931gfoDlDW2Oy9ss3F7KUbs Y1brlre+TzfH8d56sZvZ93Nb74unjHmhOmBrGyT+fNcO7f6n7Rfrar+CElluKMREMt5qLiRAD PA3vsMgMAAA== X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-6.tower-31.messagelabs.com!1481303020!49023496!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 9.0.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 41616 invoked from network); 9 Dec 2016 17:03:40 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Dec 2016 17:03:40 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with Trustwave SEG (v7, 5, 6, 8438) id ; Fri, 09 Dec 2016 17:03:33 +0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Fri, 09 Dec 2016 17:03:39 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0279.002; Fri, 9 Dec 2016 17:03:39 +0000 From: "Heatley, Nick" To: "Bjoern A. Zeeb" , Bill Fenner Thread-Topic: [sunset4] ietf-nat64 - Internet VPN clients Thread-Index: AdI/6iAEvrsPebvKTxeJBoeibdeeOgA+3NGABE2iavAABo1YgAAA4XQAAADgjeA= Date: Fri, 9 Dec 2016 17:03:38 +0000 Message-ID: <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:04:13 -0000 SXQgaXMganVzdCB0aGUgc2luZ2xlIE5BVDY0IHRoYXQgaXMgaW4gcXVlc3Rpb24gKEkgYWxzbyB0 ZW5kIHRvIHRoaW5rIHRoYXQgaXMgYnJva2VuIGZvciBJUHNlYyBjbGllbnRzPykuDQoNClBvcHVs YXIgSVBzZWMgY2xpZW50cyB3b3JrIHBlcmZlY3RseSB2aWEgNDY0eGxhdCAoZG91YmxlIE5BVDY0 KS4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzdW5zZXQ0IFttYWls dG86c3Vuc2V0NC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmpvZXJuIEEuIFplZWIN ClNlbnQ6IDA5IERlY2VtYmVyIDIwMTYgMTY6MzMNClRvOiBCaWxsIEZlbm5lcg0KQ2M6IGlwc2Vj QGlldGYub3JnOyBzdW5zZXQ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N1bnNldDRdIGlldGYt bmF0NjQgLSBJbnRlcm5ldCBWUE4gY2xpZW50cw0KDQpPbiA5IERlYyAyMDE2LCBhdCAxNjowNywg QmlsbCBGZW5uZXIgd3JvdGU6DQoNCj4gT24gRnJpLCBEZWMgOSwgMjAxNiBhdCA4OjQxIEFNLCBI ZWF0bGV5LCBOaWNrIDxuaWNrLmhlYXRsZXlAZWUuY28udWs+DQo+IHdyb3RlOg0KPg0KPj4gSGkg QWxsLA0KPj4NCj4+IFRoZSBzdW5zZXQ0IG1pbnV0ZXMgc3VnZ2VzdCBOQVQ2NCBTU0lEIHRvIGJl Y29tZSB0aGUgZGVmYXVsdD8NCj4+DQo+PiBKdXN0IGNoZWNraW5nLCBpcyB0aGVyZSBhbnkgc3Vt bWFyeSBvbiBob3cgVlBOIGNsaWVudHMgYmVoYXZlZCBvbiB0aGUNCj4+IG5hdDY0IFNTSUQgZm9s bG93aW5nIHRoZSBldmVudD8NCj4+DQo+DQo+IEp1c3QgYW4gYW5lY2RvdGUsIG5vdCBhY3R1YWwg aW5mb3JtYXRpb246IEkgaGF2ZSB0d28gZGlmZmVyZW50IHdheXMgdG8gDQo+IGNvbnRhY3QgbXkg b2ZmaWNlIFZQTiBzZXJ2ZXIgKFNTTCBWUE4gYW5kIElQU0VDKTsgbmVpdGhlciBvbmUgd29ya2Vk IA0KPiBmcm9tIE5BVDY0LiAgVGhlIHZlbmRvciBkb2N1bWVudGF0aW9uIHNheXMgdGhhdCB0aGV5 IGRvbid0IHN1cHBvcnQgDQo+IElQdjYgdHJhbnNwb3J0IGZvciB0aGUgU1NMIFZQTjsgSSBkbyBu b3Qga25vdyB3aGF0IHdlbnQgd3Jvbmcgd2l0aCB0aGUgDQo+IElQU0VDIFZQTi4gIFRoZSB2ZW5k b3IgaW50cm9kdWNlZCBzdXBwb3J0IGZvciBJUFNFQyB3aXRoIHY2IHRyYW5zcG9ydCANCj4gaW4g dGhlaXIgbmV3ZXN0IHNvZnR3YXJlLCB0byB3aGljaCB3ZSdsbCB1cGdyYWRlIHNvb247IHBlcmhh cHMgdGhhdCANCj4gdXBncmFkZSB3aWxsIGluY2x1ZGUgd2hhdGV2ZXIgaXMgcmVxdWlyZWQgZm9y IGl0IHRvIHdvcmsgdGhyb3VnaCBOQVQ2NCANCj4gdG9vLiAgVGhlaXIgc3VwcG9ydCBtYXRyaXgg c3RpbGwgc2F5cyB0aGF0IGV2ZW4gdGhlIG5ld2VzdCBzb2Z0d2FyZSANCj4gZG9lcyBub3Qgc3Vw cG9ydCBTU0wgVlBOIG92ZXIgSVB2Ni4NCg0KVGhhdOKAmXMgbWF5YmUgZm9yIHRoZSBpcHNlYyB3 ZyBidXQgd2hpbGUgbmF0aXZlIElQdjYgVlBOIGhhcyBiZWVuIHdvcmtpbmcgZmluZSBmb3IgbWUg Zm9yIGFnZXMsIGhvdyB3b3VsZCBhIE5BVDY0IHBvbGljeSBleGNoYW5nZSBhY3R1YWxseSBsb29r IGxpa2UgKEkgYW0gdGhpbmtpbmcgYWJvdXQgd2hhdCBpcyBkb25lIGZvciBJUHY0IE5BVCBvciBk b3VibGUgTkFUIHdpdGhpbiB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSk7ICBJIGRvdWJ0IHRoYXQg ZGlmZmVyZW50IEFGcyBvbiBlYWNoIGVuZCBhcyBwYXJ0IG9mIHRoZSBwb2xpY3kgYXJlIHNwZWNp ZmllZCB0byB3b3JrLCBzbyBJ4oCZZCBub3QgZXhwZWN0IElQc2VjIFZQTnMgdG8gd29yayBhY3Jv c3MgYSBOQVQ2NCAoZnJvbSBhIHY2IHRvIGEgdjQgZW5kcG9pbnQpOyAgc29tZW9uZSBzdXJwcmlz ZSBtZSBhbmQgc2F5IHdpdGggSUtFdjIgeW91IGNhbj8gIFNvbWVvbmUgc3VycHJpc2UgbWUgYW5k IHNheSB3aXRoIGEgZG91YmxlIE5BVDY0IGl0IGNhbiB3b3JrPw0KDQovYnoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN1bnNldDQgbWFpbGluZyBs aXN0DQpzdW5zZXQ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N1bnNldDQNCg0KTk9USUNFIEFORCBESVNDTEFJTUVSDQpUaGlzIGVtYWlsIGNvbnRhaW5z IEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwu IEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiANCklmIHlvdSdyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRp c2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9u IGlzIHByb2hpYml0ZWQuIA0KSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92 ZS4gVGhhbmsgeW91Lg0KDQpXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVj b3JkIHlvdXIgZW1haWxzLg0KDQpFRSBMaW1pdGVkIA0KUmVnaXN0ZXJlZCBvZmZpY2U6VHJpZGVu dCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMDIzODIxNjENCg0KRUUgTGltaXRlZCBpcyBhIHdo b2xseSBvd25lZCBzdWJzaWRpYXJ5IG9mOg0KDQpCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBw bGMNClJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUoN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAwMA0K From nobody Fri Dec 9 09:30:35 2016 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 4196E12997C; Fri, 9 Dec 2016 09:30:35 -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, 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 X8OR0CfG09Ci; Fri, 9 Dec 2016 09:30:33 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 57E7012996A; Fri, 9 Dec 2016 09:30:33 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id a20so5092915wme.2; Fri, 09 Dec 2016 09:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t/PSCh/WjPM6TghgeQvOddsSnWAMMROks+rIVvkLQOw=; b=i3ccMloq7cgeIA0WBlbzWUQJYlmrS+mjUAJ9iXHhCZrdHvjC1I8+JxG0PY3OQY3x7b 2WKU3hECTB9t0q4fjNMxVAHF7IQJKbzkgBUQCYhYtd4QXula7jkfBORfRUGZieUQWd4O PyOsSLGIuzLr5HoIBY882dlAE7qSX6o9M0qWmKOrTeCKwRLgvPZG24uiZ0d+1Jf9zFmy Haa6FrgS06sahMKhEsNA0knhIFWTkVaHPNCc77p6rKMlidEcBp96HZbCFmuRmZXOpfMX 6lOVY9rQ0p9lcgkwrkCFw0AG7Y1IwTqz8k/S8ASMxwpgAD+wyczKBgDfAenDEeiZfKjS 4q7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t/PSCh/WjPM6TghgeQvOddsSnWAMMROks+rIVvkLQOw=; b=CDSLQ3Ge+FQNU5VvHpseF8nujyB/mcC3BOx8kBamlgQYsH1tEAbeuz4Fk2z9qz1fDO F5VN3Vn0VkpZF+ralxEMaR08UXkflZhjw17Pl1tlNVRVuLFLlE90hgecMGbgBevJTNmt WvnyYrG1aRT8zIbJ4wFmOP7FeqAX7ZSZBx420jM+5sN5U9YhVWsPYKG/jXKWYJ0WOEdC ar67/Ie1Iu+quD47FCPYDzmHJ9ltgOGkzHx7BRWtva9n0p8vDbHGEGYAoS2+eSXdlMS/ bGGpeeFlkEqdldnqgyeG2I9gCcnjmNvyx3hx0oFi3mlz6OWTJs2bBsDXBaeBW72Jt50P QY/Q== X-Gm-Message-State: AKaTC014gmSRNTkHBkDT40kk9XGGZedmSou8frmpvWE0U+7n6d6OCuqv3Vko+FxlRxR5SA== X-Received: by 10.28.26.80 with SMTP id a77mr7523929wma.31.1481304631797; Fri, 09 Dec 2016 09:30:31 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id a13sm21653096wma.18.2016.12.09.09.30.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 09:30:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Fri, 9 Dec 2016 19:30:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: ipsec@ietf.org, Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:30:35 -0000 > On 9 Dec 2016, at 18:32, Bjoern A. Zeeb = wrote: >=20 > On 9 Dec 2016, at 16:07, Bill Fenner wrote: >=20 >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick = wrote: >>=20 >>> Hi All, >>>=20 >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>>=20 >>> Just checking, is there any summary on how VPN clients behaved on = the >>> nat64 SSID following the event? >>>=20 >>=20 >> Just an anecdote, not actual information: I have two different ways = to >> contact my office VPN server (SSL VPN and IPSEC); neither one worked = from >> NAT64. The vendor documentation says that they don't support IPv6 >> transport for the SSL VPN; I do not know what went wrong with the = IPSEC >> VPN. The vendor introduced support for IPSEC with v6 transport in = their >> newest software, to which we'll upgrade soon; perhaps that upgrade = will >> include whatever is required for it to work through NAT64 too. Their >> support matrix still says that even the newest software does not = support >> SSL VPN over IPv6. >=20 > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has = been working fine for me for ages, how would a NAT64 policy exchange = actually look like (I am thinking about what is done for IPv4 NAT or = double NAT within the same address family); I doubt that different AFs = on each end as part of the policy are specified to work, so I=E2=80=99d = not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 = endpoint); someone surprise me and say with IKEv2 you can? Someone = surprise me and say with a double NAT64 it can work? Regardless of IKE version, an IPsec client (and SSL-VPN client as well) = will encapsulate the v6 packet within the tunnel. The internal v6 packet = will never reach the NAT in any form that the NAT can do anything about. The encapsulating packet (for IPsec) or stream (for SSL) will get = translated correctly by the NAT64, but when the other side decrypts the = packet, it=E2=80=99s going to be an IPv6 packet. The problem is the = destination address, which is the NAT64 address invented by the DNS64. = The tunnel endpoint will not know how to deal with that. To get this working, the DNS64 should be on the remote tunnel endpoint = or behind it. And this will require that it has an IPv6 address and = knows to do the NAT64 translation in cooperation with the tunnel = endpoint. I guess this vendor=E2=80=99s IPsec implementation doesn=E2=80=99= t do all that. Neither does my employer=E2=80=99s. Yoav From nobody Fri Dec 9 09:32:47 2016 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 6F4AE1296F0 for ; Fri, 9 Dec 2016 09:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 81EtAa___gMJ for ; Fri, 9 Dec 2016 09:32:41 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 E586D1295AC for ; Fri, 9 Dec 2016 09:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481304761; 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=Wbr0kzvitGcbqBd4bAblE60J8P63KX6/qn/lxDVFjU0=; b=HoXVX10gemaJHLcCdUP2TM6pChu8SHudCmFmd7Sei2NnoZzvct915WMOThVRTQ8o skOafm48dN4jN1HNdnERImipd1MSWQsyjkxB0LcsiYaqpP4FFzG90NSvG+BImYns nKaWuOfsWXCKR8dN/tTTX5+rGnH1DOo4bmbrvjZ6ufFV8eXJQ9E13h9EQSpcZFkn BCQnxIJSRgZp5xiCnTX5ahK4uJVET+Ib6MwV55m8NQk+NoPgfZwtjI0YCelXxGvW 9iFGlTLWsJ71ae5NXHJJmsPBr22pNUsw+cegLq7aJnpOG/tRk/nsiz8L6AhRoKJd 3Q9YiuIFY8l33eU5InwLIA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B7.8E.19113.9BAEA485; Fri, 9 Dec 2016 09:32:41 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-05-584aeab99168 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 59.EF.23613.9BAEA485; Fri, 9 Dec 2016 09:32:41 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHX0026NI2H6V40@nwk-mmpp-sz07.apple.com>; Fri, 09 Dec 2016 09:32:41 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Fri, 09 Dec 2016 09:32:41 -0800 Content-transfer-encoding: quoted-printable Message-id: <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> To: "Heatley, Nick" X-Mailer: Apple Mail (2.3300) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FAYpbvzlVeEQft/A4vry9wt3t/aw2ax f8sLNotnXyezWazcs5/dgdXj4hMTj/bt31g9liz5yeTR/d87gCWKyyYlNSezLLVI3y6BK+PS 8vSCr/IVp/epNzA+kuxi5OSQEDCRmLfxKnMXIxeHkMBeRonms7NYuxg5wBJr/mlDxA8xStz6 +JkJpIFXQFDix+R7LCA1zALqElOm5ELUdDBJrN5xiQkkLiwgIbF5TyJIubCAg0TbkbusIDab gIrE8W8bmEFsToEIiTmHesFGsgioSiycvIIVZA6zwBJGiaM3VrGDJJgFtCWevLvACrHXRmLr uzPsEMumM0vcOv4DLCECVNQ85xcjxDeyEodPPmUDKZIQuM4m0fZpJdMERuFZSA6fhXD4LCQ7 FjAyr2IUyk3MzNHNzDPXSywoyEnVS87P3cQIioHpdmI7GB+usjrEKMDBqMTD63DIK0KINbGs uDL3EKM0B4uSOG/sF88IIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYynNXKs9lXkO1xx2lj9 +9OLWX5x/8+2mE65f/zdxxxpl+mCHsZfjkt37xY3LfJKqn1/qojj/cKCPd9u/0rItVgXEK// Oq6tP1xMqfguf9SvP/f+eM6dGPMkobHF1zxYfP6Tu3N/zjf2PJqmuVu9/Izh0XI7Vuljhjdu 3rv6NPnjmsbH6S136l8psRRnJBpqMRcVJwIAclmMymICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUi2FD8QXfnK68Ig/tTdSyuL3O3eH9rD5vF /i0v2CyefZ3MZrFyz352B1aPi09MPNq3f2P1WLLkJ5NH93/vAJYoLpuU1JzMstQifbsEroxL y9MLvspXnN6n3sD4SLKLkYNDQsBEYs0/7S5GTiBTTOLCvfVsXYxcHEIChxglbn38zASS4BUQ lPgx+R4LSD2zgLrElCm5EDUdTBKrd1xiAokLC0hIbN6TCFIuLOAg0XbkLiuIzSagInH82wZm EJtTIEJizqFesJEsAqoSCyevYAWZwyywhFHi6I1V7CAJZgFtiSfvLrBC7LWR2PruDDvEsunM EreO/wBLiAAVNc/5xQhxtazE4ZNP2SYwCs5CcusshFtnIRm7gJF5FaNAUWpOYqWZXmJBQU6q XnJ+7iZGcCgXRu1gbFhudYhRgINRiYfX4ZBXhBBrYllxZS4wMDiYlUR4Dz0HCvGmJFZWpRbl xxeV5qQWH2JMBvpmIrOUaHI+MM7ySuINTUwMTIyNzYyNzU3MSRNWEudNWugRISSQnliSmp2a WpBaBLOFiYNTqoGRs1FFXG5twLW7N9z3R598eHZZypYYDZEPXvGB6r9KU1XaVXff5Pbkz1xz i7Vjqosne9bZkLKIWZ3zj+11ad44yfysw4bdpaf/ZTHEs2cytrEndDR5vZj9922C4UXrmodC nXIuCs8nFj8QtZ8rff1w3M2Cj78LVtmKiO/lcV2Rl+DsXfChukuJpTgj0VCLuag4EQCe7Oza qQIAAA== Archived-At: Cc: "ipsec@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:32:44 -0000 With our push to support NAT64 networks (without 464xlat) for Apple's = devices, we added support for NAT64 networks to both our IKEv1 and IKEv2 = clients a few releases ago. It was a fairly straightforward change. The = main parts are making sure any IPv4 literals meant to be use outside the = tunnel that come across in the IKE exchange are synthesized into IPv6 = addresses; and making sure that the ESP layer is happy encapsulating = IPv4 in IPv6 for tunnels. Historically, many implementations only = supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4. =46rom an interop perspective, this is just a change that needs to be = made on the client behind the NAT64, and requires no protocol changes in = IKE or knowledge on the server side. Thanks, Tommy Pauly > On Dec 9, 2016, at 9:03 AM, Heatley, Nick = wrote: >=20 > It is just the single NAT64 that is in question (I also tend to think = that is broken for IPsec clients?). >=20 > Popular IPsec clients work perfectly via 464xlat (double NAT64). >=20 >=20 >=20 > -----Original Message----- > From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Bjoern A. = Zeeb > Sent: 09 December 2016 16:33 > To: Bill Fenner > Cc: ipsec@ietf.org; sunset4@ietf.org > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients >=20 > On 9 Dec 2016, at 16:07, Bill Fenner wrote: >=20 >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick >> wrote: >>=20 >>> Hi All, >>>=20 >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>>=20 >>> Just checking, is there any summary on how VPN clients behaved on = the >>> nat64 SSID following the event? >>>=20 >>=20 >> Just an anecdote, not actual information: I have two different ways = to=20 >> contact my office VPN server (SSL VPN and IPSEC); neither one worked=20= >> from NAT64. The vendor documentation says that they don't support=20 >> IPv6 transport for the SSL VPN; I do not know what went wrong with = the=20 >> IPSEC VPN. The vendor introduced support for IPSEC with v6 transport=20= >> in their newest software, to which we'll upgrade soon; perhaps that=20= >> upgrade will include whatever is required for it to work through = NAT64=20 >> too. Their support matrix still says that even the newest software=20= >> does not support SSL VPN over IPv6. >=20 > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has = been working fine for me for ages, how would a NAT64 policy exchange = actually look like (I am thinking about what is done for IPv4 NAT or = double NAT within the same address family); I doubt that different AFs = on each end as part of the policy are specified to work, so I=E2=80=99d = not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 = endpoint); someone surprise me and say with IKEv2 you can? Someone = surprise me and say with a double NAT64 it can work? >=20 > /bz >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >=20 > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above.=20 > If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.=20 > If you've received this email in error, please let me know immediately = on the email address above. Thank you. >=20 > We monitor our email system, and may record your emails. >=20 > EE Limited=20 > Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW > Registered in England no: 02382161 >=20 > EE Limited is a wholly owned subsidiary of: >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Dec 9 10:33:45 2016 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 800231294F1 for ; Fri, 9 Dec 2016 10:33:43 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqEARRAS5Gav for ; Fri, 9 Dec 2016 10:33:41 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 B3CC1129988 for ; Fri, 9 Dec 2016 10:33:32 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id x186so12960399vkd.1 for ; Fri, 09 Dec 2016 10:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=EzGEOd7VSo11lJOsqrulzkX2o7E/0LzDTP+P5/wPTLY=; b=hD1ktK182nMsO1WIrjLL9yHfGVmU7OnbFk26+ivz+x2l43Al/4sdarCoGtgkBtzbXu c//ouWVMqt707YaKaHAsxO1RkadtfThH/8EzWB0C7EC0Ke224NNHQ8GsJ7c+3b3yo2XT WhKcW/0z2gawt95eL5vQwJiqB5Ofm3Ox4IPbexPhLeOPjPaLfQYwpqcMfrkxb3OEdQdl yehvo1BwZ1etixNfUGPkuYdXa4vn1nIpfEmhdCZ7/0mymHhe2/6p60Kc0VMHDfwCVe1q oFR66JNEgbzVA17qN1DBdRjWEF2+dxiPbz3nRDPaLo5Zr1w5izYvVyt6M+rQDB8rQKhl NGaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EzGEOd7VSo11lJOsqrulzkX2o7E/0LzDTP+P5/wPTLY=; b=T9AE3bNFuJQq7APlYY+s8V1hHeIG/e0d2VYauFEFb2hlzlbRa/PWd+BYH9kWHMSRFi oqPL4DjNE7TQnmXq2jQ5c8/2lL97wQe9yaDFt6tZZkVUWHTM0DXpHXyqX5cHesANWUQO tx1sEl5bVI9NhBjvIzyQO+HWOFMcSWupmaa7EINjc1DGGLguSyKQmp9CQWCXYJhyvsxG pQAhl/IGMsJ0ii9YWOS9dKGfhgzfQAQIXQVmc4vIIvmK8gYtjDqywchGX/VEDKL0RG4R N6u0EQZg9p2ZkWGFz5EdrkWtfbktUuTbaDXLIbPnaO56mpEeh9haAFMe0qv+7Yrc4gWv PC3w== X-Gm-Message-State: AKaTC026C6YUl5RyDUrJMXPQMInSanyB7ePZOBSiXPgo8ohohTcTGjchwaq8ZWTA5psu+Q9fq8Xe6VeGBkMIjA== X-Received: by 10.31.32.213 with SMTP id g204mr32334054vkg.152.1481308411589; Fri, 09 Dec 2016 10:33:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.82.232 with HTTP; Fri, 9 Dec 2016 10:33:31 -0800 (PST) From: Kathleen Moriarty Date: Fri, 9 Dec 2016 13:33:31 -0500 Message-ID: To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11c01c36acf93205433dfd61 Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 18:33:43 -0000 --001a11c01c36acf93205433dfd61 Content-Type: text/plain; charset=UTF-8 Hello, Thanks for your work on draft-ietf-ipsecme-rfc4307bis. I reviewed the draft and just have a few questions, the first is a nit. Nit: In the second paragraph of 1.3, you can drop the last two words of this sentence as they are redundant: This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations. In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD or SHOULD- for: PRF_HMAC_SHA1 | MUST- | | AUTH_HMAC_SHA1_96 | MUST- The justifications seems like a bigger jump would be appropriate. Thank you! -- Best regards, Kathleen --001a11c01c36acf93205433dfd61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for your work on draft-ie= tf-ipsecme-rfc4307bis.=C2=A0 I reviewed the draft and just have a few quest= ions, the first is a nit.


Nit:
= In the second paragraph of 1.3, you can drop the last two words of this sen= tence as they are redundant:
   This doc=
ument does not give any recommendations for the use of
   algorithms, it only gives implementation recommendations for
   implementations.


In section 3.2 = & 3.3, why isn't there a bigger jump down to SHOULD or SHOULD- for:= 
PRF_HMAC_SHA=
1     | MUST-    |
| AUTH_HMAC_SHA1_96 =
     | MUST-
The justifications seems like a bigger jump = would be appropriate.


Thank you!
--

Best= regards,
Kathleen
--001a11c01c36acf93205433dfd61-- From nobody Fri Dec 9 13:39:17 2016 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 E87E61294AB; Fri, 9 Dec 2016 13:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 Ke7-im_wSpnE; Fri, 9 Dec 2016 13:39:14 -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 32C9C129541; Fri, 9 Dec 2016 13:39:13 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F352E007; Fri, 9 Dec 2016 16:56:46 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4C8563782; Fri, 9 Dec 2016 16:39:11 -0500 (EST) From: Michael Richardson To: "Bjoern A. Zeeb" In-Reply-To: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: ipsec@ietf.org, Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:39:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bjoern A. Zeeb wrote: > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has b= een working fine > for me for ages, how would a NAT64 policy exchange actually look like= (I am > thinking about what is done for IPv4 NAT or double NAT within the same NAT64 depends upon DNS64 to provide a fake IPv6 target for the application = to connect to. So, for IPsec to work over NAT64 would require: 1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6). 2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so that it can be lied to about the returned AAAA record. In Bill's case, he hasn't got (1), so it's not going to work. Once he has (1) (the upgrade he mentioned), if his policy lets him use DNS = to find his gateway, and he doesn't do DNSSEC on that, then it ought to work. Of course, once he has the upgrade, if his gateway would just have an IPv6, he wouldn't need NAT64. And he can tunnel his company 10.x v4 network over things as much as he likes... but there is the question about where his Internet bound v4 traffic will go... likely if his company's VPN wants to inspect his traffic, the v4 will go through the tunnel, not using the NAT64 at all, and causing him higher latency. But, that's what would happen in a pure v4 situation anyway. > address family); I doubt that different AFs on each end as part of t= he > policy are specified to work, so I=E2=80=99d not expect IPsec VPNs to= work across a > NAT64 (from a v6 to a v4 endpoint); someone surprise me and say with= IKEv2 > you can? Someone surprise me and say with a double NAT64 it can work? I'm not sure IKEv2 even knows or cares how the port-500 packets get there. I use v6 over X tunnels (where X is usually v4) in order to get v6 to my laptop from coffee shops regularly. I haven't tried this over NAT64, but I will change this to use DNS. Of course, I wouldn't need this tunnel in a NAT64 network, since I'd have v6, so I'll setup some v4 IPsec too for the next IETF and try it out. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhLJH8ACgkQgItw+93Q 3WX0pggAt//dqVBJw1I2UDRct44iMOI/k2tZjlk1j2CKC4zvH0dWcjzFhQt6/Pv6 CbvN3p01vBVZk+6G+TjE6T0qd8EdR9plIzEPJAOlvMW+DrQN5tRQEebRxHXc3jHS ynVVNQHkK5Qwu5uHJsNiSuECdqLeAg1Lkant9Uc4VUbiY/OthToOFCydniDODnjm v0R5pEsX/G5eYp74J4aFO0hMPActElIU5mE6KXbk7GtbiOiIc/ecmJoWdYUEhrVA hfaUvJqEr6HbNJ8/kQRb5d2LrBpdA+lgpQV4W92hO3vajPiyth62B6H/tkkEjbBS W7Rw36vhQEPOIt+W3PAvROTeS0iDIA== =StiN -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 9 13:43:09 2016 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 C555212957E; Fri, 9 Dec 2016 13:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 jFF6jG7gG1n0; Fri, 9 Dec 2016 13:43:07 -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 6F27012955D; Fri, 9 Dec 2016 13:43:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 733D0E1AB; Fri, 9 Dec 2016 17:00:41 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA76563782; Fri, 9 Dec 2016 16:43:06 -0500 (EST) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: ipsec@ietf.org, "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:43:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > To get this working, the DNS64 should be on the remote tunnel endpoint > or behind it. And this will require that it has an IPv6 address and > knows to do the NAT64 translation in cooperation with the tunnel > endpoint. I guess this vendor=E2=80=99s IPsec implementation doesn=E2= =80=99t do all > that. Neither does my employer=E2=80=99s. So, I think that you are saying that if the client does DNS through the tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess peop= le need to do DNS through the tunnel because of needing to resolv internal addresses. It's the whole MIF/split-horizon DNS problem, and I think it's all a bad IPv4-specific idea, and we should be trying to kill it. In an IPv6 world, we have better ways to build walled gardens. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhLJWoACgkQgItw+93Q 3WUovwgAukHN4r4g0GerYHIg/KN0T/iAiZ7GwFYofCfoHmeIANQ6ZUoHCf7OraWl GBD2PH7BEBtgINqdc0VbuJaWMVolzZUes1gUBcBGAa6vpgnLzdpJPLpRXU1703Kn 1LxUN3jWddAc+IR1AdtgLBbxXdZmhrs685GUOWsYPyegi+OtWCZ3s3kW/mYHbePX Hm2J27q2vh0qSK0bw3MGV+mKR0wJEDsyp9E5TTWfWYTizuaQ4vKRvenzU0fmmsdV TIgeH1SVKbLMesjjaNi7rCfSsfhWr5PuehQ+ib6WGd9SSDPIXM12dNNQ3Fly08bs wdnuqlWL6iU9jdW+/CReiWgbUjLAtg== =kqOh -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 9 13:46:58 2016 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 45BCD12955D for ; Fri, 9 Dec 2016 13:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 QRAB33-tswyq for ; Fri, 9 Dec 2016 13:46:55 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 BF8BC129584 for ; Fri, 9 Dec 2016 13:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481320007; 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=1a7Z5PD0cnx01wQ21mttSiYGscHj/b6Ij/Jysy7P54U=; b=aDMKKucRJvxJiP3Ycl1BoUndraRhhRJy0zCxpAz8VXMFJVcK97GH9DMV82CSXi0c tt682p4S0A2dYQ2i2BdVfopDr5Bd41cohn07nuHPKP3ChNJCPUe86JOnHghvhLow 0uB8hiQ4fiUd5mPeQtcOZdtVzEr/B37+bJlHu6xMN+KNVC92m80bbvvQJWEeBX/p pmbTX3lxCVBVr27F3c34XOJj5H283SQQshaBQHmBUUKza4WpV7LtFRrP6NR5083l OXb7AR5aAc0uXxtzgYn0kD0nkVDwVX40kHDbZ5EOhcicPOXp/pc+qanZXIJvcFRs tuOzX5WNngOrcMqIHgIuiw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 02.8E.19113.7462B485; Fri, 9 Dec 2016 13:46:47 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-db-584b264729c6 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 7E.56.23613.7462B485; Fri, 9 Dec 2016 13:46:47 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHX00EFETTZSH00@nwk-mmpp-sz07.apple.com>; Fri, 09 Dec 2016 13:46:47 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <7107.1481319786@obiwan.sandelman.ca> Date: Fri, 09 Dec 2016 13:46:46 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <7107.1481319786@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3300) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYpeuu5h1h8P++usX1Ze4W72/tYbPY v+UFm0XPoX52i5V79rNbLD32gcmBzaN9+zdWj52z7rJ7LFnyk8mj+7+3R8ucPcwBrFFcNimp OZllqUX6dglcGV82rmEreMNbcaaphbGBsYe7i5GDQ0LARGLDZq4uRi4OIYG9jBI3pl1j7mLk BIsfmfKZGSJxiFGi61o7WIJXQFDix+R7LCDNzALqElOm5ELUdDBJfLjxmxkkLiwgIbF5TyJI ubCAg0TbkbusIDabgIrE8W8bwMZwChhJdJ/bDmazCKhKtM1azQhiMwtsZJQ4diQKwtaWePLu AivEWhuJ1k2bWSF2LWOW2Ni6mwUkISKgJ7H8yDNGiKNlJQ6ffMoGUiQh8JhN4sXN08wTGIVn Ibl7FsLds5DsWMDIvIpRKDcxM0c3M89cL7GgICdVLzk/dxMjKDam24ntYHy4yuoQowAHoxIP r8Mhrwgh1sSy4srcQ4zSHCxK4rxTPgCFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MCYd8F5o 4eR0qK/uz/actXMNj908+pN/0pt1zpzq+QdXTzY5kM9Y4FnQxPZkgtv3DTnqtU1V9S/3MDo1 nr/p/Wy7bGQ6S5Fx7M1LySrGi6vi/559JyDZePJNzOpJzSHlx+z2364vvGl86//n3KZjD3QX ybluTbKXMud77SSsktsk901obXbVHiWW4oxEQy3mouJEABnd0MxuAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUi2FD8QdddzTvCYPpRRYvry9wt3t/aw2ax f8sLNoueQ/3sFiv37Ge3WHrsA5MDm0f79m+sHjtn3WX3WLLkJ5NH939vj5Y5e5gDWKO4bFJS czLLUov07RK4Mr5sXMNW8Ia34kxTC2MDYw93FyMnh4SAicSRKZ+ZIWwxiQv31rN1MXJxCAkc YpToutYOluAVEJT4MfkeSxcjBwezgLrElCm5EDUdTBIfbvxmBokLC0hIbN6TCFIuLOAg0Xbk LiuIzSagInH82wawMZwCRhLd57aD2SwCqhJts1YzgtjMAhsZJY4diYKwtSWevLvACrHWRqJ1 02ZWiF3LmCU2tu5mAUmICOhJLD/yjBHiaFmJwyefsk1gFJyF5NRZCKfOQjJ2ASPzKkaBotSc xEozvcSCgpxUveT83E2M4CAvjNrB2LDc6hCjAAejEg+vwyGvCCHWxLLiylxgWHAwK4nwPlDx jhDiTUmsrEotyo8vKs1JLT7EmAz0zERmKdHkfGAE5pXEG5qYGJgYG5sZG5ubmJMmrCTOqysP tEIgPbEkNTs1tSC1CGYLEwenVAMjQ6BBY4TgtVOrZbZu2cu4+9LJjwu+JfScN83XnLLa6V6r 3qJdz06duzlB4Z/YPCPNKKFPTW9EFA1XSc1KiFh42j2u8vqER4u6NPcuesqQdLNQt+RZWPeF tN1LhLxMQl5V3FSc0vbop0Z2mJuMQV299DPZIy9/veXYFPt6kt/iLxLfNqSqRK7wV2Ipzkg0 1GIuKk4EAASdUqS2AgAA Archived-At: Cc: ipsec@ietf.org, "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" , Yoav Nir Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:46:57 -0000 > On Dec 9, 2016, at 1:43 PM, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel = endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation in cooperation with the tunnel >> endpoint. I guess this vendor=E2=80=99s IPsec implementation = doesn=E2=80=99t do all >> that. Neither does my employer=E2=80=99s. >=20 > So, I think that you are saying that if the client does DNS through = the > tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess = people > need to do DNS through the tunnel because of needing to resolv = internal > addresses. It's the whole MIF/split-horizon DNS problem, and I think = it's > all a bad IPv4-specific idea, and we should be trying to kill it. The VPN's DNS should never have to know about DNS64 or support it. The = client can solve the issue independently=E2=80=94don't add it at the = server end! If I have a IPv4-only split-tunnel VPN over a NAT64 network, with DNS = configured such that some hostnames that need to get routed outside the = VPN are resolved only inside the VPN (and thus only get A records), the = client can take the IPv4 literal result and synthesize the correct IPv6 = address using the prefix of the NAT64 network. Thanks, Tommy >=20 > In an IPv6 world, we have better ways to build walled gardens. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Dec 9 14:06:24 2016 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 1865A129531; Fri, 9 Dec 2016 14:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZrRuZ7UDyQP; Fri, 9 Dec 2016 14:06:20 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.105]) (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 D2F5012950C; Fri, 9 Dec 2016 14:06:19 -0800 (PST) Received: from [85.158.143.35] by server-1.bemta-6.messagelabs.com id 58/F5-22836-9DA2B485; Fri, 09 Dec 2016 22:06:17 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRWlGSWpSXmKPExsUy9d9HH90bWt4 RBtNvmVpcX+Zu8f7WHjaL/VtesFms3LOf3WLiiYOsDqweW0/+YPNo3/6N1WPJkp9MHt3/vQNY olgz85LyKxJYM44tbGEqOBBfcenbXsYGxpWBXYxcHEICWxgl9j9vZYRwDjBK/L2znxnCOc4os XHuVJYuRk4ONgFdifZZq5hBbBEBJYmOlZvBipgFFjFKNM85DVYkLOAg0XbkLitEkaPEx6frGS HsKIljV9+zgdgsAioSGzbsAavhFXCT+LLtB9S2g8wSuzumM4EkOAVsJf6sfwI2lFFAVuJL42q wzcwC4hJNX1aCNUsICEgs2XOeGcIWlXj5+B8rRE22xPpDHxkhFghKnJz5hGUCo/AsJO2zkJTN QlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4zI4gsY2VcxahSnFpWlFukaWeglFWWmZ5TkJmbm6 BoamOnlphYXJ6an5iQmFesl5+duYgRGJAMQ7GA8vzbwEKMkB5OSKG8xk1eEEF9SfkplRmJxRn xRaU5q8SFGGQ4OJQnevZreEUKCRanpqRVpmTnA1ACTluDgURLhvQ6S5i0uSMwtzkyHSJ1i1OU 4tnLtUyYhlrz8vFQpcd6TIEUCIEUZpXlwI2Bp6hKjrJQwLyPQUUI8BalFuZklqPKvGMU5GJWE eaWBSU+IJzOvBG7TK6AjmICOmHfDHeSIkkSElFQD4zTmdIunbXkzrp5dG2m7fzXDskKmmQkX3 eef8K0V/Jwm6y7DmvVnStuiAmNzofPF3/jvRPK3fp2/65pYXL5E0ckFd9dN7U3o7w9etfx3tG TA+uINh2bOXXx53VmrGd9MuVraXQSksks5Vk5xN3J5qLHsnOTboM9hjF/zGzx3Sl4J/zjh5jS vDCWW4oxEQy3mouJEAGw6/WROAwAA X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-21.messagelabs.com!1481321176!47434734!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 64623 invoked from network); 9 Dec 2016 22:06:16 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Dec 2016 22:06:16 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with Trustwave SEG (v7, 5, 6, 8438) id ; Fri, 09 Dec 2016 22:06:09 +0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Fri, 09 Dec 2016 22:06:16 +0000 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0279.002; Fri, 9 Dec 2016 22:06:16 +0000 From: "Heatley, Nick" To: Tommy Pauly Thread-Topic: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients Thread-Index: AdI/6iAEvrsPebvKTxeJBoeibdeeOgA+3NGABE2iavAABo1YgAAA4XQAAADgjeAAATjwgAAJjgq/ Date: Fri, 9 Dec 2016 22:06:16 +0000 Message-ID: References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK>, <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> In-Reply-To: <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 22:06:23 -0000 --_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for this, very useful. Is the vpn client also discovering the well known prefix for v6 address s= ynthesis itself, or relying on the OS to provide that? -------- Original message -------- From: Tommy Pauly Date: 09/12/2016 17:32 (GMT+00:00) To: "Heatley, Nick" Cc: "Bjoern A. Zeeb" , Bill Fenner , ipsec@ietf.org, sunset4@ietf.org Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients With our push to support NAT64 networks (without 464xlat) for Apple's dev= ices, we added support for NAT64 networks to both our IKEv1 and IKEv2 cli= ents a few releases ago. It was a fairly straightforward change. The main= =20parts are making sure any IPv4 literals meant to be use outside the tu= nnel that come across in the IKE exchange are synthesized into IPv6 addre= sses; and making sure that the ESP layer is happy encapsulating IPv4 in I= Pv6 for tunnels. Historically, many implementations only supported IPv4-i= n-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4. >From an interop perspective, this is just a change that needs to be made = on the client behind the NAT64, and requires no protocol changes in IKE o= r knowledge on the server side. Thanks, Tommy Pauly > On Dec 9, 2016, at 9:03 AM, Heatley, Nick wrote= : > > It is just the single NAT64 that is in question (I also tend to think t= hat is broken for IPsec clients?). > > Popular IPsec clients work perfectly via 464xlat (double NAT64). > > > > -----Original Message----- > From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Bjoern A. = Zeeb > Sent: 09 December 2016 16:33 > To: Bill Fenner > Cc: ipsec@ietf.org; sunset4@ietf.org > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick >> wrote: >> >>> Hi All, >>> >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>> >>> Just checking, is there any summary on how VPN clients behaved on the= >>> nat64 SSID following the event? >>> >> >> Just an anecdote, not actual information: I have two different ways to= >> contact my office VPN server (SSL VPN and IPSEC); neither one worked >> from NAT64. The vendor documentation says that they don't support >> IPv6 transport for the SSL VPN; I do not know what went wrong with the= >> IPSEC VPN. The vendor introduced support for IPSEC with v6 transport >> in their newest software, to which we'll upgrade soon; perhaps that >> upgrade will include whatever is required for it to work through NAT64= >> too. Their support matrix still says that even the newest software >> does not support SSL VPN over IPv6. > > That=92s maybe for the ipsec wg but while native IPv6 VPN has been work= ing fine for me for ages, how would a NAT64 policy exchange actually look= =20like (I am thinking about what is done for IPv4 NAT or double NAT with= in the same address family); I doubt that different AFs on each end as p= art of the policy are specified to work, so I=92d not expect IPsec VPNs t= o work across a NAT64 (from a v6 to a v4 endpoint); someone surprise me = and say with IKEv2 you can? Someone surprise me and say with a double NA= T64 it can work? > > /bz > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or confiden= tial. It's meant only for the individual(s) or entity named above. > If you're not the intended recipient, note that disclosing, copying, di= stributing or using this information is prohibited. > If you've received this email in error, please let me know immediately = on the email address above. Thank you. > > We monitor our email system, and may record your emails. > > EE Limited > Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire,= =20AL10 9BW > Registered in England no: 02382161 > > EE Limited is a wholly owned subsidiary of: > > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above.=20 If you're not the intended recipient, note that disclosing, copying, dist= ributing or using this information is prohibited.=20 If you've received this email in error, please let me know immediately on= =20the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited=20 Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, A= L10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 --_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for this, very useful.
Is the vpn client also discovering the well known prefix for v6 addr= ess synthesis itself, or relying on the OS to provide that?



-------- Original message --------
From: Tommy Pauly <tpauly@apple.com>
Date: 09/12/2016 17:32 (GMT+00:00)
To: "Heatley, Nick" <Nick.Heatley@ee.co.uk>
Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>= ;, Bill Fenner <fenner@fenron.com>, ipsec@ietf.org, sunset4@ietf.or= g
Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

With our push to support NAT64 networks (without= =20464xlat) for Apple's devices, we added support for NAT64 networks to b= oth our IKEv1 and IKEv2 clients a few releases ago. It was a fairly strai= ghtforward change. The main parts are making =20sure any IPv4 literals meant to be use outside the tunnel that come ac= ross in the IKE exchange are synthesized into IPv6 addresses; and making = sure that the ESP layer is happy encapsulating IPv4 in IPv6 for tunnels. = Historically, many implementations only =20supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4.

>From an interop perspective, this is just a change that needs to be made = on the client behind the NAT64, and requires no protocol changes in IKE o= r knowledge on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, at 9:03 AM, Heatley, Nick <nick.heatley@ee.co.uk&= gt; wrote:
>
> It is just the single NAT64 that is in question (I also tend to thin= k that is broken for IPsec clients?).
>
> Popular IPsec clients work perfectly via 464xlat (double NAT64).
= >
>
>
> -----Original Message-----
> From: sunset4 [mailto:su= nset4-bounces@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ipsec@ietf.org; sunset4@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
>
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
>
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heatley@e= e.co.uk>
>> wrote:
>>
>>> Hi All,
>>>
>>> The sunset4 minutes suggest NAT64 SSID to become the default= ?
>>>
>>> Just checking, is there any summary on how VPN clients behav= ed on the
>>> nat64 SSID following the event?
>>>
>>
>> Just an anecdote, not actual information: I have two different w= ays to
>> contact my office VPN server (SSL VPN and IPSEC); neither one wo= rked
>> from NAT64.  The vendor documentation says that they don't = support
>> IPv6 transport for the SSL VPN; I do not know what went wrong wi= th the
>> IPSEC VPN.  The vendor introduced support for IPSEC with v6= =20transport
>> in their newest software, to which we'll upgrade soon; perhaps t= hat
>> upgrade will include whatever is required for it to work through= =20NAT64
>> too.  Their support matrix still says that even the newest = software
>> does not support SSL VPN over IPv6.
>
> That=92s maybe for the ipsec wg but while native IPv6 VPN has been w= orking fine for me for ages, how would a NAT64 policy exchange actually l= ook like (I am thinking about what is done for IPv4 NAT or double NAT wit= hin the same address family);  I doubt that =20different AFs on each end as part of the policy are specified to work,= =20so I=92d not expect IPsec VPNs to work across a NAT64 (from a v6 to a = v4 endpoint);  someone surprise me and say with IKEv2 you can? = =20Someone surprise me and say with a double NAT64 it can =20work?
>
> /bz
>
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/sunset4
>
> NOTICE AND DISCLAIMER
> This email contains BT information, which may be privileged or confi= dential. It's meant only for the individual(s) or entity named above.
> If you're not the intended recipient, note that disclosing, copying,= =20distributing or using this information is prohibited.
> If you've received this email in error, please let me know immediate= ly on the email address above. Thank you.
>
> We monitor our email system, and may record your emails.
>
> EE Limited
> Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshi= re, AL10 9BW
> Registered in England no: 02382161
>
> EE Limited is a wholly owned subsidiary of:
>
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.= ietf.org/mailman/listinfo/ipsec

NOTICE AND DISCLAIMER
This email contains BT information, which may= =20be=20 privileged or confidential. It's meant only for the individual(s) or enti= ty=20 named above.
If you're not the intended recipient, note that disclosi= ng,=20 copying, distributing or using this information is prohibited.
If you= 've=20 received this email in error, please let me know immediately on the email= =20 address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited
Registered office:Trident Place, Mosquito Way, Hatfield= ,=20 Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street= =20London=20 EC1A 7AJ
Registered in England no: 1800000

--_000_cjt6q6y2hsvblpb7m90xodae1481321164734emailandroidcom_-- From nobody Fri Dec 9 14:35:35 2016 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 C45B412950C; Fri, 9 Dec 2016 14:35: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, 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 Bx3GiUkS8Msd; Fri, 9 Dec 2016 14:35:29 -0800 (PST) Received: from mail-wj0-x244.google.com (mail-wj0-x244.google.com [IPv6:2a00:1450:400c:c01::244]) (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 F30AC129557; Fri, 9 Dec 2016 14:35:27 -0800 (PST) Received: by mail-wj0-x244.google.com with SMTP id xy5so4091853wjc.1; Fri, 09 Dec 2016 14:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LGNIMm6H0bbhGd34yRqzrtcpZXEI0KsoMBW5ehYxZhc=; b=B49vuuadFbVPRyXS0zg61cJ3hCdx0XdV7KGnVJoGUhETG5H5ZNk/QdmfUx4q5RyfPy blCUn/JKScjnnGvGoa1ffq6C/v0Rrw75XUacn/Gwiii6F52pcrhTbGT+oTuM7U8DPJLx UjxyKis9eiQIv1BnhJ5vlKuIFVmuAJOZ0dvFr6n/nskVoionn/hAf0nRD2fvrUg9ulsL UzZEd8BkbQV4oZ8IlJzQXK/kzLw9zPurLoKE+qCNbTe0RZTrdgKiCDq84asPuDzX00jq 7leX7gaaEOEK4LJQ3oldWc49wQggxYNMHRr45rvp0/VRYxSpqlvxnfSRuOTz59f9cGSC AbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LGNIMm6H0bbhGd34yRqzrtcpZXEI0KsoMBW5ehYxZhc=; b=iJd1jvcnP6jsN/+JE+XexFZl3tlNYuZSlCjfYp4FUeD64xHiBopRNyOWQm3iLMbqV5 7GjutPirRmgW7ImtEGxtSyPLN5jJsevu29vWGgfXDwtvuSrd8ihCnnda09SBM2RH+j3r E7UrhnMkD8rHAsjLEcjDbGZi77gV6w8lHbjXx3ZsJb9KlNGYpaQDfmttYRoatN3dgLQu QqSO68BspH2RHCCEmifTUdcX7bCBy8BhfwJOzZEiqKkp/CvvsStKycRxwnzeYW9zLfEY QpDexSPnk1NoPRQphMy/8dCh/0lNJVZ29RK5H28LL/MFDg/V1kLo4skKbFnj67h599tB eZxw== X-Gm-Message-State: AKaTC008HN/PJ44oqz2mffxebhWHchsSy57CnWbWmaLzTwmm+LZMbbuk16ZYmz6MK+3L8g== X-Received: by 10.194.90.83 with SMTP id bu19mr70324685wjb.68.1481322926287; Fri, 09 Dec 2016 14:35:26 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i132sm22722094wmf.14.2016.12.09.14.35.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 14:35:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <7107.1481319786@obiwan.sandelman.ca> Date: Sat, 10 Dec 2016 00:35:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <565C6512-ACDB-4BF6-9C73-A7D13028F81C@gmail.com> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <7107.1481319786@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 22:35:32 -0000 > On 9 Dec 2016, at 23:43, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel = endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation in cooperation with the tunnel >> endpoint. I guess this vendor=E2=80=99s IPsec implementation = doesn=E2=80=99t do all >> that. Neither does my employer=E2=80=99s. >=20 > So, I think that you are saying that if the client does DNS through = the > tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess = people > need to do DNS through the tunnel because of needing to resolv = internal > addresses. It's the whole MIF/split-horizon DNS problem, and I think = it's > all a bad IPv4-specific idea, and we should be trying to kill it. That was what I said, but then I realized Tommy is right. It doesn=E2=80=99= t really matter that the ISP / Wifi / whatever is providing me with only = IPv6 access. Most IPsec clients have their own virtual interface (with = IKEv2=E2=80=99s CFG, Cisco=E2=80=99s IKEv1 extension or (gasp!) L2TP) so = that has no issue being dual-stack or even IPv4-only. The IPv4 packets = never make it onto the access network - they get encapsulated in = ESP/IPv6, or TLS/TCP/IPv6. So with IPsec you can get IPv4 connectivity even when the access network = doesn=E2=80=99t give it to you. And you don=E2=80=99t need any DNS games = to do it. Yoav From nobody Fri Dec 9 15:12:17 2016 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 9B9C31295BB for ; Fri, 9 Dec 2016 15:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.416 X-Spam-Level: X-Spam-Status: No, score=-17.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Q-ZovjyQ8uRx for ; Fri, 9 Dec 2016 15:12:13 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5091294BD for ; Fri, 9 Dec 2016 15:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16839; q=dns/txt; s=iport; t=1481325133; x=1482534733; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Erc6K6R7QeCwBgVd2THqlCVNXUFYEbBZoSIz7+leJCo=; b=KBknB6OA91pT+BAMT5nmv5iS85tge9BSIHevZ7KqLUXYdDJr2ug7J6io XFDweVLED8QvyMQhZXJSfCcamEfn+0FA5Y1ZlyLkC9ZsKvDUpzaPGtDMj lmNUVAwJj6k4yhRvmMWE2aQY8EgKGxIvyrFGPnc8z4w1HIZh4ZvPBo7hW 8=; X-Files: smime.p7s : 4557 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQBoOUtY/5ldJa1UCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJzRAEBAQEBH4FgB41ClxOPYIUiggqGIQIjgUM/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDAXkQAgEIEQMBAi8CMB0IAQEEAQ0FDohVCK1XiyEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQ8PhB2CIYRbhCFHhUEFjz+FQYVrAYNggXyLRIFzjlKHZoYlhA0?= =?us-ascii?q?BHzcwcYVZcodKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="p7s'?scan'208,217";a="358083568" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2016 23:12:11 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uB9NCBtw019670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 23:12:11 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 17:12:10 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 17:12:10 -0600 From: "Graham Bartlett (grbartle)" To: Russ Housley , "Scott Fluhrer (sfluhrer)" Thread-Topic: [IPsec] Quantum Resistant IKEv2 Thread-Index: AdJQCCXgkOeGxGfPROWQbtulvkq0wABnwp8AAAk2HIAAAUDSAAA0ucUA Date: Fri, 9 Dec 2016 23:12:10 +0000 Message-ID: References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <53359E5B-D598-4766-81CE-390137BD3DE9@vigilsec.com> In-Reply-To: <53359E5B-D598-4766-81CE-390137BD3DE9@vigilsec.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3564169926_40640927" MIME-Version: 1.0 Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 23:12:15 -0000 --B_3564169926_40640927 Content-type: multipart/alternative; boundary="B_3564169926_40617300" --B_3564169926_40617300 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi I too am in favour of Valery=B9s option. The rational being, if an attacker can recover the SKEYSEED using a QC, I would assume that they can then inject traffic into the IKEv2 SA, examples being to use configuration payload to manipulate routing, rekey with amended traffic selector etc.. Simply put I feel we need to protect both IPsec SAs and child IKEv2 SAs. For users concerned against active attacks, the IKEv2 SA should rekey directly after IKE_AUTH and the new child IKEv2 SA be used for configuratio= n payload. This should be called out in the draft, but shouldn=B9t be mandatory= . cheers From: IPsec on behalf of Russ Housley Date: Thursday, 8 December 2016 22:02 To: "Scott Fluhrer (sfluhrer)" Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 >> o Valery Smyslov gave a suggestion that we instead stir in the PPK int= o the >> initial SK_d; as all keying material is generated based on that, this wo= uld >> also mean that IPsec SAs and any child IKE SAs are also protected. This= also >> means that an implementation would not need to remember the PPK after th= e >> initial negotiation. The only downside I can see is that we would have = to be >> a bit careful about when we update the SK_d (obviously, before we actual= ly >> use it). >> To me, all three strike me as reasonable ideas (unless we decide that we= will >> need to protect the real identity data encrypted via the IKE SA; in that >> case, Dan=B9s idea doesn=B9t protect that). Can I get opinions as to which >> strikes the group as the best? Are there any fourth options that people >> would want to put on the table? >> =20 >> I would like to see the preshared key used in a manner that protects the= IKE >> SA as well as the child SA. I have a mild preference for the third >> alternative over the first one. > =20 > Actually, in terms of what IPsec/IKE traffic is immune from recovery from= an > adversary with a Quantum Computer, the first and third options are identi= cal. I recognize that. I would like to see the preshared key used in a manner that protects the IK= E SA as well as the child SA, and between the two alternatives that offer that, I have a mild preference for the third alternative. Russ --B_3564169926_40617300 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi

I= too am in favour of Valery’s option. The rational being, if an attack= er can recover the SKEYSEED using a QC, I would assume that they can then in= ject traffic into the IKEv2 SA, examples being to use configuration payload = to manipulate routing, rekey with amended traffic selector etc.. Simply put = I feel we need to protect both IPsec SAs and child IKEv2 SAs. 

For users concerned against active attacks, the IKEv2 SA sh= ould rekey directly after IKE_AUTH and the new child IKEv2 SA be used for co= nfiguration payload. This should be called out in the draft, but shouldnR= 17;t be mandatory.

cheers

From: IPsec <ipsec-bounces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Date: Thursday, 8 December 2016 22:02
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: IETF IPsec <ipse= c@ietf.org>
Subject: Re: [I= Psec] Quantum Resistant IKEv2

=
o   Valery Smyslov gave a suggestion that we instead stir in the= PPK into the initial SK_d; as all keying material is generated based on tha= t, this would also mean that IPsec SAs and any child IKE SAs are also protec= ted.  This also means that an implementation would not need to remember= the PPK after the initial negotiation.  The only downside I can see is= that we would have to be a bit careful about when we update the SK_d (obvio= usly, before we actually use it).
To me, all three strike me as reasonable ideas (= unless we decide that we will need to protect the real identity data encrypt= ed via the IKE SA; in that case, Dan’s idea doesn’t protect that= ).  Can I get opinions as to which strikes the group as the best? = Are there any fourth options that people would want to put on the table?
&= nbsp;
I would like to see the preshared key used in a manner that protects t= he IKE SA as well as the child SA.  I have a mild preference for the th= ird alternative over the first one.
 
Actually, in terms of = what IPsec/IKE traffic is immune from recovery from an adversary with a Quan= tum Computer, the first and third options are identical.

I recognize that.

I would like to see the preshared key used in a manner that protects the = IKE SA as well as the child SA, and between the two alternatives that offer = that, I have a mild preference for the third alternative.

Russ
--B_3564169926_40617300-- --B_3564169926_40640927 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIRyQYJKoZIhvcNAQcCoIIRujCCEbYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg9+MIIFbTCCBFWgAwIBAgIQDZu2aTrsxkrY+ilxZLyNgTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYw NTE2MDAwMDAwWhcNMTgwNTE2MTIwMDAwWjCBkDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNjbyBTeXN0ZW1zLCBJ bmMuMRgwFgYDVQQDEw9HcmFoYW0gQmFydGxldHQxITAfBgkqhkiG9w0BCQEWEmdyYmFydGxl QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMqOS+hfMCqvKj+e gZdgQIEPbPvc6Mv9fJvK/hNbeOiOwBepKx73eSUh+gABrR8i7ui5/V7XlyMPg/OgQr/6UZX2 QGaqBNkiVkOqNDjwjDz6+voKVS2MNU0cCvxP5Xwb9VXgw2JzFAMMshknhP7G+9V6qxda7e5m fmBzYgCgewiITHD83tGiS/YuoOogmPfYnpQyCcnSdwj8MqnlvVfBQVdAOg+a7hv8zPcTA4mH H0Y3dqCIdNtj1QEm9D9YbDlCS1MZl/7byqLpEZA+la8Pva/r/lydbVuM7BXygqI+itXM9963 8kZim8zTh4r/wCi8uklBSeMRUHSmgocw5BpnIk8CAwEAAaOCAeswggHnMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBQmnj6AyXbjUyNRGN6Y2JOK17/CkzAM BgNVHRMBAf8EAjAAMB0GA1UdEQQWMBSBEmdyYmFydGxlQGNpc2NvLmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZI AYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2Vy dHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0B AQsFAAOCAQEAna7Ws4vfNhrcm0Od6wb6xiOBURSSXAgX7LE8chrD7UfTF+b7DKits6QY1Vvo 5s0ryCy2T4ikMMKzpAnQ9O0vvF5wbb2iF9zTyKv2M36uY6L6EbMC7QoQAihAiOGnLy4wwhsB qtoGHPL8f1ROW2xpK3twQm2jthhv7fzHRPnFFh4bwWLLISHsw7JKzaL1GuxghNr9W9CN7o2r OtnnvoSwdkPBlMmquWrUgCZ06UQfsD6nbVDvqlBlJGBsrfXk3y8yg3q+rN6LTqHccW4Rk1KS OkE8i/8NKTo8QXHSOa+jcK0o7mnjGXERklDnFGMiNVLbVhVa9CJynUpLjNct3q6+ATCCBk4w ggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMC VVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoX DTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1 cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kb LQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAf JUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ 9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1x GOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgw BgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0 LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1s AAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQG CCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAA dABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAA UwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIA ZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQA eQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUA aQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEL BQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mg VgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0 k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEy br1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIIC n6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVT MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0z MTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAX BgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQg Um9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5 cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+Y MjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nY Lxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGY M2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSS plazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8G A1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQY MBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43Jz emSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS 2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1 bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/ N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHS oyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEweTBlMQswCQYDVQQG EwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA2btmk67MZK2PopcWS8 jYEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgsmjY2EoRfjijG8yBQeTgtama zI53PI8sAZd+TqV8JLswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTYxMjA5MjMxMjA2WjANBgkqhkiG9w0BAQEFAASCAQAabeGv9vYaGsT8idG3QsL+qNpf qmht4hyJNJe5hLpQCo6QSkbLT6tf0kDX/4x3HeHxGNmGK/K+gPtMFj4zOWxGagXnjLICrILW yFvA/UiB9wIP7Fz4DP6nJMuwawDo3MQnhB8nvqQk4prIGYJKm3I/HRJs7/hMXQaeGg9yKnpR a9JuJW96KBpUxyhWop/OUjCrBfmn8N2d6wdIbtCQIOwb2YEe4+OWVUbe+h2ZfePrmEo7tCzz tY6+GXX32B9ByyXgLPgPaC42zaS+7Fr1FImkdwZIBgvp3h9O5rjJJKxN+/BhJ2+DCeH5Ssfy pcJpGanK+mFwAIciAEwgtMdM4orc --B_3564169926_40640927-- From nobody Fri Dec 9 18:28:55 2016 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 778A9128BA2 for ; Fri, 9 Dec 2016 18:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 pqLbAFlz_zcn for ; Fri, 9 Dec 2016 18:28:47 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 4FBA5129496 for ; Fri, 9 Dec 2016 18:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481336927; 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=XeWDsADtml7t2x+7dJ1j76lEbhlLGeb7zTdHXnGCo6w=; b=huJZE/O4uSPQ7GKCzv39i8COJSeofQKtRCM10ROc4JODxFnbEaVpVqB2wtMtsY3e NaT8pjaH502vjRL2XpOf0aI2XAldTEi1jxv8xyK/eS9fZDcJB7KtwiefvqYmxfBD 7NTTLnENuC1ON1Kn9SmV+LUzAn8Ivl8q085WoxJboozp1Z5SuNLCZZavU2bkm19P CmrCQ3hWJkF+lS/uOE/Lyp4bZOqfmLkwt7GTTe30TNdOFeNzIcQJ+FvGuB7neZuS QAmCHXD5iJEnBzAOaeeluHbrsHADxMkFIfxtN1bu9LsUyXpYaaXcAWlX43IGX7vm ZglASXMBKrXAKh64cvbYDg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 81.EE.18170.F586B485; Fri, 9 Dec 2016 18:28:47 -0800 (PST) X-AuditID: 11973e15-459e39a0000046fa-05-584b685f8fa4 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id 0D.0D.09148.E586B485; Fri, 9 Dec 2016 18:28:46 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg)" Received: from da0602a-dhcp105.apple.com (da0602a-dhcp105.apple.com [17.226.23.105]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHY009UJ6VYXX20@nwk-mmpp-sz12.apple.com>; Fri, 09 Dec 2016 18:28:46 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Fri, 09 Dec 2016 18:28:45 -0800 In-reply-to: To: "Heatley, Nick" References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C402022@UK30S005EXS06.EEAD.EEINT.CO.UK> <77C884D7-8A1F-4340-B30A-8BF95CB85928@apple.com> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUi2FDorBuf4R1hMPseq8X1Ze4W72/tYbPY v+UFm8Wzr5PZLFbu2c/uwOpx8YmJR/v2b6weS5b8ZPLo/u8dwBLFZZOSmpNZllqkb5fAlXFj 1UO2gtd7GStedDczNzA+WsLYxcjJISFgInGubQdrFyMXh5DAXkaJzkkHmGASO9cthkocYpT4 s64TLMErICjxY/I9FhCbWSBM4vLlRkaIomVMEhNvHwJKcHAIC0hIbN6TCFLDJqAicfzbBmaI XhuJf1vvg9nCAg4SbUfusoLYLAKqEvtezQObzyngLvHiwQxmkJnMAksYJf7t3swGkhAR0JZo nvMLalk7i8TyjTehTpWVWPl0I9ipEgKf2STOTLrENIFRaBaSa2chuXYW0IHMAuoSU6bkQoS1 JZ68u8AKYatJLPy9iAlZfAEj2ypGodzEzBzdzDwzvcSCgpxUveT83E2MoPiZbie6g/HMKqtD jAIcjEo8vA6HvCKEWBPLiitzDzFKc7AoifN2OnlHCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amDs8HsUesZk+tM//Eun6RzjrVV2ErCuaJO9tGhl8dKHRw7Ordon/4x75rElT8/w9PjvW/VW +OVZ76ICAXEHgZtCJ2N/tH7RX1wxTWn6vllHuGf7uc78wCZf66uot+TanRVsaXKaSSsnLQ5V 4Dmy0uGjvllIeJ55Tfj6VyLJJ4/+DDHZ6TplpX2WEktxRqKhFnNRcSIARZl00IACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUi2FB8RjcuwzvCYOZuK4vry9wt3t/aw2ax f8sLNotnXyezWazcs5/dgdXj4hMTj/bt31g9liz5yeTR/d87gCWKyyYlNSezLLVI3y6BK+PG qodsBa/3Mla86G5mbmB8tISxi5GTQ0LARGLnusWsELaYxIV769m6GLk4hAQOMUr8WdfJBJLg FRCU+DH5HguIzSwQJnH5ciMjRNEyJomJtw8BJTg4hAUkJDbvSQSpYRNQkTj+bQMzRK+NxL+t 98FsYQEHibYjd8GWsQioSux7NQ9sPqeAu8SLBzOYQWYyCyxhlPi3ezMbSEJEQFuiec4vqGXt LBLLN95kgjhVVmLl042sExgFZiE5cBaSA2cB3cQsoC4xZUouRFhb4sm7C6wQtprEwt+LmJDF FzCyrWIUKErNSaw00kssKMhJ1UvOz93ECI6DQucdjMeWWR1iFOBgVOLhdTjkFSHEmlhWXJkL DCUOZiURXpYk7wgh3pTEyqrUovz4otKc1OJDjBMZgd6cyCwlmpwPjNK8knhDExMDE2NjM2Nj cxNzWgorifNaOgNdJJCeWJKanZpakFoEcxQTB6dUA6M10xb5Ngbpde38v9q/veZv9k8+MNc9 9Ijtv0pHrqhGr80mC6/2hIVUNfx+4MbM0p51+eFhgS1y9zI7eWJ2BQt8WO1tkx9y0W52+u81 9YUPmkp3bzvL+OjtDo+idY+eC3Vf5V9Tu0/I0uTMkqnPTW6pqv3/WtO4ZBX/J4X82JQzHIGG 0euu2yixFGckGmoxFxUnAgBRXNLw9gIAAA== Archived-At: Cc: "ipsec@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 02:28:49 -0000 --Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable The VPN client can do the synthesis themselves using RFC 6052 = (https://tools.ietf.org/html/rfc6052) and RFC 7050 = (https://tools.ietf.org/html/rfc7050), querying ipv4only.arpa over the = DNS. macOS and iOS also support synthesis in the OS by calling getaddrinfo() = with the IPv4 address as a string, and returning an IPv6 sockaddr when = on a NAT64 network. Thanks, Tommy > On Dec 9, 2016, at 2:06 PM, Heatley, Nick = wrote: >=20 > Thanks for this, very useful. > Is the vpn client also discovering the well known prefix for v6 = address synthesis itself, or relying on the OS to provide that? >=20 >=20 >=20 > -------- Original message -------- > From: Tommy Pauly >=20 > Date: 09/12/2016 17:32 (GMT+00:00) > To: "Heatley, Nick" >=20 > Cc: "Bjoern A. Zeeb" >, Bill Fenner >, ipsec@ietf.org , = sunset4@ietf.org > Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients >=20 > With our push to support NAT64 networks (without 464xlat) for Apple's = devices, we added support for NAT64 networks to both our IKEv1 and IKEv2 = clients a few releases ago. It was a fairly straightforward change. The = main parts are making sure any IPv4 literals meant to be use outside the = tunnel that come across in the IKE exchange are synthesized into IPv6 = addresses; and making sure that the ESP layer is happy encapsulating = IPv4 in IPv6 for tunnels. Historically, many implementations only = supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4. >=20 > >=46rom an interop perspective, this is just a change that needs to be = made on the client behind the NAT64, and requires no protocol changes in = IKE or knowledge on the server side. >=20 > Thanks, > Tommy Pauly >=20 > > On Dec 9, 2016, at 9:03 AM, Heatley, Nick > wrote: > >=20 > > It is just the single NAT64 that is in question (I also tend to = think that is broken for IPsec clients?). > >=20 > > Popular IPsec clients work perfectly via 464xlat (double NAT64). > >=20 > >=20 > >=20 > > -----Original Message----- > > From: sunset4 [mailto:sunset4-bounces@ietf.org = ] On Behalf Of Bjoern A. Zeeb > > Sent: 09 December 2016 16:33 > > To: Bill Fenner > > Cc: ipsec@ietf.org ; sunset4@ietf.org = > > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients > >=20 > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >=20 > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick = > > >> wrote: > >>=20 > >>> Hi All, > >>>=20 > >>> The sunset4 minutes suggest NAT64 SSID to become the default? > >>>=20 > >>> Just checking, is there any summary on how VPN clients behaved on = the > >>> nat64 SSID following the event? > >>>=20 > >>=20 > >> Just an anecdote, not actual information: I have two different ways = to=20 > >> contact my office VPN server (SSL VPN and IPSEC); neither one = worked=20 > >> from NAT64. The vendor documentation says that they don't support=20= > >> IPv6 transport for the SSL VPN; I do not know what went wrong with = the=20 > >> IPSEC VPN. The vendor introduced support for IPSEC with v6 = transport=20 > >> in their newest software, to which we'll upgrade soon; perhaps that=20= > >> upgrade will include whatever is required for it to work through = NAT64=20 > >> too. Their support matrix still says that even the newest software=20= > >> does not support SSL VPN over IPv6. > >=20 > > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has = been working fine for me for ages, how would a NAT64 policy exchange = actually look like (I am thinking about what is done for IPv4 NAT or = double NAT within the same address family); I doubt that different AFs = on each end as part of the policy are specified to work, so I=E2=80=99d = not expect IPsec VPNs to work across a NAT64 (from a v6 to a v4 = endpoint); someone surprise me and say with IKEv2 you can? Someone = surprise me and say with a double NAT64 it can work? > >=20 > > /bz > >=20 > > _______________________________________________ > > sunset4 mailing list > > sunset4@ietf.org > > https://www.ietf.org/mailman/listinfo/sunset4 = > >=20 > > NOTICE AND DISCLAIMER > > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above.=20 > > If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.=20 > > If you've received this email in error, please let me know = immediately on the email address above. Thank you. > >=20 > > We monitor our email system, and may record your emails. > >=20 > > EE Limited=20 > > Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW > > Registered in England no: 02382161 > >=20 > > EE Limited is a wholly owned subsidiary of: > >=20 > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec = >=20 > NOTICE AND DISCLAIMER > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above.=20 > If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited.=20 > If you've received this email in error, please let me know immediately = on the email address above. Thank you. >=20 > We monitor our email system, and may record your emails. >=20 > EE Limited=20 > Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW > Registered in England no: 02382161 >=20 > EE Limited is a wholly owned subsidiary of: >=20 > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
The VPN client can do the synthesis = themselves using RFC 6052 (https://tools.ietf.org/html/rfc6052) and RFC 7050 (https://tools.ietf.org/html/rfc7050), = querying ipv4only.arpa over the DNS.

macOS and iOS also support synthesis in = the OS by calling getaddrinfo() with the IPv4 address as a string, = and returning an IPv6 sockaddr when on a NAT64 network.

Thanks,
Tommy

On Dec 9, 2016, at 2:06 PM, Heatley, Nick = <nick.heatley@ee.co.uk> wrote:

Thanks for = this, very useful.
Is the vpn client also = discovering the well known prefix for v6 address synthesis itself, or = relying on the OS to provide that?



-------- Original message = --------
From: Tommy Pauly <tpauly@apple.com> 
Date: = 09/12/2016 17:32 (GMT+00:00)
To: "Heatley, Nick" = <Nick.Heatley@ee.co.uk> 
Cc: = "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Bill Fenner <fenner@fenron.com>, ipsec@ietf.org, sunset4@ietf.org
Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN = clients

With our push to support NAT64 networks (without = 464xlat) for Apple's devices, we added support for NAT64 networks to = both our IKEv1 and IKEv2 clients a few releases ago. It was a fairly = straightforward change. The main parts are making sure any IPv4 literals = meant to be use outside the tunnel that come across in the IKE exchange = are synthesized into IPv6 addresses; and making sure that the ESP layer = is happy encapsulating IPv4 in IPv6 for tunnels. Historically, many = implementations only supported IPv4-in-IPv4, IPv6-in-IPv6, and = IPv6-in-IPv4.

>=46rom an interop = perspective, this is just a change that needs to be made on the client = behind the NAT64, and requires no protocol changes in IKE or knowledge = on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, = at 9:03 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:
> 
> It is = just the single NAT64 that is in question (I also tend to think that is = broken for IPsec clients?).
> 
> Popular = IPsec clients work perfectly via 464xlat (double NAT64).
> 
> 
> 
> -----Original Message-----
> From: = sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Bjoern A. = Zeeb
> Sent: 09 December 2016 16:33
> = To: Bill Fenner
> Cc: ipsec@ietf.org; sunset4@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN = clients
> 
> On 9 = Dec 2016, at 16:07, Bill Fenner wrote:
> 
>> On = Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heatley@ee.co.uk>
>> = wrote:
>> 
>>> = Hi All,
>>> 
>>> = The sunset4 minutes suggest NAT64 SSID to become the default?
>>> 
>>> = Just checking, is there any summary on how VPN clients behaved on the
>>> nat64 SSID following the event?
>>> 
>> 
>> = Just an anecdote, not actual information: I have two different ways = to 
>> contact my office VPN server (SSL VPN and IPSEC); = neither one worked 
>> from NAT64.  The vendor documentation says that = they don't support 
>> IPv6 transport for the SSL VPN; I do not know what = went wrong with the 
>> IPSEC VPN.  The vendor introduced support for = IPSEC with v6 transport 
>> in = their newest software, to which we'll upgrade soon; perhaps that 
>> = upgrade will include whatever is required for it to work through = NAT64 
>> too.  Their support matrix still says that even = the newest software 
>> does not support SSL VPN over IPv6.
> 
> That=E2=80=99s maybe for the ipsec wg but while native = IPv6 VPN has been working fine for me for ages, how would a NAT64 policy = exchange actually look like (I am thinking about what is done for IPv4 = NAT or double NAT within the same address family);  I doubt that = different AFs on each end as part of the policy are specified to work, = so I=E2=80=99d not expect IPsec VPNs to work across a NAT64 (from a v6 = to a v4 endpoint);  someone surprise me and say with IKEv2 you = can?  Someone surprise me and say with a double NAT64 it can = work?
> 
> /bz
> 
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
> 
> NOTICE AND DISCLAIMER
> This email = contains BT information, which may be privileged or confidential. It's = meant only for the individual(s) or entity named above. 
> If = you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited. 
> If = you've received this email in error, please let me know immediately on = the email address above. Thank you.
> 
> We = monitor our email system, and may record your emails.
> 
> EE Limited 
> = Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, = AL10 9BW
> Registered in England no: 02382161
> 
> EE Limited is a wholly owned subsidiary of:
> 
> British Telecommunications plc
> = Registered office: 81 Newgate Street London EC1A 7AJ
> = Registered in England no: 1800000
> = _______________________________________________
> IPsec = mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged = or confidential. It's meant only for the individual(s) or entity named = above. 
If= you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited. 
If you've = received this email in error, please let me know immediately on the = email address above. Thank you.

We monitor our email system, and may record your = emails.

EE = Limited 
Registered office:Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW
Registered in England no: = 02382161

EE = Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered = office: 81 Newgate Street London EC1A 7AJ
Registered in = England no: 1800000

_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_M1oqD4wLRUegBrsZO9R2Zg)-- From nobody Fri Dec 9 18:33:12 2016 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 103F4128BA2 for ; Fri, 9 Dec 2016 18:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mCZUCl5dHYzX for ; Fri, 9 Dec 2016 18:33:07 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 2EB221295C9 for ; Fri, 9 Dec 2016 18:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481337187; 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=TSS8MX7ie0a/LTab6UIkMdU8iy622c2cLXEULVZvoDc=; b=RiSNMggIZ+rfVu80QAYBR1bTaJbNM9J5Z/K7tx9Sd5e/YKm6+kvFdBUHnowEMYny 8MOG6e1tC1818zRkb96VLqb0FVL00W5wZt7Y9QoHbJfxe1pHya6znIit56aoTrG4 g5ik4Mv5AeYSeXHSSMECTcIzV3lVZ8lRdsaYeZCcZ0lJ2An3WhuSCIduhjt97g85 LoEDWD2ubPYRzgsm13kdh49orFV+GPkMXXz8Qa1kv745M+BkKIADwWB0P0ctNUVN OPY5LKc4FcZsR0BSw5SbZgORUhaIkC4MWgPxmhsd69k9EveGxRMWVqtZIdRPXrLG nmQU0KyO/3STCV8bTUI8eA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id DE.A9.19113.2696B485; Fri, 9 Dec 2016 18:33:07 -0800 (PST) X-AuditID: 11973e16-a4ca89a000004aa9-d1-584b6962c3cc Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id A0.DE.23613.2696B485; Fri, 9 Dec 2016 18:33:06 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw)" Received: from [17.153.58.87] (unknown [17.153.58.87]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OHY00GQ772YAM60@nwk-phonehomebzp-sz01.apple.com>; Fri, 09 Dec 2016 18:33:06 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Fri, 09 Dec 2016 18:32:57 -0800 In-reply-to: <565C6512-ACDB-4BF6-9C73-A7D13028F81C@gmail.com> To: Yoav Nir References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <7107.1481319786@obiwan.sandelman.ca> <565C6512-ACDB-4BF6-9C73-A7D13028F81C@gmail.com> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUi2FAYpZuc6R1hcKbe4voyd4v3t/awWezf 8oLNoudQP7vFyj372S2WHvvA5MDm0b79G6vHzll32T2WLPnJ5NH939ujZc4e5gDWKC6blNSc zLLUIn27BK6ML41LmArmJVd03l3M1MD4LLSLkZNDQsBE4tbWPtYuRi4OIYG9jBKd2ycywyTu 35vGBGILCRxjlFg2LxDE5hUQlPgx+R4LiM0sECYxZWsnC0TzDCaJ+0/OsYIkhAWkJbou3AWy OTjYBLQkDqwxgui1kdh66zkbRImDRNuRu2DlLAKqEu1/ToLt5RSwlbiycwPYQcwCjUwSR7vW gDWICChJHL7ylRli2U1miU0X+5kgLpWV+PT8JztIQkLgN5tE66q5jBMYhWYhuXYWkmtnAR3F LKAuMWVKLkRYW+LJuwusELaaxMLfi5iQxRcwsq1iFMpNzMzRzcwz10ssKMhJ1UvOz93ECIqm 6XZiOxgfrrI6xCjAwajEw+twyCtCiDWxrLgy9xCjNAeLkjhvh5N3hJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGCaZBSf7eE2bkrg/ofH9xT2eCa8yd92niLEpV0e/NDRQmLe0+b6G1R/Aa z8ucXOn/1w4+ulTNvunTMWlX2ee7upSONsT3HLowY+GnlTr3KtP3flFYdjpT8ItTXfjWTT83 /90gLLnQVX9S8z32/a/3fbN6OGF5zzuzOL8tcycl6h215b0m673uhhJLcUaioRZzUXEiAKCD IH2HAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUiON3OQTcp0zvC4O9pdYvry9wt3t/aw2ax f8sLNoueQ/3sFiv37Ge3WHrsA5MDm0f79m+sHjtn3WX3WLLkJ5NH939vj5Y5e5gDWKO4bFJS czLLUov07RK4Mr40LmEqmJdc0Xl3MVMD47PQLkZODgkBE4n796YxQdhiEhfurWcDsYUEjjFK LJsXCGLzCghK/Jh8jwXEZhYIk5iytRPI5gKqmcEkcf/JOVaQhLCAtETXhbtANgcHm4CWxIE1 RhC9NhJbbz1ngyhxkGg7chesnEVAVaL9z0lmEJtTwFbiys4NrCAzmQUamSSOdq0BaxARUJI4 fOUrM8Sym8wSmy72Q10qK/Hp+U/2CYwCs5AcOAvJgbOA7mAWUJeYMiUXIqwt8eTdBVYIW01i 4e9FTMjiCxjZVjEKFKXmJFaa6SUWFOSk6iXn525iBMVFQ2HUDsaG5VaHGAU4GJV4eB0OeUUI sSaWFVfmHmKU4GBWEuFlSfKOEOJNSaysSi3Kjy8qzUktPsQ4kRHozYnMUqLJ+cCozSuJNzQx MTAxNjYzNjY3MaelsJI4r6Uz0EUC6YklqdmpqQWpRTBHMXFwSjUwsrWUve74abh1Ve+KdgHj OWeuRnOFrAznqgwvtup+ovq21HXvy8N/bA0erkhZqLUkR/tD8qH2OwuXp8Q6Wvec6/J2/2Yf f3e5qtMJEynhO07Pz/+Q2badU1vePTur6b/klsXBi7bNWbtz/93azRwL5/wJi9x55MkpoTd+ wXXaTkv3H7Ow/O9frcRSnJFoqMVcVJwIAO/0mqL+AgAA Archived-At: Cc: Michael Richardson , "IPsecme WG \(ipsec@ietf.org\)" , "sunset4@ietf.org" , "Bjoern A. Zeeb" , Bill Fenner , Tommy Pauly Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 02:33:10 -0000 --Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable You'll need to play DNS games if the VPN server if IPv4-only (or if your VPN config gives you a server IPv4 address to connect to). In that case you'll need to query the DNS64 server for the NAT64 prefix. Apple's IKEv2 client uses an OS-provided API to synthesize an IPv6 = address from the configured IPv4 address. This allows our client to work even if the VPN server does not speak = IPv6 at all. It's always better, simpler, and more efficient to support IPv6 = server-side, but if you don't control the server this can be made to work = client-side. David > On Dec 9, 2016, at 14:35, Yoav Nir wrote: >=20 >>=20 >> On 9 Dec 2016, at 23:43, Michael Richardson = wrote: >>=20 >>=20 >> Yoav Nir wrote: >>> To get this working, the DNS64 should be on the remote tunnel = endpoint >>> or behind it. And this will require that it has an IPv6 address and >>> knows to do the NAT64 translation in cooperation with the tunnel >>> endpoint. I guess this vendor=E2=80=99s IPsec implementation = doesn=E2=80=99t do all >>> that. Neither does my employer=E2=80=99s. >>=20 >> So, I think that you are saying that if the client does DNS through = the >> tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I = guess people >> need to do DNS through the tunnel because of needing to resolv = internal >> addresses. It's the whole MIF/split-horizon DNS problem, and I think = it's >> all a bad IPv4-specific idea, and we should be trying to kill it. >=20 > That was what I said, but then I realized Tommy is right. It doesn=E2=80= =99t really matter that the ISP / Wifi / whatever is providing me with = only IPv6 access. Most IPsec clients have their own virtual interface = (with IKEv2=E2=80=99s CFG, Cisco=E2=80=99s IKEv1 extension or (gasp!) = L2TP) so that has no issue being dual-stack or even IPv4-only. The IPv4 = packets never make it onto the access network - they get encapsulated in = ESP/IPv6, or TLS/TCP/IPv6. >=20 > So with IPsec you can get IPv4 connectivity even when the access = network doesn=E2=80=99t give it to you. And you don=E2=80=99t need any = DNS games to do it. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable You'll need to play DNS games if the VPN server if = IPv4-only
(or if your VPN config gives you a server IPv4 = address to connect to).
In that case you'll need to = query the DNS64 server for the NAT64 prefix.
Apple's = IKEv2 client uses an OS-provided API to synthesize an IPv6 = address
from the configured IPv4 address.
This allows our client to work even if the VPN server does = not speak IPv6 at all.
It's always better, simpler, = and more efficient to support IPv6 server-side,
but = if you don't control the server this can be made to work client-side.

David


On Dec 9, 2016, at 14:35, Yoav Nir <ynir.ietf@gmail.com>= wrote:


On 9 Dec 2016, at 23:43, Michael = Richardson <mcr+ietf@sandelman.ca> wrote:


Yoav Nir <ynir.ietf@gmail.com>= wrote:
To get this = working, the DNS64 should be on the remote tunnel endpoint
or behind it. And this will require that it has an IPv6 = address and
knows to do the NAT64 translation in = cooperation with the tunnel
endpoint. I guess this = vendor=E2=80=99s IPsec implementation doesn=E2=80=99t do all
that.  Neither does my employer=E2=80=99s.

So, I think that you are saying = that if the client does DNS through the
tunnel, then the = HQ's DNS servers have to do DNS64 synthesis?  I guess people
need to do DNS through the tunnel because of needing to = resolv internal
addresses.  It's the whole = MIF/split-horizon DNS problem, and I think it's
all a bad = IPv4-specific idea, and we should be trying to kill it.

That was what I said, but then I realized Tommy = is right. It doesn=E2=80=99t really matter that the ISP / Wifi / = whatever is providing me with only IPv6 access. Most IPsec clients have = their own virtual interface (with IKEv2=E2=80=99s CFG, Cisco=E2=80=99s = IKEv1 extension or (gasp!) L2TP) so that has no issue being dual-stack = or even IPv4-only. The IPv4 packets never make it onto the access = network - they get encapsulated in ESP/IPv6, or TLS/TCP/IPv6.

So with IPsec you can get IPv4 = connectivity even when the access network doesn=E2=80=99t give it to = you. And you don=E2=80=99t need any DNS games to do it.

Yoav

_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_tDZ5JB0IzjoIRtt7RC0Cpw)-- From nobody Mon Dec 12 08:45:20 2016 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 DBB3A12944B for ; Mon, 12 Dec 2016 08:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fenron.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 3Mw2YTH9OFMS for ; Mon, 12 Dec 2016 08:45:17 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 8C670129DF2 for ; Mon, 12 Dec 2016 08:40:52 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id b35so86444146uaa.3 for ; Mon, 12 Dec 2016 08:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fenron.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jD51K4V7+bNvrWanQSCAfr4bGjD2jq8gb2p8cD7kU6k=; b=Uvu5P59M+Mnrod9XcYrfArO59W3x8xEZRR7ED2QdxAzh6Q9b0+W+qSK1Y1apjtQJRG KhfniEtD8crARlaN6qnYptFJeQ+2LZmCCOVsHaZyJwkKzOrCcufX9ugVJS9RYZ04CQSz xHSkHwLt5urODi50t1K+GwjHZQFsIbNx42zk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jD51K4V7+bNvrWanQSCAfr4bGjD2jq8gb2p8cD7kU6k=; b=GaPmLL4lViG180G6A7HtWLcPE7Bi5fRpSlU9plsrzvDuiX1TSwlYiR9WaU9blEtvEC 5jUN1o8nosQapYfYLT223uh+nrpUSiccB+FLZM2NBxIq749+yKT7mPzV3chHExT7dRrQ RV3lnA5QG2VBxmlAl6yA6xODJBRwjUul8v1EpSkWlW/97eHkmSjFKsTxnlfsEvMPFxLt oJyXmJ5FYoIp2j5gC/vkXrN2/Gu1AxUbx8b5CvyxOM0PZah+F2DTe/9/cLONF9pWxq5+ ViUYkK1Ygq8whoL+dGEC7YrNf7cgq+sozEQeszS2onkNl8KGe2uiG40vjmK8/aJmL05h B8mQ== X-Gm-Message-State: AKaTC02XHvuROeUlDlPUpOet4wvwFO3FOpMpkDU+RnOEb4iTcMYOmp69yRf5ugDF8PDWV0HrBk2dLIr66Wb7mg== X-Received: by 10.176.2.167 with SMTP id 36mr58640834uah.41.1481560851638; Mon, 12 Dec 2016 08:40:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.168 with HTTP; Mon, 12 Dec 2016 08:40:51 -0800 (PST) In-Reply-To: <6205.1481319551@obiwan.sandelman.ca> References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <6205.1481319551@obiwan.sandelman.ca> From: Bill Fenner Date: Mon, 12 Dec 2016 11:40:51 -0500 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a113acf724674fc054378c466 Archived-At: Cc: ipsec@ietf.org, "Bjoern A. Zeeb" , "sunset4@ietf.org" Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 16:45:19 -0000 --001a113acf724674fc054378c466 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2016 at 4:39 PM, Michael Richardson wrote: > > Bjoern A. Zeeb wrote: > > That=E2=80=99s maybe for the ipsec wg but while native IPv6 VPN has= been > working fine > > for me for ages, how would a NAT64 policy exchange actually look > like (I am > > thinking about what is done for IPv4 NAT or double NAT within the > same > > NAT64 depends upon DNS64 to provide a fake IPv6 target for the applicatio= n > to > connect to. > > So, for IPsec to work over NAT64 would require: > > 1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6)= . > 2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so that = it > can be lied to about the returned AAAA record. > > In Bill's case, he hasn't got (1), so it's not going to work. > Well, I was using Apple's "Cisco IPSec" client for OSX 10.11.5, and it's the server side implementation that says that IPv6 transport is not supported. So, perhaps, I have a client that would support it. > Once he has (1) (the upgrade he mentioned), if his policy lets him use DN= S > to > find his gateway, and he doesn't do DNSSEC on that, then it ought to work= . > That is what I have configured. Bill --001a113acf724674fc054378c466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 9, 2016 at 4:39 PM, Michael Richardson <mcr+ietf@sandelman.ca<= /a>> wrote:
Bjoern A. Zeeb <bzeeb-= lists@lists.zabbadoz.net> wrote:
=C2=A0 =C2=A0 > That=E2=80=99s maybe for the ips= ec wg but while native IPv6 VPN has been working fine
=C2=A0 =C2=A0 > for me for ages, how would a NAT64 policy exchange actua= lly look like (I am
=C2=A0 =C2=A0 > thinking about what is done for IPv4 NAT or double NAT w= ithin the same

NAT64 depends upon DNS64 to provide a fake IPv6 target for the appli= cation to
connect to.

So, for IPsec to work over NAT64 would require:

1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6).<= br> 2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so tha= t it
=C2=A0 =C2=A0can be lied to about the returned AAAA record.

In Bill's case, he hasn't got (1), so it's not going to work.

Well, I was using Apple's "Cisc= o IPSec" client for OSX 10.11.5, and it's the server side implemen= tation that says that IPv6 transport is not supported.=C2=A0 So, perhaps, I= have a client that would support it.
=C2=A0
Once he has (1) (the upgrade he mentioned), if his policy lets him use DNS = to
find his gateway, and he doesn't do DNSSEC on that, then it ought to wo= rk.

That is what I have configured.

=C2=A0 Bill

--001a113acf724674fc054378c466-- From nobody Mon Dec 12 10:11:16 2016 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 7D52B129445 for ; Mon, 12 Dec 2016 10:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896] 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 d0rZ9PUk9aLW for ; Mon, 12 Dec 2016 10:11:14 -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 34B7B129467 for ; Mon, 12 Dec 2016 10:11:14 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tcrVl5Fj6z3L5; Mon, 12 Dec 2016 19:10:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1481566255; bh=QT5FIeljQgBEtVAtgIcsqXl+fNVbkADius6dyomvNk8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mmRXMKEA6rGKpbOiJGVknQW4IeGhmRsZYdmxtG9fjm1osQbjz/ij9oSc5fBG5ycZI aXvN2cyfHopHc5tAfdZYYQnAArh5f86yh6Rl2GfomUWOMd2CuaPNPP7f5uIxNXNghY bqtaPq7gmgkaixnaLcs4tDfEeS4JBVGazbRYw4F8= 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 p_iT07w-qduZ; Mon, 12 Dec 2016 19:10:54 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 12 Dec 2016 19:10:53 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0D200506F87; Mon, 12 Dec 2016 13:10:51 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0D200506F87 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EA637421AF6D; Mon, 12 Dec 2016 13:10:51 -0500 (EST) Date: Mon, 12 Dec 2016 13:10:51 -0500 (EST) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:11:15 -0000 On Fri, 9 Dec 2016, Kathleen Moriarty wrote: > Hello, > Thanks for your work on draft-ietf-ipsecme-rfc4307bis.  I reviewed the draft and just have a few questions, the first is a nit. > > > Nit: > In the second paragraph of 1.3, you can drop the last two words of this sentence as they are redundant: > > This document does not give any recommendations for the use of > algorithms, it only gives implementation recommendations for > implementations. Will do if we do a new draft version, or else will remind RFC editor of it. > In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD or SHOULD- for: > > PRF_HMAC_SHA1 | MUST- | > > | AUTH_HMAC_SHA1_96 | MUST- > The justifications seems like a bigger jump would be appropriate. In 4307 itself, we only had one MUST and that was SHA1. The SHOULD+ candidate was AES_XCBC but it was been overtaken in reality by SHA2. And AESPRF/AES_MAC is not as widely implemented (example: not available in NSS) so even those implementors who picked the MUST and SHOULD algorithm only have SHA1 and AESPRF/AES_MAC. If a 4307bis implementation only implements the MUST algorithms, it would not interop with a 4307 implementation that implemented all the MUST and SHOULDs, if we made SHA1 a SHOULD- or less. I think the available options we have are MUST- or SHOULD-. I think MAY or SHOULD NOT would lead to interoperability issues. I think the MUST- is still the best choice. Note also that all SHA1 use here is still safe (HMAC and PRF are different from plain SHA1) Note though that I would like to keep the status for Type 2 and Type 3 the same, because all sane implementations will use the same INTEG and PRF algorithms for a given IKE session, so these two are tightly coupled. Paul From nobody Tue Dec 13 10:47:05 2016 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 46149129472 for ; Tue, 13 Dec 2016 10:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sAe313Zvy570 for ; Tue, 13 Dec 2016 10:47:00 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 20BD7129492 for ; Tue, 13 Dec 2016 10:47:00 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id y124so30557538iof.1 for ; Tue, 13 Dec 2016 10:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PrhXMpEbNY9NmxwC/BLl9HZ19ZtVIWY80tCPtypXmtU=; b=Ta5f1oFwRLJel+5iybDRinSrgnGCrmCJJKSwvo3RbSIuDLYbGeKt/8xFz3K2RYBgBH rgwbkXb3E6fzgxZ61a3lQidEfBldzN00SNfpxEejNim2keitqdTGPry+dDbbeAxfCu+Z gDBhcBuEG67WqYGjZ6jWqonVMKZEzTdH9vYocNJZJa53Ip0Adf35MNaP/1QFsZlf7yaq p70KC4oJaCrYYuzRuIDJm9sDa/8BOZd/u++O+SemxazwGB9q9UGAnMYpTNPeL7eqNT4C TiZ0gmSM4TrjmfZ4gq/umCUeivmVEqlwZw77n0kwd0ViVJV3hinwcdJuLDHcEGRmA4Fm yr2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PrhXMpEbNY9NmxwC/BLl9HZ19ZtVIWY80tCPtypXmtU=; b=QZDN/p8BKtV7pa3YERYDxK7T+ZfnTDufDMO0zwhkaM23+q/2y11EhSs5qY/kJ77arv Z2CvyAXewVu1NVyXnwpJbwKoj+nNc66UbKUJVH0bSLDixCk8PQp8+ObUlVUCUQhUNfne JF6u2bJoUgmyvmBOZBx7/3+J0Pmaqqj3LziSw1qBm6waLIl1aqyZsP20vNmtEhZEpezk Ygjebnki0OGlOBEC+k2sVqX6mZY3bmbOZJnj00GwN5V5ERrfosUPMOvfGLc10RoV/MZD rRtaJUBpEzZy7dEKEyy/hb8kWYVa8dWP3r8v+6GtGwAsFgMvuCFbNksrzke4CkgB9OXP 1Xhg== X-Gm-Message-State: AKaTC01k6RLMSPILk2eils+/CWK/TZO5N3VAhVQ34mT5LgxWFnvBAGYwZ4PPFnILemqNpdIRGiqBqzmlS0pI7A== X-Received: by 10.107.44.5 with SMTP id s5mr88816547ios.10.1481654819317; Tue, 13 Dec 2016 10:46:59 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.59.214 with HTTP; Tue, 13 Dec 2016 10:46:58 -0800 (PST) In-Reply-To: <9BC86578-38FF-45D5-8A21-887A224E772D@apple.com> References: <147448964321.14590.5635818993002735779.idtracker@ietfa.amsl.com> <145AF2E4-1622-4177-89EC-FFDD146BEFD4@apple.com> <9BC86578-38FF-45D5-8A21-887A224E772D@apple.com> From: Daniel Migault Date: Tue, 13 Dec 2016 19:46:58 +0100 X-Google-Sender-Auth: a_VkIUG4-H2v3kDx15XtmtqsykM Message-ID: To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a113944902f6c0205438ea545 Archived-At: Cc: IPsecME WG , Paul Wouters , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] New Version of Split DNS for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 18:47:03 -0000 --001a113944902f6c0205438ea545 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please find my comments on draft-pauly-ipsecme-split-dns-02. Yours, Daniel 3. Protocol Exchange 3.1. Configuration Request An initiator MAY convey its current DNSSEC trust anchors for the domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does not wish to convey this information, it MUST use a length of 0. MGLT: I think a high level explanation may be needed for the reader to understand why the initiator provides the trust anchor but maybe that is the responder and not the initiator. 3.2. Configuration Reply For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute, one or more INTERNAL_DNSSEC_TA attributes MAY be included by the responder. This attribute lists the corresponding DSSNEC MGLT: DNSSEC trust anchor in the DNS wire format of a DS record as specified in [RFC4034]. MGLT: I think that is te first time in the draft that mentions the TA is in fact the hash of it. That is fine, but maybe that could be mentioned earlier in the introduction for example. In case that storing TA as DS is defined somewhere a reference to that document might be useful. Otherwise, maybe we should mention that is a common practice. What I would like to point is that we may have to re-read the draft with that in mind. 3.4. Example Exchanges 3.4.2. Requesting Limited Domains In this example exchange, the initiator requests INTERNAL_IP4_DNS and INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, specifically requesting only "example.com" and "other.com". The responder replies with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and two domains, "example.com" and "city.other.com". Note that one of the domains in the CFG_REPLY, "city.other.com", is a subset of the requested domain, "other.com". This indicates that hosts within "other.com" that are not within "city.other.com" should be resolved using an external DNS server. MGLT: I migth be wrong but can *.other.com stands for example.other.com as well as example.city.other.com. If so how wildcard is handled. Maybe the wildcard use case should be explained. 5. Split DNS Usage Guidelines An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing domains that are designated Special Use Domain Names in [RFC6761], such as "local", "localhost", "invalid", etc. Although it may explicitly wish to support some Special Use Domain Names. MGLT: It sounds to me that deciding how to handle the .local is part of the initiator policy. I would propose something around. Handling domains that are designated Special Use Domain Names in [RFC6761], such as "local", "localhost", "invalid", etc. with the INTERNAL_DNS_DOMAIN is part of the initiator's policy. Unless the initiator explicitly wish to support some Special Use Domain Names, it SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing Special Use Domain Names. I think there is a "dommain" somewhere in the text.... On Mon, Oct 17, 2016 at 6:33 PM, Tommy Pauly wrote: > Hello, > > I=E2=80=99d like to see if there were any further comments on this draft.= We > incorporated the feedback we got from Paul H, Tero, and Daniel=E2=80=94ca= n you > review the recent version and see if the changes look good? > > Thanks, > Tommy > > > On Sep 21, 2016, at 2:23 PM, Tommy Pauly wrote: > > Hello all, > > We've posted a new version of draft-pauly-ipsecme-split-dns ( > https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02). > > The changes in this version include: > > - Textual clarification based on input from Daniel and Tero > - Clarification of DNSSEC payload types > - Update on the content and structure of the INTERNAL_DNSSEC_TA attribute > - How to associate DNSSEC values with specific domains > - Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS) > > We believe this should be ready for adoption and moving forward, to follo= w > the charter. Please review and provide your input! > > Thanks, > Tommy > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-pauly-ipsecme-split-dns-02.txt* > *Date: *September 21, 2016 at 1:27:23 PM PDT > *To: *Tommy Pauly , Paul Wouters > > > A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt > has been successfully submitted by Tommy Pauly and posted to the > IETF repository. > > Name: draft-pauly-ipsecme-split-dns > Revision: 02 > Title: Split DNS Configuration for IKEv2 > Document date: 2016-09-21 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft- > pauly-ipsecme-split-dns-02.txt > Status: https://datatracker.ietf.org/doc/draft-pauly- > ipsecme-split-dns/ > Htmlized: https://tools.ietf.org/html/draft-pauly-ipsecme- > split-dns-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-pauly- > ipsecme-split-dns-02 > > Abstract: > This document defines two Configuration Payload Attribute Types for > the IKEv2 protocol that add support for private DNS domains. These > domains should be resolved using DNS servers reachable through an > IPsec connection, while leaving all other DNS resolution unchanged. > This approach of resolving a subset of domains using non-public DNS > servers is referred to as "Split DNS". > > > > > 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 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001a113944902f6c0205438ea545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find my comments o= n draft-pauly-ipsecme-split-dns-02.

Yours,
Daniel


3.=C2=A0 Protocol Exchange

3.1.=C2=A0 Configurat= ion Request

=C2=A0=C2=A0 An initiator MAY convey its current DNSSEC = trust anchors for the
=C2=A0=C2=A0 domain specified in the INTERNAL_DNS_= DOMAIN attribute.=C2=A0 If it does
=C2=A0=C2=A0 not wish to convey this = information, it MUST use a length of 0.

MGLT: I think a high level e= xplanation may be needed for the reader to understand why the initiator pro= vides the trust anchor but maybe that is the responder and not the initiato= r.

=C2=A0=C2=A0
3.2.=C2=A0 Configuration Reply

=C2=A0=C2= =A0 For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
= =C2=A0=C2=A0 one or more INTERNAL_DNSSEC_TA attributes MAY be included by t= he
=C2=A0=C2=A0 responder.=C2=A0 This attribute lists the corresponding = DSSNEC

MGLT: DNSSEC

=C2=A0=C2=A0 trust
=C2=A0=C2=A0 anchor= in the DNS wire format of a DS record as specified in
=C2=A0=C2=A0 [RFC= 4034].

MGLT: I think that is te first time in the draft that mention= s the TA is in fact the hash of it. That is fine, but maybe that could be m= entioned earlier in the introduction for example. In case that storing TA a= s DS is defined somewhere a reference to that document might be useful. Oth= erwise, maybe we should mention that is a common practice. What I would lik= e to point is that we may have to re-read the draft with that in mind.=C2= =A0

=C2=A0
3.4.=C2=A0 Example Exchanges

3.4.2.=C2=A0 Requ= esting Limited Domains

=C2=A0=C2=A0 In this example exchange, the in= itiator requests INTERNAL_IP4_DNS and
=C2=A0=C2=A0 INTERNAL_DNS_DOMAIN a= ttributes in its CFG_REQUEST, specifically
=C2=A0=C2=A0 requesting only = "example.com" and "other.com".=C2=A0 The responder replies
= =C2=A0=C2=A0 with two DNS server addresses, 198.51.100.2 and 198.51.100.4, = and two
=C2=A0=C2=A0 domains, "examp= le.com" and "city.other.com= ".=C2=A0 Note that one of the
=C2=A0=C2=A0 domains in the CFG_R= EPLY, "city.other.com", is = a subset of the
=C2=A0=C2=A0 requested domain, "other.com".=C2=A0 This indicates that hosts within
= =C2=A0=C2=A0 "other.com" that ar= e not within "city.other.com&quo= t; should be resolved
=C2=A0=C2=A0 using an external DNS server.

= MGLT: I migth be wrong but can *.other.com= stands for example.other.com as w= ell as example.city.other.com= . If so how wildcard is handled. Maybe the wildcard use case should be expl= ained.=C2=A0
=C2=A0=C2=A0

5.=C2=A0 Split DNS Usage Guidelines
=C2=A0=C2=A0=C2=A0 An initiator SHOULD ignore INTERNAL_DNS_DOMAIN att= ributes containing
=C2=A0=C2=A0 domains that are designated Special Use = Domain Names in [RFC6761],
=C2=A0=C2=A0 such as "local", "= ;localhost", "invalid", etc.=C2=A0 Although it may
=C2=A0= =C2=A0 explicitly wish to support some Special Use Domain Names.

=C2= =A0MGLT: It sounds to me that deciding how to handle the .local is part of = the initiator policy. I would propose something around.
=C2=A0
=C2= =A0Handling domains that are designated Special Use Domain Names in [RFC676= 1], such as "local", "localhost", "invalid", = etc. with the INTERNAL_DNS_DOMAIN is part of the initiator's policy. Un= less the initiator explicitly wish to support some Special Use Domain Names= , it SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing Special Use Do= main Names.
=C2=A0=C2=A0
=C2=A0I think there is a "dommain&quo= t; somewhere in the text....

=C2=A0

On Mon, Oct 17, 2016 at 6:3= 3 PM, Tommy Pauly <tpauly@apple.com> wrote:
Hello,
=
I=E2=80=99d like to see if there were any further comments o= n this draft. We incorporated the feedback we got from Paul H, Tero, and Da= niel=E2=80=94can you review the recent version and see if the changes look = good?

Thanks,
Tommy

=

O= n Sep 21, 2016, at 2:23 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hello all,
<= br>
We've posted a new version of draft-pauly-ipsecme-split-d= ns (https://tools.ietf.org/html/draft-pauly-ipsecme-sp= lit-dns-02).

The changes in this version = include:

- Textual clarification based on input fr= om Daniel and Tero
- Clarification of DNSSEC payload types
<= div> - Update on the content and structure of the INTERNAL_= DNSSEC_TA attribute
- How to associate DNSSEC va= lues with specific domains
- Naming changes (IPSec -> IPsec, S= plit-DNS -> Split DNS)

We believe this should b= e ready for adoption and moving forward, to follow the charter. Please revi= ew and provide your input!

Thanks,
Tommy=


Begin forwarded message:<= /div>
From: internet-drafts@ietf.org
Subject: New Version = Notification for draft-pauly-ipsecme-split-dns-02.txt
Date: September 21, 201= 6 at 1:27:23 PM PDT
To: Tommy Pauly <tpauly@apple.com>, Paul Wouters <pwouters@redhat.com>


A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt
has been successfully submitted by Tommy Pauly and posted to th= e
IETF repository.

Name: draft-p= auly-ipsecme-split-dns
Revision: 02
Title: <= /span> Split DNS Configuration for IKEv2
Document date:= 2016-09-21
Group: Indi= vidual Submission
Pages: 12
URL: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-pauly= -ipsecme-split-dns-02.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/dra= ft-pauly-ipsecme-split-dns/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://tools.ietf.org/html/draft-pauly-ip= secme-split-dns-02
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/r= fcdiff?url2=3Ddraft-pauly-ipsecme-split-dns-02

Abstract: =C2=A0=C2=A0This document defines two Configuration Payload Attribute Typ= es for
=C2=A0=C2=A0the IKEv2 protocol that add support for private DNS = domains.=C2=A0 These
=C2=A0=C2=A0domains should be resolved using DNS s= ervers reachable through an
=C2=A0=C2=A0IPsec connection, while leaving= all other DNS resolution unchanged.
=C2=A0=C2=A0This approach of resol= ving a subset of domains using non-public DNS
=C2=A0=C2=A0servers is re= ferred to as "Split DNS".




Please note that it = may take a couple of minutes from the time of submission
until the htmli= zed version and diff are available at tools.ietf.org.

The IETF Secretariat


__________________________= _____________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mail= man/listinfo/ipsec


_____= __________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--001a113944902f6c0205438ea545-- From nobody Thu Dec 15 14:03:10 2016 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 E0FD41294B4 for ; Thu, 15 Dec 2016 14:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 vrsIr8J7-RKO for ; Thu, 15 Dec 2016 14:03:05 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 31C1F12946E for ; Thu, 15 Dec 2016 14:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481839384; 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=CHEIi/dwAKhYvzQiItM/Ru3TRZwgT7kJ+9OvPEs+6Sk=; b=C77QXTsvd40zLDW7uaeOGwnqSiJgWIL3khTCoF2/IqX9y9XqBvE2CrqC7f7Ucj0k nKAG+6H1WYxKL6a70Yr4LS4C8KvOqwr4PI6ES2HH9ezKEFrdzKusG1uJeO0IGHx0 r2nE75xKF6dNr0UIsSCg4UPMsRDMsD84cVFQ6Qoky0ZmJ3sG1Z/feug1NBXfoz/V rjOYQst/sYG4Z3YIMv2aIo8IUW07Uj7hThrinZZ5g9G99KvgZ2NcngqrywLxsToN 0os4rFXZGPn0U4cBg2kys4ixRxLzhmEdrl8ANGYXCaSMMuoh31vir5B1zuS+6aT+ XQWcOgebgKxA/we3IsB3cA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 44.63.06020.81313585; Thu, 15 Dec 2016 14:03:04 -0800 (PST) X-AuditID: 11973e12-a7d449a000001784-fb-585313186a13 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 18.C1.23613.81313585; Thu, 15 Dec 2016 14:03:04 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EjszIthRk27RBcFDqJ3WRA)" Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OI800HX5YL4UP30@nwk-mmpp-sz07.apple.com>; Thu, 15 Dec 2016 14:03:04 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <76D59EF4-964F-41F5-9A41-B17445E896FE@apple.com> Date: Thu, 15 Dec 2016 14:03:04 -0800 In-reply-to: To: Daniel Migault References: <147448964321.14590.5635818993002735779.idtracker@ietfa.amsl.com> <145AF2E4-1622-4177-89EC-FFDD146BEFD4@apple.com> <9BC86578-38FF-45D5-8A21-887A224E772D@apple.com> X-Mailer: Apple Mail (2.3300) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUi2FAYpSshHBxhsHOnucWU6XvYLPZvecFm cfT8czaLW+u/sFq8v3WJyYHV49fXq2weS5b8ZPI4/HUhi8f3eUwen2dfZQ5gjeKySUnNySxL LdK3S+DKOL/kDnPBn0uMFWc7e5gbGPt3MHYxcnJICJhIHN18g62LkYtDSGAvo8SV7++YYBJ3 Pr5kgkgcYpSYfvEIM0iCV0BQ4sfkeywgNrNAmMSdY7+ZIYo6mCT+fXwB1MHBISwgIbF5TyJI DZuAisTxbxugem0kLvTOZYEoMZe4NRdsDIuAqsS7bQ/B9nIKBEvsnnmIFWQks0Aro8T9k5/B ekUEDCReTtjJBmILCfxilHiwxBriUFmJwyefskHYv9kktn2PncAoNAvJqbOQnDoLaDWzgLrE lCm5EGFtiSfvLrBC2GoSC38vYkIWX8DItopRKDcxM0c3M89EL7GgICdVLzk/dxMjKI6m2wnt YDy1yuoQowAHoxIP74ItQRFCrIllxZW5hxilOViUxHnzOYMjhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTBuXv8+qk9p4eevO/d7uUifCrmo0vhvtwN/kWXdxOm8k2YFHt2Y27eT3fwy88Wm 9/nCluy//msKLF/vcmfNRVuOp5ou39N4xZ8fWHcv8tSn8w75Ru9YA0z3Gp9scJFStJgV2pf/ +KvxgpQrxrobbs2etfr2LtbzgWk8j34fTNvG/eXq0UV6RSLTlViKMxINtZiLihMBflynjYQC AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUi2FD8QVdCODjC4M9xLYsp0/ewWezf8oLN 4uj552wWt9Z/YbV4f+sSkwOrx6+vV9k8liz5yeRx+OtCFo/v85g8Ps++yhzAGsVlk5Kak1mW WqRvl8CVcX7JHeaCP5cYK8529jA3MPbvYOxi5OSQEDCRuPPxJROELSZx4d56ti5GLg4hgUOM EtMvHmEGSfAKCEr8mHyPBcRmFgiTuHPsNzNEUQeTxL+PL4C6OTiEBSQkNu9JBKlhE1CROP5t A1SvjcSF3rksECXmErfmgo1hEVCVeLftIdheToFgid0zD7GCjGQWaGWUuH/yM1iviICBxMsJ O9lAbCGBX4wSD5ZYQxwqK3H45FO2CYwCs5CcNwvJebOA1jELqEtMmZILEdaWePLuAiuErSax 8PciJmTxBYxsqxgFilJzEivN9BILCnJS9ZLzczcxgiOiMGoHY8Nyq0OMAhyMSjy8C7YERQix JpYVV+YCw4iDWUmEd69gcIQQb0piZVVqUX58UWlOavEhxomMQF9OZJYSTc4HxmteSbyhiYmB ibGxmbGxuYk5LYWVxHk5nAMihATSE0tSs1NTC1KLYI5i4uCUamBsvPA6/rjxl4C2FoEkwfPv O07Wr/b8kamyZpuumYDGuTW+1sJ64W13MtdfjXP4tuLmWv937IUmH2O3LDE5d5olL/686YHQ CuOAtfv2fljxL3j3ktbeLWpq37WlNqZnflcpWnKqzy0i5s2zU6/05uZrXnidJG2R6hQlEXp3 zbp1m28H2+lYTFisxFKckWioxVxUnAgAGVhp//sCAAA= Archived-At: Cc: IPsecME WG , Paul Wouters , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] New Version of Split DNS for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 22:03:08 -0000 --Boundary_(ID_EjszIthRk27RBcFDqJ3WRA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Daniel, Thanks for the review comments! Responses inline. Tommy > On Dec 13, 2016, at 10:46 AM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > Please find my comments on draft-pauly-ipsecme-split-dns-02.=20 >=20 > Yours,=20 > Daniel >=20 >=20 > 3. Protocol Exchange >=20 > 3.1. Configuration Request >=20 > An initiator MAY convey its current DNSSEC trust anchors for the > domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does > not wish to convey this information, it MUST use a length of 0. >=20 > MGLT: I think a high level explanation may be needed for the reader to = understand why the initiator provides the trust anchor but maybe that is = the responder and not the initiator. >=20 Sure, we can add more discussion around this to explain it. > =20 > 3.2. Configuration Reply >=20 > For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute, > one or more INTERNAL_DNSSEC_TA attributes MAY be included by the > responder. This attribute lists the corresponding DSSNEC >=20 > MGLT: DNSSEC =3D) Good catch! >=20 > trust > anchor in the DNS wire format of a DS record as specified in > [RFC4034]. >=20 > MGLT: I think that is te first time in the draft that mentions the TA = is in fact the hash of it. That is fine, but maybe that could be = mentioned earlier in the introduction for example. In case that storing = TA as DS is defined somewhere a reference to that document might be = useful. Otherwise, maybe we should mention that is a common practice. = What I would like to point is that we may have to re-read the draft with = that in mind. =20 >=20 Okay, we can also add more discussion around this in the next update. > =20 > 3.4. Example Exchanges >=20 > 3.4.2. Requesting Limited Domains >=20 > In this example exchange, the initiator requests INTERNAL_IP4_DNS = and > INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, specifically > requesting only "example.com " and "other.com = ". The responder replies > with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and = two > domains, "example.com " and "city.other.com = ". Note that one of the > domains in the CFG_REPLY, "city.other.com = ", is a subset of the > requested domain, "other.com ". This indicates = that hosts within > "other.com " that are not within "city.other.com = " should be resolved > using an external DNS server. >=20 > MGLT: I migth be wrong but can *.other.com stands = for example.other.com as well as = example.city.other.com . If so how = wildcard is handled. Maybe the wildcard use case should be explained. =20= > =20 We have some text in section 5 around how the segments in the domain are = complete segments. This covers part of the behavior. For example, if the INTERNAL_DNS_DOMAIN attribute specifies "example.com", then "example.com", "www.example.com" and "mail.eng.example.com" MUST be resolved using the internal DNS resolver(s), but "anotherexample.com" and "ample.com" MUST be resolved using the system's external DNS resolver(s). I don't want people to be using an actual * wildcard in the protocol, = though. I'll probably add a mention in the text that * does not imply a = wildcard and should not be used. >=20 > 5. Split DNS Usage Guidelines >=20 > An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes = containing > domains that are designated Special Use Domain Names in [RFC6761], > such as "local", "localhost", "invalid", etc. Although it may > explicitly wish to support some Special Use Domain Names. >=20 > MGLT: It sounds to me that deciding how to handle the .local is part = of the initiator policy. I would propose something around.=20 > =20 > Handling domains that are designated Special Use Domain Names in = [RFC6761], such as "local", "localhost", "invalid", etc. with the = INTERNAL_DNS_DOMAIN is part of the initiator's policy. Unless the = initiator explicitly wish to support some Special Use Domain Names, it = SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing Special Use = Domain Names.=20 That's a better wording, yes. Will change. > =20 > I think there is a "dommain" somewhere in the text....=20 Quite right. Again, thanks for catching! >=20 > =20 >=20 > On Mon, Oct 17, 2016 at 6:33 PM, Tommy Pauly > wrote: > Hello, >=20 > I=E2=80=99d like to see if there were any further comments on this = draft. We incorporated the feedback we got from Paul H, Tero, and = Daniel=E2=80=94can you review the recent version and see if the changes = look good? >=20 > Thanks, > Tommy >=20 >=20 >> On Sep 21, 2016, at 2:23 PM, Tommy Pauly > wrote: >>=20 >> Hello all, >>=20 >> We've posted a new version of draft-pauly-ipsecme-split-dns = (https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 = ). >>=20 >> The changes in this version include: >>=20 >> - Textual clarification based on input from Daniel and Tero >> - Clarification of DNSSEC payload types >> - Update on the content and structure of the INTERNAL_DNSSEC_TA = attribute >> - How to associate DNSSEC values with specific domains >> - Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS) >>=20 >> We believe this should be ready for adoption and moving forward, to = follow the charter. Please review and provide your input! >>=20 >> Thanks, >> Tommy >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-pauly-ipsecme-split-dns-02.txt >>> Date: September 21, 2016 at 1:27:23 PM PDT >>> To: Tommy Pauly >, Paul = Wouters > >>>=20 >>>=20 >>> A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt >>> has been successfully submitted by Tommy Pauly and posted to the >>> IETF repository. >>>=20 >>> Name: draft-pauly-ipsecme-split-dns >>> Revision: 02 >>> Title: Split DNS Configuration for IKEv2=20 >>> Document date: 2016-09-21 >>> Group: Individual Submission >>> Pages: 12 >>> URL: = https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ = >>> Htmlized: = https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-pauly-ipsecme-split-dns-02 = >>>=20 >>> Abstract: >>> This document defines two Configuration Payload Attribute Types = for >>> the IKEv2 protocol that add support for private DNS domains. = These >>> domains should be resolved using DNS servers reachable through an >>> IPsec connection, while leaving all other DNS resolution = unchanged. >>> This approach of resolving a subset of domains using non-public = DNS >>> servers is referred to as "Split DNS". >>>=20 >>>=20 >>>=20 >>>=20 >>> 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 = . >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 --Boundary_(ID_EjszIthRk27RBcFDqJ3WRA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Daniel,

Thanks for the review comments! = Responses inline.

Tommy

On Dec 13, 2016, at 10:46 AM, Daniel Migault = <daniel.migault@ericsson.com> wrote:

Hi,

Please find my comments on = draft-pauly-ipsecme-split-dns-02.

Yours,
Daniel


3.  = Protocol Exchange

3.1.  Configuration = Request

   An initiator MAY = convey its current DNSSEC trust anchors for the
  = domain specified in the INTERNAL_DNS_DOMAIN attribute.  If it = does
   not wish to convey this information, it = MUST use a length of 0.

MGLT: I think a = high level explanation may be needed for the reader to understand why = the initiator provides the trust anchor but maybe that is the responder = and not the initiator.

Sure, we can add = more discussion around this to explain it.

  
3.2.  = Configuration Reply

   For each = DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
   one or more INTERNAL_DNSSEC_TA attributes MAY be = included by the
   responder.  This = attribute lists the corresponding DSSNEC

MGLT: DNSSEC

=3D) Good catch!


   trust
   anchor in the DNS wire format of a DS record as = specified in
   [RFC4034].

MGLT: I think that is te first time in the draft that = mentions the TA is in fact the hash of it. That is fine, but maybe that = could be mentioned earlier in the introduction for example. In case that = storing TA as DS is defined somewhere a reference to that document might = be useful. Otherwise, maybe we should mention that is a common practice. = What I would like to point is that we may have to re-read the draft with = that in mind. 


Okay, we can also add more discussion around this = in the next update.

 
3.4.  Example = Exchanges

3.4.2.  Requesting Limited = Domains

   In this example = exchange, the initiator requests INTERNAL_IP4_DNS and
   INTERNAL_DNS_DOMAIN attributes in its = CFG_REQUEST, specifically
   requesting only "example.com" and "other.com".  The = responder replies
   with two DNS server = addresses, 198.51.100.2 and 198.51.100.4, and two
   domains, "example.com" and "city.other.com".  Note that one of the
   domains in the CFG_REPLY, "city.other.com", is a = subset of the
   requested domain, "other.com".  This = indicates that hosts within
   "other.com" that are not within = "city.other.com" = should be resolved
   using an external DNS = server.

MGLT: I migth be wrong but can *.other.com stands for example.other.com as = well as example.city.other.com. If so how wildcard is handled. = Maybe the wildcard use case should be explained. 
  

We have some text in section 5 around how the = segments in the domain are complete segments. This covers part of the = behavior.

For = example, if the
   INTERNAL_DNS_DOMAIN = attribute specifies "example.com", then
   "example.com", "www.example.com" and "mail.eng.example.com" = MUST be
   resolved using the internal = DNS resolver(s), but "anotherexample.com"
   and = "ample.com" MUST be resolved = using the system's external DNS
  =  resolver(s).

I don't want people to be using an actual * wildcard in the = protocol, though. I'll probably add a mention in the text that * does = not imply a wildcard and should not be used.


5.  Split DNS Usage Guidelines

    An initiator SHOULD ignore = INTERNAL_DNS_DOMAIN attributes containing
   = domains that are designated Special Use Domain Names in [RFC6761],
   such as "local", "localhost", "invalid", = etc.  Although it may
   explicitly wish to = support some Special Use Domain Names.

 MGLT: It sounds to me that deciding how to handle the = .local is part of the initiator policy. I would propose something = around.
 
 Handling domains that = are designated Special Use Domain Names in [RFC6761], such as "local", = "localhost", "invalid", etc. with the INTERNAL_DNS_DOMAIN is part of the = initiator's policy. Unless the initiator explicitly wish to support some = Special Use Domain Names, it SHOULD ignore INTERNAL_DNS_DOMAIN = attributes containing Special Use Domain Names.

That's a better wording, yes. Will = change.

  
 I think there is a = "dommain" somewhere in the text....

Quite right. Again, thanks for catching!

 

On Mon, = Oct 17, 2016 at 6:33 PM, Tommy Pauly <tpauly@apple.com> wrote:
Hello,

I=E2=80=99d like to see = if there were any further comments on this draft. We incorporated the = feedback we got from Paul H, Tero, and Daniel=E2=80=94can you review the = recent version and see if the changes look good?

Thanks,
Tommy


On Sep 21, = 2016, at 2:23 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hello = all,

We've = posted a new version of draft-pauly-ipsecme-split-dns (https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).

The changes in this version include:

- Textual clarification based on input = from Daniel and Tero
- Clarification of DNSSEC = payload types
- Update on the content and = structure of the INTERNAL_DNSSEC_TA attribute
- How to associate DNSSEC values = with specific domains
- Naming changes (IPSec -> = IPsec, Split-DNS -> Split DNS)

We believe this should be ready for = adoption and moving forward, to follow the charter. Please review and = provide your input!

Thanks,
Tommy


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-pauly-ipsecme-split-dns-02.txt
Date: = September 21, 2016 at 1:27:23 PM = PDT
To: = Tommy Pauly <tpauly@apple.com>, Paul Wouters <pwouters@redhat.com>


A new version = of I-D, draft-pauly-ipsecme-split-dns-02.txt
has been successfully submitted by Tommy Pauly and posted to = the
IETF repository.

Name: draft-pauly-ipsecme-split-dns
Revision: 02
Title: Split DNS Configuration for IKEv2 =
Document date: 2016-09-21
Group: Individual Submission
Pages: 12
URL: =            https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/
Htmlized: =       https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-pauly-ipsecme-split-dns-02

Abstract:
  This document defines = two Configuration Payload Attribute Types for
=   the IKEv2 protocol that add support for private DNS = domains.  These
  domains should be = resolved using DNS servers reachable through an
=   IPsec connection, while leaving all other DNS resolution = unchanged.
  This approach of resolving a = subset of domains using non-public DNS
=   servers is referred to as "Split DNS".




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


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



= --Boundary_(ID_EjszIthRk27RBcFDqJ3WRA)-- From nobody Fri Dec 16 12:45:12 2016 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 828CB129B87 for ; Fri, 16 Dec 2016 12:45:11 -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, HTML_MESSAGE=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 7xTnuywZWhGS for ; Fri, 16 Dec 2016 12:45:08 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 C751B1296CB for ; Fri, 16 Dec 2016 12:45:01 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 3so34043542uaz.3 for ; Fri, 16 Dec 2016 12:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MNNBJIPA7tTMV9akrYuAtlhZCEKqB9jMfDF8BlrzJjI=; b=E+nkzmuGENvaA2ACFHAu8PGC5PaFikPG/A+S+c2LglV67dCCKbtKzARTxqkW+A3aTm 6d4UsapxQauoJC9kq9lnBbH5fXyOuNgFKN8Or7/Bd7qj2JW+H5aXMH0q/wNlVnaXAQXd 75QLhtjjMg1tOLw9iXD3XFqPKCKbORBR08LlAYpZ76PTWdYV/v1U8HpYh7DBsTWJIBaH WvQu+0LG1hQWtwsJe532FnngtdONV+6YfIJnCBEI5Q0dECiic4GKUSkJdQKptg5a81ak 67cspwUYKp1iIMo9cTrgQAWij61kS1CSLVahV4/O6KZxfOj6hvN0PmfG0uSjc48MlceM q6Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MNNBJIPA7tTMV9akrYuAtlhZCEKqB9jMfDF8BlrzJjI=; b=FJRdsFHoxjNmN9NbRzbP6L0P5H1SOv+hP1EN6zoxRMjPf6Q7LXGy/egVWMC2MtR/3b F6cJZCP+uADEPlTGlEftMkeIgyK8mSmKpMS45zQt0toum6cFu8tkDd5PydMCgfhLvOLt Mi5sOUKYKXmAHeIKXL0fBNym3jiKY8yGsmR1BtbX4XB8htIAupKcawbVIapEh8l/Xf9C jz2Lc57BiOsI9DRWBwrDjPLnCrctNwQoP+W9GXadbPAZppgjb2V9gXY4Mi5nCinj8SuE TqI8QJOGG7Tp2d6hVomp+Fxbr2Jepa789jTHNgMCCr+lIqWPFZPWpL6MkUDCjGzyOjDb 4J1Q== X-Gm-Message-State: AKaTC00zKKJHdaPnwwyS34e4oMrr4uryw8A++Hm+ebY/0v/4rrH8/dNG9RvfOJ2j9zPTJK1vpZMZH2zrLW/ToA== X-Received: by 10.176.82.214 with SMTP id w22mr4317494uaw.167.1481921090599; Fri, 16 Dec 2016 12:44:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.82.232 with HTTP; Fri, 16 Dec 2016 12:44:50 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 16 Dec 2016 15:44:50 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=94eb2c18fad030c2320543cca4e5 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 20:45:11 -0000 --94eb2c18fad030c2320543cca4e5 Content-Type: text/plain; charset=UTF-8 Hi Paul, Thanks for your response and sorry for my delayed response. On Mon, Dec 12, 2016 at 1:10 PM, Paul Wouters wrote: > On Fri, 9 Dec 2016, Kathleen Moriarty wrote: > > Hello, >> Thanks for your work on draft-ietf-ipsecme-rfc4307bis. I reviewed the >> draft and just have a few questions, the first is a nit. >> >> >> Nit: >> In the second paragraph of 1.3, you can drop the last two words of this >> sentence as they are redundant: >> >> This document does not give any recommendations for the use of >> algorithms, it only gives implementation recommendations for >> implementations. >> > > Will do if we do a new draft version, or else will remind RFC editor of it. Great. > > > In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD or >> SHOULD- for: >> >> PRF_HMAC_SHA1 | MUST- | >> >> | AUTH_HMAC_SHA1_96 | MUST- The justifications seems like a bigger >> jump would be appropriate. >> > > In 4307 itself, we only had one MUST and that was SHA1. The SHOULD+ > candidate was AES_XCBC but it was been overtaken in reality by SHA2. > And AESPRF/AES_MAC is not as widely implemented (example: not > available in NSS) so even those implementors who picked the MUST > and SHOULD algorithm only have SHA1 and AESPRF/AES_MAC. If a 4307bis > implementation only implements the MUST algorithms, it would not interop > with a 4307 implementation that implemented all the MUST and SHOULDs, > if we made SHA1 a SHOULD- or less. > > I think the available options we have are MUST- or SHOULD-. I think > MAY or SHOULD NOT would lead to interoperability issues. I think the > MUST- is still the best choice. > > Note also that all SHA1 use here is still safe (HMAC and PRF are > different from plain SHA1) > > Note though that I would like to keep the status for Type 2 and Type 3 > the same, because all sane implementations will use the same INTEG and > PRF algorithms for a given IKE session, so these two are tightly > coupled. Yeah, I knew it was fine, but the justification provided was enough to drop it further, so I wanted to poke at that a bit as it'll take the next update to drop it further. If that's what the WG agreed to, that's fine. I'll push this through to IETF last call unless the WG wants me to wait until after the holidays. Thank you, Kathleen > > > Paul > -- Best regards, Kathleen --94eb2c18fad030c2320543cca4e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for your response and s= orry for my delayed response.

On Mon, Dec 12, 2016 at 1:10 PM, Paul Wouters <paul@nohats.c= a> wrote:
= On Fri, 9 Dec 2016, Kathleen Moriarty wrote:

Hello,
Thanks for your work on draft-ietf-ipsecme-rfc4307bis.=C2=A0 I reviewe= d the draft and just have a few questions, the first is a nit.


Nit:
In the second paragraph of 1.3, you can drop the last two words of this sen= tence as they are redundant:

=C2=A0 =C2=A0This document does not give any recommendations for the use of=
=C2=A0 =C2=A0algorithms, it only gives implementation recommendations for =C2=A0 =C2=A0implementations.

 Will do if we do a new draft version, or else will remind RFC editor of it.=

Great.=C2=A0


In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD = or SHOULD- for:

PRF_HMAC_SHA1=C2=A0 =C2=A0 =C2=A0| MUST-=C2=A0 =C2=A0 |

| AUTH_HMAC_SHA1_96=C2=A0 =C2=A0 =C2=A0 | MUST- The justifications seems li= ke a bigger jump would be appropriate.

 In 4307 itself, we only had one MUST and that was SHA1. The SHOULD+
candidate was AES_XCBC but it was been overtaken in reality by SHA2.
And AESPRF/AES_MAC is not as widely implemented (example: not
available in NSS) so even those implementors who picked the MUST
and SHOULD algorithm only have SHA1 and AESPRF/AES_MAC. If a 4307bis
implementation only implements the MUST algorithms, it would not interop with a 4307 implementation that implemented all the MUST and SHOULDs,
if we made SHA1 a SHOULD- or less.

I think the available options we have are MUST- or SHOULD-. I think
MAY or SHOULD NOT would lead to interoperability issues. I think the
MUST- is still the best choice.

Note also that all SHA1 use here is still safe (HMAC and PRF are
different from plain SHA1)

Note though that I would like to keep the status for Type 2 and Type 3
the same, because all sane implementations will use the same INTEG and
PRF algorithms for a given IKE session, so these two are tightly
coupled.

Yeah, I knew it was fine, but the = justification provided was enough to drop it further, so I wanted to poke a= t that a bit as it'll take the next update to drop it further.=C2=A0 If= that's what the WG agreed to, that's fine.=C2=A0 I'll push thi= s through to IETF last call unless the WG wants me to wait until after the = holidays.

Thank you,
Kathleen=C2=A0


Paul



--

Best regards,
Kathleen
--94eb2c18fad030c2320543cca4e5-- From nobody Fri Dec 16 12:54:11 2016 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 E6F9D12951B; Fri, 16 Dec 2016 12:54:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148192164790.14691.13592251189756149865.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2016 12:54:07 -0800 Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-rfc4307bis@ietf.org, David Waltermire Subject: [IPsec] Last Call: (Algorithm Implementation Requirements and Usage Guidance for IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 20:54:08 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Algorithm Implementation Requirements and Usage Guidance for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Dec 29 04:43:35 2016 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 BB615129595 for ; Thu, 29 Dec 2016 04:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFv1CHmJdC_x for ; Thu, 29 Dec 2016 04:43:33 -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 76F351295C0 for ; Thu, 29 Dec 2016 04:43:31 -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 uBTChKtp014738 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Dec 2016 14:43:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uBTChJie008355; Thu, 29 Dec 2016 14:43:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22629.1255.436519.295663@fireball.acr.fi> Date: Thu, 29 Dec 2016 14:43:19 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <00a101d25157$48cbb500$da631f00$@gmail.com> References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> <22601.24119.100454.380354@fireball.acr.fi> <00a101d25157$48cbb500$da631f00$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 14 min Archived-At: Cc: 'IPsecme WG' , 'Michael Richardson' , 'Yoav Nir' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 12:43:34 -0000 Valery Smyslov writes: > Hi Tero, >=20 > > > CREATE=5FCHILD=5FSA exchange and rekey the IKE SA using PPK. But > > > CREATE=5FCHILD=5FSA doesn=E2=80=99t allow to exchange identities.= So, if > > > pseudonyms were used in IKE=5FAUTH, how are you going to exchange= real > > > identities=3F > >=20 > > Real IDs are never exchanged over wire. The server sees pseudonym >=20 > Then what is the content of IDi and IDr in IKE=5FAUTH in this case=3F= As I said the IDi would be ID=5FKEY=5FD with value of \x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the normal server side identity, as hiding server identity is usually not useful as server must have static IP so clients can know where to connect. If server side identity protection is also needed, then server side IDr would also be similar pseudonym, but that would require server to keep track of which IDr was given to which client, and pick suitable IDr based on the IDi coming in. > > ID=5FKEY=5FID \x1c747c060d209a223d1f9f51b0351b54, it looks it up fr= om its > > table and finds a mapping from there to kivinen@iki.fi. From then o= n > > it uses kivinen@iki.fi as authenticated identifier, and verifies th= at > > the raw public key, or shared key used to authenticate the user > > actually matches the one configured to the kivinen@iki.fi. > >=20 > > Using certificates in this case would leak out the identity anyways= , > > so they cannot be used, or at least transmitted over wire. Even if > > using raw public keys, the actual public keys must not be sent over= > > wire, it needs to be taken from the configuration. > >=20 > > > And the peers must also somehow prove their real identities, so A= UTH > > > payloads must also be included, and we end up with something like= > > > full IKE=5FAUTH exchange... > >=20 > > This all is done in the server, i.e. instead of using the ID sent o= ver > > the wire, the server uses the ID sent over wire as handle to the > > table, and fetches the real ID to be used for policy decisions and > > authentication from the that table. >=20 > Again, what role the usual authentication (in IKE=5FAUTH) and > usual IKE Identities play in this scenario=3F They would play their normal role, i.e. they would be used to authenticate the connection. The only difference is that the IDi on the wire would not be the real identity but the a random pseudonym, and that pseudonym is then used by the server to fetch the real identity which would then be used for policy purposes. To provide full identity protection, even the server should not use any long term identity like kivinen@iki.fi, but instead just use some kind of user id and map that user id to the actual policy. I.e., the lookup would go like follows: IDi =3D ID=5FKEY=5FID \x1c747c060d209a223d1f9f51b0351b54 -> In server look that id from the known pseudonyms, find entry saying: Pseudonym=5FID =3D \x1c747c060d209a223d1f9f51b0351b54 User=5FID =3D KeyId(\x1234) -> Use User=5FID to search PAD for entry to verify authentication and= find the related SPD Then when the user changes their pseudonym using the protocol defined later the first list of known pseudonyms would be updated to say: Pseudonym=5FID =3D \x056f32ee5cf49404607e368bd8d3f2af User=5FID =3D KeyId(\x1234) where the Pseudonym=5FID is new random pseudonym to be used after that for future exchanges. The User=5FID stays same, but it is just internal= information inside the server, and is never transmitted over the wire. Of course the User=5FID could also be RFC822(kivinen@iki.fi) instead of= that kind of random number, but then hacking in to the server could reveal the real user identities for the clients and their next pseudonyms, so that would be bad idea if full protection is needed. Server does not really need to know who is in the other end, he just needs to know how the other end is going to authenticate himself (i.e., which PAD entry to use), and what kind of policy is allowed for that user (i.e., which SPD entries are used).=20 --=20 kivinen@iki.fi From nobody Thu Dec 29 05:09:11 2016 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 A186712948C for ; Thu, 29 Dec 2016 05:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M29MfIKITec for ; Thu, 29 Dec 2016 05:09: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 2A48E1289B0 for ; Thu, 29 Dec 2016 05:09:08 -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 uBTD8xRs000957 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Dec 2016 15:08:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uBTD8vXW001210; Thu, 29 Dec 2016 15:08:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22629.2793.418553.140726@fireball.acr.fi> Date: Thu, 29 Dec 2016 15:08:57 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 13:09:10 -0000 Scott Fluhrer (sfluhrer) writes: > o There is the option listed in the draft, where we modify both the= KEYMAT > and SKEYSEED computations; stirring it into the KEYMAT implies that t= he IPsec > SAs are generated with QR-resistant keying material, while stirring i= t into > the SKEYSEED implies that any child IKE SAs implies that any IKE SA (= other > than the initial one) also has QR-resistant keying material. This la= tter was > done specifically so that an implementation can have protected IKE SA= s (by > negotiating a child SA immediately) >=20 > o Dan Harkins suggested that we modify only the KEYMAT. This is a = simpler > option, and will continue to protect the IPsec SAs; however this impl= ies that > any data protected by the IKE SA could potentially be recovered by a = Quantum > Computer. This has the issue that differences in the PPK will not be detected, i.e., if PPKs are mismatched because of configuration error, we do get IKEv2 SA up and running, and we create IPsec Child SAs without errors, but then all traffic in IPsec SA will simply be dropped as the keying material is wrong. Also this does not protect IKE SAs at all. > o Valery Smyslov gave a suggestion that we instead stir in the PPK = into the > initial SK=5Fd; as all keying material is generated based on that, th= is would > also mean that IPsec SAs and any child IKE SAs are also protected. T= his also > means that an implementation would not need to remember the PPK after= the > initial negotiation. The only downside I can see is that we would ha= ve to be > a bit careful about when we update the SK=5Fd (obviously, before we a= ctually use > it). This would provide protection for the IPsec SAs and Child IKE SA (i.e. IKE SAs after rekey). It still has same issue that we do not get verification that PPKs are same. > To me, all three strike me as reasonable ideas (unless we decide that= we will > need to protect the real identity data encrypted via the IKE SA; in t= hat case, > Dan=E2=80=99s idea doesn=E2=80=99t protect that). Can I get opinions= as to which strikes the > group as the best=3F Are there any fourth options that people would = want to put > on the table=3F I would propose that we add PPK to both SK=5Fd and SK=5Fpi and SK=5Fpr.= SK=5Fd provides quantum resistance for the IPsec SAs and Child IKE SAs.= The SK=5Fpi and SK=5Fpr provides key verification, meaning that incorre= ct PPKs will result AUTHENTICATION=5FFAILURE notification, instead of just= wrong keys. SK=5Fpi and SK=5Fpr as used to MAC the ID payloads of the peers, and if= we mix PPK in there that might also provide some resistance against quantum computers even when the attackers can break RSA. I.e., it does not matter that they can generate valid signatures if they do not know what they are supposed to sign. > In both cases, the traffic that is protected by the initial IKE SA ca= n be > recovered; that=E2=80=99s because that traffic is encrypted by the in= itial SK=5Fei, > SK=5Fer keys, and those would be recoverable. The important thing is to keep the SK=5Fe*/SK=5Fa* so they do not depen= d on the PPK. The problem with them is that if they depend on the PPK, then we cannot see contents of the packet before we need PPK, so PPK negotiation needs to happen in clear before IKE=5FAUTH. SK=5Fd, SK=5Fpi, and SK=5Fpr all benefit from PPK, and they can and sho= uld use get PPK mixed in to them. I.e., define SK=5Fd' =3D prf(PPK, SK=5Fd) SK=5Fpi' =3D prf(PPK, SK=5Fpi) SK=5Fpr' =3D prf(PPK, SK=5Fpr) and change uses of SK=5Fd, SK=5Fpi and SK=5Fpr to use those. > - The second item is anonymity; some people were interested = in > preserving anonymity (however, not at the expense of excessive comple= xity).=20 > One idea that was brought up was that the initial exchange would be d= one using > pseudonyms (which would be sufficient for the responder to identity t= he PPK), > and then once initial IKE SAs have been established (in a QR form), e= xchange > the real identities. My questions: >=20 > o Would this idea of pseudonyms actually give any real identity pro= tection=3F=20 > Wouldn=E2=80=99t that assume that several initiators use the same PPK= (so they could > use the same pseudonym)=3F Is that the sort of thing we should be en= couraging=3F >=20 > o Should this be addressed in this draft, or could it be addressed = in a > follow-up draft=3F I think we can do that in follow up draft, and I so there is no need to complicate things in this draft. > o If it would be addressed in a follow-up, would any hooks be requi= red=3F For > example, would we want to introduce an opaque bit in a notify message= to > indicate this=3F As I see the pseudonym support, we only need a way to get quantum resistant IKE SA, and Child IKE SA is fine for that, so we already have all the features need. --=20 kivinen@iki.fi From nobody Thu Dec 29 08:47:28 2016 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 4F36D12952C for ; Thu, 29 Dec 2016 08:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 FpZCKiAHVlkw for ; Thu, 29 Dec 2016 08:47:24 -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 814311293F3 for ; Thu, 29 Dec 2016 08:47:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3DE37E224; Thu, 29 Dec 2016 12:06:06 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1531963768; Thu, 29 Dec 2016 11:47:23 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22629.1255.436519.295663@fireball.acr.fi> References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> <22601.24119.100454.380354@fireball.acr.fi> <00a101d25157$48cbb500$da631f00$@gmail.com> <22629.1255.436519.295663@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: 'IPsecme WG' , Valery Smyslov , 'Yoav Nir' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 16:47:26 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > As I said the IDi would be ID_KEY_D with value of > \x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the normal > server side identity, as hiding server identity is usually not useful > as server must have static IP so clients can know where to connect. While I think that the client IDs might be a local implementation issue, if we go down this route, I'd like us the standardize the representation of how they IDs are presented, such that, in theory, a user could type them in. Or, come up with a JSON format for presenting the ID+gateway information. [ I know that many vertically integrated "solutions" have single file solutions like the ".pcf" file from Cisco. I'm suggesting standardizing such a thing] The client ID could well be the real client ID encrypted by the server with a locally kept key. That would eliminate the database lookup for some systems, but that might be important. Again: a local implementation issue. > If server side identity protection is also needed, then server side IDr > would also be similar pseudonym, but that would require server to keep > track of which IDr was given to which client, and pick suitable IDr > based on the IDi coming in. Wow, this is indeed complex, yet I actually think this might matter to systems that have the various (not-standardardized, alas), ad-hoc VPN mechanisms, such that gateways without static IPs can be found. I think that we can leave it out of scope for now, but perhaps we don't really need to say a lot about it, except what you just wrote. > They would play their normal role, i.e. they would be used to > authenticate the connection. The only difference is that the IDi on the > wire would not be the real identity but the a random pseudonym, and > that pseudonym is then used by the server to fetch the real identity > which would then be used for policy purposes. To provide full identity > protection, even the server should not use any long term identity like > kivinen@iki.fi, but instead just use some kind of user id and map that > user id to the actual policy. Previously, in the typical large scale road warrior case, where a client has a certificate signed by a private CA, and the policy is essentially that any client with a valid certificate (modified by OCSP and CRLs, etc.), which is also provided in-band in a CERT payload, and any such client can connect and gets the same policy, I wonder if we can somehow dispense with the IDi completely, or use a constant value. Now, with a Quantum Resistant mechnanism, we are mixing per-host-pair PSK into the resulting IPsec (and perhaps IKE PARENT SA) sessions keys, but I'm unclear if we'd still be using RSA/ECDSA/EdDSA certificates at all. I know that there are QM resistant asymmetric mechanism envisioned, but I know so little about them. > I.e., the lookup would go like follows: > IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54 I think that this is a random string you made up, not a constant value. > Then when the user changes their pseudonym using the protocol defined > later the first list of known pseudonyms would be updated to say: > Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af User_ID = > KeyId(\x1234) > where the Pseudonym_ID is new random pseudonym to be used after that > for future exchanges. The User_ID stays same, but it is just internal > information inside the server, and is never transmitted over the wire. > Of course the User_ID could also be RFC822(kivinen@iki.fi) instead of > that kind of random number, but then hacking in to the server could > reveal the real user identities for the clients and their next > pseudonyms, so that would be bad idea if full protection is needed. Is it reasonable to describe this Pseudonum update mechanism seperately, or do you think it is too heavily connected to the quantum resistance -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhlPhoACgkQgItw+93Q 3WVVBgf/eF0FDhj6zd+utPMSDO5B70fkwPdUyCt56xbbW+bvSbIb8LCG9Wka0Two K/ctnZbmu6oo0l/OXTXy+22Of/8e8swTMxoP4vU46/ZTlbvCL4nS2RabYo6FOM8W yKdnDiAVsV+kM5q4Wd8DUBdVo1mDDKwrI3K7TE/4ER74ejqdAH7oKcp0RKTUDIYC nYXBmYC6gJfG8jFNMnnGw2YMs3mLpD2E8Wmv6aUDCQ3Cb7+1iW8vmxb6N6i9XO8+ 3Jm6bsej7N21HjYemjmZaWwwYrneDdk0+FgIjrdpdQ5PfrwYtEMZdOiQVkqYcBRw RM9zIc3bGTa2PmBovSuMsh1x7EzOdw== =iU6v -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 29 08:51:32 2016 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 99944129476 for ; Thu, 29 Dec 2016 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 63IS9dzY9YUz for ; Thu, 29 Dec 2016 08:51:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531FB129451 for ; Thu, 29 Dec 2016 08:51:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 62548E224; Thu, 29 Dec 2016 12:10:11 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D8CF63768; Thu, 29 Dec 2016 11:51:28 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22629.2793.418553.140726@fireball.acr.fi> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: IETF IPsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 16:51:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> o There is the option listed in the draft, where we modify both the >> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies >> that the IPsec SAs are generated with QR-resistant keying material, >> while stirring it into the SKEYSEED implies that any child IKE SAs >> implies that any IKE SA (other than the initial one) also has >> QR-resistant keying material. This latter was done specifically so >> that an implementation can have protected IKE SAs (by negotiating a >> child SA immediately) >> >> o Dan Harkins suggested that we modify only the KEYMAT. This is a >> simpler option, and will continue to protect the IPsec SAs; however >> this implies that any data protected by the IKE SA could potentially >> be recovered by a Quantum Computer. > This has the issue that differences in the PPK will not be detected, > i.e., if PPKs are mismatched because of configuration error, we do get > IKEv2 SA up and running, and we create IPsec Child SAs without errors, > but then all traffic in IPsec SA will simply be dropped as the keying > material is wrong. I think that this is a *HUGE* user configuration issue. It means that the QM resistance will be turned off first thing whenever the= re is a problem. > SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs. > The SK_pi and SK_pr provides key verification, meaning that incorrect > PPKs will result AUTHENTICATION_FAILURE notification, instead of just > wrong keys. Would it be reasonable to create some token/nonce from something before the PPK is mixed in such that we could recognize the different AUTH FAILUREs, or does that create too much of an oracle for testing PPKs? >> In both cases, the traffic that is protected by the initial IKE SA c= an >> be recovered; that=E2=80=99s because that traffic is encrypted by th= e initial >> SK_ei, SK_er keys, and those would be recoverable. > The important thing is to keep the SK_e*/SK_a* so they do not depend = on > the PPK. The problem with them is that if they depend on the PPK, then > we cannot see contents of the packet before we need PPK, so PPK > negotiation needs to happen in clear before IKE_AUTH. Good. (I haven't spent the time to understand what the changes are to the math, a= nd it's been 10 years since I wrote that code, so please consider me a very clueful end user in these discussions) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhlPxAACgkQgItw+93Q 3WVrEQf/WvpFBRmyJ1uHPid0SeOQZYICwHPPLs94ejdAbKF2O62ie0y/9TRUCq7y 8Qm7Zp4OnXIz+M9aczgN/mi5MI0Wo3TSlX6nGutMmKQO1AFVQFBD8kSFJfElHcAh BB5dVgA95nChlwdveJVff0xCro6rnrcIr77Y5TIosxOv/Y05q0mt56RKF7zHvpGP nPVFwL++xOBXUj883G1sWhsyR7OJc9EAooPqYU2wKjfViPkREyaJUmPZIibbMA01 tMndKIW0qK0lIw31PD++WyEjtjT8EWrvI9Lx4s7+6ppd5j1DpXodR2+NDfp/4B5d bNeeLDxbjqDFFKILnqrdFP/Srz0yag== =qEyw -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 30 06:33:53 2016 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 3554F1294B3 for ; Fri, 30 Dec 2016 06:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZllJHveoGs3 for ; Fri, 30 Dec 2016 06:33:50 -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 4214C124281 for ; Fri, 30 Dec 2016 06:33:50 -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 uBUEXd5A013366 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Dec 2016 16:33:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uBUEXcQS008477; Fri, 30 Dec 2016 16:33:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22630.28738.457623.117059@fireball.acr.fi> Date: Fri, 30 Dec 2016 16:33:38 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <6704.1483030043@obiwan.sandelman.ca> References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> <22601.24119.100454.380354@fireball.acr.fi> <00a101d25157$48cbb500$da631f00$@gmail.com> <22629.1255.436519.295663@fireball.acr.fi> <6704.1483030043@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Cc: 'IPsecme WG' , Valery Smyslov , 'Yoav Nir' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 14:33:52 -0000 Michael Richardson writes: > > If server side identity protection is also needed, then server side IDr > > would also be similar pseudonym, but that would require server to keep > > track of which IDr was given to which client, and pick suitable IDr > > based on the IDi coming in. > > Wow, this is indeed complex, yet I actually think this might matter to > systems that have the various (not-standardardized, alas), ad-hoc VPN > mechanisms, such that gateways without static IPs can be found. > > I think that we can leave it out of scope for now, but perhaps we don't > really need to say a lot about it, except what you just wrote. Yep. Leaving it out of scope for that future draft is fine for me... > > They would play their normal role, i.e. they would be used to > > authenticate the connection. The only difference is that the IDi on the > > wire would not be the real identity but the a random pseudonym, and > > that pseudonym is then used by the server to fetch the real identity > > which would then be used for policy purposes. To provide full identity > > protection, even the server should not use any long term identity like > > kivinen@iki.fi, but instead just use some kind of user id and map that > > user id to the actual policy. > > Previously, in the typical large scale road warrior case, where a client has > a certificate signed by a private CA, and the policy is essentially that any > client with a valid certificate (modified by OCSP and CRLs, etc.), which is > also provided in-band in a CERT payload, and any such client can connect > and gets the same policy, I wonder if we can somehow dispense with the IDi > completely, or use a constant value. > > Now, with a Quantum Resistant mechnanism, we are mixing per-host-pair PSK into the > resulting IPsec (and perhaps IKE PARENT SA) sessions keys, but I'm unclear if > we'd still be using RSA/ECDSA/EdDSA certificates at all. I know that there > are QM resistant asymmetric mechanism envisioned, but I know so little about them. If you really care about the identity protection, you cannot transmit certificates or raw public keys in-band, as those will immediately reveal your identity (or at least the fact that you are same user than last time). You might even reveal this to passive attacker, who might be able to know that this is a@b.com and this other one is long-username@subdomain.example.com by just looking that the length of the IKE_AUTH payload... So with identity protection you want to keep all that authentication information local, and when the server receives the random pseudonym, it can map that to the PAD entry and PAD entry then has either shared-key, certificate or raw public key associated with it and that is used for autentication. > > I.e., the lookup would go like follows: > > > IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54 > > I think that this is a random string you made up, not a constant value. Yep, and it can be changed at any time by using some mechanism we have not yet defined, but which will be run over the IKE SA after we have made it so that it gains resistance against quantum attackers. > > Then when the user changes their pseudonym using the protocol defined > > later the first list of known pseudonyms would be updated to say: > > > Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af User_ID = > > KeyId(\x1234) > > > where the Pseudonym_ID is new random pseudonym to be used after that > > for future exchanges. The User_ID stays same, but it is just internal > > information inside the server, and is never transmitted over the wire. > > Of course the User_ID could also be RFC822(kivinen@iki.fi) instead of > > that kind of random number, but then hacking in to the server could > > reveal the real user identities for the clients and their next > > pseudonyms, so that would be bad idea if full protection is needed. > > Is it reasonable to describe this Pseudonum update mechanism seperately, or > do you think it is too heavily connected to the quantum resistance I do not think it is in any way connected to the quantum resistance, so I think it is better to describe it as separate document. Note, that we even could simply make simple IPsec SA to the web server in the SGW and then use the rest API over http over that IPsec SA and change the pseudonym in that way. The way I described was just one way we can do it, and the actual draft that will define this protocol, needs to decide how it is actually going to work. -- kivinen@iki.fi From nobody Fri Dec 30 06:38:01 2016 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 221EE1294D1 for ; Fri, 30 Dec 2016 06:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eacpZycxZs2g for ; Fri, 30 Dec 2016 06:38: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 492D21294B3 for ; Fri, 30 Dec 2016 06:38:00 -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 uBUEbsZW009008 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Dec 2016 16:37:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uBUEbs6j012402; Fri, 30 Dec 2016 16:37:54 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22630.28994.951210.861178@fireball.acr.fi> Date: Fri, 30 Dec 2016 16:37:54 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <7633.1483030288@obiwan.sandelman.ca> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Cc: IETF IPsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 14:38:01 -0000 Michael Richardson writes: > > This has the issue that differences in the PPK will not be detected, > > i.e., if PPKs are mismatched because of configuration error, we do get > > IKEv2 SA up and running, and we create IPsec Child SAs without errors, > > but then all traffic in IPsec SA will simply be dropped as the keying > > material is wrong. > > I think that this is a *HUGE* user configuration issue. > It means that the QM resistance will be turned off first thing whenever there > is a problem. That is why I think it is important that we do detect the failures correctly. > > SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs. > > The SK_pi and SK_pr provides key verification, meaning that incorrect > > PPKs will result AUTHENTICATION_FAILURE notification, instead of just > > wrong keys. > > Would it be reasonable to create some token/nonce from something before the > PPK is mixed in such that we could recognize the different AUTH FAILUREs, > or does that create too much of an oracle for testing PPKs? I think it is better to keep the AUTHENTICATION_FAILURE to mean both, i.e., not provide an oracle. -- kivinen@iki.fi From nobody Sat Dec 31 19:17:07 2016 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 029EB12961B for ; Sat, 31 Dec 2016 19:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 TXtSJkfUO88a for ; Sat, 31 Dec 2016 19:17:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BC2129539 for ; Sat, 31 Dec 2016 19:17:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CFC020563; Sat, 31 Dec 2016 22:35:55 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EE507638D5; Sat, 31 Dec 2016 22:17:02 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22630.28994.951210.861178@fireball.acr.fi> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <22630.28994.951210.861178@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: IETF IPsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 03:17:06 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > That is why I think it is important that we do detect the failures > correctly. >> > SK_d provides quantum resistance for the IPsec SAs and Child IKE >> SAs. > The SK_pi and SK_pr provides key verification, meaning that >> incorrect > PPKs will result AUTHENTICATION_FAILURE notification, >> instead of just > wrong keys. >>=20 >> Would it be reasonable to create some token/nonce from something >> before the PPK is mixed in such that we could recognize the different >> AUTH FAILUREs, or does that create too much of an oracle for testing >> PPKs? > I think it is better to keep the AUTHENTICATION_FAILURE to mean both, > i.e., not provide an oracle. okay, but can we determine the mismatch enough to log it? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhodK4ACgkQgItw+93Q 3WXXQwgAnvklseAV+1vOz0NYUG1A6hnjB5GUUcT7au9tZtjiQJZOOVjGjttCpnHU dC7pvO0ujP0GcDcghd2WpiQ9BrcHn1ut8Ns46HGHZsFcbTz7YM9OQA3yCf7stC3O LnQvnpTEuYhNf+EKrvjN+3g9jP8D0W4TyxIPSfVm4OPEHW/zBcV3/G9XmITBnOfi PoVyA85/w6tNyzL+avGTvxjj484kbQa7xwsbEdWHV8XTb1UL478y3lf5K5rLQD6t gX6RhSwHuZ84U9hta5WyjnuOMdk03u1uxhjow2hlX9Pv6y9xZZTfFdOOOE09SJyq Y3t5qGDqASL+Ld21KU1AbPmUpMHOVQ== =JVCP -----END PGP SIGNATURE----- --=-=-=--