From nobody Wed Nov 1 10:23:53 2017 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 DF4B813F549 for ; Wed, 1 Nov 2017 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPamJ1ZZqeLf for ; Wed, 1 Nov 2017 10:23:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5D913F936 for ; Wed, 1 Nov 2017 10:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3416; q=dns/txt; s=iport; t=1509557013; x=1510766613; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QEZ17/XCE/QkHCLS+6UgTMt96fWAEFQWVOeweZ0A2Ao=; b=WAqZQA6COTXup6MbeN6DeGyu9CeVoHM0OnF5fCnSMvclKdwFkuoiRHBm 6Go+V5vpgsywzl7fw6wA9h/ZHwHofy+iESu7IrOxDPQ+Q55gkoQn1PmEK PhQnUWwChjaN9NOfuXguvAqH3ry1L6opGSFeAyJleIrDh70duJV9fAfsz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAQC+AvpZ/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1+BUicHjhWPGIF8iFCNdIIRCoU7AoUAFSoYAQIBAQEBAQEBayi?= =?us-ascii?q?FHQEBAQMBOj8MBAIBCBEEAQEBHgkHIREUCQgCBAENBQgSiXEDDQiqeYc4DYNIA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYMqBIIHgVOBaYMqgmqCAIYdBaFOPAKQAYR?= =?us-ascii?q?wkzmNGYhNAhEZAYE4AR84gWx6FYMthF93ik2BM4ERAQEB?= X-IronPort-AV: E=Sophos;i="5.44,329,1505779200"; d="scan'208";a="25300110" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2017 17:23:29 +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 vA1HNTJ2023148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2017 17:23:29 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.1320.4; Wed, 1 Nov 2017 13:23:28 -0400 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.1320.000; Wed, 1 Nov 2017 13:23:28 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters , Valery Smyslov CC: "Panos Kampanakis (pkampana)" , "ipsec@ietf.org" , "'Vukasin Karadzic'" Thread-Topic: draft-ietf-ipsecme-qr-ikev2-00 complexity Thread-Index: AQHTUVKznkBD3l5ZGkCxpEobMJJdw6L/xoKg Date: Wed, 1 Nov 2017 17:23:28 +0000 Message-ID: <352e0e4d95d6408e897421bd8cd9d019@XCH-RTP-006.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-qr-ikev2-00 complexity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:23:41 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Monday, October 30, 2017 3:43 AM > To: Valery Smyslov > Cc: Panos Kampanakis (pkampana) ; Scott Fluhrer > (sfluhrer) ; ipsec@ietf.org; 'Vukasin Karadzic' > > Subject: draft-ietf-ipsecme-qr-ikev2-00 complexity >=20 > On Wed, 23 Aug 2017, Valery Smyslov wrote: >=20 > >> It is a good idea. A new optional notification that includes the > >> auth_data as it would be calculated without the PPK would work. With > >> that, the corner case of ' PPK_id configured on initiator but missing > >> on the responder' is addressed. There is an additional cost of the ext= ra > notification message for every initiator that has no- mandatory ppk > configured for the responder. > > > > Yes, and there is also an extra cost for initiator of performing AUTH > > calculation (e.g. digital signature) twice - one with SK_p' and the > > other with SK_p. Good news are is that it is > > a) is performed by initiator only, so there is no risk of DoS attack > > on responder > > b) is needed only if initiator is configured in "permissive" mode - whe= n its > policy allows both PPK and non-PPK > > SAs with the particular responder >=20 > I've seen this in the -04 draft, and I'm not sure I like it. >=20 > What attacks are we opening up by providing two AUTH payloads to a MITM > attacker? When they receive AUTH payloads with and without PPK, can they > use this as an oracle for the PPK somehow? The attacker in this scenario = of > course has a quantum computer to perform the attack :) If the attacker can enumerate the possible values of the PPK (possibly usin= g Grover's algorithm), such attacks are already possible. For example, if the attacker acts as the responder, then he sees the PPK-in= fluenced AUTH payload, which is a function of the PPK and data which the at= tacker knows. Hence, if the attacker can enumerate the possible PPK values= , he can compute what the AUTH payload would be for each PPK, and thus dedu= ce which is the correct one. And, yes, Grover's algorithm can be used for = this search. Because of this, we recommend that the PPK have a minentropy of 256 bits; t= his prevents this attack, and other oracle attacks which you elude to. >=20 > I think that PPK can be handled with seperate configurations as well. >=20 >=20 > Note also that the use case for this feature is very limited. For access = VPNs > you would have the responder work with or without PPK, and it can just > respond to non-updated initiators without PPK and to updated initiators w= ith > PPK. Initiators only need to have one configuration and stick to it. The = only > use case is a set of gateways, for example for site-to-site connections, = where > some gateways are updated and others are not. Due to PPK support signalin= g > being in the IKE_INIT packet, the gateway cannot know whether or not it > should use PPK or not. But in the real world, almost all those kind of > gateways are on static IPs, and the responding gateway can actually know = for > which configuration the IKE_INIT packet is. This is often not true in my experience; sometimes, the responding gateway = does not have preexisting configuration for every initiator it might be abl= e to handle. From nobody Thu Nov 2 04:26:05 2017 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 ED9FD13F6C9 for ; Thu, 2 Nov 2017 04:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aZKVu3shhAcH for ; Thu, 2 Nov 2017 04:26:03 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 7E4AA13F6DE for ; Thu, 2 Nov 2017 04:26:03 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id k10so1188859otb.0 for ; Thu, 02 Nov 2017 04:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=uWbg52eB4Cm6HCz1ASxWN15C9v4r/fiUc7Brenz1nY8=; b=TApBt7hrphpXC2uUPoTcdNAuVDbtOkTsV5FV8E1GPH5JbFd4KJ9TexQPPBUgARWxw/ No+SpF8NLX7HDD1Mr9OyPxE+1egrdovKGZnBeROvt6+cgOTQkuAobVnDftyOayXDlSG2 jSoFc3LxNbEuHGIQfWHm58yUShCkRuM8TnYG5kkOzUFj9CpcsSpLlNIXtnR1O6wQ62nS PTLYwNJarUo0JOsrmPhXWGcIdW6zWiqUt3iVE8anXlEpL9GWigWYUoAaufCm+iBg9d+t UM5KyG9eFIqodlQfybp7Hlo82ZVasl0JWs7X8py1u5y81zstT5uTs9geZOvuAwylY8rV vGsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=uWbg52eB4Cm6HCz1ASxWN15C9v4r/fiUc7Brenz1nY8=; b=aCL/3hk64ZKRDbhx1snJ/1Gui9/uyCvoUTuYsu4Pw5WsZCT19lu3fWpWor8qaSevhj qEsoY2Qttqerrcwhpj4YttkkxHbQsG+ciudIrRnsIXhOhur7HrCb0gso9Tk+BFAraH1l bpe//fnDSM1J2dL4a3E2/3TQfSULZR4MLqWB80CsN6vSUYms1/4NHM5Mw6Tw9C87qZGY Mcevn8qpn6D2yCHIJcD/ZCKCR9zhFNucZy2wqoX44U+ETu53Adgb024AYP4Ff8tAz5ca Zm7JwMPagEus3ftHaiEq7Js1ul4TMJuHPHzqUfEjQMeWklItwkn6INsXixeooy4EiDUf mrXw== X-Gm-Message-State: AJaThX79RwDvvqeuOq2t6jNt9BQCs4tTTJJtShJLMVf7P5/U889hY81t /NorlSUlHYLnyAdw3v/wqW5JNY51V5afX6kCPQs= X-Google-Smtp-Source: ABhQp+QkS3iHOsRCEC0Nx9gErScxg4Zg1AViSOnP7TuXML7X1+w89eJoNSyhapDBmsZl72hbkLhNojDok0lNAzsmsYw= X-Received: by 10.157.1.74 with SMTP id 68mr1732880otu.349.1509621962597; Thu, 02 Nov 2017 04:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.182.12 with HTTP; Thu, 2 Nov 2017 04:25:22 -0700 (PDT) From: Sahana Prasad Date: Thu, 2 Nov 2017 12:25:22 +0100 Message-ID: To: kivinen@iki.fi Cc: ipsec@ietf.org, Paul Wouters , Valery Smyslov Content-Type: multipart/alternative; boundary="94eb2c03ceb8d36997055cfe409d" Archived-At: Subject: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 11:26:05 -0000 --94eb2c03ceb8d36997055cfe409d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, We could consider adding this item to the working charter : Explicitly negotiating different RSA versions (Specific case) : According to section 3.2 of rfc-8247 (was rfc-4307 bis) ,it is mentioned that : " When the Digital Signature authentication method is used with RSA signature algorithm, RSASSA-PSS MUST be supported and RSASSA- PKCS1-v1.5 MAY be supported " However , the way to signal to the peer which version of RSA is being used is neither mentioned in rfc-7427 nor in rfc-8247. Right now there is no way to fallback from RSASSA - PSS to RSASSA-PKCS1-v1.5 or vice-versa. (Ideally since RSASSA-PSS MUST be supported on both ends with Digital signatures implemented, the fallback case should not arise. Then why is there a need to still support the older version of RSASSA-PKCS1-v1.5 (the MAY case) ? ) Since the rfc-8247 clearly mentions that there should be a MUST and a MAY case, there should also be clarity on how to switch between the two methods= . A more general case: Please note that RSASSA-PSS is just a specific case but the root of the problem is that while the peers announce their list of hashes they support for using Digital Signatures, there is no explicit way for them to announce the supported list of signature formats. Earlier this was not a problem bec= ause there was only one signature format (RSA-PKCS#1). But now, we have newer RSASSA-PSS Signature formats and therefore the problem. We can probably envision that the number of signature formats will grow (newer Edward signatures, even more newer hash-based signatures etc.), so we expect that the specific problem with RSASSA-PSS won=E2=80=99t be the only problem with signature formats. Thank you. Regards, Sahana Prasad --94eb2c03ceb8d36997055cfe409d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

We could consider adding this ite= m to the working charter :

Explicitly negotiating different RSA= versions (Specific case) :

According to section 3= .2 of rfc-8247 (was rfc-4307 bis) ,it is mentioned that :

" When the Dig= ital Signature authentication method is used with RSA signature algorithm, RSASSA-PSS MUST be supported and RSASSA- PKCS1-v1.5 MAY be supported "
However , the = way to signal to the peer which version of RSA is being used is=C2=A0 neith= er mentioned=C2=A0 in rfc-7427 nor in rfc-8247.
Right now there is no way to fallback from RSASSA - PSS to RSASSA-PKCS1-v1.5=20 or vice-versa. (Ideally since RSASSA-PSS MUST be supported on both ends=20 with Digital signatures implemented, the fallback case should not arise. Then why is there a need to still support the older version of=20 RSASSA-PKCS1-v1.5=C2=A0 (the MAY case) ? )
Since the rfc-8247=20 clearly mentions that there should be a MUST and a MAY case, there=20 should also be clarity on how to switch between the two methods.
=
A more general case:

Please no= te that RSASSA-PSS is just a specific case but the root of the problem is t= hat while the peers announce their list of hashes they support for using Di= gital Signatures, there is no explicit way for them to announce the supported list of signature formats. Earlier this= was not a problem because there was only one signature for= mat (RSA-PKCS#1). But now, we have newer RSASSA-PSS Signature formats and t= herefore the problem. We can probably envision that the number of signat= ure<= span style=3D"font-family:arial,helvetica,sans-serif"> formats will grow (n= ewer Edward signatures, even= more newer hash-bas= ed signatures etc.), so we expect that the specific problem with RSASSA-PSS= won=E2=80=99t be the only problem with signature formats.


<= span style=3D"color:rgb(0,0,0)">Thank you.

Regards,

= Sahana Prasad

--94eb2c03ceb8d36997055cfe409d-- From nobody Thu Nov 2 08:48:57 2017 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 0583813B13E for ; Thu, 2 Nov 2017 08:48:56 -0700 (PDT) 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 LTrHgvZ8JsZm for ; Thu, 2 Nov 2017 08:48:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 52158139504 for ; Thu, 2 Nov 2017 08:48:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vA2Fmoe8025401 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Nov 2017 17:48:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vA2FmodG020387; Thu, 2 Nov 2017 17:48:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23035.15970.848662.263976@fireball.acr.fi> Date: Thu, 2 Nov 2017 17:48:50 +0200 From: Tero Kivinen To: Sahana Prasad Cc: ipsec@ietf.org, Paul Wouters , Valery Smyslov In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:48:56 -0000 Sahana Prasad writes: > We could consider adding this item to the working charter : > > Explicitly negotiating different RSA versions (Specific case) : If you want it to be considered as charter item, please provide text suitable for charter. -- kivinen@iki.fi From nobody Thu Nov 2 09:04:27 2017 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 DD5DA13F449 for ; Thu, 2 Nov 2017 09:04:24 -0700 (PDT) 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 h1t3hzwMzMjX for ; Thu, 2 Nov 2017 09:04:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 983C813B2AD for ; Thu, 2 Nov 2017 09:04:22 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vA2G4KGF007466 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Nov 2017 18:04:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vA2G4Kqc012014; Thu, 2 Nov 2017 18:04:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23035.16900.584463.917812@fireball.acr.fi> Date: Thu, 2 Nov 2017 18:04:20 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 15 min Archived-At: Subject: [IPsec] Charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:04:25 -0000 I have now received following items for consideration for charter (includes old items not finished in the current charter): ---------------------------------------------------------------------- IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2 MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from one IP address to another. However, in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) that controls this process. If there are several responders each having own IP address and acting together as a load sharing cluster, then it is desirable for them to have ability to request initiator to switch to a particular member. The working group will analyze the possibility to extend MOBIKE protocol or to develop new IKE extension that will allow to build load sharing clusters in an interoperable way. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Direct using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression. draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression. ----------------------------------------------------------------------- There was also some other suggestions but there was no suitable text for charter for them, so if people want them to be considered, provide text. Did I catch everything else properly? We will be working on these items in the mailing list next week and most likely during signapore session too. -- kivinen@iki.fi From nobody Thu Nov 2 09:18:29 2017 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 E7C8313F56F for ; Thu, 2 Nov 2017 09:18:27 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlX7BDQ99xuM for ; Thu, 2 Nov 2017 09:18:25 -0700 (PDT) Received: from relay.ezis.com (relay.ezis.com [5.153.73.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5771013AB36 for ; Thu, 2 Nov 2017 09:18:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.43,368,1503356400"; d="scan'208";a="2718443" Received: from unknown (HELO pqex01.post-quantum.com) ([192.168.142.3]) by ironport.ezis.com with ESMTP; 02 Nov 2017 16:18:24 +0000 Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX01.post-quantum.com (192.168.142.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Nov 2017 16:18:22 +0000 Received: from PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3]) by PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3%13]) with mapi id 15.00.1320.000; Thu, 2 Nov 2017 16:18:22 +0000 From: Cen Jung Tjhai To: Valery Smyslov , Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Charter items Thread-Index: AQHTU/RDx67F1CrOnEeR4EDKHoB+WqMBRH8A Date: Thu, 2 Nov 2017 16:18:21 +0000 Message-ID: References: <23035.16900.584463.917812@fireball.acr.fi> In-Reply-To: <23035.16900.584463.917812@fireball.acr.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.3.255.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <92CEA1E7636A6F4FBD1D65D27BACF628@post-quantum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:18:28 -0000 Hi Valery, Many thanks for providing the charter text on making IKEv2 post quantum key= ready. Could we add another sentence to it so that it reads as follows: Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Direct using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key=20 exchange to be performed in parallel with the existing Diffie-Hellman key=20 exchange.=20 Best regards, CJ > On 2 Nov 2017, at 16:04, Tero Kivinen wrote: >=20 > I have now received following items for consideration for charter > (includes old items not finished in the current charter): >=20 > ---------------------------------------------------------------------- > IKEv1 using shared secret authentication was partially resistant to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will add a mode to IKEv2 or otherwise > modify IKEv2 to have similar quantum resistant properties than IKEv1 > had. >=20 > Split-DNS is a common configuration for VPN deployments, in which > only one or a few private DNS domains are accessible and resolvable > via the tunnel. Adding new configuration attributes to IKEv2 for > configuring Split-DNS would allow more deployments to adopt IKEv2. > This configuration should also allow verification of the domains using > DNSSEC. Working group will specify needed configuration attributes for > IKEv2. >=20 > Currently, widely used counter mode based ciphers send both the ESP > sequence number and IV in form of counter, as they are very > commonly the same. There has been interest to work on a document that wil= l > compress the packet and derive IV from the sequence number instead of > sending it in separate field. The working group will specify how this > compression can be negotiated in the IKEv2, and specify how the > encryption algorithm and ESP format is used in this case. >=20 > The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based > protocol for negotiating group keys for both multicast and unicast > uses. The Working Group will develop an IKEv2-based alternative that > will include cryptographic updates. A possible starting point is > draft-yeung-g-ikev2 >=20 > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > one IP address to another. However, in MOBIKE it is the initiator of > the IKE SA (i.e. remote access client) that controls this process. If > there are several responders each having own IP address and acting > together as a load sharing cluster, then it is desirable for them to > have ability to request initiator to switch to a particular member. > The working group will analyze the possibility to extend MOBIKE > protocol or to develop new IKE extension that will allow to build load > sharing clusters in an interoperable way. >=20 > Postquantum Cryptography brings new key exchange methods. Most of > these methods that are known to date have much larger public keys then > conventional Diffie-Hellman public keys. Direct using these methods in > IKEv2 might lead to a number of problems due to the increased size of > initial IKEv2 messages. The working group will analyze the possible > problems and develop a solution, that will make adding Postquantum key > exchange methods more easy. >=20 > A growing number of use cases for constraint network - but not limited to= - > have shown interest in reducing ESP (resp. IKEv2) overhead by compressing= ESP > (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to en= able > ESP header compression. >=20 > draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extensi= on > are expected to be good starting points for ESP compression. > draft-smyslov-ipsecme-ikev2-compression and > draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 > compression. > ----------------------------------------------------------------------- >=20 > There was also some other suggestions but there was no suitable text > for charter for them, so if people want them to be considered, provide > text. >=20 > Did I catch everything else properly? >=20 > We will be working on these items in the mailing list next week and > most likely during signapore session too. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Nov 2 10:55:57 2017 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 631C413F474 for ; Thu, 2 Nov 2017 10:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 odfRBurkZoLg for ; Thu, 2 Nov 2017 10:55:54 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 7E60E1394E4 for ; Thu, 2 Nov 2017 10:55:54 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id a16so419909lfk.0 for ; Thu, 02 Nov 2017 10:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=4jiOvZkpbjCPSOshKrZOIGWrpQ2EImLp7DoLgod61yE=; b=cDakTn4qXq2JY+nGZdc0D9bBisMPlXFm0yMFljg9hNdSOxMTIvYdAdQN2pDOHaAQ09 UNOwbaR7hHewQyBwsSlY8UfUMWSHlbsFXrDIPc1ojWJFOd2LS7tPQvMA6B7FtOC1eA0E 3mLKn3wiaDPPqK8TYSfRSQCtkKPjZe91iTBMPyouDBbQ6+iyXAuk/zflVXz7wftqmOGs D6QRFYd3P06IMGPQ5V0w5B0kVXm4h5gGXjFHVbGAqoR355KmurkJnS86MvZtbpvtyF90 693pGgBz0IB2VZZ9h30yxMzoKLAvFfqN3xGmHAv6k6iqil9omLHF+4aV5CNBrotmfrrk nzZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=4jiOvZkpbjCPSOshKrZOIGWrpQ2EImLp7DoLgod61yE=; b=m8/xn+TcUnLsKd2t5r73qA+rYBP3MourV8CyIy+oLLVCBTbf1nND9UIXkbrKDiL31G JdJdQ2HadH0CblSsKbLYqENIgQVP6y8UHxcrP1Q9VLWJwhbm1FwFIdHo+HtPfop1LChG ggqApIZXNCtr0T/SPtvaVR2VxyuADN9jnP2tkLivg710uiMBTO12yoFCVDK+YAR395NT i1EFs3PKN9/W918wmTRu5aLevVoH43kBeJZa/+g8a7jLYRyINL3isLZc3++YLziBIJbe VJGD5Xrwl3OB8/O4grQDEibX5wPwrdcsPJBLCZdnmYltetsO2pwee4e/zicoe9kuQDXR HXQw== X-Gm-Message-State: AJaThX5+/Tdd5gGrXrBgRfCNR2EOzLxDycopIwHSguPvmFKJNk+qRtoS ecy1Ss4zwDUeWH+CMRpzUGxAeg== X-Google-Smtp-Source: ABhQp+RJIRzCYgGqUJyPO1to0gdEoeKm/pYJOX0lNT9a5oZS82xKkrdvtAwnyhY7B2MzF9Bs8mRC5g== X-Received: by 10.25.125.130 with SMTP id y124mr1563997lfc.137.1509645352623; Thu, 02 Nov 2017 10:55:52 -0700 (PDT) Received: from chichi (ppp83-237-171-193.pppoe.mtu-net.ru. [83.237.171.193]) by smtp.gmail.com with ESMTPSA id w9sm812241ljw.49.2017.11.02.10.55.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Nov 2017 10:55:52 -0700 (PDT) Message-ID: <78A26D391A884838808071E7F6EC5B2A@chichi> From: "Valery Smyslov" To: "Cen Jung Tjhai" , "Tero Kivinen" Cc: References: <23035.16900.584463.917812@fireball.acr.fi> In-Reply-To: Date: Thu, 2 Nov 2017 20:55:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:55:56 -0000 Hi Cen Jung, I'd rather avoid focusing on hybrid key exchange only. In my understanding hybrid key exchange will (should?) eventually become PQ-only key exchange. That's why I'd rather express charter in more generic way, so that it is applicable for both hybrid and PQ-only cases, since both have the same problem with large public keys. How about the followingy last sentence: The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. Regards, Valery. > Hi Valery, > > Many thanks for providing the charter text on making IKEv2 post quantum key ready. > > Could we add another sentence to it so that it reads as follows: > > Postquantum Cryptography brings new key exchange methods. Most of > these methods that are known to date have much larger public keys then > conventional Diffie-Hellman public keys. Direct using these methods in > IKEv2 might lead to a number of problems due to the increased size of > initial IKEv2 messages. The working group will analyze the possible > problems and develop a solution, that will make adding Postquantum key > exchange methods more easy. The solution will allow post quantum key > exchange to be performed in parallel with the existing Diffie-Hellman key > exchange. > > Best regards, > CJ From nobody Thu Nov 2 11:25:07 2017 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 0AFAE13F7F2 for ; Thu, 2 Nov 2017 11:25:06 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz-OPS0S999r for ; Thu, 2 Nov 2017 11:25:04 -0700 (PDT) Received: from relay.ezis.com (relay.ezis.com [5.153.73.19]) by ietfa.amsl.com (Postfix) with ESMTP id 998CE12711D for ; Thu, 2 Nov 2017 11:25:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.43,368,1503356400"; d="scan'208";a="2720078" Received: from unknown (HELO pqex01.post-quantum.com) ([192.168.142.3]) by ironport.ezis.com with ESMTP; 02 Nov 2017 18:25:03 +0000 Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX01.post-quantum.com (192.168.142.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Nov 2017 18:25:01 +0000 Received: from PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3]) by PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3%13]) with mapi id 15.00.1320.000; Thu, 2 Nov 2017 18:25:01 +0000 From: Cen Jung Tjhai To: Valery Smyslov CC: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Charter items Thread-Index: AQHTU/RDx67F1CrOnEeR4EDKHoB+WqMBRH8AgAAbNYCAAAguAA== Date: Thu, 2 Nov 2017 18:25:01 +0000 Message-ID: <22C03C8E-2D1C-418C-A021-04001091348A@post-quantum.com> References: <23035.16900.584463.917812@fireball.acr.fi> <78A26D391A884838808071E7F6EC5B2A@chichi> In-Reply-To: <78A26D391A884838808071E7F6EC5B2A@chichi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.3.255.7] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 18:25:06 -0000 Hi Valery, Yes, In the future (after NIST process is completed or general purpose quan= tum computers are available), one may want to use post quantum key exchange= only. Happy with your last sentence. Cheers, CJ > On 2 Nov 2017, at 17:55, Valery Smyslov wrote: >=20 > Hi Cen Jung, >=20 > I'd rather avoid focusing on hybrid key exchange only. In my understandin= g hybrid key exchange will (should?) eventually > become PQ-only key exchange. That's why I'd rather express > charter in more generic way, so that it is applicable for > both hybrid and PQ-only cases, since both have the same problem with larg= e public keys. >=20 > How about the followingy last sentence: >=20 > The solution will allow post quantum key exchange to be performed in para= llel with (or instead of) the existing Diffie-Hellman key exchange. >=20 > Regards, > Valery. >=20 >> Hi Valery, >> Many thanks for providing the charter text on making IKEv2 post quantum = key ready. >> Could we add another sentence to it so that it reads as follows: >> Postquantum Cryptography brings new key exchange methods. Most of >> these methods that are known to date have much larger public keys then >> conventional Diffie-Hellman public keys. Direct using these methods in >> IKEv2 might lead to a number of problems due to the increased size of >> initial IKEv2 messages. The working group will analyze the possible >> problems and develop a solution, that will make adding Postquantum key >> exchange methods more easy. The solution will allow post quantum key exc= hange to be performed in parallel with the existing Diffie-Hellman key exch= ange. Best regards, >> CJ >=20 From nobody Thu Nov 2 11:25:27 2017 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 6855813F7F2 for ; Thu, 2 Nov 2017 11:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 EDan6ol0zePw for ; Thu, 2 Nov 2017 11:25:24 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 6EEDC13F808 for ; Thu, 2 Nov 2017 11:25:24 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id n69so505148lfn.2 for ; Thu, 02 Nov 2017 11:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=bb59XIGa0dQNCYC+juqsc8ltIMqRQ8CkrdGcVVqbBqA=; b=ueJzbnFdOVsMgwwsYmYOzDUPddfl42IT2g3yN7EG+L5s5jJX+w9novKuaVYPQyE6eT ZE7Xv4Pj9qBe/Xr5dUuy+qW7E+v0sDJHHLceMRwJA/FMds6inXYEy2dJJ9h7dEtSvfWM P5oDMK6A3nYJksiHWcFSSZbGirrzOpy7OLTSHIaeunTgVLgJA+aMEdSaCOoOCEGrY42F m8iJetpr5nPrm0Rq1tOXayjKWrNSjhxhvvdMPNU2Rko36VJdEVcY2HjgVICDyM4C8cjH D79KRxxCb43vx/YsUsOpHE7THoF7fClROBUGn2RqxE6hesSR7KTccHQzdEP+WzoXh0X4 6fEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=bb59XIGa0dQNCYC+juqsc8ltIMqRQ8CkrdGcVVqbBqA=; b=bQgVPDQcGuJcnMVf6Yq1nrb/QaMe5BL/jFL3Zpd0gKAtXWM/QHH0F1lRtWNaQrmtbv gBx8l/wxVm1K/y8c8DVZpqhVA99C9UKJ/6B2nLrSG8JhJQKCR5oKD1MIrl9lFpHKU5m5 f2jFud7yTOkb6M1lShN/Gp6hDbH8bawRVXpVSkJyVLBCahnUKGaTSsKcqciZvKsxwOGE UduQHVI4AxLtxrFBCh0XzJRwHpABaI6MI0iAaNl+PP/w2nZk4a0XfhwpsgRtGkDwItnh k930Bs1DeSJcuelsNHx0VU6RGDv3GxsPOHMeH+C7AOpSL7WkXadBncEsuVV0aoAMC981 0RaA== X-Gm-Message-State: AMCzsaVYSMrrcwKbj1L0qavWZT30ZprkA5nGhST4+0WB2DVnuLkYvs9x l6lejquiVodO/ZY60A4ts6o= X-Google-Smtp-Source: ABhQp+TUyKdp297l+3tEoFtPV+RdoY6kgbuRsVFTlytBk+Qmh9JSuqzs5urv4xH0Usu4r9sTYp/j2g== X-Received: by 10.46.20.3 with SMTP id u3mr1851525ljd.164.1509647122767; Thu, 02 Nov 2017 11:25:22 -0700 (PDT) Received: from chichi (ppp83-237-171-193.pppoe.mtu-net.ru. [83.237.171.193]) by smtp.gmail.com with ESMTPSA id z6sm655280lfa.83.2017.11.02.11.25.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Nov 2017 11:25:22 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , "Sahana Prasad" Cc: , "Paul Wouters" References: <23035.15970.848662.263976@fireball.acr.fi> In-Reply-To: <23035.15970.848662.263976@fireball.acr.fi> Date: Thu, 2 Nov 2017 21:25:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 18:25:26 -0000 Hi Tero, how about: RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, recent advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate each other which signature format(s) the support, that leads to ineroperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. Regards, Valery. > Sahana Prasad writes: > > We could consider adding this item to the working charter : > > > > Explicitly negotiating different RSA versions (Specific case) : > > If you want it to be considered as charter item, please provide text > suitable for charter. > -- > kivinen@iki.fi From nobody Thu Nov 2 18:55:50 2017 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 E2E2813FAF1 for ; Thu, 2 Nov 2017 18:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBYrq4lfuVr0 for ; Thu, 2 Nov 2017 18:55:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 C4D5513FB12 for ; Thu, 2 Nov 2017 18:55:46 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vA31thaQ017647 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Nov 2017 03:55:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vA31tgPf005694; Fri, 3 Nov 2017 03:55:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23035.52382.605934.105306@fireball.acr.fi> Date: Fri, 3 Nov 2017 03:55:42 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "Cen Jung Tjhai" , ipsec@ietf.org In-Reply-To: <78A26D391A884838808071E7F6EC5B2A@chichi> References: <23035.16900.584463.917812@fireball.acr.fi> <78A26D391A884838808071E7F6EC5B2A@chichi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: Re: [IPsec] Charter items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 01:55:50 -0000 Valery Smyslov writes: > How about the followingy last sentence: > > The solution will allow post quantum key exchange to be > performed in parallel with (or instead of) the existing Diffie-Hellman key > exchange. Updated to match to that. -- kivinen@iki.fi From nobody Thu Nov 2 18:57:21 2017 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 45C9813FB0C for ; Thu, 2 Nov 2017 18:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPC7TDEGlWdK for ; Thu, 2 Nov 2017 18:57:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 3382E13FAF1 for ; Thu, 2 Nov 2017 18:57:19 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vA31vGf9009377 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Nov 2017 03:57:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vA31vGQn028054; Fri, 3 Nov 2017 03:57:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23035.52476.848168.743742@fireball.acr.fi> Date: Fri, 3 Nov 2017 03:57:16 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "Sahana Prasad" , , "Paul Wouters" In-Reply-To: References: <23035.15970.848662.263976@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 01:57:20 -0000 Valery Smyslov writes: > Hi Tero, > > how about: > > RFC7427 allows peers to indicate hash algorithms they support, thus > eliminating ambiguity in selecting a hash function for digital signature > authentication. However, recent advances in cryptography lead to > a situation when some signature algorithms have several signature formats. > A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, however > it is envisioned that the same situation may repeat in future > with other signature algorithms. Currently IKE peers have no explicit way > to indicate each other which signature format(s) the support, that leads > to ineroperability problems. The WG will investigate the situation > and come up with a solution that allows peers to deal with the problem > in an interoperable way. You know what I personally think about this, but as chair I have to say, added to the list of candidate items... -- kivinen@iki.fi From nobody Thu Nov 2 23:20:21 2017 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 94EFB13FC23 for ; Thu, 2 Nov 2017 23:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GKunZKeTdmQ for ; Thu, 2 Nov 2017 23:20:19 -0700 (PDT) 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 09CCB13FC07 for ; Thu, 2 Nov 2017 23:20:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ySsJG1tWYz35s; Fri, 3 Nov 2017 07:20:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1509690014; bh=mGaN1Xe6A201T2cu14W4dnLgAbPetcnwmxwhKmVMW4w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nlyGAhyMyyQncQhJ5xVL2TistGTnbD3pCWhGIZAFlFw68YUuTfn5GLFQsVOON4VsJ 1UjZuF04JymW9Ugc+iZGmlGCchOlBy7SSoL75t24r8nr43iydBrPWDIQ41VnTK2Lpc 4XK+SXxPJ4v+f4W3/RuKqK8vqha5V5tQWixdTmqA= 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 SWu4-rcU0V-r; Fri, 3 Nov 2017 07:20:12 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Nov 2017 07:20:11 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B147292C; Fri, 3 Nov 2017 02:20:10 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B147292C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9C7EF40D35AF; Fri, 3 Nov 2017 02:20:10 -0400 (EDT) Date: Fri, 3 Nov 2017 02:20:10 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: Tero Kivinen , Sahana Prasad , ipsec@ietf.org In-Reply-To: Message-ID: References: <23035.15970.848662.263976@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Agenda for IETF 100 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 06:20:20 -0000 On Thu, 2 Nov 2017, Valery Smyslov wrote: > RFC7427 allows peers to indicate hash algorithms they support, thus > eliminating ambiguity in selecting a hash function for digital signature > authentication. However, recent advances in cryptography lead to a situation > when some signature algorithms have several signature formats. I think it is worth investigating a bit more. > A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, This example is indeed the first known problem. One of the most widespread implementations of 7427 does not support PSS. I'm not sure 8247 making RSASSA-PSS will help much. Paul From nobody Fri Nov 3 13:08:49 2017 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 5895613FF7B for ; Fri, 3 Nov 2017 13:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyR9djLi9Vwa for ; Fri, 3 Nov 2017 13:08:45 -0700 (PDT) Received: from mo3.mail.sc.edu (mo3.mail.sc.edu [129.252.158.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 084E113FF77 for ; Fri, 3 Nov 2017 13:08:44 -0700 (PDT) Received: from mo3.mail.sc.edu (127.0.0.1) id hvj6cq0171sm for ; Fri, 3 Nov 2017 16:08:44 -0400 (envelope-from ) Received: from CAE145HUBP02.ds.sc.edu ([172.27.7.169]) by mo3.mail.sc.edu (SonicWALL 8.2.1.4973) with ESMTPS (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256) id 201711032008430218602; Fri, 03 Nov 2017 16:08:43 -0400 Received: from CAE145EMBP02.ds.sc.edu ([fe80::bc67:c4b6:7a3c:50a0]) by CAE145HUBP02.ds.sc.edu ([::1]) with mapi id 14.03.0339.000; Fri, 3 Nov 2017 16:08:28 -0400 From: "LUO, LANNAN" To: "ipsec@ietf.org" Thread-Topic: IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) Thread-Index: AQHTTN4tHq1UdrQ9G0Gy7sJzFTVFw6LzIt5DgAAA0teAAABrVIAAAMAzgABdBVeAAABc4YAAAEBfgAAAIq+AAAD044AAABahgAAAJyuAAAAr+4AAAFE3gAAAR1eAAABgz4AAAJSRgAABVYuAAAItpYAAAEH7gAAA1m2AAAQOAYAAAC0BgAAAWg2AAADW4YAAAD8FgAAANaeAAC1EMoAD+M0lgAAD3ZyAAAMbj4AAAurmgAAEig6AAATnpoAAAB98gAAIx8WAAAHMFIAAJon2gAA4f1KABLN/XoAABeZkgAA2uyKAAAC7ZoAA2eSbgAQEL1OAASBtBYAAARN7gAAAhOuAAAErBw== Date: Fri, 3 Nov 2017 20:08:27 +0000 Message-ID: References: , , , , , , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.7.4] Content-Type: multipart/alternative; boundary="_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA22A6CAE145EMBP02dss_" MIME-Version: 1.0 X-Mlf-Version: 8.2.1.4973 X-Mlf-UniqueId: o201711032008430218602 Archived-At: Subject: [IPsec] IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:08:47 -0000 --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA22A6CAE145EMBP02dss_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [Apologies, if you receive multiple copies of this CFP] CALL FOR PAPERS IEEE CNS 2018 IEEE Conference on Communications and Network Security Beijing, China, May 30-June 1, 2018 URL: http://cns2018.ieee-cns.org/ IEEE Communications Society Core Conference PAPER SUBMISSION DEADLINE December 20, 2017 ***************************************************************************= ********* IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, polic= y makers, and users to exchange ideas, techniques and tools, raise awarenes= s, and share experience related to all practical and theoretical aspects of= cybersecurity. Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the= network layer to the variety of applications reliant on a secure communica= tion substrate. TOPICS OF INTERESTS -------------------------------- * Anonymity and privacy technologies * Computer and network forensics * Cyber deterrence strategies * Game-theoretic security technologies * Implementation and evaluation of networked security systems * Information-theoretic security * Intrusion detection, prevention, and response * Key management, public key infrastructures, certification, revocation, an= d authentication * Malware detection and mitigation * Security metrics and models * Physical-layer and cross-layer security technologies * Security and privacy for big data * Security and privacy for data and network outsourcing services * Security and privacy for mobile and wearable devices * Security and privacy in cellular networks * Security and privacy in cloud and edge computing * Security and privacy in crowdsourcing * Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) * Security and privacy in peer-to-peer and overlay networks * Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks * Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems * Security for critical infrastructures (smart grids, transportation system= s, etc.) * Security for future Internet architectures and designs * Security for software-defined and data center networks * Social, economic, and policy issues of trust, security, and privacy * Traffic analysis * Usable security and privacy * Web, e-commerce, m-commerce, and e-mail security IMPORTANT DATES --------------------------- Paper Submission Deadline: December 20, 2017 Notification of Acceptance: February 27, 2018 Final Paper Submission: March 19, 2018 CONFERENCE CHAIRS ------------------------------- General Chair: Jiwu Jing (Chinese Academy of Sciences, PR China) Program Chairs: Loukas Lazos (University of Arizona, USA) Peng Liu (Pennsylvania State University, USA) TECHNICAL PROGRAM COMMITTEE ---------------------------------------------------- See: http://cns2018.ieee-cns.org/ --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA22A6CAE145EMBP02dss_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[Apologies, if you receive multiple co= pies of this CFP]
          &nbs= p;               CALL FOR PAPERS  <= /span>
 
            &nb= sp;            =   IEEE CNS 2018          =
 
           IEEE Conferenc= e on Communications and Network Security 
            &nb= sp;         Beijing, China, May 30-= June 1, 2018 
            &nb= sp;         URL: http://cns2018.ieee-cns= .org/ 
            &nb= sp;            =     
            &nb= sp;     IEEE Communications Society Core Conference&nbs= p;
 
            &nb= sp;     PAPER SUBMISSION DEADLINE December 20, 2017&nbs= p;
 
***************************************************************************= ********* 
IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, policy makers, and users to exchange = ideas, techniques and tools, raise awareness, and share experience related = to all practical and theoretical aspects of cybersecurity. 
 
Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the network layer to the variety of a= pplications reliant on a secure communication substrate.  
 
TOPICS OF INTERESTS 
-------------------------------- 
* Anonymity and privacy technologies 
* Computer and network forensics 
* Cyber deterrence strategies 
* Game-theoretic security technologies 
* Implementation and evaluation of networked security systems 
* Information-theoretic security 
* Intrusion detection, prevention, and response 
* Key management, public key infrastructures, certification, revocation, an= d authentication 
* Malware detection and mitigation 
* Security metrics and models 
* Physical-layer and cross-layer security technologies 
* Security and privacy for big data 
* Security and privacy for data and network outsourcing services 
* Security and privacy for mobile and wearable devices 
* Security and privacy in cellular networks 
* Security and privacy in cloud and edge computing 
* Security and privacy in crowdsourcing 
* Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) 
* Security and privacy in peer-to-peer and overlay networks 
* Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks 
* Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems 
* Security for critical infrastructures (smart grids, transportation system= s, etc.) 
* Security for future Internet architectures and designs 
* Security for software-defined and data center networks 
* Social, economic, and policy issues of trust, security, and privacy =  
* Traffic analysis  
* Usable security and privacy  
* Web, e-commerce, m-commerce, and e-mail security   
 
 
IMPORTANT DATES 
--------------------------- 
Paper Submission Deadline: December 20, 2017 
Notification of Acceptance: February 27, 2018 
Final Paper Submission: March 19, 2018  
 
 
CONFERENCE CHAIRS  
------------------------------- 
General Chair:  
Jiwu Jing (Chinese Academy of Sciences, PR China)  
 
Program Chairs:  
Loukas Lazos (University of Arizona, USA) 
Peng Liu (Pennsylvania State University, USA) 
 
 
TECHNICAL PROGRAM COMMITTEE 
---------------------------------------------------- 
See: http://cns2018.ieee-cns.org/
 
--_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA22A6CAE145EMBP02dss_-- From nobody Fri Nov 3 13:19:34 2017 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 DDBD513FF84 for ; Fri, 3 Nov 2017 13:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y6EJ9Nyt5-E for ; Fri, 3 Nov 2017 13:19:31 -0700 (PDT) Received: from mo3.mail.sc.edu (mo3.mail.sc.edu [129.252.158.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 AFB3613FF48 for ; Fri, 3 Nov 2017 13:19:30 -0700 (PDT) Received: from mo3.mail.sc.edu (127.0.0.1) id hvj7l40171sg for ; Fri, 3 Nov 2017 16:19:30 -0400 (envelope-from ) Received: from CAE145HUBP02.ds.sc.edu ([172.27.7.169]) by mo3.mail.sc.edu (SonicWALL 8.2.1.4973) with ESMTPS (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256) id 201711032019290200985; Fri, 03 Nov 2017 16:19:29 -0400 Received: from CAE145EMBP02.ds.sc.edu ([fe80::bc67:c4b6:7a3c:50a0]) by CAE145HUBP02.ds.sc.edu ([::1]) with mapi id 14.03.0339.000; Fri, 3 Nov 2017 16:19:29 -0400 From: "LUO, LANNAN" To: "ipsec@ietf.org" Thread-Topic: IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) Thread-Index: AQHTTN4tHq1UdrQ9G0Gy7sJzFTVFw6LzIt5DgAAA0teAAABrVIAAAMAzgABdBVeAAABc4YAAAEBfgAAAIq+AAAD044AAABahgAAAJyuAAAAr+4AAAFE3gAAAR1eAAABgz4AAAJSRgAABVYuAAAItpYAAAEH7gAAA1m2AAAQOAYAAAC0BgAAAWg2AAADW4YAAAD8FgAAANaeAAC1EMoAD+M0lgAAD3ZyAAAMbj4AAAurmgAAEig6AAATnpoAAAB98gAAIx8WAAAHMFIAAJon2gAA4f1KABLN/XoAABeZkgAA2uyKAAAC7ZoAA2eSbgAQEL1OAASBtBYAAARN7gAAAhOuAAAErB4AAADwHgAAAfyuAAAFFTYAAAIFHgAAAFguAAAAvmYAAABk1gAAAGyGAAAAgew== Date: Fri, 3 Nov 2017 20:19:27 +0000 Message-ID: References: , , , , , , , , , , , , , , , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.7.4] Content-Type: multipart/alternative; boundary="_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA234DCAE145EMBP02dss_" MIME-Version: 1.0 X-Mlf-Version: 8.2.1.4973 X-Mlf-UniqueId: o201711032019290200985 Archived-At: Subject: [IPsec] IEEE CNS 2018 Call for Papers (Submission Deadline - December 20) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:19:33 -0000 --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA234DCAE145EMBP02dss_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [Apologies, if you receive multiple copies of this CFP] CALL FOR PAPERS IEEE CNS 2018 IEEE Conference on Communications and Network Security Beijing, China, May 30-June 1, 2018 URL: http://cns2018.ieee-cns.org/ IEEE Communications Society Core Conference PAPER SUBMISSION DEADLINE December 20, 2017 ***************************************************************************= ********* IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, polic= y makers, and users to exchange ideas, techniques and tools, raise awarenes= s, and share experience related to all practical and theoretical aspects of= cybersecurity. Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the= network layer to the variety of applications reliant on a secure communica= tion substrate. TOPICS OF INTERESTS -------------------------------- * Anonymity and privacy technologies * Computer and network forensics * Cyber deterrence strategies * Game-theoretic security technologies * Implementation and evaluation of networked security systems * Information-theoretic security * Intrusion detection, prevention, and response * Key management, public key infrastructures, certification, revocation, an= d authentication * Malware detection and mitigation * Security metrics and models * Physical-layer and cross-layer security technologies * Security and privacy for big data * Security and privacy for data and network outsourcing services * Security and privacy for mobile and wearable devices * Security and privacy in cellular networks * Security and privacy in cloud and edge computing * Security and privacy in crowdsourcing * Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) * Security and privacy in peer-to-peer and overlay networks * Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks * Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems * Security for critical infrastructures (smart grids, transportation system= s, etc.) * Security for future Internet architectures and designs * Security for software-defined and data center networks * Social, economic, and policy issues of trust, security, and privacy * Traffic analysis * Usable security and privacy * Web, e-commerce, m-commerce, and e-mail security IMPORTANT DATES --------------------------- Paper Submission Deadline: December 20, 2017 Notification of Acceptance: February 27, 2018 Final Paper Submission: March 19, 2018 CONFERENCE CHAIRS ------------------------------- General Chair: Jiwu Jing (Chinese Academy of Sciences, PR China) Program Chairs: Loukas Lazos (University of Arizona, USA) Peng Liu (Pennsylvania State University, USA) TECHNICAL PROGRAM COMMITTEE ---------------------------------------------------- See: http://cns2018.ieee-cns.org/ --_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA234DCAE145EMBP02dss_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[Apologies, if you receive multiple co= pies of this CFP]
          &nbs= p;               CALL FOR PAPERS  <= /span>
 
            &nb= sp;            =   IEEE CNS 2018          =
 
           IEEE Conferenc= e on Communications and Network Security 
            &nb= sp;         Beijing, China, May 30-= June 1, 2018 
            &nb= sp;         URL: http://cns2018.ieee-cns= .org/ 
            &nb= sp;            =     
            &nb= sp;     IEEE Communications Society Core Conference&nbs= p;
 
            &nb= sp;     PAPER SUBMISSION DEADLINE December 20, 2017&nbs= p;
 
***************************************************************************= ********* 
IEEE Conference on Communications and Network Security (IEEE CNS) is a conf= erence series in IEEE Communications Society (ComSoc) core conference portf= olio and the only ComSoc conference focusing solely on cybersecurity. IEEE = CNS provides a premier forum for security researchers, practitioners, policy makers, and users to exchange = ideas, techniques and tools, raise awareness, and share experience related = to all practical and theoretical aspects of cybersecurity. 
 
Building on the success of the past five years=92 conferences, IEEE CNS 201= 8 seeks original high-quality technical papers from academia, government, a= nd industry. Topics of interest encompass all practical and theoretical asp= ects of communications and network security, from the physical layer to the network layer to the variety of a= pplications reliant on a secure communication substrate.  
 
TOPICS OF INTERESTS 
-------------------------------- 
* Anonymity and privacy technologies 
* Computer and network forensics 
* Cyber deterrence strategies 
* Game-theoretic security technologies 
* Implementation and evaluation of networked security systems 
* Information-theoretic security 
* Intrusion detection, prevention, and response 
* Key management, public key infrastructures, certification, revocation, an= d authentication 
* Malware detection and mitigation 
* Security metrics and models 
* Physical-layer and cross-layer security technologies 
* Security and privacy for big data 
* Security and privacy for data and network outsourcing services 
* Security and privacy for mobile and wearable devices 
* Security and privacy in cellular networks 
* Security and privacy in cloud and edge computing 
* Security and privacy in crowdsourcing 
* Security and privacy in emerging wireless technologies (dynamic spectrum = sharing, cognitive radio networks, millimeter wave communications, MIMO sys= tems, etc.) 
* Security and privacy in peer-to-peer and overlay networks 
* Security and privacy in Wi-Fi, ad hoc, mesh, sensor, vehicular, body-area= , disruption/delay tolerant, and social networks 
* Security and privacy in smart cities, smart and connected health, IoT, an= d RFID systems 
* Security for critical infrastructures (smart grids, transportation system= s, etc.) 
* Security for future Internet architectures and designs 
* Security for software-defined and data center networks 
* Social, economic, and policy issues of trust, security, and privacy =  
* Traffic analysis  
* Usable security and privacy  
* Web, e-commerce, m-commerce, and e-mail security   
 
 
IMPORTANT DATES 
--------------------------- 
Paper Submission Deadline: December 20, 2017 
Notification of Acceptance: February 27, 2018 
Final Paper Submission: March 19, 2018  
 
 
CONFERENCE CHAIRS  
------------------------------- 
General Chair:  
Jiwu Jing (Chinese Academy of Sciences, PR China)  
 
Program Chairs:  
Loukas Lazos (University of Arizona, USA) 
Peng Liu (Pennsylvania State University, USA) 
 
 
TECHNICAL PROGRAM COMMITTEE 
---------------------------------------------------- 
See: http://cns2018.ieee-cns.org/
 
--_000_F0ACB042FDEBA44C972AA9527AEEB8DC07DA234DCAE145EMBP02dss_-- From nobody Sun Nov 5 09:37:14 2017 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 069A613FB82 for ; Sun, 5 Nov 2017 09:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K5VFMLOQH2G for ; Sun, 5 Nov 2017 09:37:11 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 DA3DA13FC8F for ; Sun, 5 Nov 2017 09:37:10 -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 vA5Hb6T5009750 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Nov 2017 19:37:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vA5Hb6cf007778; Sun, 5 Nov 2017 19:37:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23039.19522.246855.199327@fireball.acr.fi> Date: Sun, 5 Nov 2017 19:37:06 +0200 From: Tero Kivinen To: Paul Wouters Cc: Valery Smyslov , Sahana Prasad , ipsec@ietf.org In-Reply-To: References: <23035.15970.848662.263976@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 13 min Archived-At: Subject: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 17:37:13 -0000 Paul Wouters writes: > On Thu, 2 Nov 2017, Valery Smyslov wrote: > > > RFC7427 allows peers to indicate hash algorithms they support, thus > > eliminating ambiguity in selecting a hash function for digital signature > > authentication. However, recent advances in cryptography lead to a situation > > when some signature algorithms have several signature formats. > > I think it is worth investigating a bit more. > > > A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, > > This example is indeed the first known problem. One of the most > widespread implementations of 7427 does not support PSS. I'm not > sure 8247 making RSASSA-PSS will help much. One question that comes to my mind is that why is the server offering CA which issues RSASSA-PSS certificates it is does not support those certificates. I.e. server is saying it will use CA which it cannot use, and I would say that is configuration error in the server side. Also usually client will know which certificate it must use when connecting to the server, exactly as it must know which PSK it must use when it connects to which server. I can see that there are corner cases where the adminstrative domain is updating from PKCS#1 certificates to the RSASSA-PSS, and not all of its infrastructure is updated yet, but it can prevent issues by either making sure server sides are updated before clients, or using separate CA for different key types. Another case where this might happen when client is doing opportunistic encryption i.e., it does not even try to authenticate, thus it does not care which key it is using or what key the other end is using, thus it will just pick one of its own keys and use that. In most cases IPsec is considered as "requires preconfiguration" use case, i.e., I cannot random try to connect host A with IPsec and assume that will work. It is same thing with secure shell, i.e., unless I have account and password or key configured for host A, there is no point of trying to see if I can log in to the host A. I.e., if you need to configure that this is the CA I want to trust when connecting to host A, and this is the identity I am going to use for myself, it is not that much more to configure that this is the key I am going to use when authenticating to host A. With PSK I will need to explictly give the keys anyways, why should the certificates be that much different case, that you cannot preconfigure the key you are using. TLS and HIP are examples of cases which are more or less "no preconfiguration required", i.e., you can just try to connect and if it works then you can use connection. This is the reason why the RFC7427 only negotiates the hash algorithm, and the section 5 of the RFC 7427 gives several ways of solving this issue without doing protocol changes. I still think this is more or less a configuration mismatch issue, i.e., if your configuration is wrong you will end up in trouble, but if you plan your upgrade process, or configure your systems correctly, this issue is disappears. -- kivinen@iki.fi From nobody Sun Nov 5 23:33:01 2017 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 81A2A13FB02 for ; Sun, 5 Nov 2017 23:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 gnJ8YOHOetf4 for ; Sun, 5 Nov 2017 23:32:59 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 922D913F963 for ; Sun, 5 Nov 2017 23:32:58 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id l23so9404681lfk.10 for ; Sun, 05 Nov 2017 23:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=UAH9jqQXM/KZa11UQpzs+4aEFhVGobdIrLcZkswS0q0=; b=hNTDR4zkXHXjW7qos4J/uAeuqQD2IFfL4i/ivB9TMPjkdKwVuFiZrRcOf8jpYqSpUC 2w/t89XFndGTG9h3EqHi9kmt87PLxi8TAk9owtNmoSY3TP0Wq9Hi9SmXKQpp1B1PT8w9 jvCSsBM+ytpRUtVCG4EKOmaXmK9Z8UKIi8dKvHPGtIMqb4jZy3IdjJQ1MHMIyzdI0rGy dXMjGDEa6wHGTzNH22GTRC4cetaOpFSabHMpfW07JDZ+Ft04SIOnKl6CrOevWGS7RNkn YGosCHD0fBHYlkB7uyCNFkxlZQUdcu+P3bzOuYKnMTA34cWgi06eIjRtndppstSxhu2m N1qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=UAH9jqQXM/KZa11UQpzs+4aEFhVGobdIrLcZkswS0q0=; b=o/hiB90aSilnGcLqkqGl975L5QrftJzJKWzvnPeLjZ2ZTS7nDxsYdXXvKSyksMI3wj BkusSAqsz+XtPAFIxhW+wvsXrNwv2e4HkbMAc1jkVDxPET/g35sCJKziNuL5MwmkpA2U ExLXWcqUHAdmdEQUO+YVxOQUnKL6cDr7ZMZRy2wkNJ+Ikwe6NIPbmypQA/zblnRJ3zqQ Q2l3dM3XznfHY+YdfBu5uW+0T3qIm5TMUzNxzvRYk64L7g7T4u/CE2A7L4pKLvCsdhY/ uOH2EOvQTfMs378f95DU2wD+v2Cc5T7JcJGJ4yjL71POV9kyZeozf+3pFZ3x2168+F9J hGjg== X-Gm-Message-State: AMCzsaV769wTOgA5zshLmvQUNjJ/2ew1QXDIMar/lYvlbjnTqDQVOL5W ogJZuJUps4kdvfhcMFsR1gk= X-Google-Smtp-Source: ABhQp+RLvJ48OtFCAyGouJXm92/tdgEKhsRZVbG/0J6hnu+ipOabv5OCpvEgMMHthUR16XvbFB357A== X-Received: by 10.46.77.214 with SMTP id c83mr5668588ljd.128.1509953576801; Sun, 05 Nov 2017 23:32:56 -0800 (PST) Received: from chichi (ppp83-237-164-81.pppoe.mtu-net.ru. [83.237.164.81]) by smtp.gmail.com with ESMTPSA id a4sm2472749ljd.7.2017.11.05.23.32.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Nov 2017 23:32:56 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , "Paul Wouters" Cc: , "Sahana Prasad" References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> In-Reply-To: <23039.19522.246855.199327@fireball.acr.fi> Date: Mon, 6 Nov 2017 10:32:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 07:33:00 -0000 Hi Tero, > One question that comes to my mind is that why is the server offering > CA which issues RSASSA-PSS certificates it is does not support those > certificates. I.e. server is saying it will use CA which it cannot > use, and I would say that is configuration error in the server side. Well, if we are talking about the specific product we ran into interoperability problem with, then its behavior is a bit different. It does support RSASSA-PSS signatures in certificates, however it cannot use RSASSA-PSS signatures in IKE. I guess that the reason for such behaviour is because the certificate processing (including signature verification) is performed by some cert lib, while IKE signature forming/verification is performed by another piece of code. > Also usually client will know which certificate it must use when > connecting to the server, exactly as it must know which PSK it must > use when it connects to which server. There is no indication in certificate that the public key it contains must be used explicitely with RSASSA-PKCS#1 or RSASSA-PSS. So, the client does know which certificate to us, it doesn't know which form of signature to use. > I can see that there are corner cases where the adminstrative domain > is updating from PKCS#1 certificates to the RSASSA-PSS, and not all of > its infrastructure is updated yet, but it can prevent issues by either > making sure server sides are updated before clients, There are use cases when both peers can act as initiator and responder (SG-SG). > or using separate CA for different key types. Very inconvenient. > Another case where this might happen when > client is doing opportunistic encryption i.e., it does not even try to > authenticate, thus it does not care which key it is using or what key > the other end is using, thus it will just pick one of its own keys and > use that. > > In most cases IPsec is considered as "requires preconfiguration" use > case, i.e., I cannot random try to connect host A with IPsec and > assume that will work. It is same thing with secure shell, i.e., > unless I have account and password or key configured for host A, there > is no point of trying to see if I can log in to the host A. I.e., if > you need to configure that this is the CA I want to trust when > connecting to host A, and this is the identity I am going to use for > myself, it is not that much more to configure that this is the key I > am going to use when authenticating to host A. With PSK I will need to > explictly give the keys anyways, why should the certificates be that > much different case, that you cannot preconfigure the key you are > using. > > TLS and HIP are examples of cases which are more or less "no > preconfiguration required", i.e., you can just try to connect and if > it works then you can use connection. I think that is true only for HTTPS use case, when TLS client is preconfigured with a bunch of trusted CAs and the authentication is performed one-way. Is not true for TLS in general. > This is the reason why the RFC7427 only negotiates the hash algorithm, > and the section 5 of the RFC 7427 gives several ways of solving this > issue without doing protocol changes. No, section 5 is about a different problem: how to select a proper certificate, if we have several certificates containing public keys for different signature algorithms. Now we have the only certificate (or raw key), but we don't know how to use it, because there are more than one way of using it and the peer doesn't inform us what it supports. > I still think this is more or less a configuration mismatch issue, > i.e., if your configuration is wrong you will end up in trouble, but > if you plan your upgrade process, or configure your systems correctly, > this issue is disappears. In some cases it can be solved by additional configuration option, but I dont't think in all. The other option for initiator is to retry IKE SA in case it receives AUTHENTICATION_FAILED. But it is very bad option and I'd rather resolve it by protocol means. RSASSA-PSS is just a specific problem we ran into, I suspect we can have the same sort of problem in future with other signature algorithms, provided their number is nowdays increasing rapidly. Regards, Valery. > -- > kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 6 01:50:32 2017 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 1C44113FB83 for ; Mon, 6 Nov 2017 01:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbinNDEberVK for ; Mon, 6 Nov 2017 01:50:27 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F1413FA82 for ; Mon, 6 Nov 2017 01:50:26 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 090FC201FA; Mon, 6 Nov 2017 10:50:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id E1E5320068; Mon, 6 Nov 2017 10:50:24 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Mon, 6 Nov 2017 10:50:24 +0100 From: To: Paul Wouters CC: "ipsec@ietf.org" Thread-Topic: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes Thread-Index: AdNSV4kHi0D1kj0WS2KalqWhxj42+AAJES2AARgZ1qA= Date: Mon, 6 Nov 2017 09:50:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A071E94@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A0634FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 09:50:31 -0000 RGVhciBQYXVsLCANCg0KVGhhbmsgeW91IGZvciB0aGUgZmVlZGJhY2suDQoNClBsZWFzZSBzZWUg aW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogUGF1bCBXb3V0ZXJzIFttYWlsdG86cGF1bEBub2hhdHMuY2FdDQo+IEVudm95w6nC oDogbWFyZGkgMzEgb2N0b2JyZSAyMDE3IDIxOjEwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVk IElNVC9PTE4NCj4gQ2PCoDogaXBzZWNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtJUHNlY10g ZHJhZnQtYm91Y2FkYWlyLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzDQo+IA0KPiBPbiBUdWUsIDMx IE9jdCAyMDE3LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiANCj4gPiBB cyBwZXIgYSBzdWdnZXN0aW9uIGZyb20gVGVybywgSeKAmW0gc2VuZGluZyB0aGlzIG1lc3NhZ2Ug dG8gdGhlIGxpc3QgdG8NCj4gYXNrIGZvciBtb3JlIGZlZWRiYWNrIG9uIHRoaXMgc2hvcnQgZHJh ZnQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItaXBzZWNt ZS1pcHY2LWlwdjQtY29kZXMtMDANCj4gPg0KPiA+IEZXSVcsIHRoZSBkcmFmdCBpbmNsdWRlcyBh biDigJx1cGRhdGXigJ0gaGVhZGVyIGJlY2F1c2UgSSB0aG91Z2h0IHRoaXMgY2FuDQo+IGJlIGdl bmVyYWxpemVkIHRvIG90aGVyIHVzZSBjYXNlcyB0aGFuIHRoZSAzR1BQIGNhc2UgSeKAmW0gaW50 ZXJlc3RlZCBpbi4NCj4gPg0KPiA+IENvbW1lbnRzIGFuZCBndWlkYW5jZSB0byBnZXQgZWFybHkg Y29kZXBvaW50IGFzc2lnbm1lbnRzIGlzIG1vcmUgdGhhbg0KPiB3ZWxjb21lLg0KPiANCj4gSXQg c2VlbXMgb2theSB0byByZXR1cm4gc29tZSBtb3JlIGluZm9ybWF0aW9uIGluIHRoZSBlcnJvcnMg b24gb2J0YWluaW5nDQo+IGFuIGludGVybmFsIElQIGFkZHJlc3MuDQoNCltNZWRdIE9LLCB0aGFu a3MuDQoNCj4gDQo+IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIG1lYW5pbmcgb2YgU0lO R0xFX0FGX1NVUFBPUlRFRC4gRG9lcyB0aGF0DQo+IGltcGx5IHRoZSBmYW1pbHkgbXVzdCBiZSB0 aGUgc2FtZSBhcyB0aGUgSUtFIGFkZHJlc3MgZmFtaWx5IHVzZWQ/DQoNCltNZWRdIE5vLg0KDQog T3INCj4gZG9lcyBpdCBqdXN0IG1lYW4geW91IGNhbiBvbmx5IHJlcXVlc3QgdjQgb3IgdjYgYnV0 IG5vdCBib3RoIF9hbmRfDQo+IGl0IGlzIGluZGVwZW5kZW50IG9mIHRoZSBhZGRyZXNzIGZhbWls eSB1c2VkIGZvciB0aGlzIElLRSBleGNoYW5nZT8NCg0KW01lZF0gWWVzLiANCg0KVGhpcyBjb2Rl IGlzIHR5cGljYWxseSByZXR1cm5lZCB3aGVuIGFuIGluaXRpYXRvciBpbmNsdWRlcyBib3RoIElO VEVSTkFMX0lQNF9BRERSRVNTIGFuZCBJTlRFUk5BTF9JUDZfQUREUkVTUyBpbiB0aGUgc2FtZSBy ZXF1ZXN0LCBidXQgb25seSBJTlRFUk5BTF9JUDRfQUREUkVTUyBvciBJTlRFUk5BTF9JUDZfQURE UkVTUyBjYW4gYmUgaG9ub3JlZCBwZXIgcmVxdWVzdC4gVGhhdCBpcywgaW4gYWRkaXRpb24gdG8g dGhlIElQdjQgYWRkcmVzcyBvciBJUHY2IHByZWZpeCwgdGhlIHJlc3BvbnNlIHdpbGwgaW5jbHVk ZSBTSU5HTEVfQUZfU1VQUE9SVEVEIHRvIG5vdGlmeSB0aGUgaW5pdGlhdG9yIHRoYXQgb25seSBJ UHY0IG9yIElQdjYgY29uZmlndXJhdGlvbiBjYW4gYmUgaGFuZGxlZCBwZXIgcmVxdWVzdCwgbm90 IGJvdGguIFRoZSBjcml0ZXJpYSB0byBzZWxlY3Qgd2hpY2ggYWRkcmVzcyBmYW1pbHkgdG8gaG9u b3Igd2hlbiBib3RoIGFyZSBpbmNsdWRlZCBpbiBhIHJlcXVlc3QsIGlzIHBvbGljeS1iYXNlZC4g DQoNCj4gDQo+IFRoYXQgaXMsIGFyZSB5b3UgZXhwZWN0aW5nIDRpbjYgYW5kIDZpbjQgaXRlbXMg aWYgdGhlIElLRSBwZWVyIGFkZHJlc3MNCj4gZmFtaWx5IGlzIG9uZSwgYW5kIHRoZSBJTlRFUk5B TF9JUCBmYW1pbHkgaXMgdGhlIG90aGVyIGZhbWlseT8NCj4gDQo+IE1heWJlIHRoaXMgaXMgZ2V0 dGluZyB0b28gY29tYmluYXRvcnksIGFuZCB0aGUgbm90aWZ5IHNob3VsZCBiZSBqdXN0DQo+IGEg RkFNSUxZX1JFU1RSSUNUSU9OIHR5cGUgd2l0aCBhIHZhbHVlIHRoYXQgY2FuIGJlIHZhcmlvdXMg dGhpbmdzLA0KPiBzbyB5b3UgY2FuIHNheSB2NG9ubHksIHY2b25seSwgaW50ZXJuYWw9ZXh0ZXJu YWwsIDRpbjZhbGxvd2VkLA0KPiA2aW40YWxsb3dlZCA/DQoNCltNZWRdIEdpdmVuIHRoZSBhdmFp bGFibGUgc3BhY2UgKDQ3LTgxOTEpLCBhc3NpZ25pbmcgNCBjb2RlcyBpcyBtdWNoIG1vcmUgc2lt cGxlIGNvbXBhcmVkIHRvIGFzc2lnbmluZyBhIHR5cGUgd2l0aCBzdWItdmFsdWVzLiAgDQpQbGVh c2Ugbm90ZSB0aGF0IG5vbmUgb2YgdGhlIHZhbHVlcyBsaXN0ZWQgaW4geW91ciBleGFtcGxlIGNh biBiZSByZXR1cm5lZCBhcyBhbiBlcXVpdmFsZW50IHRvIFNJTkdMRV9BRl9TVVBQT1JURUQgZGVz Y3JpYmVkIGFib3ZlLiANCg0KPiANCj4gUGF1bA0K From nobody Sat Nov 11 22:44:49 2017 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 20C21126C0F for ; Sat, 11 Nov 2017 22:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-atn48EoR7d for ; Sat, 11 Nov 2017 22:44:46 -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 2D9B91293D9 for ; Sat, 11 Nov 2017 22:44:46 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yZPQL5StHz3GW for ; Sun, 12 Nov 2017 07:44:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510469082; bh=qjPdd/OrNgwOWnGEeGUNkLPengpaDGKmEydJkJcluCI=; h=Date:From:To:Subject:In-Reply-To:References; b=BsznHvs8OWXmuzfEkFJkJzhBNhLl49YoPNf/bosRFhSyNSSr4qZKuzolAnOyp57Tv ClQR25pMn49eqponJTjoOw99FCiMD6AXVrUX7zKkM0dmo2pmxkJ9IPDQ40tGQzf7pg 4wuFSL0E8H9sbv2d2OofafWKI4iIRV7y+cFrxLYA= 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 CA7Oe2yeZWfk for ; Sun, 12 Nov 2017 07:44:40 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 12 Nov 2017 07:44:39 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B635262D29; Sun, 12 Nov 2017 01:44:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B635262D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9FE2940D35AF for ; Sun, 12 Nov 2017 01:44:38 -0500 (EST) Date: Sun, 12 Nov 2017 01:44:38 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <0023D7DE-30B7-417B-9612-9E3FCA7A7263@apple.com> Message-ID: References: <119401d35182$7eef32c0$7ccd9840$@gmail.com> <0023D7DE-30B7-417B-9612-9E3FCA7A7263@apple.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 06:44:48 -0000 Valery Smyslov wrote: Thanks for the review! > I found the document almost ready. A few editorial issues should be resolved. > > 1. Throughout the document attribute INTERNAL_DNSSEC_TA is often called INTERNAL_DNS_TA. >    Please, choose a single name :-) Fixed. Should have been INTERNAL_DNSSEC_TA everywhere. > s/one more more/one or more Fixed. > 3. Section 4.1 > >   o  Domain Name (0 or more octets) - A Fully Qualified Domain Name >      used for Split DNS rules, such as example.com, in DNS presentation >      format and optionally using IDNA [RFC5890] for Internationalized >      Domain Names.  The value is NOT null-terminated. > > Why NOT is in uppercase? It is not a RFC2119 word, I guess... It was a warning to C programmers :) I changed it to: Implementors need to be careful that this value is not null-terminated. > 4. Section 4.2 > >   o  DNSKEY algorithm (0 or 1 octet) - Value from the IANA DNS Security >      Algorithm Numbers Registry > >   o  DS algorithm (0 or 1 octet) - Value from the IANA Delegation >      Signer (DS) Resource Record (RR) Type Digest Algorithms Registry > > There are no such fields in the picture above. There are fields > Algorithm  and Digest Type. Please, make the names match > those in the picture. Fixed. > 5. Section 6 > >   INTERNAL_DNSSEC_TA directives MUST immediately follow an >   INTERNAL_DNS_DOMAIN directive.  As the INTERNAL_DNSSEC_TA format >   itself does not contain the domain name, it relies on the preceding >   INTERNAL_DNS_DOMAIN to provide the domain for which it specifies the >   trust anchor. > > s/directives/attributes > s/directive/attribute I did s/directive/payload/ instead. I'll push -03 once the submission window opens again tomorrow. Paul From nobody Sat Nov 11 22:49:39 2017 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 29A36126C0F; Sat, 11 Nov 2017 22:49:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151046937211.30926.13638040576169367957@ietfa.amsl.com> Date: Sat, 11 Nov 2017 22:49:32 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 06:49:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-03.txt Pages : 11 Date : 2017-11-11 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". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-03 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 Nov 12 06:03:31 2017 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 27C9112943D for ; Sun, 12 Nov 2017 06:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iGVHrfOLdcEO for ; Sun, 12 Nov 2017 06:03:28 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 ED1451200F1 for ; Sun, 12 Nov 2017 06:03:27 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id 73so1268601lfu.10 for ; Sun, 12 Nov 2017 06:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XBbLQorKAk3I1dTU5QEWXjgas0eRhUg3wLAogPFnQe4=; b=P7yE908NVyFQpOGoEasYlSJRNbHvRyliRjnUEqMc2Djuxa21Pui7dxykEP+eNhU4WA 49IcaTrVXTk5PvFii8cHOKsOXG0H398o9yCa+A8wEkllm/g58CZNrLKfJ2SngxnKO6N/ AjqHmgw8cN6mneaR7O28skiErLWiWnFQNY7A4VAMA/7ugJQ7zZOGAuoLt6fbhu4qimqk QLc+ufW89wsJZY/5H6Iw6uaifhEKnlucTPKIPIC8oFIs2G/exXMDcrm1+tQwNHyMeSKX C8BIbRi1YXwvFWxtOiGVSo4MatqbdOrYeSH2LXZ1upuPmH2EgjxWbqtTnBQ7VmhXtIkj JZ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XBbLQorKAk3I1dTU5QEWXjgas0eRhUg3wLAogPFnQe4=; b=c6aLavoionCzJHIXPQLEwKx5XDep4N7DWUoE4cBbxSN3xmurdbO+8GiO8HtKRmwSoM tCS7tOck91HLEilEcprp8nbRmHvufE4yFErF8HiYhbj05MEGfEGC8XQ7LpJgZg0VjojU bo6VndUQNqcu+NNV9EdhVWlHBj8du0pZltamGCtjnG5f//9KW4KMwKwUaeI3cMEZziIJ AhJ56dUZvpbpDNqxIZRTphhYQyAWxsFdRz9X620pSbhMIEjZMmTHpmuiNIcGxdri89q9 eoLsvG9xHT0YpvatNnlawKGCEL+AA69jawtadqf5oAGNss6OoIJ+FuOZSU+fNZviBrDb zrQw== X-Gm-Message-State: AJaThX7Rj6TQbqTEzLG1Ut1tXGFRIyNGGTV4W0vpRRtJAPf7mDLSCSF4 DFvB1yFHjql0Mu1rzt19g5cs0+EWDYwIi7eqW3Y= X-Google-Smtp-Source: AGs4zMZDnC6xEjNpDzOv82y2DXewim46l35HD9dOIvQ+SRu7UtFKeff6O7PMge2i13WqYA59ASXZrNgyD4p8M6qE3Zc= X-Received: by 10.46.25.18 with SMTP id p18mr2102102lje.24.1510495406179; Sun, 12 Nov 2017 06:03:26 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.82.218 with HTTP; Sun, 12 Nov 2017 06:03:25 -0800 (PST) In-Reply-To: <116c01d3517a$a071f840$e155e8c0$@gmail.com> References: <116b01d35179$5545b240$ffd116c0$@gmail.com> <116c01d3517a$a071f840$e155e8c0$@gmail.com> From: Daniel Migault Date: Sun, 12 Nov 2017 09:03:25 -0500 X-Google-Sender-Auth: c9oGcyjG_ytg0Qqff0eGdq0GTX8 Message-ID: To: Valery Smyslov Cc: "Waltermire, David A. (Fed)" , IPsecME WG Content-Type: multipart/alternative; boundary="94eb2c1a66641eca51055dc99e08" Archived-At: Subject: Re: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 14:03:30 -0000 --94eb2c1a66641eca51055dc99e08 Content-Type: text/plain; charset="UTF-8" Hi, This is the text I propose to address Valery comment regarding the IANA consideration section. Let me know if you have any comment on that. Yours, Daniel 8. IANA Considerations AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. This section limits assignment of new code points to the recommended suites provided in [RFC8221], thus the new Transform Type 1 - Encryption Algorithm Transform IDs are as defined below: - ENCR_AES_CCM_8_IIV - ENCR_AES_GCM_16_IIV - ENCR_CHACHA20_POLY1305_IIV [RFC8247] recommends the same suites for IKEv2. However some IKEv2 extensions such as [RFC6311] or [RFC7383] allow the Message ID to be re-initialized, which is incompatible with the uniqueness property of the nonce, and makes these suites highly insecure. Given that the traffic associated to IKEv2 is expected to remain low compared to the ESP traffic, the suites defined in this document MUST NOT be used for IKEv2. The IANA is expected to put "Not allowed" in the column "IKEv2 Reference" for these transforms. On Mon, Oct 30, 2017 at 8:28 AM, Valery Smyslov wrote: > Sorry, I made a typo (see below): > > > 2. IANA Considerations > > > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > > implement the implicit IV described in this document. This section > > limits assignment of new code points to the recommended suites > > provided in [I-D.ietf-ipsecme-rfc4307bis] and > > [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 - > > Encryption Algorithm Transform IDs are as defined below: > > > > The newly defined IIV transforms are not applicable for IKEv2 > (because there is no unique per message field; > > Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). > So, [I-D.ietf-ipsecme-rfc7321bis] > > [I-D.ietf-ipsecme-rfc4307bis] of course. > > > (now RFC8247) must not be referenced here. Moreover, I'd like to > express this prohibition > > more explicitly in IANA registry, instructing IANA to put "Not > allowed" in the column "IKEv2 Reference" > > for these transforms: > > So, the correct text is: > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This section > limits assignment of new code points to the recommended suites > provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using > implicit IV for these > algorithms is defined for ESP only and is not allowed for > protecting > IKEv2 messages. > > IANA is requested to add the following transforms to the Transform > Type 1 - > Encryption Algorithm Transform IDs registry for IKEv2, setting > "ESP Reference" > to this document and marking "IKEv2 Reference" as "Not allowed": > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --94eb2c1a66641eca51055dc99e08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This is the text I propos= e to address Valery comment regarding the IANA consideration section. Let m= e know if you have any comment on that.

Yours,
Danie= l=C2=A0

8.=C2=A0 IANA Considerations

=C2=A0= =C2=A0 AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
=C2= =A0=C2=A0 implement the implicit IV described in this document.=C2=A0 This = section
=C2=A0=C2=A0 limits assignment of new code points to the recomme= nded suites
=C2=A0=C2=A0 provided in [RFC8221], thus the new Transform T= ype 1 - Encryption
=C2=A0=C2=A0 Algorithm Transform IDs are as defined b= elow:

=C2=A0=C2=A0 -=C2=A0 ENCR_AES_CCM_8_IIV

=C2=A0=C2=A0 -= =C2=A0 ENCR_AES_GCM_16_IIV

=C2=A0=C2=A0 -=C2=A0 ENCR_CHACHA20_POLY13= 05_IIV

=C2=A0=C2=A0 [RFC8247] recommends the same suites for IKEv2.= =C2=A0 However some IKEv2
=C2=A0=C2=A0 extensions such as [RFC6311] or [= RFC7383] allow the Message ID to be
=C2=A0=C2=A0 re-initialized, which i= s incompatible with the uniqueness property of
=C2=A0=C2=A0 the nonce, a= nd makes these suites highly insecure.=C2=A0 Given that the
=C2=A0=C2=A0= traffic associated to IKEv2 is expected to remain low compared to the
= =C2=A0=C2=A0 ESP traffic, the suites defined in this document MUST NOT be u= sed for
=C2=A0=C2=A0 IKEv2.=C2=A0 The IANA is expected to put "Not = allowed" in the column
=C2=A0=C2=A0 "IKEv2 Reference" for= these transforms.


On Mon, Oct 30, 2017 at 8:28 AM, Valery Sm= yslov <svanru@gmail.com> wrote:
Sorry, I made a typo (see below):

> 2. IANA Considerations
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1= 305 are likely to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement the implicit IV described in this = document.=C2=A0 This section
>=C2=A0 =C2=A0 =C2=A0 =C2=A0limits assignment of new code points to the = recommended suites
>=C2=A0 =C2=A0 =C2=A0 =C2=A0provided in [I-D.ietf-ipsecme-rfc4307bis] an= d
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ipsecme-rfc7321bis], thus the new = Transform Type 1 -
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Encryption Algorithm Transform IDs are as de= fined below:
>
>=C2=A0 =C2=A0 =C2=A0The newly defined IIV transforms are not applicable= for IKEv2 (because there is no unique per message field;
>=C2=A0 =C2=A0 =C2=A0Message ID do can repeat, e.g. in case RFC6311 or R= FC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis]

[I-D.ietf-ipsecme-rfc4307bis] of course.

>=C2=A0 =C2=A0 =C2=A0(now RFC8247) must not be referenced here. Moreover= , I'd like to express this prohibition
>=C2=A0 =C2=A0 =C2=A0more explicitly in IANA registry, instructing IANA = to put "Not allowed" in the column "IKEv2 Reference" >=C2=A0 =C2=A0 =C2=A0for these transforms:

So, the correct text is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305= are likely to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implement the implicit IV described in this doc= ument.=C2=A0 This section
=C2=A0 =C2=A0 =C2=A0 =C2=A0 limits assignment of new code points to the rec= ommended suites
=C2=A0 =C2=A0 =C2=A0 =C2=A0 provided in [I-D.ietf-ipsecme-rfc7321bis= ]. Note, that using implicit IV for these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithms is defined= for ESP only and is not allowed for protecting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IKEv2 messages.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA is requested to add the following transfor= ms to the Transform Type 1 -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Encryption Algorithm Transform IDs registry for= IKEv2, setting "ESP Reference"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to this document and marking "IKEv2 Refere= nce" as "Not allowed":

Regards,
Valery.


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

--94eb2c1a66641eca51055dc99e08-- From nobody Sun Nov 12 06:51:45 2017 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 9A3451200FC for ; Sun, 12 Nov 2017 06:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF-0qBBvz5Zw for ; Sun, 12 Nov 2017 06:51:42 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 A690A1200F1 for ; Sun, 12 Nov 2017 06:51:41 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id o66so7443207lfg.0 for ; Sun, 12 Nov 2017 06:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=3aG4SpDgjvuQUCKjjXNBwV//sdhieajmR/2QM/d3efw=; b=ME1WwlnoFobE0APULRak5fOVTkSZPIlbeGiLZ0AHBriiYTeZEd/Hr/M2XHFF2+Gco1 UN5Ov9K+uMWTokOlWLFhYmOxv6OUkJ08pq5qjQ1Czf3dS5Ycnv4R0kv91tGEoDZN2gM+ IJeO07mgP60atjPMTizmov7DaXKMmxThA9oEC4SRb8GssFFqVM538ZnqiE+TZect1HQn c+pmrGcjfhBaJVHHyyBDQMHDoOfIadiGWTHar2F4JzrBn7T3JfBBA5O8IVVNU1Y+POPa vc1lJbYHdEj8BraY8820aY167L7JWKWZWVpo45N05n+8Lkgn5vKlLVvRsLUDlwP9epQj ToOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=3aG4SpDgjvuQUCKjjXNBwV//sdhieajmR/2QM/d3efw=; b=bDcKyuqGUR/NXHrfi5OhHfpuBevdmFPox5LC0IHbPVLSnUMwAFpJK9nNeDKLfWMaeh nprx/1GSySIQ0E92Zy4xhi5rpqL7eZcF9AxAOb5BE/vPC8yirLzavl5oiQO7YCgnp30R I8oqkovOCQK7HATLvnmsXEnPo1BaAoqoWbSWAEfFdgnWXlD9bbmntbOO3PGL6jK2GvQ9 DIsvXq1gIdXLfO0uK5oNgGq1rnuLBYswuZB/HRC5/lAtFGzWNVzcFIeAZMKmbT3NvIyG o3bggRfDD5nQGl9szP6jDwSw+6zdNwozSIAdO1i4wKTsduZkB/jA0C3pA+IEYzvzfr/V uTBw== X-Gm-Message-State: AJaThX7aDqW0+4xP6+B0xdXYu4J6u+D7n4i/XLcNIuUOJ/XiCqnkDXAF IUfez11cirY52npeY6Sy1Dw= X-Google-Smtp-Source: AGs4zMZJuZh8bzQ5KEND3ENTcnuwU1yGAFTl66hLgyoGz5oTTzVbxiiGu7qxiVcLpw3O5cbjktp3+w== X-Received: by 10.46.83.25 with SMTP id h25mr2234581ljb.158.1510498299927; Sun, 12 Nov 2017 06:51:39 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t10sm2640705lja.92.2017.11.12.06.51.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 12 Nov 2017 06:51:39 -0800 (PST) From: "Valery Smyslov" To: "'Daniel Migault'" Cc: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: <116b01d35179$5545b240$ffd116c0$@gmail.com> <116c01d3517a$a071f840$e155e8c0$@gmail.com> In-Reply-To: Date: Sun, 12 Nov 2017 17:51:34 +0300 Message-ID: <004801d35bc5$bcc15c70$36441550$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01D35BDE.E2134F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJvoYhNuzlFapr5r+XuB80i/J+14QJ2EjuaAlkxuwICL51F1KGgThmQ Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 14:51:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0049_01D35BDE.E2134F60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, =20 thank you for addressing that. I have no problems with your text. There are two nits, however. First: in phrase =E2=80=9Dallow the Message = ID to be re-initialized=E2=80=9D I would use some other word instead of =E2=80=9Cre-initialized=E2=80=9D, = e.g. =E2=80=9Creused=E2=80=9D, or =E2=80=9Crepeated=E2=80=9D. And second: I would change =E2=80=9CIANA = is expected=E2=80=9D to =E2=80=9CIANA is requested=E2=80=9D or smth similar. =20 Regards, Valery. =20 =20 Hi,=20 This is the text I propose to address Valery comment regarding the IANA = consideration section. Let me know if you have any comment on that. Yours,=20 Daniel =20 8. IANA Considerations AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. This section limits assignment of new code points to the recommended suites provided in [RFC8221], thus the new Transform Type 1 - Encryption Algorithm Transform IDs are as defined below: - ENCR_AES_CCM_8_IIV - ENCR_AES_GCM_16_IIV - ENCR_CHACHA20_POLY1305_IIV [RFC8247] recommends the same suites for IKEv2. However some IKEv2 extensions such as [RFC6311] or [RFC7383] allow the Message ID to be re-initialized, which is incompatible with the uniqueness property of the nonce, and makes these suites highly insecure. Given that the traffic associated to IKEv2 is expected to remain low compared to the ESP traffic, the suites defined in this document MUST NOT be used for IKEv2. The IANA is expected to put "Not allowed" in the column "IKEv2 Reference" for these transforms. =20 On Mon, Oct 30, 2017 at 8:28 AM, Valery Smyslov = wrote: Sorry, I made a typo (see below): > 2. IANA Considerations > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This = section > limits assignment of new code points to the recommended suites > provided in [I-D.ietf-ipsecme-rfc4307bis] and > [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 - > Encryption Algorithm Transform IDs are as defined below: > > The newly defined IIV transforms are not applicable for IKEv2 = (because there is no unique per message field; > Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is = used). So, [I-D.ietf-ipsecme-rfc7321bis] [I-D.ietf-ipsecme-rfc4307bis] of course. > (now RFC8247) must not be referenced here. Moreover, I'd like to = express this prohibition > more explicitly in IANA registry, instructing IANA to put "Not = allowed" in the column "IKEv2 Reference" > for these transforms: So, the correct text is: AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the implicit IV described in this document. This = section limits assignment of new code points to the recommended suites provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using = implicit IV for these algorithms is defined for ESP only and is not allowed for = protecting IKEv2 messages. IANA is requested to add the following transforms to the = Transform Type 1 - Encryption Algorithm Transform IDs registry for IKEv2, setting = "ESP Reference" to this document and marking "IKEv2 Reference" as "Not allowed": Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_0049_01D35BDE.E2134F60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Daniel,

 

thank you for addressing that. I have no problems with your = text.

There are two nits, however. First: in phrase =E2=80=9Dallow the = Message ID to be re-initialized=E2=80=9D

I would use some other word instead of = =E2=80=9Cre-initialized=E2=80=9D, e.g. = =E2=80=9Creused=E2=80=9D,

or =E2=80=9Crepeated=E2=80=9D. And second: I would change = =E2=80=9CIANA is expected=E2=80=9D

to =E2=80=9CIANA is requested=E2=80=9D or smth = similar.

 

Regards,

Valery.

 

 

Hi,

This is the text I = propose to address Valery comment regarding the IANA consideration = section. Let me know if you have any comment on = that.

Yours, =

Daniel  =


8.  IANA = Considerations

   AES-CTR, AES-CCM, AES-GCM and = ChaCha20-Poly1305 are likely to
   implement the implicit = IV described in this document.  This section
   limits = assignment of new code points to the recommended suites
   = provided in [RFC8221], thus the new Transform Type 1 - = Encryption
   Algorithm Transform IDs are as defined = below:

   -  = ENCR_AES_CCM_8_IIV

   -  = ENCR_AES_GCM_16_IIV

   -  = ENCR_CHACHA20_POLY1305_IIV

   [RFC8247] recommends the = same suites for IKEv2.  However some IKEv2
   = extensions such as [RFC6311] or [RFC7383] allow the Message ID to = be
   re-initialized, which is incompatible with the = uniqueness property of
   the nonce, and makes these suites = highly insecure.  Given that the
   traffic associated = to IKEv2 is expected to remain low compared to the
   ESP = traffic, the suites defined in this document MUST NOT be used = for
   IKEv2.  The IANA is expected to put "Not = allowed" in the column
   "IKEv2 Reference" = for these transforms.

 

On Mon, = Oct 30, 2017 at 8:28 AM, Valery Smyslov <svanru@gmail.com> wrote:

Sorry, I made a typo = (see below):

> 2. IANA Considerations
>
>  =      AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are = likely to
>       implement the implicit IV = described in this document.  This section
>    =    limits assignment of new code points to the recommended = suites
>       provided in = [I-D.ietf-ipsecme-rfc4307bis] and
>      =  [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 = -
>       Encryption Algorithm Transform IDs = are as defined below:
>
>     The newly = defined IIV transforms are not applicable for IKEv2 (because there is no = unique per message field;
>     Message ID do can = repeat, e.g. in case RFC6311 or RFC7383 is used). So, = [I-D.ietf-ipsecme-rfc7321bis]

[I-D.ietf-ipsecme-rfc4307bis] of = course.

>     (now RFC8247) must not be = referenced here. Moreover, I'd like to express this = prohibition
>     more explicitly in IANA registry, = instructing IANA to put "Not allowed" in the column = "IKEv2 Reference"
>     for these = transforms:

So, the correct text is:

      =   AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely = to
        implement the implicit IV described in = this document.  This section
        limits = assignment of new code points to the recommended suites
    =     provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that = using implicit IV for these
      =   algorithms is defined for ESP only and is not allowed for = protecting
        IKEv2 = messages.

        = IANA is requested to add the following transforms to the Transform Type = 1 -
        Encryption = Algorithm Transform IDs registry for IKEv2, setting "ESP = Reference"
        = to this document and marking "IKEv2 Reference" as "Not = allowed":

Regards,
Valery.


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

 

------=_NextPart_000_0049_01D35BDE.E2134F60-- From nobody Sun Nov 12 06:54:40 2017 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 CDFC5129456 for ; Sun, 12 Nov 2017 06:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_lYzWf07ctm for ; Sun, 12 Nov 2017 06:54:37 -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 2A4D91200F1 for ; Sun, 12 Nov 2017 06:54:37 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yZcHb2sDBz5K for ; Sun, 12 Nov 2017 15:54:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510498475; bh=PVXglaoAQLEJlnXg9k6wDDj9K09Ddopn4TBaK5oN0P8=; h=Date:From:To:Subject; b=i43rGaFR0nDMPbmgn0h5gGH9fKEC0TrAVScknIgy7feW6MVMQYpe50EXQaOpJqTLX bDpbXaAmOIBKRaK98wZ7eKvMnmY9g7MgEUYOk8cLc8AWgCVaUlgpVn45VQBLnAj5hj scU2PnEmEVv3Owa/LI4XqDMHm1HRKhoPKZWwnMIc= 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 pSET9kWeIDTy for ; Sun, 12 Nov 2017 15:54:30 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 12 Nov 2017 15:54:30 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9288862D29; Sun, 12 Nov 2017 09:54:29 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9288862D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7F32440D35AF for ; Sun, 12 Nov 2017 09:54:29 -0500 (EST) Date: Sun, 12 Nov 2017 09:54:29 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Labeled IPsec for charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 14:54:39 -0000 Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2. Paul From nobody Sun Nov 12 15:35:26 2017 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 440F9126C83 for ; Sun, 12 Nov 2017 15:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 SVGqzDB_eJPA for ; Sun, 12 Nov 2017 15:35:20 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 4EC161242F5 for ; Sun, 12 Nov 2017 15:35:19 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id 73so2058626lfu.10 for ; Sun, 12 Nov 2017 15:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6DlCqnXJoGW6A5esHEjWXug8EGql0e+7+u4Kz9Dakd4=; b=mNaSFwYYbczK5eaB68mpZ+kxiCstdnMtDoulKYE+4S5oed4bQZIiiHlx8JqcMBXeUZ ZLjb8QFSRqYrgcyST6++9iLuwHxQ8Z/vibc57+yYH9RWITvybTMpHLqk1o7AoNt2wpqF +ihEZFQYdpXwrYEaiEJBXIKNqBnYuMQbhIqPDlqprZQ1cA3IX9ettSbTMY8z6jCK89/y xOFxLU+zVnbtyMnRyT8YPj1B319ssCtT7glUDEdIqwwtUOx9Rp8J5KcJPGQceVFZLSo7 WxDImCQYyO0UJZhg/HJHV9mEGH+W5hWal3l9ecPKmkgj/2ezC18w5QoIRXBdw+WpJBKO YN6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6DlCqnXJoGW6A5esHEjWXug8EGql0e+7+u4Kz9Dakd4=; b=FTDSw7eloEPNARcZoH1cHUBww3jWZp9TN/o0oP1jdp770lQmRyFVUqm3Pz8vOzKeKA M2z57vWAhRtwmuhp0R5z7m2CBulRNb73Xd8vKL8E1L3riEeUwHURi+c9NR8L+XjWcB7M hlmPAaiozCBkwBudJgPizzVXVhEnn3g1Rgkvp8axafJpCwgbkRYUIQWF/8HsA2NUIPRx 9f/VVBX1OJy174mHEzL4cN+Cya8jLKSy2C0OPGQ/nK3ATbNT9isDRg2rgO0VMMSUzOgq zvo0Gc3yrVO+IsOGsHMtI3xGwm2ZvE6r8ozelOmPRUKQk8aXQ6wzbbiDy4zjTqgMy0lb XwmQ== X-Gm-Message-State: AJaThX4UNzLk/5/MGQTfwJsibl8pJd/TQzvqNwlU6uFMWFnvxyUF4HUw z7RSgwa6EBP1lwXzrPZv1htzzDAG/iGdSTkpX0Y= X-Google-Smtp-Source: AGs4zMZC8MtuIBktwKWvOP39BubImJL1v8EBGNU0ZOiL1NnFhUvmAugwsep8qz6jiayPdpn3QOjo3xRc3PxK21psuQA= X-Received: by 10.25.17.19 with SMTP id g19mr1248232lfi.183.1510529717561; Sun, 12 Nov 2017 15:35:17 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.82.218 with HTTP; Sun, 12 Nov 2017 15:35:16 -0800 (PST) In-Reply-To: <004801d35bc5$bcc15c70$36441550$@gmail.com> References: <116b01d35179$5545b240$ffd116c0$@gmail.com> <116c01d3517a$a071f840$e155e8c0$@gmail.com> <004801d35bc5$bcc15c70$36441550$@gmail.com> From: Daniel Migault Date: Sun, 12 Nov 2017 18:35:16 -0500 X-Google-Sender-Auth: p2Uk8DtvZvpwA1o9Vit4We6rywY Message-ID: To: Valery Smyslov Cc: IPsecME WG , "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary="001a1140817c3cec9d055dd19ba9" Archived-At: Subject: Re: [IPsec] WGLC on draft-mglt-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:35:22 -0000 --001a1140817c3cec9d055dd19ba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feed back Valery. I am just waiting a bit in order to see if there is a consensus in a) not using suites that badly interfere with some extensions vs b) mentioning the suites must not be used wit these extensions. a) is definitively safer, but we may need b) later as well. Yours, Daniel On Sun, Nov 12, 2017 at 9:51 AM, Valery Smyslov wrote: > Hi Daniel, > > > > thank you for addressing that. I have no problems with your text. > > There are two nits, however. First: in phrase =E2=80=9Dallow the Message = ID to be > re-initialized=E2=80=9D > > I would use some other word instead of =E2=80=9Cre-initialized=E2=80=9D, = e.g. =E2=80=9Creused=E2=80=9D, > > or =E2=80=9Crepeated=E2=80=9D. And second: I would change =E2=80=9CIANA i= s expected=E2=80=9D > > to =E2=80=9CIANA is requested=E2=80=9D or smth similar. > > > > Regards, > > Valery. > > > > > > Hi, > > This is the text I propose to address Valery comment regarding the IANA > consideration section. Let me know if you have any comment on that. > > Yours, > > Daniel > > > 8. IANA Considerations > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This section > limits assignment of new code points to the recommended suites > provided in [RFC8221], thus the new Transform Type 1 - Encryption > Algorithm Transform IDs are as defined below: > > - ENCR_AES_CCM_8_IIV > > - ENCR_AES_GCM_16_IIV > > - ENCR_CHACHA20_POLY1305_IIV > > [RFC8247] recommends the same suites for IKEv2. However some IKEv2 > extensions such as [RFC6311] or [RFC7383] allow the Message ID to be > re-initialized, which is incompatible with the uniqueness property of > the nonce, and makes these suites highly insecure. Given that the > traffic associated to IKEv2 is expected to remain low compared to the > ESP traffic, the suites defined in this document MUST NOT be used for > IKEv2. The IANA is expected to put "Not allowed" in the column > "IKEv2 Reference" for these transforms. > > > > On Mon, Oct 30, 2017 at 8:28 AM, Valery Smyslov wrote: > > Sorry, I made a typo (see below): > > > 2. IANA Considerations > > > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > > implement the implicit IV described in this document. This secti= on > > limits assignment of new code points to the recommended suites > > provided in [I-D.ietf-ipsecme-rfc4307bis] and > > [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 - > > Encryption Algorithm Transform IDs are as defined below: > > > > The newly defined IIV transforms are not applicable for IKEv2 > (because there is no unique per message field; > > Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). > So, [I-D.ietf-ipsecme-rfc7321bis] > > [I-D.ietf-ipsecme-rfc4307bis] of course. > > > (now RFC8247) must not be referenced here. Moreover, I'd like to > express this prohibition > > more explicitly in IANA registry, instructing IANA to put "Not > allowed" in the column "IKEv2 Reference" > > for these transforms: > > So, the correct text is: > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This secti= on > limits assignment of new code points to the recommended suites > provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using > implicit IV for these > algorithms is defined for ESP only and is not allowed for > protecting > IKEv2 messages. > > IANA is requested to add the following transforms to the Transfor= m > Type 1 - > Encryption Algorithm Transform IDs registry for IKEv2, setting > "ESP Reference" > to this document and marking "IKEv2 Reference" as "Not allowed": > > Regards, > Valery. > > > _______________________________________________ > 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 > > --001a1140817c3cec9d055dd19ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feed back Valery. I am just waiting a = bit in order to see if there is a consensus in

a) not using suites = that badly interfere with some extensions
vs
b) mentioning the suit= es must not be used wit these extensions.

a) is de= finitively safer, but we may need b) later as well.

Yours,
Daniel=C2=A0

On Sun, Nov 12, 2017 at 9:51 AM, V= alery Smyslov <svanru@gmail.com> wrote:

Hi Daniel,

=C2=A0

tha= nk you for addressing that. I have no problems with your text.

There are two nits, however. First: in phrase =E2=80=9Dallow the Message = ID to be re-initialized=E2=80=9D

I would use some other word = instead of =E2=80=9Cre-initialized=E2=80=9D, e.g. =E2=80=9Creused=E2=80=9D,=

or =E2=80=9Crepeated=E2=80=9D. And second: I would change = =E2=80=9CIANA is expected=E2=80=9D

to =E2=80=9CIANA is reques= ted=E2=80=9D or smth similar.

=C2=A0

=

Regards,

Valery.

=C2=A0<= /u>

=C2=A0

Hi,

This is the text I propose = to address Valery comment regarding the IANA consideration section. Let me = know if you have any comment on that.

Yours,

Daniel=C2=A0=


8.=C2=A0 IANA Considerations

=C2=A0=C2=A0 AES-CTR, = AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
=C2=A0=C2=A0 implem= ent the implicit IV described in this document.=C2=A0 This section
=C2= =A0=C2=A0 limits assignment of new code points to the recommended suites=C2=A0=C2=A0 provided in [RFC8221], thus the new Transform Type 1 - Encryp= tion
=C2=A0=C2=A0 Algorithm Transform IDs are as defined below:

= =C2=A0=C2=A0 -=C2=A0 ENCR_AES_CCM_8_IIV

=C2=A0=C2=A0 -=C2=A0 ENCR_AE= S_GCM_16_IIV

=C2=A0=C2=A0 -=C2=A0 ENCR_CHACHA20_POLY1305_IIV

= =C2=A0=C2=A0 [RFC8247] recommends the same suites for IKEv2.=C2=A0 However = some IKEv2
=C2=A0=C2=A0 extensions such as [RFC6311] or [RFC7383] allow = the Message ID to be
=C2=A0=C2=A0 re-initialized, which is incompatible = with the uniqueness property of
=C2=A0=C2=A0 the nonce, and makes these = suites highly insecure.=C2=A0 Given that the
=C2=A0=C2=A0 traffic associ= ated to IKEv2 is expected to remain low compared to the
=C2=A0=C2=A0 ESP= traffic, the suites defined in this document MUST NOT be used for
=C2= =A0=C2=A0 IKEv2.=C2=A0 The IANA is expected to put "Not allowed" = in the column
=C2=A0=C2=A0 "IKEv2 Reference" for these transfo= rms.

<= u>=C2=A0

On Mon, Oct 30, 2017 at = 8:28 AM, Valery Smyslov <svanru@gmail.com> wrote:

Sorry, I made a typo (see below):
> 2. IANA Considerations
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-= CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0implement the implicit IV described in this document.=C2= =A0 This section
>=C2=A0 =C2=A0 =C2=A0 =C2=A0limits assignment of new= code points to the recommended suites
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pr= ovided in [I-D.ietf-ipsecme-rfc4307bis] and
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0[I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 -
&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0Encryption Algorithm Transform IDs are as def= ined below:
>
>=C2=A0 =C2=A0 =C2=A0The newly defined IIV transf= orms are not applicable for IKEv2 (because there is no unique per message f= ield;
>=C2=A0 =C2=A0 =C2=A0Message ID do can repeat, e.g. in case RFC= 6311 or RFC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis]

[I-D.iet= f-ipsecme-rfc4307bis] of course.

>=C2=A0 =C2=A0 =C2=A0(now RFC824= 7) must not be referenced here. Moreover, I'd like to express this proh= ibition
>=C2=A0 =C2=A0 =C2=A0more explicitly in IANA registry, instru= cting IANA to put "Not allowed" in the column "IKEv2 Referen= ce"
>=C2=A0 =C2=A0 =C2=A0for these transforms:

So, the co= rrect text is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 AES-CTR, AES-CCM, AES-GCM= and ChaCha20-Poly1305 are likely to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 impleme= nt the implicit IV described in this document.=C2=A0 This section
=C2=A0= =C2=A0 =C2=A0 =C2=A0 limits assignment of new code points to the recommend= ed suites
=C2=A0 =C2=A0 =C2=A0 =C2=A0 provided in [I-D.ietf-ipsecme-rfc7= 321bis]. Note, that using implicit IV for these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithms is defined for ESP o= nly and is not allowed for protecting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IKEv2 messages.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA is req= uested to add the following transforms to the Transform Type 1 -
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Encrypt= ion Algorithm Transform IDs registry for IKEv2, setting "ESP Reference= "
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 to this document and marking "IKEv2 Reference" as &quo= t;Not allowed":

Regards,
Valery.


____________________________________= ___________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listin= fo/ipsec

<= /u>=C2=A0


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


--001a1140817c3cec9d055dd19ba9-- From nobody Sun Nov 12 15:39:35 2017 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 CD7BA1242F5 for ; Sun, 12 Nov 2017 15:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, 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 GtEvW6t13vxx for ; Sun, 12 Nov 2017 15:39:32 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 0E6091205F0 for ; Sun, 12 Nov 2017 15:39: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=1510529970; 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=F3aWj9pTzMirmRPBZFZsoVPJUYr+loCY1X5o6xnE5VM=; b=CTcuekDz/92L8YyAjKdfppO6A/Y5tEfS71uBWZW52IvvF3CMKp7jiqN0nd76SXaO g5ePDMs7gq76c0AnGlknHxB3ADRqKnXeTTQWYMCtz5SSvnnMmFxQeNMCIXDR96ly /FPIAoXkI0dHt9jbAeh0+BUGbS7ZAOhBu4dXw6VS5PkDQv+jji05j+0+rVeCcj6K +jPLNNYUyFQjZ2C4b0ksYke+/FcIguJzz60IPdKV5DWErSGyHsCJLlDDyLhRmJg+ 1riUrGtw+fFnIzshugHTD0w+zokHioAOuwTebIyzxS7y22hnmIop0p13BH5/eYTu YcNo23WpjBfxIK2GFTBArQ==; Received: from relay2.asia.apple.com ( [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id B3.53.07591.1BBD80A5; Mon, 13 Nov 2017 07:39:29 +0800 (MYT) X-AuditID: 1152fe11-8cbff70000001da7-b7-5a08dbb1a722 Received: from sng-mailphp-s01.asia.apple.com ( [17.84.76.247]) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 82.6C.31851.1BBD80A5; Mon, 13 Nov 2017 07:39:29 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TWNEmuncU1U3y21qPyauKA)" Received: from [17.235.157.243] (unknown [17.235.157.243]) by sng-mailphp-s01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZB00C92WDS6T30@sng-mailphp-s01.asia.apple.com> for ipsec@ietf.org; Mon, 13 Nov 2017 07:39:29 +0800 (SGT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Mon, 13 Nov 2017 07:39:29 +0800 To: IPsecME WG X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUiGHRCQHfjbY4og7vvrC32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLsvJrEVXJOuOPj+PnMD40XxLkZODgkBE4mvrZPYuxi5OIQE VjJJtM+awdLFyAGWOPFbCiK+m1Hix9KlLCANvAKCEj8m3wOzmQXCJLrX72eEKNrCJLF9djtY QlhAWqLrwl1WkEFsAloSB9YYQYStJKauvMIMEuYVsJF4cT0QJMwioCrx5NdWJpCwiIC8xMwb mRCnKUocmTmHGWS6hMBHVol1E24zTWDkn4XkillIroCwtSS+P2oFinMA2fISB8/LQoQ1JZ7d +8QOYWtLPHl3gXUBI9sqRvHcxMwc3cw8Q73E4sxEvcSCgpxUveT83E2M4JD9J7iDcepCw0OM AhyMSjy8wsc5ooRYE8uKK3MPMUpwMCuJ8Po9Y48S4k1JrKxKLcqPLyrNSS0+xCjNwaIkztsX +SlSSCA9sSQ1OzW1ILUIJsvEwSnVwFhUvLxhveU9y2gLQ8Pqe40bM5LXu8o+9NqzddsUuZWp M/eVblz8djPvE72PR8/XLJ05T/LeNPXDtzX2Nd8xDZv19zZ7e5gu2wOGn1c23s291lr86OEs c9fu6YUKmozV69+/yXHapXsj6a+G/pYanuVXTvHxMKU/9xTkWrk1yu6Kv7/RAqXf2fFKLMUZ iYZazEXFiQDdFGtTVQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUiGOLzXXfjbY4og2WvjC32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLsvJrEVXJOuOPj+PnMD40XxLkYODgkBE4kTv6W6GLk4hAR2 M0r8WLqUpYuRk4NXQFDix+R7YDazQJhE9/r9jBBFW5gkts9uB0sIC0hLdF24ywoyiE1AS+LA GiOIsJXE1JVXmEHCvAI2Ei+uB4KEWQRUJZ782soEEhYRkJeYeSMTJCwhoChxZOYc5gmMPLOQ LJ6FZDGErSXx/VErUJwDyJaXOHheFiKsKfHs3id2CFtb4sm7C6wLGNlWMYoWpeYkVhrpJRZn JuolFhTkpOol5+duYgSFWNAJgR2Msw4ZHGIU4GBU4uFlPM4RJcSaWFZcmXuIUYKDWUmE1+8Z e5QQb0piZVVqUX58UWlOavEhRmkOFiVxXs2oT5FCAumJJanZqakFqUUwWSYOTqkGxjXSjHHK B5ym+F1nfLVsX9tV+eKL7ZkT1xu2eCyJUTgTaPJKdO2U9vteAm7zn7fwmy63iOrbFnRJ1vK9 sDGnvFXzZlObtqcl65v3nfudvrjuyJT7KctYi43Pd3x7275cPnjGbtbU35db3h0weRl/wfFj Xuc08dzmpfNfsUmofDwS9Hma5rc3zkosxRmJhlrMRcWJAN2DvcEtAgAA Archived-At: Subject: [IPsec] Proposed new privacy items to the ipsecme charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:39:34 -0000 --Boundary_(ID_TWNEmuncU1U3y21qPyauKA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello all, Unfortunately I won't be able to attend today's session due to a conflict, however I'd like to suggest the following privacy concerns for the charter: 1) Improving the privacy of servers that obfuscate IKEv2/IPsec using TLS. Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec server on TCP port 443 with TLS. However if a government agent tries to send an SA_INIT over that it will discover that this server runs IKEv2/IPsec, and may blacklist it. 2) Improving the privacy of the initiator's identity in the presence of a man in the middle attacker. Today an attacker with full control of the network can receive the IDi/IDr sent by the initiator in the first AUTH packet. I would like to add making IKEv2 resilient to these attack to the charter. These attacks could be resolved using an HMAC extension to IKE_SA_INIT using a pre-shared key, for example. I had written up a proposed solution here: https://www.ietf.org/mail-archive/web/ipsec/current/msg11575.html Regardless of the solution, I think there is value in adding these items to the charter. Thanks, David Schinazi --Boundary_(ID_TWNEmuncU1U3y21qPyauKA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hello= all,

Unfortunately = I won't be able to attend today's session due to a conflict, however I'd = like to suggest the following privacy concerns for the = charter:

1) = Improving the privacy of servers that obfuscate IKEv2/IPsec using = TLS.
    Today thanks to RFC 8229 it = is possible to run an IKEv2/IPsec server on TCP port 443 with = TLS.
    However if a government agent = tries to send an SA_INIT over that it will discover that this server = runs IKEv2/IPsec, and may blacklist it.

2) Improving the privacy of the = initiator's identity in the presence of a man in the middle = attacker.
    Today an attacker with full = control of the network can receive the IDi/IDr sent by the initiator in = the first AUTH packet.

I would like to add making IKEv2 resilient to these attack to = the charter.
These attacks could be resolved using = an HMAC extension to IKE_SA_INIT using a pre-shared key, for = example.
I had written up a proposed solution = here:
https://www.ietf.org/mail-archive/web/ipsec/current/msg11575.ht= ml

Regardless of the solution, I think there is value in adding = these items to the charter.

Thanks,
David = Schinazi
= --Boundary_(ID_TWNEmuncU1U3y21qPyauKA)-- From nobody Sun Nov 12 18:34:51 2017 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 7FA341273E2 for ; Sun, 12 Nov 2017 18:34:42 -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 L4AdROHYtcOn for ; Sun, 12 Nov 2017 18:34:34 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 98A04127136 for ; Sun, 12 Nov 2017 18:34:29 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id o7so11626969pgc.4 for ; Sun, 12 Nov 2017 18:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=aLKBJXLISyFZCdoTZrewouorsYeZREYidCc4kZBXPSQ=; b=L9Pn3pznAU5VP/norpMM7/x2oJ2uiyXN8oeX5LTNxNFxsdtUlE8Hrug2CD9P/1ZcMQ Y7UpwkxsXj3mShzXMkWxgHBCG8Pliq/P4WLtBXkxKuGQxt2WgYvH1UE9DhiuYTB46hH0 TfBVxWLe1ZW7IcB9C9ykAgeTlg3DTipfUt+RWWgJqYl9t1NyihABGKi9f7ONfkq5SJYj 34O4YP6Y3GVEzQMBty3SYrvueK1T+QDHqlOmOgUTqf5plZHDotyAbQvCX6TxZXDIemXH d64BJ+GReaO7VhQWfQr7Lie95hsN0BKXRUWHQkOVHNJVtFOFwVPFvinvkm4Q9Lei24UI +/Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=aLKBJXLISyFZCdoTZrewouorsYeZREYidCc4kZBXPSQ=; b=kg8gnS4P6Yzh8H68D2UnujErsVPBkL/5ZgrShCLxjcqrlZwXbMrshaNCgc9oNkzDzo sRw+bS46a1D24oeIHKvxsM019qwya3GvHbj+LnQoa/0w0lMUGGL4jqfbnhvLsdNsrmRr ViGs/YnqS2Tz02gYv1yB5kuuPxaTC+XBxnZev3cQyXUr4KY9R06B6HIeH+7adjN04Put mamZvLc0eehrNJ0Ja3iPsrg8H9HcBWlmpUYQ60+g8i5pgL5UPGt5v2RbNtEZXJs89jp0 jPzv+ufrSnAGquyV8LsZ2rIG/fqDXUyr/c6nqDtdg+yLvsByXv+lQ6AH9/YBKIy6wxwZ QDtw== X-Gm-Message-State: AJaThX7QiqIrd3v6lO3sPNGwZi5EwpDWP42f5nea5mSJKquKM8Rog5wU OhZLvDpk2SI9I9nKwg9Gej02vdCS X-Google-Smtp-Source: AGs4zMZMDb2cgB1efjF3mQLXFd9MeJF13NeymOcftzJDbpcUcapsYrU9emaZFV3rnrffPEyGYDjKLA== X-Received: by 10.84.242.76 with SMTP id c12mr585399pll.328.1510540469025; Sun, 12 Nov 2017 18:34:29 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:bc7d:cc2b:45ee:e502? ([2001:67c:370:128:bc7d:cc2b:45ee:e502]) by smtp.gmail.com with ESMTPSA id u9sm34315411pfa.40.2017.11.12.18.34.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:34:28 -0800 (PST) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_EBD7A23D-91EB-404A-95D8-1F90098F070B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: Date: Mon, 13 Nov 2017 10:34:40 +0800 To: IPsecME WG X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:34:42 -0000 --Apple-Mail=_EBD7A23D-91EB-404A-95D8-1F90098F070B Content-Type: multipart/alternative; boundary="Apple-Mail=_3D7A6D7B-C185-4696-A3D7-B8FC9FC4F0E1" --Apple-Mail=_3D7A6D7B-C185-4696-A3D7-B8FC9FC4F0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make this work. The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: All responses have the same Message ID as the requests. The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. When a message is fragmented as in RFC 7383, all fragments that are part = of the same message are transmitted (and encrypted) with the same = Message ID. Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: Proposal #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. Proposal #2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| The Fragment Counter is the same as in the RFC 7383 fragment payload, or = zero if we are using the regular encrypted payload. The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. The Fragment Counter differentiates between different part of the same = message. The Next Payload differentiates between sending a message fragmented and = sending it unfragmented. So in summary, I think it=E2=80=99s doable and can be added to the draft = if we have consensus. Yoav --Apple-Mail=_3D7A6D7B-C185-4696-A3D7-B8FC9FC4F0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

So = following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make this work.

The IKE header has a =E2=80=9CMessage = ID=E2=80=9D field that is a counter. It=E2=80=99s tempting to use this = as a counter, same as we use the replay counter in IPsec.  However, = as Tero pointed out on Jabber, each such message ID can be used several = times:
  • All = responses have the same Message ID as the requests.
  • The= Message ID is one sided.  The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator.
  • When a message is fragmented as in RFC = 7383, all fragments that are part of the same message are transmitted = (and encrypted) with the same Message ID.

Re-using the Message ID makes us = re-use the AEAD nonce. Not good.  Fortunately, all the algorithms = that the IIV draft mentions require an 8-octet IV while the Message ID = is 4-octet.  We can use the 32 =E2=80=9Cspare=E2=80=9D bits to = differentiate these messages.  I have two proposals for = constructing the 8-octet IV:

Proposal #1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| 24 zero = bits | Flags (8 bits) | Message ID (32 bits)|

And use IIV only for regular Encrypted = Payload, not for Encrypted Fragment.  The reasoning is that if you = use fragmentation you=E2=80=99ve already solved the message-too-big = issue.

The = Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation.

Proposal #2:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| Next = Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)|

The = Fragment Counter is the same as in the RFC 7383 fragment payload, or = zero if we are using the regular encrypted payload.

The Flags octet includes = the I(nitiator) and R(esponse) bits, which differentiate the cases that = are not related to fragmentation.

The Fragment Counter differentiates = between different part of the same message.

The Next Payload differentiates between = sending a message fragmented and sending it = unfragmented. 


So in summary, I think = it=E2=80=99s doable and can be added to the draft if we have = consensus.

Yoav
 


= --Apple-Mail=_3D7A6D7B-C185-4696-A3D7-B8FC9FC4F0E1-- --Apple-Mail=_EBD7A23D-91EB-404A-95D8-1F90098F070B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloJBMAACgkQuEkLFQpY zJlwAwgAreBZyk8TMbSaQwojA3x0vmqojH0wZaZDp2rgsjUbZDUyVP6YdVOw1fuK KR8WOCTfxCSZpcZcUSkmNPshF97w3x8SBG4EWFVHH8DuPwmsY7fKaQ+VH06Sfig/ gWfj/geQp2jW72DwExPkxn+BjVVZDH7UkMTxyuVX/evnahwUzniZo/asC1SvbHrj 0+9TNArJZUZ9ydVg+eL/5JuyumIuSzSWN/u9bSxi8mAzZztIfWMv/jwlyOaM5U8t fqfoNOJo1D8VBDnCaUdL3Mnqr/A0z7FIMlbNe+txHPSuyskRivaglFJm6CqM25O/ cw8hUtIiMbyI8MuGbBCI5fDtDSpnIg== =tJ/s -----END PGP SIGNATURE----- --Apple-Mail=_EBD7A23D-91EB-404A-95D8-1F90098F070B-- From nobody Sun Nov 12 18:51:30 2017 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 8D7541286B2 for ; Sun, 12 Nov 2017 18:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_R0vzahaKr3 for ; Sun, 12 Nov 2017 18:51:23 -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 75F38124B17 for ; Sun, 12 Nov 2017 18:51:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B1B9320008; Sun, 12 Nov 2017 21:52:51 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9071181F0B; Sun, 12 Nov 2017 21:51:18 -0500 (EST) From: Michael Richardson To: Yoav Nir cc: IPsecME WG In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:51:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Proposal #1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| > And use IIV only for regular Encrypted Payload, not for Encrypted > Fragment. The reasoning is that if you use fragmentation you=E2=80=99= ve > already solved the message-too-big issue. > The Flags octet includes the I(nitiator) and R(esponse) bits, which > differentiate the cases that are not related to fragmentation. > Proposal #2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 > bits)| > The Fragment Counter is the same as in the RFC 7383 fragment payload, > or zero if we are using the regular encrypted payload. I think that #2 does a better job. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloJCKYACgkQgItw+93Q 3WWiigf/Vux233DdQlfekr417xjsaMKxRtZgXfOSsrrbEPzePOpk3eUw2fh7cGqw AFEbHr9LsprMiVgBfCzC05gH+zSC/rZQnUpBYSR//jev2YvYTGrKPdPFQ3zeOTDg YpVzz64TPNhj2+DU9nLwt/eCeSn/PVkNbaMr/xm0S2Pi3TmHF9StIPCVeq950tJZ wykzOHxnY73DxRYXMJB0MV0TbwPQf8ZTeoIw/n0heuEhtR0GGokHmWiSmcsxInF+ ZRlYakHsxRlA6BqjlqNpWFhSmokKJleTAd4ltvVB9x5G23KgarPHbA2ZW1Q24OEs RWy2Kg5scf10gFSQM3bDBf3/O+KcEQ== =GQpT -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 12 18:56:16 2017 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 9DC4B127B73; Sun, 12 Nov 2017 18:56:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, ipsecme-chairs@ietf.org, kivinen@iki.fi, Tero Kivinen , ipsec@ietf.org, draft-ietf-ipsecme-eddsa@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151054176759.21338.6509634552752124708.idtracker@ietfa.amsl.com> Date: Sun, 12 Nov 2017 18:56:07 -0800 Archived-At: Subject: [IPsec] Last Call: (Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:56:08 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (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 2017-11-26. 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 This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Nov 12 19:16:25 2017 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 D219712896F for ; Sun, 12 Nov 2017 19:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 l7EQp8DjLJGm for ; Sun, 12 Nov 2017 19:16:17 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (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 BD17712700F for ; Sun, 12 Nov 2017 19:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510542974; 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=eGwD6J4LVfwtgUuhGrdeYlmugaFEc63QDIaPqawymuU=; b=0z9WJ3eA7r+BXrECQzbnEmnTVwCdvDk19XOi1Gf913CbY+8HI9AAs9iTZGRR7Bby 4EW0LHO7ANgic0kZHbXwsR3Dnhh+IbOnozgTVm9lyzEC5adRaxt1e7fmInmllAtu ZSLhd2ZjDeArQ/j1um0Slt/QScAQ1kd5SbMFRaM/0V/UmWwhxIhcXIDN0H6BIfbq kRqUuzF6tekPAIPROhzAUUE2xdl4N7GsC19MpOlF1mgMq3E9lSH8Tm9VuHHyFS0C qf5EILzSkvigXh4GhLu7wg3gQPBDjfCFW4uJZM+51xqAtCz36vOclAKJKMxIwour CTZy5fYmUPofN07tcr8xNg==; Received: from relay3.asia.apple.com ( [17.82.200.17]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 29.DB.05091.E7E090A5; Mon, 13 Nov 2017 11:16:14 +0800 (MYT) X-AuditID: 1152fe06-a100e9c0000013e3-52-5a090e7e4bc9 Received: from sng-mailphp-s01.asia.apple.com ( [17.84.76.247]) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id E8.FD.26676.D7E090A5; Mon, 13 Nov 2017 11:16:14 +0800 (MYT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.235.147.133] by sng-mailphp-s01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZC0057M6F1W270@sng-mailphp-s01.asia.apple.com>; Mon, 13 Nov 2017 11:16:13 +0800 (SGT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <15077.1510541478@obiwan.sandelman.ca> Date: Mon, 13 Nov 2017 11:16:12 +0800 Cc: Yoav Nir , IPsecME WG Content-transfer-encoding: quoted-printable Message-id: <008EF7E2-2987-4C35-B57C-A13AA271E36A@apple.com> References: <15077.1510541478@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUiGHRCULeOjzPK4Fcrp8X+LS/YLHoO9bNb LD32gcmB2WPnrLvsHkuW/GTyaJmzhzmAOYrLJiU1J7MstUjfLoEr4/iX0oKb3BVvDyxnbmDc wtnFyMkhIWAisWtyN0sXIxeHkMBKJokn/bcYYRI3/l9jh0jsZpSYvWYCM0iCV0BQ4sfke0Ad HBzMAuoSU6bkQtS0MEm82DGDFaRGWEBaouvCXSjbWuLPzQdMIPVsAloSB9YYgYQ5BYwlumbf YgOxWQRUJfZO/MoCYjML2Evc2naNFcLWlnjy7gIrxFobiXPTpjGB2EICqRIT+5eB9YoI6Eks P/IM6mZFiSMz5zCD3CMhMIdNovfXL+YJjMKzkJw9C+HsWUhWLGBkXsUonpuYmaObmWekl1ic maiXWFCQk6qXnJ+7iREc9P/YdjAueG14iFGAg1GJh3cpN2eUEGtiWXFl7iFGCQ5mJRHeI/c5 ooR4UxIrq1KL8uOLSnNSiw8xSnOwKInz9kZ+ihQSSE8sSc1OTS1ILYLJMnFwSjUwumuXix4+ zjxd+kVICuclJVWntxohggqF3qGOhzdIMzrmOpTd4dkdl7Jggp15UtzyY18X75xWq6u3QzWL jTtl+v5fvedcD235foH91pJU9+XKjLon5b/9urNo2vSZNtOFUvWkvjF1fLl+OMTLSmLt1l9O LWc+pj/auCfwBD//r++9C9Mn/titocRSnJFoqMVcVJwIAHucBoZ2AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUiGOLzXbeOjzPK4NM9Vov9W16wWfQc6me3 WHrsA5MDs8fOWXfZPZYs+cnk0TJnD3MAcxSXTUpqTmZZapG+XQJXxvEvpQU3uSveHljO3MC4 hbOLkZNDQsBE4sb/a+xdjFwcQgK7GSVmr5nADJLgFRCU+DH5HksXIwcHs4C6xJQpuRA1LUwS L3bMYAWpERaQlui6cBfKtpb4c/MBE0g9m4CWxIE1RiBhTgFjia7Zt9hAbBYBVYm9E7+ygNjM AvYSt7ZdY4WwtSWevLvACrHWRuLctGlMILaQQKrExP5lYL0iAnoSy488Y4S4WVHiyMw5zBMY BWYhuXQWwqWzkExdwMi8ilG0KDUnsdJYL7E4M1EvsaAgJ1UvOT93EyMoSINOCO5g/DDV8BCj AAejEg+vMTdnlBBrYllxZe4hRgkOZiUR3iP3OaKEeFMSK6tSi/Lji0pzUosPMUpzsCiJ82pG fYoUEkhPLEnNTk0tSC2CyTJxcEo1MK6enqKgeNLtqleGxwun1KZpuuzPt3yxfNM1R+emad6i luOSoRscw9Qifz/ZnFD74rTYyyfvdF5Gbd7MqRba3P9dp3CmsKR092zdR7XLIgzC9Xb411hv LV5x4s/6zRKpGxXaLapWybw8KWAszdPatvn/mtlfFH/qsZ7/c1LOun/eCofrWYvvBiixFGck GmoxFxUnAgCGi1uBTgIAAA== Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:16:24 -0000 I suspect that there was a typo and Yoav meant to include the flags for = proposal 2: | Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) | = Message ID (32 bits) | In that case I do prefer option 2 as it doesn't add much complexity and = allows fragmentation. David > On Nov 13, 2017, at 10:51, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> Proposal #1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >=20 >> And use IIV only for regular Encrypted Payload, not for Encrypted >> Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve= >> already solved the message-too-big issue. >=20 >> The Flags octet includes the I(nitiator) and R(esponse) bits, which >> differentiate the cases that are not related to fragmentation. >=20 >> Proposal #2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 >> bits)| >=20 >> The Fragment Counter is the same as in the RFC 7383 fragment payload, >> or zero if we are using the regular encrypted payload. >=20 > I think that #2 does a better job. >=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 Sun Nov 12 19:30:30 2017 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 74FA212700F for ; Sun, 12 Nov 2017 19:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmfXvy7xHa0R for ; Sun, 12 Nov 2017 19:30:28 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 70778126DCA for ; Sun, 12 Nov 2017 19:30:27 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id g35so2439870lfi.13 for ; Sun, 12 Nov 2017 19:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=S1pMkoAJCgL/pyGqLxeBkS42etWY2Z1ERdYxysEDdb8=; b=mUlP+Ljk1JFmRVvUvU1sU2A3KfHLKoCM7TjIdwuJojKmfgiXtxpJXJxsqC2uu6kOpw 9BG495TrBkjRhgLcmuoi03OXmsmeiMk090Ugn6uC5lFHjPo+NMVU7wmVw84YQH6ugmi4 HZnpkIyuSMfhc0bTzUnfvgcolhZuP3AF3Yjz3ZgDAGzlmhqpl7uIOe3QpiruiCiL7Lfg KwbxM+5Zg6IB6bTW5dE82c3UE4+F5IsnJ53iVagXi+sR8Y6gRkSnzvEw5wzAdKgOjKnf Bs0XnHVqJ0oP0YjpjpCgX1NEc5HBl71fasbP+WGkfx5ax4zbMLSPWnBrk95I39oFhqyu +MFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=S1pMkoAJCgL/pyGqLxeBkS42etWY2Z1ERdYxysEDdb8=; b=ptaSWYsEzjKcsglhS8/QJ2/pOpVh6e57oyGT988cMTEfCEqc1K48Sj5eA8tLYIt+uE /HeaiqAQALK6t+p1n582hm26aPYm/SdUz7Tzgcw1oNb8MTavOTppSOnC0o79fYPtGi5F vbb7m/H6G1Ef7H4m+Ggre9yNX1ljIvW3vQdjI+jqrpG2iHfjxUelrbkIS0Ky/7CuVOmd iym8UTyZ19wat5aHMlJTfzRKDmjvE22OiWO6Fcp7TYhI8O1VqaWiCMS8sWHCdR72Gihu Bhlb7Rz1G7y1Pj8+sJ+Yo6LO89NXIxhDCdU6GPtYJ6nYhGKQtZxubWz4Ph5w1rXQ25H6 z//g== X-Gm-Message-State: AJaThX5Mmcul2pDI5/kc2WoxzRFUiPmZO3Tx0SWQ6uC/eyPgWOZkNa0f yE1d/FdW22Az2hTgWLNpSTCoUw== X-Google-Smtp-Source: AGs4zMbZ1vIepauJqHvFzmikcO8PCgD5fXUcD+ca0MbDiJsvP4zsxMVZ8YLomo1V1I4m/1Xenh+dlg== X-Received: by 10.25.40.74 with SMTP id o71mr2882303lfo.223.1510543825486; Sun, 12 Nov 2017 19:30:25 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q135sm2724064lfe.71.2017.11.12.19.30.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 12 Nov 2017 19:30:24 -0800 (PST) From: "Valery Smyslov" To: "'Yoav Nir'" , "'IPsecME WG'" References: In-Reply-To: Date: Mon, 13 Nov 2017 06:30:20 +0300 Message-ID: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010C_01D35C48.E18F1E10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwoU1jUGTnHsA3NnK29zh3WK6Q8qLXGVgQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:30:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010C_01D35C48.E18F1E10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 there is also an RFC6311, which allows messages with the MessageID (0) to be sent over the same IKE SA in case of cluster failover. If the IKE SA is a result of a rekey (not IKE_SA_INIT), then its first encrypted message will have MessageID of 0, so if failover happens later, the MessageID of zero will repeat, breaking the security. You should consider this case also. =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, November 13, 2017 5:35 AM To: IPsecME WG Subject: [IPsec] Proposal for using Implicit IV for IKE =20 Hi. =20 So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make this work. =20 The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: * All responses have the same Message ID as the requests. * The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. * When a message is fragmented as in RFC 7383, all fragments that are = part of the same message are transmitted (and encrypted) with the same = Message ID. =20 Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: =20 Proposal #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| =20 And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. =20 The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. =20 Proposal #2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| =20 The Fragment Counter is the same as in the RFC 7383 fragment payload, or = zero if we are using the regular encrypted payload. =20 The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. =20 The Fragment Counter differentiates between different part of the same = message. =20 The Next Payload differentiates between sending a message fragmented and = sending it unfragmented.=20 =20 =20 So in summary, I think it=E2=80=99s doable and can be added to the draft = if we have consensus. =20 Yoav =20 =20 =20 ------=_NextPart_000_010C_01D35C48.E18F1E10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

there is also an RFC6311, which allows = messages

with the MessageID (0) to be sent over the same IKE = SA

in case of cluster failover. If the IKE SA is a result of a = rekey

(not IKE_SA_INIT), then its first encrypted = message

will have MessageID of 0, so if failover happens = later,

the MessageID of zero will repeat, breaking the = security.

You should consider this case also.

 

Regards,

Valery.

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent: Monday, November 13, 2017 5:35 AM
To: = IPsecME WG
Subject: [IPsec] Proposal for using Implicit IV for = IKE

 

Hi.

 

So following Daniel=E2=80=99s message in the room, = here=E2=80=99s how I think we can make this = work.

 

The IKE header has a =E2=80=9CMessage ID=E2=80=9D = field that is a counter. It=E2=80=99s tempting to use this as a counter, = same as we use the replay counter in IPsec.  However, as Tero = pointed out on Jabber, each such message ID can be used several = times:

  • All responses have the same Message ID as the = requests.
  • The Message ID is one sided.  The n-th request from = the original Responder has the same Message ID as the n-th request from = the original Initiator.
  • When a message is fragmented as in RFC 7383, all fragments = that are part of the same message are transmitted (and encrypted) with = the same Message ID.

 

Re-using the Message ID makes us re-use the AEAD = nonce. Not good.  Fortunately, all the algorithms that the IIV = draft mentions require an 8-octet IV while the Message ID is 4-octet. =  We can use the 32 =E2=80=9Cspare=E2=80=9D bits to differentiate = these messages.  I have two proposals for constructing the 8-octet = IV:

 

Proposal #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| 24 zero bits | Flags (8 bits) | Message ID (32 = bits)|

 

And use IIV only for regular Encrypted Payload, not = for Encrypted Fragment.  The reasoning is that if you use = fragmentation you=E2=80=99ve already solved the message-too-big = issue.

 

The Flags octet includes the I(nitiator) and = R(esponse) bits, which differentiate the cases that are not related to = fragmentation.

 

Proposal #2:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| Next Payload (8 bits) | Fragment Counter (16 = bits) | Message ID (32 bits)|

 

The Fragment Counter is the same as in the RFC 7383 = fragment payload, or zero if we are using the regular encrypted = payload.

 

The Flags octet includes the I(nitiator) and = R(esponse) bits, which differentiate the cases that are not related to = fragmentation.

 

The Fragment Counter differentiates between different = part of the same message.

 

The Next Payload differentiates between sending a = message fragmented and sending it = unfragmented. 

 

 

So in summary, I think it=E2=80=99s doable and can be = added to the draft if we have consensus.

 

Yoav

 

 

 

------=_NextPart_000_010C_01D35C48.E18F1E10-- From nobody Sun Nov 12 19:35:30 2017 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 5A86B128B44; Sun, 12 Nov 2017 19:35:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, ipsecme-chairs@ietf.org, kivinen@iki.fi, Tero Kivinen , ipsec@ietf.org, draft-ietf-ipsecme-eddsa@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151054412436.21330.12065412828502403093.idtracker@ietfa.amsl.com> Date: Sun, 12 Nov 2017 19:35:24 -0800 Archived-At: Subject: [IPsec] Last Call: (Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:35:24 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (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 2017-12-04. 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 This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Nov 12 19:54:58 2017 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 EFA2C1276AF for ; Sun, 12 Nov 2017 19:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvK_Ora_g925 for ; Sun, 12 Nov 2017 19:54:55 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 23EFB126DCA for ; Sun, 12 Nov 2017 19:54:55 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id i15so634969pfa.3 for ; Sun, 12 Nov 2017 19:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cxlChb6b23ZrD4rh26n5KWzRlZJyKEsTtWZhQ8MhqOI=; b=s0PAFQT4bth8aWDWTYHDjRvzOaACz0r1W1YykRBgWg3gT1RxLnviNeNPTO1Hk9bbTe 13d+Qhb6roi8IkShsWw/b6glGkMXVChNiXlZV9GJxBfJMX68tlayNCsdoKeFxTupREGT 9xEIwkppoP3EOX693ia/fBn4HxD/3x4yyET0x8p6Yw4OVqvZQvJPswVv3zK7G2LV+hKZ t7zH0u6mPKkLwiabKLbPNmwOu5NRpC0mbrfMEP4Qin07TQLlZVkqv5p3nrS25r+avU9J Kkyv5rwinX8VCmz9DtGc4Pt+gIqAj1DYaTO9hvuDsOLT+bExFXpYXYyec8c7zUtbwdXv tKFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cxlChb6b23ZrD4rh26n5KWzRlZJyKEsTtWZhQ8MhqOI=; b=lm6lNgKmbkgVe0tfbizu/hqwljZf9P/j2btLrO5sMaOtAWBiz75ltGEC5qxcMO2E1D jAGXR7JsI7hRjPozt/qOH1SVodcx+WiKSSBLVXH6787MhbECHp2tea1CzLe5K+NWKuWQ DenIJUMP+5UiXui4jGY1vQhOwG9hjr+LG/Pofh7u3CaxkFa9Q666ceczquYhcbX3+jio peCHJbygI9ste8EorQKlOPGFcMlA0nm83focaP1ALzrG3lGPOaCef2YPnQm/0yqmf1Qr i9Vj+Xu1aeTXzk9uL0ujKU+/kzzhHL+gODjNj5XoT5+rn+hFEUUsj9WyFWcPGMMIf7Bg tU1Q== X-Gm-Message-State: AJaThX6/zhV/LowbW8w8d2o6VoRt131m6JkugHzE9KwnlH98wOkePenr 4j+fFBoTmMj7tOVd3h/PI7A= X-Google-Smtp-Source: AGs4zMYXTMwUpEy2s5BO1+SKlT7HeMiAp6YeK/xHO33qjqLTCXpivEha6Qa1+gIOzft2QAp1rNwASg== X-Received: by 10.101.82.130 with SMTP id y2mr7381252pgp.65.1510545294751; Sun, 12 Nov 2017 19:54:54 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:a40a:d302:10d8:a1b3? ([2001:67c:370:128:a40a:d302:10d8:a1b3]) by smtp.gmail.com with ESMTPSA id q13sm24903276pgt.73.2017.11.12.19.54.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 19:54:54 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_110BB692-E08A-45AA-A033-A6D99A1D1D1F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 13 Nov 2017 11:55:22 +0800 In-Reply-To: <008EF7E2-2987-4C35-B57C-A13AA271E36A@apple.com> Cc: Michael Richardson , IPsecME WG To: David Schinazi References: <15077.1510541478@obiwan.sandelman.ca> <008EF7E2-2987-4C35-B57C-A13AA271E36A@apple.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:54:57 -0000 --Apple-Mail=_110BB692-E08A-45AA-A033-A6D99A1D1D1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right. Thanks, David. > On 13 Nov 2017, at 11:16, David Schinazi wrote: >=20 > I suspect that there was a typo and Yoav meant to include the flags = for proposal 2: >=20 > | Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) = | Message ID (32 bits) | >=20 > In that case I do prefer option 2 as it doesn't add much complexity = and allows fragmentation. >=20 > David >=20 >=20 >> On Nov 13, 2017, at 10:51, Michael Richardson = wrote: >>=20 >>=20 >> Yoav Nir wrote: >>> Proposal #1: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >>=20 >>> And use IIV only for regular Encrypted Payload, not for Encrypted >>> Fragment. The reasoning is that if you use fragmentation you=E2=80=99v= e >>> already solved the message-too-big issue. >>=20 >>> The Flags octet includes the I(nitiator) and R(esponse) bits, which >>> differentiate the cases that are not related to fragmentation. >>=20 >>> Proposal #2: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID = (32 >>> bits)| >>=20 >>> The Fragment Counter is the same as in the RFC 7383 fragment = payload, >>> or zero if we are using the regular encrypted payload. >>=20 >> I think that #2 does a better job. >>=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 >=20 --Apple-Mail=_110BB692-E08A-45AA-A033-A6D99A1D1D1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloJF6oACgkQuEkLFQpY zJlj2wgAgVjME9H9b83tzPYCgu2Q4gKMvERK76eN/zLgP/Xb4SPcZ+P3dPnbUoOR M4GgemWgGbulNFFm8WjPGXdwn0nreLiFGHS9iI1BfRreHdp8X48b2tjCVifTjr3X DYC2V9Hp0Ef9nDPwmYdbz77sqWIqCmLRJyysUuV7jqPk8BaSWBmoRD7vr9J4ttnG XlDJ49Bnhc8oEkjpoe8OXDgriRDHX8oBh7VFCARGovXJpVq2WCzXkOER8mVpE6Vk mFDzaKcssAiHiPacVXnxT2NNegsh0w+gMWOSKMULkx2fwO+FUEcUKE4tq5mfT+5N YIfMAbKduN4+Wd8Kw4mI2iB7/rNKbQ== =eonU -----END PGP SIGNATURE----- --Apple-Mail=_110BB692-E08A-45AA-A033-A6D99A1D1D1F-- From nobody Mon Nov 13 00:21:34 2017 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 3335D126B6E for ; Mon, 13 Nov 2017 00:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK7_RDVVmmzU for ; Mon, 13 Nov 2017 00:21:31 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D7C129457 for ; Mon, 13 Nov 2017 00:21:30 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 689321209A0 for ; Mon, 13 Nov 2017 09:21:29 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 50D4A160080 for ; Mon, 13 Nov 2017 09:21:29 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 09:21:29 +0100 From: To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-boucadair-ipsecme-ipv6-ipv4-codes-01.txt Thread-Index: AQHTXFgo4qJStlJuFU+i31kYlMmrKKMR9+PA Date: Mon, 13 Nov 2017 08:21:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0779B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151056118107.21398.8821483468460252511.idtracker@ietfa.amsl.com> In-Reply-To: <151056118107.21398.8821483468460252511.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [IPsec] TR: New Version Notification for draft-boucadair-ipsecme-ipv6-ipv4-codes-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:21:33 -0000 RGVhciBhbGwsIA0KDQpUaGlzIHVwZGF0ZWQgdmVyc2lvbiBjbGFyaWZpZXMgdGhlIHBvaW50IHJh aXNlZCBieSBQYXVsLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBsdW5kaSAxMyBub3ZlbWJyZSAyMDE3IDA5 OjIwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gT2JqZXTCoDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ib3VjYWRhaXItaXBzZWNtZS1pcHY2LWlwdjQt DQo+IGNvZGVzLTAxLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1i b3VjYWRhaXItaXBzZWNtZS1pcHY2LWlwdjQtY29kZXMtMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUN Cj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWJvdWNhZGFpci1pcHNlY21l LWlwdjYtaXB2NC1jb2Rlcw0KPiBSZXZpc2lvbjoJMDENCj4gVGl0bGU6CQlJS0V2MiBOb3RpZmlj YXRpb24gQ29kZXMgZm9yIElQdjQvSVB2NiBDb2V4aXN0ZW5jZQ0KPiBEb2N1bWVudCBkYXRlOgky MDE3LTExLTEyDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNQ0K PiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWJvdWNhZGFpci0NCj4gaXBzZWNtZS1pcHY2LWlwdjQtY29kZXMtMDEudHh0DQo+IFN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRh aXItaXBzZWNtZS0NCj4gaXB2Ni1pcHY0LWNvZGVzLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1pcHNlY21lLWlwdjYtDQo+IGlw djQtY29kZXMtMDENCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtYm91Y2FkYWlyLQ0KPiBpcHNlY21lLWlwdjYtaXB2NC1jb2Rlcy0w MQ0KPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWJvdWNhZGFpci1pcHNlY21lLQ0KPiBpcHY2LWlwdjQtY29kZXMtMDENCj4gDQo+IEFic3Ry YWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBuZXcgSUtFdjIgbm90aWZpY2F0aW9u IGNvZGVzIHRvIGJldHRlciBtYW5hZ2UNCj4gICAgSVB2NCBhbmQgSVB2NiBjby1leGlzdGVuY2Uu DQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Nov 13 00:46:49 2017 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 08E82128BA2 for ; Mon, 13 Nov 2017 00:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsdwzQRZnVfD for ; Mon, 13 Nov 2017 00:46:46 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E529126B6E for ; Mon, 13 Nov 2017 00:46:46 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id F32F116055A for ; Mon, 13 Nov 2017 09:46:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id D7803180062 for ; Mon, 13 Nov 2017 09:46:44 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 09:46:44 +0100 From: To: "ipsec@ietf.org" Thread-Topic: IPv4 & IPv6 address failure errors: Proposed Charter Text Thread-Index: AdNcW+140wRbVcwqS0SPwiahqqHllw== Date: Mon, 13 Nov 2017 08:46:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A077A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A077A39OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] IPv4 & IPv6 address failure errors: Proposed Charter Text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:46:48 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A077A39OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, all, Please find below a text proposal for including this NEW item in the charte= r: RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A077A39OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear chairs, all,

 

Please find below a text proposal for inclu= ding this NEW item in the charter:

 

   RFC7296 defines a generic notificati=
on code that is related to a
   failure to handle an internal addres=
s failure.  That code does not
   explicitly allow an initiator to det=
ermine why a given address family
   is not assigned, nor whether it shou=
ld try using another address
   family.  The Working Group will=
 specify a set of more specific
   notification codes that will provide=
 sufficient information to the
   IKEv2 initiator about the encountere=
d failure.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A077A39OPEXCLILMA3corp_-- From nobody Mon Nov 13 02:05:12 2017 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 605521293D9 for ; Mon, 13 Nov 2017 02:05: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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT_lL83YbldN for ; Mon, 13 Nov 2017 02:05:10 -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 D1059128B38 for ; Mon, 13 Nov 2017 02:05:09 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yb5q66ddyz39h; Mon, 13 Nov 2017 11:05:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510567506; bh=bWR3ejouSXxaWjY07PUnij5CHqGuAvFgd3fSwDbCE2k=; h=Date:From:To:cc:Subject; b=peLSx9yx0tTnz3YVEaQYuQz8pwDmNOE67ewghdahry0sic218Cof2RDraDirTB9gA H875rX8ewcUonr982HDjTbY1C7Nqg1qnW1LP+0H4aqJjlLwqZMKTLel9WUjqxycb8l zHIqdFrU3a1ir0QM/MwKOoPNqA25MmFLsZRsh6gs= 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 BDaSjUOm37jW; Mon, 13 Nov 2017 11:05:05 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Nov 2017 11:05:05 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DC23C62D29; Mon, 13 Nov 2017 05:05:04 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DC23C62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D533A40D35AF; Mon, 13 Nov 2017 05:05:04 -0500 (EST) Date: Mon, 13 Nov 2017 05:05:04 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Vukasin Karadzic Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] qr-ikev2 interop test X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:05:11 -0000 Some people were interested in interop for the ppk draft. We have implemented draft-fluhrer-qr-ikev2, and are going to implement draft-ietf-ipsecme-qr-ikev2 in the near future. To test, feel free to use the below server and let us know if you had positive or negative results: server: vpn-ppk.nohats.ca server ID: GroupPPK1 PSK: SecretPSK PPK ID: PPKID1 static PPK: NotQuantumSafe It is configured as an access VPN, so you will get an IP addres via CP to 0.0.0.0/0. We are still working on cleaning up the code for dynamic PPK (OTP) support. Paul & Vukasin From nobody Mon Nov 13 08:01:38 2017 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 E3ACD129449 for ; Mon, 13 Nov 2017 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yq7MaP0rJdOx for ; Mon, 13 Nov 2017 08:01:29 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 BC162127843 for ; Mon, 13 Nov 2017 08:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510588886; 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=6wTUMFc2PqjKzaw0DaCmSyTas5rLBAPKlW7oOVWvEjY=; b=z4jVBRNvYbSLBh0nwo5bZgVBq7lDKhUUB7xUp6IKVsSwEoM0NQ5eIAyHkmbVc58N 1+OJIH5ouX5q+CBo/k2I6VuuUInWSoMwJ1FJDcDs5OUC09VmWfUoYki4viWadhco TF9bRLUxI2zM/Sd3BfzR3gqo+qlvlwB+RZc3VyLV1jJtKpoAh7zuyplTocK748hX +qqFhW6etEwQT+YEjExrmpJx6m/bYjvgCUM3annocIPUHTwLp7IVu7VFWUhEW3ee mHXeilCx3X8qHDcir9hbImHgD7k5wjt9vB08XwgYWxm+zr3OWlKEj6tpC6/VgzYA zuUNRFbRs5R9VLsMyVXhig==; Received: from relay1.asia.apple.com ( [17.82.200.18]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 5C.8D.07591.6D1C90A5; Tue, 14 Nov 2017 00:01:26 +0800 (MYT) X-AuditID: 1152fe11-8cbff70000001da7-04-5a09c1d6de73 Received: from sng-mmpp-sz02.asia.apple.com ( [17.84.80.27]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 69.3B.23340.6D1C90A5; Tue, 14 Nov 2017 00:01:26 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.235.146.138] by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZD00JA85UEUI50@sng-mmpp-sz02.asia.apple.com>; Tue, 14 Nov 2017 00:01:26 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Tue, 14 Nov 2017 00:01:25 +0800 Cc: "ipsec@ietf.org WG" , Vukasin Karadzic Message-id: References: To: Paul Wouters X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUiGHRCSPfaQc4og62Nahb7t7xgs3h/6xKT Rfe/Q+wOzB47Z91l91iy5CeTx/d5TAHMUVw2Kak5mWWpRfp2CVwZX9ZfYi94yVHR8uolawPj f7YuRk4OCQETifMdp1i7GLk4hARWMklsun6NFSYxa2EvO0RiB6PE1fZ9TCAJXgFBiR+T77F0 MXJwMAvISxw8LwsSZhbQkvj+qJUFor6BSWL/yufMIDXCAhISm/ckgtQIA9XsXHaMHcRmE1CR OP5tAzOIzSngKDH1+wMwm0VAVeJs5x42iJmREm+/7GaFWGsj0fT+EDvISCEBB4nXCwRBwiIC ihKTzjxigThZUeLhpi6wXyQE5rBJTH22h30Co/AsJFfPQrh6FpKrFzAyr2IUz03MzNHNzDPU SyzOTNRLLCjISdVLzs/dxAgO+X+COxinLjQ8xCjAwajEw7tjE2eUEGtiWXFl7iFGCQ5mJRHe T+uAQrwpiZVVqUX58UWlOanFhxilOViUxHn7Ij9FCgmkJ5akZqemFqQWwWSZODilGhiPbqyY vZTl6rryMBbr/Kb3AQeWtG1vfndEqXXL68ilzy8tDwtoOiETKK3351jLhIh1t2x+TtiQrCqS E1st5/ShKmlhq+36tJTby+tePv8fyBHDcjxSsf3v0ojo/M/KmmkTKji/ath9SEu8OGWGlrCz V1lIscmbr17rj1SYh3HaLd6ZfWtfv5ASS3FGoqEWc1FxIgBkftKWdQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUiGBIgrXvtIGeUwezLShb7t7xgs3h/6xKT Rfe/Q+wOzB47Z91l91iy5CeTx/d5TAHMUVw2Kak5mWWpRfp2CVwZX9ZfYi94yVHR8uolawPj f7YuRk4OCQETiVkLe9m7GLk4hAR2MEpcbd/HBJLgFRCU+DH5HksXIwcHs4C8xMHzsiBhZgEt ie+PWlkg6huYJPavfM4MUiMsICGxeU8iSI0wUM3OZcfYQWw2ARWJ4982MIPYnAKOElO/PwCz WQRUJc527mGDmBkp8fbLblaItTYSTe8PsYOMFBJwkHi9QBAkLCKgKDHpzCMWiJMVJR5u6mKd wCgwC8mhsxAOnYXk0AWMzKsYRYtScxIrDfUSizMT9RILCnJS9ZLzczcxgkI06ITQDsaP+w0O MQpwMCrx8KZs5owSYk0sK67MPcQowcGsJML7aR1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9m 1KdIIYH0xJLU7NTUgtQimCwTB6dUA+MR2ws90zXK8s1NsoTvanzKuHYjbMODuEkvjrYHz9I+ b313RaeHY0Lhaf33Bl7RLLHVx06rL9OoCJ834SZLgJ7xKrF/CaYhp8xvP33w7NDtV5vk/ucc LF5989x3qe+X2ntOTxc2Urixn/Xe/muvG06kR15J356azRl4zMXnaf1SpZDFCxYfEFmvxFKc kWioxVxUnAgA+0ERdU0CAAA= Archived-At: Subject: Re: [IPsec] qr-ikev2 interop test X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:01:35 -0000 Thanks for setting this up! I'll try an interop soon (this week I hope). However, some questions first: what values are you using for these? - PPK_SUPPORT notify code - PPK_IDENTITY notify code Also, I presume you're using PPK_ID_FIXED, not PPK_ID_OPAQUE? Thanks, Tommy > On Nov 13, 2017, at 6:05 PM, Paul Wouters wrote: > > > Some people were interested in interop for the ppk draft. > > We have implemented draft-fluhrer-qr-ikev2, and are going to > implement draft-ietf-ipsecme-qr-ikev2 in the near future. > > To test, feel free to use the below server and let us know if you > had positive or negative results: > > server: vpn-ppk.nohats.ca > server ID: GroupPPK1 > PSK: SecretPSK > PPK ID: PPKID1 > static PPK: NotQuantumSafe > > It is configured as an access VPN, so you will get an IP addres via CP to > 0.0.0.0/0. > > We are still working on cleaning up the code for dynamic PPK (OTP) support. > > Paul & Vukasin > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 13 08:16:56 2017 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 6B56D1200F1 for ; Mon, 13 Nov 2017 08:16:51 -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 IQriaHTCRwbD for ; Mon, 13 Nov 2017 08:16:50 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 E2A9A129B06 for ; Mon, 13 Nov 2017 08:16:49 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id k61so14899147wrc.4 for ; Mon, 13 Nov 2017 08:16:49 -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=v2J4dgp2TTCqaQuhsjBlQcu0KZc+M1rLir0PRJD8R/g=; b=hR0UX1eHmmYsc/fSu/Jxql6RoA5os4MNhKp41HZM1Hc+qjZOMvkFjRTd080DjRu17J +yH3hjhfuIdUkdxRXiT83CLoIoj9g6zjTNshQD/UmhKl24VyhbO4EJCrjgsAAzmhoPkR q80W6651tkl4Ck2zAe9i/wp+kx6ICSdL5Uct6iQ4f1Yv28WrieJPxdCO8OziXxB9b60a KdGTq594+Anlh8PPmCMOYZjIM2h3D6UwQpapyXT40yTrgNcJD89PPdYLqGOOzaB4/ExL 6PbthsaWapDE4WYvgqEjHiaXZ+nUeY79F0gyr+5qi7cStImegAEhzm3V26FEgpLIqDPS 8O5Q== 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=v2J4dgp2TTCqaQuhsjBlQcu0KZc+M1rLir0PRJD8R/g=; b=FuZD5ZYserQ+Ji591GVgGuHUmOl/ucm7bk6AMW++voyTspEuCAlbHB310nwE7oVOsp XJfDRrJGJD08LIjqbIPbsoICGEjst7zftzPJqGsRc8pQdLXjV0+jZv/CGgWe8PA9EcnP k07Ej0EYOtpgj3ZW6k0NfSdA0Otf3PikSj5gWezZpZl+p0YB6QRgHwXT/kfBg4vOUtdp QaPklzhsj32DeycZXKABrMDOssicIBm8/VKEu2bArZnD5pfhDGzU+jHYrVxtyq2vfooM ALaKS8DWay2tJQuJZyiKTJ/J86Ysia0xbPgjWrZDN3+dd4/HG+D45GujmWPp18g3v5qd a4bA== X-Gm-Message-State: AJaThX71bnCFPuo+93Kt9iWsHCdaEuIKzIFcER0g9c1vJY3sUHPcjlvr KF9/WZcAqQGGXOJEQG8dYzOOlPjqvezanIVJDVQ= X-Google-Smtp-Source: AGs4zMbT6/pbjPD6lwMcGTqi3agFo+toCakn+MyEmJjm4yJIH5nkNLWzJ9n3lykPUTaDa2/reiORCevHvadQB7JM+L0= X-Received: by 10.223.136.92 with SMTP id e28mr7438960wre.36.1510589808427; Mon, 13 Nov 2017 08:16:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.105.77 with HTTP; Mon, 13 Nov 2017 08:16:47 -0800 (PST) Received: by 10.28.105.77 with HTTP; Mon, 13 Nov 2017 08:16:47 -0800 (PST) In-Reply-To: References: From: Vukasin Karadzic Date: Mon, 13 Nov 2017 17:16:47 +0100 Message-ID: To: Tommy Pauly Cc: Paul Wouters , ipsec@ietf.org Content-Type: multipart/alternative; boundary="001a114988deeec81a055ddf987f" Archived-At: Subject: Re: [IPsec] qr-ikev2 interop test X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:16:51 -0000 --001a114988deeec81a055ddf987f Content-Type: text/plain; charset="UTF-8" On 13 Nov 2017 5:01 pm, "Tommy Pauly" wrote: Thanks for setting this up! I'll try an interop soon (this week I hope). However, some questions first: what values are you using for these? - PPK_SUPPORT notify code - PPK_IDENTITY notify code The values 40960 and 40961 were picked as private use numbers for PPK_SUPPORT and PPK_IDENTITY Notify messages, respectively Also, I presume you're using PPK_ID_FIXED, not PPK_ID_OPAQUE? Yes! Regards, Vukasin --001a114988deeec81a055ddf987f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 13 Nov 2017 5:01 pm, "Tommy Pauly" <tpauly@apple.com> wrote:
Thanks = for setting this up! I'll try an interop soon (this week I hope).

However, some questions first: what values are you using for these?
- PPK_SUPPORT notify code
- PPK_IDENTITY notify code
=
The values 40960 and 40= 961 were picked as private use numbers for PPK_SUPPORT and PPK_IDENTITY Not= ify messages, respectively

Also, I presume you're using PPK_ID_FIXED, not PPK_ID_OPAQUE?

Yes!=

Regards,
Vukasin

--001a114988deeec81a055ddf987f-- From nobody Mon Nov 13 23:31:03 2017 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 75037129493 for ; Mon, 13 Nov 2017 23:30:58 -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 HOG_eRVxLCsm for ; Mon, 13 Nov 2017 23:30:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 7025C129481 for ; Mon, 13 Nov 2017 23:30:56 -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 vAE7UqGT026087 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Nov 2017 09:30:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vAE7UqNL027178; Tue, 14 Nov 2017 09:30:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23050.39852.520962.719946@fireball.acr.fi> Date: Tue, 14 Nov 2017 09:30:52 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "Paul Wouters" , , "Sahana Prasad" In-Reply-To: References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 22 min Archived-At: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:30:58 -0000 Valery Smyslov writes: > > This is the reason why the RFC7427 only negotiates the hash algorithm, > > and the section 5 of the RFC 7427 gives several ways of solving this > > issue without doing protocol changes. > > No, section 5 is about a different problem: how to select > a proper certificate, if we have several certificates containing > public keys for different signature algorithms. Not true. It is how to select public key algorithm to use, and that boils down selecting suitable private/public key pair from your own private / public key pairs. When you have selected your private key you want to use that will then dicatate which public key you are going to using and also the certificate you are going to use. Even if you can use same private key for PKCS#1 and RSA-PSS, does not mean that you should do it. Using same key for different algorithms breaks the key separation principle, and I think that is considered bad idea. > Now we have the only certificate (or raw key), but we don't > know how to use it, because there are more than one way of > using it and the peer doesn't inform us what it supports. When you are generating the signature you have private key, and that should have algorithm associated to it... So when you select public key that will have one private key associated with it that has one algorithm associated to it etc. > RSASSA-PSS is just a specific problem we ran into, I suspect > we can have the same sort of problem in future with other signature > algorithms, provided their number is nowdays increasing > rapidly. If I remember right on discussion about the different elliptic curve algorithms, the situation was same there, i.e., even if you could use the same key for different algorithms, it is considered bad idea... -- kivinen@iki.fi From nobody Tue Nov 14 00:20:16 2017 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 072BC127077 for ; Tue, 14 Nov 2017 00:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpjE2SMfZgRa for ; Tue, 14 Nov 2017 00:20:08 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 F00991294BF for ; Tue, 14 Nov 2017 00:20:07 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id n69so21285900lfn.2 for ; Tue, 14 Nov 2017 00:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=gdwAFPp/d78gE4lEJr+93ZSSHFa9O79VQ8DrwC9DLrk=; b=EWWnyzLg0ahQidNMjLkQTNaGcg4bXs0mSE1vPXtQtLgDkmknwM/WB8G/xk+fRjhbvj LK9jQqUi+cLUAuFY8VuedI9Y2OT284Aq+M//VhcKZjjkxYgqSvngBctHcXHeZuZju8fc XmqOqOBQ7XE9a4CwVgVpMlVgyHKVaBQTB+1mWAFKe/nlETQuKHqEZBJyd78xwdWD+B44 Uo+d0gjaMDwVeZSvFUPSJB/Gn4N3yyfldighaam6AeewqCuF7xyyC7izUnLe4T9CI/Xt 0fRD0SS+kt+buGQJY/uarEluY8wEfK6E8CMWOFo8cnRHCPIyZ4/IsddwllvKQcK++Y2k D7HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=gdwAFPp/d78gE4lEJr+93ZSSHFa9O79VQ8DrwC9DLrk=; b=czCbnSTgtMZdQdm6NnSY8Xg1Xcbyj3O4XnsJDsxVMq63vzsXcp6xdUwG9/l+cQnjup NCYIjcfVEoo3008sCqyeNl7VJ9VpD3ODxtcrb+dvnOXPUJFnIWRqzFUDUWjD/XZOa4gc bn0gdgoZPuuyCrh1L7yLjevnibdfAn3BC2QvwsMbfMPnDQzkWb7caiR4IIV0SVOtpP00 ZJeOkaaVq4uzb9GtCW/rC9pBnUgJFfUTF+AMlWcy8ddc3MfbaprfRHEHqfZ7gwRIzDSo tFcAYNHrQPepGERybx093yuZ6QxIccWEqHFYwmzw68tdWafE1QDZMGer+diZVwmJGN+k 7PIA== X-Gm-Message-State: AJaThX44NmFLr+uaJWmW2aYx7/GI7EaXQr9MKQVxCm6Q1Rm+s2Jzd9jB o0q4ucshk1Oi5LPWTa9PQIhHCw== X-Google-Smtp-Source: AGs4zMaQprXkGSV5rvSCVWdNf35GzDLiypOPjxTcJl8GPW4KeTZsjos2MqL/NojFuv859ETNXrlgWA== X-Received: by 10.46.47.6 with SMTP id v6mr4273318ljv.163.1510647606021; Tue, 14 Nov 2017 00:20:06 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a9sm598537lfg.12.2017.11.14.00.20.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 00:20:05 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Paul Wouters'" , , "'Sahana Prasad'" References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> <23050.39852.520962.719946@fireball.acr.fi> In-Reply-To: <23050.39852.520962.719946@fireball.acr.fi> Date: Tue, 14 Nov 2017 11:20:01 +0300 Message-ID: <02ec01d35d21$5ea60980$1bf21c80$@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: AQHmiJT1dlQG1O0xNU142zXveMWwSwLsQDTUAr9f9YoCOd7Y3AFeJIlAAiQKtFcDNXcgAqJ4RO0Q Content-Language: ru Archived-At: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:20:14 -0000 > > RSASSA-PSS is just a specific problem we ran into, I suspect > > we can have the same sort of problem in future with other signature > > algorithms, provided their number is nowdays increasing > > rapidly. > > If I remember right on discussion about the different elliptic curve > algorithms, the situation was same there, i.e., even if you could use > the same key for different algorithms, it is considered bad idea... We are not talking about different algorithms. Consider the situation when the same signature can we represented in a different ways (e.g. different ASN.1 encodings). In this case we'll run into the problem if one of the peers supports only one way. The only reliable way for the initiator to select a proper form of signature now is pre-configuration. But it doesn't scale well and is problematic with opportunistic encryption. Regards, Valery. From nobody Tue Nov 14 00:57:43 2017 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 32BA71287A7 for ; Tue, 14 Nov 2017 00:57:42 -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 SHYpAirUcPwN for ; Tue, 14 Nov 2017 00:57:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 49CF2124B09 for ; Tue, 14 Nov 2017 00:57:40 -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 vAE8vYUY028155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Nov 2017 10:57:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vAE8vYHW003365; Tue, 14 Nov 2017 10:57:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23050.45054.267720.174818@fireball.acr.fi> Date: Tue, 14 Nov 2017 10:57:34 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Paul Wouters'" , , "'Sahana Prasad'" In-Reply-To: <02ec01d35d21$5ea60980$1bf21c80$@gmail.com> References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> <23050.39852.520962.719946@fireball.acr.fi> <02ec01d35d21$5ea60980$1bf21c80$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 6 min Archived-At: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:57:42 -0000 Valery Smyslov writes: > > If I remember right on discussion about the different elliptic curve > > algorithms, the situation was same there, i.e., even if you could use > > the same key for different algorithms, it is considered bad idea... > > We are not talking about different algorithms. Consider the situation > when the same signature can we represented in a different ways > (e.g. different ASN.1 encodings). > In this case we'll run into the problem if one of the peers supports > only one way. Why would you make multiple encodings formats for the same algorithm? And if so why should we allow that in IPsec. We do not allow prehashed formats of the Ed25519 and Ed448 because we do not want to have multiple formats for the same thing. > The only reliable way for the initiator to select a proper form of signature > now is pre-configuration. But it doesn't scale well and is problematic > with opportunistic encryption. It is same with PSKs or IP addresses / DNS names. You need to pre-configure the PSK to be used and to which IP address (or DNS name) to connect... IPsec normally do require some pre-configuration before it can be used (with exception to the opportunistic encryption). -- kivinen@iki.fi From nobody Tue Nov 14 01:09:20 2017 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 D0BC412773A for ; Tue, 14 Nov 2017 01:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPIYJUs_iE3v for ; Tue, 14 Nov 2017 01:09:17 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 D23A1124205 for ; Tue, 14 Nov 2017 01:09:16 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id m1so5416842lfj.9 for ; Tue, 14 Nov 2017 01:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=z2yZo9vndXMOctLES0yH8PvTOy+Hb1Ln6ZhUKdf15Yk=; b=A9cwaSvCG+Sxhbqh8or4zMJizcea0YsMhm8fLMFNjq23jbSV4FWZ1ASgT6fXBSvWvH WMuWDBhxH1Rge8ytfeCd3jn0T8+umUt9FPjkmPdaFzS3+U5tGPdAZPfFpYQ1Q8UIJKlr oDqannRHJJSCxDCp+JdETivc/nVzf0MFw5VF/hxfXwBjyU+g6TLGKCLoVCKvqDFZAcS6 IFZN1qmJjoX2fTUaCq85cO421sQNhCmnG2LsFNVpYGER/ZTRWQMOqFYWf86Q9WU2FVAf ffoeAun36UGeuv/XGwx/UgdgzLLPkoihMM+cEqn8uaCJX7dJ4Wy2bLMOz9CPbLfBP4vQ s/bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=z2yZo9vndXMOctLES0yH8PvTOy+Hb1Ln6ZhUKdf15Yk=; b=oebVcsHjvk9uVXBP737iTfUTvjRfLTUV/tbjGl4vzmEFlzoEuWtU4Wk87wIyDMvOg7 upyXsfxw7CARLgug2R6aL7nOnLlbZzoGieLoDz4eHSv00FJcJImx+h4TX9DMyGTyG2v1 /UvyG15Y/FNCePswqGlg/LTt0D2M8g+HKFm+eowtWbXMpytgGvMQYiOy10kiYfQoV6kf sw9LYVPvLc+Y3Q8xfr3cO3YJSXwIMQTAwDIGSyfPCrKpBQe85agG6agjttjRkQoAjNbD jP6p+KuT2ZKFTEJQ8/BQIQIgEJjU7/3U4wpxeAhiLsmVP0ch6wpmhcCT52n+AqRHArxI TFcQ== X-Gm-Message-State: AJaThX5TZYi7E9qZlpWifkgHXHIh7MvhWcYj2AyYMh2+hRhhu3+3PgYs BY6Sgg4/HCaTYi2wDol8KOCXoQ== X-Google-Smtp-Source: AGs4zMa4Q8Vu3DvART949FHh0zfQnu7aAN/1Hx92Wmg8J6b+1x8rKeGB9/u1TTP1uLoXSn8CwHF6ng== X-Received: by 10.25.215.222 with SMTP id q91mr4676737lfi.25.1510650554923; Tue, 14 Nov 2017 01:09:14 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g73sm118569ljg.24.2017.11.14.01.09.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 01:09:14 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Paul Wouters'" , , "'Sahana Prasad'" References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> <23050.39852.520962.719946@fireball.acr.fi> <02ec01d35d21$5ea60980$1bf21c80$@gmail.com> <23050.45054.267720.174818@fireball.acr.fi> In-Reply-To: <23050.45054.267720.174818@fireball.acr.fi> Date: Tue, 14 Nov 2017 12:09:10 +0300 Message-ID: <02fc01d35d28$3c712780$b5537680$@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: AQHmiJT1dlQG1O0xNU142zXveMWwSwLsQDTUAr9f9YoCOd7Y3AFeJIlAAiQKtFcDNXcgAgFwxGVZAaUlVYiiX6SjgA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:09:18 -0000 > Why would you make multiple encodings formats for the same algorithm? > And if so why should we allow that in IPsec. We do not allow prehashed > formats of the Ed25519 and Ed448 because we do not want to have > multiple formats for the same thing. If tomorrow cryptographers discover some weakness in one encoding and start recommend using another format, then we'll have to follow. And it doesn't matter if we disallowed using it before. > > The only reliable way for the initiator to select a proper form of signature > > now is pre-configuration. But it doesn't scale well and is problematic > > with opportunistic encryption. > > It is same with PSKs or IP addresses / DNS names. You need to > pre-configure the PSK to be used and to which IP address (or DNS name) > to connect... IPsec normally do require some pre-configuration before > it can be used (with exception to the opportunistic encryption). Some pre-configuration is inevitable. But let's try to keep it minimal - it helps maintain algorithm agility in large scale. From nobody Tue Nov 14 06:35:17 2017 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 D3151126C89 for ; Tue, 14 Nov 2017 06:35:15 -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 nV3wrEDVa1X8 for ; Tue, 14 Nov 2017 06:35:13 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 C01C8124B0A for ; Tue, 14 Nov 2017 06:35:13 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id a84so9643696pfl.0 for ; Tue, 14 Nov 2017 06:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zY5mz9RtXQ7RkaSzDGb94nvW58Zw8gSlOREwIYZJY/Y=; b=qMnoIfakaXpbwNrP7USqRySAnPq98RjH/vRwS7MY1LqCGdWmTKuizlEprCacH85bSp e+IovIm9QkAnbAyMKQ2SRTvFgvqpSMwQAnbrpG8Ifbupa+XBavA7Gn/wsaaMBZGIWi46 SrQrITNOHz9hgMw9PeUFCk9ROiQh0EcGxuDMA2kde8vGsq5TlmqOIxjENTVFp3JMnC3H liB/80JkfXEGN2wVFwUUEQGh7H6gNAEeuJLs+2bxMQoLyuIVjr9jSxWaClkZDq7Jxi36 ju3Q7Pn9szZko6ragP/H9w4Od4dtvPHB57U4rnN3QDgI0AeENYAOH4wUP0E2UoOCkFLL mfNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zY5mz9RtXQ7RkaSzDGb94nvW58Zw8gSlOREwIYZJY/Y=; b=M51wPJcFHZJqEn+1akwTas8m3rkrfdxoZUw8kWJ+Vcfw2vNVRBA694FJxJ0440VNp0 hS2hoOjtGYFQKFLyrnd+at2aoLHviK16ax2IB5oFj5WDo65kDJwgbws2foX05H2+wTcq f/Ey/Hdx4Li/tMzwvsDggHFPujhOnhqj6S/4odoAc5/ay8/Ehiyo23AOJg1uhduHVBhD LfYbnmYf8G/QNguwvQXxWknVH4hHC9SIZBikuxn56qIMFKYqW5j6RZ016yG3H04+fCFl XbtmbSVPdtehkBa8V/FMMo5pIv9FS4XLUmepUSLdTT0pMPtD0B+5gkMsU3SdRj0EzPyP Y6nw== X-Gm-Message-State: AJaThX72jdN/PTcq0ShPs2TuGkJXSbVuIQkBAHp1Rzalj2q937T6PJyL J4pNV/jzRSfgBIFhVKtVifM= X-Google-Smtp-Source: AGs4zMaUPtPnoPpsL2pgmY6tn68LSkJ+ksKIZpxyWNXmjhM/+VvWGajfWI4TmeegoE5KM6Lv4M5bpw== X-Received: by 10.159.216.130 with SMTP id s2mr12402238plp.347.1510670113341; Tue, 14 Nov 2017 06:35:13 -0800 (PST) Received: from [172.20.6.34] ([203.127.152.4]) by smtp.gmail.com with ESMTPSA id a78sm31420048pfl.155.2017.11.14.06.35.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 06:35:12 -0800 (PST) From: Yoav Nir Message-Id: <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D05059D7-C0C5-46CA-B781-D2C6A940BACA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Tue, 14 Nov 2017 22:36:03 +0800 In-Reply-To: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> Cc: IPsecME WG To: Valery Smyslov References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 14:35:16 -0000 --Apple-Mail=_D05059D7-C0C5-46CA-B781-D2C6A940BACA Content-Type: multipart/alternative; boundary="Apple-Mail=_C0784D57-49F0-48F1-AE9B-CBC1DC31F69D" --Apple-Mail=_C0784D57-49F0-48F1-AE9B-CBC1DC31F69D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization = messages in 6311 all have Message ID zero and are encrypted. There do = not seem to be any cleartext bits that differentiate one such message = from another (which is why the RFC admits that they are replayable). So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? = Drop the whole thing? Something else that I=E2=80=99m missing? Yoav > On 13 Nov 2017, at 11:30, Valery Smyslov wrote: >=20 > Hi, >=20 > there is also an RFC6311, which allows messages > with the MessageID (0) to be sent over the same IKE SA > in case of cluster failover. If the IKE SA is a result of a rekey > (not IKE_SA_INIT), then its first encrypted message > will have MessageID of 0, so if failover happens later, > the MessageID of zero will repeat, breaking the security. > You should consider this case also. >=20 > Regards, > Valery. >=20 > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Monday, November 13, 2017 5:35 AM > To: IPsecME WG > Subject: [IPsec] Proposal for using Implicit IV for IKE >=20 > Hi. >=20 > So following Daniel=E2=80=99s message in the room, here=E2=80=99s how = I think we can make this work. >=20 > The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: > All responses have the same Message ID as the requests. > The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. > When a message is fragmented as in RFC 7383, all fragments that are = part of the same message are transmitted (and encrypted) with the same = Message ID. >=20 > Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: >=20 > Proposal #1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >=20 > And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. >=20 > The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. >=20 > Proposal #2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| >=20 > The Fragment Counter is the same as in the RFC 7383 fragment payload, = or zero if we are using the regular encrypted payload. >=20 > The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. >=20 > The Fragment Counter differentiates between different part of the same = message. >=20 > The Next Payload differentiates between sending a message fragmented = and sending it unfragmented. >=20 >=20 > So in summary, I think it=E2=80=99s doable and can be added to the = draft if we have consensus. >=20 > Yoav --Apple-Mail=_C0784D57-49F0-48F1-AE9B-CBC1DC31F69D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Having re-read RFC 6311, Valery=E2=80=99s right. The = synchronization messages in 6311 all have Message ID zero and are = encrypted. There do not seem to be any cleartext bits that differentiate = one such message from another (which is why the RFC admits that they are = replayable).

So = I=E2=80=99m kind of stuck.  Support IIV or RFC 6311 but not both? =  Drop the whole thing?  Something else that I=E2=80=99m = missing?

Yoav

On 13 Nov 2017, at 11:30, Valery Smyslov <svanru@gmail.com> = wrote:

Hi,
 
there is also an RFC6311, which allows messages
with the = MessageID (0) to be sent over the same IKE SA
in case of = cluster failover. If the IKE SA is a result of a rekey
(not = IKE_SA_INIT), then its first encrypted message
will have = MessageID of 0, so if failover happens later,
the MessageID = of zero will repeat, breaking the security.
You should = consider this case also.
 
Regards,
Valery.
 
From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf = Of Yoav Nir
Sent: Monday, November 13, 2017 = 5:35 AM
To: IPsecME WG
Subject: [IPsec] Proposal for using = Implicit IV for IKE
 
Hi.
 
So following Daniel=E2=80=99s message in = the room, here=E2=80=99s how I think we can make this work.
 
The IKE = header has a =E2=80=9CMessage ID=E2=80=9D field that is a counter. = It=E2=80=99s tempting to use this as a counter, same as we use the = replay counter in IPsec.  However, as Tero pointed out on Jabber, = each such message ID can be used several times:
  • All responses have the same Message = ID as the requests.
  • The Message ID is one sided. =  The n-th request from the original Responder has the same Message = ID as the n-th request from the original Initiator.
  • When a message is fragmented as in RFC 7383, all fragments that = are part of the same message are transmitted (and encrypted) with the = same Message ID.
 
Re-using the Message ID = makes us re-use the AEAD nonce. Not good.  Fortunately, all the = algorithms that the IIV draft mentions require an 8-octet IV while the = Message ID is 4-octet.  We can use the 32 =E2=80=9Cspare=E2=80=9D = bits to differentiate these messages.  I have two proposals for = constructing the 8-octet IV:
 
Proposal #1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| 24 zero bits | Flags (8 bits) | Message ID (32 = bits)|
 
And use IIV only for regular Encrypted = Payload, not for Encrypted Fragment.  The reasoning is that if you = use fragmentation you=E2=80=99ve already solved the message-too-big = issue.
 
The Flags octet includes the I(nitiator) = and R(esponse) bits, which differentiate the cases that are not related = to fragmentation.
 
Proposal #2:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| Next Payload (8 bits) | Fragment Counter (16 bits) = | Message ID (32 bits)|
 
The Fragment Counter is the same as in = the RFC 7383 fragment payload, or zero if we are using the regular = encrypted payload.
 
The Flags octet includes the I(nitiator) = and R(esponse) bits, which differentiate the cases that are not related = to fragmentation.
 
The Fragment Counter differentiates = between different part of the same message.
 
The Next = Payload differentiates between sending a message fragmented and sending = it unfragmented. 
 
 
So in summary, I think it=E2=80=99s = doable and can be added to the draft if we have consensus.
 
Yoav

= --Apple-Mail=_C0784D57-49F0-48F1-AE9B-CBC1DC31F69D-- --Apple-Mail=_D05059D7-C0C5-46CA-B781-D2C6A940BACA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloK/1MACgkQuEkLFQpY zJlLJwgAtOnV5brGCbl438RxherJmd5KPYpOwm7qCSmpBDZRPf4MRWkKdz6POkVG vj7JjPMi5dnUWlvol0vnTgyKGOX/JAoYv5FrR9/QNEdwTxcr9oKOCv704tQ1+N/6 0gF4Vw9KPtumMVQF9A7EKsvfgpxbT9nqSocdGTiLKcrv6eJfkZ0uoeaHT4/Jz7rr JbkVRCg1v+OPxe6g47TP/znCLg4yRrcNXb3D+zeK+s/C0Ar5P1TVxAUSs5RUkxrH HPCO+AYXzu6BSChrEqQZltT8lR6pQgAZsSGSoAvio2u/sIbuEb7+QScJ4KgLFkUx 1IQ7+623o3XLMP1uJs0oSs8VhrqUfA== =umOm -----END PGP SIGNATURE----- --Apple-Mail=_D05059D7-C0C5-46CA-B781-D2C6A940BACA-- From nobody Tue Nov 14 17:42:31 2017 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 E1CE112944E for ; Tue, 14 Nov 2017 17:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4KMA45fzm0p for ; Tue, 14 Nov 2017 17:42:27 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 A8AEC129418 for ; Tue, 14 Nov 2017 17:42:26 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id e143so24435677lfg.12 for ; Tue, 14 Nov 2017 17:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=JZSdwNLQK2RDNtvOT56SAQAPvIE2+mF5x1gCwEBmzSk=; b=OcXfaem48jcDzSdcHEs3JO0MBE8fqFSujAxjcX4Jl2w1RAHfCK2dWG+TEP6yu5DYsR 33sq6VOYi6ASn5Gi7v2pBKOGhr5w0kTYFIYGgrsxHWDbnyT6ws/4AZqEbRc24etm5UqO P3XPZJvUWsfILCo1HwCIaNEtsanoeilKXgJy6Evh7X97onbf92PDh8tOjEMkAGfIKn4p 31lHLwckpgV/sVr9R5D9ZAkzFIGTcasP20TfIuLSU99zZQTRNfLspG4RPxcUUTypHuEu iosufAXVaMPBO5QimUPBLwOzxmsfNfXEL8u317AhmRr4zPWv34pbXmD2C2+trdb+an3a HfoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=JZSdwNLQK2RDNtvOT56SAQAPvIE2+mF5x1gCwEBmzSk=; b=nDL3FvwsKm7j16Kqd6LfCZQKPi8srNL5jGHWu2gHSdXdYDZisPafQBmIwKpECNfZKj fBEo9e+Oe6zigOECc0N6FAmAqebnmtG2a4LTf7jboLF+W50rTF9aIzHX3n8nDnHe+2Kb 55R/ct4nfVvMKO2VQW42wa92MlAAdnh9g9TAvGxX4gV9geff310vOy4bwiDXFqpCRVGa rO0IzJkkFt5VFZRzy5AjYj04DCiJ+By8BoDEPTK52EhJEQXQ57FgVPjzHUb+EekZqEp6 ls9WrzMBdyElaaot/WUGMerFeWtiK7037494QSjeOg87k6Yb/DRpspKM+rK/9z/YH/hR VeJQ== X-Gm-Message-State: AJaThX5bFoNVI5dXvH6qM6rISHwX32LA5MfYmnErSL0JF7Bcemd/L4b4 UygRGDlOWNhu1XRNY1djx6AakQ== X-Google-Smtp-Source: AGs4zMZN4GrgBQjhmZiIiImpBfwLYNxxNVx9PGx7CiK02CyASINmp6CBysw92cwjPwIwNOskGkY8sw== X-Received: by 10.25.199.17 with SMTP id x17mr2414363lff.199.1510710144525; Tue, 14 Nov 2017 17:42:24 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 1sm2074775ljt.22.2017.11.14.17.42.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 17:42:23 -0800 (PST) From: "Valery Smyslov" To: "'Yoav Nir'" Cc: "'IPsecME WG'" References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> In-Reply-To: <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> Date: Wed, 15 Nov 2017 04:42:20 +0300 Message-ID: <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AB_01D35DCC.1FE66220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwoU1jUGTnHsA3NnK29zh3WK6Q8gGJzYXfAxcSeDyitRcLkA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:42:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AB_01D35DCC.1FE66220 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I=E2=80=99m a bit nervous since we are trying to find a quick solution to an apparently not-so-easy problem in a rush time of WGLC. =20 I think we need more time for that, so we either should=20 drop the IIV for IKE and proceed with the current document for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2) or hold on the draft until we found a solution for IKEv2 too. =20 What about the way how to make IIV work with RFC6311, I can imaging the following solution. Cluster failover generally occurs rarely, so we may not worry about the overhead associated with sending RFC6311 messages. So we can introduce a combine mode, when some messages have implicit IV and some (e.g.RFC6311 = messages)=20 have explicit IV. Obviously we need to differentiate between them, so I presume we need to grab one of reserved bits in IKE header flags for this purpose. I admit it looks complicated, but I cannot come up with a simpler solution (except for not using IIV in IKEv2 at all). =20 Regards, Valery. =20 =20 From: Yoav Nir [mailto:ynir.ietf@gmail.com]=20 Sent: Tuesday, November 14, 2017 5:36 PM To: Valery Smyslov Cc: IPsecME WG Subject: Re: [IPsec] Proposal for using Implicit IV for IKE =20 Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization = messages in 6311 all have Message ID zero and are encrypted. There do = not seem to be any cleartext bits that differentiate one such message = from another (which is why the RFC admits that they are replayable). =20 So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? = Drop the whole thing? Something else that I=E2=80=99m missing? =20 Yoav On 13 Nov 2017, at 11:30, Valery Smyslov wrote: =20 Hi, =20 there is also an RFC6311, which allows messages with the MessageID (0) to be sent over the same IKE SA in case of cluster failover. If the IKE SA is a result of a rekey (not IKE_SA_INIT), then its first encrypted message will have MessageID of 0, so if failover happens later, the MessageID of zero will repeat, breaking the security. You should consider this case also. =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, November 13, 2017 5:35 AM To: IPsecME WG Subject: [IPsec] Proposal for using Implicit IV for IKE =20 Hi. =20 So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make this work. =20 The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: * All responses have the same Message ID as the requests. * The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. * When a message is fragmented as in RFC 7383, all fragments that are = part of the same message are transmitted (and encrypted) with the same = Message ID. =20 Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: =20 Proposal #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| =20 And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. =20 The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. =20 Proposal #2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| =20 The Fragment Counter is the same as in the RFC 7383 fragment payload, or = zero if we are using the regular encrypted payload. =20 The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. =20 The Fragment Counter differentiates between different part of the same = message. =20 The Next Payload differentiates between sending a message fragmented and = sending it unfragmented.=20 =20 =20 So in summary, I think it=E2=80=99s doable and can be added to the draft = if we have consensus. =20 Yoav =20 ------=_NextPart_000_03AB_01D35DCC.1FE66220 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I=E2=80=99m a bit nervous since we are trying to find a quick = solution

to an apparently not-so-easy problem in a rush time of = WGLC.

 

I think we need more time for that, so we either should =

drop the IIV for IKE and proceed with the current = document

for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2)

or hold on the draft until we found a solution for IKEv2 = too.

 

What about the way how to make IIV work with RFC6311, I = can

imaging the following solution. Cluster failover generally = occurs

rarely, so we may not worry about the overhead = associated

with sending RFC6311 messages. So we can introduce a = combine

mode, when some messages have implicit IV and some (e.g.RFC6311 = messages)

have explicit IV. Obviously we need to differentiate between = them,

so I presume we need to grab one of reserved bits in IKE header = flags

for this purpose. I admit it looks complicated, but I cannot come = up

with a simpler solution (except for not using IIV in IKEv2 at = all).

 

Regards,

Valery.

 

 

From:= Yoav Nir = [mailto:ynir.ietf@gmail.com]
Sent: Tuesday, November 14, 2017 = 5:36 PM
To: Valery Smyslov
Cc: IPsecME = WG
Subject: Re: [IPsec] Proposal for using Implicit IV for = IKE

 

Having = re-read RFC 6311, Valery=E2=80=99s right. The synchronization messages = in 6311 all have Message ID zero and are encrypted. There do not seem to = be any cleartext bits that differentiate one such message from another = (which is why the RFC admits that they are = replayable).

 

So I=E2=80=99m kind of stuck.  Support IIV or RFC = 6311 but not both?  Drop the whole thing?  Something else that = I=E2=80=99m missing?

 

Yoav



On 13 = Nov 2017, at 11:30, Valery Smyslov <svanru@gmail.com> = wrote:

 

Hi,

 

there is also an RFC6311, which allows = messages

with the MessageID (0) to be sent over the same IKE = SA

in case of cluster failover. If the IKE SA is a result of a = rekey

(not IKE_SA_INIT), then its first encrypted = message

will have MessageID of 0, so if failover happens = later,

the MessageID of zero will repeat, breaking the = security.

You should consider this case = also.

 

Regards,

Valery.

 

From:=  IPsec [mailto:ipsec-bounces@ietf.org]=  On Behalf Of Yoav = Nir
Sent: Monday, November 13, 2017 = 5:35 AM
To: IPsecME = WG
Subject: [IPsec] Proposal for using = Implicit IV for IKE

 

Hi.

 

So following Daniel=E2=80=99s message in the room, = here=E2=80=99s how I think we can make this = work.

 

The IKE header has a =E2=80=9CMessage ID=E2=80=9D = field that is a counter. It=E2=80=99s tempting to use this as a counter, = same as we use the replay counter in IPsec.  However, as Tero = pointed out on Jabber, each such message ID can be used several = times:

  • All = responses have the same Message ID as the requests.
  • The Message ID is = one sided.  The n-th request from the original Responder has the = same Message ID as the n-th request from the original = Initiator.
  • When a message is fragmented as in RFC 7383, all fragments = that are part of the same message are transmitted (and encrypted) with = the same Message ID.

 

Re-using the Message ID makes us re-use the AEAD = nonce. Not good.  Fortunately, all the algorithms that the IIV = draft mentions require an 8-octet IV while the Message ID is 4-octet. =  We can use the 32 =E2=80=9Cspare=E2=80=9D bits to differentiate = these messages.  I have two proposals for constructing the 8-octet = IV:

 

Proposal #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| 24 zero bits | Flags (8 bits) | = Message ID (32 bits)|

 

And use IIV only for regular Encrypted Payload, not = for Encrypted Fragment.  The reasoning is that if you use = fragmentation you=E2=80=99ve already solved the message-too-big = issue.

 

The Flags octet includes the I(nitiator) and = R(esponse) bits, which differentiate the cases that are not related to = fragmentation.

 

Proposal #2:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| Next Payload (8 bits) | Fragment = Counter (16 bits) | Message ID (32 = bits)|

 

The Fragment Counter is the same as in the RFC 7383 = fragment payload, or zero if we are using the regular encrypted = payload.

 

The Flags octet includes the I(nitiator) and = R(esponse) bits, which differentiate the cases that are not related to = fragmentation.

 

The Fragment Counter differentiates between different = part of the same message.

 

The Next Payload differentiates between sending a = message fragmented and sending it = unfragmented. 

 

 

So in summary, I think it=E2=80=99s doable and can be = added to the draft if we have = consensus.

 

Yoav

 

------=_NextPart_000_03AB_01D35DCC.1FE66220-- From nobody Tue Nov 14 18:10:18 2017 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 23CC5126D73 for ; Tue, 14 Nov 2017 18:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0W-ySzQ7yQ9 for ; Tue, 14 Nov 2017 18:10:14 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 DBADF129485 for ; Tue, 14 Nov 2017 18:10:13 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id f134so16180985lfg.8 for ; Tue, 14 Nov 2017 18:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=edPtPcFSEAmmMLqcVHP69UbGDpiT5H9mL2n5JMXkvBs=; b=nR2h8PQkbmOkKopIpdArjvO5tHh4qBwtw7IyDEpkDl2KWxwjyxW8a5jp1NCWB3jjpQ 6X006RhCmfOQxQ2+Zl1i/gOfsGS3Yo8zTaL49DbJKXimwyHaSjd8opVxPxnfyr/aycDx SD+CCgXUz+MIdFn6YXNoUyC9Z2VjleURv5lnDopChadVevQufQ2jfyOHcjDMcp0lNskf 11zifNd5sG/OpV43z/YLTN0rauhqXJoSZ31kJjKEFmodB7OQJbO0gbvSFlDRjTmkRz0B Pup6D8/M9g0eCYRly4bTZ8knqRyp83Jpi3a0n0zjGSjCDhbXz5IPewt+TKQLTdzhWYsq r6Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=edPtPcFSEAmmMLqcVHP69UbGDpiT5H9mL2n5JMXkvBs=; b=AoIsKWM9O1VWDKyFic0NIi9wEm/sk8n77TpRYrGLF4ZRg8BONSzJSMCKY5eTxpOdXr 3kStXJRgZZxv63JFjkdKKXnZi48qJGl47X3ySZIodLy94TQqk1dO99zHsiq4/j7x1T3a ZejeBSNAqYYKZ4TvYyvydcBtUP2AIZ9C5mqC9VQyDT9QM7sWe7z/KwTN31ObaUTM5B7t 7Z/2Lewa1CLywl+3C/YESvjjpz04SD0JItMAAOFabHnWLbeW1LOZr2XNCqSDldPtxpev KaW/AwSgzGaft4Fr9s2/tV5QgEeY96HrNbwEWXHb48VbOYjkTzYTMsTlOWeHPblDlbX+ nj0g== X-Gm-Message-State: AJaThX7KVY8N+azOVq0V5EfbJ07NfPnSfwAIW/aWlbpwNhnzCGm5m/RB imc9TBX0gCRORytrgQrp1QEEpnB4jAbKj92YULQ= X-Google-Smtp-Source: AGs4zMYScIHnv9r5uBW3oHwyC6UTyOwG68YFm6g2meMEYxox9aBWx10x3IqzQYL0Zl5OsAsbCNnWciB+9wqqNut77Jk= X-Received: by 10.25.24.166 with SMTP id 38mr3378901lfy.79.1510711812104; Tue, 14 Nov 2017 18:10:12 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.82.218 with HTTP; Tue, 14 Nov 2017 18:10:11 -0800 (PST) In-Reply-To: <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> From: Daniel Migault Date: Tue, 14 Nov 2017 21:10:11 -0500 X-Google-Sender-Auth: nOQMDkAU9yV_8ewyAHClAZIAsdQ Message-ID: To: Valery Smyslov Cc: Yoav Nir , IPsecME WG Content-Type: multipart/alternative; boundary="001a11405914eb256b055dfc002d" Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:10:17 -0000 --001a11405914eb256b055dfc002d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am more incline to have IIV for iKEv2 in another document and as such we request the IANA to set the "IKEv2 Reference" to UNDEFINED. What about the following text ? [RFC8247] recommends the same suites for IKEv2. However some IKEv2 extensions such as [RFC6311] or [RFC7383] allow the Message ID to be re-used, which is incompatible with the uniqueness property of the nonce, and makes these suites highly insecure. As a result, the suites defined is this document does not apply to IKEv2. The IANA is expected to put "UNDEFINED" in the column "IKEv2 Reference" for these transforms. Yours, Daniel On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov wrote: > Hi, > > > > I=E2=80=99m a bit nervous since we are trying to find a quick solution > > to an apparently not-so-easy problem in a rush time of WGLC. > > > > I think we need more time for that, so we either should > > drop the IIV for IKE and proceed with the current document > > for ESP only (and probably creating a new work item =E2=80=93 IIV for IKE= v2) > > or hold on the draft until we found a solution for IKEv2 too. > > > > What about the way how to make IIV work with RFC6311, I can > > imaging the following solution. Cluster failover generally occurs > > rarely, so we may not worry about the overhead associated > > with sending RFC6311 messages. So we can introduce a combine > > mode, when some messages have implicit IV and some (e.g.RFC6311 messages) > > have explicit IV. Obviously we need to differentiate between them, > > so I presume we need to grab one of reserved bits in IKE header flags > > for this purpose. I admit it looks complicated, but I cannot come up > > with a simpler solution (except for not using IIV in IKEv2 at all). > > > > Regards, > > Valery. > > > > > > *From:* Yoav Nir [mailto:ynir.ietf@gmail.com] > *Sent:* Tuesday, November 14, 2017 5:36 PM > *To:* Valery Smyslov > *Cc:* IPsecME WG > *Subject:* Re: [IPsec] Proposal for using Implicit IV for IKE > > > > Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization mess= ages in > 6311 all have Message ID zero and are encrypted. There do not seem to be > any cleartext bits that differentiate one such message from another (whic= h > is why the RFC admits that they are replayable). > > > > So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? Dro= p the > whole thing? Something else that I=E2=80=99m missing? > > > > Yoav > > > > On 13 Nov 2017, at 11:30, Valery Smyslov wrote: > > > > Hi, > > > > there is also an RFC6311, which allows messages > > with the MessageID (0) to be sent over the same IKE SA > > in case of cluster failover. If the IKE SA is a result of a rekey > > (not IKE_SA_INIT), then its first encrypted message > > will have MessageID of 0, so if failover happens later, > > the MessageID of zero will repeat, breaking the security. > > You should consider this case also. > > > > Regards, > > Valery. > > > > *From:* IPsec [mailto:ipsec-bounces@ietf.org ] *O= n > Behalf Of *Yoav Nir > *Sent:* Monday, November 13, 2017 5:35 AM > *To:* IPsecME WG > *Subject:* [IPsec] Proposal for using Implicit IV for IKE > > > > Hi. > > > > So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I t= hink we can make > this work. > > > > The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a counter= . It=E2=80=99s tempting > to use this as a counter, same as we use the replay counter in IPsec. > However, as Tero pointed out on Jabber, each such message ID can be used > several times: > > - All responses have the same Message ID as the requests. > - The Message ID is one sided. The n-th request from the original > Responder has the same Message ID as the n-th request from the origina= l > Initiator. > - When a message is fragmented as in RFC 7383, all fragments that are > part of the same message are transmitted (and encrypted) with the same > Message ID. > > > > Re-using the Message ID makes us re-use the AEAD nonce. Not good. > Fortunately, all the algorithms that the IIV draft mentions require an > 8-octet IV while the Message ID is 4-octet. We can use the 32 =E2=80=9Cs= pare=E2=80=9D bits > to differentiate these messages. I have two proposals for constructing t= he > 8-octet IV: > > > > Proposal #1: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| > > > > And use IIV only for regular Encrypted Payload, not for Encrypted > Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already > solved the message-too-big issue. > > > > The Flags octet includes the I(nitiator) and R(esponse) bits, which > differentiate the cases that are not related to fragmentation. > > > > Proposal #2: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 > bits)| > > > > The Fragment Counter is the same as in the RFC 7383 fragment payload, or > zero if we are using the regular encrypted payload. > > > > The Flags octet includes the I(nitiator) and R(esponse) bits, which > differentiate the cases that are not related to fragmentation. > > > > The Fragment Counter differentiates between different part of the same > message. > > > > The Next Payload differentiates between sending a message fragmented and > sending it unfragmented. > > > > > > So in summary, I think it=E2=80=99s doable and can be added to the draft = if we > have consensus. > > > > Yoav > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001a11405914eb256b055dfc002d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am more incline to have IIV for iKEv2 in another do= cument and as such we request the IANA to set the "IKEv2 Reference&quo= t; to UNDEFINED.

What about the following text ?

= =C2=A0=C2=A0 [RFC8247] recommends the same suites for IKEv2.=C2=A0 However = some IKEv2
=C2=A0=C2=A0 extensions such as [RFC6311] or [RFC7383] allow = the Message ID to be
=C2=A0=C2=A0 re-used, which is incompatible with th= e uniqueness property of
=C2=A0=C2=A0 the nonce, and makes these suites = highly insecure. As a result, the suites
=C2=A0=C2=A0 defined is this do= cument does not apply to IKEv2. The IANA is expected to
=C2=A0=C2=A0 pu= t "UNDEFINED" in the column "IKEv2 Reference" for these= transforms.

Yours,
Daniel

On Tue, No= v 14, 2017 at 8:42 PM, Valery Smyslov <svanru@gmail.com> wrot= e:

Hi,

=C2=A0

I= =E2=80=99m a bit nervous since we are trying to find a quick solution

to an apparently not-so-easy problem in a rush time of WGLC.<= /u>

=C2=A0

I think we need more time for that, so we e= ither should

drop the IIV for IKE and proceed with the curre= nt document

for ESP only (and probably creating a new work it= em =E2=80=93 IIV for IKEv2)

= or hold on the draft until we fou= nd a solution for IKEv2 too.

=C2=A0

<= p class=3D"MsoNormal">What about = the way how to make IIV work with RFC6311, I can

imaging the = following solution. Cluster failover generally occurs<= /p>

rarely,= so we may not worry about the overhead associated

=

with sendi= ng RFC6311 messages. So we can introduce a combine

=

mode, when= some messages have implicit IV and some (e.g.RFC6311 messages) <= /u>

have explicit IV. Obviously we need to differentiate between them,

so I presume we need to grab one of reserved bits in IKE header = flags

for this purpose. I admit it looks complicated, but I c= annot come up

with a simpler solution (except for not using I= IV in IKEv2 at all).

=C2=A0

Regards,=

Valery.

=C2=A0

=C2=A0=

From: Yoav Nir [mailto:ynir.ietf@gmail.com]
= Sent: Tuesday, November 14, 2017 5:36 PM
To: Valery Smyslo= v
Cc: IPsecME WG
Subject: Re: [IPsec] Proposal for usin= g Implicit IV for IKE

=C2=A0

Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization mes= sages in 6311 all have Message ID zero and are encrypted. There do not seem= to be any cleartext bits that differentiate one such message from another = (which is why the RFC admits that they are replayable).

=C2=A0

So I=E2=80=99m kind of stuck.=C2=A0 Support IIV or RFC 6311 but no= t both?=C2=A0 Drop the whole thing?=C2=A0 Something else that I=E2=80=99m m= issing?

=C2=A0=

Yoav



On 1= 3 Nov 2017, at 11:30, Valery Smyslov <svanru@gmail.com> wrote:

=

=C2=A0

Hi,

=

=C2=A0

there is also an RFC6311, which allows mes= sages

with the MessageID (0) to be sent over the s= ame IKE SA

in case of cluster failover. If the IKE= SA is a result of a rekey

(not IKE_SA_INIT), then= its first encrypted message

will have MessageID o= f 0, so if failover happens later,

the MessageID o= f zero will repeat, breaking the security.

You sho= uld consider this case also.

=C2=A0<= u>

Regards,

Valery.

=C2=A0

From:=C2= =A0IPsec [mailto:ipsec-bounces@ietf.org]= =C2=A0= On Behalf Of=C2= =A0Yoav Nir
Sent:=C2=A0Monday, November 13, 2017 5:35 AM
= To:=C2=A0IPsecME WG
Subject:=C2=A0[IPsec] Proposal for using Implicit IV for IK= E

=C2=A0

Hi.

=C2=A0<= u>

So following = Daniel=E2=80=99s message in the room, here=E2=80=99s how I think we can mak= e this work.

= =C2=A0

The IK= E header has a =E2=80=9CMessage ID=E2=80=9D field that is a counter. It=E2= =80=99s tempting to use this as a counter, same as we use the replay counte= r in IPsec.=C2=A0 However, as Tero pointed out on Jabber, each such message= ID can be used several times:

  • All responses hav= e the same Message ID as the requests.
  • The Message ID is one sided.=C2=A0 The n-th request from the original= Responder has the same Message ID as the n-th request from the original In= itiator.
  • When a message is fragme= nted as in RFC 7383, all fragments that are part of the same message are tr= ansmitted (and encrypted) with the same Message ID.
=

=C2=A0

=

Re-using the Message ID makes us re-use th= e AEAD nonce. Not good.=C2=A0 Fortunately, all the algorithms that the IIV = draft mentions require an 8-octet IV while the Message ID is 4-octet.=C2=A0= We can use the 32 =E2=80=9Cspare=E2=80=9D bits to differentiate these mess= ages.=C2=A0 I have two proposals for constructing the 8-octet IV:=

=C2=A0

Proposal #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

| 24 zero= bits | Flags (8 bits) | Message ID (32 bits)|

=C2=A0

=

And use IIV only for regular Encrypted Payload,= not for Encrypted Fragment.=C2=A0 The reasoning is that if you use fragmen= tation you=E2=80=99ve already solved the message-too-big issue.

=C2=A0

=

The Flags octet includes the I= (nitiator) and R(esponse) bits, which differentiate the cases that are not = related to fragmentation.

=C2=A0

Proposal #2:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div>

| Next Payload (8 bits) | Fragment Counter (16 b= its) | Message ID (32 bits)|

=C2=A0

The Fragment Counter is the same as in the RFC 7383 fragment payl= oad, or zero if we are using the regular encrypted payload.

=C2=A0

The Flags octet includes the I(nit= iator) and R(esponse) bits, which differentiate the cases that are not rela= ted to fragmentation.

=C2=A0

The Fragment Counter differentiates between different part of the same m= essage.

=C2= =A0

The Next = Payload differentiates between sending a message fragmented and sending it = unfragmented.=C2=A0

=C2=A0

=C2=A0

So in= summary, I think it=E2=80=99s doable and can be added to the draft if we h= ave consensus.

=C2=A0

Yoav=

<= /u>=C2=A0


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


--001a11405914eb256b055dfc002d-- From nobody Tue Nov 14 18:15:29 2017 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 AF8BF1200CF for ; Tue, 14 Nov 2017 18:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVuNOSdGFhUn for ; Tue, 14 Nov 2017 18:15:26 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 A7E3A126D73 for ; Tue, 14 Nov 2017 18:15:25 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id o41so657354lfi.2 for ; Tue, 14 Nov 2017 18:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=vWWqaXQ4KPDxnuOdeIvK3imyW1T8Chvt88INpV0tcNE=; b=Ryp4V5YAYHOPg9yG6SV7yRcdl5Yht+1UCYi4q22jFDOV4aRJezmD7r7Z5MLngXm57z b9ojM/IDZktYC56sI/C/EJDGCs+3uyZXG+Po1AMoJqSVaJagqAz031W4uNCAi8J6G212 0cDxIg9a4o3RlYoTV2XU2l9qf215d0wQUMvVtPP8IRJlphcKhVt54zVRutMSTiAisWFA 7Wm8w1CB3vfNSWTV6mms6F/ms/jIr/5u2VtoIDqKVWiuxe3GT47oNfuSfilu/BdCNiHJ 0xUiw0a5/9rNRHS9lu3cm0EnBtgrR5ADFEj7jZ32meXmbjbfJWbovcjJquI3jyAKeVSD WOng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=vWWqaXQ4KPDxnuOdeIvK3imyW1T8Chvt88INpV0tcNE=; b=Wll8WR3flfPb1n56ClWs7qfjKc1UIYrEMFz+o0Ib+Ev69VRxO29ZiT7AKnjW1//s9J X1KsQAsGq2IjwxPxzofnu3rX7UfcsvaP8sKFWGUvtcILft/nZrPSaqyYUPynNe1nWAYI YuhMCVQ4uWQzOBVruE2IYFvxxOgZJxB7itR7SPTWyhm1RSGjY8xulvmLlJJn2VqWmW4q QPF6JOzb46zs0Jk6KHyf/VhVIw68D+/pqRN9f5FsmyqgfkyXFetBN1eXF/v9QQ1d3Tko dHgG9fJsBKnN1kvIAni0tgSMJTcvGksFXib567C6ICd8dQNGU9uNIRNzbg5CAFE6YqnB VpTQ== X-Gm-Message-State: AJaThX6ZEGpUMoVs7la7usGCD739/axEbZ383np2H6NpA1MAsOsd26CK /8HEBn+GqT9nDt9clWaq6xU= X-Google-Smtp-Source: AGs4zMbukt9biBmnld7TUWat93Ix2INH/8bvFHYtiqsdGDITJXPQ0sKirXuLgYx1bLTeoXj2ZWF1Eg== X-Received: by 10.25.142.5 with SMTP id q5mr4388160lfd.19.1510712123922; Tue, 14 Nov 2017 18:15:23 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t7sm3992688ljd.53.2017.11.14.18.15.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 18:15:23 -0800 (PST) From: "Valery Smyslov" To: "'Daniel Migault'" Cc: "'Yoav Nir'" , "'IPsecME WG'" References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> In-Reply-To: Date: Wed, 15 Nov 2017 05:15:20 +0300 Message-ID: <03bb01d35db7$969398d0$c3baca70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BC_01D35DD0.BBE7D5B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwoU1jUGTnHsA3NnK29zh3WK6Q8gGJzYXfAxcSeDwBIzby+QHFddfQop3fv7A= Content-Language: ru Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:15:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03BC_01D35DD0.BBE7D5B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I also think that separate document is a right way to go. =20 From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault Sent: Wednesday, November 15, 2017 5:10 AM To: Valery Smyslov Cc: Yoav Nir; IPsecME WG Subject: Re: [IPsec] Proposal for using Implicit IV for IKE =20 I am more incline to have IIV for iKEv2 in another document and as such = we request the IANA to set the "IKEv2 Reference" to UNDEFINED.=20 What about the following text ? [RFC8247] recommends the same suites for IKEv2. However some IKEv2 extensions such as [RFC6311] or [RFC7383] allow the Message ID to be re-used, which is incompatible with the uniqueness property of the nonce, and makes these suites highly insecure. As a result, the = suites defined is this document does not apply to IKEv2. The IANA is = expected to=20 put "UNDEFINED" in the column "IKEv2 Reference" for these transforms. =20 Yours,=20 Daniel =20 On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov = wrote: Hi, =20 I=E2=80=99m a bit nervous since we are trying to find a quick solution to an apparently not-so-easy problem in a rush time of WGLC. =20 I think we need more time for that, so we either should=20 drop the IIV for IKE and proceed with the current document for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2) or hold on the draft until we found a solution for IKEv2 too. =20 What about the way how to make IIV work with RFC6311, I can imaging the following solution. Cluster failover generally occurs rarely, so we may not worry about the overhead associated with sending RFC6311 messages. So we can introduce a combine mode, when some messages have implicit IV and some (e.g.RFC6311 = messages)=20 have explicit IV. Obviously we need to differentiate between them, so I presume we need to grab one of reserved bits in IKE header flags for this purpose. I admit it looks complicated, but I cannot come up with a simpler solution (except for not using IIV in IKEv2 at all). =20 Regards, Valery. =20 =20 From: Yoav Nir [mailto:ynir.ietf@gmail.com]=20 Sent: Tuesday, November 14, 2017 5:36 PM To: Valery Smyslov Cc: IPsecME WG Subject: Re: [IPsec] Proposal for using Implicit IV for IKE =20 Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization = messages in 6311 all have Message ID zero and are encrypted. There do = not seem to be any cleartext bits that differentiate one such message = from another (which is why the RFC admits that they are replayable). =20 So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? = Drop the whole thing? Something else that I=E2=80=99m missing? =20 Yoav =20 On 13 Nov 2017, at 11:30, Valery Smyslov wrote: =20 Hi, =20 there is also an RFC6311, which allows messages with the MessageID (0) to be sent over the same IKE SA in case of cluster failover. If the IKE SA is a result of a rekey (not IKE_SA_INIT), then its first encrypted message will have MessageID of 0, so if failover happens later, the MessageID of zero will repeat, breaking the security. You should consider this case also. =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, November 13, 2017 5:35 AM To: IPsecME WG Subject: [IPsec] Proposal for using Implicit IV for IKE =20 Hi. =20 So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make this work. =20 The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: * All responses have the same Message ID as the requests. * The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. * When a message is fragmented as in RFC 7383, all fragments that are = part of the same message are transmitted (and encrypted) with the same = Message ID. =20 Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: =20 Proposal #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| =20 And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. =20 The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. =20 Proposal #2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| =20 The Fragment Counter is the same as in the RFC 7383 fragment payload, or = zero if we are using the regular encrypted payload. =20 The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. =20 The Fragment Counter differentiates between different part of the same = message. =20 The Next Payload differentiates between sending a message fragmented and = sending it unfragmented.=20 =20 =20 So in summary, I think it=E2=80=99s doable and can be added to the draft = if we have consensus. =20 Yoav =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_03BC_01D35DD0.BBE7D5B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I also think that separate document is a right way to = go.

 

From:= = mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault
Sent: Wednesday, November 15, 2017 5:10 = AM
To: Valery Smyslov
Cc: Yoav Nir; IPsecME = WG
Subject: Re: [IPsec] Proposal for using Implicit IV for = IKE

 

I am more incline to have IIV for iKEv2 = in another document and as such we request the IANA to set the = "IKEv2 Reference" to UNDEFINED.

What about the following text ?


   [RFC8247] recommends the same suites = for IKEv2.  However some IKEv2
   extensions such as = [RFC6311] or [RFC7383] allow the Message ID to be
   = re-used, which is incompatible with the uniqueness property = of
   the nonce, and makes these suites highly insecure. As = a result, the suites
   defined is this document does not = apply to IKEv2. The IANA is expected to
   put = "UNDEFINED" in the column "IKEv2 Reference" for = these transforms.

 

Yours,

Daniel

 

On Tue, = Nov 14, 2017 at 8:42 PM, Valery Smyslov <svanru@gmail.com> = wrote:

Hi,

 

I=E2=80=99m a bit nervous since we are trying to find a quick = solution

to an apparently not-so-easy problem in a rush time of = WGLC.

 

I think we need more time for that, so we either should =

drop the IIV for IKE and proceed with the current = document

for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2)

or hold on the draft until we found a solution for IKEv2 = too.

 

What about the way how to make IIV work with RFC6311, I = can

imaging the following solution. Cluster failover generally = occurs

rarely, so we may not worry about the overhead = associated

with sending RFC6311 messages. So we can introduce a = combine

mode, when some messages have implicit IV and some (e.g.RFC6311 = messages)

have explicit IV. Obviously we need to differentiate between = them,

so I presume we need to grab one of reserved bits in IKE header = flags

for this purpose. I admit it looks complicated, but I cannot come = up

with a simpler solution (except for not using IIV in IKEv2 at = all).

 

Regards,

Valery.

 

 

From:= Yoav Nir = [mailto:ynir.ietf@gmail.com]
Sent: Tuesday, = November 14, 2017 5:36 PM
To: Valery Smyslov
Cc: = IPsecME WG
Subject: Re: [IPsec] Proposal for using Implicit IV = for IKE

 <= /o:p>

Having = re-read RFC 6311, Valery=E2=80=99s right. The synchronization messages = in 6311 all have Message ID zero and are encrypted. There do not seem to = be any cleartext bits that differentiate one such message from another = (which is why the RFC admits that they are = replayable).

 <= /o:p>

So = I=E2=80=99m kind of stuck.  Support IIV or RFC 6311 but not = both?  Drop the whole thing?  Something else that I=E2=80=99m = missing?

 <= /o:p>

Yoav

 <= /p>

On 13 Nov = 2017, at 11:30, Valery Smyslov <svanru@gmail.com> wrote:

 <= /o:p>

Hi,

 

there is also an RFC6311, which allows = messages

with the MessageID (0) to be sent over the same IKE = SA

in case of cluster failover. If the IKE SA is a result of a = rekey

(not IKE_SA_INIT), then its first encrypted = message

will have MessageID of 0, so if failover happens = later,

the MessageID of zero will repeat, breaking the = security.

You should consider this case = also.

 

Regards,

Valery.

 

From:=  IPsec [mailto:ipsec-bounces@ietf.org] On = Behalf Of Yoav = Nir
Sent: Monday, = November 13, 2017 5:35 AM
To: IPsecME = WG
Subject: [IPsec] = Proposal for using Implicit IV for = IKE

 

Hi.

 <= /o:p>

So = following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make this work.

 <= /o:p>

The IKE = header has a =E2=80=9CMessage ID=E2=80=9D field that is a counter. = It=E2=80=99s tempting to use this as a counter, same as we use the = replay counter in IPsec.  However, as Tero pointed out on Jabber, = each such message ID can be used several = times:

  • All responses have the same Message ID as the = requests.
  • The Message ID is one sided.  The n-th request from = the original Responder has the same Message ID as the n-th request from = the original Initiator.
  • When a message is fragmented as in RFC 7383, all fragments = that are part of the same message are transmitted (and encrypted) with = the same Message ID.

 <= /o:p>

Re-using = the Message ID makes us re-use the AEAD nonce. Not good.  = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet.  We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages.  I = have two proposals for constructing the 8-octet = IV:

 <= /o:p>

Proposal = #1:

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

| 24 zero = bits | Flags (8 bits) | Message ID (32 = bits)|

 <= /o:p>

And use IIV = only for regular Encrypted Payload, not for Encrypted Fragment.  = The reasoning is that if you use fragmentation you=E2=80=99ve already = solved the message-too-big issue.

 <= /o:p>

The Flags = octet includes the I(nitiator) and R(esponse) bits, which differentiate = the cases that are not related to = fragmentation.

 <= /o:p>

Proposal = #2:

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

| Next = Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)|

 <= /o:p>

The = Fragment Counter is the same as in the RFC 7383 fragment payload, or = zero if we are using the regular encrypted = payload.

 <= /o:p>

The Flags = octet includes the I(nitiator) and R(esponse) bits, which differentiate = the cases that are not related to = fragmentation.

 <= /o:p>

The = Fragment Counter differentiates between different part of the same = message.

 <= /o:p>

The Next = Payload differentiates between sending a message fragmented and sending = it unfragmented. 

 <= /o:p>

 <= /o:p>

So in = summary, I think it=E2=80=99s doable and can be added to the draft if we = have consensus.

 <= /o:p>

Yoav

 <= /o:p>


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

 

------=_NextPart_000_03BC_01D35DD0.BBE7D5B0-- From nobody Tue Nov 14 18:30:14 2017 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 71090129498 for ; Tue, 14 Nov 2017 18:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpopg9QZ6K4v for ; Tue, 14 Nov 2017 18:30:11 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1521126E3A for ; Tue, 14 Nov 2017 18:30:10 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id o7so16885218pgc.4 for ; Tue, 14 Nov 2017 18:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Uml4QLunIOu++cPesiRqsh2Bu2vO+RYtEYMhZkOtXXI=; b=myWgIw68E1Am4XhIBoAq4/LkhH9ZrflXSrPyAP+yAzYc4/nOgiK4d0w6HhdnnhbGhm sCMCJhN3FUdHCUj9kKyfFPAFh7I4sahqMb8V3V05MkgK4vgb0nWAVCxGOG36rtgQMjd3 VcPHdK9bCUtrW8MQDL87CgAfvTtagfiWqd1Ro4aHmkTJA+wdhwdL7B7DomenRkAGVhQI i4GqacEZY1+Cdw44d+RYB/hrTD5Q+uixuNR0NW8M51eZLEZ33Shdq61E+GS5GNSFxfub 49cCcyjpk333va2r7ykz0XehD9gOz9qrnYyOiX3KeGB2JE3C+UcAGwVlW7X/v8I4FbDj HLew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Uml4QLunIOu++cPesiRqsh2Bu2vO+RYtEYMhZkOtXXI=; b=csiXgfcF7qSW1iWvXj/t9N47yn7r0uPTm/UFEe/cTnE/PNPIgpu0yy8aYRVdTb4lIT agiihMhUA1aHV7ayLzCI+tpC3IM0mfxAlHliMriSzU5RTZ3CJ3lPy2EQZW2S8Ii7nf30 AcvhPPe9p8GxnO2wecn+pQWK24xjlTOqpUjZ05MmSE4M/rlCfdPsgHUCxkXZ/wqih86T Lkd7ToiToVY0i7V5OXIQDjGzi9MvFWxx+BtqYxbvf54NfMNhvO85Rz3eDG4j+pP7qwYb xgjfReH5LixwSjhV3k4dU5MXs1M+NFUTfo58n47EAknzS6LUgr/DEqY4r4ZdI9yLi2yB XFRg== X-Gm-Message-State: AJaThX7q/Br7BOiLKcQHaEfyAQt3SiyBaynzM2oUWaV0VQkSbets/r4S w22GmR2icLPdx7k6oouaHWc= X-Google-Smtp-Source: AGs4zMY6Rl3RaeFGJjh5XFqvGCClS68PTBVWaAjs1M5O7NTHjO5sAM7Wv+Myxqa/ys1LZdSRqPWtoA== X-Received: by 10.98.141.150 with SMTP id p22mr1643653pfk.207.1510713010417; Tue, 14 Nov 2017 18:30:10 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:11b9:4fe2:bb8c:6524? ([2001:67c:370:128:11b9:4fe2:bb8c:6524]) by smtp.gmail.com with ESMTPSA id y1sm24973294pge.27.2017.11.14.18.30.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 18:30:09 -0800 (PST) From: Yoav Nir Message-Id: <7073D6DB-2C7E-4B0F-AF97-BD477458443E@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E7181425-B136-42F5-A176-C3408B2EB448"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Wed, 15 Nov 2017 10:30:26 +0800 In-Reply-To: Cc: Valery Smyslov , IPsecME WG To: Daniel Migault References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:30:13 -0000 --Apple-Mail=_E7181425-B136-42F5-A176-C3408B2EB448 Content-Type: multipart/alternative; boundary="Apple-Mail=_226E6B67-67F5-4693-9306-C8C617425AE2" --Apple-Mail=_226E6B67-67F5-4693-9306-C8C617425AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Daniel I think your text is confusing without the suggestion to use Message ID = as a nonce. This suggestion is not in the text, it was only in this = email thread. So I think the text should be (new paragraph at the end of IANA = Considerations): These algorithms should be added with this document as ESP Reference = and =E2=80=9CNot Allowed=E2=80=9D for IKEv2 Reference. This seems fitting for = https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#i= kev2-parameters-5 A new document will change that. > On 15 Nov 2017, at 10:10, Daniel Migault = wrote: >=20 > I am more incline to have IIV for iKEv2 in another document and as = such we request the IANA to set the "IKEv2 Reference" to UNDEFINED. >=20 > What about the following text ? >=20 > [RFC8247] recommends the same suites for IKEv2. However some IKEv2 > extensions such as [RFC6311] or [RFC7383] allow the Message ID to = be > re-used, which is incompatible with the uniqueness property of > the nonce, and makes these suites highly insecure. As a result, the = suites > defined is this document does not apply to IKEv2. The IANA is = expected to > put "UNDEFINED" in the column "IKEv2 Reference" for these = transforms. >=20 > Yours, > Daniel >=20 > On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov > wrote: > Hi, >=20 >=20 >=20 > I=E2=80=99m a bit nervous since we are trying to find a quick solution >=20 > to an apparently not-so-easy problem in a rush time of WGLC. >=20 >=20 >=20 > I think we need more time for that, so we either should >=20 > drop the IIV for IKE and proceed with the current document >=20 > for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2) >=20 > or hold on the draft until we found a solution for IKEv2 too. >=20 >=20 >=20 > What about the way how to make IIV work with RFC6311, I can >=20 > imaging the following solution. Cluster failover generally occurs >=20 > rarely, so we may not worry about the overhead associated >=20 > with sending RFC6311 messages. So we can introduce a combine >=20 > mode, when some messages have implicit IV and some (e.g.RFC6311 = messages) >=20 > have explicit IV. Obviously we need to differentiate between them, >=20 > so I presume we need to grab one of reserved bits in IKE header flags >=20 > for this purpose. I admit it looks complicated, but I cannot come up >=20 > with a simpler solution (except for not using IIV in IKEv2 at all). >=20 >=20 >=20 > Regards, >=20 > Valery. >=20 >=20 >=20 >=20 >=20 > From: Yoav Nir [mailto:ynir.ietf@gmail.com = ] > Sent: Tuesday, November 14, 2017 5:36 PM > To: Valery Smyslov > Cc: IPsecME WG > Subject: Re: [IPsec] Proposal for using Implicit IV for IKE >=20 >=20 >=20 > Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization = messages in 6311 all have Message ID zero and are encrypted. There do = not seem to be any cleartext bits that differentiate one such message = from another (which is why the RFC admits that they are replayable). >=20 >=20 >=20 > So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? = Drop the whole thing? Something else that I=E2=80=99m missing? >=20 >=20 >=20 > Yoav >=20 >=20 >=20 >=20 > On 13 Nov 2017, at 11:30, Valery Smyslov > wrote: >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > there is also an RFC6311, which allows messages >=20 > with the MessageID (0) to be sent over the same IKE SA >=20 > in case of cluster failover. If the IKE SA is a result of a rekey >=20 > (not IKE_SA_INIT), then its first encrypted message >=20 > will have MessageID of 0, so if failover happens later, >=20 > the MessageID of zero will repeat, breaking the security. >=20 > You should consider this case also. >=20 >=20 >=20 > Regards, >=20 > Valery. >=20 >=20 >=20 > From: IPsec [mailto:ipsec-bounces@ietf.org = ] On Behalf Of Yoav Nir > Sent: Monday, November 13, 2017 5:35 AM > To: IPsecME WG > Subject: [IPsec] Proposal for using Implicit IV for IKE >=20 >=20 >=20 > Hi. >=20 >=20 >=20 > So following Daniel=E2=80=99s message in the room, here=E2=80=99s how = I think we can make this work. >=20 >=20 >=20 > The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: >=20 > All responses have the same Message ID as the requests. > The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. > When a message is fragmented as in RFC 7383, all fragments that are = part of the same message are transmitted (and encrypted) with the same = Message ID. >=20 >=20 > Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: >=20 >=20 >=20 > Proposal #1: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >=20 >=20 >=20 > And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. >=20 >=20 >=20 > The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. >=20 >=20 >=20 > Proposal #2: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| >=20 >=20 >=20 > The Fragment Counter is the same as in the RFC 7383 fragment payload, = or zero if we are using the regular encrypted payload. >=20 >=20 >=20 > The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. >=20 >=20 >=20 > The Fragment Counter differentiates between different part of the same = message. >=20 >=20 >=20 > The Next Payload differentiates between sending a message fragmented = and sending it unfragmented. >=20 >=20 >=20 >=20 >=20 > So in summary, I think it=E2=80=99s doable and can be added to the = draft if we have consensus. >=20 >=20 >=20 > Yoav >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 --Apple-Mail=_226E6B67-67F5-4693-9306-C8C617425AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Daniel

I think your = text is confusing without the suggestion to use Message ID as a nonce. = This suggestion is not in the text, it was only in this email = thread.

So I = think the text should be (new paragraph at the end of IANA = Considerations):
   These algorithms = should be added with this document as ESP Reference and =E2=80=9CNot = Allowed=E2=80=9D for IKEv2 Reference.

This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ikev2-paramet= ers.xhtml#ikev2-parameters-5

A new document will change that.

On 15 Nov 2017, at 10:10, Daniel Migault <daniel.migault@ericsson.com> wrote:

I am more incline to have IIV for iKEv2 in = another document and as such we request the IANA to set the "IKEv2 = Reference" to UNDEFINED.

What about = the following text ?

   [RFC8247] recommends the same suites for = IKEv2.  However some IKEv2
   extensions = such as [RFC6311] or [RFC7383] allow the Message ID to be
   re-used, which is incompatible with the = uniqueness property of
   the nonce, and makes = these suites highly insecure. As a result, the suites
   defined is this document does not apply to = IKEv2. The IANA is expected to
   put = "UNDEFINED" in the column "IKEv2 Reference" for these = transforms.

Yours,
Daniel

On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov = <svanru@gmail.com> wrote:

Hi,

 

I=E2=80=99m a bit = nervous since we are trying to find a quick solution

to an apparently = not-so-easy problem in a rush time of WGLC.

 

I think we need more = time for that, so we either should

drop the IIV for IKE and = proceed with the current document

for ESP only (and = probably creating a new work item =E2=80=93 IIV for IKEv2)

or hold on the draft = until we found a solution for IKEv2 too.

 

What about the way how = to make IIV work with RFC6311, I can

imaging the following = solution. Cluster failover generally occurs

rarely, so we may not = worry about the overhead associated

with sending RFC6311 = messages. So we can introduce a combine

mode, when some messages = have implicit IV and some (e.g.RFC6311 messages)

have explicit IV. = Obviously we need to differentiate between them,

so I presume we need to = grab one of reserved bits in IKE header flags

for this purpose. I = admit it looks complicated, but I cannot come up

with a simpler solution = (except for not using IIV in IKEv2 at all).

 

Regards,

Valery.

 

 

From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent:= Tuesday, November 14, 2017 5:36 PM
To: = Valery Smyslov
Cc: IPsecME WG
Subject: Re: [IPsec] Proposal for using = Implicit IV for IKE

 

Having re-read RFC 6311, Valery=E2=80=99s right. The = synchronization messages in 6311 all have Message ID zero and are = encrypted. There do not seem to be any cleartext bits that differentiate = one such message from another (which is why the RFC admits that they are = replayable).

 

So I=E2=80= =99m kind of stuck.  Support IIV or RFC 6311 but not both?  = Drop the whole thing?  Something else that I=E2=80=99m missing?

 

Yoav



On 13 Nov = 2017, at 11:30, Valery Smyslov <svanru@gmail.com> wrote:

 

Hi,

 

there is also an = RFC6311, which allows messages

with the MessageID (0) = to be sent over the same IKE SA

in case of cluster = failover. If the IKE SA is a result of a rekey

(not IKE_SA_INIT), then = its first encrypted message

will have MessageID of = 0, so if failover happens later,

the MessageID of zero = will repeat, breaking the security.

You should consider this = case also.

 

Regards,

Valery.

 

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav= Nir
Sent: Monday, = November 13, 2017 5:35 AM
To: IPsecME = WG
Subject: [IPsec] = Proposal for using Implicit IV for IKE

 

Hi.

 

So following Daniel=E2=80=99s message = in the room, here=E2=80=99s how I think we can make this work.

 

The IKE header has a =E2=80=9CMessage ID=E2=80=9D = field that is a counter. It=E2=80=99s tempting to use this as a counter, = same as we use the replay counter in IPsec.  However, as Tero = pointed out on Jabber, each such message ID can be used several times:

  • All responses have the same Message ID as the = requests.
  • The Message ID is one sided.  The n-th request = from the original Responder has the same Message ID as the n-th request = from the original Initiator.
  • When a message is fragmented as in RFC 7383, all = fragments that are part of the same message are transmitted (and = encrypted) with the same Message ID.

 

Re-using the Message ID makes us re-use the AEAD = nonce. Not good.  Fortunately, all the algorithms that the IIV = draft mentions require an 8-octet IV while the Message ID is = 4-octet.  We can use the 32 =E2=80=9Cspare=E2=80=9D bits to = differentiate these messages.  I have two proposals for = constructing the 8-octet IV:

 

Proposal #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| 24 zero bits | Flags (8 bits) | Message ID (32 = bits)|

 

And use IIV only for regular Encrypted = Payload, not for Encrypted Fragment.  The reasoning is that if you = use fragmentation you=E2=80=99ve already solved the message-too-big = issue.

 

The Flags octet includes the = I(nitiator) and R(esponse) bits, which differentiate the cases that are = not related to fragmentation.

 

Proposal #2:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| Next Payload (8 bits) | Fragment Counter (16 bits) = | Message ID (32 bits)|

 

The Fragment Counter is the same as in the RFC 7383 = fragment payload, or zero if we are using the regular encrypted = payload.

 

The Flags octet includes the = I(nitiator) and R(esponse) bits, which differentiate the cases that are = not related to fragmentation.

 

The Fragment Counter differentiates between = different part of the same message.

 

The Next Payload differentiates between sending a = message fragmented and sending it unfragmented. 

 

 

So in summary, I think it=E2=80=99s doable and can = be added to the draft if we have consensus.

 

Yoav

 


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



= --Apple-Mail=_226E6B67-67F5-4693-9306-C8C617425AE2-- --Apple-Mail=_E7181425-B136-42F5-A176-C3408B2EB448 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloLpsIACgkQuEkLFQpY zJmaHAgAjlfXyPIRkTx1KK28NNCaTCj3Lp7ji7LJimRv8dTwP9ZIoReOgReI24t1 gYtWXSE3XZDiplVtycfwZeqJate69LwNRBWX35Mb/JYopIafSVGFlaAMUXft4car x/4tnTsnSLrWJL/yVQx2bWztISzdQ5AjH5zKPs7lD7vbE7VbjBBru9x7CAg/Z4pn G7ZSKzDmxnXKm3YuoIWyNdRAZPq4S9Cs1to64OBfk1k0nfEyMCDeBSuYpzKP0t9q tdO9vkHVsMJwChlN5lVpjntfTDYeBSYBORV7a/XLSNJxfiDccdbPelkEzHapQ5ZX zgBBv3Tx6aPMZaPBzBe6MYGJNOiUOQ== =9EqC -----END PGP SIGNATURE----- --Apple-Mail=_E7181425-B136-42F5-A176-C3408B2EB448-- From nobody Tue Nov 14 18:40:09 2017 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 BC0E4120724 for ; Tue, 14 Nov 2017 18:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j75xHL3peL2 for ; Tue, 14 Nov 2017 18:40:04 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B063E1201F2 for ; Tue, 14 Nov 2017 18:40:04 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id r62so3338402pfd.5 for ; Tue, 14 Nov 2017 18:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UfmCHUSQmKYp0nEOuM7Z0rmmgBSJkd+qEFvoPK0A7co=; b=ZzxhsfvGiZV821d6RwFbQhNMZhaB+UWGiNUXRUsDMH4W/FH5T6kCaScNEZqh2F8uv7 ziPeTNTQzYAB3Wg0r1ALSxggjhwHjcpHjV4/LhNxiXM8B9lwu2kG6ZyJXdMU7SeEZdYG ZI6as/62axsK+/5UkoRvUc3tJdtzz4Z/GWYyn9wckKOIp0SRAdNFMyNucnxhKmnHomQY JRiL79TQ40FJeIJ6AZVkZ5HJJugJo7m44whb7vDkJVWzkSSzMDqEgM3sGi1mxudTF/vd NsLsgq9NxbhOYYoH5PqKbmdSz3vfYkWwfsGqOAQEECTGQmC1CK0aa9FTuT1EsS6Bsofy girg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UfmCHUSQmKYp0nEOuM7Z0rmmgBSJkd+qEFvoPK0A7co=; b=csOKD00j9ADqbhGdAxOCjhSIVpoMSwhyuCFxh1Erg7hrXweArHlkRa9kfsFn6Jm+9S 29ZAV6ngIn8o73JLCOTFasxz3bM94+bdq98Nv1r1fiI+qYSXg22go7kRSV0rYh1B+QQB DkcmfkkN43RTOH38y8E8/5TU5mzRPsRJyr9LZ+3B7ejJoIXd8ra/6JuVfWkKBRYwl69A fO1B6b9L2emSg4KAWCFHWPsjvE0qalerizLbHBnyFfGSn3nXsZHikn7m39torRtI1779 TYXQ0GYjbcmWl8KPBppdH1yGMipLQPNF32kdv4Pf5JH+XvLeceB+/7T/ya2kGPga03NE dOcw== X-Gm-Message-State: AJaThX7oEW5elNHJIqO3vMkdVd8Qu8xeusV6Rt9qdcwClwd6CD7Gr/07 ZQuE5nohV/liyJdxPv3XK50ybzCH X-Google-Smtp-Source: AGs4zMYoTkAbfdRYdfY7yjFaTyjMc6kaJS9NRKO/YK7e5kWvxjYlNhJZyXtXFqCsljDJa0pk3QatLw== X-Received: by 10.84.224.202 with SMTP id k10mr14406726pln.403.1510713604338; Tue, 14 Nov 2017 18:40:04 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:11b9:4fe2:bb8c:6524? ([2001:67c:370:128:11b9:4fe2:bb8c:6524]) by smtp.gmail.com with ESMTPSA id a87sm18985921pfg.159.2017.11.14.18.40.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 18:40:03 -0800 (PST) From: Yoav Nir Message-Id: <0E332181-1DDD-4984-B84E-1852056BA1D4@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_565DA060-EECA-4AF3-8526-DB5FD0EB4CB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Wed, 15 Nov 2017 10:40:20 +0800 In-Reply-To: <7073D6DB-2C7E-4B0F-AF97-BD477458443E@gmail.com> Cc: Valery Smyslov , IPsecME WG To: Daniel Migault References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> <7073D6DB-2C7E-4B0F-AF97-BD477458443E@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:40:08 -0000 --Apple-Mail=_565DA060-EECA-4AF3-8526-DB5FD0EB4CB4 Content-Type: multipart/alternative; boundary="Apple-Mail=_284689F2-0260-468D-98FF-1D58D352C0A7" --Apple-Mail=_284689F2-0260-468D-98FF-1D58D352C0A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oh, and if you=E2=80=99re updating the draft anyway, you should update = the references now that 8221 and 8247 have been published. Yoav > On 15 Nov 2017, at 10:30, Yoav Nir wrote: >=20 > Hi, Daniel >=20 > I think your text is confusing without the suggestion to use Message = ID as a nonce. This suggestion is not in the text, it was only in this = email thread. >=20 > So I think the text should be (new paragraph at the end of IANA = Considerations): > These algorithms should be added with this document as ESP = Reference and =E2=80=9CNot Allowed=E2=80=9D for IKEv2 Reference. >=20 > This seems fitting for = https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#i= kev2-parameters-5 = >=20 > A new document will change that. >=20 >> On 15 Nov 2017, at 10:10, Daniel Migault > wrote: >>=20 >> I am more incline to have IIV for iKEv2 in another document and as = such we request the IANA to set the "IKEv2 Reference" to UNDEFINED. >>=20 >> What about the following text ? >>=20 >> [RFC8247] recommends the same suites for IKEv2. However some = IKEv2 >> extensions such as [RFC6311] or [RFC7383] allow the Message ID to = be >> re-used, which is incompatible with the uniqueness property of >> the nonce, and makes these suites highly insecure. As a result, = the suites >> defined is this document does not apply to IKEv2. The IANA is = expected to >> put "UNDEFINED" in the column "IKEv2 Reference" for these = transforms. >>=20 >> Yours, >> Daniel >>=20 >> On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov > wrote: >> Hi, >>=20 >>=20 >>=20 >> I=E2=80=99m a bit nervous since we are trying to find a quick = solution >>=20 >> to an apparently not-so-easy problem in a rush time of WGLC. >>=20 >>=20 >>=20 >> I think we need more time for that, so we either should >>=20 >> drop the IIV for IKE and proceed with the current document >>=20 >> for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2) >>=20 >> or hold on the draft until we found a solution for IKEv2 too. >>=20 >>=20 >>=20 >> What about the way how to make IIV work with RFC6311, I can >>=20 >> imaging the following solution. Cluster failover generally occurs >>=20 >> rarely, so we may not worry about the overhead associated >>=20 >> with sending RFC6311 messages. So we can introduce a combine >>=20 >> mode, when some messages have implicit IV and some (e.g.RFC6311 = messages) >>=20 >> have explicit IV. Obviously we need to differentiate between them, >>=20 >> so I presume we need to grab one of reserved bits in IKE header flags >>=20 >> for this purpose. I admit it looks complicated, but I cannot come up >>=20 >> with a simpler solution (except for not using IIV in IKEv2 at all). >>=20 >>=20 >>=20 >> Regards, >>=20 >> Valery. >>=20 >>=20 >>=20 >>=20 >>=20 >> From: Yoav Nir [mailto:ynir.ietf@gmail.com = ] >> Sent: Tuesday, November 14, 2017 5:36 PM >> To: Valery Smyslov >> Cc: IPsecME WG >> Subject: Re: [IPsec] Proposal for using Implicit IV for IKE >>=20 >>=20 >>=20 >> Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization = messages in 6311 all have Message ID zero and are encrypted. There do = not seem to be any cleartext bits that differentiate one such message = from another (which is why the RFC admits that they are replayable). >>=20 >>=20 >>=20 >> So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? = Drop the whole thing? Something else that I=E2=80=99m missing? >>=20 >>=20 >>=20 >> Yoav >>=20 >>=20 >>=20 >>=20 >> On 13 Nov 2017, at 11:30, Valery Smyslov > wrote: >>=20 >>=20 >>=20 >> Hi, >>=20 >>=20 >>=20 >> there is also an RFC6311, which allows messages >>=20 >> with the MessageID (0) to be sent over the same IKE SA >>=20 >> in case of cluster failover. If the IKE SA is a result of a rekey >>=20 >> (not IKE_SA_INIT), then its first encrypted message >>=20 >> will have MessageID of 0, so if failover happens later, >>=20 >> the MessageID of zero will repeat, breaking the security. >>=20 >> You should consider this case also. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Valery. >>=20 >>=20 >>=20 >> From: IPsec [mailto:ipsec-bounces@ietf.org = ] On Behalf Of Yoav Nir >> Sent: Monday, November 13, 2017 5:35 AM >> To: IPsecME WG >> Subject: [IPsec] Proposal for using Implicit IV for IKE >>=20 >>=20 >>=20 >> Hi. >>=20 >>=20 >>=20 >> So following Daniel=E2=80=99s message in the room, here=E2=80=99s how = I think we can make this work. >>=20 >>=20 >>=20 >> The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a = counter. It=E2=80=99s tempting to use this as a counter, same as we use = the replay counter in IPsec. However, as Tero pointed out on Jabber, = each such message ID can be used several times: >>=20 >> All responses have the same Message ID as the requests. >> The Message ID is one sided. The n-th request from the original = Responder has the same Message ID as the n-th request from the original = Initiator. >> When a message is fragmented as in RFC 7383, all fragments that are = part of the same message are transmitted (and encrypted) with the same = Message ID. >>=20 >>=20 >> Re-using the Message ID makes us re-use the AEAD nonce. Not good. = Fortunately, all the algorithms that the IIV draft mentions require an = 8-octet IV while the Message ID is 4-octet. We can use the 32 = =E2=80=9Cspare=E2=80=9D bits to differentiate these messages. I have = two proposals for constructing the 8-octet IV: >>=20 >>=20 >>=20 >> Proposal #1: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >>=20 >>=20 >>=20 >> And use IIV only for regular Encrypted Payload, not for Encrypted = Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve = already solved the message-too-big issue. >>=20 >>=20 >>=20 >> The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. >>=20 >>=20 >>=20 >> Proposal #2: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 = bits)| >>=20 >>=20 >>=20 >> The Fragment Counter is the same as in the RFC 7383 fragment payload, = or zero if we are using the regular encrypted payload. >>=20 >>=20 >>=20 >> The Flags octet includes the I(nitiator) and R(esponse) bits, which = differentiate the cases that are not related to fragmentation. >>=20 >>=20 >>=20 >> The Fragment Counter differentiates between different part of the = same message. >>=20 >>=20 >>=20 >> The Next Payload differentiates between sending a message fragmented = and sending it unfragmented. >>=20 >>=20 >>=20 >>=20 >>=20 >> So in summary, I think it=E2=80=99s doable and can be added to the = draft if we have consensus. >>=20 >>=20 >>=20 >> Yoav >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >>=20 >>=20 >=20 --Apple-Mail=_284689F2-0260-468D-98FF-1D58D352C0A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oh, = and if you=E2=80=99re updating the draft anyway, you should update the = references now that 8221 and 8247 have been published.

Yoav

On 15 = Nov 2017, at 10:30, Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi, Daniel

I think your text is = confusing without the suggestion to use Message ID as a nonce. This = suggestion is not in the text, it was only in this email = thread.

So I = think the text should be (new paragraph at the end of IANA = Considerations):
   These algorithms = should be added with this document as ESP Reference and =E2=80=9CNot = Allowed=E2=80=9D for IKEv2 Reference.

This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ikev2-paramet= ers.xhtml#ikev2-parameters-5

A new document will change that.

On 15 Nov 2017, at 10:10, Daniel Migault = <daniel.migault@ericsson.com> wrote:

I am more incline to have IIV for iKEv2 in = another document and as such we request the IANA to set the "IKEv2 = Reference" to UNDEFINED.

What about = the following text ?

   [RFC8247] recommends the same suites for = IKEv2.  However some IKEv2
   extensions = such as [RFC6311] or [RFC7383] allow the Message ID to be
   re-used, which is incompatible with the = uniqueness property of
   the nonce, and makes = these suites highly insecure. As a result, the suites
   defined is this document does not apply to = IKEv2. The IANA is expected to
   put = "UNDEFINED" in the column "IKEv2 Reference" for these = transforms.

Yours,
Daniel

On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov = <svanru@gmail.com> wrote:

Hi,

 

I=E2=80=99m a bit = nervous since we are trying to find a quick solution

to an apparently = not-so-easy problem in a rush time of WGLC.

 

I think we need more = time for that, so we either should

drop the IIV for IKE and = proceed with the current document

for ESP only (and = probably creating a new work item =E2=80=93 IIV for IKEv2)

or hold on the draft = until we found a solution for IKEv2 too.

 

What about the way how = to make IIV work with RFC6311, I can

imaging the following = solution. Cluster failover generally occurs

rarely, so we may not = worry about the overhead associated

with sending RFC6311 = messages. So we can introduce a combine

mode, when some messages = have implicit IV and some (e.g.RFC6311 messages)

have explicit IV. = Obviously we need to differentiate between them,

so I presume we need to = grab one of reserved bits in IKE header flags

for this purpose. I = admit it looks complicated, but I cannot come up

with a simpler solution = (except for not using IIV in IKEv2 at all).

 

Regards,

Valery.

 

 

From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent:= Tuesday, November 14, 2017 5:36 PM
To: = Valery Smyslov
Cc: IPsecME WG
Subject: Re: [IPsec] Proposal for using = Implicit IV for IKE

 

Having re-read RFC 6311, Valery=E2=80=99s right. The = synchronization messages in 6311 all have Message ID zero and are = encrypted. There do not seem to be any cleartext bits that differentiate = one such message from another (which is why the RFC admits that they are = replayable).

 

So I=E2=80= =99m kind of stuck.  Support IIV or RFC 6311 but not both?  = Drop the whole thing?  Something else that I=E2=80=99m missing?

 

Yoav



On 13 Nov = 2017, at 11:30, Valery Smyslov <svanru@gmail.com> wrote:

 

Hi,

 

there is also an = RFC6311, which allows messages

with the MessageID (0) = to be sent over the same IKE SA

in case of cluster = failover. If the IKE SA is a result of a rekey

(not IKE_SA_INIT), then = its first encrypted message

will have MessageID of = 0, so if failover happens later,

the MessageID of zero = will repeat, breaking the security.

You should consider this = case also.

 

Regards,

Valery.

 

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav= Nir
Sent: Monday, = November 13, 2017 5:35 AM
To: IPsecME = WG
Subject: [IPsec] = Proposal for using Implicit IV for IKE

 

Hi.

 

So following Daniel=E2=80=99s message = in the room, here=E2=80=99s how I think we can make this work.

 

The IKE header has a =E2=80=9CMessage ID=E2=80=9D = field that is a counter. It=E2=80=99s tempting to use this as a counter, = same as we use the replay counter in IPsec.  However, as Tero = pointed out on Jabber, each such message ID can be used several times:

  • All responses have the same Message ID as the = requests.
  • The Message ID is one sided.  The n-th request = from the original Responder has the same Message ID as the n-th request = from the original Initiator.
  • When a message is fragmented as in RFC 7383, all = fragments that are part of the same message are transmitted (and = encrypted) with the same Message ID.

 

Re-using the Message ID makes us re-use the AEAD = nonce. Not good.  Fortunately, all the algorithms that the IIV = draft mentions require an 8-octet IV while the Message ID is = 4-octet.  We can use the 32 =E2=80=9Cspare=E2=80=9D bits to = differentiate these messages.  I have two proposals for = constructing the 8-octet IV:

 

Proposal #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| 24 zero bits | Flags (8 bits) | Message ID (32 = bits)|

 

And use IIV only for regular Encrypted = Payload, not for Encrypted Fragment.  The reasoning is that if you = use fragmentation you=E2=80=99ve already solved the message-too-big = issue.

 

The Flags octet includes the = I(nitiator) and R(esponse) bits, which differentiate the cases that are = not related to fragmentation.

 

Proposal #2:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| Next Payload (8 bits) | Fragment Counter (16 bits) = | Message ID (32 bits)|

 

The Fragment Counter is the same as in the RFC 7383 = fragment payload, or zero if we are using the regular encrypted = payload.

 

The Flags octet includes the = I(nitiator) and R(esponse) bits, which differentiate the cases that are = not related to fragmentation.

 

The Fragment Counter differentiates between = different part of the same message.

 

The Next Payload differentiates between sending a = message fragmented and sending it unfragmented. 

 

 

So in summary, I think it=E2=80=99s doable and can = be added to the draft if we have consensus.

 

Yoav

 


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




= --Apple-Mail=_284689F2-0260-468D-98FF-1D58D352C0A7-- --Apple-Mail=_565DA060-EECA-4AF3-8526-DB5FD0EB4CB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloLqRQACgkQuEkLFQpY zJlg6wf/YvicgGNhCK7hFfbIPTOIfXSdvqVo0+LRI0ZfgQEOTq9iHExmkxZnVMIw V3Ocj5WXr1DQKfq5ld1N15rMtDIfYkOcYMiGpMq4zUkOc8qbA8tNEV0duC+6Rg0k l7CnliKXfXJe4h1ARMLPTJly3DPMC5EZOk0BgrvTLxacXxmpQrT0F218yR0zfDWB XM0GYG8uZJp4mTyZQsrv5sd/MpAmHskWIPGilBtddgze2gGAKA9VOJWIf1hHctju f5iPml700+bGsLSxjA/7tnmMQKvpGZeo3b58iqRKgrECLK0YKdicBPo5Jcic1XoS NsoC2q64PzDJ//MzXappy1y9emfU9g== =C5hT -----END PGP SIGNATURE----- --Apple-Mail=_565DA060-EECA-4AF3-8526-DB5FD0EB4CB4-- From nobody Tue Nov 14 19:20:48 2017 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 29DC71201F2 for ; Tue, 14 Nov 2017 19:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjrWq-1IMbWv for ; Tue, 14 Nov 2017 19:20:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 452511252BA for ; Tue, 14 Nov 2017 19:20:45 -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 vAF3KVbg008273 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Nov 2017 05:20:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vAF3KQLA014023; Wed, 15 Nov 2017 05:20:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23051.45690.505582.429019@fireball.acr.fi> Date: Wed, 15 Nov 2017 05:20:26 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Paul Wouters'" , , "'Sahana Prasad'" In-Reply-To: <02fc01d35d28$3c712780$b5537680$@gmail.com> References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> <23050.39852.520962.719946@fireball.acr.fi> <02ec01d35d21$5ea60980$1bf21c80$@gmail.com> <23050.45054.267720.174818@fireball.acr.fi> <02fc01d35d28$3c712780$b5537680$@gmail.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: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:20:47 -0000 Valery Smyslov writes: > > Why would you make multiple encodings formats for the same algorithm? > > And if so why should we allow that in IPsec. We do not allow prehashed > > formats of the Ed25519 and Ed448 because we do not want to have > > multiple formats for the same thing. > > If tomorrow cryptographers discover some weakness in one encoding > and start recommend using another format, then we'll have to follow. > And it doesn't matter if we disallowed using it before. In such case you do create a new key, and you do disable the old format, so there is no issue with this, as you still have only one format for a key. > > > The only reliable way for the initiator to select a proper form of signature > > > now is pre-configuration. But it doesn't scale well and is problematic > > > with opportunistic encryption. > > > > It is same with PSKs or IP addresses / DNS names. You need to > > pre-configure the PSK to be used and to which IP address (or DNS name) > > to connect... IPsec normally do require some pre-configuration before > > it can be used (with exception to the opportunistic encryption). > > Some pre-configuration is inevitable. But let's try to keep it minimal - > it helps maintain algorithm agility in large scale. Yes, but configuring the authentication credentials (PSK, or private key to be used) for each remote host is something that I do expect to be done in future too. -- kivinen@iki.fi From nobody Tue Nov 14 19:47:36 2017 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 C1421126C22 for ; Tue, 14 Nov 2017 19:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSZJavxzeLL8 for ; Tue, 14 Nov 2017 19:47:23 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 4E972127522 for ; Tue, 14 Nov 2017 19:47:21 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id k66so12595593lfg.3 for ; Tue, 14 Nov 2017 19:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+XoWBIdlRTfgsenZfi2LSP3SaPG0rhq5Bp/som/lpt4=; b=BZ528wXJ9zdzIl4roHzm3Z/VAP5kO2RKcbGhnUN/9GS0oyQCrY3XLybhwhV7WiAwSY j+5qSd4dNfOy86shoDZ1BVCGjKYCwmGBEhbAeDObzrI9H47lpNbVUNnRIMZDVh9m6/Hu c1/K5mBxl5l3F4JJZRnPqxBi0ueao+OKCJQDktr7wInjTJn+pWYk91V6mnMgvIsftWSv gN0ALlANQaQWPUVKWUFUIsVf5/tcnIbOk/VgXYQBl6XOhsKE6V0UHbed5eIYzLxu1kHF 1WQLuMxV6iGl+YL7XrkpmWLwyJMiQh8OJOynvkbTJYIkxlRBv38TSvcg6LjzdJh9GXmz OUyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+XoWBIdlRTfgsenZfi2LSP3SaPG0rhq5Bp/som/lpt4=; b=EForkP8h2oF5lPzLCjqDx4aPkgSgG2MKHKP6thdrb8n7qI/WcVn8xGSEIfwO+nCpTb dM8rU1iA2CXGuA4cDHBl3fpfAmmqZo19u7+f+POCnUKczwthLeLuieYrpHt7sGC2Q7Ek HL8+fapA9vURIEZifZZMp27BGB3MkTL71Y7hlv3COvrH7P3K7gEoi+17jLmV4WuBq2pB 0Rg7PQaDcFaWfivDVN4h9I9arQdsoFF0+W868fUS0BLtDodcpMu/dp01KdD7wQVNBBZe yhbbhqluHQ6pS0Po1SFZRZecGH7AQX77LZZ0IAsN2iTNstVhQaoWm3dwp0jNaRPxSJVU g3cw== X-Gm-Message-State: AJaThX6Ycz43DCNREKn+PKV6Wev4mlxznCZ4qTU0W0T0TZe+fl+4vFV4 MQL+CqPg3ohQ7Br1ACN1S7fFBRKVpyDsmtCxr3A= X-Google-Smtp-Source: AGs4zMYEnXyYVDSPAf8aZxCKSDeEVNI0mslBtU79qp/Ei3a7imbm/tIwweOK3TKEaF01NGys4Cb+CEzfQXN4Tvq1wQg= X-Received: by 10.25.15.73 with SMTP id e70mr4187376lfi.64.1510717639600; Tue, 14 Nov 2017 19:47:19 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.82.218 with HTTP; Tue, 14 Nov 2017 19:47:18 -0800 (PST) In-Reply-To: <7073D6DB-2C7E-4B0F-AF97-BD477458443E@gmail.com> References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> <7073D6DB-2C7E-4B0F-AF97-BD477458443E@gmail.com> From: Daniel Migault Date: Tue, 14 Nov 2017 22:47:18 -0500 X-Google-Sender-Auth: 3oXB0WsIP3072B4I5rO2ydZUAps Message-ID: To: Yoav Nir Cc: IPsecME WG , Valery Smyslov Content-Type: multipart/alternative; boundary="001a113fb94843aed6055dfd5cdc" Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:47:24 -0000 --001a113fb94843aed6055dfd5cdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree. I will also make sure the the text make it sure the document is only on ESP. I believe the confusion --- and the clarification! came from citing the IKEv2 recommendations. So I intend to make explicit in the abstract / intro, we only address ESP. Yours, Daniel On Tue, Nov 14, 2017 at 9:30 PM, Yoav Nir wrote: > Hi, Daniel > > I think your text is confusing without the suggestion to use Message ID a= s > a nonce. This suggestion is not in the text, it was only in this email > thread. > > So I think the text should be (new paragraph at the end of IANA > Considerations): > These algorithms should be added with this document as ESP Reference > and =E2=80=9CNot Allowed=E2=80=9D for IKEv2 Reference. > > This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ > ikev2-parameters.xhtml#ikev2-parameters-5 > > A new document will change that. > > > On 15 Nov 2017, at 10:10, Daniel Migault > wrote: > > I am more incline to have IIV for iKEv2 in another document and as such w= e > request the IANA to set the "IKEv2 Reference" to UNDEFINED. > > What about the following text ? > > [RFC8247] recommends the same suites for IKEv2. However some IKEv2 > extensions such as [RFC6311] or [RFC7383] allow the Message ID to be > re-used, which is incompatible with the uniqueness property of > the nonce, and makes these suites highly insecure. As a result, the > suites > defined is this document does not apply to IKEv2. The IANA is expected > to > put "UNDEFINED" in the column "IKEv2 Reference" for these transforms. > > Yours, > Daniel > > On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov wrote: > >> Hi, >> >> >> >> I=E2=80=99m a bit nervous since we are trying to find a quick solution >> >> to an apparently not-so-easy problem in a rush time of WGLC. >> >> >> >> I think we need more time for that, so we either should >> >> drop the IIV for IKE and proceed with the current document >> >> for ESP only (and probably creating a new work item =E2=80=93 IIV for IK= Ev2) >> >> or hold on the draft until we found a solution for IKEv2 too. >> >> >> >> What about the way how to make IIV work with RFC6311, I can >> >> imaging the following solution. Cluster failover generally occurs >> >> rarely, so we may not worry about the overhead associated >> >> with sending RFC6311 messages. So we can introduce a combine >> >> mode, when some messages have implicit IV and some (e.g.RFC6311 messages= ) >> >> have explicit IV. Obviously we need to differentiate between them, >> >> so I presume we need to grab one of reserved bits in IKE header flags >> >> for this purpose. I admit it looks complicated, but I cannot come up >> >> with a simpler solution (except for not using IIV in IKEv2 at all). >> >> >> >> Regards, >> >> Valery. >> >> >> >> >> >> *From:* Yoav Nir [mailto:ynir.ietf@gmail.com] >> *Sent:* Tuesday, November 14, 2017 5:36 PM >> *To:* Valery Smyslov >> *Cc:* IPsecME WG >> *Subject:* Re: [IPsec] Proposal for using Implicit IV for IKE >> >> >> >> Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization mes= sages in >> 6311 all have Message ID zero and are encrypted. There do not seem to be >> any cleartext bits that differentiate one such message from another (whi= ch >> is why the RFC admits that they are replayable). >> >> >> >> So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? Dr= op the >> whole thing? Something else that I=E2=80=99m missing? >> >> >> >> Yoav >> >> >> >> On 13 Nov 2017, at 11:30, Valery Smyslov wrote: >> >> >> >> Hi, >> >> >> >> there is also an RFC6311, which allows messages >> >> with the MessageID (0) to be sent over the same IKE SA >> >> in case of cluster failover. If the IKE SA is a result of a rekey >> >> (not IKE_SA_INIT), then its first encrypted message >> >> will have MessageID of 0, so if failover happens later, >> >> the MessageID of zero will repeat, breaking the security. >> >> You should consider this case also. >> >> >> >> Regards, >> >> Valery. >> >> >> >> *From:* IPsec [mailto:ipsec-bounces@ietf.org ] *= On >> Behalf Of *Yoav Nir >> *Sent:* Monday, November 13, 2017 5:35 AM >> *To:* IPsecME WG >> *Subject:* [IPsec] Proposal for using Implicit IV for IKE >> >> >> >> Hi. >> >> >> >> So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make >> this work. >> >> >> >> The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a counte= r. It=E2=80=99s tempting >> to use this as a counter, same as we use the replay counter in IPsec. >> However, as Tero pointed out on Jabber, each such message ID can be used >> several times: >> >> - All responses have the same Message ID as the requests. >> - The Message ID is one sided. The n-th request from the original >> Responder has the same Message ID as the n-th request from the origin= al >> Initiator. >> - When a message is fragmented as in RFC 7383, all fragments that are >> part of the same message are transmitted (and encrypted) with the sam= e >> Message ID. >> >> >> >> Re-using the Message ID makes us re-use the AEAD nonce. Not good. >> Fortunately, all the algorithms that the IIV draft mentions require an >> 8-octet IV while the Message ID is 4-octet. We can use the 32 =E2=80=9C= spare=E2=80=9D bits >> to differentiate these messages. I have two proposals for constructing = the >> 8-octet IV: >> >> >> >> Proposal #1: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >> >> >> >> And use IIV only for regular Encrypted Payload, not for Encrypted >> Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve= already >> solved the message-too-big issue. >> >> >> >> The Flags octet includes the I(nitiator) and R(esponse) bits, which >> differentiate the cases that are not related to fragmentation. >> >> >> >> Proposal #2: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 >> bits)| >> >> >> >> The Fragment Counter is the same as in the RFC 7383 fragment payload, or >> zero if we are using the regular encrypted payload. >> >> >> >> The Flags octet includes the I(nitiator) and R(esponse) bits, which >> differentiate the cases that are not related to fragmentation. >> >> >> >> The Fragment Counter differentiates between different part of the same >> message. >> >> >> >> The Next Payload differentiates between sending a message fragmented and >> sending it unfragmented. >> >> >> >> >> >> So in summary, I think it=E2=80=99s doable and can be added to the draft= if we >> have consensus. >> >> >> >> Yoav >> >> >> >> _______________________________________________ >> 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 > > --001a113fb94843aed6055dfd5cdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. I will also make sure the the text make= it sure the document is only on ESP. I believe the confusion --- and the c= larification!=C2=A0 came from citing the IKEv2 recommendations. So I intend= to make explicit in the abstract / intro, we only address ESP.

Yours,
Daniel

On Tue, Nov 14, 2017 at 9:30 PM, Yoav Nir <ynir.ietf@g= mail.com> wrote:
Hi, Daniel
I think your text is confusing without the suggestion to use Me= ssage ID as a nonce. This suggestion is not in the text, it was only in thi= s email thread.

So I think the text should be (new= paragraph at the end of IANA Considerations):
=C2=A0 =C2=A0These= algorithms should be added with this document as ESP Reference and =E2=80= =9CNot Allowed=E2=80=9D for IKEv2 Reference.


A new document will= change that.


=
On 15 Nov 2017, at 10:10, Daniel Migault <daniel.migault@ericsson.com>= wrote:

<= div>
I am more incline to have IIV for iKEv2 in anothe= r document and as such we request the IANA to set the "IKEv2 Reference= " to UNDEFINED.

What about the following text ?
=
=C2=A0=C2=A0 [RFC8247] recommends the same suites for IKEv2.=C2=A0 Howe= ver some IKEv2
=C2=A0=C2=A0 extensions such as [RFC6311] or [RFC7383] al= low the Message ID to be
=C2=A0=C2=A0 re-used, which is incompatible wit= h the uniqueness property of
=C2=A0=C2=A0 the nonce, and makes these sui= tes highly insecure. As a result, the suites
=C2=A0=C2=A0 defined is thi= s document does not apply to IKEv2. The IANA is expected to
=C2=A0=C2= =A0 put "UNDEFINED" in the column "IKEv2 Reference" for= these transforms.

Yours,
Daniel

On T= ue, Nov 14, 2017 at 8:42 PM, Valery Smyslov <svanru@gmail.com> wrote:
Hi,

=C2=A0

I=E2=80=99m a bit nervous since we are trying to= find a quick solution

to an apparently not-so-easy problem i= n a rush time of WGLC.

=C2=A0

I think we need m= ore time for that, so we either should

drop the IIV for IKE = and proceed with the current document

for ESP only (and proba= bly creating a new work item =E2=80=93 IIV for IKEv2)<= /p>

or hold= on the draft until we found a solution for IKEv2 too.=

=C2=A0

What about the way how to make IIV work with RFC6311, I can<= u>

imaging the following solution. Cluster failover generally oc= curs

rarely, so we may not worry about the overhead associate= d

with sending RFC6311 messages. So we can introduce a combin= e

mode, when some messages have implicit IV and some (e.g.RFC= 6311 messages)

have explicit IV. Obviously we need to diffe= rentiate between them,

so I presume we need to grab one of re= served bits in IKE header flags

for this purpose. I admit it = looks complicated, but I cannot come up

with a simpler soluti= on (except for not using IIV in IKEv2 at all).

=C2=A0<= u>

Regards,

Valery.

=C2=A0

<= u>=C2=A0

<= b>From: Yo= av Nir [mailto:yni= r.ietf@gmail.com]
Sent: Tuesday, November 14, 2017 5:36 PMTo: Valery Smyslov
Cc: IPsecME WG
Subject: Re:= [IPsec] Proposal for using Implicit IV for IKE

=C2=A0

Having re-read RFC 6311, Va= lery=E2=80=99s right. The synchronization messages in 6311 all have Message= ID zero and are encrypted. There do not seem to be any cleartext bits that= differentiate one such message from another (which is why the RFC admits t= hat they are replayable).

<= /u>=C2=A0

So I=E2=80=99m kind o= f stuck.=C2=A0 Support IIV or RFC 6311 but not both?=C2=A0 Drop the whole t= hing?=C2=A0 Something else that I=E2=80=99m missing?

=C2=A0

Yoav



On 13 Nov 2017, at 11:30, Valery S= myslov <svanru@gma= il.com> wrote:

= =C2=A0

Hi,

=C2=A0

there is also an RFC6311, which allows messages

=

with the MessageID (0) to be sent over the same IKE SA

in case of cluster failover. If the IKE SA is a result of a rekey

(not IKE_SA_INIT), then its first encrypted message

will have MessageID of 0, so if failover happens la= ter,

the MessageID of zero will repeat, breaking = the security.

You should consider this case also.<= /span>

=C2=A0

Regards,=

Valery.

=C2=A0

From:=C2=A0IPsec [mailto:ipsec-bounces@ietf.org]=C2= =A0On Behalf Of=C2=A0Yoav Nir
Sent:=C2=A0Monday, November 13, 2017 5:35 AM
To:=C2=A0IPsecME WG
Subject:=C2=A0[IPsec] Proposal for usi= ng Implicit IV for IKE

=C2=A0

Hi.

=C2=A0

So following Daniel=E2=80=99s message in the room, here=E2=80=99s = how I think we can make this work.

<= p class=3D"MsoNormal">=C2=A0

The IKE header has a =E2=80=9CMessage ID=E2=80=9D field tha= t is a counter. It=E2=80=99s tempting to use this as a counter, same as we = use the replay counter in IPsec.=C2=A0 However, as Tero pointed out on Jabb= er, each such message ID can be used several times:

=
  • All responses have the same Message ID as the requests.
  • The Message ID is one sided.=C2=A0 The n-th reque= st from the original Responder has the same Message ID as the n-th request = from the original Initiator.
  • When= a message is fragmented as in RFC 7383, all fragments that are part of the= same message are transmitted (and encrypted) with the same Message ID.<= /u>

=C2=A0

Re-using the Message I= D makes us re-use the AEAD nonce. Not good.=C2=A0 Fortunately, all the algo= rithms that the IIV draft mentions require an 8-octet IV while the Message = ID is 4-octet.=C2=A0 We can use the 32 =E2=80=9Cspare=E2=80=9D bits to diff= erentiate these messages.=C2=A0 I have two proposals for constructing the 8= -octet IV:

= =C2=A0

Propos= al #1:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

| 24 zero bits | Flags (8 bits) | Message ID (32 bits)|<= u>

=C2=A0=

And use IIV only for regul= ar Encrypted Payload, not for Encrypted Fragment.=C2=A0 The reasoning is th= at if you use fragmentation you=E2=80=99ve already solved the message-too-b= ig issue.

=C2= =A0

The Flags= octet includes the I(nitiator) and R(esponse) bits, which differentiate th= e cases that are not related to fragmentation.

=C2=A0

=

Proposal #2:

=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| Next Payload (8 bits) | Fra= gment Counter (16 bits) | Message ID (32 bits)|

=C2=A0

The Fragment Counter is the same as in the RFC= 7383 fragment payload, or zero if we are using the regular encrypted paylo= ad.

=C2=A0=

The Flags octet= includes the I(nitiator) and R(esponse) bits, which differentiate the case= s that are not related to fragmentation.

=

=C2=A0

<= p class=3D"MsoNormal">The Fragment Counter differentiates between different= part of the same message.

=C2=A0

The Next Payload differentiates between sending a message fragment= ed and sending it unfragmented.=C2=A0

=C2=A0

=C2=A0

So in summary, I think it=E2=80=99s doable and can be added = to the draft if we have consensus.

<= p class=3D"MsoNormal">=C2=A0

Yoav

=C2=A0


_______________________________________________
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


--001a113fb94843aed6055dfd5cdc-- From nobody Tue Nov 14 19:49:51 2017 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 30893127522 for ; Tue, 14 Nov 2017 19:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr7Lfi-MmODL for ; Tue, 14 Nov 2017 19:49:46 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F80126CBF for ; Tue, 14 Nov 2017 19:49:45 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id o41so815385lfi.2 for ; Tue, 14 Nov 2017 19:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VqZ/toVuqzAjm3lLkw4pR/+Lt9qtt8rduRkIih/7Gkw=; b=NMjxVtgQ3RJsPrONBpE+jnnlI/pMjtfoC+bPHFaPxFmSAEH1lYk+J4K4isHpmaIs7A AwWv+W98XsBXqWz/MNsJkeC47wAYo+XvHUE+uIbCYBN9ZBjKGDXyMpx+tNB9z8vPg98/ ICCTpruWiQrNfthLEDfs6/gdJWz3XQ8t+YtWDTL3lEgcz6KEov8Xc6cRyoX/Pksi05CQ 0lvt1EZRyXSNQHpOPNNgeFN6StHDEErP/aiqMahiywVkF7maa8mFnw7IYX5AgolLfjIu 850Inx+w1dfDIp1M9Dtp/IFqRdK79NfWLVHFMtZ77c5PxvOsTftHZn4VXO5n9HxI1V6R 1EMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VqZ/toVuqzAjm3lLkw4pR/+Lt9qtt8rduRkIih/7Gkw=; b=MrJdR83JthHJgU7Guuz8N0ReE2nBhnJ6/flFLS1UHQGhG4wVuRaqajHXOjDODGpQs8 0HmFCiFlik/MocfizPCJUhxclEtbzJZRsaYHpDyE0FUZh02MQSdc9HM38bv9Q5iiUPFF Rdgnx384GyeFwsfK5ctvZu/JiBUaeChPSs/LMAcdFBnlIb401ehpAWtJOa2uHmkaXoCR /I+JlcTaUN9UdQcOIvtX1luXcz0ZCw/gMcBtUX2MmYhkjpD6fojkvsl8WJXgGW7bilCs uONM/h2aNAS6xrfHzs8CxuB9p3pB/cMUUlGxYXys+n3zVLRDnBNgXs35OU8DUEVgaNCQ ogbg== X-Gm-Message-State: AJaThX6YtGfRo9xyn/7pU0jOzBZBx7KZ7cEQERG/PwAffl4VB8Di8UyR giJbOld6Kl+awLb0wMkIQ6wPk/aQYhrOTYIBNr0= X-Google-Smtp-Source: AGs4zMamgaqjouZBTnTQ9EUdjrVrjm2JA9TMhIofgOPXxQw5nlfQhLdYzfljivJa9Txi4ZlYsWxpeFPj73D0kP6O4m0= X-Received: by 10.46.69.70 with SMTP id s67mr1440586lja.76.1510717784155; Tue, 14 Nov 2017 19:49:44 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.82.218 with HTTP; Tue, 14 Nov 2017 19:49:43 -0800 (PST) In-Reply-To: <0E332181-1DDD-4984-B84E-1852056BA1D4@gmail.com> References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> <7073D6DB-2C7E-4B0F-AF97-BD477458443E@gmail.com> <0E332181-1DDD-4984-B84E-1852056BA1D4@gmail.com> From: Daniel Migault Date: Tue, 14 Nov 2017 22:49:43 -0500 X-Google-Sender-Auth: kDXG8Zl4K8xO4d6wb3FRRfX3iQQ Message-ID: To: Yoav Nir Cc: IPsecME WG , Valery Smyslov Content-Type: multipart/alternative; boundary="001a114b15d4e16ade055dfd649f" Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:49:50 -0000 --001a114b15d4e16ade055dfd649f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This has been updated on my local copy... I was waiting to clarify how we handle the iKEv2 issue before publishing the update. On Tue, Nov 14, 2017 at 9:40 PM, Yoav Nir wrote: > Oh, and if you=E2=80=99re updating the draft anyway, you should update th= e > references now that 8221 and 8247 have been published. > > Yoav > > > On 15 Nov 2017, at 10:30, Yoav Nir wrote: > > Hi, Daniel > > I think your text is confusing without the suggestion to use Message ID a= s > a nonce. This suggestion is not in the text, it was only in this email > thread. > > So I think the text should be (new paragraph at the end of IANA > Considerations): > These algorithms should be added with this document as ESP Reference > and =E2=80=9CNot Allowed=E2=80=9D for IKEv2 Reference. > > This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ > ikev2-parameters.xhtml#ikev2-parameters-5 > > A new document will change that. > > On 15 Nov 2017, at 10:10, Daniel Migault > wrote: > > I am more incline to have IIV for iKEv2 in another document and as such w= e > request the IANA to set the "IKEv2 Reference" to UNDEFINED. > > What about the following text ? > > [RFC8247] recommends the same suites for IKEv2. However some IKEv2 > extensions such as [RFC6311] or [RFC7383] allow the Message ID to be > re-used, which is incompatible with the uniqueness property of > the nonce, and makes these suites highly insecure. As a result, the > suites > defined is this document does not apply to IKEv2. The IANA is expected > to > put "UNDEFINED" in the column "IKEv2 Reference" for these transforms. > > Yours, > Daniel > > On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov wrote: > >> Hi, >> >> >> >> I=E2=80=99m a bit nervous since we are trying to find a quick solution >> >> to an apparently not-so-easy problem in a rush time of WGLC. >> >> >> >> I think we need more time for that, so we either should >> >> drop the IIV for IKE and proceed with the current document >> >> for ESP only (and probably creating a new work item =E2=80=93 IIV for IK= Ev2) >> >> or hold on the draft until we found a solution for IKEv2 too. >> >> >> >> What about the way how to make IIV work with RFC6311, I can >> >> imaging the following solution. Cluster failover generally occurs >> >> rarely, so we may not worry about the overhead associated >> >> with sending RFC6311 messages. So we can introduce a combine >> >> mode, when some messages have implicit IV and some (e.g.RFC6311 messages= ) >> >> have explicit IV. Obviously we need to differentiate between them, >> >> so I presume we need to grab one of reserved bits in IKE header flags >> >> for this purpose. I admit it looks complicated, but I cannot come up >> >> with a simpler solution (except for not using IIV in IKEv2 at all). >> >> >> >> Regards, >> >> Valery. >> >> >> >> >> >> *From:* Yoav Nir [mailto:ynir.ietf@gmail.com] >> *Sent:* Tuesday, November 14, 2017 5:36 PM >> *To:* Valery Smyslov >> *Cc:* IPsecME WG >> *Subject:* Re: [IPsec] Proposal for using Implicit IV for IKE >> >> >> >> Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization mes= sages in >> 6311 all have Message ID zero and are encrypted. There do not seem to be >> any cleartext bits that differentiate one such message from another (whi= ch >> is why the RFC admits that they are replayable). >> >> >> >> So I=E2=80=99m kind of stuck. Support IIV or RFC 6311 but not both? Dr= op the >> whole thing? Something else that I=E2=80=99m missing? >> >> >> >> Yoav >> >> >> >> On 13 Nov 2017, at 11:30, Valery Smyslov wrote: >> >> >> >> Hi, >> >> >> >> there is also an RFC6311, which allows messages >> >> with the MessageID (0) to be sent over the same IKE SA >> >> in case of cluster failover. If the IKE SA is a result of a rekey >> >> (not IKE_SA_INIT), then its first encrypted message >> >> will have MessageID of 0, so if failover happens later, >> >> the MessageID of zero will repeat, breaking the security. >> >> You should consider this case also. >> >> >> >> Regards, >> >> Valery. >> >> >> >> *From:* IPsec [mailto:ipsec-bounces@ietf.org ] *= On >> Behalf Of *Yoav Nir >> *Sent:* Monday, November 13, 2017 5:35 AM >> *To:* IPsecME WG >> *Subject:* [IPsec] Proposal for using Implicit IV for IKE >> >> >> >> Hi. >> >> >> >> So following Daniel=E2=80=99s message in the room, here=E2=80=99s how I = think we can make >> this work. >> >> >> >> The IKE header has a =E2=80=9CMessage ID=E2=80=9D field that is a counte= r. It=E2=80=99s tempting >> to use this as a counter, same as we use the replay counter in IPsec. >> However, as Tero pointed out on Jabber, each such message ID can be used >> several times: >> >> - All responses have the same Message ID as the requests. >> - The Message ID is one sided. The n-th request from the original >> Responder has the same Message ID as the n-th request from the origin= al >> Initiator. >> - When a message is fragmented as in RFC 7383, all fragments that are >> part of the same message are transmitted (and encrypted) with the sam= e >> Message ID. >> >> >> >> Re-using the Message ID makes us re-use the AEAD nonce. Not good. >> Fortunately, all the algorithms that the IIV draft mentions require an >> 8-octet IV while the Message ID is 4-octet. We can use the 32 =E2=80=9C= spare=E2=80=9D bits >> to differentiate these messages. I have two proposals for constructing = the >> 8-octet IV: >> >> >> >> Proposal #1: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| >> >> >> >> And use IIV only for regular Encrypted Payload, not for Encrypted >> Fragment. The reasoning is that if you use fragmentation you=E2=80=99ve= already >> solved the message-too-big issue. >> >> >> >> The Flags octet includes the I(nitiator) and R(esponse) bits, which >> differentiate the cases that are not related to fragmentation. >> >> >> >> Proposal #2: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 >> bits)| >> >> >> >> The Fragment Counter is the same as in the RFC 7383 fragment payload, or >> zero if we are using the regular encrypted payload. >> >> >> >> The Flags octet includes the I(nitiator) and R(esponse) bits, which >> differentiate the cases that are not related to fragmentation. >> >> >> >> The Fragment Counter differentiates between different part of the same >> message. >> >> >> >> The Next Payload differentiates between sending a message fragmented and >> sending it unfragmented. >> >> >> >> >> >> So in summary, I think it=E2=80=99s doable and can be added to the draft= if we >> have consensus. >> >> >> >> Yoav >> >> >> >> _______________________________________________ >> 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 > > --001a114b15d4e16ade055dfd649f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This has been updated on my local copy... I was waiting to= clarify how we handle the iKEv2 issue before publishing the update.

On Tue, Nov 1= 4, 2017 at 9:40 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:<= br>
Oh, and if you=E2=80=99re updating the draft anyway= , you should update the references now that 8221 and 8247 have been publish= ed.

Yoav<= div>


On 15 Nov= 2017, at 10:30, Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi, Daniel

I think you= r text is confusing without the suggestion to use Message ID as a nonce. Th= is suggestion is not in the text, it was only in this email thread.

So I think the text should be (new paragraph at the end o= f IANA Considerations):
=C2=A0 =C2=A0These algorithms should be a= dded with this document as ESP Reference and =E2=80=9CNot Allowed=E2=80=9D = for IKEv2 Reference.

This seems fitting for=C2=A0<= a href=3D"https://www.iana.org/assignments/ikev2-parameters/ikev2-parameter= s.xhtml#ikev2-parameters-5" target=3D"_blank">https://www.iana.org/ass= ignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters= -5

A new document will change that.
On 15 Nov 2017, at 10:10, Daniel Migault &= lt;daniel.= migault@ericsson.com> wrote:

I am more incline to= have IIV for iKEv2 in another document and as such we request the IANA to = set the "IKEv2 Reference" to UNDEFINED.

What about = the following text ?

=C2=A0=C2=A0 [RFC8247] recommends the same= suites for IKEv2.=C2=A0 However some IKEv2
=C2=A0=C2=A0 extensions such= as [RFC6311] or [RFC7383] allow the Message ID to be
=C2=A0=C2=A0 re-us= ed, which is incompatible with the uniqueness property of
=C2=A0=C2=A0 t= he nonce, and makes these suites highly insecure. As a result, the suites=C2=A0=C2=A0 defined is this document does not apply to IKEv2. The IANA i= s expected to
=C2=A0=C2=A0 put "UNDEFINED" in the column &quo= t;IKEv2 Reference" for these transforms.

Your= s,
Daniel

On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov <sva= nru@gmail.com> wrote:

Hi,

=C2=A0

I=E2=80=99m a bit nerv= ous since we are trying to find a quick solution

to an appare= ntly not-so-easy problem in a rush time of WGLC.

=C2= =A0

I think we need more time for that, so we either should <= u>

drop the IIV for IKE and proceed with the current document=

for ESP only (and probably creating a new work item =E2=80=93 IIV for = IKEv2)

or hold on the draft until we found a solution for IKE= v2 too.

=C2=A0

What about the way how to make I= IV work with RFC6311, I can

= imaging the following solution. C= luster failover generally occurs

rarely, so we may not worry = about the overhead associated

with sending RFC6311 messages. = So we can introduce a combine

mode, when some messages have i= mplicit IV and some (e.g.RFC6311 messages)

have explicit IV.= Obviously we need to differentiate between them,

<= p class=3D"MsoNormal">so I presum= e we need to grab one of reserved bits in IKE header flags

fo= r this purpose. I admit it looks complicated, but I cannot come up

with a simpler solution (except for not using IIV in IKEv2 at all).

=C2=A0

Regards,

Valery.<= /u>

=C2=A0

=C2=A0

From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent: Tuesday, N= ovember 14, 2017 5:36 PM
To: Valery Smyslov
Cc: IPsecME= WG
Subject: Re: [IPsec] Proposal for using Implicit IV for IKE

=C2=A0

= Having re-read RFC 6311, Valery=E2=80=99s right. The synchronization messag= es in 6311 all have Message ID zero and are encrypted. There do not seem to= be any cleartext bits that differentiate one such message from another (wh= ich is why the RFC admits that they are replayable).

=

=C2=A0

So I=E2=80=99m kind of stuck.=C2=A0 Support IIV or RFC 6311 but not b= oth?=C2=A0 Drop the whole thing?=C2=A0 Something else that I=E2=80=99m miss= ing?

=C2=A0

Yoav



On 13 = Nov 2017, at 11:30, Valery Smyslov <svanru@gmail.com> wrote:

=C2=A0

Hi,

= =C2=A0

there is also an RFC6311, which allows mess= ages

with the MessageID (0) to be sent over the s= ame IKE SA

in case of cluster failover. If the IKE= SA is a result of a rekey

(not IKE_SA_INIT), then= its first encrypted message

will have MessageID o= f 0, so if failover happens later,

the MessageID o= f zero will repeat, breaking the security.

You sho= uld consider this case also.

=C2=A0<= u>

Regards,

Valery.

=C2=A0

From:=C2=A0IPsec [mailto:ipsec-boun= ces@ietf.org]=C2=A0On Behalf Of=C2=A0= Yoav Nir
Sent:=C2=A0Monday, November 13, 2017 5:= 35 AM
To:=C2=A0IPsecME WG
Subject:= =C2=A0[IPsec] Proposal for using Implicit IV for IKE

=C2=A0

Hi.

=C2=A0

=

So following Daniel=E2=80=99s = message in the room, here=E2=80=99s how I think we can make this work.

=C2=A0<= /u>

The IKE header has a = =E2=80=9CMessage ID=E2=80=9D field that is a counter. It=E2=80=99s tempting= to use this as a counter, same as we use the replay counter in IPsec.=C2= =A0 However, as Tero pointed out on Jabber, each such message ID can be use= d several times:

  • All responses have the same Mess= age ID as the requests.
  • The Messa= ge ID is one sided.=C2=A0 The n-th request from the original Responder has = the same Message ID as the n-th request from the original Initiator.=
  • When a message is fragmented as in RFC = 7383, all fragments that are part of the same message are transmitted (and = encrypted) with the same Message ID.

=C2=A0

Re-using the Message ID makes us re-use the AEAD nonce. N= ot good.=C2=A0 Fortunately, all the algorithms that the IIV draft mentions = require an 8-octet IV while the Message ID is 4-octet.=C2=A0 We can use the= 32 =E2=80=9Cspare=E2=80=9D bits to differentiate these messages.=C2=A0 I h= ave two proposals for constructing the 8-octet IV:

<= /div>

=C2=A0

<= div>

Proposal #1:

<= div>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

| 24 zero bits | Flags (8= bits) | Message ID (32 bits)|

=C2=A0

And use IIV only for regular Encrypted Payload, not for Encrypt= ed Fragment.=C2=A0 The reasoning is that if you use fragmentation you=E2=80= =99ve already solved the message-too-big issue.

=C2=A0

The Flags octet includes the I(nitiator) and R= (esponse) bits, which differentiate the cases that are not related to fragm= entation.

=C2= =A0

Proposal = #2:

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

| Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID = (32 bits)|

= =C2=A0

The Fr= agment Counter is the same as in the RFC 7383 fragment payload, or zero if = we are using the regular encrypted payload.

=C2=A0

The Flags octet includes the I(nitiator) and R(esp= onse) bits, which differentiate the cases that are not related to fragmenta= tion.

=C2=A0<= u>

The Fragment = Counter differentiates between different part of the same message.

=C2=A0<= /p>

The Next Payload differenti= ates between sending a message fragmented and sending it unfragmented.=C2= =A0

=C2=A0=

=C2=A0

So in summary, I thin= k it=E2=80=99s doable and can be added to the draft if we have consensus.

=C2=A0<= u>

Yoav

=C2=A0=


______________________________<= wbr>_________________
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


--001a114b15d4e16ade055dfd649f-- From nobody Tue Nov 14 20:49:56 2017 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 32C931201F8 for ; Tue, 14 Nov 2017 20:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAT3_W_qGpIn for ; Tue, 14 Nov 2017 20:49:50 -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 90BEC126E64 for ; Tue, 14 Nov 2017 20:49:45 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ycBkG5mSPz37Y for ; Wed, 15 Nov 2017 05:49:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510721382; bh=knbdMnFy5GQOLgwoqPT45WPt7S5Jxl8vGdfyq2oyRuI=; h=Date:From:To:Subject:In-Reply-To:References; b=YZMlTwuemCAVFRLLy5eFDwzKofXSOfPuDNbSSBvZhxcg51jalFVgRILXZ1TYPiPXT 5BxWHpGnYsmQlzHY8EoedNDQ4OwaZBmfx10PlPBvw9L6siZQbvtKQYHrAi9OYxcscZ vLRewCteuYSEpsaFzDY1Pf5HTU9bUCe3YI5ky8zA= 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 y383LQL-Eavr for ; Wed, 15 Nov 2017 05:49:41 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 15 Nov 2017 05:49:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B17A162D29; Tue, 14 Nov 2017 23:49:39 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B17A162D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9F5D840D35AF for ; Tue, 14 Nov 2017 23:49:39 -0500 (EST) Date: Tue, 14 Nov 2017 23:49:39 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> Message-ID: References: <010b01d35c2f$bc3f7510$34be5f30$@gmail.com> <65ECBDA0-6F02-4288-AAF6-CEEEE7E86713@gmail.com> <03aa01d35db2$fa946f30$efbd4d90$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Proposal for using Implicit IV for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:49:55 -0000 On Wed, 15 Nov 2017, Valery Smyslov wrote: > I’m a bit nervous since we are trying to find a quick solution > to an apparently not-so-easy problem in a rush time of WGLC. > > I think we need more time for that, so we either should > drop the IIV for IKE and proceed with the current document > for ESP only (and probably creating a new work item – IIV for IKEv2) Yes please. Split the document. Paul From nobody Wed Nov 15 17:51:52 2017 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 793DE1293DF for ; Wed, 15 Nov 2017 17:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1mrDlUJcoLm for ; Wed, 15 Nov 2017 17:51:47 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 ED7D1120227 for ; Wed, 15 Nov 2017 17:51:46 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id w21so28334757lfc.6 for ; Wed, 15 Nov 2017 17:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=1K67rGq9/ve2QWVt52iZcXvdOq/V9YyyVdoPWKBYuno=; b=gNGv4pUnPO2n+vIadbBEJIrUAweWyQSjdB90eFMBCIH4wGZi1BlAjTgkk/sYfEBTw1 91j1EmWpQQRFMAcfaHV2ypAasCVrOhYaFiIRzK97BdL7Yk/Fr82vrgPLvv+tmT2gdT20 tRBWLFUgEonSY/Kdij4sSS5GOEA0k4yG/4b8lKdnuMRU3Q/UgAdZoC5ELnBcKZ29Jwnz TcULxYJGBmKL+j5i7g6d2niRECDm6QUEdBRQ1zwzTZhayYO9RDf/s9oN85RSnJ/riWKc acreR8f4xthXw8DILwC9jP5G6eUblQ6ElCC+sXTZKUpsVGD/NVB147oVemXD6M+4ZC8N jS0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=1K67rGq9/ve2QWVt52iZcXvdOq/V9YyyVdoPWKBYuno=; b=tkEzPdZBC8tCIa73aVVSwqNIVXGzlRyyR+Cwgtd9ZCbF2Gf2UNJ1GcB294z/OBGrPc xi3VHLQ41USdbN2t7JWvuaLk4MgLgJvF9HG8+9SOth7cgvliWEcLdAplTbM/jGTp040T Cwl/BSnpHScZazE9T0hICm40+lovtHDww06wdIKVKYf59YVu1Phh6lvkfWWzcbScmTRK x0ntxXO1xro9mlj5jamVFvPMRIb6OGlhg9gTieuTATWGxBCXXSGKtYQ7kVkL5OebTv4H 8EpXt8JHhqrVQbEpA/Sbc1MYbfHfGv/pfCbfbSlS3nlbraIXeI+UAg3j5YNp7yTZ0Ibe Pn6w== X-Gm-Message-State: AJaThX4noch6HbOnhM1eDiqdIBqwKExJxMs2vX3Y4lH3A3dozBDfmEby GIsa7nlggr1uT9DRxlnsiPSYNw== X-Google-Smtp-Source: AGs4zMadFneze9Cc4208eCEKkmD4w7XX38Y2Sur+ccy8209Z/FFKoclmkgpR4YBLpVz34BvCVeIWng== X-Received: by 10.25.213.138 with SMTP id m132mr12843lfg.107.1510797104907; Wed, 15 Nov 2017 17:51:44 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p64sm3489585lfe.47.2017.11.15.17.51.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 17:51:44 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Paul Wouters'" , , "'Sahana Prasad'" References: <23035.15970.848662.263976@fireball.acr.fi> <23039.19522.246855.199327@fireball.acr.fi> <23050.39852.520962.719946@fireball.acr.fi> <02ec01d35d21$5ea60980$1bf21c80$@gmail.com> <23050.45054.267720.174818@fireball.acr.fi> <02fc01d35d28$3c712780$b5537680$@gmail.com> <23051.45690.505582.429019@fireball.acr.fi> In-Reply-To: <23051.45690.505582.429019@fireball.acr.fi> Date: Thu, 16 Nov 2017 04:51:41 +0300 Message-ID: <04ce01d35e7d$7388e270$5a9aa750$@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: AQHmiJT1dlQG1O0xNU142zXveMWwSwLsQDTUAr9f9YoCOd7Y3AFeJIlAAiQKtFcDNXcgAgFwxGVZAaUlVYgC9rN49QLmIJPVojLC4pA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Signature algorithm negotiation (was Re: Agenda for IETF 100) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 01:51:48 -0000 > > If tomorrow cryptographers discover some weakness in one encoding > > and start recommend using another format, then we'll have to follow. > > And it doesn't matter if we disallowed using it before. > > In such case you do create a new key, and you do disable the old > format, so there is no issue with this, as you still have only one > format for a key. I'm not so sure about the future movements in cryptography :-) Nevertheless, even if it is a different key, it'll most probably be issued by the same CA, so the initiator will have no clue how to select the proper key apart from pre-configuration (CERTREQUEST won't help). And pre-configuration won't work is case of opportunistic encryption and in will work badly in large scale. We still have a problem. From nobody Thu Nov 16 21:20:50 2017 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 54FD5127B31 for ; Thu, 16 Nov 2017 21:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcxvKrLJE3Ja for ; Thu, 16 Nov 2017 21:20:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 C54131270B4 for ; Thu, 16 Nov 2017 21:20:46 -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 vAH5KgO1017705 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Nov 2017 07:20:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vAH5KgpG027166; Fri, 17 Nov 2017 07:20:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23054.29098.665202.402605@fireball.acr.fi> Date: Fri, 17 Nov 2017 07:20:42 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Subject: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 05:20:49 -0000 I put the candidate charter text to the wiki. This includes the changes in the first two paragraphs, removes items already done, and list of new items. I have not yet added the items that came too late to have charter text bashed in the meeting to the wiki. For those items which do not have text yet, it would be good idea if those people could send new proposed text to the list so we could bash those at the same time as we go and check the other pieces. So read that candidate charter text and comment it on the list. Wiki address is https://trac.ietf.org/trac/ipsecme/wiki/recharter2017 -- kivinen@iki.fi From nobody Thu Nov 16 22:35:25 2017 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 58C9D128796 for ; Thu, 16 Nov 2017 22:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bhu7QCkiswI for ; Thu, 16 Nov 2017 22:35:22 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7940A1200C1 for ; Thu, 16 Nov 2017 22:35:22 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 7F84716118A; Fri, 17 Nov 2017 07:35:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 62A5516007F; Fri, 17 Nov 2017 07:35:20 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 07:35:20 +0100 From: To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Candidate charter text is now in wiki Thread-Index: AQHTX2PY1LVxwKS2jUO3yJx92UH7bqMYHZYQ Date: Fri, 17 Nov 2017 06:35:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23054.29098.665202.402605@fireball.acr.fi> In-Reply-To: <23054.29098.665202.402605@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:35:24 -0000 Dear Tero, It seems that you missed this text for the address failure codes (Nov 13):= =20 https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html =20 I'm resending it fwiw: RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. Cheers, Med > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen > Envoy=E9=A0: vendredi 17 novembre 2017 06:21 > =C0=A0: ipsec@ietf.org > Objet=A0: [IPsec] Candidate charter text is now in wiki >=20 > I put the candidate charter text to the wiki. This includes the > changes in the first two paragraphs, removes items already done, and > list of new items. I have not yet added the items that came too late > to have charter text bashed in the meeting to the wiki. >=20 > For those items which do not have text yet, it would be good idea if > those people could send new proposed text to the list so we could bash > those at the same time as we go and check the other pieces. >=20 > So read that candidate charter text and comment it on the list. >=20 > Wiki address is https://trac.ietf.org/trac/ipsecme/wiki/recharter2017 > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Nov 17 23:59:28 2017 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 5CD82126C26; Fri, 17 Nov 2017 23:59:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg To: Cc: ipsec@ietf.org, ietf@ietf.org, draft-ietf-ipsecme-eddsa.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151099196129.9056.6462331514698284743@ietfa.amsl.com> Date: Fri, 17 Nov 2017 23:59:21 -0800 Archived-At: Subject: [IPsec] Genart last call review of draft-ietf-ipsecme-eddsa-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 07:59:21 -0000 Reviewer: Christer Holmberg Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipsecme-eddsa-04 Reviewer: Christer Holmberg Review Date: 2017-11-17 IETF LC End Date: 2017-12-04 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and almost ready for publication. However, I have some editorial change suggestions that I think would improve the readability of the document. Major issues: None Minor issues: None Nits/editorial comments: Q1: ---- In the Abstract the text says " Edwards-curve digital signature algorithm", without the EdDSA abbreviation, and in the Introduction the text says "EdDSA" without the enhancement. I suggest to say "Edwards-curve digital signature algorithm (EdDSA)" in the first occurrences within the Abstract and the Introduction. Q2: ---- In the Introduction the text says "The latter RFC" and "that document". I suggest to explicitly use the RFC numbers instead. That makes it easier to read, and there is always a theoretical change that someone files an errata, or update the text within another RFC, that changes the order to the RFCs so that "The latter" etc points to the wrong RFC... Q3: ---- In the Introduction the text says: "EdDSA defines the binary format of the signatures that should be used in the "Signature Value" field of the Authentication Data Format in section 3." Section 3 of what? I assume you refer section 3 of RFC 8032, so I suggest to explicitly say that. Otherwise someone (at least I did) may jump to section 3 of the draft and start looking. The same thing applies to "Appendix A". Please indicate the RFC number. Q4: ---- In the Introduction the text says: "we define a new value" I suggest to say "this document defines a new value". Or, you could even say "section 2 of this document defines a new value". Q5: ---- In section 3, I suggest to add a reference (URL?) to the hash algorithm registry. From nobody Mon Nov 27 06:09:21 2017 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 22B52128B8D; Mon, 27 Nov 2017 06:09:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: ipsec@ietf.org, ietf@ietf.org, draft-ietf-ipsecme-eddsa.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151179175411.30910.13010385715015417131@ietfa.amsl.com> Date: Mon, 27 Nov 2017 06:09:14 -0800 Archived-At: Subject: [IPsec] Secdir last call review of draft-ietf-ipsecme-eddsa-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:09:14 -0000 Reviewer: Adam Montville Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready. A very straightforward, short document defining a new value in SIGNATURE_HASH_ALGORITHMS notification of IKE, so that non-hashing signature methods (specifically the Edwards-curve digital signature algorithm) can be used. One nit: s/or/of/ in last sentence of second introduction paragraph, so that it reads, "See section 8.5 of RFC 8032...". From nobody Mon Nov 27 07:33:00 2017 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 1F1E0126BF3; Mon, 27 Nov 2017 07:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151179677407.30946.6583016989870225096@ietfa.amsl.com> Date: Mon, 27 Nov 2017 07:32:54 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 15:32:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-00.txt Pages : 7 Date : 2017-11-18 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and savec in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 27 10:52:11 2017 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 EC24D1292CE; Mon, 27 Nov 2017 10:52:03 -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, FREEMAIL_FROM=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 8kDOm-KRJRbc; Mon, 27 Nov 2017 10:52:02 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 166C71270A3; Mon, 27 Nov 2017 10:51:59 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v186so36981622wma.2; Mon, 27 Nov 2017 10:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cH/zE46AO3nlnKLOl73KViBYRVJ/HvNksL6Sc05yNX4=; b=OUnzZZoZcZuBdXprcM8Q/rqpVUA1/VW5fsT50kDwiCukZgGyoHp3LGAf/cDZ7VS+r1 KbkVSgEqC2ArU4mJC1WtkSB+s8vRbgW0IgiorOHEdL37MC3KgT5G617f8M0pGsp/mifS PxwomtjuTHBgSPLHth91g7Czu9bRdf3VIVo2+DwItXAJRcLJ912h7IMbxqVGNK8dmouw Rlr0aHKGQdOVjnnGdy8YGv3aFCBi01x3/kE5qc46Kn1Yhgvt3L9cBXikCca/H/51G8wF s0LRoq8/d5cZ3E16AHi+uBsi1wctuQ0xcRUE/eQp97VgkJYV0PxRozSVEWYbToCxt6uo klOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cH/zE46AO3nlnKLOl73KViBYRVJ/HvNksL6Sc05yNX4=; b=sXBDYa/UBrlbR5jEjeWhpmaep2VMbpZy7Vd+Quy886fMAbEiCkrwj06F+PSu32We1Z AI4mP9DsgOOpJmCLiKZbaxENn+yHC+y1pX0QkR5gdidJCxDJRiP9w2qVe2lHMQCR497g k8JKcgmLbTJqJ5GnP0/8vsHTy/L++kuwMVzCSUOqWMIPI159AB9HCvqSOMCuvNeUmPjz rDOawhdfWROwRO/sGum3mVFAt7VAImS+GY4EguZxre86eRE3ntoxeYfCcDhutqpmBVU9 /jNibaL74Z2Fij05XO31No+hiMXvVmh1OO9sVX0reQDZq/xZ14V63pdca7q40iSzb8S9 YnYQ== X-Gm-Message-State: AJaThX5HdSNaBcJJK36QtU46PofXbWOEWmH+/GTaR2vY6wGrSfOCAze5 gFS3rkrRtRBvno89vEb4Ijg= X-Google-Smtp-Source: AGs4zMairR2sfNUYRGiwRdZC8XpTXzr30A0qTFwp5i3M+IJSUpwJI2H0MctvCCuS8Fjoep4YSTOj1w== X-Received: by 10.28.138.12 with SMTP id m12mr19458997wmd.134.1511808717614; Mon, 27 Nov 2017 10:51:57 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i55sm9385454wra.60.2017.11.27.10.51.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 10:51:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Yoav Nir In-Reply-To: <151179175411.30910.13010385715015417131@ietfa.amsl.com> Date: Mon, 27 Nov 2017 20:51:54 +0200 Cc: secdir , ipsec@ietf.org, ietf@ietf.org, draft-ietf-ipsecme-eddsa.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <23E34FAC-BF15-4523-91CE-88E3B2A7AA46@gmail.com> References: <151179175411.30910.13010385715015417131@ietfa.amsl.com> To: Adam Montville X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-eddsa-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 18:52:04 -0000 > On 27 Nov 2017, at 16:09, Adam Montville = wrote: >=20 > Reviewer: Adam Montville > Review result: Ready >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > This document is ready. >=20 > A very straightforward, short document defining a new value in > SIGNATURE_HASH_ALGORITHMS notification of IKE, so that non-hashing = signature > methods (specifically the Edwards-curve digital signature algorithm) = can be > used. Thanks, Adam. >=20 > One nit: s/or/of/ in last sentence of second introduction paragraph, = so that it > reads, "See section 8.5 of RFC 8032=E2=80=A6=E2=80=9D Unless something else comes up, I=E2=80=99ll leave this to AUTH48 = (although the RFC Editor are likely to find it and fix it anyway). Yoav= From nobody Tue Nov 28 16:52:31 2017 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 215C9128B93; Tue, 28 Nov 2017 16:52:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Jaeggli To: Cc: ipsec@ietf.org, ietf@ietf.org, draft-ietf-ipsecme-eddsa.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151191675007.8090.17913891042195155302@ietfa.amsl.com> Date: Tue, 28 Nov 2017 16:52:30 -0800 Archived-At: Subject: [IPsec] Opsdir last call review of draft-ietf-ipsecme-eddsa-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 00:52:30 -0000 Reviewer: Joel Jaeggli Review result: Ready I reviewed draft-ietf-ipsecme-eddsa on behalf of the opsdir during it's IETF Last call. This standards track draft introduces an importance change in the IKE negotiation in that the sender can indicate that it hash algorithms which do not require prehashing and can instead operate on arbitrary length data. It also goes on to make a more strong requirement then RFC 8032 (which is informational) that: " The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph respectively) MUST NOT be used in IKE." Changes to IKE negotiation require careful review, but I am satisfied that this explicit signal improves the handling of support for the edwards curves. From nobody Tue Nov 28 19:47:56 2017 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 940A1127863 for ; Tue, 28 Nov 2017 19:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 9dOdBBu6hA_w for ; Tue, 28 Nov 2017 19:47:53 -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 EBC8612741D for ; Tue, 28 Nov 2017 19:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1511927273; 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=p9bJOjcRaxckOS9mVuqKFE1OYv7rXlT9qm+hvl/CQLk=; b=VPVpTk9DiiW57DC5oTdmvWW/TJxrukHd2YH5Ur7WHl+MmonuOPQ5N3+uQL5pyt92 uBq1OBB6H1Bt4z3c7iqE7QPJEKhcJvWlRO1DVGSAWARKYD3vTG7k+mvn1nV+6pY4 VyRbk67lTuQRYV92fy/MXTSUU7uqCG0lFp6o/iUl2st1uN6sXAag28BqrCSCfUOg X4tg0yqXIEO4ReZAVIfVFAKVPViBoH0xbLdrojxIDCNiqI4NjUrwvuKaYeM94UI0 uUxRAC9WGhmFCA1/6V0Oc8aIhN/shZP5sJujIZbc3bZN5UbddS/KYaQqStgm3XsQ nRnxNuxn8/XwZ/oVfj5CUg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 11.43.16042.9ED2E1A5; Tue, 28 Nov 2017 19:47:53 -0800 (PST) X-AuditID: 11973e12-801fd9c000003eaa-0b-5a1e2de90c88 Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id D9.AF.22651.9ED2E1A5; Tue, 28 Nov 2017 19:47:53 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.35.34] (unknown [17.234.35.34]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171102 64bit (built Nov 2 2017)) with ESMTPSA id <0P05008XIUJRRH30@kencur.apple.com>; Tue, 28 Nov 2017 19:47:53 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 28 Nov 2017 19:47:47 -0800 Cc: "ipsec@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <84472A32-CABA-4CFC-AA4D-BCAF070E9959@apple.com> References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Tero Kivinen X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FCYpvtSVy7KoLVN32L/lhdsFkfPP2dz YPJYsuQnk8fhrwtZApiiuGxSUnMyy1KL9O0SuDL6VkcUTJWo6N+4hr2BcY1wFyMnh4SAicTB NdfZuxi5OIQE1jBJ3N8/nRkmsWn3NTBbSGATo8SknmoQm1dAUOLH5HssXYwcHMwC6hJTpuRC 9DYySbyfdYUNpEZYQFqi68JdVgjbSuL1oYuMIPVsAloSB9YYgYQ5BVIkdt2/zQoSZhFQlXj1 2h0kzAxkzppwmwnC1pZ48u4CK8RWG4l76/cyQlzTzyjRNJ0XxBYRUJTY/WQrE8TFihJHZs5h BjlHQuAvq8S6VV2sExiFZyG5ehbC1bOQrFjAyLyKUSg3MTNHNzPPRC+xoCAnVS85P3cTIyik p9sJ7WA8tcrqEKMAB6MSD6/GatkoIdbEsuLK3EOM0hwsSuK8ObJyUUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYw/wCXjWH1JhkzF/+wkzuvXuVlErZDdUrvJcUgmofvlxotfbeilzFxZ2H W56n9UsmZPzkF3dT+Gy87Fltwi2zW9x/GJMexTAElfSXHEjjvcq8Pv3jKY/XiXzKMZzGwVfi Wk5My34UbbIxSeFhW8qNvfUdL4rbEudUlivfKnilbOldwcRhzarEUpyRaKjFXFScCABikt6T SgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiON1OTfelrlyUQfcxdYv9W16wWRw9/5zN gcljyZKfTB6Hvy5kCWCK4rJJSc3JLEst0rdL4MroWx1RMFWion/jGvYGxjXCXYycHBICJhKb dl9jBrGFBDYxSkzqqQaxeQUEJX5MvsfSxcjBwSygLjFlSm4XIxdQSSOTxPtZV9hAaoQFpCW6 LtxlhbCtJF4fusgIUs8moCVxYI0RSJhTIEVi1/3brCBhFgFViVev3UHCzEDmrAm3mSBsbYkn 7y6wQmy1kbi3fi8jxDX9jBJN03lBbBEBRYndT7YyQVysKHFk5hzmCYwCs5AcOgvh0FlIpi5g ZF7FKFCUmpNYaaGXWFCQk6qXnJ+7iREUgg2FaTsYm5ZbHWIU4GBU4uG9sEI2Sog1say4MvcQ owQHs5IIb+UkoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHezyvFo4QE0hNLUrNTUwtSi2CyTByc Ug2MS/ZsO8O0ZPbdeu+UWVInlIsOH95b7aNsJdotYMhq3NxyU/HOtMSkNZ2L7vQlJJ3bcs51 DvseIbZ98t9NF5e8LjdyPqF74bvS2TkX17AY7933vq5J1TpRpHY5Y03r9o1sSw4kqB5vzMm5 Ns/izTudK3EJdyTbmKKWpLxmmDT/SfiBjju1RxaGKLEUZyQaajEXFScCAL8pBAE9AgAA Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 03:47:55 -0000 Hi Tero, Here is proposed charter text for the "Mitigating privacy concerns" = section: IKEv2 is currently vulnerable to the two following privacy concerns: 1) It's not possible to run a server that obfuscates IKEv2/IPsec using = TLS. Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec server = on TCP port 443 with TLS. However if a government agent tries to send an SA_INIT over that it = will discover that this server runs IKEv2/IPsec, and may blacklist it. We should add a mechanism to IKEv2 that allows the server to only = respond to SA_INIT from known entities (e.g. that possess a shared = secret). 2) The privacy of the initiator's identity in the presence of a man in = the middle attacker is not protected Today an attacker with full control of the network can receive the = IDi/IDr sent by the initiator in the first AUTH packet. We should add a mechanism to IKEv2 that allows the initiator to only = send IDi/IDr to known entities (e.g. that possess a shared secret). Thanks, David Schinazi > On Nov 16, 2017, at 22:35, mohamed.boucadair@orange.com wrote: >=20 > Dear Tero, >=20 > It seems that you missed this text for the address failure codes (Nov = 13):=20 > https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html =20 >=20 > I'm resending it fwiw: >=20 > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address = family > is not assigned, nor whether it should try using another address > family. The Working Group will specify a set of more specific > notification codes that will provide sufficient information to the > IKEv2 initiator about the encountered failure. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen >> Envoy=C3=A9 : vendredi 17 novembre 2017 06:21 >> =C3=80 : ipsec@ietf.org >> Objet : [IPsec] Candidate charter text is now in wiki >>=20 >> I put the candidate charter text to the wiki. This includes the >> changes in the first two paragraphs, removes items already done, and >> list of new items. I have not yet added the items that came too late >> to have charter text bashed in the meeting to the wiki. >>=20 >> For those items which do not have text yet, it would be good idea if >> those people could send new proposed text to the list so we could = bash >> those at the same time as we go and check the other pieces. >>=20 >> So read that candidate charter text and comment it on the list. >>=20 >> Wiki address is https://trac.ietf.org/trac/ipsecme/wiki/recharter2017 >> -- >> kivinen@iki.fi >>=20 >> _______________________________________________ >> 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 Nov 29 06:54:23 2017 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 8BF84126C25 for ; Wed, 29 Nov 2017 06:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9GPCj9YTT11 for ; Wed, 29 Nov 2017 06:54:20 -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 DFC0B1243F6 for ; Wed, 29 Nov 2017 06:54:19 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yn3TM2gnXz3LJ for ; Wed, 29 Nov 2017 15:54:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1511967255; bh=tSB9FtbqDQ4mMbGhOpS3UbHvZH8XSybQZWVqSWhEpKc=; h=Date:From:To:Subject; b=OCIkcIUqT/MyejGYcfZEBTNI++jyFogHJmg7gXbTF0gwHE5j69mKA6YWpMhQQzjcn h7tFvorNGgAGudjd0udii5aG4bBkLesDcRVnr5ehhFk3iNDzAH+AkEdS/DJ77H2hf1 ZX1P/iIS2oGRuNCmCmQSzc6O6WwTP10N90BNOrP4= 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 3nXcHlT_sP8O for ; Wed, 29 Nov 2017 15:54:13 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 29 Nov 2017 15:54:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EE115A7FA5; Wed, 29 Nov 2017 09:54:11 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EE115A7FA5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E190F4B41F87 for ; Wed, 29 Nov 2017 09:54:11 -0500 (EST) Date: Wed, 29 Nov 2017 09:54:11 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 14:54:21 -0000 Hi, We are looking at Opportunistic IPsec and supporting key rollover support. In IKEv1, the initiator used the responder's key first, and the responder could figure out which of its multiple keys the initiator used. But in IKEv2, the responder uses one of their keys and it does not really know which ones the initiator knows about. So we would like the initiator to indicate which key it is expecting the peer to use. We could use the IDr payload in IKE_AUTH for that, using an ID_KEY_ID type. But we would also really like to use the IDr payload on the initiator to convey to the responder which FQDN we are expecting, so a responder could use a different key for each FQDN it is responsible for. While the responder could map ID_KEY_ID to FQDN's, it would be nice if we could send both pieces of information from the initiator. I can see a few ways of doing this: 1) Allow sending two IDr payloads in IKE_AUTH request 2) Add a new NOTIFY type that takes an IDr payload, then send the real IDr payload and the NOTIFY containing the second IDr payload. 3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr payload with that. 4) No change, use IDr ID_KEY_ID and leave it the implementer's problem to figure out keyid -> FQDN. I've ordered these according to my preference. I'd like to hear other people's view on this :) Paul From nobody Thu Nov 30 00:04:23 2017 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 91DAE128E00 for ; Thu, 30 Nov 2017 00:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhZJe-nP7r_3 for ; Thu, 30 Nov 2017 00:04:21 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 51176128DF3 for ; Thu, 30 Nov 2017 00:04:20 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id t197so6854903lfe.7 for ; Thu, 30 Nov 2017 00:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=teMYwf6Ef9WmGKeKiizNluPff8lUtqUmqM4KgpcKurc=; b=cdIYSPwKSf+7ZqT0X1qnANyOh11MLvAYxOz1rKzv5aXQp9xSuFxbJh8oenngYwWiDX EbpsfmefYWQIB/RKGk2sBN4SR5KaFOR77ybKZ1u+LZjd60JpAx8Q24GaTp5G27dG8deN fJOWqJTYFkut3BpWWya9iq9RHj6nTmLqij0uRC+b01ABneqjAZvekgYa1Ddf4mCr/qwf GAb/izQoFiC8MNxi/hcOhdhIcOM0999Irw62SS0XZ4/coAZWG29KN2uYvqs2L4zw813Z LF3dppytMEXLRUcaSEpaiZLwElqN1u34GzTnQ/HEyDRyUhEiXxzGYOAN/pbtHQJDNqH5 llnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=teMYwf6Ef9WmGKeKiizNluPff8lUtqUmqM4KgpcKurc=; b=Zh+pSJ857gHi1cwt03Y+qWhmVnCca+c6iNcRFkYE6BWXczwTvEFVl26v5iRzJ0zArl akXxmvVHcZwwkCYwr4B15zu877Oby8/jC3cEHgcuX+5wbnUxIfu+ls/iecrAaAyVWtCx HWBMWkhMjShiERe1MXxBZnLlco8RWMbNQct1ora/Jny1Yz0mLve6+oqpAilxdC8NzeCM /dCrRPrxzBDA+NZ2QNDIZuGM1qPSgphJQ/95isvU4D19jDt4oaVE2jt605wvZhDzAorA 6CLpp26rWMKgyYu1EJ/OzQH8QpSKlwyDAcpCj1u27xnVNE5yo9jss3gjgnCuxQEzRSwo /nPQ== X-Gm-Message-State: AJaThX4WwG4/DgQY1mp7W+B1hW6geYZ/9aihU7SK9QIooOM9QjXZ2LgL 73/hvUZRYv9hYl4qeDhxexEL2A== X-Google-Smtp-Source: AGs4zMZo43EiUxHibdi7K1+5upFJVv2tGcR2K2WdkRRbVE+Jr02XGHjv/LJ0JApfW0O+ljEYV5FRrg== X-Received: by 10.25.42.8 with SMTP id f8mr2104638lfl.161.1512029058484; Thu, 30 Nov 2017 00:04:18 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a15sm738359ljb.11.2017.11.30.00.04.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Nov 2017 00:04:17 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , References: In-Reply-To: Date: Thu, 30 Nov 2017 11:03:55 +0300 Message-ID: <010d01d369b1$c4cb1dd0$4e615970$@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: AQIATMar/Ak5qfmBt6ZHStgROknEOqLSxvQQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 08:04:22 -0000 Hi Paul, > We are looking at Opportunistic IPsec and supporting key rollover > support. In IKEv1, the initiator used the responder's key first, > and the responder could figure out which of its multiple keys the > initiator used. But in IKEv2, the responder uses one of their keys > and it does not really know which ones the initiator knows about. > > So we would like the initiator to indicate which key it is expecting > the peer to use. > > We could use the IDr payload in IKE_AUTH for that, using an ID_KEY_ID > type. But we would also really like to use the IDr payload on the > initiator to convey to the responder which FQDN we are expecting, so a > responder could use a different key for each FQDN it is responsible for. Doesn't ID_KEY_ID unambiguously determine the FQDN? I presume that you may have several keys for each FQDN (for key rollover), but each key is used for a single FQDN. If this is the case, then sending FQDN along with ID_KEY_ID in IDr looks superfluous - you should be able to always map ID_KEY_ID to FQDN. Moreover, while ID_KEY_ID is often an opaque data, an FQDN reveals perceived responder identity to an active attacker, so there are some privacy concerns... > While the responder could map ID_KEY_ID to FQDN's, it would be nice if > we could send both pieces of information from the initiator. I can see > a few ways of doing this: > > 1) Allow sending two IDr payloads in IKE_AUTH request > > 2) Add a new NOTIFY type that takes an IDr payload, then send the real > IDr payload and the NOTIFY containing the second IDr payload. > > 3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr > payload with that. > > 4) No change, use IDr ID_KEY_ID and leave it the implementer's problem > to figure out keyid -> FQDN. > > I've ordered these according to my preference. I'd like to hear other > people's view on this :) My preference is quite the opposite :-) Regards, Valery. From nobody Thu Nov 30 05:52:26 2017 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 B3AC212947C for ; Thu, 30 Nov 2017 05:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INP1x6uYhsup for ; Thu, 30 Nov 2017 05:52:24 -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 633D112946A for ; Thu, 30 Nov 2017 05:52:24 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ynf3T5qb9z3Ml; Thu, 30 Nov 2017 14:52:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1512049941; bh=ctRT3nnKPIlxAbIrTDwR8ccT2uC70DGBoQAdF2qmvEg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FV38luEZtLrg+NgF/OEshHyRWNE+vQ9Rit7r64ADSsnxXKl5sSCTx1Mz31/i5mZHD UhUBRWrOj2ouEWq69OfAy0MUGHEUQBv0DmlBZvEIJgbKDXszRTBWBYwsaXAw7MkaTv R5ng1u62y3hBh3PQWtRs537P8RtS2xNB7rf3iuSg= 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 iijbTD6EAYl3; Thu, 30 Nov 2017 14:52:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Nov 2017 14:52:19 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3836FA7FBF; Thu, 30 Nov 2017 08:52:18 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3836FA7FBF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3231E4B41F87; Thu, 30 Nov 2017 08:52:18 -0500 (EST) Date: Thu, 30 Nov 2017 08:52:18 -0500 (EST) From: Paul Wouters To: Valery Smyslov , David Schinazi cc: "ipsec@ietf.org WG" In-Reply-To: <010d01d369b1$c4cb1dd0$4e615970$@gmail.com> Message-ID: References: <010d01d369b1$c4cb1dd0$4e615970$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 13:52:26 -0000 On Thu, 30 Nov 2017, Valery Smyslov wrote: > Doesn't ID_KEY_ID unambiguously determine the FQDN? Yes, but indirectly and incoveniently. > Moreover, while ID_KEY_ID is often an opaque data, an FQDN > reveals perceived responder identity to an active attacker, > so there are some privacy concerns... Any internet-wide opportunistic method depends on some public method to find public keys, so that information, FQDN or opaque, is available to the attacker anyway. However, come to think of it, the IDr payload could help David for his hidden-in-TLS feature so it would not depend on PPK. Paul From nobody Thu Nov 30 08:51:22 2017 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 8C155120727 for ; Thu, 30 Nov 2017 08:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uLFx-HFND1gT for ; Thu, 30 Nov 2017 08:51:14 -0800 (PST) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 A7B1D1293E9 for ; Thu, 30 Nov 2017 08:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1512060669; 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=/MZBK5yP/WRNiTMjY+MZexelXYf4F/NgrNIUow5fqcU=; b=Hf9aoVQLYRQJx3HDoaJStoxDIz1oEextEwed+SSrd7BP3vjhx+A/br26nkOQDf6O 6YRK9K2NRYnvxA6iQ846Hj02Qw/K0rgJMvn7CskHVNgl0WO8CE2P1wJbT1tvOtqV xHdxr8Lo6JBSIvhYlwla91tvlqIj0u/kRBaE6I4FVxgbDVyeYzZ7ESwHlzby39k+ FGGxEJWTF34h0WI8gvd4vASJYi2tUIYytfWv04zvQR2tt+TW1jxYJr2rbp+Bh/Pu LMo8rf+LKb/z7YvcatZSiK4P7U3wnOJJhDf9txKxKHJUFcBXTrX/A2mEaQcOH+e7 vuP69/L/C2fGOupv3I+NhQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 1A.65.29340.CF6302A5; Thu, 30 Nov 2017 08:51:09 -0800 (PST) X-AuditID: 11ab0217-df6059c00000729c-44-5a2036fc608c Received: from koseret.apple.com (koseret.apple.com [17.151.62.39]) by relay3.apple.com (Apple SCV relay) with SMTP id 85.52.12852.CF6302A5; Thu, 30 Nov 2017 08:51:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.86.130] (unknown [17.234.86.130]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171102 64bit (built Nov 2 2017)) with ESMTPSA id <0P0800JG6PGY4I70@koseret.apple.com>; Thu, 30 Nov 2017 08:51:08 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Thu, 30 Nov 2017 08:50:57 -0800 Cc: Valery Smyslov , "ipsec@ietf.org WG" Message-id: <7F8B2603-B6AC-48FF-9522-52B419FDF40D@apple.com> References: <010d01d369b1$c4cb1dd0$4e615970$@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUi2FAYrPvXTCHKYPJtRov9W16wWby/dYnJ 4saHmWwOzB47Z91l91iy5CeTx/d5TAHMUVw2Kak5mWWpRfp2CVwZf07/ZCo4wlnxrecmewPj EfYuRk4OCQETifl/eoFsLg4hgTVMEh2/F7LAJJ7PuM0EkdjCKDH36Gw2kASvgKDEj8n3gIo4 OJgF5CUOnpcFCTMLaEl8f9TKAlHfyiTRPfk8M0hCWEBaouvCXVYI20Tiw8mD7CC9bEANB9YY gYQ5BRwlbn+bD3YQi4CqxPXVG5khZnpLrH7/ngVirY3E8QMw9yxllOide4ERJCEioCgx6cwj qKMVJY7MnMMMUiQhMIFN4vmzXqYJjMKzkNw9C+HuWUjuXsDIvIpRODcxM0c3M8/IWC+xoCAn VS85P3cTIyjcVzOJ72D8/NrwEKMAB6MSD+8EYYUoIdbEsuLK3EOM0hwsSuK82n7yUUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYbfJOyIneapvzvPzkjW1n7uwMf/zkSETr/o1Gnjeme+7+ o9wz7f/eiwoTTyg2JmTrL5yg+t1ibZ7Lz/RrGRtVktnK+9ZxcFoelz978nDDw7aTFdfOzssw UV8+u3Zvas0Fgai7j9NneT/Z15S97RqP+89VLU92zjNPOi3K8l+I9eB6H7sV6WbzBZRYijMS DbWYi4oTAVK3C/1YAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUiON1OXfePmUKUwcyPahb7t7xgs3h/6xKT xY0PM9kcmD12zrrL7rFkyU8mj+/zmAKYo7hsUlJzMstSi/TtErgy/pz+yVRwhLPiW89N9gbG I+xdjJwcEgImEs9n3GbqYuTiEBLYwigx9+hsNpAEr4CgxI/J91i6GDk4mAXkJQ6elwUJMwto SXx/1MoCUd/KJNE9+TwzSEJYQFqi68JdVgjbROLDyYPsIL1sQA0H1hiBhDkFHCVuf5sPtpdF QFXi+uqNzBAzvSVWv3/PArHWRuL4AZh7ljJK9M69wAiSEBFQlJh05hELxNGKEkdmzmGewCgw C8mpsxBOnYXk1AWMzKsYBYpScxIrjfUSCwpyUvWS83M3MYKCs6EweAfjn2VWhxgFOBiVeHgt BBWihFgTy4orcw8xSnAwK4nwKp+QjxLiTUmsrEotyo8vKs1JLT7EKM3BoiTO+2mleJSQQHpi SWp2ampBahFMlomDU6qBUe2Vza3Dxzi8ShecMpKYevQ1r8n2ZrcXb1JcNQJVOJqrJr29vu7x gekFCzOeX9mrWRx176JpbFbNi1L3lR2JQmns+0usFjOWbOjeV9pbtcEvYmXqcZ7swL/6CzXb Wlgv/YqfZiRlM/f8OsEtK0LOiFx8wvaCq8VtixwPy8JPPT6pofM/8d2aq8RSnJFoqMVcVJwI AKJp8I1KAgAA Archived-At: Subject: Re: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 16:51:21 -0000 Hi Paul, Regarding the original email, I'm not a fan of (1) as then implementations have to handle receiving two different FQDN IDr's for example. Having something like (2) where the new notify can only appear once and it explicitly is there to select the key sounds best IMHO. Regarding the hidden-in-TLS feature (I like that name, thanks Paul), I don't think this would help as the goal is to not reply to SA_INIT from an untrusted party so changing the AUTH is too late. David > On Nov 30, 2017, at 05:52, Paul Wouters wrote: > > On Thu, 30 Nov 2017, Valery Smyslov wrote: > >> Doesn't ID_KEY_ID unambiguously determine the FQDN? > > Yes, but indirectly and incoveniently. > >> Moreover, while ID_KEY_ID is often an opaque data, an FQDN >> reveals perceived responder identity to an active attacker, >> so there are some privacy concerns... > > Any internet-wide opportunistic method depends on some public method to > find public keys, so that information, FQDN or opaque, is available > to the attacker anyway. > > However, come to think of it, the IDr payload could help David for his > hidden-in-TLS feature so it would not depend on PPK. > > Paul From nobody Thu Nov 30 08:56:57 2017 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 1BABA1287A5 for ; Thu, 30 Nov 2017 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbqruqjJAK9M for ; Thu, 30 Nov 2017 08:56:54 -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 A436E1200FC for ; Thu, 30 Nov 2017 08:56:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ynk8N4wrnz3Nt; Thu, 30 Nov 2017 17:56:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1512061012; bh=6a4p3JO7/GOOxUA+XY3AeNl71/g3BKK47+5SJ9tbIuQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SYcPtHUECp0x60rbrTH5FkCfz5kiUohHeWWrpOkFUqzRr946TH7LdgZuVPERejCST 116dtSCDHf7XMfEzUDzD9V9By/8B51II0cy3sBemF+J94PbxZ3mbK3eOzXzQBUMo1v 7SSPoyXQKDNwnx60kXvJRemxHJzUcKER8GuapRKo= 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 W6Yvb-1bdtt0; Thu, 30 Nov 2017 17:56:51 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Nov 2017 17:56:49 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DF65F92C; Thu, 30 Nov 2017 11:56:47 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DF65F92C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D87AF4B41F8D; Thu, 30 Nov 2017 11:56:47 -0500 (EST) Date: Thu, 30 Nov 2017 11:56:47 -0500 (EST) From: Paul Wouters To: David Schinazi cc: "ipsec@ietf.org WG" In-Reply-To: <7F8B2603-B6AC-48FF-9522-52B419FDF40D@apple.com> Message-ID: References: <010d01d369b1$c4cb1dd0$4e615970$@gmail.com> <7F8B2603-B6AC-48FF-9522-52B419FDF40D@apple.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 16:56:56 -0000 On Thu, 30 Nov 2017, David Schinazi wrote: > Regarding the original email, I'm not a fan of (1) as then implementations > have to handle receiving two different FQDN IDr's for example. > Having something like (2) where the new notify can only appear once > and it explicitly is there to select the key sounds best IMHO. Thanks :) > Regarding the hidden-in-TLS feature (I like that name, thanks Paul), > I don't think this would help as the goal is to not reply to SA_INIT from an > untrusted party so changing the AUTH is too late. Ohh, that's correct.... Paul From nobody Thu Nov 30 15:41:58 2017 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 D0E8C124D68 for ; Thu, 30 Nov 2017 15:41:56 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsXl23dhTwJ4 for ; Thu, 30 Nov 2017 15:41:54 -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 8F14D120046 for ; Thu, 30 Nov 2017 15:41:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ynv7g4vh7z3sZ; Fri, 1 Dec 2017 00:41:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1512085311; bh=ZTN80/wnBOHVmjbPaQ2dZjK/gSmeI/Vppf+cQLKIWe0=; h=Date:From:To:cc:Subject; b=fOItTKFB/0wuZzc+9CxqEpo6VJ7YVuLjzrWaO1KdC4DzJKou4BF/AttZlcY7iqxq/ LntTrjpdJAFT/l8QBXWWFumbAXv0UsNw/DqfEbmHOj/BE/+eW2470Qb2aWBguShUMC FBtAFwJvvQRmdyOOppLXlSWMT3Wb2FYfgX6WCN5s= 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 x_8dJ_uld6_i; Fri, 1 Dec 2017 00:41:49 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 1 Dec 2017 00:41:49 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E25EB428283; Thu, 30 Nov 2017 18:41:47 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E25EB428283 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D59F24B41F95; Thu, 30 Nov 2017 18:41:47 -0500 (EST) Date: Thu, 30 Nov 2017 18:41:47 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Tero Kivinen Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] draft-ietf-ipsecme-qr-ikev2-00 interop and test server X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 23:41:57 -0000 Since we interoperated with Tommy, I think we are getting in pretty good shape with the document. If you want to test the PPK interop, you can use the following test server: server: vpn-ppk.nohats.ca server id: vpn-ppk.nohats.ca (ID_FQDN) group id (client id): GroupPPK1 PSK: "SecretPSK" PPKID: "PPKID1" of type PPK_ID_OPAQUE PPK: "NotQuantumSafe" Notify payload private numbers used: PPK_SUPPORT = 40960 PPK_IDENTITY = 40961 Oterwise, it is a standard remote access configuration. You will get an IP from the server, with 0.0.0.0/0 as the remote network and DNS assigned via CP payloads. Tero, are we in a state where you as Expert would be willing to do Early Codepoints? Paul & Vukasin From nobody Thu Nov 30 15:43:14 2017 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 C4047124D68 for ; Thu, 30 Nov 2017 15:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePItnXOePvR4 for ; Thu, 30 Nov 2017 15:43:11 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 894F81270A7 for ; Thu, 30 Nov 2017 15:43:10 -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 vAUNh5MW029080 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Dec 2017 01:43:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vAUNh59f008848; Fri, 1 Dec 2017 01:43:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23072.38793.121465.972588@fireball.acr.fi> Date: Fri, 1 Dec 2017 01:43:05 +0200 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 11 min Archived-At: Subject: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 23:43:13 -0000 Paul Wouters writes: > We could use the IDr payload in IKE_AUTH for that, using an ID_KEY_ID > type. But we would also really like to use the IDr payload on the > initiator to convey to the responder which FQDN we are expecting, so a > responder could use a different key for each FQDN it is responsible for. > > While the responder could map ID_KEY_ID to FQDN's, it would be nice if > we could send both pieces of information from the initiator. I can see > a few ways of doing this: > > 1) Allow sending two IDr payloads in IKE_AUTH request This will most likely break lots of implementations, and as this happens before peer is authenticated, some of the will silently just drop packets with generate INVALID_SYNTAX, i.e., which do not match the payload patterns expected by recipient. This would mean there would need to be yet another negotiation before this feature could be used. > 2) Add a new NOTIFY type that takes an IDr payload, then send the real > IDr payload and the NOTIFY containing the second IDr payload. I think this is bad idea. Hiding information in notify is bad idea. > 3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr > payload with that. This is better option, as implementations should ignore IDr payload they do not understand and fall back as their normal use. On the other hand as you are talking about OE here, you could simply reuse the ID_RFC822_ADDR type, and send @ identities in there. Or if you might also have real users in addition to OE users, add suitable prefix to email address, for example: oe-keyid+@ > 4) No change, use IDr ID_KEY_ID and leave it the implementer's problem > to figure out keyid -> FQDN. ID_KEY_ID can have also have structure, it is opaque string which is interpreted as the vendor feels like to interpret it. This means you can format the ID_KEY_ID in whatever format you like, examples being: 01keyidfqdn.example.net or od or use json, asn.1, or whatever format is suitable for you. It all depends how your client gets this. If it just gets this from the server as binary blob, and reflects it back on IKE_AUTH, the only end which needs to know how to interpret the ID_KEY_ID blob is the server. If the client needs to construct this from separate pieces, i.e., then it needs to know the format. -- kivinen@iki.fi From nobody Thu Nov 30 15:49:49 2017 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 144D51252BA for ; Thu, 30 Nov 2017 15:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx536hAZGfMI for ; Thu, 30 Nov 2017 15:49:47 -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 C5504120046 for ; Thu, 30 Nov 2017 15:49:46 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ynvJk2wZMz3sZ; Fri, 1 Dec 2017 00:49:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1512085782; bh=wvU/hoJLwHsAKUQJPGPqJ/sVtjQkUcMtNkDt31suW8w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Yi6I1MMYjHU8GSXh2ZDLrx6+c5j8AYJrf1NyYgLRIt9r5ZuUeMwN7ymi8N57dRQBm pXiP2r5Rmlw2b0+K47AZzw1W63IEpCaG65ASBZHK0SJa5AYY15+kqFQIu8GXl4KORY mnnbrzO5HLAxybsijc0gn6CZD1mzGTdYviFi8D5U= 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 Thj10QCoijcU; Fri, 1 Dec 2017 00:49:40 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 1 Dec 2017 00:49:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 82F45428283; Thu, 30 Nov 2017 18:49:39 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 82F45428283 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 716EB40D6F5A; Thu, 30 Nov 2017 18:49:39 -0500 (EST) Date: Thu, 30 Nov 2017 18:49:39 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <23072.38793.121465.972588@fireball.acr.fi> Message-ID: References: <23072.38793.121465.972588@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Key rollover and IDr payload(s) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 23:49:48 -0000 On Fri, 1 Dec 2017, Tero Kivinen wrote: >> 1) Allow sending two IDr payloads in IKE_AUTH request > > This will most likely break lots of implementations, and as this > happens before peer is authenticated, some of the will silently just > drop packets with generate INVALID_SYNTAX, i.e., which do not match > the payload patterns expected by recipient. This would mean there > would need to be yet another negotiation before this feature could be > used. True.... >> 2) Add a new NOTIFY type that takes an IDr payload, then send the real >> IDr payload and the NOTIFY containing the second IDr payload. > > I think this is bad idea. Hiding information in notify is bad idea. Yes, but... >> 3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr >> payload with that. > > This is better option, as implementations should ignore IDr payload > they do not understand and fall back as their normal use. > > On the other hand as you are talking about OE here, you could simply > reuse the ID_RFC822_ADDR type, and send > > @ Ohh, keyid@fqdn is actually a nice idea. I like it! > identities in there. Or if you might also have real users in addition > to OE users, add suitable prefix to email address, for example: > > oe-keyid+@ hmmmm. >> 4) No change, use IDr ID_KEY_ID and leave it the implementer's problem >> to figure out keyid -> FQDN. > > ID_KEY_ID can have also have structure, it is opaque string which is > interpreted as the vendor feels like to interpret it. This means you > can format the ID_KEY_ID in whatever format you like, examples being: > > 01keyidfqdn.example.net But this is as bad as using private values and hoping for interop. Any structures used that are not defined in an RFC won't interop. > or use json, asn.1, or whatever format is suitable for you. It all > depends how your client gets this. We want to leave that open. Right now this is for when using DNSSEC, but if people want to pull stuff from a blockchain or whatever is sexy tomorrow, that should be possible too. For CERT based OE, this is not a problem unless you want to roll your CA, but I can't think about that scenario right now :) Thanks for the feedback! Paul