From openpgp@brainhub.org Wed Jan 2 23:07:03 2013 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 0505A21F8917 for ; Wed, 2 Jan 2013 23:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2vGcA-n9l13 for ; Wed, 2 Jan 2013 23:07:02 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83C21F88F1 for ; Wed, 2 Jan 2013 23:07:02 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id jK2o1k0051zF43QA3K71ST; Thu, 03 Jan 2013 07:07:01 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta24.emeryville.ca.mail.comcast.net with comcast id jK701k0052g33ZR8kK71kj; Thu, 03 Jan 2013 07:07:01 +0000 Message-ID: <50E52E14.5080603@brainhub.org> Date: Wed, 02 Jan 2013 23:07:00 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357196821; bh=QtljU/MwWYppd9DPd41b0D60S1N5M2HE4xwWhvKO6ho=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mnl8AM9/9QdGR4fMVaO1EQFCmCZGcvexq2K0lUM6MZKO5vZ/lUpqkcc4O5tYjl1ih tqlV4hwP+abXl26NCxZxCcktUnF9LQylgkFpGs16S0spds9eBr9DhOtRV02mMhAs6x 3rbH1fNyN0UYucPDTTQNfRpTfMOiH0ToN7Ivq4ExUresbMeZQGsJBsBM8kF7H1d+Hw T+v+1HNJCqdcsaU7ZyUDAoUch2iK/GhutodRiFchw7uef592c08kCcatA2+XJ3C9ge D1DEHLURNgScyomXEn7vaZWoMO5e7dp0OfaOSeiffVgh/Ylhte+eowtZ+lm6e9+6r0 gp26penBD9tFg== X-Mailman-Approved-At: Thu, 03 Jan 2013 09:55:16 -0800 Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 07:07:03 -0000 Sorry for bringing up this so late, but I just noticed the discussion about the point compression in this thread. I posted the "Compact representation of an elliptic curve point" http://tools.ietf.org/html/draft-jivsov-ecc-compact that I think is helpful as a generic definition of a compressed point. I know that https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ -03 moved away from the compressed representation, but the preceding discussion is one of the reasons why I created this draft. It's unfortunate that with current state of ECC at IETF there is always an uncertainty/complexity such as "do we use an uncompressed point or compressed point; and there is IPR". There is also an issue of what's hashed and how the {x,y} is encoded. In the end in practice this means that there is no compression used. I want to add as an alternative point of view that for new features or protocols there is also a way to reduce complexity by using only the compact point representation, such as in http://tools.ietf.org/html/draft-jivsov-ecc-compact. From Johannes.Merkle@secunet.com Fri Jan 4 04:10:11 2013 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 6707721F85DF for ; Fri, 4 Jan 2013 04:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pHKqf-IfTjj for ; Fri, 4 Jan 2013 04:10:10 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3703F21F85D0 for ; Fri, 4 Jan 2013 04:10:05 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 65D091A0080; Fri, 4 Jan 2013 13:10:03 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 831D61A007F; Fri, 4 Jan 2013 13:10:01 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jan 2013 13:10:01 +0100 Message-ID: <50E6C698.10809@secunet.com> Date: Fri, 04 Jan 2013 13:10:00 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrey Jivsov References: <50E52E14.5080603@brainhub.org> In-Reply-To: <50E52E14.5080603@brainhub.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2013 12:10:01.0356 (UTC) FILETIME=[6C0DC4C0:01CDEA74] Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:10:11 -0000 Hi Andrey, point compression has been deleted from the draft due to the strong objections in this WG. The possibility to choose from two distinct encodings was considered inappropriate complexity given the limited benefit. Generally, I think that your draft has its value, albeit probably not for IKE. Some nits: Line 256: Recall that the x is an integer in the underlying finite field. should be Recall that the x is an element in the underlying finite field represented by an integer. ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ Line 352: When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves should be When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves ^^^^^^^ ^^^ Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the private key in Section 4.2 Section 5: First, key pairs must be generated as defined in Section 4.2 to allow compact representation. But, as you have pointed out in Section 3: Some protocols, such as ECDH, don't depend on the exact value of the y. Thus, in these protocols, it does not matter, if the key is "compliant" or not. This should be explained, not only in Section 5 but also in the beginning of Section 4.2. regards, Johannes Andrey Jivsov schrieb am 03.01.2013 08:07: > Sorry for bringing up this so late, but I just noticed the discussion about the point compression in this thread. > > I posted the "Compact representation of an elliptic curve point" http://tools.ietf.org/html/draft-jivsov-ecc-compact > that I think is helpful as a generic definition of a compressed point. > > I know that https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ -03 moved away from the compressed > representation, but the preceding discussion is one of the reasons why I created this draft. It's unfortunate that with > current state of ECC at IETF there is always an uncertainty/complexity such as "do we use an uncompressed point or > compressed point; and there is IPR". There is also an issue of what's hashed and how the {x,y} is encoded. In the end in > practice this means that there is no compression used. > > I want to add as an alternative point of view that for new features or protocols there is also a way to reduce > complexity by using only the compact point representation, such as in http://tools.ietf.org/html/draft-jivsov-ecc-compact. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From openpgp@brainhub.org Fri Jan 4 12:23:48 2013 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 CBD4D21F8853 for ; Fri, 4 Jan 2013 12:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96XxUCI9eUTX for ; Fri, 4 Jan 2013 12:23:44 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id C54BC21F8846 for ; Fri, 4 Jan 2013 12:23:44 -0800 (PST) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta11.emeryville.ca.mail.comcast.net with comcast id jwLA1k0040cQ2SLABwPk2l; Fri, 04 Jan 2013 20:23:44 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta10.emeryville.ca.mail.comcast.net with comcast id jwPj1k0052g33ZR8WwPjBz; Fri, 04 Jan 2013 20:23:44 +0000 Message-ID: <50E73A4F.2020403@brainhub.org> Date: Fri, 04 Jan 2013 12:23:43 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Johannes Merkle References: <50E52E14.5080603@brainhub.org> <50E6C698.10809@secunet.com> In-Reply-To: <50E6C698.10809@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357331024; bh=/Swz7ng/iAGUhNZJ0z4inWyO2IlumRBBs2zOBrWjcDA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e1aqrVD11fQB+DiT8kqLvIaIR5WHKfVTQI9JOlLEuG/tn4RKGyAs5pM+GEpNSks+L /WceOBeRltklRVZOUIVf0y8IiS7S3LwvHYO3tbuovbVRpO9H8axdjL64oSq1dqJb/G x2PjSMcpItGCwfpTdbyAG3V7TaYEE0dSdWjWGiyKXOOA4+N4kcNIEFhfGavaLYC9lT MPkYjgXoV4LmYi4WwHeT3K3mBNU+CfEWZlECsGLT9gz23CT2Zr99qVSPNRgumEVema tWsvRBU2OegVbkCTGrMW0ZuokroHGK48qHjH9eXGQ2+lZM0HI/xM939sXm/Oki9DrC 0BV1n5h/nwb1A== X-Mailman-Approved-At: Sat, 05 Jan 2013 08:32:53 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:23:48 -0000 Thank you, Johannes, for your comments. I will integrate them in the next revision. I do agree that for online protocols like IKE and TLS the point compression of the ephemeral ECDH is not that beneficial. Point compression is more beneficial for storage security for reasons of performance and storage efficiency. For storage efficiency side: when there are multiple recipients per message, each associated with one ECDH-related field, it's possible for ECDH-specific payload to get arbitrary large for a fixed short message. For the performance argument: if the message was encrypted to N recipients, to decode it only one recipient will be used, and thus the calculation of 'y' is done once but the space is saved for N. Even for certificates that have one public key there is some benefit, given that the certificates are pre-precessed for chain validation and are often cached. On 01/04/2013 04:10 AM, Johannes Merkle wrote: > Hi Andrey, > > point compression has been deleted from the draft due to the strong objections in this WG. The possibility to choose > from two distinct encodings was considered inappropriate complexity given the limited benefit. > > Generally, I think that your draft has its value, albeit probably not for IKE. > > Some nits: > Line 256: > Recall that the x is an integer in the underlying finite field. > should be > Recall that the x is an element in the underlying finite field represented by an integer. > ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ > Line 352: > When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves > should be > When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves > ^^^^^^^ ^^^ > Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the private key in Section 4.2 > > Section 5: > First, key pairs must be generated as defined in Section 4.2 to allow > compact representation. > But, as you have pointed out in Section 3: > Some protocols, such as ECDH, don't depend on the exact value of > the y. > Thus, in these protocols, it does not matter, if the key is "compliant" or not. This should be explained, not only in > Section 5 but also in the beginning of Section 4.2. > > regards, > Johannes > > > Andrey Jivsov schrieb am 03.01.2013 08:07: >> Sorry for bringing up this so late, but I just noticed the discussion about the point compression in this thread. >> >> I posted the "Compact representation of an elliptic curve point" http://tools.ietf.org/html/draft-jivsov-ecc-compact >> that I think is helpful as a generic definition of a compressed point. >> >> I know that https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ -03 moved away from the compressed >> representation, but the preceding discussion is one of the reasons why I created this draft. It's unfortunate that with >> current state of ECC at IETF there is always an uncertainty/complexity such as "do we use an uncompressed point or >> compressed point; and there is IPR". There is also an issue of what's hashed and how the {x,y} is encoded. In the end in >> practice this means that there is no compression used. >> >> I want to add as an alternative point of view that for new features or protocols there is also a way to reduce >> complexity by using only the compact point representation, such as in http://tools.ietf.org/html/draft-jivsov-ecc-compact. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> From kent@bbn.com Mon Jan 7 07:52:12 2013 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 2565421F8782 for ; Mon, 7 Jan 2013 07:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXBdkOgN5ary for ; Mon, 7 Jan 2013 07:52:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0C21F875A for ; Mon, 7 Jan 2013 07:52:11 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:52642 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TsEzh-000AwS-P9; Mon, 07 Jan 2013 10:52:09 -0500 Message-ID: <50EAEF28.2040502@bbn.com> Date: Mon, 07 Jan 2013 10:52:08 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrey Jivsov , ipsec References: <50E52E14.5080603@brainhub.org> <50E6C698.10809@secunet.com> <50E73A4F.2020403@brainhub.org> In-Reply-To: <50E73A4F.2020403@brainhub.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:52:12 -0000 On 1/4/13 3:23 PM, Andrey Jivsov wrote: > ... > > Point compression is more beneficial for storage security for reasons > of performance and storage efficiency. For storage efficiency side: > when there are multiple recipients per message, each associated with > one ECDH-related field, it's possible for ECDH-specific payload to get > arbitrary large for a fixed short message. For the performance > argument: if the message was encrypted to N recipients, to decode it > only one recipient will be used, and thus the calculation of 'y' is > done once but the space is saved for N. Are you confident that this attempt at space efficiency is consistent with S/MIME processing rules? Or are you suggesting that S/MIME and other secure email standards become alg-specific to take advantage of this optimization? > > Even for certificates that have one public key there is some benefit, > given that the certificates are pre-precessed for chain validation and > are often cached. Most IETF security protocols make use of X.509 (PKIX) certs. X.509 certs always contain just one key. So I'm puzzled by the phrase "Even for certificates that have one public key ..." Steve From openpgp@brainhub.org Mon Jan 7 10:32:47 2013 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 29DD321F882E for ; Mon, 7 Jan 2013 10:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3gc0aUdRih2 for ; Mon, 7 Jan 2013 10:32:46 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id A99B221F882B for ; Mon, 7 Jan 2013 10:32:46 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta02.emeryville.ca.mail.comcast.net with comcast id l4uZ1k0041vN32cA26YmXm; Mon, 07 Jan 2013 18:32:46 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta22.emeryville.ca.mail.comcast.net with comcast id l6Yl1k00T2g33ZR8i6YllT; Mon, 07 Jan 2013 18:32:46 +0000 Message-ID: <50EB1474.1030702@brainhub.org> Date: Mon, 07 Jan 2013 10:31:16 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stephen Kent References: <50E52E14.5080603@brainhub.org> <50E6C698.10809@secunet.com> <50E73A4F.2020403@brainhub.org> <50EAEF28.2040502@bbn.com> In-Reply-To: <50EAEF28.2040502@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357583566; bh=TKh1XzvZdw0nTmyQSAGqswsEgzSzOTaP/P5yE+k1k6c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tLf/lWdl1E1dpECRQ1HBGo8bY7ikrZQDg15e6/Udh/ehLU5IShhk2oFutW9R4MN8q z/H3Ct4U2pXpEXip6cE/uIenqYJK+RFCrjoDN1wy1PjrzzYSFLaD0G67INu6qoa8Os Wh+0EZaqkAggcYZzegwamRqKB8lQtppPb4P4F11shO0c7UO7e7BrFtY8vo10nj5fmW IsuNgS7l+NKRdr7ahTmU9pEhUdIHPmuXnGIpEWXVZpeco4y6JE8vpLfVaE+IOxzvka otBq4hNhQGtJstrX6K3aeciUDRLubuGZKiNjrP55LWtf0J0c7CLDuR8wYPhWtuyArV jo8YLIZ3V74JA== Cc: ipsec Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 18:32:47 -0000 On 01/07/2013 07:52 AM, Stephen Kent wrote: > > On 1/4/13 3:23 PM, Andrey Jivsov wrote: >> ... >> >> Point compression is more beneficial for storage security for reasons >> of performance and storage efficiency. For storage efficiency side: >> when there are multiple recipients per message, each associated with >> one ECDH-related field, it's possible for ECDH-specific payload to get >> arbitrary large for a fixed short message. For the performance >> argument: if the message was encrypted to N recipients, to decode it >> only one recipient will be used, and thus the calculation of 'y' is >> done once but the space is saved for N. > Are you confident that this attempt at space efficiency is consistent > with S/MIME processing rules? > Or are you suggesting that S/MIME and other secure email standards > become alg-specific to take > advantage of this optimization? If you are asking if my proposal is compatible with the current format that IETF standards use, which is by and large is SEC1, then, no, my proposal is not binary identical to the SEC1. The issue of this interoperability is discussed in the spec. While I believe that my proposal, which is written for modp curves, is superior to (modp subset of) SEC1, I realize that adding an alternative compact representation / point compression to existing standards is an uphill battle. For existing standards that define some point compression I would only say that if one finds that the point compression is not actually used / configured in real-world implementations, please take a look at my proposal as it may be a format that will eventually find its way into the implementations if standardized (IPR issues is one such a concern). For any new format / protocol / feature, RFC 6090 + http://tools.ietf.org/html/draft-jivsov-ecc-compact should be a more natural path. >> Even for certificates that have one public key there is some benefit, >> given that the certificates are pre-precessed for chain validation and >> are often cached. > Most IETF security protocols make use of X.509 (PKIX) certs. X.509 certs > always contain just one key. > So I'm puzzled by the phrase "Even for certificates that have one public > key ..." I agree that the statement was unclear. I was saying that because the certificates contain only one public key, the space saving is only size-of-the-curve+1 byte per certificate. Nonetheless, given that certificates need to be pre-processed and validated, and these results are often cached, the overhead of calculation of the 'y' is probably not material. From Johannes.Merkle@secunet.com Tue Jan 8 02:22:04 2013 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 B90CD21F84D9 for ; Tue, 8 Jan 2013 02:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMlXJBWqP8dF for ; Tue, 8 Jan 2013 02:22:04 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF3A21F84D0 for ; Tue, 8 Jan 2013 02:22:02 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id A31FD1A0079; Tue, 8 Jan 2013 11:22:00 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 17E701A0076; Tue, 8 Jan 2013 11:21:58 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jan 2013 11:21:57 +0100 Message-ID: <50EBF345.5020106@secunet.com> Date: Tue, 08 Jan 2013 11:21:57 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrey Jivsov References: <50E52E14.5080603@brainhub.org> <50E6C698.10809@secunet.com> <50E73A4F.2020403@brainhub.org> <50EAEF28.2040502@bbn.com> <50EB1474.1030702@brainhub.org> In-Reply-To: <50EB1474.1030702@brainhub.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2013 10:21:57.0796 (UTC) FILETIME=[FD340640:01CDED89] Cc: ipsec , Stephen Kent Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:22:04 -0000 Andrey, > > For any new format / protocol / feature, RFC 6090 + http://tools.ietf.org/html/draft-jivsov-ecc-compact should be a more > natural path. Well, RFC 6090 is not always a good reference, at least it is very unfortunate that the signature scheme KT-I is not fully compatible with ECDSA (Errata 2777). > I agree that the statement was unclear. I was saying that because the certificates contain only one public key, the > space saving is only size-of-the-curve+1 byte per certificate. Nonetheless, given that certificates need to be > pre-processed and validated, and these results are often cached, the overhead of calculation of the 'y' is probably not > material. For X.509 certificates, the ANSI format is already well established, so the alternative method is hardly relevant there. As you said, it is more a suggestion to consider for new specifications. -- Johannes From kent@bbn.com Tue Jan 8 08:52:14 2013 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 D660B11E80D5 for ; Tue, 8 Jan 2013 08:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1RO3roC3-CN for ; Tue, 8 Jan 2013 08:52:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0B14C11E8097 for ; Tue, 8 Jan 2013 08:52:13 -0800 (PST) Received: from dhcp89-089-242.bbn.com ([128.89.89.242]:50306) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TscPK-0004Ee-Pu; Tue, 08 Jan 2013 11:52:10 -0500 Message-ID: <50EC4EB9.2060204@bbn.com> Date: Tue, 08 Jan 2013 11:52:09 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Johannes Merkle References: <50E52E14.5080603@brainhub.org> <50E6C698.10809@secunet.com> <50E73A4F.2020403@brainhub.org> <50EAEF28.2040502@bbn.com> <50EB1474.1030702@brainhub.org> <50EBF345.5020106@secunet.com> In-Reply-To: <50EBF345.5020106@secunet.com> Content-Type: multipart/alternative; boundary="------------020201080301080003010606" Cc: ipsec , Andrey Jivsov Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:52:14 -0000 This is a multi-part message in MIME format. --------------020201080301080003010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, I think my initial concern has been misunderstood, or maybe I misunderstood the purported benefits of the proposed mechanism. When I asked about compatibility with existing S/MIME specs, I was not referring to details of how the EC public key is represented in a cert, per se. Andrey's message on 1/4 said: "Point compression is more beneficial for storage security for reasons of performance and storage efficiency. For storage efficiency side: when there are multiple recipients per message, each associated with one ECDH-related field, it's possible for ECDH-specific payload to get arbitrary large for a fixed short message. For the performance argument: *if the message was encrypted to N recipients, to decode it only one recipient will be used, and thus the calculation of 'y' is done once but the space is saved for N. * My question was whether this technique, in bold above, is compatible with the current, normal processing for S/MINE, or whether it would require S/MIME to operate differently (at the originator or at any recipient) in order to reduce the overhead in the fashion alluded to above. I don;t think that question has been answered. Steve --------------020201080301080003010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,

I think my initial concern has been misunderstood, or maybe I misunderstood the
purported benefits of the proposed mechanism.

When I asked about compatibility with existing S/MIME specs, I was not referring to
details of how the EC public key is represented in  a cert, per se.

Andrey's message on 1/4 said:

"Point compression is more beneficial for storage security for reasons of performance and storage efficiency. For storage efficiency side: when there are multiple recipients per message, each associated with one ECDH-related field, it's possible for ECDH-specific payload to get arbitrary large for a fixed short message. For the performance argument: if the message was encrypted to N recipients, to decode it only one recipient will be used, and thus the calculation of 'y' is done once but the space is saved for N.

My question was whether this technique, in bold above, is compatible with the current, normal
processing for S/MINE, or whether it would require S/MIME to operate differently (at the originator
or at any recipient) in order to reduce the overhead in the fashion alluded to above.

I don;t think that question has been answered.

Steve
--------------020201080301080003010606-- From openpgp@brainhub.org Tue Jan 8 11:38:14 2013 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 5CE0821F8578 for ; Tue, 8 Jan 2013 11:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_31=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ribHggKBDiRa for ; Tue, 8 Jan 2013 11:38:13 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8B98921F8542 for ; Tue, 8 Jan 2013 11:38:13 -0800 (PST) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta06.emeryville.ca.mail.comcast.net with comcast id lVuf1k0081bwxycA6XeDjb; Tue, 08 Jan 2013 19:38:13 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta18.emeryville.ca.mail.comcast.net with comcast id lXeB1k00V2g33ZR8eXeCbL; Tue, 08 Jan 2013 19:38:13 +0000 Message-ID: <50EC74F5.2040605@brainhub.org> Date: Tue, 08 Jan 2013 11:35:17 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stephen Kent References: <50E52E14.5080603@brainhub.org> <50E6C698.10809@secunet.com> <50E73A4F.2020403@brainhub.org> <50EAEF28.2040502@bbn.com> <50EB1474.1030702@brainhub.org> <50EBF345.5020106@secunet.com> <50EC4EB9.2060204@bbn.com> In-Reply-To: <50EC4EB9.2060204@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357673893; bh=Rxi0upSCOPhbgWqV+v+A4UqkoHa2DUFDMbc17ZbRg04=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ay3YO3mljExMhqG2NOvWA2bF+1cfC+ob+uAgoOJ2qMG9F8btOIyZUpEorHNJ1jcsh Zq7qz1s84ZrYv4++lGauhy1B0S3Ml4NyEC3N/nm10qyX0z1Ty7RtOyhJqDBPj7VadJ b9JKCIvw5EmOtYXqkq/FKcqsDpOqaNWOtfB7JmVMBwSIWdFQAo0Ksv6F/KrJsKAYOu uayHO6BEbhp/UfJgKi1NVZwd4OAdKENOmQGt2CkdEDJw7yJojZupJdMPOn+Cw3DYtF tZATT8WlgwEtWMjN6rSOIO6Ka9IbmTYFBKImy1ZumgDa6HcJp59KGIsuu3UV0EARjO dHDs7IdBcrxfA== Cc: ipsec , Johannes Merkle Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 19:38:14 -0000 I believe that the compact representation of the point documented here http://tools.ietf.org/html/draft-jivsov-ecc-compact is suitable for any IETF protocol. It doesn't expect changes of processing rules, that would be a non-starter. For example, consider how it would work for IKE http://tools.ietf.org/html/rfc4753. Section 7 tells that IKE KE uses x|y sequence. My proposal would change it to x. The bring a question of "isn't there up to 1 bit of entropy present in y"? I prove in the spec that it's valued as zero, i.e. it doesn't add anything to the security. Regardless, of the answer to whether there is 0 or 1 of entropy present in y, the ambiguity of y/-y must be resolved and the method I propose does so by a minor tweak to the key generation, to generate a "compliant" key ( As a matter of fact, no tweaks are needed for ECDH keys, only for ECDSA keys. ECDH keys are always "compliant" when only the x of the shared point is used. ) This means that the IKE initiators and responders generate their ephemeral keys in such a way that the simple dropping of the y is what constitutes the compact representation. This works the same way for SMIME with ECDH. Sender is free to generate a "compliant" ephemeral ECDH and the rest of processing rules are identical to current SMIME with point compression method. BTW, I believe that a crypto software should always generate only "compliant" ECC keys, because there is no loss of security in doing so. Then the compact representation is worry free and is never conditioned on the type of the key. On 01/08/2013 08:52 AM, Stephen Kent wrote: > Folks, > > I think my initial concern has been misunderstood, or maybe I > misunderstood the > purported benefits of the proposed mechanism. > > When I asked about compatibility with existing S/MIME specs, I was not > referring to > details of how the EC public key is represented in a cert, per se. > > Andrey's message on 1/4 said: > > "Point compression is more beneficial for storage security for reasons > of performance and storage efficiency. For storage efficiency side: when > there are multiple recipients per message, each associated with one > ECDH-related field, it's possible for ECDH-specific payload to get > arbitrary large for a fixed short message. For the performance argument: > *if the message was encrypted to N recipients, to decode it only one > recipient will be used, and thus the calculation of 'y' is done once but > the space is saved for N. * > > My question was whether this technique, in bold above, is compatible > with the current, normal > processing for S/MINE, or whether it would require S/MIME to operate > differently (at the originator > or at any recipient) in order to reduce the overhead in the fashion > alluded to above. > > I don;t think that question has been answered. > > Steve From wwwrun@rfc-editor.org Wed Jan 9 04:03:27 2013 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 3A3EC21F86F6 for ; Wed, 9 Jan 2013 04:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoOwMTvY7NNf for ; Wed, 9 Jan 2013 04:03:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BF85621F86E8 for ; Wed, 9 Jan 2013 04:03:26 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 51DCAB1E002; Wed, 9 Jan 2013 03:53:04 -0800 (PST) To: ynir@checkpoint.com, wierbows@us.ibm.com, fd@cisco.com, psethi@cisco.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com From: RFC Errata System Message-Id: <20130109115304.51DCAB1E002@rfc-editor.org> Date: Wed, 9 Jan 2013 03:53:04 -0800 (PST) X-Mailman-Approved-At: Wed, 09 Jan 2013 04:15:12 -0800 Cc: ipsec@ietf.org, valery@smyslov.net, rfc-editor@rfc-editor.org Subject: [IPsec] [Technical Errata Reported] RFC6290 (3448) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 12:03:27 -0000 The following errata report has been submitted for RFC6290, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6290&eid=3448 -------------------------------------- Type: Technical Reported by: Valery Smyslov Section: 4.3 Original Text ------------- For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. Corrected Text -------------- For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new QCD_TOKEN in the IKE_AUTH exchange that immediately followes the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in the same IKE_AUTH exchange. Notes ----- Original text mixes up terms "ticket" (as Session Resumption ticket from RFC5723) and "token" (as QCD token from this RFC). As QCD token must never be sent in an unprotected message (see section 9.2 from this RFC) it cannot be sent in the IKE_SESSION_RESUME exchange because this exchange is done in clear. So, QCD token must be sent in the IKE_AUTH exchange that immediately followes the IKE_SESSION_RESUME exchange. In this case there is no need for the separate INFORMATIONAL exchange the Initiator's QCD token (if any) to be sent in, because it could be sent in the same IKE_AUTH exchange. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6290 (draft-ietf-ipsecme-failure-detection-08) -------------------------------------- Title : A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Publication Date : June 2011 Author(s) : Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From yaronf.ietf@gmail.com Wed Jan 9 04:13:25 2013 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 D7A8C21F8712 for ; Wed, 9 Jan 2013 04:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvhWOxBrsqnv for ; Wed, 9 Jan 2013 04:13:25 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9721F86F8 for ; Wed, 9 Jan 2013 04:13:24 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fk20so1725057lab.22 for ; Wed, 09 Jan 2013 04:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=X/q0Nzqw0nT5OskHCjwfk+UXJcEb42OI8iM1NWKXyU8=; b=prBxv/eZzhGc0ivCJ6wsEu7tRDRdAhlJFk6LlP8BIljjM/NvR1dH1x0qLiiRLFgNF7 +YRh1GpSBo7848cDkvtX0bD0Eje7ejOxG6Be0WJI1japYREkMGhBhqlem8i4s3ByqnZB E9dqA445gcmORFYnXZt3Fjh5eGBnIG/sTlQxQgZ7NxUTCr5xKs8IAe8N1s97ru0JuEfx 0kqtoA6mCtfIROVjmpYYU8jWbYH+aBiKT7b1TwbjaxeijS6Cn16vEoqOKoAUwrjHZbJj LWxIJ8bs/5RpUZBTnI9UanEsflA2QQYzcJgdJoq9L7wKrv3uJH+oIn3DsQ4gwQxk5m2O R78A== X-Received: by 10.112.87.97 with SMTP id w1mr26314228lbz.91.1357733601772; Wed, 09 Jan 2013 04:13:21 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id fh4sm23869503lbb.7.2013.01.09.04.12.58 (version=SSLv3 cipher=OTHER); Wed, 09 Jan 2013 04:13:20 -0800 (PST) Message-ID: <50ED5EC8.6000602@gmail.com> Date: Wed, 09 Jan 2013 14:12:56 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: RFC Errata System References: <20130109115304.51DCAB1E002@rfc-editor.org> In-Reply-To: <20130109115304.51DCAB1E002@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Jan 2013 04:15:12 -0800 Cc: valery@smyslov.net, ynir@checkpoint.com, paul.hoffman@vpnc.org, ipsec@ietf.org, fd@cisco.com, psethi@cisco.com, turners@ieca.com, wierbows@us.ibm.com, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] [Technical Errata Reported] RFC6290 (3448) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 12:13:26 -0000 This is in line with the WG discussion, and I recommend to mark it as verified. Thanks, Yaron On 01/09/2013 01:53 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6290, > "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6290&eid=3448 > > -------------------------------------- > Type: Technical > Reported by: Valery Smyslov > > Section: 4.3 > > Original Text > ------------- > For session resumption, as specified in [RFC5723], the situation is > similar. The responder, which is necessarily the peer that has > crashed, SHOULD send a new ticket within the protected payload of the > IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, > it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. > > Corrected Text > -------------- > For session resumption, as specified in [RFC5723], the situation is > similar. The responder, which is necessarily the peer that has > crashed, SHOULD send a new QCD_TOKEN in the IKE_AUTH exchange > that immediately followes the IKE_SESSION_RESUME exchange. > If the Initiator is also a token maker, it needs to send a QCD_TOKEN in > the same IKE_AUTH exchange. > > > Notes > ----- > Original text mixes up terms "ticket" (as Session Resumption ticket from RFC5723) and "token" (as QCD token from this RFC). As QCD token must never be sent in an unprotected message (see section 9.2 from this RFC) it cannot be sent in the IKE_SESSION_RESUME exchange because this exchange is done in clear. So, QCD token must be sent in the IKE_AUTH exchange that immediately followes the IKE_SESSION_RESUME exchange. In this case there is no need for the separate INFORMATIONAL exchange the Initiator's QCD token (if any) to be sent in, because it could be sent in the same IKE_AUTH exchange. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6290 (draft-ietf-ipsecme-failure-detection-08) > -------------------------------------- > Title : A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) > Publication Date : June 2011 > Author(s) : Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG > From wwwrun@rfc-editor.org Wed Jan 9 04:21:31 2013 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 4371C21F87AC for ; Wed, 9 Jan 2013 04:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcUrcwH6EJOI for ; Wed, 9 Jan 2013 04:21:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8F521F87A9 for ; Wed, 9 Jan 2013 04:21:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 42527B1E002; Wed, 9 Jan 2013 04:11:08 -0800 (PST) To: ynir@checkpoint.com, wierbows@us.ibm.com, fd@cisco.com, psethi@cisco.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com From: RFC Errata System Message-Id: <20130109121108.42527B1E002@rfc-editor.org> Date: Wed, 9 Jan 2013 04:11:08 -0800 (PST) X-Mailman-Approved-At: Wed, 09 Jan 2013 05:48:03 -0800 Cc: ipsec@ietf.org, valery@smyslov.net, rfc-editor@rfc-editor.org Subject: [IPsec] [Technical Errata Reported] RFC6290 (3449) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 12:21:31 -0000 The following errata report has been submitted for RFC6290, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6290&eid=3449 -------------------------------------- Type: Technical Reported by: Valery Smyslov Section: 4.1 Original Text ------------- o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA. Corrected Text -------------- o Protocol ID (1 octet) MUST be 0. Notes ----- RFC5996 (IKEv2) in section 3.10 while describing Protocol ID field in Notify Payload specifies that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt". As this RFC requires SPI field to be empty (later in section 4.1), Protocol ID should be zero to be consistent with RFC5996. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6290 (draft-ietf-ipsecme-failure-detection-08) -------------------------------------- Title : A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Publication Date : June 2011 Author(s) : Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From yaronf.ietf@gmail.com Wed Jan 9 05:47:00 2013 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 D5AB021F85B8 for ; Wed, 9 Jan 2013 05:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTep0GpySwwK for ; Wed, 9 Jan 2013 05:47:00 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id E10FE21F8235 for ; Wed, 9 Jan 2013 05:46:52 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fn20so1829732lab.26 for ; Wed, 09 Jan 2013 05:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2FFegeDBc6MZaqzTZrqRz789G9zIda17PmJQKsKoe/o=; b=SSi+eg0XIPvrK3oKKFoYORx77PYSHuwPQIGJfQhZkOzBnezzQmpjr0dTZiA4rN5JCt 2z+d2uo3v5cA/j1NXHAPEI1MQ3Nj7DtSZi/wogGjrvQLlWIaRYqnp8vcsDSVCGO5VFpz bjGGZepErmnx5MjP9hLoSAAmYawppF6m6aJVAuCnh7PiDWkNMvS8o/z+9iqJwM6JesBR 2Khxov9ttS+FbkYpCih3w76/H+NP/4WuED8pxNmiz8Fj25eOi6cMrTl5GDWG/kV50Dig SkxGBRpSrhLFL12Om6qjYQmDkMRcmsQTADz4NgnGQqUl1rjThwL/wETRzsOqdp7FOXal O/qg== X-Received: by 10.112.23.136 with SMTP id m8mr27854400lbf.16.1357739211641; Wed, 09 Jan 2013 05:46:51 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id ee5sm24012872lbb.14.2013.01.09.05.46.29 (version=SSLv3 cipher=OTHER); Wed, 09 Jan 2013 05:46:50 -0800 (PST) Message-ID: <50ED74B2.1010905@gmail.com> Date: Wed, 09 Jan 2013 15:46:26 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: RFC Errata System References: <20130109121108.42527B1E002@rfc-editor.org> In-Reply-To: <20130109121108.42527B1E002@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Jan 2013 05:47:58 -0800 Cc: valery@smyslov.net, ynir@checkpoint.com, paul.hoffman@vpnc.org, ipsec@ietf.org, fd@cisco.com, psethi@cisco.com, turners@ieca.com, wierbows@us.ibm.com, stephen.farrell@cs.tcd.ie Subject: Re: [IPsec] [Technical Errata Reported] RFC6290 (3449) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:47:01 -0000 Similarly to #3448, this errata was also confirmed by WG discussion. Thanks, Yaron On 01/09/2013 02:11 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6290, > "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6290&eid=3449 > > -------------------------------------- > Type: Technical > Reported by: Valery Smyslov > > Section: 4.1 > > Original Text > ------------- > o Protocol ID (1 octet) MUST be 1, as this message is related to an > IKE SA. > > > Corrected Text > -------------- > o Protocol ID (1 octet) MUST be 0. > > > Notes > ----- > RFC5996 (IKEv2) in section 3.10 while describing Protocol ID field in Notify Payload specifies that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt". As this RFC requires SPI field to be empty (later in section 4.1), Protocol ID should be zero to be consistent with RFC5996. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6290 (draft-ietf-ipsecme-failure-detection-08) > -------------------------------------- > Title : A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) > Publication Date : June 2011 > Author(s) : Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG > From turners@ieca.com Wed Jan 9 06:17:44 2013 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 64EC421F8700 for ; Wed, 9 Jan 2013 06:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8CgTBfhfMsb for ; Wed, 9 Jan 2013 06:17:44 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [70.85.130.5]) by ietfa.amsl.com (Postfix) with ESMTP id DC5AE21F86D9 for ; Wed, 9 Jan 2013 06:17:43 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id E2C3BF9B64672; Wed, 9 Jan 2013 08:17:25 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id C7C9EF9B6464B for ; Wed, 9 Jan 2013 08:17:25 -0600 (CST) Received: from [108.45.19.185] (port=56735 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TswTL-0000Ju-SY; Wed, 09 Jan 2013 08:17:39 -0600 Message-ID: <50ED7C03.7090303@ieca.com> Date: Wed, 09 Jan 2013 09:17:39 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:56735 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: ipsec@ietf.org Subject: [IPsec] AD review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 14:17:44 -0000 These are pretty much just nits. Please address Tero's comments as well. 1. We charter WGs and I'm going to go with the thought that it will succeed ;) a: r/is chartered to/will 2. s1.1: Hub definition. Verb choice: r/there is no devices/there are no devices 3. s1.1.: Spoke definition: Extra the: r/in the a star/in a star Need some ses: r/it encrypt data coming from cleartext device /it encrypts data coming from cleartext devices 4. s2: Use administrative domain in s1 but organization here. Is consistency needed? Not sure what you'd think about this, but what do you think about not using lowercase 2119 words in any of the s2 subsections? Reviewers should be able to piece together that this is the use case section and not the requirements section and therefore there shouldn't be any 2119 language here - but they don't always. To be clear, I'm not hard over on this. r/must use/need r/must/need to r/should/ought to 5. s2.1: Can you remove direct from "direct, point-to-point"? Isn't direct in the definition? Shouldn't "hub and spoke topology" be "star topology"? "hub and spoke topology" isn't defined in s1.1. I think you might need an "a" to match the previous sentence: r/Such use case/Such a use case ? r/expose them/expose themselves 6. s2.2: An extra the: r/for the voice and other/for voice and other Nit picking here but I think this is clearer: r/endpoints are administrated by separate management domains /endpoints are in different administrative domains Please expand: L3VPNs and GRE. 7. s4.1: r/firewall, NAT box/firewalls, NAT boxes 8. Req 10 + 11: Is the requirement driver under 11 for both 10 and 11? If so then it should be "These requirements". If you're going to do this couldn't you just group 10-14 as they're the same driver for all 5? Or, is the driver under 10 missing? 9 s5: To match the title: r/Problem state and requirement/problem statement and requirements 10. General: Sometimes it's ADVPN and other times it's AD VPN. 11. Allied and federated environments should be defined in the terminology section or at least introduced earlier in the draft. spt From dharkins@lounge.org Fri Jan 11 09:53:14 2013 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 F13D521F87B3 for ; Fri, 11 Jan 2013 09:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBJSPZdWmOpQ for ; Fri, 11 Jan 2013 09:53:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B29521F8795 for ; Fri, 11 Jan 2013 09:52:27 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 92FF51022405A; Fri, 11 Jan 2013 09:52:08 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 11 Jan 2013 09:52:08 -0800 (PST) Message-ID: Date: Fri, 11 Jan 2013 09:52:08 -0800 (PST) From: "Dan Harkins" To: "ipsec" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: turners@ieca.com, johannes.merkle@secunet.com Subject: [IPsec] ID on adding Brainpool ECC curve's to RFC2409's registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:53:15 -0000 Hello, At the Security Area Directorate's lunch at IETF 84 it was agreed that I would write up an I-D to assign code points for brainpool elliptic cubes to the registry created by RFC 2409 as a way of addressing a liaison request from another SDO. Even though this is not an IPsecME working group issue there has been a little discussion on this list about this draft. We'd like to go to IETF LC on it soon so if you care about this topic, please take a look at: http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-03 and if you have an issue with it, please comment. regards, Dan. From iesg-secretary@ietf.org Tue Jan 15 08:50:29 2013 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 6D3C421F860A; Tue, 15 Jan 2013 08:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+jdQ1q88PaC; Tue, 15 Jan 2013 08:50:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6C21F8929; Tue, 15 Jan 2013 08:50:27 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115165027.12612.2475.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 08:50:27 -0800 Cc: ipsecme WG Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:50:29 -0000 The IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Current Status: Active Working Group Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Sean Turner Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 5996), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and helping publish Informational documents describing current vendor proprietary solutions. Recently discovered incorrect behavior of ISPs poses a challenge to IKE, whose UDP messages (especially #3 and #4) sometimes get fragmented at the IP level and then dropped by these ISPs. There is interest in solving this issue by allowing transport of IKE over TCP; this is currently implemented by some vendors. The group will standardize such a solution, using draft-nir-ipsecme-ike-tcp as a starting point. The WG will review and possibly revise the list of mandatory-to- implement algorithms for ESP and AH based on five years of experience with newer algorithms and cryptographic modes. This work will be based on draft-mcgrew-ipsec-me-esp-ah-reqts. The WG will update the way IKEv2 uses public keys that are trusted out-of-band (that is, not through a common PKIX trust anchor). This work will be based on draft-kivinen-ipsecme-oob-pubkey. The WG will revise the IKEv2 specification with a small number of mandatory tests required for the secure operation of IKEv2 when using elliptic curve cryptography. This work will be based on draft-sheffer-ipsecme-dh-checks. This charter will expire in January 2015 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases and requirements Feb 2013 - IETF Last Call on IKE over TCP Feb 2013 - IETF LC new MITM algorithms Apr 2013 - IETF LC out-of-band public key draft Jun 2013 - IETF Last Call on large scale VPN protocol From kivinen@iki.fi Thu Jan 17 09:03:56 2013 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 D12BA21F878F for ; Thu, 17 Jan 2013 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVPmgeFfLqWi for ; Thu, 17 Jan 2013 09:03:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0758021F86C8 for ; Thu, 17 Jan 2013 09:03:55 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0HH3pwb022379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2013 19:03:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0HH3oGh026778; Thu, 17 Jan 2013 19:03:50 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20728.12021.834751.712756@fireball.kivinen.iki.fi> Date: Thu, 17 Jan 2013 19:03:49 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 21 min Subject: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:03:56 -0000 I got question now about the values allocated for the "IKEv2 in the Fibre Channel Security Association Management Protocol" and their use in the normal IPsec use over IP. This question was about support for AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values everybody in IP world are using. When those values were allocated it was assumed that they were only to be used in the FC world. I noticed that when all other RFC4595 allocated numbers have FC_ in their names, but these AUTH_* does not have those. Also there is nothing that explictly forbid their use in the IKEv2/ESP over IP, it has been implicit because there is nothing that says they can be used in the IP world either. One of the reasons for these is that this allocation happened when we had this process flaw and those drafts never came to the IANA expert for review (i.e. to me), so I only did some early comments to their -00 draft, and then later noticed that the values had been added to the registry. To clear up this confusion, I would like to add note to the IANA table saying "Only for Fibre Channel use" for those two values. Does anybody have any objections for doing that? -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Jan 17 09:13:41 2013 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 1C9EC21F8587 for ; Thu, 17 Jan 2013 09:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8MKUEzyhhXY for ; Thu, 17 Jan 2013 09:13:40 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id CC11421F879D for ; Thu, 17 Jan 2013 09:13:39 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id n10so2025215lbo.8 for ; Thu, 17 Jan 2013 09:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7M0/57E3Sh3zVxxnef1RiyAQgW3ga8m8JSh9jFkpkdE=; b=04TtwuaGg4AHkuV66ivN9wyE2Kz3P6xR2f4U6QOAyDM+ZUXN+Vw+mPkmUVp4BCfqeV dmt3oSDEgF0Gpyi8OMv2paVkB3i6Ud4lpm/KRPKj8Si4UJfLEMoFft5gNNU0m7I6cmYh x7UOQS6v2EWzwfyPSaFuA9M9JL37HhZwDut2kQ1P5JT52UPvZW2bNuM1nMPh7axTrmD3 a4TYH2nCErJ5aOOlOeEVNQPlxaSwwHL6urNMti1B0jZoCVtq/B1p4ARvnkDvE8D0131X EuoamOW4sT4TfKvh+5k0Q39mwI/KEhc8M20y7slM2GNEdenrDTe6hUtATCQw+sZVvx0I Ws4Q== X-Received: by 10.152.110.18 with SMTP id hw18mr5639880lab.22.1358442818738; Thu, 17 Jan 2013 09:13:38 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id hn3sm1021181lab.10.2013.01.17.09.13.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 09:13:37 -0800 (PST) Message-ID: <50F8313C.60204@gmail.com> Date: Thu, 17 Jan 2013 19:13:32 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> In-Reply-To: <20728.12021.834751.712756@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:13:41 -0000 Actually, why? At first sight they look entirely reasonable to me (untruncated versions of MAC, where we usually truncate). Are you saying they are not well defined? If they're both well-defined and secure, I don't see any reason to add this limitation. After all, we do have much weirder algorithms in the registry. Thanks, Yaron On 01/17/2013 07:03 PM, Tero Kivinen wrote: > I got question now about the values allocated for the "IKEv2 in the > Fibre Channel Security Association Management Protocol" and their use > in the normal IPsec use over IP. This question was about support for > AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of > using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values > everybody in IP world are using. When those values were allocated it > was assumed that they were only to be used in the FC world. > > I noticed that when all other RFC4595 allocated numbers have FC_ in > their names, but these AUTH_* does not have those. Also there is > nothing that explictly forbid their use in the IKEv2/ESP over IP, it > has been implicit because there is nothing that says they can be used > in the IP world either. > > One of the reasons for these is that this allocation happened when we > had this process flaw and those drafts never came to the IANA expert > for review (i.e. to me), so I only did some early comments to their > -00 draft, and then later noticed that the values had been added to > the registry. > > To clear up this confusion, I would like to add note to the IANA table > saying "Only for Fibre Channel use" for those two values. > > Does anybody have any objections for doing that? > From david.black@emc.com Thu Jan 17 09:16:23 2013 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 67F8821F87D6 for ; Thu, 17 Jan 2013 09:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTLHtzPmm2VQ for ; Thu, 17 Jan 2013 09:16:22 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59D6D21F87C3 for ; Thu, 17 Jan 2013 09:16:22 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0HHGFUl020413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 12:16:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 17 Jan 2013 12:16:03 -0500 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0HHG2Dn013893; Thu, 17 Jan 2013 12:16:02 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 17 Jan 2013 12:16:02 -0500 From: "Black, David" To: "'kivinen@iki.fi'" , "'ipsec@ietf.org'" Date: Thu, 17 Jan 2013 12:16:01 -0500 Thread-Topic: [IPsec] IANA ikev2 registry and FC values Thread-Index: Ac301NIal9ntXLfbTju4MYbNBC3YrgAAYEkT Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287AB6FC7@MX15A.corp.emc.com> In-Reply-To: <20728.12021.834751.712756@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:16:23 -0000 No problem here - I'm one of the authors of RFC 4595. Thanks, --David +++Sent from Blackberry ----- Original Message ----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Thursday, January 17, 2013 12:03 PM=0A= To: ipsec@ietf.org Subject: [IPsec] IANA ikev2 registry and FC values I got question now about the values allocated for the "IKEv2 in the Fibre Channel Security Association Management Protocol" and their use in the normal IPsec use over IP. This question was about support for AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values everybody in IP world are using. When those values were allocated it was assumed that they were only to be used in the FC world. I noticed that when all other RFC4595 allocated numbers have FC_ in their names, but these AUTH_* does not have those. Also there is nothing that explictly forbid their use in the IKEv2/ESP over IP, it has been implicit because there is nothing that says they can be used in the IP world either. One of the reasons for these is that this allocation happened when we had this process flaw and those drafts never came to the IANA expert for review (i.e. to me), so I only did some early comments to their -00 draft, and then later noticed that the values had been added to the registry. To clear up this confusion, I would like to add note to the IANA table saying "Only for Fibre Channel use" for those two values. Does anybody have any objections for doing that?=20 --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Thu Jan 17 09:19:17 2013 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 5922021F869F for ; Thu, 17 Jan 2013 09:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hMpZ1BTMoxW for ; Thu, 17 Jan 2013 09:19:16 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6A11F21F857A for ; Thu, 17 Jan 2013 09:19:16 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DC10310224052; Thu, 17 Jan 2013 09:19:15 -0800 (PST) Received: from 216.123.155.211 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 17 Jan 2013 09:19:16 -0800 (PST) Message-ID: <98a68558188e76db21c232a85d12d6cb.squirrel@www.trepanning.net> In-Reply-To: <20728.12021.834751.712756@fireball.kivinen.iki.fi> References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> Date: Thu, 17 Jan 2013 09:19:16 -0800 (PST) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:19:17 -0000 Hello, On Thu, January 17, 2013 9:03 am, Tero Kivinen wrote: > I got question now about the values allocated for the "IKEv2 in the > Fibre Channel Security Association Management Protocol" and their use > in the normal IPsec use over IP. This question was about support for > AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of > using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values > everybody in IP world are using. When those values were allocated it > was assumed that they were only to be used in the FC world. > > I noticed that when all other RFC4595 allocated numbers have FC_ in > their names, but these AUTH_* does not have those. Also there is > nothing that explictly forbid their use in the IKEv2/ESP over IP, it > has been implicit because there is nothing that says they can be used > in the IP world either. > > One of the reasons for these is that this allocation happened when we > had this process flaw and those drafts never came to the IANA expert > for review (i.e. to me), so I only did some early comments to their > -00 draft, and then later noticed that the values had been added to > the registry. > > To clear up this confusion, I would like to add note to the IANA table > saying "Only for Fibre Channel use" for those two values. > > Does anybody have any objections for doing that? I don't actually see what the problem is that this note would solve. Unless there's a problem then I have an objection to adding this note. Can you restate the problem? Dan. From kivinen@iki.fi Thu Jan 17 09:38:47 2013 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 16C7321F866D for ; Thu, 17 Jan 2013 09:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ll-3J2ylwyZ for ; Thu, 17 Jan 2013 09:38:46 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 38FFE21F8798 for ; Thu, 17 Jan 2013 09:38:46 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0HHceur002971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 19:38:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0HHcdPF026125; Thu, 17 Jan 2013 19:38:39 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20728.14111.293749.62984@fireball.kivinen.iki.fi> Date: Thu, 17 Jan 2013 19:38:39 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <50F8313C.60204@gmail.com> References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <50F8313C.60204@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:38:47 -0000 Yaron Sheffer writes: > Actually, why? At first sight they look entirely reasonable to me > (untruncated versions of MAC, where we usually truncate). Are you saying > they are not well defined? I do not think they offer anything compared to the truncated versions, i.e. it just adds a 2nd way to do exactly same thing with no clear reason. Note that RFC2104 section 5 says that there are some advantages of truncating the output of the hash-based MAC functions (even though the results are not absolute). > If they're both well-defined and secure, I don't see any reason to add > this limitation. They are not defined for IP use at all. None of the IKEv2/ESP over IP uses those values. Ah, found text from our IPsec/IKE Roadmap: For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version and the standard non- truncated version; thus, IKEv2 has the capability to negotiate either version of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is reserved for use by the Fibre Channel protocol [RFC4595]. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs. which actually says we always use truncated version (so I was wrong they are not forbidden anywhere, missed this text last time as it uses SHA-1 spelling not SHA1, which I was searching for :-). > After all, we do have much weirder algorithms in the registry. That is true, and I do not consider that as a good thing. It is much better to have one good way of doing things than two ways of doing same thing, especially if those two ways are about the same. -- kivinen@iki.fi From kivinen@iki.fi Thu Jan 17 09:41:44 2013 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 F14D221F8B49 for ; Thu, 17 Jan 2013 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQUEMdbhC4gn for ; Thu, 17 Jan 2013 09:41:43 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE3921F8A11 for ; Thu, 17 Jan 2013 09:41:42 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0HHffVw025277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 19:41:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0HHffG5007595; Thu, 17 Jan 2013 19:41:41 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20728.14293.844231.917856@fireball.kivinen.iki.fi> Date: Thu, 17 Jan 2013 19:41:41 +0200 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <98a68558188e76db21c232a85d12d6cb.squirrel@www.trepanning.net> References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <98a68558188e76db21c232a85d12d6cb.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:41:44 -0000 Dan Harkins writes: > I don't actually see what the problem is that this note would solve. > Unless there's a problem then I have an objection to adding this note. > Can you restate the problem? Mostly because then saying integrity protection with SHA-1 is not well defined anymore. Currently it is assumed it always means AUTH_HMAC_SHA1_96, but if implementations start supporting AUTH_HMAC_SHA1_160 too, then the GUI etc needs to be modified to be explicit about the truncation length, and that just causes confusion and interoperability problems. Especially as I do not know any implementation out there that supports AUTH_HMAC_SHA1_160 for IP use... -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Jan 17 09:48:11 2013 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 7D5B221F8611 for ; Thu, 17 Jan 2013 09:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaP7oVgCQ87C for ; Thu, 17 Jan 2013 09:48:10 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4521F85AF for ; Thu, 17 Jan 2013 09:48:10 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so2112904lab.41 for ; Thu, 17 Jan 2013 09:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NfNaAiO2ApVK/o7nk84Hujeqr+TLbL01ygjP7v/JlnY=; b=u2WVK3yi3KyQf7KwAnk8cfjHRlcpRo/yhkUnQxtMQsWEmTv5sk6HyuZkiDl2DoLomg 0ZS6z3RZnhExO+mnwqevB9irVWUnlcYnHqfKOYNH4yEeqfsWtV45FuLH34KQaT/J4FkF oltE5K7tbss1GFzwuBB4zBMRMnGqWNgRrJJLfZVzKaOfvIgeT/FIckRxie3XiZd3zDYr vdgFyJG/XACHG0UEH/WS8b/QJQl64MKXZvPWhn8TfOv1853hbgnl8NFsjnTzAZaISc/Q XL3+lHuUSvF5Ino/f5XEyBtXQAdAx4bxwwJKUIbmqa1flnHRdiUKPj1gJHWle0Ru2nu+ Vr9g== X-Received: by 10.152.113.6 with SMTP id iu6mr5695637lab.43.1358444889182; Thu, 17 Jan 2013 09:48:09 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id b3sm1140318lbl.0.2013.01.17.09.48.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 09:48:07 -0800 (PST) Message-ID: <50F83953.9060003@gmail.com> Date: Thu, 17 Jan 2013 19:48:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <50F8313C.60204@gmail.com> <20728.14111.293749.62984@fireball.kivinen.iki.fi> In-Reply-To: <20728.14111.293749.62984@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:48:11 -0000 Hi Tero, please see below. Thanks, Yaron On 01/17/2013 07:38 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> Actually, why? At first sight they look entirely reasonable to me >> (untruncated versions of MAC, where we usually truncate). Are you saying >> they are not well defined? > > I do not think they offer anything compared to the truncated versions, > i.e. it just adds a 2nd way to do exactly same thing with no clear > reason. Whether they're adding anything or not is for cryptographers to say. Sec. 5 of RFC 2104 is very equivocal about this. OTOH your proposal would mean one more difference between "regular" IPsec implementations and FC-specific ones. I don't think that would be a good thing. > > Note that RFC2104 section 5 says that there are some advantages of > truncating the output of the hash-based MAC functions (even though the > results are not absolute). See above. > >> If they're both well-defined and secure, I don't see any reason to add >> this limitation. > > They are not defined for IP use at all. None of the IKEv2/ESP over IP > uses those values. Ah, found text from our IPsec/IKE Roadmap: > > For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry > contains values for both the truncated version and the standard non- > truncated version; thus, IKEv2 has the capability to negotiate either > version of the algorithm. However, only the truncated version is > used for IKEv2 SAs and for IPsec SAs. The non-truncated version is > reserved for use by the Fibre Channel protocol [RFC4595]. For the > other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- > RIPEMD), only the truncated version can be used for both IKEv2 and > IPsec-v3 SAs. > > which actually says we always use truncated version (so I was wrong > they are not forbidden anywhere, missed this text last time as it uses > SHA-1 spelling not SHA1, which I was searching for :-). > This text is simply describing the existing situation. It is not at all normative. >> After all, we do have much weirder algorithms in the registry. > > That is true, and I do not consider that as a good thing. It is much > better to have one good way of doing things than two ways of doing > same thing, especially if those two ways are about the same. > Yes, but people have good reasons to add algorithms, which is (part of the reason) why we negotiate them in the protocol. Thus "Tiger", "camellia" and the like, and I'm sure the FC folks had a good reason for the untruncated algorithms, too. From kivinen@iki.fi Thu Jan 17 10:13:41 2013 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 E02C321F8765 for ; Thu, 17 Jan 2013 10:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLKwT5oai1rW for ; Thu, 17 Jan 2013 10:13:41 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id F10D021F85C8 for ; Thu, 17 Jan 2013 10:13:40 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0HIDXdA022064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 20:13:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0HIDUUP002334; Thu, 17 Jan 2013 20:13:30 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20728.16202.414687.956476@fireball.kivinen.iki.fi> Date: Thu, 17 Jan 2013 20:13:30 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <50F83953.9060003@gmail.com> References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <50F8313C.60204@gmail.com> <20728.14111.293749.62984@fireball.kivinen.iki.fi> <50F83953.9060003@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 19 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:13:42 -0000 Yaron Sheffer writes: > OTOH your proposal would mean one more difference between "regular" > IPsec implementations and FC-specific ones. I don't think that would be > a good thing. FC-specific ones are only using these non-truncated ones, and they are using special ID payloads, separate protocol ID values, different types of traffic selectors etc. They are reusing the basic IKEv2 protocol, and some of the payloads, but it is different protocol than IKEv2. > > They are not defined for IP use at all. None of the IKEv2/ESP over IP > > uses those values. Ah, found text from our IPsec/IKE Roadmap: > > > > For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry > > contains values for both the truncated version and the standard non- > > truncated version; thus, IKEv2 has the capability to negotiate either > > version of the algorithm. However, only the truncated version is > > used for IKEv2 SAs and for IPsec SAs. The non-truncated version is > > reserved for use by the Fibre Channel protocol [RFC4595]. For the > > other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- > > RIPEMD), only the truncated version can be used for both IKEv2 and > > IPsec-v3 SAs. > > > > which actually says we always use truncated version (so I was wrong > > they are not forbidden anywhere, missed this text last time as it uses > > SHA-1 spelling not SHA1, which I was searching for :-). > > > > This text is simply describing the existing situation. It is not at all > normative. Which is why I also want to describe that existing situation in the IANA registry. If you want to use those non-truncated versions in IPsec, you can write draft describing that... > > That is true, and I do not consider that as a good thing. It is much > > better to have one good way of doing things than two ways of doing > > same thing, especially if those two ways are about the same. > > > > Yes, but people have good reasons to add algorithms, which is (part of > the reason) why we negotiate them in the protocol. Thus "Tiger", > "camellia" and the like, and I'm sure the FC folks had a good reason for > the untruncated algorithms, too. They had some reason, but on the other hand IPsec people did not want those untruncated algorithms, and have not specified them for IP use. This is one of the problems when sharing registries causes problems. Suddenly you might have options for protocols which did not request them added to them, because someone else who shares the same registry added them. -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Jan 17 10:24:01 2013 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 66F8C21F87F5 for ; Thu, 17 Jan 2013 10:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfE2R2-Vgjru for ; Thu, 17 Jan 2013 10:23:59 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id BD35C21F86CD for ; Thu, 17 Jan 2013 10:23:58 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id je9so1573809bkc.27 for ; Thu, 17 Jan 2013 10:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EkaR2OJNtbWGYwMhPiIox2pNuFwhJV/NJGkqCQU0k30=; b=DmwyEWrMZup6VZCZdE9r6gJjIS7sJbJs9Otx6X63yzBjHit/AL5aub5VDYJovCp6eg 6yi/NNlGXCUoyTDrwurwrjCr7DlO5McF3KUcBxkN1KNYcStJIjcY6/OmhP+7UK8+QMNe Z1GoO5wT5/u8kd+1rcJb+DcmL/IljJHH8A2fDSsJAH5kcsPI7/qumBjt+GRFY8NdMhsg 2YL/shWNXI88jZBlXI4K6E5VPrUPNq28OkUvZGxnOb9m1uUv+KzBYg/I5iiYh/S+rF90 6SM5J8gZPO/6tSNW4jmznuhTfRqPfaI4hdTEZ4uexsCQGTdBhKFEjZ/y6FD/duJke8zT LUNg== X-Received: by 10.204.10.88 with SMTP id o24mr1782667bko.19.1358447037803; Thu, 17 Jan 2013 10:23:57 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id o9sm2122082bko.15.2013.01.17.10.23.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 10:23:56 -0800 (PST) Message-ID: <50F841B8.5080707@gmail.com> Date: Thu, 17 Jan 2013 20:23:52 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <50F8313C.60204@gmail.com> <20728.14111.293749.62984@fireball.kivinen.iki.fi> <50F83953.9060003@gmail.com> <20728.16202.414687.956476@fireball.kivinen.iki.fi> In-Reply-To: <20728.16202.414687.956476@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:24:01 -0000 I agree that sharing registries with related but different protocols is not a good thing. I just think this is not one of these cases. Thanks, Yaron On 01/17/2013 08:13 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> OTOH your proposal would mean one more difference between "regular" >> IPsec implementations and FC-specific ones. I don't think that would be >> a good thing. > > FC-specific ones are only using these non-truncated ones, and they are > using special ID payloads, separate protocol ID values, different > types of traffic selectors etc. They are reusing the basic IKEv2 > protocol, and some of the payloads, but it is different protocol than > IKEv2. > >>> They are not defined for IP use at all. None of the IKEv2/ESP over IP >>> uses those values. Ah, found text from our IPsec/IKE Roadmap: >>> >>> For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry >>> contains values for both the truncated version and the standard non- >>> truncated version; thus, IKEv2 has the capability to negotiate either >>> version of the algorithm. However, only the truncated version is >>> used for IKEv2 SAs and for IPsec SAs. The non-truncated version is >>> reserved for use by the Fibre Channel protocol [RFC4595]. For the >>> other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- >>> RIPEMD), only the truncated version can be used for both IKEv2 and >>> IPsec-v3 SAs. >>> >>> which actually says we always use truncated version (so I was wrong >>> they are not forbidden anywhere, missed this text last time as it uses >>> SHA-1 spelling not SHA1, which I was searching for :-). >>> >> >> This text is simply describing the existing situation. It is not at all >> normative. > > Which is why I also want to describe that existing situation in the > IANA registry. If you want to use those non-truncated versions in > IPsec, you can write draft describing that... > >>> That is true, and I do not consider that as a good thing. It is much >>> better to have one good way of doing things than two ways of doing >>> same thing, especially if those two ways are about the same. >>> >> >> Yes, but people have good reasons to add algorithms, which is (part of >> the reason) why we negotiate them in the protocol. Thus "Tiger", >> "camellia" and the like, and I'm sure the FC folks had a good reason for >> the untruncated algorithms, too. > > They had some reason, but on the other hand IPsec people did not want > those untruncated algorithms, and have not specified them for IP use. > This is one of the problems when sharing registries causes problems. > Suddenly you might have options for protocols which did not request > them added to them, because someone else who shares the same registry > added them. > From dharkins@lounge.org Thu Jan 17 11:44:28 2013 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 493D421F8870 for ; Thu, 17 Jan 2013 11:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wccni3ktsB+W for ; Thu, 17 Jan 2013 11:44:24 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 08FEE21F88ED for ; Thu, 17 Jan 2013 11:44:24 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2CCE410224052; Thu, 17 Jan 2013 11:44:21 -0800 (PST) Received: from 216.123.155.211 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 17 Jan 2013 11:44:21 -0800 (PST) Message-ID: In-Reply-To: <50F841B8.5080707@gmail.com> References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <50F8313C.60204@gmail.com> <20728.14111.293749.62984@fireball.kivinen.iki.fi> <50F83953.9060003@gmail.com> <20728.16202.414687.956476@fireball.kivinen.iki.fi> <50F841B8.5080707@gmail.com> Date: Thu, 17 Jan 2013 11:44:21 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IANA ikev2 registry and FC values X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:44:28 -0000 Hello, On Thu, January 17, 2013 10:23 am, Yaron Sheffer wrote: > I agree that sharing registries with related but different protocols is > not a good thing. I just think this is not one of these cases. I agree that this is not the case but sharing registries should not be a problem. We use OIDs all the time with different protocols. The problems arise when a group of people attempts to impose administrative rules on protocol use and say that some completely legitimate technical application is prohibited for the simple reason that they say it is. Dan. > Thanks, > Yaron > > On 01/17/2013 08:13 PM, Tero Kivinen wrote: >> Yaron Sheffer writes: >>> OTOH your proposal would mean one more difference between "regular" >>> IPsec implementations and FC-specific ones. I don't think that would be >>> a good thing. >> >> FC-specific ones are only using these non-truncated ones, and they are >> using special ID payloads, separate protocol ID values, different >> types of traffic selectors etc. They are reusing the basic IKEv2 >> protocol, and some of the payloads, but it is different protocol than >> IKEv2. >> >>>> They are not defined for IP use at all. None of the IKEv2/ESP over IP >>>> uses those values. Ah, found text from our IPsec/IKE Roadmap: >>>> >>>> For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry >>>> contains values for both the truncated version and the standard >>>> non- >>>> truncated version; thus, IKEv2 has the capability to negotiate >>>> either >>>> version of the algorithm. However, only the truncated version is >>>> used for IKEv2 SAs and for IPsec SAs. The non-truncated version >>>> is >>>> reserved for use by the Fibre Channel protocol [RFC4595]. For >>>> the >>>> other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and >>>> HMAC- >>>> RIPEMD), only the truncated version can be used for both IKEv2 >>>> and >>>> IPsec-v3 SAs. >>>> >>>> which actually says we always use truncated version (so I was wrong >>>> they are not forbidden anywhere, missed this text last time as it uses >>>> SHA-1 spelling not SHA1, which I was searching for :-). >>>> >>> >>> This text is simply describing the existing situation. It is not at all >>> normative. >> >> Which is why I also want to describe that existing situation in the >> IANA registry. If you want to use those non-truncated versions in >> IPsec, you can write draft describing that... >> >>>> That is true, and I do not consider that as a good thing. It is much >>>> better to have one good way of doing things than two ways of doing >>>> same thing, especially if those two ways are about the same. >>>> >>> >>> Yes, but people have good reasons to add algorithms, which is (part of >>> the reason) why we negotiate them in the protocol. Thus "Tiger", >>> "camellia" and the like, and I'm sure the FC folks had a good reason >>> for >>> the untruncated algorithms, too. >> >> They had some reason, but on the other hand IPsec people did not want >> those untruncated algorithms, and have not specified them for IP use. >> This is one of the problems when sharing registries causes problems. >> Suddenly you might have options for protocols which did not request >> them added to them, because someone else who shares the same registry >> added them. >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Mon Jan 28 21:19:33 2013 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 F3FB111E8097 for ; Mon, 28 Jan 2013 21:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0enVO9iZoPwW for ; Mon, 28 Jan 2013 21:19:32 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0E25621F85EE for ; Mon, 28 Jan 2013 21:19:31 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so18120eaa.10 for ; Mon, 28 Jan 2013 21:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=dDBlsZMxOW3iBl+4tIl/TiYjNSSWJJwNsFQK6zGhBtM=; b=ZsdgvnDDDzTtyEiRoEqr9AJ7AT9QUNi2lU48b7v12ehdY4Yk1FlHijRe4vSU9lAQpE D3ct3SgD75xIAoDfovnCCTndPbzX81hQZUa+FiJVQrY9dbdSzsdxKfdYsIrlTeMhSphz HOp4gSLPdBqwfOHEjRf2Tde6DTngtnKM1y2dJ1nhzNKeDk3U73lnnH+aT149UqkWDNdE BmyS+2Eu8XZZB8IDD7Eg2Pnvfh8+Fy4EhND6AsJBMEoRmDeiFeQROJjpzfometUfttfR ZsFrR/NWUjUXmOOQLAQb8UmfOq/DwyzO9ux4sp1PoQZwmCtF+yBJnLlSmhlwrKyT4PF6 o00A== X-Received: by 10.14.207.6 with SMTP id m6mr1190188eeo.10.1359436771065; Mon, 28 Jan 2013 21:19:31 -0800 (PST) Received: from [10.0.0.5] (bzq-79-176-124-5.red.bezeqint.net. [79.176.124.5]) by mx.google.com with ESMTPS id d3sm18926518eeo.13.2013.01.28.21.19.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 21:19:29 -0800 (PST) Message-ID: <51075BDE.4060106@gmail.com> Date: Tue, 29 Jan 2013 07:19:26 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: IPsecme WG References: <20130129042627.73B2AB1E007@rfc-editor.org> In-Reply-To: <20130129042627.73B2AB1E007@rfc-editor.org> X-Forwarded-Message-Id: <20130129042627.73B2AB1E007@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: RFC 6867 on An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 05:19:33 -0000 -------- Original Message -------- Subject: RFC 6867 on An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) Date: Mon, 28 Jan 2013 20:26:27 -0800 (PST) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6867 Title: An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) Author: Y. Nir, Q. Wu Status: Experimental Stream: IETF Date: January 2013 Mailbox: ynir@checkpoint.com, sunseawq@huawei.com Pages: 9 Characters: 19322 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nir-ipsecme-erx-11.txt URL: http://www.rfc-editor.org/rfc/rfc6867.txt This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From vishwas.ietf@gmail.com Tue Jan 29 11:47:17 2013 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 00E1B21F85C3 for ; Tue, 29 Jan 2013 11:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXz6slkbpxkt for ; Tue, 29 Jan 2013 11:47:16 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2302521F85D4 for ; Tue, 29 Jan 2013 11:47:16 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id hy16so1835740qab.14 for ; Tue, 29 Jan 2013 11:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3E9ddiMAku+RiFrVqSaNlQlPvvIz5ud+vvsNwCctTts=; b=gEAD/5GXGdtKQ/dNV8LzcZgM4L7qM/wSjuMKc5oAeJNXeay6x6YIVI9NJx/UQTXJOG h4ihBPysVeZq2P1V3aYQVOfCC2dDC+ZJmUazVfOhmIzQ9avkIhZV4kSzS6ys6Elx6Ekw 6rO/6P2yewqKsGBiewYch8uXA9iJY2ONJTi2aEGCDN7lol38FD+DCU2FOraE9qMhfO8g 8ATFQpDbPurUi8EqQqiu2uU2T+7Cjk73Xl7n0U/SZX5P5V5P7oHJ3OaUgtzZUKznaVwD e87El+LBF23F7TQqGiSku9xCJzWi88v7EsDDfbhqO98lrChG6K4QMnlm7+9Lx1subZAg 7+RQ== MIME-Version: 1.0 X-Received: by 10.224.199.70 with SMTP id er6mr2401781qab.19.1359488831128; Tue, 29 Jan 2013 11:47:11 -0800 (PST) Received: by 10.229.92.77 with HTTP; Tue, 29 Jan 2013 11:47:11 -0800 (PST) In-Reply-To: <50ED7C03.7090303@ieca.com> References: <50ED7C03.7090303@ieca.com> Date: Tue, 29 Jan 2013 11:47:11 -0800 Message-ID: From: Vishwas Manral To: Sean Turner Content-Type: multipart/alternative; boundary=20cf30050e8adb040d04d472a823 Cc: ipsec@ietf.org, draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:47:17 -0000 --20cf30050e8adb040d04d472a823 Content-Type: text/plain; charset=ISO-8859-1 Hi Sean, I realized I missed this email. I will work on this draft this week and next. Thanks, Vishwas On Wed, Jan 9, 2013 at 6:17 AM, Sean Turner wrote: > These are pretty much just nits. Please address Tero's comments as well. > > 1. We charter WGs and I'm going to go with the thought that it will > succeed ;) > > a: r/is chartered to/will > > 2. s1.1: Hub definition. > > Verb choice: > > r/there is no devices/there are no devices > > 3. s1.1.: Spoke definition: > > Extra the: > > r/in the a star/in a star > > Need some ses: > > r/it encrypt data coming from cleartext device > /it encrypts data coming from cleartext devices > > 4. s2: Use administrative domain in s1 but organization here. Is > consistency needed? > > Not sure what you'd think about this, but what do you think about not > using lowercase 2119 words in any of the s2 subsections? Reviewers should > be able to piece together that this is the use case section and not the > requirements section and therefore there shouldn't be any 2119 language > here - but they don't always. To be clear, I'm not hard over on this. > > r/must use/need > r/must/need to > r/should/ought to > > 5. s2.1: > > Can you remove direct from "direct, point-to-point"? Isn't direct in the > definition? > > Shouldn't "hub and spoke topology" be "star topology"? "hub and spoke > topology" isn't defined in s1.1. > > I think you might need an "a" to match the previous sentence: > > r/Such use case/Such a use case ? > > r/expose them/expose themselves > > 6. s2.2: > > An extra the: > > r/for the voice and other/for voice and other > > Nit picking here but I think this is clearer: > > r/endpoints are administrated by separate management domains > /endpoints are in different administrative domains > > Please expand: L3VPNs and GRE. > > 7. s4.1: > > r/firewall, NAT box/firewalls, NAT boxes > > 8. Req 10 + 11: Is the requirement driver under 11 for both 10 and 11? If > so then it should be "These requirements". If you're going to do this > couldn't you just group 10-14 as they're the same driver for all 5? Or, is > the driver under 10 missing? > > 9 s5: To match the title: > > r/Problem state and requirement/problem statement and requirements > > 10. General: Sometimes it's ADVPN and other times it's AD VPN. > > 11. Allied and federated environments should be defined in the terminology > section or at least introduced earlier in the draft. > > spt > ______________________________**_________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/**listinfo/ipsec > --20cf30050e8adb040d04d472a823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sean,
=A0
I realized I missed this email. I wil= l work on this draft this week and next.
=A0
Thanks,
Vishwas
On Wed, Jan 9, 2013 at = 6:17 AM, Sean Turner <turners@ieca.com> wrote:
These are pretty much just nits. =A0Please address Tero= 9;s comments as well.

1. We charter WGs and I'm going to go with the thought that it will suc= ceed ;)

a: r/is chartered to/will

2. s1.1: Hub definition.

Verb choice:

r/there is no devices/there are no devices

3. s1.1.: Spoke definition:

Extra the:

r/in the a star/in a star

Need some ses:

r/it encrypt data coming from cleartext device
=A0/it encrypts data coming from cleartext devices

4. s2: Use administrative domain in s1 but organization here. =A0Is consist= ency needed?

Not sure what you'd think about this, but what do you think about not u= sing lowercase 2119 words in any of the s2 subsections? =A0Reviewers should= be able to piece together that this is the use case section and not the re= quirements section and therefore there shouldn't be any 2119 language h= ere - but they don't always. =A0To be clear, I'm not hard over on t= his.

r/must use/need
r/must/need to
r/should/ought to

5. s2.1:

Can you remove direct from "direct, point-to-point"? =A0Isn't= direct in the definition?

Shouldn't "hub and spoke topology" be "star topology&quo= t;? =A0"hub and spoke topology" isn't defined in s1.1.

I think you might need an "a" to match the previous sentence:

r/Such use case/Such a use case ?

r/expose them/expose themselves

6. s2.2:

An extra the:

r/for the voice and other/for voice and other

Nit picking here but I think this is clearer:

r/endpoints are administrated by separate management domains
=A0/endpoints are in different administrative domains

Please expand: L3VPNs and GRE.

7. s4.1:

r/firewall, NAT box/firewalls, NAT boxes

8. Req 10 + 11: Is the requirement driver under 11 for both 10 and 11? If s= o then it should be "These requirements". =A0If you're going = to do this couldn't you just group 10-14 as they're the same driver= for all 5? Or, is the driver under 10 missing?

9 s5: To match the title:

r/Problem state and requirement/problem statement and requirements

10. General: Sometimes it's ADVPN and other times it's AD VPN.

11. Allied and federated environments should be defined in the terminology = section or at least introduced earlier in the draft.

spt
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--20cf30050e8adb040d04d472a823-- From internet-drafts@ietf.org Tue Jan 29 12:58:03 2013 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 4CA9221F8873; Tue, 29 Jan 2013 12:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8V4Hlox9igS; Tue, 29 Jan 2013 12:58:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A856821F87D5; Tue, 29 Jan 2013 12:58:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130129205802.8754.11516.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 12:58:02 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:58:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Additional Diffie-Hellman Tests for IKEv2 Author(s) : Yaron Sheffer Scott Fluhrer Filename : draft-ietf-ipsecme-dh-checks-00.txt Pages : 8 Date : 2013-01-29 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From turners@ieca.com Thu Jan 31 07:56:21 2013 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 7307221F856F for ; Thu, 31 Jan 2013 07:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVVkdRVeOQi4 for ; Thu, 31 Jan 2013 07:56:21 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.55.9]) by ietfa.amsl.com (Postfix) with ESMTP id EF32C21F856E for ; Thu, 31 Jan 2013 07:56:20 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 85648E1FCFFD; Thu, 31 Jan 2013 09:56:20 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 76F6CE1FCFC4 for ; Thu, 31 Jan 2013 09:56:20 -0600 (CST) Received: from [108.45.16.214] (port=52565 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U0wUu-0000d4-Ah for ipsec@ietf.org; Thu, 31 Jan 2013 09:56:20 -0600 Message-ID: <510A9423.1050908@ieca.com> Date: Thu, 31 Jan 2013 10:56:19 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipsec@ietf.org References: <20130131141207.23167.68024.idtracker@ietfa.amsl.com> In-Reply-To: <20130131141207.23167.68024.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130131141207.23167.68024.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:52565 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] Fwd: Last Call: (Brainpool Elliptic Curves for the IKE Group Description Registry) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:56:21 -0000 Note the following IETF LC. If you have comments please send them to ietf@ietf.org. spt -------- Original Message -------- Subject: Last Call: (Brainpool Elliptic Curves for the IKE Group Description Registry) to Informational RFC Date: Thu, 31 Jan 2013 06:12:07 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Brainpool Elliptic Curves for the IKE Group Description Registry' as Informational RFC 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 2013-02-28. 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 memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by The Internet Key Exchange (IKE) but is used by other protocols. The file can be obtained via http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/ballot/ No IPR declarations have been submitted directly on this I-D.