From kivinen@iki.fi Mon Aug 1 07:42:55 2011 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 7DB3D11E8073 for ; Mon, 1 Aug 2011 07:42:55 -0700 (PDT) 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 uZlqInlrKjUX for ; Mon, 1 Aug 2011 07:42:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id C944D11E80E5 for ; Mon, 1 Aug 2011 07:42:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p71Egl4p012328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2011 17:42:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p71Egj2E015180; Mon, 1 Aug 2011 17:42:45 +0300 (EEST) 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: <20022.47973.373596.130885@fireball.kivinen.iki.fi> Date: Mon, 1 Aug 2011 17:42:45 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4E332698.20900@gmail.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 25 min Cc: IPsecme WG , Dan Harkins , Paul Hoffman Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) 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: Mon, 01 Aug 2011 14:42:55 -0000 Yaron Sheffer writes: > it doesn't matter exactly what negotiation is used, as long as two peers > can offer multiple methods in IKE_SA_INIT, and find out which auth > methods they have in common, if any. This is true for PACE, and also for > version -04 of SPSK, i.e. before it adopted your framework. Yes all drafts now have negotiation method happening in the IKE_SA_INIT, which is good. > Regarding IANA allocation, I would like to quote from RFC 5226: > > "The designated expert is responsible for initiating and coordinating > the appropriate review of an assignment request. The review may be wide > or narrow, depending on the situation and the judgment of the designated > expert. This may involve consultation with a set of technology experts, > discussion on a public mailing list, consultation with a working group > (or its mailing list if the working group has disbanded), etc. [...] > Designated experts are expected to be able to defend their decisions to > the IETF community, and the evaluation process is not intended to be > secretive or bestow unquestioned power on the expert." > > I certainly do not want to turn the IANA allocation into a "fight". I do > think the community needs to be consulted. As we have seen from the ipsec list the community does not seem to care too much, but I myself as a member of the community and also the person responsible for the IANA registries do care. I have stated my reasons why I consider allocating multiple payload numbers etc for exactly same thing a bad thing. As it seems that IKEv2 might be used with other things than IPsec too in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in the IKEv2 IANA registries. Even if those use cases are not IPsec they most likely will reuse most of the registries from the IPsec. We could overlap their numbers with each other, but on the other hand that can cause confusion, so it might be better to make sure they do not have overlapping numbers, i.e. use of unique numbers for different things and mark those as reserved in the registries which do not use them. This is bit what IKEv1 and IKEv2 did, for example we are not using payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1 used them. Same way our exchange numbers 0-33 are reserved etc. I am not sure whether we are doing that in the future or not. I want to think more about this and see the actual protocols before deciding. But on the other hand I want to keep our options open, which means I do not want to fill our registries with multiple registrations for the exactly same thing. Can you explain me what problems will it cause if the draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the draft-kivinen-ipsecme-secure-password-framework framework just like other secure password method drafts have already done? In my understanding there will be 2 extra bytes in the IKE_SA_INIT notification phase to indicate the PACE inside N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two depending how you do it) in the ENONCE and PKEi/PKEr payloads. So in total the technical differences will be 7 extra bytes. Is there anything else? -- kivinen@iki.fi From paul.hoffman@vpnc.org Mon Aug 1 09:11:28 2011 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 254B621F8DBB for ; Mon, 1 Aug 2011 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 oczRYl0Vg4jl for ; Mon, 1 Aug 2011 09:11:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 454E221F8DB9 for ; Mon, 1 Aug 2011 09:11:27 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p71GBDMc046666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2011 09:11:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20022.47973.373596.130885@fireball.kivinen.iki.fi> Date: Mon, 1 Aug 2011 09:11:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1084) Cc: IPsecme WG Subject: [IPsec] Role of the IANA expert reviewer 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, 01 Aug 2011 16:11:28 -0000 On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote: > As we have seen from the ipsec list the community does not seem to > care too much, but I myself as a member of the community and also the > person responsible for the IANA registries do care. You are *not* responsible for the IANA registries. RFC 5226 says: It should be noted that a key motivation for having designated experts is for the IETF to provide IANA with a subject matter expert to whom the evaluation process can be delegated. IANA forwards requests for an assignment to the expert for evaluation, and the expert (after performing the evaluation) informs IANA as to whether or not to make the assignment or registration. . . . Designated experts are expected to be able to defend their decisions to the IETF community, and the evaluation process is not intended to be secretive or bestow unquestioned power on the expert. Experts are expected to apply applicable documented review or vetting procedures, or in the absence of documented criteria, follow generally accepted norms, e.g., those in Section 3.3. I do not believe that you can defend a decision to reject registrations = based on what is in RFC 4306. If you disagree, please show which text = you are referring to. > I have stated my reasons why I consider allocating multiple payload > numbers etc for exactly same thing a bad thing. The three proposals do not do "exactly the same thing": they each have = different cryptographic and administrative properties. This has been = widely discussed in the WG. > As it seems that IKEv2 might be used with other things than IPsec too > in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in > the IKEv2 IANA registries. >=20 > Even if those use cases are not IPsec they most likely will reuse most > of the registries from the IPsec. We could overlap their numbers with > each other, but on the other hand that can cause confusion, so it > might be better to make sure they do not have overlapping numbers, > i.e. use of unique numbers for different things and mark those as > reserved in the registries which do not use them. >=20 > This is bit what IKEv1 and IKEv2 did, for example we are not using > payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1 > used them. Same way our exchange numbers 0-33 are reserved etc. >=20 > I am not sure whether we are doing that in the future or not. I want > to think more about this and see the actual protocols before deciding. This should be a WG/IETF decision, not that of a single person. > But on the other hand I want to keep our options open, which means I > do not want to fill our registries with multiple registrations for the > exactly same thing. See above. > Can you explain me what problems will it cause if the > draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the > draft-kivinen-ipsecme-secure-password-framework framework just like > other secure password method drafts have already done? > In my understanding there will be 2 extra bytes in the IKE_SA_INIT > notification phase to indicate the PACE inside > N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two > depending how you do it) in the ENONCE and PKEi/PKEr payloads. >=20 > So in total the technical differences will be 7 extra bytes. Is there > anything else? Regardless of what the authors of this document do, that question is not = relevant to whether or not you, as the designated expert, give them a = codepoint. --Paul Hoffman From dharkins@lounge.org Mon Aug 1 12:29:07 2011 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 A4BF411E813D for ; Mon, 1 Aug 2011 12:29:07 -0700 (PDT) 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 wZdVn7yZ3rql for ; Mon, 1 Aug 2011 12:29:06 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DEA5E11E8137 for ; Mon, 1 Aug 2011 12:29:06 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7DE00A888108; Mon, 1 Aug 2011 12:29:13 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 1 Aug 2011 12:29:13 -0700 (PDT) Message-ID: In-Reply-To: <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> Date: Mon, 1 Aug 2011 12:29:13 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" 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: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 01 Aug 2011 19:29:07 -0000 On Mon, August 1, 2011 9:11 am, Paul Hoffman wrote: > On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote: >> I have stated my reasons why I consider allocating multiple payload >> numbers etc for exactly same thing a bad thing. > > The three proposals do not do "exactly the same thing": they each have > different cryptographic and administrative properties. This has been > widely discussed in the WG. Yes, they do do "exactly the same thing", they all implement a zero knowledge proof to authenticate the peers using a simple password. They use cryptography differently to achieve that same result but that doesn't mean the "cryptographic properties" are different; they're not. The cryptographic property that the exchanges have is resistance to off-line dictionary attack, i.e. the advantage an attacker gains is through interaction and not computation. Administrative differences? They all use the same D-H group used in IKE and they all need to be provisioned with a password. No difference there either. If these drafts had some different properties, or were different in any meaningful and technical way, then we'd have a "winner" already. But we don't, and that's because they do the same thing and have the same properties. All we have to show for those delays and the capricious process imposed on the WG is an implementation problem-- 3 ways of doing the same thing. Dan. From turners@ieca.com Tue Aug 2 05:47:27 2011 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 EDE7A21F8D55 for ; Tue, 2 Aug 2011 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 GFw+YFHtPYv6 for ; Tue, 2 Aug 2011 05:47:26 -0700 (PDT) Received: from nm27.access.bullet.mail.mud.yahoo.com (nm27.access.bullet.mail.mud.yahoo.com [66.94.237.92]) by ietfa.amsl.com (Postfix) with SMTP id F216621F8D70 for ; Tue, 2 Aug 2011 05:47:25 -0700 (PDT) Received: from [66.94.237.201] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 02 Aug 2011 12:47:30 -0000 Received: from [98.139.221.60] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 02 Aug 2011 12:47:29 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 02 Aug 2011 12:47:29 -0000 X-Yahoo-Newman-Id: 723047.35639.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: If63Xq8VM1lZ9Y.l7Co8dH3jj3ZKb6jsVsAH1bcE_sjMw6l s.pfGzsjwxpk.jsazKKM3HFvakjXYWTgqa6WKwEchjTx0IsQ0J6LNntAXd6Z J1ycwUdjiNd.cHheMBRlt53nJ5R7Dw90chWGqvOQOp_3rLNMbzTy3q1cCeo7 HipMfbgS5NPxKfnpNdZ0Di.dcIoTdwdJDuVVimgg7enS2Wamk8g9rW_kQext nv6ZU000mUdsCKezEQPh7hc.wjAjz11uLZykzwE4hLG1KuD4dl587wQ1W9G2 6ZQ_uIL0k5Xnl01ZXhFNSfw_9AbO2_JG0Ki4PBLgqm__RxET.1ecbz3200gV D.3rnZ7dF5L72ZF2pK2hEegA- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.121.225 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 02 Aug 2011 05:47:25 -0700 PDT Message-ID: <4E37F1D2.90305@ieca.com> Date: Tue, 02 Aug 2011 08:47:14 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Hoffman References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> In-Reply-To: <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 02 Aug 2011 12:47:27 -0000 On 8/1/11 12:11 PM, Paul Hoffman wrote: > On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote: > >> As we have seen from the ipsec list the community does not seem to >> care too much, but I myself as a member of the community and also the >> person responsible for the IANA registries do care. WRT who is responsible ... Technically, IANA is responsible for maintaining the registries in accordance with the registration rules documented in the RFC that creates/defines the registry. The IANA experts (who are appointed by the IESG) are responsible for reviewing requests for additions and modifications in the registries that they are designated for. The IETF/IESG is ultimately responsible for the registry as (most of them) are a product of the IETF process. > You are *not* responsible for the IANA registries. RFC 5226 says: > > It should be noted that a key motivation for having designated > experts is for the IETF to provide IANA with a subject matter expert > to whom the evaluation process can be delegated. IANA forwards > requests for an assignment to the expert for evaluation, and the > expert (after performing the evaluation) informs IANA as to whether > or not to make the assignment or registration. > > . . . > > Designated experts are expected to be able to defend their decisions > to the IETF community, and the evaluation process is not intended to > be secretive or bestow unquestioned power on the expert. Experts are > expected to apply applicable documented review or vetting procedures, > or in the absence of documented criteria, follow generally accepted > norms, e.g., those in Section 3.3. > > I do not believe that you can defend a decision to reject registrations based on what is in RFC 4306. If you disagree, please show which text you are referring to. My understanding is that Tero is stating early that he would deny the requests based scarcity of code points, which is allowed per RFC 5226: Possible reasons to deny a request include: - scarcity of code points, where the finite remaining code points should be prudently managed, or when a request for a large number of code points is made, when a single code point is the norm. >> I have stated my reasons why I consider allocating multiple payload >> numbers etc for exactly same thing a bad thing. > > The three proposals do not do "exactly the same thing": they each have different cryptographic and administrative properties. This has been widely discussed in the WG. But, they're for the same "thing": extension(s) to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. spt >> As it seems that IKEv2 might be used with other things than IPsec too >> in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in >> the IKEv2 IANA registries. >> >> Even if those use cases are not IPsec they most likely will reuse most >> of the registries from the IPsec. We could overlap their numbers with >> each other, but on the other hand that can cause confusion, so it >> might be better to make sure they do not have overlapping numbers, >> i.e. use of unique numbers for different things and mark those as >> reserved in the registries which do not use them. >> >> This is bit what IKEv1 and IKEv2 did, for example we are not using >> payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1 >> used them. Same way our exchange numbers 0-33 are reserved etc. >> >> I am not sure whether we are doing that in the future or not. I want >> to think more about this and see the actual protocols before deciding. > > This should be a WG/IETF decision, not that of a single person. > >> But on the other hand I want to keep our options open, which means I >> do not want to fill our registries with multiple registrations for the >> exactly same thing. > > See above. > >> Can you explain me what problems will it cause if the >> draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the >> draft-kivinen-ipsecme-secure-password-framework framework just like >> other secure password method drafts have already done? > > >> In my understanding there will be 2 extra bytes in the IKE_SA_INIT >> notification phase to indicate the PACE inside >> N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two >> depending how you do it) in the ENONCE and PKEi/PKEr payloads. >> >> So in total the technical differences will be 7 extra bytes. Is there >> anything else? > > Regardless of what the authors of this document do, that question is not relevant to whether or not you, as the designated expert, give them a codepoint. > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Tue Aug 2 06:12:15 2011 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 D75FC21F8B91 for ; Tue, 2 Aug 2011 06:12:15 -0700 (PDT) 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 p94KxGHixekD for ; Tue, 2 Aug 2011 06:12:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0801421F8B12 for ; Tue, 2 Aug 2011 06:12:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p72DCIuH023867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Aug 2011 16:12:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p72DCIvh025748; Tue, 2 Aug 2011 16:12:18 +0300 (EEST) 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: <20023.63410.170713.739208@fireball.kivinen.iki.fi> Date: Tue, 2 Aug 2011 16:12:18 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 51 min X-Total-Time: 57 min Cc: IPsecme WG Subject: [IPsec] Role of the IANA expert reviewer 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, 02 Aug 2011 13:12:16 -0000 Paul Hoffman writes: > You are *not* responsible for the IANA registries. RFC 5226 says: > > It should be noted that a key motivation for having designated > experts is for the IETF to provide IANA with a subject matter expert > to whom the evaluation process can be delegated. IANA forwards > requests for an assignment to the expert for evaluation, and the > expert (after performing the evaluation) informs IANA as to whether > or not to make the assignment or registration. Ok, perhaps using word of being responsible for the IANA registries is wrong as IANA will be responsible for the actual registries, but it is my understanding that designed expert is support to help IANA to keep the registries usable. > . . . > > Designated experts are expected to be able to defend their decisions > to the IETF community, and the evaluation process is not intended to > be secretive or bestow unquestioned power on the expert. Experts are > expected to apply applicable documented review or vetting procedures, > or in the absence of documented criteria, follow generally accepted > norms, e.g., those in Section 3.3. > > I do not believe that you can defend a decision to reject > registrations based on what is in RFC 4306. If you disagree, please > show which text you are referring to. If I have to be able to defend all my decisions to reject things based on the RFC4306 only, there is no way I can reject anything as the only text in there is text which says: ---------------------------------------------------------------------- Note: When creating a new Transform Type, a new registry for it must be created. Changes and additions to any of those registries are by expert review. ---------------------------------------------------------------------- So if someone sends IANA a request (note, you do not even need Internet-Draft or RFC) saying that he made typo in his code and wrote 53 instead of 3 for his 3DES algorithm number and now wants to make new allocation saying that 53 means ENCR_3DES, then I do not have any way to say that this should not be allowed to IANA, as RFC4306 does not give such option. Or if someone wants to change numbers like Diffie-Hellman Group Transform ID 19 to mean completely something else than what it means now (which actually did happen, and during that discussion area directors managed to convince me that it would be better to accept that change of existing codepoint, and not allocate new codepoint for this new use). What is the point of having designated expert if there is nothing he can do than to follow RFC creating the registries, especially when those RFCs do not give any specific instructions? My undestandating has been that as the RFCs creating the IANA registries do not include exact rules for allocations then it is designated experts responsiblity to interpreted what could have been said in the RFC in question for those allocations. This would mean things like "do not make changes to existing code points which are not needed", "do not make duplicate allocations for existing code points without good reason" etc. In some cases it is needed to do that kind of things, like there was in the ECP group i.e. some of the existing vendors had already used the number in question that way and it was seen that those vendors were important enough and slow enough that they would never update their products to new numbers if such numbers would be allocated. In some cases there is no need to break those unwritten rules. This is the case where I do not see real reason to break those unwritten rules which say "no duplicate codepoints for the same thing". Of course people who are unhappy with the work of the expert are allowed to appeal to the IESG about every decision the expert makes. > > I have stated my reasons why I consider allocating multiple payload > > numbers etc for exactly same thing a bad thing. > > The three proposals do not do "exactly the same thing": they each > have different cryptographic and administrative properties. This has > been widely discussed in the WG. Note that I did not claim that three proposals are "exactly the same thing", I said that the payload types they allocate are "for the excatly same thing", i.e. transfering secure password protocol specific data between the peers. In RFC4306 we do not have separate KE payload allocated for each different key type (one for ECP, one for MODP etc). Same goes with the CERT/AUTH etc payloads. The RFC4306 usually allocates one payload number for one specific purpose and if multiple different formats for the same thing is needed then there is subtype inside this payload. This is true for KE/IDi/IDr/CERT/CERTREQ/AUTH/TSi/TSr/CP payloads at least. SA/N/D payloads hava protocol ID inside which then changes the values going after it. Actually only the Ni/Nr/V and EAP payloads do not have subtype inside, and in EAP case there is subtype, but it is inside the EAP payload. I.e. the current RFC4306 use of payloads do use subtypes a lot and those subtypes change the payload format inside the main payload. We do have two numbers for the same payload in the RFC4306 case, especially for TSi/TSr and IDi/IDr, but this is because both of those payloads (i.e. TSi/TSr and IDi/IDr) can happen in the same message, and we wanted to remove the ordering restriction from there, meaning instead of relying on the payload order to decide which of them is initiator payload (TSi/IDi) and which is responder (TSr/IDr) we have separate numbers for them. On the other hand we also use Ni/Nr for nonces, but they only have one payload number allocated for them as they can never happen in the same message, thus it is easy to see which one is which. There are similar reasons why there is no need to allocate separate exchange type for each of the protocols (all of them follow the similar payload exchanges which are already done for the EAP, and we didn't allocate separate exchange type for IKE_AUTH when used with EAP, so we should not do it here too). To come back to the "The tree proposals do not do exactly same thing", I do also consider the tree proposals do the same thing; they provide solution to exactly same problem. They do have technical differences, but they provide solution to the same problem, which I do consider meaning they are do same thing. > > I am not sure whether we are doing that in the future or not. I want > > to think more about this and see the actual protocols before deciding. > > This should be a WG/IETF decision, not that of a single person. How on earth can you interpret statement saying "I am not sure whether *we* are doing that in the future or not." to indicate that it will be a single persons decision? I *as a community member* and as a designated expert do want to think more about this before giving my input about this in future, and I do not want to close our options now. Also the WG will most likely be closed before those decisions needs to be done. If I will get asked input from IANA as designated expert, I will of course ask input from the community (ipsec-list) too, but the list has not been as active as you would like to get input for different things lately. Note, also that those documents will most likely come from the other working groups and go through their own WGLC and then go to the IESG, and they might have separate IANA registries and separate designated etc. This part of the discussion is bit early, but as it is the problem that I can see that the designated expert of the ikev2 registries might see in the future (how far in future is different thing), and I happen to be the designated expert now, I want to think about this early, not only after the problem is there. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Aug 2 07:23:58 2011 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 EC496228006 for ; Tue, 2 Aug 2011 07:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 mfZNdxCG3nM4 for ; Tue, 2 Aug 2011 07:23:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D20321F84F9 for ; Tue, 2 Aug 2011 07:23:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72ENj5G011099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 07:23:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4E37F1D2.90305@ieca.com> Date: Tue, 2 Aug 2011 07:24:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <017C02B6-0B64-4499-B9C8-DB157169CAC8@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> <4E37F1D2.90305@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1244.3) Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 02 Aug 2011 14:23:59 -0000 On Aug 2, 2011, at 5:47 AM, Sean Turner wrote: > My understanding is that Tero is stating early that he would deny the = requests based scarcity of code points For a registry of this size with so few codepoints allocated so far (and = so many reserved code points that can be allocated later) that could = easily be extended later, this would be an example of premature = scarcity. > But, they're for the same "thing": extension(s) to IKEv2 to allow > mutual authentication based on "weak" (low-entropy) shared > secrets. This line of argument would allow Tero to not allocate code points for = SHA-3, because it does the "same thing" as SHA-2. Let's not go there. --Paul Hoffman From paul.hoffman@vpnc.org Tue Aug 2 07:43:00 2011 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 0E3F421F84F3 for ; Tue, 2 Aug 2011 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 D7UO2Mg261SS for ; Tue, 2 Aug 2011 07:42:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E83121F84ED for ; Tue, 2 Aug 2011 07:42:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72EgkXD011830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 07:42:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20023.63410.170713.739208@fireball.kivinen.iki.fi> Date: Tue, 2 Aug 2011 07:43:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> <20023.63410.170713.739208@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1244.3) Cc: IPsecme WG Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 02 Aug 2011 14:43:00 -0000 On Aug 2, 2011, at 6:12 AM, Tero Kivinen wrote: > Paul Hoffman writes: >> You are *not* responsible for the IANA registries. RFC 5226 says: >>=20 >> It should be noted that a key motivation for having designated >> experts is for the IETF to provide IANA with a subject matter = expert >> to whom the evaluation process can be delegated. IANA forwards >> requests for an assignment to the expert for evaluation, and the >> expert (after performing the evaluation) informs IANA as to whether >> or not to make the assignment or registration. >=20 > Ok, perhaps using word of being responsible for the IANA registries is > wrong as IANA will be responsible for the actual registries, but it is > my understanding that designed expert is support to help IANA to keep > the registries usable.=20 Absolutely. And, you have done a fine job of that so far (certainly = better than I could have done). In my mind, keeping serious proposals = for IKEv2 functionality out of the registry does not keep it useful. > If I have to be able to defend all my decisions to reject things based > on the RFC4306 only, there is no way I can reject anything as the only > text in there is text which says: >=20 > ---------------------------------------------------------------------- > Note: When creating a new Transform Type, a new registry for it must > be created. >=20 > Changes and additions to any of those registries are by expert > review. > ---------------------------------------------------------------------- You can reject whatever you want, subject to IETF review. This thread is = that review, ahead of time. I am disagreeing with your apparent decision = to reject these ahead of time. >>> I have stated my reasons why I consider allocating multiple payload >>> numbers etc for exactly same thing a bad thing. >>=20 >> The three proposals do not do "exactly the same thing": they each >> have different cryptographic and administrative properties. This has >> been widely discussed in the WG. >=20 > Note that I did not claim that three proposals are "exactly the same > thing", I said that the payload types they allocate are "for the > excatly same thing", i.e. transfering secure password protocol > specific data between the peers. And SHA-3 will do "exactly the same thing" as SHA-2: will you not = allocate code points for it? :-) > In RFC4306 we do not have separate KE payload allocated for each > different key type (one for ECP, one for MODP etc). Same goes with the > CERT/AUTH etc payloads. The RFC4306 usually allocates one payload > number for one specific purpose and if multiple different formats for > the same thing is needed then there is subtype inside this payload. > This is true for KE/IDi/IDr/CERT/CERTREQ/AUTH/TSi/TSr/CP payloads at > least. SA/N/D payloads hava protocol ID inside which then changes the > values going after it. Actually only the Ni/Nr/V and EAP payloads do > not have subtype inside, and in EAP case there is subtype, but it is > inside the EAP payload. >=20 > I.e. the current RFC4306 use of payloads do use subtypes a lot and > those subtypes change the payload format inside the main payload. Sure, but that is because we knew which values we wanted when we wrote = IKEv2. Today, we are talking about extensions. > We do have two numbers for the same payload in the RFC4306 case, > especially for TSi/TSr and IDi/IDr, but this is because both of those > payloads (i.e. TSi/TSr and IDi/IDr) can happen in the same message, > and we wanted to remove the ordering restriction from there, meaning > instead of relying on the payload order to decide which of them is > initiator payload (TSi/IDi) and which is responder (TSr/IDr) we have > separate numbers for them. On the other hand we also use Ni/Nr for > nonces, but they only have one payload number allocated for them as > they can never happen in the same message, thus it is easy to see > which one is which. >=20 > There are similar reasons why there is no need to allocate separate > exchange type for each of the protocols (all of them follow the > similar payload exchanges which are already done for the EAP, and we > didn't allocate separate exchange type for IKE_AUTH when used with > EAP, so we should not do it here too). >=20 > To come back to the "The tree proposals do not do exactly same thing", > I do also consider the tree proposals do the same thing; they provide > solution to exactly same problem. They do have technical differences, > but they provide solution to the same problem, which I do consider > meaning they are do same thing. Thank you for giving the fuller explanation of your thinking. However, I = still don't think that justifies rejecting ahead of time the idea that = each gets its own IANA allocation: it just argues more effectively for = your current draft on how to negotiate them. I think those two are = completely separate discussions, which is why I changed the subject on = this thread. >>> I am not sure whether we are doing that in the future or not. I want >>> to think more about this and see the actual protocols before = deciding. >>=20 >> This should be a WG/IETF decision, not that of a single person. >=20 > How on earth can you interpret statement saying "I am not sure whether > *we* are doing that in the future or not." to indicate that it will be > a single persons decision? The "I" part. The expert reviewers for some IANA registries seem to = think that they are the ones who do this consideration, and your use of = "I" instead of "we" concerned me. (This could be an English/Finnish = thing...) > I *as a community member* and as a designated expert do want to think > more about this before giving my input about this in future, and I do > not want to close our options now. Yay! We are in agreement then. > Also the WG will most likely be closed before those decisions needs to > be done. If I will get asked input from IANA as designated expert, I > will of course ask input from the community (ipsec-list) too, but the > list has not been as active as you would like to get input for > different things lately. If you have questions about what you are doing as expert reviewer, by = all means please start discussions on this list, regardless of whether = it is a WG or not. > Note, also that those documents will most likely come from the other > working groups and go through their own WGLC and then go to the IESG, > and they might have separate IANA registries and separate designated > etc. And this list should discuss that as well. > This part of the discussion is bit early, but as it is the problem > that I can see that the designated expert of the ikev2 registries > might see in the future (how far in future is different thing), and I > happen to be the designated expert now, I want to think about this > early, not only after the problem is there. Assuming you mean "we" instead of "I" there, we are in complete = agreement. --Paul Hoffman From ynir@checkpoint.com Tue Aug 2 09:00:42 2011 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 9FE7911E8098 for ; Tue, 2 Aug 2011 09:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2gM8tsWBY68A for ; Tue, 2 Aug 2011 09:00:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB311E808A for ; Tue, 2 Aug 2011 09:00:41 -0700 (PDT) X-CheckPoint: {4E382CB6-8-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p72G0mQS026115; Tue, 2 Aug 2011 19:00:48 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 2 Aug 2011 19:00:48 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 2 Aug 2011 19:00:47 +0300 From: Yoav Nir To: Paul Hoffman Date: Tue, 2 Aug 2011 19:00:48 +0300 Thread-Topic: [IPsec] Role of the IANA expert reviewer Thread-Index: AcxRLVeJgRI5hyVDQwymfNgXwnOumg== Message-ID: References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> <20023.63410.170713.739208@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 02 Aug 2011 16:00:42 -0000 On Aug 2, 2011, at 5:43 PM, Paul Hoffman wrote: >=20 >>>> I have stated my reasons why I consider allocating multiple payload >>>> numbers etc for exactly same thing a bad thing. >>>=20 >>> The three proposals do not do "exactly the same thing": they each >>> have different cryptographic and administrative properties. This has >>> been widely discussed in the WG. >>=20 >> Note that I did not claim that three proposals are "exactly the same >> thing", I said that the payload types they allocate are "for the >> excatly same thing", i.e. transfering secure password protocol >> specific data between the peers. >=20 > And SHA-3 will do "exactly the same thing" as SHA-2: will you not allocat= e code points for it? :-) If we knew as much about algorithms as we do about protocols, yes. But we d= on't. We don't know what algorithm will be considered secure in 2020, and t= hat is why there's a (rough?) consensus in the IETF that algorithm agility = is a "good thing". There is no such consensus that protocol variants are a good thing. I think= it's just the opposite. Although I don't think it's Tero's job to stop the= publication of three documents that are "for the same thing". That should = be done by the community. Yoav= From kivinen@iki.fi Wed Aug 3 06:23:17 2011 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 6521121F8B59 for ; Wed, 3 Aug 2011 06:23:17 -0700 (PDT) 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 8YgElaN8k6RE for ; Wed, 3 Aug 2011 06:23:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16DC21F8B56 for ; Wed, 3 Aug 2011 06:23:15 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p73DNNVm010960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Aug 2011 16:23:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p73DNKGC010089; Wed, 3 Aug 2011 16:23:20 +0300 (EEST) 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: <20025.19400.703811.349034@fireball.kivinen.iki.fi> Date: Wed, 3 Aug 2011 16:23:20 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> <20023.63410.170713.739208@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 57 min X-Total-Time: 64 min Cc: IPsecme WG Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 13:23:17 -0000 Paul Hoffman writes: > > Ok, perhaps using word of being responsible for the IANA registries is > > wrong as IANA will be responsible for the actual registries, but it is > > my understanding that designed expert is support to help IANA to keep > > the registries usable. > > Absolutely. And, you have done a fine job of that so far (certainly > better than I could have done). In my mind, keeping serious > proposals for IKEv2 functionality out of the registry does not keep > it useful. I have not tried to keep any proposal out from the IKEv2, I wanted the proposals which do about same thing, and which already have separate mechanism to negotiate which of them is used, to use same numbers for the payloads / exchange / authentication types in the IKE_AUTH phase. The only differences in the for example for the exchange type would be to use number 35 as exchange type instead of allocating new number. Same thing with payload number, i.e all three proposals would be using same payload number for their own payloads. All three of the protocols can still be used, I just wanted them to use same numbers for same things as this is how IKEv2 does for those registries. We have IKE_AUTH, not IKE_AUTH_PSK_CERT, IKE_AUTH_EAP_FIRST, IKE_AUTH_EAP_INTERMEDIATE, IKE_AUTH_EAP_LAST. Creating two new exchanges IKE_PACE, IKE_PACE_AUTH is not how IKEv2 does things normally, especially as the IKE_PACE combined with IKE_PACE_AUTH looks very much like IKE_AUTH done with EAP, except that it uses secure password method specific payloads instead of EAP payloads. Also as I said in EAP we do have one EAP specific payload we use to transmit all EAP specific data inside the IKE_AUTH. We do not have multiple EAP specific payloads transmitting differenet EAP payloads in IKEv2. We could have EAP_REQUEST, EAP_RESPONSE, EAP_SUCCESS, EAP_FAILURE payloads in IKEv2 instead of using just one EAP payload. Especially as the IKEv2 code needs to check into the code inside to see whether it is EAP_SUCCESS or EAP_FAILURE. IKEv2 way of allocating IANA numbers have been so that it tries to save numbers especially on the 8 bit registries. It is very different when you compare what we have done for example in the Encryption Algorithm Transform IDs registry. That registry is 16-bit registry with 1022 numbers for IANA to allocate, and there we have for example 9 numbers allocated for different AES variants (CBC, CTR, CCM_8, CCM_12, CCM_16, GCM_8, GCM_12, GCM_16, GMAC). > > If I have to be able to defend all my decisions to reject things based > > on the RFC4306 only, there is no way I can reject anything as the only > > text in there is text which says: > > > > ---------------------------------------------------------------------- > > Note: When creating a new Transform Type, a new registry for it must > > be created. > > > > Changes and additions to any of those registries are by expert > > review. > > ---------------------------------------------------------------------- > > You can reject whatever you want, subject to IETF review. This > thread is that review, ahead of time. I am disagreeing with your > apparent decision to reject these ahead of time. That would be fine, if you would defend your disagreement with technical reasons, but you seem to be just rejecting about the fact that any numbers could be rejected even with technical reasons. I have given out my reasons why I want all of those methods to use same number space (i.e. want to keep the registry clean, do not want to allocate duplicate numbers for same things (not same protocols, but for example same kind of payloads), want to keep allocations in the same way other allocations in IKEv2 has been done etc). I have listed some of those in my previous emails, altough it might be that I have not formulated all of them very throughly and those reasons might have been scattered in different emails, and I have mostly concentrated in the most technical aspect, i.e. the small number space of payload numbers, and keeping the more political ones (like following the similar way of doing allocations than what is done in the IKEv2 RFC) in the background. > > Note that I did not claim that three proposals are "exactly the same > > thing", I said that the payload types they allocate are "for the > > excatly same thing", i.e. transfering secure password protocol > > specific data between the peers. > > And SHA-3 will do "exactly the same thing" as SHA-2: will you not > allocate code points for it? :-) SHA-3 will get code point, as will any other reasonable cipher/hash. Actually SHA-3 will most likely get 3 + 3 code points as this is how things are allocated in IKEv2. I.e. it will get 3 code points in the PRF registry for 256, 384 and 512 bit sizes and it will also get 3 code points in the Integrity Algorithm Transform ID registry. Those registries are 16-bit registries, and they have 1022 numbers for IANA allocation and 64511 for private use. I do not see any reason to limit allocations for SHA-3 in that registry as that is not small registry, and the way we normally do allocations there is to encode the size to that number. I would most likely be against if someone would like to create new Transform Attribute Type for HASH Length attribute (similar than what we now have for Key Length arttribute for encryption cipher), and then said that we only allocate one SHA-3 attribute and mandate it to be used with that new HASH Length attribute type with values indicating whether it is 256, 384 or 512 bits. My reason would be that it is so much different than current IKEv2 allocations for hashes. On the other hand if SHA-3 family will support any random bit lengths and someone wants to support SHA-3-1, SHA-3-2, SHA-3-3, ... SHA-3-1023, SHA-3-1024, then I would exactly propose using the method above instead of allocating 1024 numbers to the SHA-3. And in both cases I would try to convince the people doing that work way before it comes to IANA allocation phase, and I would again be telling that my reasons might still be same if it comes to IANA allocation phase (as I did in this time). > > I.e. the current RFC4306 use of payloads do use subtypes a lot and > > those subtypes change the payload format inside the main payload. > > Sure, but that is because we knew which values we wanted when we > wrote IKEv2. Today, we are talking about extensions. We are talking about extensions which know EXACTLY which subpayloads they want to support. For two of the drafts there is exactly one type of payload they send, for one there is two different payloads in both directions. And everything what goes inside the payload is going to be method specific anyway, so if someone make yet another secure password method then they format their payload as they like. > Thank you for giving the fuller explanation of your thinking. > However, I still don't think that justifies rejecting ahead of time > the idea that each gets its own IANA allocation: it just argues more > effectively for your current draft on how to negotiate them. I think > those two are completely separate discussions, which is why I > changed the subject on this thread. If we do not negotiate the methods at all (as some of them didn't) then there would be no other option than to allocate each of them some separate numbers, as that would be only way to distinguish them. So to have *a* way to know which method is used, is requirement for the shared allocations. Note, that method does not need to be same for all drafts, there just needs to be some way to know which method is used. All current methods already have a way to know which method is used, altought the way is not same. > >>> I am not sure whether we are doing that in the future or not. I want > >>> to think more about this and see the actual protocols before deciding. > >> > >> This should be a WG/IETF decision, not that of a single person. > > > > How on earth can you interpret statement saying "I am not sure whether > > *we* are doing that in the future or not." to indicate that it will be > > a single persons decision? > > The "I" part. I cannot speak for the whole working group / IETF, which is why I said that I am not sure what we (meaning the WG / IETF) are doing in future. > The expert reviewers for some IANA registries seem to think that > they are the ones who do this consideration, and your use of "I" > instead of "we" concerned me. (This could be an English/Finnish > thing...) The "I" part refered to my own thinking, the "we" part refered to the community who decides. I do not think collective thoughts are that common yet (at least here in Finland), so I usually think I will be using I when I refer to my own thoughts... Saying "We are not sure whether we are doing that" would indicate majestic plural for my ears, which might have been even worse... -- kivinen@iki.fi From kivinen@iki.fi Wed Aug 3 06:55:24 2011 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 EEC0721F8B79 for ; Wed, 3 Aug 2011 06:55:23 -0700 (PDT) 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 iuqwnt39jlFj for ; Wed, 3 Aug 2011 06:55:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8A621F8B78 for ; Wed, 3 Aug 2011 06:55:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p73DtNnU010226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2011 16:55:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p73DtJBZ010303; Wed, 3 Aug 2011 16:55:19 +0300 (EEST) 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: <20025.21319.658286.892954@fireball.kivinen.iki.fi> Date: Wed, 3 Aug 2011 16:55:19 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> <20023.63410.170713.739208@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 13:55:24 -0000 Yoav Nir writes: > There is no such consensus that protocol variants are a good thing. > I think it's just the opposite. Although I don't think it's Tero's > job to stop the publication of three documents that are "for the > same thing". That should be done by the community. I am most definately not trying to stop any of the documents. I am trying to make sure that the documents can go forward and get IANA allocations done in a nice and consistent way, which will also make it easier for implementors to implement one or multiple of those methods. The actual numbers used inside the protocols does not affect the actual protocols that much, especially as there are no numbers in any of the documents yet (i.e. you cannot say changing the numbers would break interoperability with early implementations). -- kivinen@iki.fi From ynir@checkpoint.com Wed Aug 3 07:00:06 2011 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 994CF21F8AF0 for ; Wed, 3 Aug 2011 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3GYeQrfG-4Id for ; Wed, 3 Aug 2011 07:00:05 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6A821F8AE1 for ; Wed, 3 Aug 2011 07:00:04 -0700 (PDT) X-CheckPoint: {4E3961F3-4F-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p73E0BfM011479; Wed, 3 Aug 2011 17:00:12 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 3 Aug 2011 17:00:12 +0300 From: Yoav Nir To: Tero Kivinen Date: Wed, 3 Aug 2011 17:00:13 +0300 Thread-Topic: [IPsec] Role of the IANA expert reviewer Thread-Index: AcxR5akefpvaoMB/RwWA3LnYknsYKA== Message-ID: In-Reply-To: <20025.21319.658286.892954@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 14:00:06 -0000 On 8/3/11 4:55 PM, "Tero Kivinen" wrote: >Yoav Nir writes: >> There is no such consensus that protocol variants are a good thing. >> I think it's just the opposite. Although I don't think it's Tero's >> job to stop the publication of three documents that are "for the >> same thing". That should be done by the community. > >I am most definately not trying to stop any of the documents. > >I am trying to make sure that the documents can go forward and get >IANA allocations done in a nice and consistent way, which will also >make it easier for implementors to implement one or multiple of those >methods. Fully agree. But I also think that it *is* up to the community to stop these three from moving on, and choose only one of them instead. Since we haven't found any expert who will say that one is definitely better than the others, almost any selection method will do. Sean and Paul rolling a big fuzzy die at the SAAG meeting in Tai-Pei is one good way to do this. Yoav From yaronf.ietf@gmail.com Wed Aug 3 10:09:10 2011 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 7AC8C21F863C for ; Wed, 3 Aug 2011 10:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 Lb0aO4rkXvQU for ; Wed, 3 Aug 2011 10:09:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5827921F863A for ; Wed, 3 Aug 2011 10:09:09 -0700 (PDT) Received: by wwe5 with SMTP id 5so723477wwe.13 for ; Wed, 03 Aug 2011 10:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ydHVHkHL2/JAuRcX+1tIRUi7DeyMvfibKxFKx56NiJI=; b=I1qLaqoRHIvGfcXf7p8DybGa48yB9MjhkSpOyUwvZDOgMjk8YnJv6rVrtCnS3bMdDd aIAAIni54XtZWKB0hqGTj9CF/mwQIuCFohPstn7VSUJbLP+iOwciW/92nVS4Vve6I671 dBRGLWrRsyqli2EHtBPyGdC9CFv4W9cDrC9Y8= Received: by 10.227.180.205 with SMTP id bv13mr2107182wbb.93.1312391361110; Wed, 03 Aug 2011 10:09:21 -0700 (PDT) Received: from [10.0.0.6] (93-173-6-225.bb.netvision.net.il [93.173.6.225]) by mx.google.com with ESMTPS id fn12sm831831wbb.38.2011.08.03.10.09.18 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 10:09:20 -0700 (PDT) Message-ID: <4E3980BD.4080307@gmail.com> Date: Wed, 03 Aug 2011 20:09:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 17:09:10 -0000 Hi Yoav, as a coauthor on one of these documents, I find your proposal below positively insulting. There were three author teams, and you should give them credit for having rational reasons for publishing these documents and moving them through the IETF progress. Rolling a dice is a lazy solution that wouldn't result in an outcome we can justify. OTOH, an open cryptographic review of the three options most certainly would. Until such a process takes place, I would rather we have three Experimental protocols. Thanks, Yaron On 08/03/2011 05:00 PM, Yoav Nir wrote: > > On 8/3/11 4:55 PM, "Tero Kivinen" wrote: > >> Yoav Nir writes: >>> There is no such consensus that protocol variants are a good thing. >>> I think it's just the opposite. Although I don't think it's Tero's >>> job to stop the publication of three documents that are "for the >>> same thing". That should be done by the community. >> I am most definately not trying to stop any of the documents. >> >> I am trying to make sure that the documents can go forward and get >> IANA allocations done in a nice and consistent way, which will also >> make it easier for implementors to implement one or multiple of those >> methods. > Fully agree. But I also think that it *is* up to the community to stop > these three from moving on, and choose only one of them instead. > > Since we haven't found any expert who will say that one is definitely > better than the others, almost any selection method will do. > > Sean and Paul rolling a big fuzzy die at the SAAG meeting in Tai-Pei is > one good way to do this. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Aug 3 11:07:53 2011 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 7DF0D21F8538 for ; Wed, 3 Aug 2011 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fhBR3TkBqYgN for ; Wed, 3 Aug 2011 11:07:53 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF421F855D for ; Wed, 3 Aug 2011 11:07:41 -0700 (PDT) X-CheckPoint: {4E399BF9-12-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p73I7m8v025497; Wed, 3 Aug 2011 21:07:48 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 3 Aug 2011 21:07:48 +0300 From: Yoav Nir To: Yaron Sheffer Date: Wed, 3 Aug 2011 21:07:46 +0300 Thread-Topic: [IPsec] Role of the IANA expert reviewer Thread-Index: AcxSCD/XAZZoNnoaQ86mJw5op0mZSw== Message-ID: <0F7BB6CD-CDA8-480C-A8F5-4F66BA57D30F@checkpoint.com> References: <4E3980BD.4080307@gmail.com> In-Reply-To: <4E3980BD.4080307@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 18:07:53 -0000 On Aug 3, 2011, at 8:09 PM, Yaron Sheffer wrote: > Hi Yoav, >=20 > as a coauthor on one of these documents, I find your proposal below=20 > positively insulting. There were three author teams, and you should give= =20 > them credit for having rational reasons for publishing these documents=20 > and moving them through the IETF progress. > Rolling a dice is a lazy solution that wouldn't result in an outcome we=20 > can justify. OTOH, an open cryptographic review of the three options=20 > most certainly would.=20 The way I've heard it, such a review did take place without the desired res= ults. Managers sometimes need to make decisions even without complete knowledge. = And in such cases that decision can seem to be based on a hunch or rolling = the die. It's better than this decision not to decide, because it shifts th= e burden to developers.= From yaronf.ietf@gmail.com Wed Aug 3 11:43:43 2011 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 D743611E807C for ; Wed, 3 Aug 2011 11:43:43 -0700 (PDT) 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 dLR7W9NbbdK5 for ; Wed, 3 Aug 2011 11:43:43 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 24ED011E8078 for ; Wed, 3 Aug 2011 11:43:42 -0700 (PDT) Received: by wwg11 with SMTP id 11so3725053wwg.1 for ; Wed, 03 Aug 2011 11:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4MwQQHK95F5hBHc7tP4UofUBXviOWL68R3FSqxf8oUM=; b=DF7iKR+reQ9l46YjHQW+HDF+tXmOivmpZskHaReBiGuFfIgzGe5189focjkk7EKWJj DW3fMW9RAQcRSIScsza8B29WBvxtpeCcVR5W0IhNhwJ3t0SfdKxs3QD8TzVIZ25F++3r /wVRrd+hTr51CH1b6Izc4eoPvRU6l1Nzsrstk= Received: by 10.227.202.14 with SMTP id fc14mr8751355wbb.83.1312397035062; Wed, 03 Aug 2011 11:43:55 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-179-228-198.red.bezeqint.net [79.179.228.198]) by mx.google.com with ESMTPS id fc2sm893726wbb.18.2011.08.03.11.43.52 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 11:43:54 -0700 (PDT) Message-ID: <4E3996E4.6080302@gmail.com> Date: Wed, 03 Aug 2011 21:43:48 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Yoav Nir References: <4E3980BD.4080307@gmail.com> <0F7BB6CD-CDA8-480C-A8F5-4F66BA57D30F@checkpoint.com> In-Reply-To: <0F7BB6CD-CDA8-480C-A8F5-4F66BA57D30F@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 18:43:44 -0000 The IETF prides itself on an open process, and I would expect such a review to take place in an open and documented manner. Even if the bottom line is, "they are all the same". A named individual should take responsibility for the outcome. And if vendors are so interested in a PAKE solution, well they could always sponsor a starving cryptographer for a few days' work, for the benefit of the community. In fact I can think of at least one VPN vendor who actually employs cryptographers. Thanks, Yaron On 08/03/2011 09:07 PM, Yoav Nir wrote: > On Aug 3, 2011, at 8:09 PM, Yaron Sheffer wrote: > >> Hi Yoav, >> >> as a coauthor on one of these documents, I find your proposal below >> positively insulting. There were three author teams, and you should give >> them credit for having rational reasons for publishing these documents >> and moving them through the IETF progress. >> Rolling a dice is a lazy solution that wouldn't result in an outcome we >> can justify. OTOH, an open cryptographic review of the three options >> most certainly would. > The way I've heard it, such a review did take place without the desired results. > > Managers sometimes need to make decisions even without complete knowledge. And in such cases that decision can seem to be based on a hunch or rolling the die. It's better than this decision not to decide, because it shifts the burden to developers. From turners@ieca.com Wed Aug 3 11:58:10 2011 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 82AF111E807E for ; Wed, 3 Aug 2011 11:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 lQhbetgrSh1L for ; Wed, 3 Aug 2011 11:58:09 -0700 (PDT) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by ietfa.amsl.com (Postfix) with SMTP id A791811E8083 for ; Wed, 3 Aug 2011 11:58:09 -0700 (PDT) Received: from [98.139.91.66] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 18:58:19 -0000 Received: from [98.139.91.25] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 18:58:19 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 18:58:19 -0000 X-Yahoo-Newman-Id: 856195.90853.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 78516 invoked from network); 3 Aug 2011 18:58:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312397899; bh=X/QQNhdKINxa8sHroJJhXbixey84X/eSmgHLuYUCEV8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=1imXrbFQjfltjwmkdNGbnGS4CoqnAvtmTtTb9wCVdmP3cwinCV1xmClLiJvGD2qoSbvFrxkUQgEh/O/HFpRKFYu0iChknydHG+/oN1OUY2Ebd32NxdCk38hgLBLPuZx9oteZsxTe+8vAubpzthvbOOJc5R2362QFdSDtlMtrJoM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tmyjFokVM1kJLzOCsFTg5hR6o.8AfFJ33.OWPoiySYHc4jO KrGv0ElW6G1dK4j_3Df8f6yjaSnD8BEZAUNdXCYz2Pfu9fJGJ.ScD.1yv_gH UpYq6mhhWRGT8uWB4vTyLAUj9kZfjuIQgKi1q4GU7_vOpg4cZRmzM3tD1iGV 6ylphuerdj_AwybCvMAcwDyqgSGSmq3BwzBYq8oSsUOMcBuNhpNKLBwknKvs JdioVwzzu7Ad1GYIgHqMaQ_ZWbLo3OgZAGWnkKId0EPy4noZ4bh.vqokt.o4 8qaz5NQWq8gKBEV0MBkn4jbB343LSlzRttE9IeIdE7uNnL544rLTZPA4_rMi 0DoOr1ZUvcmxoGXh.4Q5_Pr0uIv9xNf_VzImDOquOdYUp X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@71.191.2.44 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 03 Aug 2011 11:58:19 -0700 PDT Message-ID: <4E399A4A.6020803@ieca.com> Date: Wed, 03 Aug 2011 14:58:18 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tero Kivinen References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> <4E332698.20900@gmail.com> <20022.47973.373596.130885@fireball.kivinen.iki.fi> <3B741203-FDF8-48EE-8942-C3FF3A2B5CF0@vpnc.org> <20023.63410.170713.739208@fireball.kivinen.iki.fi> <20025.21319.658286.892954@fireball.kivinen.iki.fi> In-Reply-To: <20025.21319.658286.892954@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Yoav Nir , Paul Hoffman Subject: Re: [IPsec] Role of the IANA expert reviewer 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, 03 Aug 2011 18:58:10 -0000 On 8/3/11 9:55 AM, Tero Kivinen wrote: > Yoav Nir writes: >> There is no such consensus that protocol variants are a good thing. >> I think it's just the opposite. Although I don't think it's Tero's >> job to stop the publication of three documents that are "for the >> same thing". That should be done by the community. > > I am most definately not trying to stop any of the documents. To make it clear. Tero came up with the framework. I told the authors to adopt to it. spt From ynir@checkpoint.com Sat Aug 6 13:37:39 2011 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 3A8FB21F84D6 for ; Sat, 6 Aug 2011 13:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 t5AJ41tpz2oW for ; Sat, 6 Aug 2011 13:37:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98B21F84CB for ; Sat, 6 Aug 2011 13:37:37 -0700 (PDT) X-CheckPoint: {4E3DB3A2-8-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p76KbwRu002210 for ; Sat, 6 Aug 2011 23:37:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 6 Aug 2011 23:37:58 +0300 From: Yoav Nir To: IPsecme WG Date: Sat, 6 Aug 2011 23:37:53 +0300 Thread-Topic: IKEv2 and ERP Thread-Index: AcxUeLl/LoVOUFPyTL+atktj9L76jQ== Message-ID: <6205B3A8-4806-4F7A-B0CB-B9E36A744A37@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] IKEv2 and 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: Sat, 06 Aug 2011 20:37:39 -0000 Hi At the meeting in Quebec, I gave a presentation at the hokey meeting about = http://tools.ietf.org/html/draft-nir-ipsecme-erx . The draft covers using the EAP extensions for re-authentication in IKEv2. T= he obvious (to me) use-case is a phone connected to a 802.1x network. As yo= u leave the building, the same phone automatically using IKEv2 over a 3G ne= twork without the user authenticating, by using the handed-over keys from 8= 02.1x. ERP (RFC 5296) works in two cases: 1. when the new AAA backend and the old AAA backend are the same, and 2. when they are different - you connect to a local EAP server There is an open question here. Obviously, when you use EAP for 802.1x or P= PP or some other network access, you often connect to a local Authenticator= that is not the same as your "home network". But is this relevant in IKEv2= ? IKEv2 is used over the Internet. Why would you ever want to connect to a= server other than your home (or a server that relies on the same AAA backe= nd) In other words: is there a use-case for connecting to a local rather than a= home server in IKE, a use-case that uses EAP. My feeling is that the answer is no, and there were some phone operators in= the room who agreed with me. Someone did bring up the case of host-to-host= IPsec, but I don't think that ever uses EAP. Does anybody have different thoughts about this? Thanks Yoav From prbatra@cisco.com Wed Aug 17 23:17:38 2011 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 0C5B021F8581 for ; Wed, 17 Aug 2011 23:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM9dFz11Xu1M for ; Wed, 17 Aug 2011 23:17:37 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0621F856C for ; Wed, 17 Aug 2011 23:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=429; q=dns/txt; s=iport; t=1313648310; x=1314857910; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to; bh=eUdn0g7fhatKjNmlTefhDshdpBFIzOWikStEdQ6Gx5c=; b=FJ0r0U2vuNJi+o8rIDQkyajPcFn6OkprD7PXeHr1HZAyZHhf6IjvypGy ba3pqW6Djpgr03Q/yRNZA6I8EcmgQycZtp7HS30LGa2KWBAXb/GK8CUYy YhAiV+uDJJ/uU55jQRLg9+BPAKnt1IQir9hlH795OWqDdMSE6/6of0yn1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoGALmtTE5Io8US/2dsb2JhbABAmV2PFXeBQQEBAQMSAR0KTwIBKgYYBgFWAQEECxAaoRABnnWFaV8Eh16QSoto X-IronPort-AV: E=Sophos;i="4.68,243,1312156800"; d="scan'208";a="51010731" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 18 Aug 2011 06:18:28 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7I6IRZx013982 for ; Thu, 18 Aug 2011 06:18:28 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 11:48:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-CR-Hashedpuzzle: AUEh Azvw BYlJ CGjF CieL DD0D DdkU EMxW E7Ju E8Pd Fvim F4e2 HNVv HVE3 Hft+ KbmD; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B095C219-BFC9-41AB-AC8C-4FC891CE0EA3}; cAByAGIAYQB0AHIAYQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 18 Aug 2011 06:18:18 GMT; SQBQAFMAZQBjACAAaQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuACAAcQB1AGUAcgB5AC4A X-CR-Puzzleid: {B095C219-BFC9-41AB-AC8C-4FC891CE0EA3} Content-class: urn:content-classes:message Date: Thu, 18 Aug 2011 11:48:18 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec implementation query. Thread-Index: AcxK0UywJgRnA9ThSiW+Is6Eot+WkgAcjspgBIq+AZA= References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 18 Aug 2011 06:18:21.0871 (UTC) FILETIME=[A12C1BF0:01CC5D6E] Subject: [IPsec] IPSec implementation query. 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, 18 Aug 2011 06:17:38 -0000 Hello, IPSec in linux kernel doesn't seem to work with packets sent from RAW socket. I think this is as per the design of RAW socket, that they bypass the transport layer. But as they enter the core IP layer, and there is a policy to protect, they should get protected. But this does not happen? Any clues? Also, if this is not possible, how can we use kernel IPSec to protect RAW socket data. Thanks, Prashant From kivinen@iki.fi Wed Aug 24 06:20:16 2011 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 2627621F8AF7 for ; Wed, 24 Aug 2011 06:20:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSRcH2k1XLgF for ; Wed, 24 Aug 2011 06:20:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id D348C21F8AF0 for ; Wed, 24 Aug 2011 06:20:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p7ODLOfA006163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 16:21:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p7ODLOE5004910; Wed, 24 Aug 2011 16:21:24 +0300 (EEST) 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: <20052.64212.314808.78488@fireball.kivinen.iki.fi> Date: Wed, 24 Aug 2011 16:21:24 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-secure-password-framework-02.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: Wed, 24 Aug 2011 13:20:16 -0000 From: internet-drafts@ietf.org Subject: New Version Notification for draft-kivinen-ipsecme-secure-password-framework-02.txt Date: Wed, 24 Aug 2011 06:18:38 -0700 A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-02.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-secure-password-framework Revision: 02 Title: Secure Password Framework for IKEv2 Creation date: 2011-08-24 WG ID: Individual Submission Number of pages: 14 Abstract: This document creates a generic way for Internet Key Exchange (IKEv2) to use any of the symmetric secure password authentication methods. There are multiple methods already specified in other documents and this document does not add new one. This document specifies a way to agree on which method is to be used in current connection. This document also provides a common way to transmit secure password authentication method specific payloads between peers. -- kivinen@iki.fi From nbn@cisco.com Thu Aug 25 03:46:57 2011 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 F2F6121F85F1 for ; Thu, 25 Aug 2011 03:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMzr+S1N2GvZ for ; Thu, 25 Aug 2011 03:46:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A523221F85EC for ; Thu, 25 Aug 2011 03:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=3528; q=dns/txt; s=iport; t=1314269289; x=1315478889; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+8MaB/uDLwbYtOXHJ8RE0CPt4GdnMziK0/B8Pf+g1mA=; b=aQbMoCeCc6RvX6BqTwvEiE6Zj7t4lcqHJqQ4AzHCK+8EKbQSomS3u5F6 NLIGcN3vjV5izt+mNnKAwDCvdZlYBcviIOCwObwe1JS5p23mLqV+lyQIp Ci63u7f0yWQMJrW44b89R8KnjL9aJ28VxJUdgbVXRMLbCHeK8c73jV3mu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAANQnVk5Io8US/2dsb2JhbABCmCmPWHeBQAEBAQEDAQEBDwEdPgsQAgEIEQQBAQsGFwEGASAGHwkIAQEEAQoICBqHVJw1AZ8HhWxgBIcyLZBQhGGHDA X-IronPort-AV: E=Sophos;i="4.68,280,1312156800"; d="scan'208";a="51968639" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 25 Aug 2011 10:48:06 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7PAm5tk025245; Thu, 25 Aug 2011 10:48:05 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 16:18:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Aug 2011 16:18:04 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance thread-index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaA= References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Naveen B N (nbn)" To: "Yaron Sheffer" , "Yoav Nir" X-OriginalArrivalTime: 25 Aug 2011 10:48:05.0548 (UTC) FILETIME=[78497EC0:01CC6314] Cc: ipsec@ietf.org, "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance 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, 25 Aug 2011 10:46:57 -0000 Hi , Can we not use the existing RSA keys to get the shared secret without = using the DH computation Because of the calculation that are involved. Let's say A wants to initiate a session with B. Let A get the Public key of B from CA by sending a protected message = using public key of CA. Use the obtained public key for sending the shared secret to B and same = from the other End has well, this will ensure authentication and avoiding DH = computation. I feel that certificate can be used for authentication and as well has = negotiated Symmetric key using the=20 Concept of Asymmetric cryptography which is one of the good features of = certificate. Why in Ikev2, certificates are just used for authentication and why they = are not used for=20 negotiating Symmetric key instead in place of DH computation. Is it to = avoid use of Trusted CA negotiation. Thanks and Regards Naveen From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Prashant Batra (prbatra) Sent: Tuesday, July 26, 2011 6:33 PM To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance Thanks Yoav and Yaron =A0for the suggestions. Even I was thinking and tried generating and storing the key pair = =A0well in the beginning,.=A0 This helped to some extent. The secret calculation is also very expensive, but this has to be done = in midst of the exchange only. Regards, Prashant=20 From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Tuesday, July 26, 2011 4:47 PM To: Yoav Nir Cc: Prashant Batra (prbatra); ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance You might want to review = http://tools.ietf.org/html/rfc5996#section-2.12. Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces = the computational costs of renewing an IKE SA when a client needs to = reconnect to a gateway a second time after some failure. Thanks, =A0=A0=A0 Yaron On 07/26/2011 01:40 PM, Yoav Nir wrote:=20 On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: Hello, The DH exchange (Calculation of Public/Private key and the Secret) in IKEV2 Initial exchange=20 seems to be very expensive. This is slowing down the overall IKEv2 tunnel establishment. Is there a way to optimize it? Hi Prashant. I know of three ways to optimize the D-H exchange. First, note that each peer has to perform two operations:=20 =A01. Generate: create a random x and calculate X=3D2^x mod p 2. Derive: calculate the shared secret S=3DY^x mod p The "Derive" operation has to be done during the exchange, but the = "Generate" operation can be done long before the exchange. If your = problem is degraded performance at some peak, you can pre-generate some = values. This has a high cost in memory, but can be useful for dealing = with peaks. Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 mod = p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p = for 0<=3Dx<=3D2048 and store these values. After that, both the generate = and derive operations become simple multiplications of the resulting = values. This has a fixed cost in memory, but can accelerate things. Third, you may want to look at the EC groups. The EC operations require = less computation. Hope this helps Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From sfluhrer@cisco.com Thu Aug 25 06:26:28 2011 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 4267A21F86AB for ; Thu, 25 Aug 2011 06:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbmucCN3H5ER for ; Thu, 25 Aug 2011 06:26:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 217C321F8634 for ; Thu, 25 Aug 2011 06:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=5712; q=dns/txt; s=iport; t=1314278861; x=1315488461; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6GcfVvenUZL5t0gDTy9ZkzmirDboXfJ6DLFG37iSWqw=; b=GFSHEEDGg2rDuV1HURUcppJz/Z8e8Vg/rzDzkcSFbicg/eZJZtQrl1Ef CbSTfgirLwiE6ImOSYR2tFXNSea7LXuvg0FRbuskaR7fb1gOCRKem0LHA EGIQlI8zeisQvZEb8X3GhTawtbA65S7rRkkcCg5diTfnbjDSB50rddMdJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAFlNVk6rRDoI/2dsb2JhbABCmCmPWHeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGHwkIAQEEARIIGodQBJwDAZ8MhWxgBIcyL5BOhGGHJA X-IronPort-AV: E=Sophos;i="4.68,280,1312156800"; d="scan'208";a="16414689" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 25 Aug 2011 13:27:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7PDRdo7001341; Thu, 25 Aug 2011 13:27:39 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 06:27:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: HxJ0 LMtH LZg7 PYPX UFnf Ubct WvWE XTkJ bMqu cetk dxiI fg3m gjcE h/kA iH+5 iOXG; 3; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAeQBhAHIAbwBuAGYALgBpAGUAdABmAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwB5AG4AaQByAEAAYwBoAGUAYwBrAHAAbwBpAG4AdAAuAGMAbwBtAA==; Sosha1_v1; 7; {71DD033A-40B9-4F98-88D5-287F3E300645}; cwBmAGwAdQBoAHIAZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 25 Aug 2011 13:27:28 GMT; UgBFADoAIABbAEkAUABzAGUAYwBdACAARABIACAAawBlAHkAcwAgAGMAYQBsAGMAdQBsAGEAdABpAG8AbgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQA= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {71DD033A-40B9-4F98-88D5-287F3E300645} Content-class: urn:content-classes:message Date: Thu, 25 Aug 2011 06:27:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwA== References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Scott Fluhrer (sfluhrer)" To: "Naveen B N (nbn)" , "Yaron Sheffer" , "Yoav Nir" X-OriginalArrivalTime: 25 Aug 2011 13:27:39.0803 (UTC) FILETIME=[C2FCDEB0:01CC632A] Cc: ipsec@ietf.org, "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance 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, 25 Aug 2011 13:26:28 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Naveen B N (nbn) > Sent: Thursday, August 25, 2011 6:48 AM > To: Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > Subject: Re: [IPsec] DH keys calculation performance >=20 > Hi , > Can we not use the existing RSA keys to get the shared secret without > using the DH computation > Because of the calculation that are involved. > Let's say A wants to initiate a session with B. > Let A get the Public key of B from CA by sending a protected message > using public key of CA. > Use the obtained public key for sending the shared secret to B and = same > from the other > End has well, this will ensure authentication and avoiding DH > computation. >=20 > I feel that certificate can be used for authentication and as well has > negotiated Symmetric key using the > Concept of Asymmetric cryptography which is one of the good features > of certificate. >=20 > Why in Ikev2, certificates are just used for authentication and why > they are not used for > negotiating Symmetric key instead in place of DH computation. Is it to > avoid use of Trusted CA negotiation. Well, you certainly can use certificates (with public key encryption = keys) to transport keying material; indeed, the ciphersuite of TLS that = is in general use does exactly that. However, it does have a few drawbacks. Here are some of the reasons = that the IKEv2 designers may have chosen not to use it: - Transporting keying material lacks forward secrecy. "Forward secrecy" = is the property that, if some actually recovers the entire state of one = (or both) of the sides, they still won't be able to decrypt a transcript = of a session that had happened earlier (because the state needed to = decrypt it was zeroized when the session was closed). With key = transport, it is impractical to zeroize the private key used during the = exchange, and with that, the attacker can decrypt the keying material, = and from there, rederive the session keys. In contrast, with DH, as = long as both sides zeroize the private exponents and shared secrets = (along with the session state), the attacker does not have enough = information. - IKEv2 allows other types of authentication beyond certificates; using = public key encryption as a step in generating keying material would = imply that we would need a different mechanism to generate keying = material for other types of authentication. This is certainly not = impossible (in fact, IKEv1 did have different mechanisms based on = authentication type, although for different reasons); the IKEv2 = designers decided to unify that. >=20 > Thanks and Regards > Naveen >=20 > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Prashant Batra (prbatra) > Sent: Tuesday, July 26, 2011 6:33 PM > To: Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] DH keys calculation performance >=20 > Thanks Yoav and Yaron =A0for the suggestions. > Even I was thinking and tried generating and storing the key pair = =A0well > in the beginning,.=A0 This helped to some extent. >=20 > The secret calculation is also very expensive, but this has to be done > in midst of the exchange only. >=20 > Regards, > Prashant >=20 >=20 > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Tuesday, July 26, 2011 4:47 PM > To: Yoav Nir > Cc: Prashant Batra (prbatra); ipsec@ietf.org > Subject: Re: [IPsec] DH keys calculation performance >=20 > You might want to review http://tools.ietf.org/html/rfc5996#section- > 2.12. >=20 > Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces > the computational costs of renewing an IKE SA when a client needs to > reconnect to a gateway a second time after some failure. >=20 > Thanks, > =A0=A0=A0 Yaron >=20 > On 07/26/2011 01:40 PM, Yoav Nir wrote: >=20 > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >=20 > Hello, >=20 > The DH exchange (Calculation of Public/Private key and the Secret) in > IKEV2 Initial exchange > seems to be very expensive. This is slowing down the overall IKEv2 > tunnel establishment. > Is there a way to optimize it? >=20 > Hi Prashant. >=20 > I know of three ways to optimize the D-H exchange. >=20 > First, note that each peer has to perform two operations: > =A01. Generate: create a random x and calculate X=3D2^x mod p > 2. Derive: calculate the shared secret S=3DY^x mod p > The "Derive" operation has to be done during the exchange, but the > "Generate" operation can be done long before the exchange. If your > problem is degraded performance at some peak, you can pre-generate = some > values. This has a high cost in memory, but can be useful for dealing > with peaks. >=20 > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 = mod > p)) mod p > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p > for 0<=3Dx<=3D2048 and store these values. After that, both the = generate > and derive operations become simple multiplications of the resulting > values. This has a fixed cost in memory, but can accelerate things. >=20 > Third, you may want to look at the EC groups. The EC operations = require > less computation. >=20 > Hope this helps >=20 > Yoav >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nbn@cisco.com Thu Aug 25 09:32:44 2011 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 57B6A21F87F9 for ; Thu, 25 Aug 2011 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qrwmeWUXikl for ; Thu, 25 Aug 2011 09:32:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2321F8593 for ; Thu, 25 Aug 2011 09:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=8553; q=dns/txt; s=iport; t=1314290037; x=1315499637; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JtqYrv7Q2Itx8DO/rWZlXlZ02xPp/WUL8xePjGuzf3U=; b=mxTHch3UUIXgbXVxgWJUWHaNc8jfE/RnV9FaqTBv3ezcMTHXM+3WWTEh /W1d8MRrxl2B12DUWVOfm5yb4rA0/dG+rok2Ut09npj64ceK3pyhxweTN o92Xog4gs7YwUgjA+W22qYUkApWnW9vYtiqYFyn67cY7u34YhGz94MTi8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AADV5Vk5Io8US/2dsb2JhbABCmCuPWHeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGHwkIAQEEAQoICBECB4dQBJt9AZ8RhWxgBIcyLZBQhGGHDA X-IronPort-AV: E=Sophos;i="4.68,281,1312156800"; d="scan'208";a="112470809" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 25 Aug 2011 16:33:52 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7PGXpkM012702; Thu, 25 Aug 2011 16:33:51 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 22:03:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Aug 2011 22:03:48 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance thread-index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBA References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Naveen B N (nbn)" To: "Scott Fluhrer (sfluhrer)" , "Yaron Sheffer" , "Yoav Nir" , X-OriginalArrivalTime: 25 Aug 2011 16:33:51.0090 (UTC) FILETIME=[C597FD20:01CC6344] Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net, "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance 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, 25 Aug 2011 16:32:44 -0000 Hi Scott, Please find the queries and comments inline .. Scott>- Transporting keying material lacks forward secrecy. "Forward = secrecy" is the property that, if some actually recovers the entire = state of one (or both) of the sides, they still won't be able to decrypt = a transcript of a session that had happened earlier (because the state = needed to decrypt it was zeroized when the session was closed). With = key transport, it is impractical to zeroize the private key used during = the exchange, and with that, the attacker can decrypt the keying = material, and from there, rederive the session keys. In contrast, with = DH, as long as both sides zeroize the private exponents and shared = secrets (along with the session state), the attacker does not have = enough information. Naveen>> TO maintain "Forward Secrecy", we have to change the keys from = time to time based on the key length, which can be achieved by = re-negotiating=20 new keys with the communicated Symmetric key. But if you say that the first session used is to derive the private = key of the peer, then Asymmetric key should never be used for deriving = symmetric keys Or to protect data. If Certificate are still used in TLS for = negotiation of Symmetric keys, this is a major issue because they are = used in important places. Naveen>>So, Certificates should only be used for authentication in a = protected environment is it. What could be the life time of the RSA keys then, how long will it = take to derive a private key from a public key with the best available = resources. Then it comes down to DH method being the best secured available = solution for negotiating Symmetric key on the fly, without having shared = keying material with the peer. Scott>- IKEv2 allows other types of authentication beyond certificates; = using public key encryption as a step in generating keying material = would imply that we would need a different mechanism to generate keying = material for other types of authentication. This is certainly not = impossible (in fact, IKEv1 did have different mechanisms based on = authentication type, although for different reasons); the IKEv2 = designers decided to unify that. Naveen>>May be Ikev2 designers feel that the intruder may selects a week = authentication type if exposed in plan message, But I think we are = authenticating the INIT_MESSAGE in IKE_AUTH Message, so they could have provided a authentication method in = IKE_INIT message. Thanks and Regards Naveen -----Original Message----- From: Scott Fluhrer (sfluhrer)=20 Sent: Thursday, August 25, 2011 6:57 PM To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org; Prashant Batra (prbatra) Subject: RE: [IPsec] DH keys calculation performance > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Naveen B N (nbn) > Sent: Thursday, August 25, 2011 6:48 AM > To: Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > Subject: Re: [IPsec] DH keys calculation performance >=20 > Hi , > Can we not use the existing RSA keys to get the shared secret without > using the DH computation > Because of the calculation that are involved. > Let's say A wants to initiate a session with B. > Let A get the Public key of B from CA by sending a protected message > using public key of CA. > Use the obtained public key for sending the shared secret to B and = same > from the other > End has well, this will ensure authentication and avoiding DH > computation. >=20 > I feel that certificate can be used for authentication and as well has > negotiated Symmetric key using the > Concept of Asymmetric cryptography which is one of the good features > of certificate. >=20 > Why in Ikev2, certificates are just used for authentication and why > they are not used for > negotiating Symmetric key instead in place of DH computation. Is it to > avoid use of Trusted CA negotiation. Well, you certainly can use certificates (with public key encryption = keys) to transport keying material; indeed, the ciphersuite of TLS that = is in general use does exactly that. However, it does have a few drawbacks. Here are some of the reasons = that the IKEv2 designers may have chosen not to use it: - Transporting keying material lacks forward secrecy. "Forward secrecy" = is the property that, if some actually recovers the entire state of one = (or both) of the sides, they still won't be able to decrypt a transcript = of a session that had happened earlier (because the state needed to = decrypt it was zeroized when the session was closed). With key = transport, it is impractical to zeroize the private key used during the = exchange, and with that, the attacker can decrypt the keying material, = and from there, rederive the session keys. In contrast, with DH, as = long as both sides zeroize the private exponents and shared secrets = (along with the session state), the attacker does not have enough = information. - IKEv2 allows other types of authentication beyond certificates; using = public key encryption as a step in generating keying material would = imply that we would need a different mechanism to generate keying = material for other types of authentication. This is certainly not = impossible (in fact, IKEv1 did have different mechanisms based on = authentication type, although for different reasons); the IKEv2 = designers decided to unify that. >=20 > Thanks and Regards > Naveen >=20 > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Prashant Batra (prbatra) > Sent: Tuesday, July 26, 2011 6:33 PM > To: Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] DH keys calculation performance >=20 > Thanks Yoav and Yaron =A0for the suggestions. > Even I was thinking and tried generating and storing the key pair = =A0well > in the beginning,.=A0 This helped to some extent. >=20 > The secret calculation is also very expensive, but this has to be done > in midst of the exchange only. >=20 > Regards, > Prashant >=20 >=20 > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Tuesday, July 26, 2011 4:47 PM > To: Yoav Nir > Cc: Prashant Batra (prbatra); ipsec@ietf.org > Subject: Re: [IPsec] DH keys calculation performance >=20 > You might want to review http://tools.ietf.org/html/rfc5996#section- > 2.12. >=20 > Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces > the computational costs of renewing an IKE SA when a client needs to > reconnect to a gateway a second time after some failure. >=20 > Thanks, > =A0=A0=A0 Yaron >=20 > On 07/26/2011 01:40 PM, Yoav Nir wrote: >=20 > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >=20 > Hello, >=20 > The DH exchange (Calculation of Public/Private key and the Secret) in > IKEV2 Initial exchange > seems to be very expensive. This is slowing down the overall IKEv2 > tunnel establishment. > Is there a way to optimize it? >=20 > Hi Prashant. >=20 > I know of three ways to optimize the D-H exchange. >=20 > First, note that each peer has to perform two operations: > =A01. Generate: create a random x and calculate X=3D2^x mod p > 2. Derive: calculate the shared secret S=3DY^x mod p > The "Derive" operation has to be done during the exchange, but the > "Generate" operation can be done long before the exchange. If your > problem is degraded performance at some peak, you can pre-generate = some > values. This has a high cost in memory, but can be useful for dealing > with peaks. >=20 > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 = mod > p)) mod p > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p > for 0<=3Dx<=3D2048 and store these values. After that, both the = generate > and derive operations become simple multiplications of the resulting > values. This has a fixed cost in memory, but can accelerate things. >=20 > Third, you may want to look at the EC groups. The EC operations = require > less computation. >=20 > Hope this helps >=20 > Yoav >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From sfluhrer@cisco.com Thu Aug 25 09:46:46 2011 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 85E7B21F86C0 for ; Thu, 25 Aug 2011 09:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3au3OXC9UHm for ; Thu, 25 Aug 2011 09:46:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA7421F8620 for ; Thu, 25 Aug 2011 09:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=10213; q=dns/txt; s=iport; t=1314290879; x=1315500479; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uWOpF+gkvOA/KeN1qWtJA3FP0ZpURNm/0ayfOn64TU8=; b=HNtSebVSKtcbV/uAmzgykEHFXH0DNtUrF2Pt2NkKhTgGR6iSzfCwuevt 9QrBT6VnemsJhvuBCI/PchbE27qJlAj8UgrXRVAKtDOUZwHaeeFts351v lJVTN/IxFwfpnQWTPt509QQ/zEjxQUSbzIzpr+rudYRpLAioB4TMvaz9A Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AAEV8Vk6rRDoH/2dsb2JhbABCmCuPWHeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGAR4JCAEBBAESCBECB4dQBJtyAZ8NhWxgBIcyL4kohyaEYYck X-IronPort-AV: E=Sophos;i="4.68,281,1312156800"; d="scan'208";a="16491803" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 25 Aug 2011 16:47:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7PGlwuv017458; Thu, 25 Aug 2011 16:47:58 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 09:47:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ACU7 D+YG EIeJ dWnd dmm2 evds gxbp mxO3 qoZk ywzz 1bsG 107Y 2oHV 8NKA AA1ZVw== AC5tVw==; 7; aQBrAGUAdgAyAC0AZABlAHYAZQBsAEAAbABpAHMAdABzAC4AcwBvAHUAcgBjAGUAZgBvAHIAZwBlAC4AbgBlAHQAOwBpAHAAcwBlAGMALQB0AG8AbwBsAHMALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgBzAG8AdQByAGMAZQBmAG8AcgBnAGUALgBuAGUAdAA7AGkAcABzAGUAYwAtAHQAbwBvAGwAcwAtAHUAcwBlAHIAcwBAAGwAaQBzAHQAcwAuAHMAbwB1AHIAYwBlAGYAbwByAGcAZQAuAG4AZQB0ADsAaQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAdABpAG0AbwAuAHQAZQByAGEAcwBAAGkAawBpAC4AZgBpADsAeQBhAHIAbwBuAGYALgBpAGUAdABmAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwB5AG4AaQByAEAAYwBoAGUAYwBrAHAAbwBpAG4AdAAuAGMAbwBtAA==; Sosha1_v1; 7; {E4207743-EC6A-4E19-99C5-BF8573DE59D3}; cwBmAGwAdQBoAHIAZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 25 Aug 2011 16:47:42 GMT; UgBFADoAIABbAEkAUABzAGUAYwBdACAARABIACAAawBlAHkAcwAgAGMAYQBsAGMAdQBsAGEAdABpAG8AbgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQA= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {E4207743-EC6A-4E19-99C5-BF8573DE59D3} Content-class: urn:content-classes:message Date: Thu, 25 Aug 2011 09:47:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBAAADbL1A= References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Scott Fluhrer (sfluhrer)" To: "Naveen B N (nbn)" , "Yaron Sheffer" , "Yoav Nir" , X-OriginalArrivalTime: 25 Aug 2011 16:47:57.0824 (UTC) FILETIME=[BE495800:01CC6346] Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net, "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance 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, 25 Aug 2011 16:46:46 -0000 > -----Original Message----- > From: Naveen B N (nbn) > Sent: Thursday, August 25, 2011 12:34 PM > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; > timo.teras@iki.fi > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; ipsec- > tools-devel@lists.sourceforge.net > Subject: RE: [IPsec] DH keys calculation performance >=20 > Hi Scott, >=20 > Please find the queries and comments inline .. >=20 > Scott>- Transporting keying material lacks forward secrecy. "Forward > secrecy" is the property that, if some actually recovers the entire > state of one (or both) of the sides, they still won't be able to > decrypt a transcript of a session that had happened earlier (because > the state needed to decrypt it was zeroized when the session was > closed). With key transport, it is impractical to zeroize the private > key used during the exchange, and with that, the attacker can decrypt > the keying material, and from there, rederive the session keys. In > contrast, with DH, as long as both sides zeroize the private exponents > and shared secrets (along with the session state), the attacker does > not have enough information. >=20 > Naveen>> TO maintain "Forward Secrecy", we have to change the keys = from > time to time based on the key length, which can be achieved by re- > negotiating > new keys with the communicated Symmetric key. > But if you say that the first session used is to derive the > private key of the peer, then Asymmetric key should never be used for > deriving symmetric keys > Or to protect data. If Certificate are still used in TLS for > negotiation of Symmetric keys, this is a major issue because they are > used in important places. I believe you misunderstand; we're not using the asymmetric key to = "derive" the symmetric keys, but instead just to transport it. Here's the scenario: - Side A picks some keying material ("premaster secret" is TLS's = terminology for it) - Side A encrypts it with Side B's public key, and sends it to B - Side B decrypts it with his own private key - Both side A and side B use that keying material (and possibly other = information that has been exchanged) to derive the real session keys The problem I was discussing: what if, after the session has been shut = down, the attacker recovers side B's private key? This private key is = unlikely to be zeroized along with the session (at least, with the = current CA infrastructure); using this private key, the attacker could = decrypt the encrypted keying material (just like B did), and rederive = the session keys (again, just like B did). >=20 > Naveen>>So, Certificates should only be used for authentication in a > protected environment is it. > What could be the life time of the RSA keys then, how long will > it take to derive a private key from a public key with the best > available resources. > Then it comes down to DH method being the best secured > available solution for negotiating Symmetric key on the fly, without > having shared keying material with the peer. >=20 > Scott>- IKEv2 allows other types of authentication beyond = certificates; > using public key encryption as a step in generating keying material > would imply that we would need a different mechanism to generate = keying > material for other types of authentication. This is certainly not > impossible (in fact, IKEv1 did have different mechanisms based on > authentication type, although for different reasons); the IKEv2 > designers decided to unify that. >=20 > Naveen>>May be Ikev2 designers feel that the intruder may selects a > week authentication type if exposed in plan message, But I think we = are > authenticating the INIT_MESSAGE in IKE_AUTH > Message, so they could have provided a authentication method = in > IKE_INIT message. >=20 >=20 > Thanks and Regards > Naveen >=20 > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Thursday, August 25, 2011 6:57 PM > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > Subject: RE: [IPsec] DH keys calculation performance >=20 >=20 >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Naveen B N (nbn) > > Sent: Thursday, August 25, 2011 6:48 AM > > To: Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > Subject: Re: [IPsec] DH keys calculation performance > > > > Hi , > > Can we not use the existing RSA keys to get the shared secret = without > > using the DH computation > > Because of the calculation that are involved. > > Let's say A wants to initiate a session with B. > > Let A get the Public key of B from CA by sending a protected message > > using public key of CA. > > Use the obtained public key for sending the shared secret to B and > same > > from the other > > End has well, this will ensure authentication and avoiding DH > > computation. > > > > I feel that certificate can be used for authentication and as well > has > > negotiated Symmetric key using the > > Concept of Asymmetric cryptography which is one of the good = features > > of certificate. > > > > Why in Ikev2, certificates are just used for authentication and why > > they are not used for > > negotiating Symmetric key instead in place of DH computation. Is it > to > > avoid use of Trusted CA negotiation. >=20 > Well, you certainly can use certificates (with public key encryption > keys) to transport keying material; indeed, the ciphersuite of TLS = that > is in general use does exactly that. >=20 > However, it does have a few drawbacks. Here are some of the reasons > that the IKEv2 designers may have chosen not to use it: >=20 > - Transporting keying material lacks forward secrecy. "Forward > secrecy" is the property that, if some actually recovers the entire > state of one (or both) of the sides, they still won't be able to > decrypt a transcript of a session that had happened earlier (because > the state needed to decrypt it was zeroized when the session was > closed). With key transport, it is impractical to zeroize the private > key used during the exchange, and with that, the attacker can decrypt > the keying material, and from there, rederive the session keys. In > contrast, with DH, as long as both sides zeroize the private exponents > and shared secrets (along with the session state), the attacker does > not have enough information. >=20 > - IKEv2 allows other types of authentication beyond certificates; = using > public key encryption as a step in generating keying material would > imply that we would need a different mechanism to generate keying > material for other types of authentication. This is certainly not > impossible (in fact, IKEv1 did have different mechanisms based on > authentication type, although for different reasons); the IKEv2 > designers decided to unify that. >=20 > > > > Thanks and Regards > > Naveen > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Prashant Batra (prbatra) > > Sent: Tuesday, July 26, 2011 6:33 PM > > To: Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] DH keys calculation performance > > > > Thanks Yoav and Yaron =A0for the suggestions. > > Even I was thinking and tried generating and storing the key pair > =A0well > > in the beginning,.=A0 This helped to some extent. > > > > The secret calculation is also very expensive, but this has to be > done > > in midst of the exchange only. > > > > Regards, > > Prashant > > > > > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > Sent: Tuesday, July 26, 2011 4:47 PM > > To: Yoav Nir > > Cc: Prashant Batra (prbatra); ipsec@ietf.org > > Subject: Re: [IPsec] DH keys calculation performance > > > > You might want to review http://tools.ietf.org/html/rfc5996#section- > > 2.12. > > > > Also, session resumption (http://tools.ietf.org/html/rfc5723) = reduces > > the computational costs of renewing an IKE SA when a client needs to > > reconnect to a gateway a second time after some failure. > > > > Thanks, > > =A0=A0=A0 Yaron > > > > On 07/26/2011 01:40 PM, Yoav Nir wrote: > > > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > > > > Hello, > > > > The DH exchange (Calculation of Public/Private key and the Secret) = in > > IKEV2 Initial exchange > > seems to be very expensive. This is slowing down the overall IKEv2 > > tunnel establishment. > > Is there a way to optimize it? > > > > Hi Prashant. > > > > I know of three ways to optimize the D-H exchange. > > > > First, note that each peer has to perform two operations: > > =A01. Generate: create a random x and calculate X=3D2^x mod p > > 2. Derive: calculate the shared secret S=3DY^x mod p > > The "Derive" operation has to be done during the exchange, but the > > "Generate" operation can be done long before the exchange. If your > > problem is degraded performance at some peak, you can pre-generate > some > > values. This has a high cost in memory, but can be useful for = dealing > > with peaks. > > > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 = mod > > p)) mod p > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod = p > > for 0<=3Dx<=3D2048 and store these values. After that, both the = generate > > and derive operations become simple multiplications of the resulting > > values. This has a fixed cost in memory, but can accelerate things. > > > > Third, you may want to look at the EC groups. The EC operations > require > > less computation. > > > > Hope this helps > > > > Yoav > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nbn@cisco.com Thu Aug 25 22:35:55 2011 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 7F0F721F85E3 for ; Thu, 25 Aug 2011 22:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKHM5ZfMBMlW for ; Thu, 25 Aug 2011 22:35:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6C28F21F84CB for ; Thu, 25 Aug 2011 22:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=11066; q=dns/txt; s=iport; t=1314337030; x=1315546630; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to:cc; bh=suqD+JnWfDWS8BfaA+73EICAgThIAy41gqlcJHoOlh0=; b=axPKdAIyo6AJKsNpQGnAx9yn9at77O/ZhTNEpZx9nMBOzxV24P8koYXB bTslBZcXEttoIMbKqmU4X1PlkdI8zJi2otk5X3Xu8qIAmG2eUPCnP3sbO tNQZtdgNp47PT4QsZpCKbZUs22w4oiCX2+jbwYTDbjXwKLDaXNm4rw4Bz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAAOIvV05Io8UT/2dsb2JhbABEmDmPWXeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGAR4JCAIEAQoICBECB4dQBJsfAZ8NhWxgBIczLYkqhyaEYYcO X-IronPort-AV: E=Sophos;i="4.68,283,1312156800"; d="scan'208";a="112534687" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2011 05:37:03 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7Q5b2fG005455; Fri, 26 Aug 2011 05:37:02 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 11:07:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 11:07:01 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance thread-index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBAAADbL1AAFla60AAE7taw References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Naveen B N (nbn)" To: "Naveen B N (nbn)" , "Scott Fluhrer (sfluhrer)" , "Yaron Sheffer" , "Yoav Nir" X-OriginalArrivalTime: 26 Aug 2011 05:37:02.0846 (UTC) FILETIME=[2EDCE9E0:01CC63B2] Cc: ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance 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, 26 Aug 2011 05:35:55 -0000 Hi Scott, if we can take care of the "Forward Secrecy", When using Asymetric keys from certificates=20 To negotiate symmetric keys, then certificate=20 Can be used in place of DH Computation. "TO maintain "Forward Secrecy", we have to change the keys from time to time based on the key length, which can be achieved by re- negotiating" If this is possible then I can present a draft for the same. Thanks & Regards Naveen -----Original Message----- From: Scott Fluhrer (sfluhrer)=20 Sent: Thursday, August 25, 2011 10:18 PM To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); = 'ipsec-tools-users@lists.sourceforge.net'; = 'ikev2-devel@lists.sourceforge.net'; = 'ipsec-tools-devel@lists.sourceforge.net' Subject: RE: [IPsec] DH keys calculation performance > -----Original Message----- > From: Naveen B N (nbn) > Sent: Thursday, August 25, 2011 12:34 PM > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; > timo.teras@iki.fi > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; ipsec- > tools-devel@lists.sourceforge.net > Subject: RE: [IPsec] DH keys calculation performance >=20 > Hi Scott, >=20 > Please find the queries and comments inline .. >=20 > Scott>- Transporting keying material lacks forward secrecy. "Forward > secrecy" is the property that, if some actually recovers the entire > state of one (or both) of the sides, they still won't be able to > decrypt a transcript of a session that had happened earlier (because > the state needed to decrypt it was zeroized when the session was > closed). With key transport, it is impractical to zeroize the private > key used during the exchange, and with that, the attacker can decrypt > the keying material, and from there, rederive the session keys. In > contrast, with DH, as long as both sides zeroize the private exponents > and shared secrets (along with the session state), the attacker does > not have enough information. >=20 > Naveen>> TO maintain "Forward Secrecy", we have to change the keys = from > time to time based on the key length, which can be achieved by re- > negotiating > new keys with the communicated Symmetric key. > But if you say that the first session used is to derive the > private key of the peer, then Asymmetric key should never be used for > deriving symmetric keys > Or to protect data. If Certificate are still used in TLS for > negotiation of Symmetric keys, this is a major issue because they are > used in important places. I believe you misunderstand; we're not using the asymmetric key to = "derive" the symmetric keys, but instead just to transport it. Here's the scenario: - Side A picks some keying material ("premaster secret" is TLS's = terminology for it) - Side A encrypts it with Side B's public key, and sends it to B - Side B decrypts it with his own private key - Both side A and side B use that keying material (and possibly other = information that has been exchanged) to derive the real session keys The problem I was discussing: what if, after the session has been shut = down, the attacker recovers side B's private key? This private key is = unlikely to be zeroized along with the session (at least, with the = current CA infrastructure); using this private key, the attacker could = decrypt the encrypted keying material (just like B did), and rederive = the session keys (again, just like B did). >=20 > Naveen>>So, Certificates should only be used for authentication in a > protected environment is it. > What could be the life time of the RSA keys then, how long will > it take to derive a private key from a public key with the best > available resources. > Then it comes down to DH method being the best secured > available solution for negotiating Symmetric key on the fly, without > having shared keying material with the peer. >=20 > Scott>- IKEv2 allows other types of authentication beyond = certificates; > using public key encryption as a step in generating keying material > would imply that we would need a different mechanism to generate = keying > material for other types of authentication. This is certainly not > impossible (in fact, IKEv1 did have different mechanisms based on > authentication type, although for different reasons); the IKEv2 > designers decided to unify that. >=20 > Naveen>>May be Ikev2 designers feel that the intruder may selects a > week authentication type if exposed in plan message, But I think we = are > authenticating the INIT_MESSAGE in IKE_AUTH > Message, so they could have provided a authentication method = in > IKE_INIT message. >=20 >=20 > Thanks and Regards > Naveen >=20 > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Thursday, August 25, 2011 6:57 PM > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > Subject: RE: [IPsec] DH keys calculation performance >=20 >=20 >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Naveen B N (nbn) > > Sent: Thursday, August 25, 2011 6:48 AM > > To: Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > Subject: Re: [IPsec] DH keys calculation performance > > > > Hi , > > Can we not use the existing RSA keys to get the shared secret = without > > using the DH computation > > Because of the calculation that are involved. > > Let's say A wants to initiate a session with B. > > Let A get the Public key of B from CA by sending a protected message > > using public key of CA. > > Use the obtained public key for sending the shared secret to B and > same > > from the other > > End has well, this will ensure authentication and avoiding DH > > computation. > > > > I feel that certificate can be used for authentication and as well > has > > negotiated Symmetric key using the > > Concept of Asymmetric cryptography which is one of the good = features > > of certificate. > > > > Why in Ikev2, certificates are just used for authentication and why > > they are not used for > > negotiating Symmetric key instead in place of DH computation. Is it > to > > avoid use of Trusted CA negotiation. >=20 > Well, you certainly can use certificates (with public key encryption > keys) to transport keying material; indeed, the ciphersuite of TLS = that > is in general use does exactly that. >=20 > However, it does have a few drawbacks. Here are some of the reasons > that the IKEv2 designers may have chosen not to use it: >=20 > - Transporting keying material lacks forward secrecy. "Forward > secrecy" is the property that, if some actually recovers the entire > state of one (or both) of the sides, they still won't be able to > decrypt a transcript of a session that had happened earlier (because > the state needed to decrypt it was zeroized when the session was > closed). With key transport, it is impractical to zeroize the private > key used during the exchange, and with that, the attacker can decrypt > the keying material, and from there, rederive the session keys. In > contrast, with DH, as long as both sides zeroize the private exponents > and shared secrets (along with the session state), the attacker does > not have enough information. >=20 > - IKEv2 allows other types of authentication beyond certificates; = using > public key encryption as a step in generating keying material would > imply that we would need a different mechanism to generate keying > material for other types of authentication. This is certainly not > impossible (in fact, IKEv1 did have different mechanisms based on > authentication type, although for different reasons); the IKEv2 > designers decided to unify that. >=20 > > > > Thanks and Regards > > Naveen > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Prashant Batra (prbatra) > > Sent: Tuesday, July 26, 2011 6:33 PM > > To: Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] DH keys calculation performance > > > > Thanks Yoav and Yaron =A0for the suggestions. > > Even I was thinking and tried generating and storing the key pair > =A0well > > in the beginning,.=A0 This helped to some extent. > > > > The secret calculation is also very expensive, but this has to be > done > > in midst of the exchange only. > > > > Regards, > > Prashant > > > > > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > Sent: Tuesday, July 26, 2011 4:47 PM > > To: Yoav Nir > > Cc: Prashant Batra (prbatra); ipsec@ietf.org > > Subject: Re: [IPsec] DH keys calculation performance > > > > You might want to review http://tools.ietf.org/html/rfc5996#section- > > 2.12. > > > > Also, session resumption (http://tools.ietf.org/html/rfc5723) = reduces > > the computational costs of renewing an IKE SA when a client needs to > > reconnect to a gateway a second time after some failure. > > > > Thanks, > > =A0=A0=A0 Yaron > > > > On 07/26/2011 01:40 PM, Yoav Nir wrote: > > > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > > > > Hello, > > > > The DH exchange (Calculation of Public/Private key and the Secret) = in > > IKEV2 Initial exchange > > seems to be very expensive. This is slowing down the overall IKEv2 > > tunnel establishment. > > Is there a way to optimize it? > > > > Hi Prashant. > > > > I know of three ways to optimize the D-H exchange. > > > > First, note that each peer has to perform two operations: > > =A01. Generate: create a random x and calculate X=3D2^x mod p > > 2. Derive: calculate the shared secret S=3DY^x mod p > > The "Derive" operation has to be done during the exchange, but the > > "Generate" operation can be done long before the exchange. If your > > problem is degraded performance at some peak, you can pre-generate > some > > values. This has a high cost in memory, but can be useful for = dealing > > with peaks. > > > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 = mod > > p)) mod p > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod = p > > for 0<=3Dx<=3D2048 and store these values. After that, both the = generate > > and derive operations become simple multiplications of the resulting > > values. This has a fixed cost in memory, but can accelerate things. > > > > Third, you may want to look at the EC groups. The EC operations > require > > less computation. > > > > Hope this helps > > > > Yoav > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From ramaswamy.bm@globaledgesoft.com Thu Aug 25 23:24:21 2011 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 3AC7E21F8AFF for ; Thu, 25 Aug 2011 23:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia-SynDm-8cP for ; Thu, 25 Aug 2011 23:24:17 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [119.82.106.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74F21F8A95 for ; Thu, 25 Aug 2011 23:24:15 -0700 (PDT) Received: from RamaswamySM (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id D112D58811D; Fri, 26 Aug 2011 11:57:27 +0530 (IST) From: "ramaswamy" To: , , , References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> In-Reply-To: Date: Fri, 26 Aug 2011 11:54:56 +0530 Message-ID: <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_008A_01CC63E6.FF820240" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBAAByvF5A= Content-Language: en-us Subject: [IPsec] New method to resist replay attack in ikev2 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, 26 Aug 2011 06:24:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01CC63E6.FF820240 Content-Type: multipart/alternative; boundary="----=_NextPart_001_008B_01CC63E6.FF820240" ------=_NextPart_001_008B_01CC63E6.FF820240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the first Child SA. In exceptional cases, there may be more than one of each of these exchanges. In case a DoS attack is expected on IKEv2, the responder may fight back using certain defense methods. In DoS attack where the target is flooded with session initiation (IKE_SA_INIT) requests from a spoofed IP address the responder may use cookie negotiation to defend oneself. This means that the responder does not do anything until it is verified that the initiator can receive packets at the address from which it claims to be sending them. This procedure is called IKEv2 negotiation with cookies and is illustrated in below figure. IK2.JPG In cookie negotiation messages (1) and (4) constitute IKE_SA_INIT exchange and messages (2) and (3) constitute cookie exchange that is used to verify the initiator. Finally, an IKE_AUTH exchange consists of messages (5) and (6).IKEv2 DoS protection is optional and it allows the responder to respond to message 1 with a cookie, which the initiator equally has to include in message 3. IKEv2 cookie negotiation tries to avoid redundant processing until the existence of the initiator can be determined. In peer to peer network environment, any one peer can act as either initiator or responder. In this situation, resistance against DoS attack and identity protection of both the initiator and the responder is crucial as anyone can be a victim of attacks. In client server environment resistance of client against DoS attack and protection of identity of the server is not a priority. But protecting the identity of client and resistance against DoS attack of server is more vital. On the other hand, in wireless network environment, where the bandwidth of channel is less and packet loss is more, DoS attack is major issue because probability of packet loss is more when the channel is flooded. Having several advantages, ikev2 still suffers from some deficiency, such as DoS attack, replay attack, man-in-the middle attack, when using in different network environments and connections. One problem is regarding the way it protects the peers form DoS attack. It has cookies mechanism to protect against DoS attack. In this case resistance can be obtained by increasing the number of message in the initial exchange . What is paid to get the level of protection is increasing two messages to initial exchange. This forces the new delay to system especially in wireless environment with high probability of packet loss. Therefore using this method attacker can gain the success by introducing delay to valid initiator. Therefore in this case there is no use of cookies negotiation because host would be still under Dos attack. Cookies negotiation to be protecting the Dos attack also falls short in case the attack is carried out by multiple sources and each peer reply correctly to cookie negotiation. It is important to protect the initiator's identity in both client-server and peer to peer environment. In original ikev2, only the identity of responder is protected by both active and passive attacker. It fails to protect the initiator identity from the active attacker. One of deficiency of ikev2, which we found in both client server and peer to peer environment, is when the responder is invalid entity, the initiator knows about the responder only when responder is authenticating to initiator. In this case the initiator is victim of replay attack and all the computation carried out by initiator would go in vain. This is also called as CPU based dos attack and memory based dos attack. Proposed new negotiations ik3.JPG Before initial exchange begins initiator looks up to the pre shared secret with the intended responder and does the hash value on first half of pre shared secret, nonce of the initiator. Once the responder receives the request it looks up the correspondence pre shared key in its table and it takes the nonce form initiator request message then it does a hash value to authenticate the initiator. After authentication of initiator the responder calculate the hash value of its own by using first half of the preshared key, initiator nonce and responder nonce and send the response to initiator so that ikev2 can avoid the replay attack, because only the intended user, who has pre shared key, can only generate hash value. After the IKE_SA_INIT exchange that is initial authentication is successful, both the parties calculates the quantity called SKEYSEED from nonce, second half part of the pre shared key and the Diffie-Hellman shared secret established. SKEYSEED also used to calculate the seven other keys to protect the further messages. SKEYSEED = PRF (Ni | Nr | second half of PSK, gIR). In case a DoS attack is expected on IKEv2, the responder may fight back using our advanced cookie negotiation method which ensure responder does no to do anything until it is verified that the initiator can receive the packets at the address from which it is claims to be sending them. Upon receiving cookies request message the initiator calculates hash value on received cookie, first half of the preshared key and nonce of the initiator to authenticate to responder. Generating the hash value of preshared key with responder cookie ensure that only intended initiator can replay for the cookie request. If the cookie negotiation fails, protocol will halt. Kindly share the views on the same, Best Regards , Ram ------=_NextPart_001_008B_01CC63E6.FF820240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

In the common case, there is a single = IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to = establish the IKE SA and the first Child SA. In exceptional cases, there may be = more than one of each of these exchanges.

 

         &nb= sp;      In case a DoS attack is expected on IKEv2, the responder may fight back = using certain defense methods. In DoS attack where the target is flooded with session initiation (IKE_SA_INIT) requests from a spoofed IP address the = responder may use cookie negotiation to defend oneself. This means that the responder = does not do anything until it is verified that the initiator can receive = packets at the address from which it claims to be sending them. This procedure is = called IKEv2 negotiation with cookies and is illustrated in below = figure.

     

3DIK2.JPG

In cookie negotiation messages (1) and (4) constitute IKE_SA_INIT exchange and messages (2) and (3) constitute = cookie exchange that is used to verify the initiator. Finally, an IKE_AUTH = exchange consists of messages (5) and (6).IKEv2 DoS protection is optional and it = allows the responder to respond to message 1 with a cookie, which the initiator equally has to include in message 3. IKEv2 cookie negotiation tries to = avoid redundant processing until the existence of the initiator can be = determined.

 

In peer to peer network environment, any one peer can act as either = initiator or responder. In this situation, resistance against DoS attack and identity protection of both the initiator and the responder is crucial as anyone = can be a victim of attacks.

 

In client server environment resistance of client against DoS attack and protection of identity of the server is not a priority. But protecting = the identity of client and resistance against DoS attack of server is more = vital. On the other hand, in wireless network environment, where the bandwidth of = channel is less and packet loss is more, DoS attack is major issue because = probability of packet loss is more when the channel is flooded. =

Having several advantages, ikev2 still suffers from some deficiency, such as = DoS attack, replay attack, man-in-the middle attack, when using in different network environments and connections. One problem is regarding the way = it protects the peers form DoS attack. It has cookies mechanism to protect = against DoS attack. In this case resistance can be obtained by increasing the = number of message in the initial exchange . What is paid to get the level of = protection is increasing two messages to initial exchange. This forces the new = delay to system especially in wireless environment with high probability of packet loss. Therefore using this method attacker can gain the success by introducing = delay to valid initiator. Therefore in this case there is no use of cookies negotiation because host would be still under Dos attack. Cookies = negotiation to be protecting the Dos attack also falls short in case the attack is = carried out by multiple sources and each peer reply correctly to cookie = negotiation.

 

It is important to protect the initiator’s identity in both = client-server and peer to peer environment.  In original ikev2, only the identity of responder is protected by both active and passive attacker. It fails to = protect the initiator identity from the active attacker. One of deficiency of = ikev2, which we found in both client server and peer to peer environment, is = when the responder is invalid entity, the initiator knows about the responder = only when responder is authenticating to initiator.  In this case the = initiator is victim of replay attack and all the computation carried out by initiator = would go in vain.  This is also called as CPU based dos attack and memory = based dos attack.

 

Proposed new negotiations

3Dik3.JPG

 

Before initial exchange begins initiator looks up to the pre shared secret with = the intended responder and does the hash value on first half of pre shared = secret, nonce of the initiator. Once the responder receives the request it looks = up the correspondence pre shared key in its table and it takes the nonce form initiator request message then it does a hash value to authenticate the initiator. After authentication of initiator the responder calculate the = hash value of its own by using first half of the preshared key, initiator = nonce and responder nonce and send the response to initiator = so that ikev2 can avoid the replay attack, because only the intended user, = who has pre shared key, can only generate hash value. After the IKE_SA_INIT = exchange that is initial  authentication is successful, both the parties = calculates the quantity called SKEYSEED from nonce, second half part  of the = pre shared key and the Diffie-Hellman shared secret established. SKEYSEED = also used to calculate the seven other keys to protect the further = messages.

SKEYSEED =3D PRF (Ni | Nr | second half of PSK, = gIR).

 

In case a DoS attack is expected on IKEv2, the responder may fight back = using our advanced cookie negotiation method  which ensure responder  = does no to do anything until it is verified that the initiator can receive the = packets at the address from which it is claims to be sending them. Upon = receiving cookies request message the initiator calculates hash value on received = cookie, first half of the preshared key and nonce of the initiator to = authenticate to responder. Generating the hash value of preshared key with responder = cookie ensure that only intended initiator can replay for the cookie request. = If the cookie negotiation fails, protocol will halt.

 

 

Kindly share the views on the same,

 

Best Regards ,

Ram

 

------=_NextPart_001_008B_01CC63E6.FF820240-- ------=_NextPart_000_008A_01CC63E6.FF820240 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAD6ASABAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APTdQ1e8g1VNOsdNF5KY PPctcCIKu7b3BzzTf7S8Qf8AQvwf+DAf/EUf2l4h/wCheh/8GA/+Io/tLxD/ANC9D/4MB/8AEUf2 l4h/6F6H/wAGA/8AiKP7S8Q/9C9D/wCDAf8AxFH9o+If+heh/wDBgP8A4ij+0fEP/QvQ/wDgwH/x FH9o+If+heh/8GA/+IpkmuarazWwv9ESCGedIPMS8DlSxwONozzW6KWiiiiiiiiiikrHvtXvYdW/ s6w0wXkiwLO7NcCIAFmUDkHP3TTf7R8Q/wDQvQ/+DAf/ABFH9peIf+heh/8ABgP/AIij+0fEP/Qv Q/8AgwH/AMRR/aPiH/oXof8AwYD/AOIo/tHxD/0L0P8A4MB/8RR/aXiH/oXof/BgP/iKP7S8Q/8A QvQ/+DAf/EUf2j4h/wCheh/8GA/+Io/tHxD/ANC9D/4MB/8AEUHUfEOP+Reh/wDBgP8A4itDSr5d T0u1v0jMa3MKyhWPIyM4q3WJ/wAzyf8AsGf+1al169vLDTluLJIHkNxFFibdjDuEzx3BYH8KZ/wk +itJcRLqUQaAukj4OyNkGWUtjGQATjOcA+hqjH4u06SK9ie9eAWcEchvnt28tw6ghhxj+IYXPOeK 0rnX9PtXniMjtJAjMVWJyGKruKKwGC2BnaMn2qCz8V6VPYWdw8ksH2mNZAkkL5jB7sdvyrnjccA4 ODVyx13TdSuZbeyuRO8DMshRGKoynBUtjGfbOa0KKxfE/wDx76d/2E7b/wBGCtmlooooooooooor Fj/5He5/7BsP/oySp/EeoXGk6BeahbLC0ltH5mJs7SB1zj2qho3iIXC3j3l1YTQWsayNeWbkwjJI KEkn5hjJ9mFXP+En0f7Cbz7U3lq5QqIX8wMBuI8vG77vPTpz0pYfE+jXF59jhvkeYMqMArYViAVD HGASDwD1OR1BpknivQ4YZpptQSKKHBaSRWVWGduVJGHGSBlcjkU6XxBp32M3CXSjLmNQ8b5D4zyu NwGMNnH3eenNUtI8U2j6Tpkmp3cS3l5AkjbEOwFuASRkKCemTzWnp+uabqsskdhc/aPKLK7IjbAQ cEbsYzntnOOelaFNb7h+lZXhP/kUdI/684v/AEEVr1h5z45OP+gYP/RtT67YXWpWC29pLDHIJ4pS 0ysRhHD44I6lQPzrIm8OayWd4rrT9x1GS8UPE5GGjMYU4brg5zUUfhHVY9HvbFdQtM3VlFbHMLY3 IgTd1z90ZA9TUt14X1S51qG/a+t32SFzv8wlQ0bIUVQ23A3Eg4z600+EtRaxS2k1C3bzbJLK4YRE bY1JwY+fvcn72e1bOiadd6el6t1NC5uLuSdPKUrtDHODknmtTNGaxvE3/Hvp3/YStv8A0YK2QaWi iiiiiiiiiisWI/8AFbXJ/wCobD/6Mkqx4h0+41bQrqwtZYopbhNgeVSygZ54BHas2+8OXd2L62S4 t47LUov9Jj8skiXGCyc42nC5BHqe9RTeGr19MS2hOl2khuPMf7NbNGqDaVyhUghuhyevIPFJF4f1 KXWbl5rlfsf2u3nDOg8yVoo0G4EdMspBBHbjrVebwdqLacbOO9tQILc21sWiY/IZEcl+fvfIAMYH Jq62gao2pzagt5aJKbvz4cRMQAYREwbJ5OACMd+tVbLwXPZmyMk9heSQwRwSTXFmCyLGzMpjHQH5 iDn0Brb0KwutOs5YryWGR3uZZgYVIADuWxyT0JIrTyKRz8h+lZXhP/kUtI/684v/AEEVr1j6hotz c6mmoWWpvZSiDyGAhWQMu7d36c1m3MOvwa1Y2A8Q5W6jlYsbKPK7NuMfXdV/+ytd/wChlb/wCjo/ srXf+hlb/wAAo6P7K13/AKGVv/AKOj+ytd/6GVv/AACjo/srXf8AoZW/8Ao6P7K13/oZW/8AAKOj +ytd/wChlb/wCjpj6BqVzNbm+117iKCdJvLFrGm4qcjkc9a3QMUtFFFFFFFFFFFY99ot1Pqv9oWO qPZSNAsLqIEkDAMzDr0+8aZ/ZWu/9DK3/gFHR/ZWu/8AQyt/4BR0f2Trp/5mVv8AwCjo/srXf+hl b/wCjo/srXf+hlb/AMAo6P7K13/oZW/8Ao6P7K13/oZW/wDAKOj+ytd/6GVv/AKOqWnwa/eXOoRN 4iKi0ufJUiyj+YeWj5P4uR+FXTpOun/mZW/8Ao60NLsF0vS7WwSRpFtoViDN1YKMZNW6KxNQ/wCR t0b/AK43P8o626KKKKKKKKKKKKKKKKKKKKKKKKKKKKKx9D/5CGu/9hD/ANoRVsUUUViah/yNujf9 cbn+UdbdFFFFFFITgVE9wkbKjyIrv91WYAt9B3qNtQtFXc13bgZxkyD/AB96e93BHEsrzxLG/Kuz gA/Q96dFMk0YkidZEboyHIP4ika4iSXymmjV8btpYA49cU8yDftyN2M4zzTTMgzl1BXG4EjjPSnk nHvULXluqsxuYQEbaxLj5T6H3oa9t1lEJuYRKTjYXG4n6VMjrIu5SCPUHIqNrmFA7NNGqocMxcAK fQ+lOWVXB2OrYx0OetSUUUUUUUUVj6H/AMhDXf8AsIf+0Iq2KKKKxNQ/5G3Rv+uNz/KOtuiiiiii kbpXLeKMHXPD6wtaJefaZTE9zCZAo8th2II5I79cVzllLokbaY2orp7KuqX5lYW+I+d+Dgg4HKYy fSrmrRwSadDsS2FnNrUTacLiHfEE2DcQvBClt57DnI4IrZ8L3VrambTbma2t9Tlnd3sol8tE2gL+ 7U/wkKH99xPGay9aTTZtduFMTT3P2uFWtpoSHlYbG3QyDnAG0leV4bjnNJNrUv8AareJ1khOmQ3P 2MnzW3mPO0/u9vUth87vugHHaneItSgefV7e6lgKWk9hJDsjIZf3gJ3EfewOfQA9K7Fb21e9azWd DcIgkaLPzBCcBsema4SJtLg1jVL3UEtJNJTVCrReT9yYooEjD+MfeHTjk884LmfTJPHVzcF9MaEy W0rCW2LzSkISpiYDru8s+px17V0fhXW4b/S7aOa6tzeSmZvLiTywwWQgsF9MFfz965rxAjSzeLBZ xrcKY4xc2pUEMPKPzgEcurY/AHuBXU6NfCXXtZss2+21kiWNYotpClBwT3IOR+lb1FFFFFFFFY+h /wDIQ13/ALCH/tCKtiiiisTUP+Rt0b/rjc/yjrbooooooooooqB7eF7tLhog0qKVVyOVBxnH5VMO lFB6VDHbQpdSXKxKJXUKz45IHQfrU9FQNbRG7FyYlMwTYHI5C5ziph0opaKKKKKKKZ5ieZ5e9d+M 7c849cVh2F5BYS+ILq5fZEmoDJxnrDCAB6kkgAeprTj1C0mvXskuIzcpGJHg3fOqnoSO1SWV5Df2 y3Fu++NiQMjBBBIII7EEEEeoqxSVzuuQT3PiTRo7e9ks5PLuT5kaIxxhOPmBH6Va/sfVv+hmvP8A wGg/+Io/sfVv+hmvP/AaD/4ij+x9W/6Ga8/8BoP/AIij+x9W/wChmvP/AAGg/wDiKP7H1b/oZrz/ AMBoP/iKP7H1b/oZrz/wGg/+Io/sfVv+hmvP/AaD/wCIo/sfVv8AoZrz/wABoP8A4ij+x9W/6Ga8 /wDAaD/4ij+yNW/6Ga8/8BoP/iKT+yNV/wChnvP/AAHt/wD4ij+yNW/6Ge8/8Brf/wCIo/sjVv8A oZ7z/wABrf8A+Io/sjVf+hnvP/Ae3/8AiKP7I1b/AKGe8/8AAa3/APiKP7J1X/oZ7z/wHt//AIij +yNW/wChmvP/AAGt/wD4ij+ydV/6Ge8/8BoP/iKP7I1b/oZ7z/wGt/8A4ij+ydV/6Ge8/wDAa3/+ Io/sjVf+hnvP/AaD/wCIpf7H1b/oZrz/AMBoP/iKP7H1b/oZrz/wGg/+Io/sfVv+hmvP/AaD/wCI o/sfVv8AoZrz/wABoP8A4ij+x9W/6Ga8/wDAaD/4ij+x9W/6Ga8/8BoP/iKP7H1b/oZrz/wGg/8A iKP7H1b/AKGa8/8AAaD/AOIrifFfgXxXq/i3T7vTtblQQQYe+k2RtH82doVAN3rzWnDb3FnFKl7e Nd/Z9eh+03DqFDDyYxlgOMZKj8q2DKU8cqUsLsR/ZGhadbZvKLllb73ToMZ9sVb8Onc+rSJzC+oO YiPukBEVsf8AAw4PuDWzRWJqH/I26N/1xuf5R1t0UUUUUUUVheINbk0a/wBL3zwQ2dzK6TtJEzMM IWG0g8dMcg9ayrTXta1EWH2W607beXdzCJTauRsi3bSBvBydpz9fbmXU/Ed/ZWOTLaQzW9+lndTS Qs8ZDIGDqoYEcMvBJ7j3rV8PalJqtg9xI8UyCQrFcwqVjuFwDvUEkgZJXqeVJrL1fxNeaZd6takQ AwWyy2cjRkqXKuxjf5sknYcEY/Tm5Nrs1vHLhEk+wWgur9wuMjYSFjXPU7T1OAB3qO61LXtOSO6u YbGe1kwD5W5Gid2VY1JJO4ZblgBwPu0641i+0R2XVjBdA2006NaxmMjy1DMpDMc5BGDn8KmF7qln c2g1BrSWK+l8lFt42UwuVZhkljvGFIzhe3HPGdoGu6prkohjlsQ9tJIt63kOBgOVVUBfrhSS3IGQ PWoZvEuqW+g6dqFxd6fb/aLyWCaVrWRkRV8zBCh85/d+v8XtWtp+rXhTT3vzbyR6ig8ia3VlG8qX AKtkgFRnPYgg9id2iiiiiiiisXRkWS911WUMP7RHDDI/1MVa+2iNAi4CqoyTgDFPorE1D/kbdG/6 43P8o62gc0tFFFFFFFUL3Sxe6lY3pupojZMzLGgXa5Zdp3ZBPQnoR1rMHhJkeCSLW76OSC4muEcJ CTulzuyCmMcnH1+lWJfDcckVuovbhJIrpbuSYbC08gGMtlcYxxgYwAAOlOttIvLLVA9rqDLpp8x2 tHVSA7HPynGQMknqfQDHRl74XttQl1Nru4llj1KBYZIiF2xhQQGU4zkbieSetK+lNHqUkixLc2t/ CtvdRyEAqFDAEeoIYgj3BFKPDcEist5d3N6u3ZEJnA8lcgjaVAywIHzHJ4HNOi0BGZ31G7l1Jmja IfaFQBUYYYAKAOe5PNOg0MpcRy3OoXV4Lck26T7MRHBGchQWOCRliTyfWqcfhMwW9pHBrF7FLayS Otwqxb2Dkkq3yYK5JOMenoKVPChisLK1i1m9Q2U7zxyhYixZt2c5TGPnbt3+lSQ6TcfbbVZppJIL CQzJLIyl5pCjLjAACoAx4AHOMYxzuUUUUUUUUVjaGcX+u/8AYQ/9oRVr7hjNKDmlpK5bxXq6aJq2 mai9rc3SxQXJMdtHvc8J29Pesbwd8Tp/EtxqDyaNdLBAyrElrCZWGc53nseOmK6j/hJk/wCgNrH/ AIBNR/wkyf8AQG1j/wAAmo/4SZP+gNrH/gE1H/CTJ/0BtY/8Amo/4SZP+gNrH/gE1H/CTJ/0BtY/ 8Amo/wCEmT/oDax/4BNR/wAJMn/QG1j/AMAmo/4SZP8AoDax/wCATUf8JMn/AEBtY/8AAJqP+EmT /oDax/4BNR/wkyf9AbWP/AJqP+EmX/oDax/4BNSf8JKmf+QNrH/gE1L/AMJMn/QG1j/wCaj/AISZ P+gNrH/gE1H/AAkyf9AbWP8AwCaj/hJk/wCgNrH/AIBNR/wkyf8AQG1j/wAAmpP+ElTJP9j6x/4B NS/8JMn/AEBtY/8AAJqP+EmT/oDax/4BNR/wkyf9AbWP/AJqP+EmT/oDax/4BNR/wkyf9AbWP/AJ qP8AhJk/6A2sf+ATUf8ACTJ/0BtY/wDAJqP+EmT/AKA2sf8AgE1H/CTJ/wBAbWP/AACasyy1h44d Xnt7aRLi71VYYIrlChDNDEMsPQAE++O2a1brVLyz1O2gltIza3EogWRZf3hbbktsxgIMY659qs6P fSXkEyXCqtzazNBNsHykjBBH1VlOOcZx2rQpKxdQH/FW6N/1xuv5R1oW2l2FldT3VraRQzXGPNeN QpfHTOOtW6KKKoT6tFb6rDpxhuHmmieZWSIlNq4zk+vI4/2hWbH4ys51tmgsNTmN1G8sapaknarb WJ545I/MVYufE9nbpaPHDdXX2xmWJbeEudyjJVh/CQAeD6Gp11u2bSJtTVZTFAHMiCM+YpXO5Svq CDxSQ69aXGoWtnCsshu7b7TFKqZjKcc7umeRx7iopPEtirERJcXGGIJghLgKOr8fw5yM9yDjOKT/ AISexktba4tYrq8+0xCZI7eEu4Q9GYdgfepZ9fs4reGaIS3RnBMcVvGXkYDqdvbB4Oeh461H/wAJ NYefaQkThrnfy0WBCUGXEhP3CB601fE1s1vZTm0vkS+nEMIe2IJJGQSOy4ycn0NRP4us47qWBrHU iIZzBJKtozIrAZJJHbHOfStO61K2tLA3zybocKVMfzb9xAULjqSSAPqKr2Wv2d8LvaJoWslBuEnj MZjyMjOfYZqxBqMNzpyX8AeWKSISKqL8xHpj17Y9aLXU7a8vLu0hcmWzdUmBUgAkZGM9eKZfatDY T2cMsczG8l8qNo49yqcFvmPYYBOfY1SbxVaLpw1AWl80DXCwRlbY5kLHClR3UnAB9xV2x1VL+JJE tbuLdK0RWaEoyFc8kHtxwe+RT9U1KDSNPkv7oP5EWC5RdxUZxn6DvUP9twnUJ7FILmSSCBZyyRZR lY4Xae5OD+RrRByKWiikrk5LWaeTVZ7dDLLZ6zHcCIdZAsMQIHvgkj3GO9abaXeyeIE1R7+JoETb HbPbHdECPmw+77xOMnHQYqXQbaaKG7up4zFJfXTXHlN1RcKqg+5VASOxJHatWisTUP8AkbdG/wCu Nz/KOtuiiiiud1jSp9Q8Q2MpguPssFtMrSwXhhbexQgfKQSPk+nI9Ky9Jstd0pdJb+xTMbSzmgkU XiZBaRSOT14Tr71LdeHb6Y6dE6yBWvZ7q6ltbnymgMisAFIwWwX/ABx0p9umpRaPe+H/AOyma4Fl IRcrMCk7tldxJOQzElufQ+1RxeG7+LzHiURLPpEsH2cuMQzsEGFI/hJXP1ye/Fmw+1wOL3TbVbpp LeG0ngeQRNbSRbvvA9vnOcc9CMg1ZNtqmm3z30NpHqD3MEUUyROIdjJuII3djvPfIwKgh0nUNKmh 1CCFL2bbOs1usgTBll807WbrgnHOMjn2qjd+Gr3UdStZbq2YRXFzLc3PlXAU25MaIg/28bAT2zxg irko1+/i0s3WkokttfrJKy3KYaMBhvA9fmBx9apRWV7pviK81m6spIYjcu6ztfDyREyouTEOdx2c YGckCtG3stQi8IG1htIJLiWV2Fvd8J5bzFiGx0+RunYjFUH0rWprRrFLR7awu50WSL7UryW8IB3b Scggnb8vIChhjmln0XV00PXdHhhmnglG6xla5WN3duXztACqG5xjnnrmtG3a/sL7W9SudOKxyRxS Qqsys0hRMFeOhzxTNf06bX4NJiewl8hpxLdL9oETwqY2XHB5IL8gdcEd6q6jBr+o6N9hn0ou8V5C yyxXaRmaNJA27K42NhR07njHYg0/UrQaKy6fMkOnTSM6yXwdxGY2GX7OdzZHUgD1NXtXa+1zwbKL bT3S5u4Ri2mkVWXJ7np05rK1Hw1qKW+rCyRpEuoIBbQ+eIzEwkd2Td02jdwOmDjmuzjJKBmXaTyV znB9KfRRRWNoYzf67/2EP/aEVbG0elGMUtJ2rn9ZvLWx8TaNPeXMNvF5VyvmTSBFzhOMmrv/AAk2 gf8AQc07/wAC4/8AGj/hJtA/6Dmnf+Bcf+NH/CTaB/0HNO/8C4/8aP8AhJtA/wCg5p3/AIFx/wCN H/CTaB/0HNO/8C4/8aP+El0D/oOab/4FR/40f8JLoH/Qc03/AMCo/wDGj/hJPD//AEG9N/8AAqP/ ABo/4SXQP+g5pv8A4FR/40f8JLoH/Qc07/wKj/xoHiTw+CSNb03J6/6VHz+tH/CS6B/0HNN/8Co/ 8aP+El0D/oOab/4FR/40f8JLoH/Qc03/AMCo/wDGj/hJdA/6Dmm/+BUf+NB8SeH2GDremke91H/j R/wkugf9BzTf/AqP/Gj/AISXQP8AoOab/wCBUf8AjR/wkugf9BzTf/AqP/Gj/hJdA/6Dmm/+BUf+ NH/CS6B/0HNN/wDAqP8Axo/4SXQP+g5pv/gVH/jR/wAJL4f/AOg3pv8A4FR/40f8JLoH/Qc03/wK j/xo/wCEl8P/APQc03/wKj/xo/4SXQP+g5p3/gXH/jR/wk2gf9BzTv8AwLj/AMaP+Em0D/oOad/4 Fx/40f8ACS6B/wBBzTv/AALj/wAaw9U+JnhvR9Yt7C5vUeOePcLmB1ljQ5xhtpJHrVzQtUsWGuai l3E9mb7eJ0bKkeTF3HfPGK2vt9sbpbUXMX2hk3iEuN+3129cVJa3MN5brcW8gkicZVh+R/HPapqS sPU40k8V6MsiK6+Tc8MMjpHWv9jtf+faL/vgUfY7X/n2i/74FH2O1/59ov8AvgUfY7X/AJ9ov++B R9jtf+faL/vgUfY7X/n2i/74FH2O1/59ov8AvgUfY7X/AJ9ov++BR9jtf+faL/vgUfY7X/n2i/74 FH2O1/59ov8AvgUfY7X/AJ9ov++BR9jtf+faL/vgUfY7X/n2i/74FH2O1/59ov8AvgUfY7X/AJ9o v++BR9jtf+faL/vgUfY7X/n2i/74FH2O1/59ov8AvgUfY7X/AJ9ov++BR9jtf+faL/vgUfY7X/n2 i/74FH2O1/59ov8AvgUfY7X/AJ9ov++BR9jtf+faL/vgUfY7X/n2i/74FH2O1/59ov8AvgUfY7X/ AJ9ov++BR9jtf+faL/vgVg6t4D0DXNYg1PUrMTtbx7Eh6RnnOSB1P6VmyQw273EEcSRWia/Crxqo WNU8mPAI6Y3bfxxVvUkMniizigifKXKSyRi1Kk4UjzfN6EdBt68VpeHfv6sF/wBSNRfysfdxtTdj /ge/Pvu75rZorE1D/kbdG/643P8AKOtuiiiiqkmqafFNLDLfWySwJ5kqNKoaNP7zDPA5HJqFvEOi I6I2sWAaQAopuUywPQjnnNSXms6Xp8oivtStLWRl3BJp1QkeuCelW1dHUOrBlYZBByCKrxanYTXD W0V9byTo2xollUsrYzgjOc4B/Kp1midnVJFZoztcA5KnAOD6HBB/GkkmiiKiSVE3sFXcwG4nsPU0 ryxxRtJI6oiAszMcAAdSTVaPWNMla3WPUbVzc58gLMp83HB28/Nj2ptrrWk30/kWmp2dxLgny4p1 dsDrwDV3IPeqkmr6bFA08moWqQrIYmkaZQocdVJzgH261byPWobi+tLWSKO5uoYXnbZEskgUyN6K D1PPamDVNPa5e1W+tjPGdrxCVd6nBOCM56An8Khh8QaLcb/I1exl8tDI+y5RtqjqxweAM9aE1/RZ IZJ01exaKHHmSLcoVTJwMnPGTxQmv6LLBLPHq9i8UOPNkW5QqmTgZOeMn1py63pL2j3i6pZtbRsF eYTrsUnsWzgHkU6LV9MntZbuHUbWS3hOJJUmUonfkg4HUUn9s6WbaO6/tK08iV9kcvnrtdvQHOCf artFFFYelQx3F3r0csayIdRB2uMgkQwkfqK2QD+tNghjgj2RxLGu4ttUYGSSSfxJJ/GpaKxNQ/5G 3Rv+uNz/ACjrboooori9fju5tc1Y2k0luF0lVc/YGlE2GkO1W6Z+ZeBnr7UzTb6ytb1Dd2VyyNpF pDt+wStuYeZuT7uAcMOuOtQPZazby6Tb2zeVqMGlzgtLamdGJdCsZbgA4U457V0Xhq605rBNNsmn EllEgkjuImR0znGcgZ5DdOOK5yymis57W+h0m+ZbOGWQWs9q3m2gKnASQD5g3yqF5PzZPTifSJNU 0y/jmvG3prMTyM8VvM3lSAFg7qR8vB2bevCjotJHJcz6B4cvNSa6u7038UkjNZsrRcEN8oXKj1J6 5z3rq4tRtLmO6aKQutpI0U4EbZVlGSMYyeCOmc5rk/Ccv9kW+mDUILiZ7y2RIZvsUga124BiYBfl Gedxxk5J4xUegSyRXM7tLOFBuzBGdKcNbbpXbzN5A3ArjgcnIGK3PC2pPc6ba219ezT6o9slxOs0 BiZc/KRjAAwQfx57isG4tLyefU5bSGZ4ZNZi8+CSJ13KHhxIgI5wVbOOo57VsRarNbeKNRGoX86W SPBDaxm1ZYy8gxjfj5vmxznAJqzq0Zk8TaUq43/ZbvaT2OI8H2qrpEVo0Wl2s2lSNfaYmZpnhKiF 9hVmD4w+4k9M5zk4rF8OO0Vpc/aBPKv2ecRW50t42twXdid5X5tw2DA56cVZ8NWcqyaZ/bINxGli n2MfYTGEYBS6yDn5lMakE49smmeRH/wrG6ZLGRbmSB4sfZG80nzGKjbjcR82fTk0zVIblNL11b7z bm8ntkS3kgsWCSRZyp2DPzBnIIJB46YGat2vmMkF3N5t9FbXzTXcw09ofMUoyp+7Iy5T5D0PAGMk VFqs0GpaTrWqWAzp81vAsZKFN8iu25gpGehVckDO3Hau5FLRRWPof/IQ13/sIf8AtCKtiiiisTUP +Rt0b/rjdfyjrazS0UUU0qT34owfWjbnvTVhRGd0RVeQ5dgvLHGAT68AU7b70YI6GjbznPNNjhSI ERoqAksQoxyTkn8TTtvXnrRg+tMWBFkeVUUSOAGcLycdMmn4PrTHgSQoXVX2NuTcM7T6j35NQXel Wl7c21zPGTNasWhdZGUqTjPQjIOBweOKtbT60FScc0BcHOaMHOc0bT60YPrWddeHdJvA4msY/wB7 IJJfLzH5rDoX2kbuvQ5rSAwKWiisfQ/+Qhrv/YQ/9oRVsUUUh6Vyviu71Gz1XTLnSdPGoXawXPlw GQIG4Tuf5Vz3gbxV4y1fUNWGpaWrywMgFtJJ9nEAOegKknPrXZf2h4i/6F+3/wDBgP8A4ij+0PEX /Qv2/wD4MB/8RR/aHiL/AKF+3/8ABgP/AIij+0PEX/Qv2/8A4MB/8RR/aHiL/oX7f/wYD/4ij+0P EX/Qv2//AIMB/wDEUf2h4i/6F+3/APBgP/iKP7Q8Rf8AQv2//gwH/wARR/aHiL/oX7f/AMGA/wDi KP7Q8Rf9C/b/APgwH/xFH9oeIv8AoX7f/wAGA/8AiKP7Q8Rf9C/b/wDgwH/xFH9oeIv+hft//BgP /iKP7Q8Rf9C/b/8AgwH/AMRR/aHiL/oX7f8A8GA/+Io/tDxF/wBC/b/+DAf/ABFH9oeIv+hft/8A wYD/AOIo/tDxF/0L9v8A+DAf/EUf2h4i/wChft//AAYD/wCIo/tDxF/0L9v/AODAf/EUf2h4i/6F +3/8GA/+Io/tDxF/0L9v/wCDAf8AxFH9oeIv+hft/wDwYD/4ij+0PEX/AEL9v/4MB/8AEUf2h4i/ 6F+3/wDBgP8A4ij+0PEX/Qv2/wD4MB/8RR/aHiL/AKF+3/8ABgP/AIij+0PEX/Qv2/8A4MB/8RR/ aPiL/oX7f/wYD/4isyw1S6sodYmltES+n1RYYrcS71LtDEB82BxjJPToRWrfeIEstVs9O8gzSTuq yOrYWLdnbn6lTx6AntVnSdQe/t5fORY7m3laGdFOQGHOR7FSrD2b1q/SVi6gP+Kt0b/rjdfyjrZ2 ruLYGSME4qjrmovpGjXWopbi4NtGZDGX2bgOvOD2rK1DxXcWL3ippsU4tLFbtyl2OcnBX7vbDc98 D14tHXLuATRXumpDdiB54IkuN6zKmNw3bRtIJHbuPemaL4im1Ka3jubFLY3VubiHy7gTfKNuQ3A2 n519c8+lWNY1ltMltYUt0ke4YgGSYRJxj5dxBy5zwvfB54qjJ4slhey+0aU9uLy2eZUllAkDqwUR hMcsSy4we59K2bGe6ntI5L21W0nb70IlEm30+bAzWZD4jkuTpLQWO6HU5JFV2mAMaqCwJGOchTxn iooPE12Y5bq80tLeyhuHt5JkufMZWV9mdu0cZ98+1bdpcrdRNIpjYLI6ZjkDj5SR19eOR2PFZt/r lzBJdDT9Lk1BbIET7JAr79oYIikfMcEdx1HU8VWuPE15FrDWEelxMFEBy94qO3mZ4VCvJG1uM9qb J4puYb27SbTIxbWl0ts8i3QMh3bdrCPbz99e/HPpT7DX9XutUNlPoAg8vyzOwvFcxK4YgkbRn7uD g9+9TR+IJf7I1S+uLHypNLMgkhWUOH2IH4bA6g+lJ/bt8xMMOk+fcwoJLqJLgfuw2SoUkDexAzjg e9VLnxXfQzwwx6Mu+Wzjudk94sLguceXgr97dx161JeeKbiyv7+F9NjNvYBXll+1AOUK7sqm3k9e M8mnR+INWfWf7Pbw+EACyM/2xSyxGQpv27fYtjPT34pkPim5a8kjn0yOO3jvRZtIt0GfcWCqQm0c EsM88DJ7Utp4nubjUZbeXToYYYZpo5JBeKzqIxkv5e0ErnaODxuFWLfxBNIYLi40/wAiwumRYLjz gzEucJuTHyhsjueoz3xJba3LIuq/abIQvprYZVl3iQbA4IOBjIPSqR8UX6w28j6OgM9hLegfawcB MfL93qQy/r6Va07Xbi4a1GoaetkL1N1syziUMdu4g8DaduT6cHn1d/b8cmqWdtarBdWt2WQXMU4b a4QvtKgeg6571sDkZoxRiuTa0nubnUZbaPzZLXXIp/LBALgQxAgE8Dhs/hVvUPCqXerRahDqN3Cw u47iWPzMo21doAGMj88cn1q9olrNAdQnnTy2u7x5hGSCVUBUHI9Qm723Y7VqUViah/yNujf9cbn+ UdbdZ2v2E2q6FeafbyRRSXMRi3yoWUA8HIBGeM1g3fhG4c34sP7Mso76wW2ZYrUqA4JJfgjP3jj8 K0H0rU7sy3N9dWpu1t5Le2EMbLGm/G4tk5J+Ve46e9ULPw7f+HbaKXRItPa4eGKG6j8kxpKycCQE HIODznPTgZ66+r2GoXkkbWV1bLCI3Sa2uoPMjn3bcbuQeAD+dZp8KSNLp6zTQXEFlaSQgyo3mh2K kOrA/LgqAMc4zzWtplvqKad9n1i4gupcbTJAjR7lxjnk89elZOlaZqMlnoEkjRwNpjOLiOWI7mO1 kwpBA6EnPIPFLD4f1SSCaxvbyzaxnuXuJBBE6yHdJv25LEAZ74qfRbLVtIkjstlm9nJNcTyvChTy 97blVRk92PtgevWefS75by4bT71LeG9cPcloy0isFC5jOcDKqByDjGaz73w3e3PiJ9UjfTmO2JYZ J7dnmg2bvmVtwGTvPtwKD4UnOpXOqh7H+0Ptn2i1n+zklV2BCjnOSCADxjmtSz0+6g13UL+WaFoL qOJEjRCGUoD1JODnce3pXOv/AGpd6f4iW20+Q2l4t04MsTRys3koqBVPJyQ3bt1rYjsrueU6lpNw LY3kaJOLu3bcoXIDKpwVYZPBGOlVtU8M3l5rEF9G+nzrbwRxx/boGkkVlfdvDAjnIHT0ps3hOa51 O61K4ls5brdBJZztbfPG8Yx8xz0bnIGMZ45wa04NPvh4hOpTzW5jazSBo0Rg24MWJBJ6ZJ4xnpWb b+FZ4L+XVQ1j/aP2ySeKcW55jcbTG5zk8YOQRyB2yC2z8L3kOq3V3I+mkXU0pkmjt2E/luQTHuLY x8oGccdqf/Z2qw3FhptxGt1pNu8bRSwKBKpjIKCTcwG0YByoJOOg71w2pXN/rjWdm/2O6Lq7zxNG zbbdVXYDjOX46YIzz6vt9Nv9T0+xmt5EtlTSpLJo7q2kVw7BQTgkcAoO3PPPSrtlouobLQancWkw 0+MrbLDEyqzFCmXyTkYJ4Hqfasy00250YaBpcUAmmsfPkZ7a2ZYcGOQLkngEkgYz3rrLB7t7CB7+ OOO6KAypESVVu4BNWKKxtDGb/Xf+wh/7QirYwPSilorE1D/kbdG/643P8o626SijFLSYoqjrOopp WmS3R2lxhY1Y43uThR+JIrLm1+5l0jTb2xFvuubuO3nWUEhCW2sBg9QR3qG91fX411h7RNNKabK3 +sWTJQQiTseWywHYcE+1Mk8RappzaXJq82lw217IwaVQ4wvlhxjJ4Odw79j7Vp+G9UuNX0tryZ7a QG4ljje3B2siOVB5J64J/Gqepa3qtrqptYbe1VWkRIUuNymcHG5lk+7kDd8n3vlz3FWX8Qwp4lXS js8sjYZNwyJiNwTr/d5/EUk2rTz293Lpt1YFLSd0nmnD7IQigsCMjJ5OSCAK0rG6kvNOgupIGgkm hWQwueUJGdp+lc/bap4qN9cwS22mTmyjR5YoDIjOWRiFVmJGdwA5HOc8UW3ia5W3vZ9QmsYbe0tw 73ASRDHITjY8TfOOMfXPFX/El7qum6ZJfactoUtoZJpvtO8k7RkBQpHXnk9KpX+sa9paJ9sj09QA x+0BZBC/91CefKJ9WyORirlv4gjuree2ieI6ra24kuYFDOkTlA2CRxjJ455xWlpt2NQ062vAmwXE SybM525AOPw6fhVqilpMUtFFFY+h/wDIQ13/ALCH/tCKtiiiisTUP+Rt0b/rjc/yjrbooooopD0r L1XRhq1xZvNORBayF3tjGrpPkYwwYdgT+PPaqi+FY0jukiu5IkluUubeOOJFS1dQMbVAwRwCQepy e9TjQWOlahaSX0rz6hu8+52KGJKBMhcbR8oA6e9L/Ychm0mU6hLnTFIx5afvsrty3HHGemKj07SN S0y5jRNR8+0Mk804kiUM7yNuAGAMAEsc++KS58OG6up5H1O7NtczJNNattKEqF2hSRlRlATjrVd/ B0clm8bXrfbXufP+3/Z4/OX5t20HHTPH046U648L3EyXSDWbhFurv7TIvkRkH5QNhBHK/KvXritD TLTUbUzR3t6bqIBFgLKN+AoDMxAGSx5x2/lBJoDS3GrStqE6jU4REVQKphAUqCjAZzyetQTeF2ub a9jn1S6llurb7IJmRN0cWeR0wx5PJ5qVtI1K+8PXemalqJaS43p58UShljPQYxgnHfHf2zTrzRLm 6uVuE1e6gk+zi3cKqlHGSSxQjG456jpUdroLaPBqDWc003nwJHDAQo8vYmxQG4zwByTWhpFm+n6T Z2km3zIYERynQsAMn8Tk1eoooooopKyND/5CGu/9hD/2hFWxRRSVzuu6haab4k0a5vbhIIvKuV3u eMkR4FWf+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8 O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP +Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/ ++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8A QXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8 O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP+Ew8O/8AQXt/++qP +Ew8O/8AQXt/++jWBrHxW8P6LrFvZzO09tNHuN1b/MIjnGGXr+IrY8K39pqTaxfWU6z281/uSReh HkRV0G4UZzS0lYt/x4s0Yf8ATG5/lHW1RRSE4NGfr+VGfqPrRn60tJn60ZozRn6/lRmjP1ozx3oz zjmjP1oz9aUcjvSE0v50meehoz9aM0Z9c0bucc0E4GecUo5GaKxtS8JaNrGrwapqVmt1PbR7IllO UUZz93oTn1rKa4ltW1O2tG8h7vWY7ZZFH+qBhiyQPoCB6Zz2qybnVbXxEUvp7qKwluFitNiQtHJl BgMf9YDuD89OBWjoNxNJFd2s8jSvY3TQCVurrhXXPuA4HvjPetWisTUP+Rt0b/rjc/yjrboopkgU qQ/3cc/SvONE2PF4ZWdLIWZvbgRSres0knyynBUgDqF/iPIFWfDyafBpOlXGkzI2pS3KpKI5jIzx GQ79wyeAgzk9MCoNNSCHWTPGLa2g/tadRqAu2ZlCMW8plPChlBAOcY9yAes8Sz2cuhgzX628E0sa iUAvG5LABW2kZU9DgjjvXKXaQppGy3aEzprNusQkvGa23FUAVH67MYyvODuHvXT+GTpypcpDKDqR kP8AaCvIDIJepyAcAfNxjjBFY+vmKXSPEUt5Lt230MYDylfLUeUQuc4wdzNx/f554E1zbeH5PFmq NqM0CNHbWzITclWQ/vOQM8HATp6CpvD+u6lc3gstTezi8izt3lLPiZpJAeCvAU5HTnt68W9cgjuf EOhQygugeaQLuIG5UBUnHoaz9Jg025Ol3NxdTjWndZLpIpCWaQKQyyJ2VST6AYGKyvDMWnC7neYW KQMLqKOVL5mkkzK42umcABBwecAdRTPC2n299Hp9tdxQ20E9hHKxhvHf+0Pun5jxgqVJIyep7Vre GtF0i48OXM8aCUTmeOXbOzKwWZyvfqABz1xitrw9ewr4U0+WS4U+TYxNMzPkp+7BO70PfmsPRNbu TrUd7eL5dlrbEWrtNGVYgZjCgEnlAc5AweOpqs8Fj9nvbNivnt4gjYQmU7ynmoCQM527S3tjNXLb QtGTxvLAgJkhtYrpR9pcuJPNclsZ74Ge2MDpWOwQxToEsjp//CRqrSm9bzAfMUbduMYwSMbumTiu 01q6tB4fvZ5L5oLdY233MHzFMcEjH8q5i2vrfQo9Re1lhe5eKGG2ENzm2Z3ZwgUOTsckkspJGNpz zT4vEF5oHh7ULWZIRf6aEkSK8uFBaJ2wCxQtg53DGc8A9xVu3msF8WQBL+3F6qyNesk+fNYpkRBS egHz+wVfWusikSWJZI3V0YZVlOQR9afRXM2+nf2jc6uqy+TLBq6TRSbd21lhi7d8gkfjWq+iWcmp Lfv5rOrBxGZW8veBgPtzjdjjNSabp/2BbktL5stzcPPI+3GScBRj2UKPfGe9XaKxNQ/5G3Rv+uNz /KOtuiimlQwIPIPBBqAadZBUUWkAWMkoBEuFJ6444og06ytZDJb2kELkYLRxqpI9MgUj6bZPbyW5 tYhFKcuqoACfXp196LbTrSzsorKCBEt4VCpHjIAFL/Z9n5KQ/ZIPKjO5E8tdqH1AxweaclnbRTPN HBEksn35FQBm+p6moE0m1Wa7d0EqXbrJJFIoZd4ULuGR3Cr+XuakfTbGSYTvZ27SggiRolLAjpzj tUV5pFhfHNxaxufMV2O0AuVOVyepAIH5Cm6hpX269srtbqW3ls3ZlMYUhwwwyncDwR6c1aW3hSd5 lhjWSQAPIEAZgPU9TUUem2EJZorG2UspVisSjcD1HA5HtUi2luixhbaJRET5YCD5M9cenU1DNYIb GS1tG+whx9+CNPl9cAgj9Ki0rQbDSrRreCLeJERJWk+YyhVCjd+A6Vb+wWm2Nfs0OITmMeWPkPtx x+FONnbG5F0beIzgYEuwbwOnXrSi2gFwbgQxiYjBk2jcR6Z61H/Z1ltK/Y4NpfeR5S43evTr7020 0yzsbZreCFVjd2kcHnczHJJ9Tmnf2fZbNn2ODZv8zb5S43/3unX3pZLCzmd3ltYZGcAMXjBLY6Zy OegpjaZYkuwtYkd1KmRECvgjB5AzUlnaW9hZxWlrEsUEKBI0XooHap6Kx9D/AOQhrv8A2EP/AGhF WxRRRWJqH/I26N/1xuf5R1t0UUUUUUUUUUVDc20V1bS28oJjmQo+GIOCMHkciuFTTfD9pBr9wJha Czu/I82B2fykZIhtZQeVLEgjry3Q0WF5baXqkMMf2J0mvYIWdLgtAPkk2mEH7rZzuXJA3Drmr/iW w0K9v9JvpWgmN7exwM5nysiBJPlHOOuOnfFULi30mDVDFDdGU213BAYvNdLqLaY9qoSSJI/ukgjp uOTV2fWLzULbUZJJLNRpuqRQwC2cs5PmIMMegLBinpyc8CuyHSloooooooooorH0P/kIa7/2EP8A 2hFWxRRRWFqkiReKdIkkdURYLoszHAAxHyTU2j+JtJ167urfS7sXRsyFldB8gJ9D36dq16KKKKKK KKKKKiW2gQsVhjUudzYUDcfU+tNFlaBVUWsIVW3KBGMA+o96X7Ha7ET7NFtjOUGwYU+o9KU28BlW UwxmRclX2jIz1waFtoE3bII13tubCAZPqfepKWiiiiiiiiiiufsbyHTpPEF1cMVjj1AZwMkkwwgA DuSSAPrWlJqtnDew2Uk+LmcZSLaSce+Onfr6VNY3kN/arcwElGJHzDBDAkMCOxBBB9xVikrnfEvh 228Rajp8F/aG4sVinEvzEbSQm3kc54NZXhz4V6FoF1esUF9b3BUxJcoGaLGcjPfr6Vvf8If4c/6A 1p/37FH/AAh/hz/oDWn/AH7FH/CH+HP+gNaf9+xR/wAIf4c/6A1p/wB+xR/wh/hz/oDWn/fsUf8A CH+HP+gNaf8AfsUf8If4c/6A1p/37FH/AAh/hz/oDWn/AH7FH/CH+HP+gNaf9+xR/wAIf4c/6A1p /wB+xR/wh/hz/oDWn/fsUf8ACH+HP+gNaf8AfsUf8If4c/6A1p/37FH/AAh/hz/oDWn/AH7FH/CH +HP+gNaf9+xR/wAIf4c/6A1p/wB+xR/wh/hz/oDWn/fsUf8ACH+HP+gNaf8AfsUf8If4c/6A1p/3 7FH/AAh/hz/oDWn/AH7FH/CH+HP+gNaf9+xR/wAIf4c/6A1p/wB+xR/wh/hz/oDWn/fsUf8ACH+H P+gNaf8AfsUf8If4c/6A1p/37FH/AAh/hz/oDWn/AH7FH/CH+HP+gNaf9+xR/wAIf4c/6A1p/wB+ xQfCHh3/AKA1p/37rA+y2+nfaUt4Ut7O28QRM6qMKimGMc/8CYfiavQwavZ+KrowrcmG7uxK4KIY PJ8tVJ3Y3B9ynC5x7c1peHfnk1aZeYZdQcxMOhARFbH0dWH1BrZooooooooooooooooooooooooo ooooooorF0VQ19rgYAj+0Rwf+uEVa/cUqqFyFAAz2p1f/9k= ------=_NextPart_000_008A_01CC63E6.FF820240 Content-Type: image/jpeg; name="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCADPASABAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/AO68M+GPD9x4W0iefQtN lllsYXd3tEZmYoCSSRyaux6D4OmuprWLSNEkuIMebEltEXjz0yMZFObwx4XSRI28PaZlwSP9BTHH XJ24HXvSjwv4Y84w/wDCPaZvChv+PFMYzjrtx26dak/4RPwz/wBC9pX/AIBx/wCFH/CJeGf+he0r /wAA4/8ACj/hEvDX/Qu6V/4Bx/4Uf8Il4a/6F3Sv/AOP/Cj/AIRLw1/0Lul/+AUf+FQeHbS2sdT1 y2s7eK3gS7j2xQoERcwRk4A461v0UUUUUUUUUUVX1AkadckHBEL/AMjXP6F4X8PTaBpssug6bI72 kTMzWkZJJQck45p1zp3gOzuvst1Y+H4J+P3UkMKtz04IzV7/AIRLwz/0L2lf+Acf+FH/AAiXhn/o XtK/8A4/8KP+ES8M/wDQvaV/4Bx/4Uf8Il4Z/wChe0r/AMA4/wDCq02g+EIL23s5NE0hbi53eTH9 jjy+0ZOPl7CrP/CJeGf+he0r/wAA4/8ACj/hEvDX/QvaV/4Bx/4Uf8Il4a/6F3Sv/AOP/Cs+bR9L 0rxXoradptpZtILhXNvAsZYbAcHA5rp6Wsfwl/yJui/9g+D/ANFrXNavqgtNV1w2mqw2M4ubBHch WO1jtYYPsSfwrN1bXJLmDUtHOvGRIYL6LaHTzX2KjKWOPdxwBwD6Vrza20F1dWsGszzwjTopIs7R IpMpVnLEcDBGXIwq/Ng98zT9Wlv9UsLiXVJXmtzdwRLBKswkKmJlViq/PkE5IA4HbBNTnXL5bOIx +IDGsrWfnzSKj+VNJIRLCOgXavO08gCu/toTb2yQmaSYoMeZKQWb3OAKlorG0f8A5Dmvf9fUX/oi Otmiiiiiiiiiiiq2o/8AINuv+uL/AMjVXw7/AMixpf8A15Q/+gCub8QG4m8Sagmn3kSyxaXEZrcR K7yp5km4Ak/Kdp/UVHeapI91p0Wia7bW+mx2kX2Z33ObhtxUqAOXICrleCN3vTNV1jUVk1ySz1mQ SWiPtEKLJHFiRRtZCMq+MgckPliOlWDqk5Ty5NZlTTDfGM6llVITyd/3yMD978nT/Z61nP4i1KOK e7u9cEMlrZWs/wBlKIo3s7Kd2eSCNpxx94fjLfarcnXYJkupZryOe9EVosW9UAjcQtwMjcMHk/Nn I6U2LVdUWwtd/imA/aL6CJ3iUOV3Bt6b2GM9OByvfrXfW8LQQxxNK8pRQN8hyzY7n3qasTVf+Rp0 L/t4/wDRYrborlfDuvWlj4a0qzubfUY54LOGKRP7OnO1lQAjhPWrkXivSJ08yH7bKhJAZdOnIyDg 87PUEU//AISXTP8AnlqH/gsuP/iKX/hJdN/556h/4LLj/wCIo/4SbTB0iv8A/wAFlx/8RR/wkum9 47//AMFlx/8AEU7/AISjTcf6vUP/AAW3H/xFH/CUab/zz1D/AMFtx/8AEUf8JRpv/PPUP/Bbcf8A xFR+H5hdahrN2kU6Qz3SGMzQvEWAhjUnDAHqCOnatyiiiiiiiiiiiq98rPp9wigszRMAB3ODWDov iGytNC0+2ng1FJYrWNHX+zrg7WCgEfc9auf8JNpvePUM+v8AZlx/8RSf8JLpn/PPUP8AwWXH/wAR Ud1rmjXttJbXNtfyRSDDodNuBkf98VL/AMJNpvTy9Qx/2DLj/wCIo/4SbTf+eWoH/uGXH/xFH/CT acOkeoZ/7Btx/wDEUDxLpoGPL1D/AMFlx/8AEUkvi7SYIzJN9ujQEAs+n3AAycDnZ60//hKNN/55 6h/4Lbj/AOIqk+oRar4n0h7SC82W4nMjy2ksSrlABy6gda6QHNLTQD61j+FOdBQ/9PFz/wCj3rZo oooooxQAR1OaWiiiiiiiiiiiimgH1paKKKKKKxfF/Hhq4/66Q/8Ao1K2qCM96AMUtFYvhP8A5ACf 9fNz/wCj3raoooooooooooooopDSbqUHNLRRRRRRRRRRWJ4w/wCRauP+ukP/AKNStqlooorF8J/8 gBP+vm5/9HvW1WL4h1mTRZNNkM1rDa3F15NxJcZ+VdrNkEHGflI59RWTb+JtX1BYmsZNMdJ9SltI pdjspRUZg3Dcn5SPxqbUfEmoWOn3G42UV3ZXUMFxJKG8nbIRhxzkY3A4J7HnvWj4e1ibV4J3d7ed IpAqXVrnyphgElck9DweTyKp6zr2q2OoPBbW1sFIVbcXJZRcseu2T7oI5+U8naeg5q3ceIobfxFD pZKbGASSTcPklbmNevcA/iyetR6z4hawi1D7Ibe4uLGOF5IGLKUDsRknoeBkDrx7itzJ56VzH/CQ apNrl/otqbBryGZfK3q+Eh2Kxd+eT84AA7gnp0ZqXiTUbPxL/ZKXGloXEBgimWTzJt5YMAQcDGwn OMcjNdBpd/Dqdmbm3uI7iIyyIskYIB2uVxz1xjGehxxWHq/ii60y81a1McANtbJNaSMrbHYq5Mb8 /ePlnGP5itXTNT+2TS2zzwSXFvFEZ44lYeWzqTznsew6jvWBbeMLqeSztBdaW1/LqT2s0C78pGrM NwGc5+TPPHIrSvdeu10jVNUsraGW3s4pPKEjlTK6Ehzx0UEEepI7DBrP8R2WvahdO1o979mRIJI1 tJ1hJIkBccn5iVB67cY6nNaeo+IW0zUdOhuLdkgvIZHPBeVXUKdgRQc8EkkZ6fjU1x4iskPkW08U 91JAZbdNxCS/KWUb8EDIGfXGTWZo3ii/1rUobeC2iiRLeKS5LxScl4t/yPjbwSoweSMkdKg0XxZq moJMpgs72dIpm8mz3KYnRtoVyxP3uSOn3T1ptx4s1W2s5rl30zyLeSBJJysi7d77WDRk7kKgqeeu a0BrepiyS/eK1Fvd3UMVomG3iORwu5+cZwc4HTvVbTvFV7qLaRGqW0U1zM0d0jK2QoVyHj5+6fLY c9/oaTVfF08FrNNpsllcLHFcSGV1cIPKljQqefRzk9MircWs6ndaXe6rbfY2s0t2ezJVt0rKuSzc 8KSGwOuMZ9Kq6T4skutJudQu9Q0swxmJFlt0kISRwCUYEnJwyYIPUn0rcsb+Wa4nsrlFjurYKzhO VZGztYfXaeDyCD7E6FYnjD/kWrj/AK6Q/wDo1K2qWiiiuS8PeJNFsdJ+zXWqW0MsdzcB0d8Ff3z9 a0/+Ev8ADv8A0GrP/v4Koajrvh+/utPnXxJbQCyn87YpVhIdpXBz0GGbp61ltLoofzIfGkUbi+kv FOyI4ZlK45HQAmpprrw9Na7P+EqhW5e5iuZrrKFpWjIKjBGABgdPT3qWDWNJsdVR7PxRZrpzvJJN auVOGYfwHGQNxz1wMYxzwy+u/D99cXTP4uC216V8+18xShVVAwuRlM4ySOtVpk8MT2d2knia1a7u ZzKt8Y4vOhyQdqtjoOg9BUupXGhalJeu/i+KL7XbxQMFWP5QjFgRkdSWb8/atNPFOmDU/MbxFYtZ C3C+XuG5pc/ez2GO3v2xzm3FzoM7Xsi+Loopbm5W5ilUR7rdlUL8vHdVAOff1pJLvSJb97w+NYg0 scSSDyoudmcEHHynLMcjpn2qXTNY07S7iKNPFlpcWfmTSz+bsDu7tuAGAMYJY598U2/n8L6nNqbX fiO3ki1GBYfKyo8naGwytjORubr60PqumwX815p/iu0V7jyEZJdhVI485xxkkgt37+1MjudCjtrO H/hL4iLW+a8DER5csWYqeOmXbpzz7Uo1XRW0vUNCbXbaK1ufNMd0kilgJGZnUqe4LHB6Yx3FbUHi rw9HBHHJrtpKyIFLlwNxA64HSs/UtW0C/wBRt7yPxRb25t4ZYwi7GB3gAnkdsD8qyDaeGwbGSLxh Ek1lGsayskTkhUKDqPlG1jkDAJ561f0G90DQ/Px4shuhLHFGPM2LsEa7V6DnjHX0p9rf+HoPDcui t4qjcSLIPtKyKki7ySSNvAIJODUE82hXB82TxijXHmQkTHyydkT70TGMH5jkt1NQ3l5pMcjNZ+J7 d7eS+hnFpmNUgxIrMynGegJx3JNWNPk8K2Q0x38RW88+mvIY5iVVnVwwKtjjA3kj/wDXWfcro81x Jb/8JVCYLiO5aS4/d7o2kkifaBjkHY3PatKa+0SSa9Mfi+GGG+iKSwose3eV2mQZH3j1PY8VXd9F l0qawl8axssiIgdUiUgLt5IA+Y4UDJ6CtHTfEei/bbnUrrWLSOa4jjiWLzQSqIWILY43EuSQOBwO etaE3jLw9HC7rq9oxVSQvmjnjpXIN8TNC8WaBNaRO9pfGSH/AEab+L96n3WHB/SvS6WiiisXwn/y AE/6+bn/ANHvW1RRSUUUUtFFFJS0lFLRSUtFFFJS0lLRRTJoxNC8TZw6lTj3Fcbf+EtE8M+FLiPS rFImZ4d8x+aR/wB6nVjzW1DNfX9/q3kXXkC2dbWFSu5VbartIRxk4cAA9NvfNUhql6fCmka285Mu IGuEUALMJCqsMdBywI+ldMvGc06isXwp/wAi+v8A18XP/o96ln1jytUnsBZXErw2v2repTa4yQFG WzuyD1496oweKmuWhS20S/laa0S7AVoRiN84zl+vHQVPL4jj860Sx0+61D7ZE8sbQNGoAQgMDvZc EFhx/hWhp19DqdjFd2+fLkBwGGCCDgg+4II/Cs618TQXl5BBHZXfl3ErRRXG1TGSqljuwcp93gMA Tnirtnqtre315aQNmW1YLJ05z6fQgj6g0l9qttp/2fzN8ouLlLdfKG4Kznjd6D3/AMavSMRGxVSx A4UHk+3NYuneJF1MWn2fTrw/aUMr7vL/ANHTOAX+b+LkgDJwDTtP8QPqF2IBpF7DGZZYvPcxlA0Z IbO1iQMjGcYzitZXSQHY6tjqVOfesS58V2ttHqLG1uJJtOnSGWBWTed23a4y2Np3jvn2rdEqZVGY K5H3CRmqN1qgtNVstPNrNI17v2yKV2JtGTuyc9PQGq1p4hhu4I3+x3MU0s7wpbttLnYxVm4YgKCD yT29xmtqHiRksZ5LC3bzYr8WT/aEPDYBLBMguORgAgnPHvFpXiSSPw1fahqki3M2nyzCdLSBgyqr sANpJ7AHPp17mugFzB5JlM8YRDhnLjCn0J7Gsi88VWNncXFs0UzXEEyQrGdqeazKXG0sQMYB5JAz xUl54ga1ks4xpN9K93btPtXy1MYXbuDBmGCNw4Gahj8WWc8iG3tLue3eWKL7RGgKhpCNuVzuVec7 iAPenxeJkmlaGHTLyScXT2/lAx7js+9J97AQcDJ5yQMU6DxRZXFzZQCKVDfRSvbs5UB2RtrJ1+9z kdsd6SPxLC2gJrb2dzHbtuyjFN6gEjOA2DyOxpt34rtLNdUDW07zaWyiaBSm9lYAh1y2CvPsfatC 71KKySN7gMqsQHIIPk8DlueBkgEjpkduauqQVBBBB6EU6isTxf8A8i1cf9dIf/RqVONIIm1Ei5lj ivmV8RHa6OBtZg3uFTjtg+tVx4bji0eDSYLmf7LHNG7LM5kYohBCBjyBlV/I+tbQzk5p1FYvhT/k AL/18XP/AKPeqWseG5NW12a7uLS2nt1sDDAGndG83JPIA4Xnrk9OlRafpXiHTbi0ljtdPl8rTYbN t1064ZCcsP3fI59qZdeDWuf7OspRHNZ20Fwsk3mvHIskhDblC9gR3bofbnV0RtQh36feafDBHaRo qXEDkpKec4UqMdjxkc4zxWfFo2vJdi926el4iyk3ELMn2jIYIjrtxgEqS3JOwcc0zT/DOoabLp9x CVllKOmoLNeOyEMMkRjb3fDZOMYx3ptl4Z1Cw8Mabp8FtZJcW95HPMBO21lV92Q23JJGByK6Czub u4a7Ell5PkyskBZziZQB83TK85HfpkZrB0HQdY8P21mlpBZZk3f2hH9pfa7Z+WRPk+9jrnAwAOwI bpvhzUbPU7u8fTtPEty8/mTC7kYvHI+/Zt2gA8Abs8ehq14VsbzRLK30WTTYYo7e2DyXEMpZWk3E Y5UEkgZz26elVr7wte6i+oSuYIZJL1Z7Z0kLbo8RqyuNvGRGDxnk+2aml0+70/xPe61DpUF0bvyI IysreYoBIdjlcKMH152+9Wdd0KTWNV0xpYIJrK2aRpg8rI2WXA2gDn8xWbo+mXXh67tpr2CKO32T W6m3dpFi3zmRNxIBxztzzyB61taNZXlpcao10sKrdXhmi8uQsdu1V+bIGD8ueM9ak1+xudR0G/sr QRma5t3hXzXKqNwxkkAngH0rnp/CeoSpewx21lBaymB44I7hhkqhVhnZ8pyQd2CTt565Fez8Ka4b yyfUbPTLiOCSAyM1w0jMI4WjJw0fJO4N17fjW9rOgtq+uadLcW0E1jbRyiQPKyvubbggAc429z39 qrvompy6skzJYokVyHhuYSUljhBH7oqBh8gFeSMBu+KgtdC1jTru81KzgshfXN8zuGuXCTQHkK3y cMO2Bxk+4NXRdFu9R0/SvtEMaWq2txFP+9ZZUdpQwKjb2MY5yOtVvEXhzUbbwlYII4LmXThKZpA7 BiHBB2KFwSd2e3TA61pan4XvtVfV2YwQvcTpJaukpJwEVGVxt4BC9s847gGibSn0+41+VrOHz9af y7XyXZ5HzHtIbIAUZG484/IV02nwNa6dbW7kFoYkRivTIAHFWKKxPGH/ACLVx/10h/8ARqVtUtFF FYvhP/kAJ/183P8A6PetnNLRTSMmlFLSHkUgXFOoppGTSikKkkfWlpNvvQFINOoooopKRQR16+tK wJHBwaAMUhGaUcClorE8X/8AItXH/XSH/wBGpWo13bpO0LTIJFQyMpPIXOMn0FNGoWjeTtuY288k RFWBDkdcHvVgEHpS0V5PqXxOXwho6WFvpc9xdtPcFZZVKQj9+/Q/xfhXc2vimOW1hkk0zVS7xqWK WEmMkduOlS/8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8 JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf 4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8A wXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAv V/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4Uf8 JPD/ANAvV/8AwXyf4Uf8JPD/ANAvV/8AwXyf4VleJdeiu9EkgXT9TjLywgPLZOij96vUkYFWo5bK N/Edzqih4o7lRJuQsTEsSFVwOSNzPgepNZgNtJ4UkvrRoxJJqUc0UcIwIGLooVRjg+X1x3ZscV2y 4ycU6iuc0PTbHVfC4tdQtIbmFri5ykiAj/XvW/FEkEaRxjaiKFUegHSpKKKKKKKKKKKKKKKKKKKK KKKKKKKKxPGH/ItXH/XSH/0alaa2UC3z3qqVnkjEbsCfmUEkZHtk4+ppLixt7qaCWZS5t38yMEnA bGM47kZOPrVgDFLRWL4T/wCQAn/Xzc/+j3rZNJk56UAtQCT0pRSZNAJzSnpxSZPSkJPb1pc0mWx0 pcmjJoy2OlGTijLUZb8aMmjJ9KMmjJzQCehpMtS5ajJJpR0paKxPGH/ItXH/AF0h/wDRqVtUtFFF YvhP/kAJ/wBfNz/6Petk9K4jXRjxZfi2j0+SRtH/ANIF1cNHhNzZOAD2AyTjtzVHSoPDUt3Y/wBo S2Wz+xLZh5k4HzEtkjnr+tJfrLdvor3Vla6hffYbpzb3kxjaRFdCh4BJbbnGR3auu8M3EEmjW0EO ox3skcYLkPllzkgEdRjpzzxXN6QNLl1u0nhu1u0llmJkWRkmzscH7Qh4ZQNwD8clRjByYPCTabHb 6XJqslosf7z+ymE+Uzuy+cn/AFmQPUAcDnOeq1Ys+taLCzMsTTyMRnh2WNiq4+vzZPHy+uK5SVNF Ohqsslr9n/4SRlbMwC/60ggnP9zHHpV5tQtdLv4odO+xvpD3lrHHvkzGkrF9/lHOCR+7JGcDJPUm t7XLqVvDtzcaZL5j4ADwEMQNwDkEdwN3TkYrB1Cz8OR6Vq9xps2Y10yUOIpibdSeQSc4EhKjvnj6 VkSppkfhHUVYaVFPJLbFUtrwtEyhkALN/CSWcHgHHrirFzpentoWvG+itbSSxikaKyinby4WEZxK CcZ3bl5xgEY65rW1PR9MtPCsMtlCigXVtcRsjkhWaSMEqc8Aj045PrS6u32zXZbvT9tzcQaPLJZN GQ4Eu4gFexPalgtPDbTiWzuC7C1lNyElLRsGUbmmz0bjqcHrXMacNPTwRqbzDTY5JNIQxm2uy5kw m7dJz8r7yO2c8ZNa1lpenzyahBqFvZWsVvCJktILhmhlwpInyduRhsdwMDPao5dO0q3+HunzwpbZ vJLF2M1wRHJIWRWycnGRuBx78VDdR2yeH7qG6WxtZE1S3Uae9wVigIkVT8xAO113EkDoT1wavWAs DaWFpemzj05jO15HDOWtlnypjXeT0xuIGcZHrgUajBBN4Z11IVElhaOr6eysSqMEG4ofQMW9vStm +Wy1HxTpjSGK4hitbpwQ2VV1eIZ44yMke3NctosHhyVdCW/exaI2FyT5s4wWEyY6nk8t+ta8OrX0 SaZp8b2pg1G8uII3vHbcYFDFCo6tlQBknuPWtPws1tZ2U1ijxx4vrpYYt/O1ZTwoPYfpXQDpS1ie MP8AkWrj/rpD/wCjUrapaKKKxfCf/IAT/r5uf/R71tVE1tA7s7QxszLtZioJI9D7Uw2FkxBa0gJX pmMcfpUphiaVZTEhkUYVyoyPxqtBptpbXk93Dbok9wAJHUckDOB+ZJ+pNTrbQK5cQxh2XaWCDJHp 9KabK0KKhtYSqcqPLGFPt6VBd2kFzd2jvIUntnMsW1hk8bW4PUYbB+tRNNoiRTLLLYCOB/3oZkAR jx83oT70jX+hK6Wn2vTgyNhIfMjyrey9jS2E+i6fYpFa3dokBlZQRMpDSE5IznliTk9+auGC0ht3 UxQpDyzgqAvuT2qC1TSrqAi0WzmibDERBWU9QDx9D+RqVxZSQ+e/kNHIoXzG2lWGeBnuMniqGoWd pqyrpq6gYvszpJLb27JuwpDKGBBKjIHTFQvpulaLe2l4L9dNSKNoRE0iLHMC2453DJO4k5BBq7Fe 6N5W6O7sTHcuU3LImJm7jj7x5/WpooNNIMcMVqRKgcqir869jgdR71D/AGjoj3Atvtlg03+pEXmo W9NmM5/CpYpdLul+zRPaTCNiPKQq21h1GOxGf1qSSGzmlZJYoJJCoZlZQTjkAn26/rStZ2rWrWpt ojAwwYig2n8OlZc3hq1k0l9Lgubu2tXYbkWTf8uMbBvB2r04XHSnjw/axXdrcWsktr9nMu5E2kTe Yys4fcCeSo5GDV7+z7JhhrOAqOgMS8fpT5raKXBKLvUYR9oJT3GRxVDT9AtbAwyM0l1cQySyrPNj cGkOXOAAAeccDpWqOlLWJ4w/5Fq4/wCukP8A6NStqlooorF8J/8AIAT/AK+bn/0e9bVFFFFFIelc HeapfPqUviWEf6HYT/ZvLKyiVowcOAm3DbiQwOcfKmfu0/WFhK67Yi2LXGp3EMtsggJ85QkQznGO qt1PY1o3Gn6UfGlvbNp8BWSymdh9nypcyo2S2MZO1j1zxWDGGaO1l8yI2X/CROy2/wDZ7hxmViGL emCDnb0IGa6rVr6xv/DNxcok97bE7ClspMhYOFOAe4YdD6VzgvBZw6gunJun1GSG1iv1tni3HDD5 1UcMg/jAAy444p/9p3ui6Td6UzJHNYXEBTyoHmTyXkBMakqMlRnkDAG3uKtNq+jReJ3nIa1t9Ojm MkgtnUO5wXZm24KjPXuc9hWp4ut7SbwxqE8tukzpZyrCfL3sC64G0YJyTgcVkaxFpUc0TRW5tftF p5hnFj5tvKGIGx0AyGPXI2njk8Yqaw1hNL1eysLwCwtm023SK3MLHyZSdojMuDnsOTTmsNKXxjPb /wBnRbF08SbVt+C4lZyQ2MbskHrnNYhuRZ2Ul/pMM0dxbac3lPcWJ8+zyU2xMFwJN3QHBI25JOa6 jDDXtEb7QbiV7W4LSsgTeh8s5wOhyVwPQnnPXoaKKKKKKKxPF/8AyLVx/wBdIf8A0albWRRkGgEH pS0Vi+E/+QCn/Xxc/wDo962qKKKKKQ9KTBowcUAH1pMH/JpkNvHbxLFBGscajCqgwBUm0+v60YPr TJoEuIzHMiyISCVYZBwcj9RT8EdABRg0ySCObZ5sav5bbl3DOD6j35p2D/8AWpcGoTZwtereMmZ0 QxqxJO1ScnA6DOBk+wqxRRRRRRTJZFhheV/uopY/QVyOoeKdG8S+FLiTSr6OYrJDviziRP3qdVPI rTSW6vLzWpY7mWI2rC2iSNd+3CK7MFPBY7wBnptHqRWaupXo0h79rm4L2GoJFsnASSSN9gKyqoCg 5kyMDoF9TXXAYzTqK5Pw74b0W90n7TdaVazTSXNwXd4gSx85+prU/wCER8Of9ASx/wC/C0f8Ij4c /wCgJY/9+Fo/4RHw5/0BLH/vwtH/AAiPhz/oCWP/AH4Wj/hEfDn/AEBLH/vwtH/CI+HP+gJY/wDf haP+ER8Of9ASx/78LR/wiPhz/oCWP/fhaP8AhEfDn/QEsf8AvwtH/CI+HP8AoCWP/fhaP+ER8Of9 ASx/78LR/wAIj4c/6Alj/wB+Fo/4RHw5/wBASx/78LR/wiPhz/oCWP8A34Wj/hEfDn/QEsf+/C0f 8Ij4c/6Alj/34Wj/AIRHw5/0BLH/AL8LR/wiPhz/AKAlj/34Wj/hEfDn/QEsf+/C0f8ACI+HP+gJ Y/8AfhaP+ER8Of8AQEsf+/C0f8Ij4c/6Alj/AN+Fo/4RHw5/0BLH/vwtH/CI+HP+gJY/9+Fo/wCE R8Of9ASx/wC/C0f8Ij4c/wCgJY/9+Fo/4RHw5/0BLH/vwtH/AAiPhz/oCWP/AH4WmTeDvD0kEiJo 1irMpAbyF4OOtcafhjofhLQJr1N95qAki/0iXgLmVPuqOB+pru/7Fgaa/wDMYvBfFXeHptcDBYN1 yQE+m0YqOXw9bNYpZRO6Q/aFnm3MZGn2kHDMxz1C85z8oHStQDBPvTqKxfCf/IAT/r5uf/R71tUU UUUUUUUUUUUUUUUUUUUUUUUUUUVieMP+RauP+ukP/o1K2qWiiisXwn/yAE/6+bn/ANHvW1RRXLa1 4huNK1u8tpLtY4Rp4mt1WzeUrISwyxXt8vQ469eKjsb3xDqN1BEmp2sW7TYLts2edzuWBH3+B8v6 1XvvFlzt026OoRaZa3VtLJIWs2uNrxuq9VPAO49R2HrXT6Vc3V1pdvPeweRO6ZdMdD/Tsce9Yllq muy6zFZ3UlvbmRpC8MkDAqoU7TG+dsgzjOcHAPGOaj8Ma1quvxW0hu4FWBc3mbYq0zE8BAW4UAEb uQT06Gtu/v54dS06ygC5uZGMpIyVRVJJx2ycDPbNYb6prh0yFkv7ZZ5NXez8w2uQIw7ION3X5c5z 3xVpvEo0a4ew1d2uJw8SxS21uf3pk37RtBO05Qjrjp71raveS2WhX19CoEsFrJKgccbgpIyPwrJg vdau5jZQXlss9rDHNNLJbnbOZNxVQob5RhcE5J9qzNW1/XNPu7K1uNQtbOaeyRmC2Tzr9oLhCMhh hMsOTT9V8R6lYeILuyF/CGjWJrW0Fk7m4dlY+X5gOFyV4J6Z9qtrP4mPiIWTajZCPyhclPsh+55u 3Zu3ddvfHXtitLSry9k1nVbK7mjlS2aNoWSPYQrgnB5OcY68VV8R+KYNCvrO3eWFAx8248xwpEWd uVyeTk54zwh45FWry7vo/EmnWkU8a21xDM8iGLcxKbcYbPA+f07e9YSan4km0S01AalZp5twluw+ xkklrjy8/f4wMHvzV281fUdH1HTINTvojHNBMZjBZO5d1K7SApJUYfng/d681e8L6hd6l4ftr28l jllm3HckfljG4gfKSccCqNxqutw64tuzW8EMl0iRpLC22SLdyyyg434/hYDk4BNTWvimC48VzaQJ YdgBjjw43mVBlwRnOMHA4/gbnkVFeeJHvNPu73SrgQQ6ezrM9xat+8kU48tckdT39x746G2eWS2i eaPy5WQF0znaccj8KlorE8Yf8i1cf9dIf/RqVtUtFFFYvhP/AJACf9fNz/6Petqiisq50SK41C6v DeXSPdWv2VlR1CqvJBX5fvcn161Uj8KRQyRvBq+pxGO2jtvkkT5o0ztB+TryeRirJ8P2RureVGlj it7Z7ZbZGAiZHxuyMZJOBznt9aXSdMuNMmmVtQnuLTai28Mu0mIAc8gA9wMHPCjnk1DY+GbSwaEx XV46W4byI5ZQywswILjjOcM3UkDPSmQeFoLaHT44NRv4zYBlR1kTc6sc7XO3keg4/Pmreo2U0+pa ZdwhSLSZzIpOCVZCv6Zzj2qm3hWBrJLUalqACXjXiyCRN/mEkn+HGMknGO9SP4at5PIZ728aaK4S drguu+VlztDfLjaATwAOp7k06bTr+TwreadNdfa7ue3mQSPhRlw2BwOgyBnHQZpsekNe28E1x9o0 678sRzpbTg+Yo6KzY5+owRk4NLceG4Zb6O7t7+9sWjtxbolsyBAgOcYZT/kUHw1ZmW7Zri7YXaRK VMgPlmP7jKcZyDzkk5PXNWIdIji1ZNSN3cySrbC3Kuy7WXOdxAUfMTz/AErOs9O1d/El1qMjCyt3 lXMSushnVUKjPHy8nPrxV7+w4ftWo3JuLgyX6hWBZSIsDaCny8HB75pn/CPQCysreK9vIpLCMxQ3 Kuvm7CACpJUg52r27D3pZvD9rJpVvpsU9zbxW8yTK0TgMzK2/JJB/i56dfap59MS41a31I3NxHJb xPEsaMuwh8ZJBGc8L3/hHvVbSdEl0iWGKDUZ5LGGFlEUxVizs+7cSAOnQfU+lNHhm0+0vMLq82SX JuWhMoMZlzkNgjIwQCADjjkHmmp4XtY9MtLBbu8C2kyzpLuXzGKtuAZtvIzUU3hG3lh8oatqaL9p kufklQfO/X+DsckehOfTGpZ2l1bXdw8l68tuyxrDC+D5YVcFs4yST169Per1LWJ4w/5Fq4/66Q/+ jUrapaKKKxfCf/IAT/r5uf8A0e9bVFFFFJijAoxRgelFGKK5bWbPUm8QWsMGv31tHfNLhIlj2xbY wRjKkn5gScnvioJLvVbbVY5JtRlkge6KDyRHJFOFDfugODHJwAckglT0rWg87W/DlhcW99eWXnRR zF12GUqVztJIIycjJA7ViWi60+h6bdDWbu5a9hjnlh3xJP8AcBbyiVwRzkqR6cir2ma9commWUq3 GpXF8Zt10qLEsexyGDLngqDjAzyvXmtTw9dTXelhrl/MmilkiZ8fe2uQDkcE7QMkcZz9K08UYowK MD0oxRgelFFGB6UtFYnjD/kWrj/rpD/6NStrvijNLRRXnQ+Ivh/wnoQgu7g3F6Li4/0WDlx++f7x 6L+NdVb+LvD0sEcra1p8ZkQMVa6TKkjp1qX/AISrw7/0HdO/8Ck/xo/4Srw7/wBB3Tv/AAKT/Gj/ AISrw7/0HdO/8Ck/xo/4Srw7/wBB3Tv/AAKT/Gj/AISrw7/0HdO/8Ck/xo/4Srw7/wBB3Tv/AAKT /Gj/AISrw7/0HdO/8Ck/xo/4Srw7/wBB3Tv/AAKT/Gj/AISrw7/0HdO/8Ck/xo/4Srw7/wBB3Tv/ AAKT/Gj/AISrw7/0HdO/8Ck/xqlc6t4Sur62vp9Z09p7QsYGF8Btz14DYPHrVZJfA0c7zR6jpyPI zu22+wN7Elnxuxu5PzdR60trdeD7ECO2121jgFv9mEP9pZQJnPALcHkjI5xTTL4Ga0tbQ6lp3lWS lbb/AE/5ogeu1t2Rxx16cVMl74MjuLOdNV09ZLJWWAi+AC7vvZG7DE9yck9asafrnhfTrQW0Gu2H lh3f5rtCcsxY9/VjVn/hKvDv/Qd07/wKT/Gj/hKvDv8A0HdO/wDApP8AGj/hKvDv/Qd07/wKT/Gj /hKvDv8A0HdO/wDApP8AGj/hKvDv/Qd07/wKT/Gj/hKvDv8A0HdO/wDApP8AGj/hKvDv/Qd07/wK T/Gj/hKvDv8A0HdO/wDApP8AGj/hKvDv/Qd07/wKT/Gj/hKvDv8A0HdO/wDApP8AGj/hKvDv/Qd0 7/wKT/GsnxP4i0W70KW3tdXsZppJYQkcdwjMx81egB5qZryS2l8QasIHubi0kW2gjRS3yiNGAwMn lpMsR2A44rEsrrOkX1yl3dXFzp2qwlJrhHQnesSuMMBhSWc7RgDjjpXfjqadRXE2vg3QvFPhtF1O xR5BcXG2dPllX9+/Rh/I119vax29vHAqgrGgQEjnAGKk8tP7i/lR5af3F/Kjy0/uL+VHlp/cX8qP LT+4v5UeWn9xfyo8tP7i/lR5af3F/Kjy0/uL+VHlp/cX8qPLT+4v5UeWn9xfyo8tP7i/lR5af3F/ Kjy0/uL+VHlp/cX8qPLT+4v5UeWn9xfyo8tP7i/lR5af3F/Kjy0/uL+VHlp/cX8qPLT+4v5UeWn9 xfyo8tP7i/lR5af3F/Kjy0/uL+VHlp/cX8qxvFsS/wDCOT7YxnzIeg5/1qVow2MMF7c3Ue4Pc7fM XPy5XIyB2JBAJ74HpTLnTLe7CiSPCrOs5CcCRh03f3ug6+g9KuLnvTqKztCsZtO0tbacqXE0z/Kc jDSMw/RhWjRRRRRRRRRRRRRRRRRRRRRRRRRRRRSEZGKAKWiiv//Z ------=_NextPart_000_008A_01CC63E6.FF820240-- From sfluhrer@cisco.com Fri Aug 26 06:55:50 2011 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 0A26B21F8745 for ; Fri, 26 Aug 2011 06:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1THmL5PpvwG for ; Fri, 26 Aug 2011 06:55:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42821F86EC for ; Fri, 26 Aug 2011 06:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=12400; q=dns/txt; s=iport; t=1314367022; x=1315576622; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=YGOHkytU7K0J+vOif76AVCJr85JRBnSLOldsIDMaOII=; b=NL0cJvAKqQlf8911qgAEAejvY6cmcWkMeL3hqLZcWVuaWTTLuap46dBp mtyge1kTFDMiFzPZfmvbsi2pFRUaMEloXzJLPpmyKD/XNo/rE7HNs+hR+ fRZcwSy8Ja7Y/6x+w/8Shc4TVkZrlvMPAuALcJsqKs7ANGpuKx2iYQdqz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEAANylV06rRDoG/2dsb2JhbABCmDuPXXeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGAR4JCAIEARIIEQIHh1AEmwsBnxyFbGAEhzMviSiHJoRhhyk X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16800650" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 26 Aug 2011 13:57:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7QDv06M022019; Fri, 26 Aug 2011 13:57:00 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 06:57:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AVmT AhtP B0Yv CU3E Efmi GpHL GrHX KidG TP/T VIle ViI/ WtlL XkDw bGz/ c5FY h7++; 3; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAeQBhAHIAbwBuAGYALgBpAGUAdABmAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwB5AG4AaQByAEAAYwBoAGUAYwBrAHAAbwBpAG4AdAAuAGMAbwBtAA==; Sosha1_v1; 7; {6D94B606-45D1-4EC5-95CE-6D07B37A6990}; cwBmAGwAdQBoAHIAZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 26 Aug 2011 13:56:50 GMT; UgBFADoAIABbAEkAUABzAGUAYwBdACAARABIACAAawBlAHkAcwAgAGMAYQBsAGMAdQBsAGEAdABpAG8AbgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQA= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {6D94B606-45D1-4EC5-95CE-6D07B37A6990} Content-class: urn:content-classes:message Date: Fri, 26 Aug 2011 06:56:50 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBAAADbL1AAFla60AAE7tawABFAY4A= References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Scott Fluhrer (sfluhrer)" To: "Naveen B N (nbn)" , "Yaron Sheffer" , "Yoav Nir" X-OriginalArrivalTime: 26 Aug 2011 13:57:00.0712 (UTC) FILETIME=[06FC0280:01CC63F8] Cc: ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance 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, 26 Aug 2011 13:55:50 -0000 > -----Original Message----- > From: Naveen B N (nbn) > Sent: Friday, August 26, 2011 1:37 AM > To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav > Nir' > Cc: 'ipsec@ietf.org' > Subject: RE: [IPsec] DH keys calculation performance >=20 > Hi Scott, > if we can take care of the "Forward Secrecy", > When using Asymetric keys from certificates > To negotiate symmetric keys, then certificate > Can be used in place of DH Computation. >=20 > "TO maintain "Forward Secrecy", we have to change the keys from > time to time based on the key length, which can be achieved by re- > negotiating" No, you'd have the change the asymmetric keys all well; with the private = key, the attacker can still recover the session (symmetric) keys. Now, it's not impossible to change the public keys; however, it does = involve generating a fresh private/public key pair. With RSA, at least, = that's a lot more expensive than doing a single exchange (or, for that = matter, several dozen simple exchanges), and so if the point of this is = to reduce the total amount of computation, well, that rather misses the = point. >=20 > If this is possible then I can present a draft for the same. >=20 > Thanks & Regards > Naveen >=20 >=20 > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Thursday, August 25, 2011 10:18 PM > To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- > users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; > 'ipsec-tools-devel@lists.sourceforge.net' > Subject: RE: [IPsec] DH keys calculation performance >=20 >=20 > > -----Original Message----- > > From: Naveen B N (nbn) > > Sent: Thursday, August 25, 2011 12:34 PM > > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; > > timo.teras@iki.fi > > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- > > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; > ipsec- > > tools-devel@lists.sourceforge.net > > Subject: RE: [IPsec] DH keys calculation performance > > > > Hi Scott, > > > > Please find the queries and comments inline .. > > > > Scott>- Transporting keying material lacks forward secrecy. = "Forward > > secrecy" is the property that, if some actually recovers the entire > > state of one (or both) of the sides, they still won't be able to > > decrypt a transcript of a session that had happened earlier (because > > the state needed to decrypt it was zeroized when the session was > > closed). With key transport, it is impractical to zeroize the > private > > key used during the exchange, and with that, the attacker can = decrypt > > the keying material, and from there, rederive the session keys. In > > contrast, with DH, as long as both sides zeroize the private > exponents > > and shared secrets (along with the session state), the attacker does > > not have enough information. > > > > Naveen>> TO maintain "Forward Secrecy", we have to change the keys > from > > time to time based on the key length, which can be achieved by re- > > negotiating > > new keys with the communicated Symmetric key. > > But if you say that the first session used is to derive the > > private key of the peer, then Asymmetric key should never be used = for > > deriving symmetric keys > > Or to protect data. If Certificate are still used in TLS for > > negotiation of Symmetric keys, this is a major issue because they = are > > used in important places. >=20 > I believe you misunderstand; we're not using the asymmetric key to > "derive" the symmetric keys, but instead just to transport it. >=20 > Here's the scenario: > - Side A picks some keying material ("premaster secret" is TLS's > terminology for it) > - Side A encrypts it with Side B's public key, and sends it to B > - Side B decrypts it with his own private key > - Both side A and side B use that keying material (and possibly other > information that has been exchanged) to derive the real session keys >=20 > The problem I was discussing: what if, after the session has been shut > down, the attacker recovers side B's private key? This private key is > unlikely to be zeroized along with the session (at least, with the > current CA infrastructure); using this private key, the attacker could > decrypt the encrypted keying material (just like B did), and rederive > the session keys (again, just like B did). >=20 > > > > Naveen>>So, Certificates should only be used for authentication in a > > protected environment is it. > > What could be the life time of the RSA keys then, how long will > > it take to derive a private key from a public key with the best > > available resources. > > Then it comes down to DH method being the best secured > > available solution for negotiating Symmetric key on the fly, without > > having shared keying material with the peer. > > > > Scott>- IKEv2 allows other types of authentication beyond > certificates; > > using public key encryption as a step in generating keying material > > would imply that we would need a different mechanism to generate > keying > > material for other types of authentication. This is certainly not > > impossible (in fact, IKEv1 did have different mechanisms based on > > authentication type, although for different reasons); the IKEv2 > > designers decided to unify that. > > > > Naveen>>May be Ikev2 designers feel that the intruder may selects a > > week authentication type if exposed in plan message, But I think we > are > > authenticating the INIT_MESSAGE in IKE_AUTH > > Message, so they could have provided a authentication method > in > > IKE_INIT message. > > > > > > Thanks and Regards > > Naveen > > > > -----Original Message----- > > From: Scott Fluhrer (sfluhrer) > > Sent: Thursday, August 25, 2011 6:57 PM > > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > Subject: RE: [IPsec] DH keys calculation performance > > > > > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > Behalf > > > Of Naveen B N (nbn) > > > Sent: Thursday, August 25, 2011 6:48 AM > > > To: Yaron Sheffer; Yoav Nir > > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > > Subject: Re: [IPsec] DH keys calculation performance > > > > > > Hi , > > > Can we not use the existing RSA keys to get the shared secret > without > > > using the DH computation > > > Because of the calculation that are involved. > > > Let's say A wants to initiate a session with B. > > > Let A get the Public key of B from CA by sending a protected > message > > > using public key of CA. > > > Use the obtained public key for sending the shared secret to B and > > same > > > from the other > > > End has well, this will ensure authentication and avoiding DH > > > computation. > > > > > > I feel that certificate can be used for authentication and as well > > has > > > negotiated Symmetric key using the > > > Concept of Asymmetric cryptography which is one of the good > features > > > of certificate. > > > > > > Why in Ikev2, certificates are just used for authentication and = why > > > they are not used for > > > negotiating Symmetric key instead in place of DH computation. Is = it > > to > > > avoid use of Trusted CA negotiation. > > > > Well, you certainly can use certificates (with public key encryption > > keys) to transport keying material; indeed, the ciphersuite of TLS > that > > is in general use does exactly that. > > > > However, it does have a few drawbacks. Here are some of the reasons > > that the IKEv2 designers may have chosen not to use it: > > > > - Transporting keying material lacks forward secrecy. "Forward > > secrecy" is the property that, if some actually recovers the entire > > state of one (or both) of the sides, they still won't be able to > > decrypt a transcript of a session that had happened earlier (because > > the state needed to decrypt it was zeroized when the session was > > closed). With key transport, it is impractical to zeroize the > private > > key used during the exchange, and with that, the attacker can = decrypt > > the keying material, and from there, rederive the session keys. In > > contrast, with DH, as long as both sides zeroize the private > exponents > > and shared secrets (along with the session state), the attacker does > > not have enough information. > > > > - IKEv2 allows other types of authentication beyond certificates; > using > > public key encryption as a step in generating keying material would > > imply that we would need a different mechanism to generate keying > > material for other types of authentication. This is certainly not > > impossible (in fact, IKEv1 did have different mechanisms based on > > authentication type, although for different reasons); the IKEv2 > > designers decided to unify that. > > > > > > > > Thanks and Regards > > > Naveen > > > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > Behalf > > > Of Prashant Batra (prbatra) > > > Sent: Tuesday, July 26, 2011 6:33 PM > > > To: Yaron Sheffer; Yoav Nir > > > Cc: ipsec@ietf.org > > > Subject: Re: [IPsec] DH keys calculation performance > > > > > > Thanks Yoav and Yaron =A0for the suggestions. > > > Even I was thinking and tried generating and storing the key pair > > =A0well > > > in the beginning,.=A0 This helped to some extent. > > > > > > The secret calculation is also very expensive, but this has to be > > done > > > in midst of the exchange only. > > > > > > Regards, > > > Prashant > > > > > > > > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > > Sent: Tuesday, July 26, 2011 4:47 PM > > > To: Yoav Nir > > > Cc: Prashant Batra (prbatra); ipsec@ietf.org > > > Subject: Re: [IPsec] DH keys calculation performance > > > > > > You might want to review > http://tools.ietf.org/html/rfc5996#section- > > > 2.12. > > > > > > Also, session resumption (http://tools.ietf.org/html/rfc5723) > reduces > > > the computational costs of renewing an IKE SA when a client needs > to > > > reconnect to a gateway a second time after some failure. > > > > > > Thanks, > > > =A0=A0=A0 Yaron > > > > > > On 07/26/2011 01:40 PM, Yoav Nir wrote: > > > > > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > > > > > > Hello, > > > > > > The DH exchange (Calculation of Public/Private key and the Secret) > in > > > IKEV2 Initial exchange > > > seems to be very expensive. This is slowing down the overall IKEv2 > > > tunnel establishment. > > > Is there a way to optimize it? > > > > > > Hi Prashant. > > > > > > I know of three ways to optimize the D-H exchange. > > > > > > First, note that each peer has to perform two operations: > > > =A01. Generate: create a random x and calculate X=3D2^x mod p > > > 2. Derive: calculate the shared secret S=3DY^x mod p > > > The "Derive" operation has to be done during the exchange, but the > > > "Generate" operation can be done long before the exchange. If your > > > problem is degraded performance at some peak, you can pre-generate > > some > > > values. This has a high cost in memory, but can be useful for > dealing > > > with peaks. > > > > > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * = (2^1 > mod > > > p)) mod p > > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x = mod > p > > > for 0<=3Dx<=3D2048 and store these values. After that, both the > generate > > > and derive operations become simple multiplications of the > resulting > > > values. This has a fixed cost in memory, but can accelerate = things. > > > > > > Third, you may want to look at the EC groups. The EC operations > > require > > > less computation. > > > > > > Hope this helps > > > > > > Yoav > > > > > > > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec From nbn@cisco.com Thu Aug 25 22:29:24 2011 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 6274721F8AAF for ; Thu, 25 Aug 2011 22:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B9arcvsrKLx for ; Thu, 25 Aug 2011 22:29:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 765B221F84DF for ; Thu, 25 Aug 2011 22:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=11066; q=dns/txt; s=iport; t=1314336638; x=1315546238; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=suqD+JnWfDWS8BfaA+73EICAgThIAy41gqlcJHoOlh0=; b=S31F9rOLr/OVH29R/360o67WwGnGsJGpO8OkFrALUgPJnpAjwxkw+INl d7IQnYmTUCZE4ryKNLKeHs7n6eiKUOFhF8tsDGQacAoBZUnRqXUV5bW2Q j2LeOgOQ/gGRElvXInxroJAmXze/MvPUFytZT9swFmrR/o1L+NEqT6GFq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAAE0uV05Io8UQ/2dsb2JhbABEmDmPWXeBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGAR4JCAIEAQoICBECB4dQBJspAZ8NhWxgBIczLYkqhyaEYYcO X-IronPort-AV: E=Sophos;i="4.68,283,1312156800"; d="scan'208";a="52075572" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 26 Aug 2011 05:30:34 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7Q5UXO6006531; Fri, 26 Aug 2011 05:30:33 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 11:00:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 11:00:33 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance thread-index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBAAADbL1AAFla60A== References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Naveen B N (nbn)" To: "Scott Fluhrer (sfluhrer)" , "Yaron Sheffer" , "Yoav Nir" , X-OriginalArrivalTime: 26 Aug 2011 05:30:33.0644 (UTC) FILETIME=[46E166C0:01CC63B1] X-Mailman-Approved-At: Fri, 26 Aug 2011 08:20:17 -0700 Cc: ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net, "Sastry SK \(sassk\)" , ipsec@ietf.org, "Prashant Batra \(prbatra\)" , "Saravana Ravindran \(sarravin\)" Subject: Re: [IPsec] DH keys calculation performance 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, 26 Aug 2011 05:29:24 -0000 Hi Scott, if we can take care of the "Forward Secrecy", When using Asymetric keys from certificates=20 To negotiate symmetric keys, then certificate=20 Can be used in place of DH Computation. "TO maintain "Forward Secrecy", we have to change the keys from time to time based on the key length, which can be achieved by re- negotiating" If this is possible then I can present a draft for the same. Thanks & Regards Naveen -----Original Message----- From: Scott Fluhrer (sfluhrer)=20 Sent: Thursday, August 25, 2011 10:18 PM To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); = 'ipsec-tools-users@lists.sourceforge.net'; = 'ikev2-devel@lists.sourceforge.net'; = 'ipsec-tools-devel@lists.sourceforge.net' Subject: RE: [IPsec] DH keys calculation performance > -----Original Message----- > From: Naveen B N (nbn) > Sent: Thursday, August 25, 2011 12:34 PM > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; > timo.teras@iki.fi > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; ipsec- > tools-devel@lists.sourceforge.net > Subject: RE: [IPsec] DH keys calculation performance >=20 > Hi Scott, >=20 > Please find the queries and comments inline .. >=20 > Scott>- Transporting keying material lacks forward secrecy. "Forward > secrecy" is the property that, if some actually recovers the entire > state of one (or both) of the sides, they still won't be able to > decrypt a transcript of a session that had happened earlier (because > the state needed to decrypt it was zeroized when the session was > closed). With key transport, it is impractical to zeroize the private > key used during the exchange, and with that, the attacker can decrypt > the keying material, and from there, rederive the session keys. In > contrast, with DH, as long as both sides zeroize the private exponents > and shared secrets (along with the session state), the attacker does > not have enough information. >=20 > Naveen>> TO maintain "Forward Secrecy", we have to change the keys = from > time to time based on the key length, which can be achieved by re- > negotiating > new keys with the communicated Symmetric key. > But if you say that the first session used is to derive the > private key of the peer, then Asymmetric key should never be used for > deriving symmetric keys > Or to protect data. If Certificate are still used in TLS for > negotiation of Symmetric keys, this is a major issue because they are > used in important places. I believe you misunderstand; we're not using the asymmetric key to = "derive" the symmetric keys, but instead just to transport it. Here's the scenario: - Side A picks some keying material ("premaster secret" is TLS's = terminology for it) - Side A encrypts it with Side B's public key, and sends it to B - Side B decrypts it with his own private key - Both side A and side B use that keying material (and possibly other = information that has been exchanged) to derive the real session keys The problem I was discussing: what if, after the session has been shut = down, the attacker recovers side B's private key? This private key is = unlikely to be zeroized along with the session (at least, with the = current CA infrastructure); using this private key, the attacker could = decrypt the encrypted keying material (just like B did), and rederive = the session keys (again, just like B did). >=20 > Naveen>>So, Certificates should only be used for authentication in a > protected environment is it. > What could be the life time of the RSA keys then, how long will > it take to derive a private key from a public key with the best > available resources. > Then it comes down to DH method being the best secured > available solution for negotiating Symmetric key on the fly, without > having shared keying material with the peer. >=20 > Scott>- IKEv2 allows other types of authentication beyond = certificates; > using public key encryption as a step in generating keying material > would imply that we would need a different mechanism to generate = keying > material for other types of authentication. This is certainly not > impossible (in fact, IKEv1 did have different mechanisms based on > authentication type, although for different reasons); the IKEv2 > designers decided to unify that. >=20 > Naveen>>May be Ikev2 designers feel that the intruder may selects a > week authentication type if exposed in plan message, But I think we = are > authenticating the INIT_MESSAGE in IKE_AUTH > Message, so they could have provided a authentication method = in > IKE_INIT message. >=20 >=20 > Thanks and Regards > Naveen >=20 > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Thursday, August 25, 2011 6:57 PM > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > Subject: RE: [IPsec] DH keys calculation performance >=20 >=20 >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Naveen B N (nbn) > > Sent: Thursday, August 25, 2011 6:48 AM > > To: Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > Subject: Re: [IPsec] DH keys calculation performance > > > > Hi , > > Can we not use the existing RSA keys to get the shared secret = without > > using the DH computation > > Because of the calculation that are involved. > > Let's say A wants to initiate a session with B. > > Let A get the Public key of B from CA by sending a protected message > > using public key of CA. > > Use the obtained public key for sending the shared secret to B and > same > > from the other > > End has well, this will ensure authentication and avoiding DH > > computation. > > > > I feel that certificate can be used for authentication and as well > has > > negotiated Symmetric key using the > > Concept of Asymmetric cryptography which is one of the good = features > > of certificate. > > > > Why in Ikev2, certificates are just used for authentication and why > > they are not used for > > negotiating Symmetric key instead in place of DH computation. Is it > to > > avoid use of Trusted CA negotiation. >=20 > Well, you certainly can use certificates (with public key encryption > keys) to transport keying material; indeed, the ciphersuite of TLS = that > is in general use does exactly that. >=20 > However, it does have a few drawbacks. Here are some of the reasons > that the IKEv2 designers may have chosen not to use it: >=20 > - Transporting keying material lacks forward secrecy. "Forward > secrecy" is the property that, if some actually recovers the entire > state of one (or both) of the sides, they still won't be able to > decrypt a transcript of a session that had happened earlier (because > the state needed to decrypt it was zeroized when the session was > closed). With key transport, it is impractical to zeroize the private > key used during the exchange, and with that, the attacker can decrypt > the keying material, and from there, rederive the session keys. In > contrast, with DH, as long as both sides zeroize the private exponents > and shared secrets (along with the session state), the attacker does > not have enough information. >=20 > - IKEv2 allows other types of authentication beyond certificates; = using > public key encryption as a step in generating keying material would > imply that we would need a different mechanism to generate keying > material for other types of authentication. This is certainly not > impossible (in fact, IKEv1 did have different mechanisms based on > authentication type, although for different reasons); the IKEv2 > designers decided to unify that. >=20 > > > > Thanks and Regards > > Naveen > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Prashant Batra (prbatra) > > Sent: Tuesday, July 26, 2011 6:33 PM > > To: Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] DH keys calculation performance > > > > Thanks Yoav and Yaron =A0for the suggestions. > > Even I was thinking and tried generating and storing the key pair > =A0well > > in the beginning,.=A0 This helped to some extent. > > > > The secret calculation is also very expensive, but this has to be > done > > in midst of the exchange only. > > > > Regards, > > Prashant > > > > > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > Sent: Tuesday, July 26, 2011 4:47 PM > > To: Yoav Nir > > Cc: Prashant Batra (prbatra); ipsec@ietf.org > > Subject: Re: [IPsec] DH keys calculation performance > > > > You might want to review http://tools.ietf.org/html/rfc5996#section- > > 2.12. > > > > Also, session resumption (http://tools.ietf.org/html/rfc5723) = reduces > > the computational costs of renewing an IKE SA when a client needs to > > reconnect to a gateway a second time after some failure. > > > > Thanks, > > =A0=A0=A0 Yaron > > > > On 07/26/2011 01:40 PM, Yoav Nir wrote: > > > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > > > > Hello, > > > > The DH exchange (Calculation of Public/Private key and the Secret) = in > > IKEV2 Initial exchange > > seems to be very expensive. This is slowing down the overall IKEv2 > > tunnel establishment. > > Is there a way to optimize it? > > > > Hi Prashant. > > > > I know of three ways to optimize the D-H exchange. > > > > First, note that each peer has to perform two operations: > > =A01. Generate: create a random x and calculate X=3D2^x mod p > > 2. Derive: calculate the shared secret S=3DY^x mod p > > The "Derive" operation has to be done during the exchange, but the > > "Generate" operation can be done long before the exchange. If your > > problem is degraded performance at some peak, you can pre-generate > some > > values. This has a high cost in memory, but can be useful for = dealing > > with peaks. > > > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 = mod > > p)) mod p > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod = p > > for 0<=3Dx<=3D2048 and store these values. After that, both the = generate > > and derive operations become simple multiplications of the resulting > > values. This has a fixed cost in memory, but can accelerate things. > > > > Third, you may want to look at the EC groups. The EC operations > require > > less computation. > > > > Hope this helps > > > > Yoav > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From prbatra@cisco.com Fri Aug 26 11:04:53 2011 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 9AFBD21F8B38 for ; Fri, 26 Aug 2011 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG1IJ4C1K6Uf for ; Fri, 26 Aug 2011 11:04:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 93BBA21F8B21 for ; Fri, 26 Aug 2011 11:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=4941; q=dns/txt; s=iport; t=1314381969; x=1315591569; h=mime-version:subject:date:message-id:from:to; bh=uY8EFxqJpqRvd+D9t5ya+CjoZnSgUcwWOrgr4dvCcdE=; b=R9UBpSjTldCmdqn/WSuqFxjp8vTjSMaULjsJ3GQqGLt5IeKXy7frxjzo EgqiUMusO/CHXRoW2r1dEPRByh9sbSVUhdgHdnpmg/7ke//tOMUimQ4np Q4KviEwQoFkPzZCn4zyU+O4Z2XyS1rMryj92YV2G6xDf9DkMNEjy51u3y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIFAFffV05Io8UT/2dsb2JhbAA6CYJNlj+PGXeBQgEBAxIBCREDWwEqBhgHVwEECxAaokGBIwGfIYMpgkNgBIdgkFCLcg X-IronPort-AV: E=Sophos;i="4.68,286,1312156800"; d="scan'208,217";a="52188799" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 26 Aug 2011 18:06:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7QI679S004890 for ; Fri, 26 Aug 2011 18:06:07 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 23:36:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC641A.D3D9D774" Date: Fri, 26 Aug 2011 23:36:05 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IKEv2 for load-sharing Thread-Index: AcxkGtLuvnnVuNLgSCyfV7NIMK3M4g== From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 26 Aug 2011 18:06:07.0467 (UTC) FILETIME=[D3F1D3B0:01CC641A] Subject: [IPsec] IKEv2 for load-sharing 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, 26 Aug 2011 18:04:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC641A.D3D9D774 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 RFC-4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) defines the extension of IKEv2 to support mobile users to offer seamless services when connected using IPSec and also the support for SCTP multi-homing in override mode. =20 To support a load-share model for SCTP(2 associations) or for that matter for any transport protocol between 2 gateways/nodes, 2 IKEv2 tunnels are needed between the same pair of gw/nodes. According to the current standards, the same pair of gateways has to go through complete IKEv2 exchange twice(atleast 2, INIT and AUTH) to provide such a service. So, speaking the number of IKEv2 and IPSec tunnels needed between the gateways will increase with the increase in the amount of load-sharing and thus time to establish these tunnels. =20 Going by the fact that the identity at both the gateways would be authenticated in the first tunnel establishment, is there a better way to achieve load-sharing? =20 Regards, Prashant Batra ------_=_NextPart_001_01CC641A.D3D9D774 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

RFC-4555 (IKEv2 Mobility and Multihoming Protocol = (MOBIKE)) defines the extension of IKEv2 to support mobile users to offer seamless services when connected using IPSec

and also the support for SCTP multi-homing in = override mode.

 

To support a load-share model for SCTP(2 = associations) or for that matter for any transport protocol between 2 gateways/nodes, 2 = IKEv2 tunnels are needed between the same pair of gw/nodes.

According to the current standards, the same pair = of gateways has to go through complete IKEv2 exchange twice(atleast 2, INIT = and AUTH) to provide such a service.

So, speaking the number of IKEv2 and IPSec tunnels = needed between the gateways will increase with the increase in the amount of = load-sharing and thus time to establish these tunnels.

 

Going by the fact that the identity at both the = gateways would be authenticated in the first tunnel establishment, is there a = better way to achieve load-sharing?

 

Regards,

Prashant Batra

------_=_NextPart_001_01CC641A.D3D9D774-- From paul.hoffman@vpnc.org Fri Aug 26 11:44:29 2011 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 330AD21F8C33 for ; Fri, 26 Aug 2011 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNIVUGWVZJld for ; Fri, 26 Aug 2011 11:44:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B23AE21F8C2D for ; Fri, 26 Aug 2011 11:44:28 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7QIjhB8028180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2011 11:45:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 26 Aug 2011 11:45:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38DBEE0E-51CA-4808-8D04-F1EF54E1E601@vpnc.org> References: To: Prashant Batra (prbatra) X-Mailer: Apple Mail (2.1244.3) Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 for load-sharing 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, 26 Aug 2011 18:44:29 -0000 On Aug 26, 2011, at 11:06 AM, Prashant Batra (prbatra) wrote: > Hello, > =20 > RFC-4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) defines = the extension of IKEv2 to support mobile users to offer seamless = services when connected using IPSec > and also the support for SCTP multi-homing in override mode. > =20 > To support a load-share model for SCTP(2 associations) or for that = matter for any transport protocol between 2 gateways/nodes, 2 IKEv2 = tunnels are needed between the same pair of gw/nodes. > According to the current standards, the same pair of gateways has to = go through complete IKEv2 exchange twice(atleast 2, INIT and AUTH) to = provide such a service. > So, speaking the number of IKEv2 and IPSec tunnels needed between the = gateways will increase with the increase in the amount of load-sharing = and thus time to establish these tunnels. > =20 > Going by the fact that the identity at both the gateways would be = authenticated in the first tunnel establishment, is there a better way = to achieve load-sharing? By "better" I assume you mean "more efficient". If so, there probably is = a "better" way to do it, but at the cost of greater complexity. I = vaguely remember this being discussed in MOBIKE, but dismissed as too = complicated for the value. Others here might remember more. --Paul Hoffman From nbn@cisco.com Sun Aug 28 22:53:11 2011 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 193C921F87E2 for ; Sun, 28 Aug 2011 22:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7tv34FjQZcq for ; Sun, 28 Aug 2011 22:53:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D0DC221F87D9 for ; Sun, 28 Aug 2011 22:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=13844; q=dns/txt; s=iport; t=1314597273; x=1315806873; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gHdfjd/iN475VPRZ7vXx5x2ogHN8MYPv0hgv59VXCfI=; b=d7IAbA5XPbCtDN5koatA1HzueTPWKp03+ABdGEu5xSQH1X2VXIl40b+f XFrFUfnmgfBaM1tA+I96smZbI3krdSt1xuX8eWSXjdfQuJ3EswqrJm0C4 RKRpLOo5f9SvnZQQg6iwLlLJG3uyBLyB1DmgdtWQ+/1cWYzYzmsauSC9f w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAF8oW05Io8UQ/2dsb2JhbABCmBmPXneBQAEBAQECAQEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASAGAR4JCAIEAQoICBECB4dQBJhNAZ1uhWxgBIc1LYkshyiEYocT X-IronPort-AV: E=Sophos;i="4.68,295,1312156800"; d="scan'208";a="112903974" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2011 05:54:28 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7T5sRCX010192; Mon, 29 Aug 2011 05:54:27 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 11:24:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 11:24:26 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Perfect Forward secrecy thread-index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhABdzlgaAAB0VBwAAHIuBAAADbL1AAFla60AAE7tawABFAY4AAhVsc4A== References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com><4E2EA248.70708@gmail.com> From: "Naveen B N (nbn)" To: "Scott Fluhrer (sfluhrer)" , "Yaron Sheffer" , "Yoav Nir" , "Rajeshwar Singh Jenwar (rsj)" X-OriginalArrivalTime: 29 Aug 2011 05:54:27.0638 (UTC) FILETIME=[1CD8C560:01CC6610] Cc: ipsec@ietf.org, "Rajeshwar Singh Jenwar \(rsj\)" Subject: Re: [IPsec] Perfect Forward secrecy 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, 29 Aug 2011 05:53:11 -0000 Hi Scott, Even with the Pre-shared secret, the protocol can't keep up the property = of " perfect Forward secrecy". I have assumed the both the server and client use pre-shared secret, = same below methods applies to Certificate based=20 Authentication has well. Below steps show why. Subject: Intruder X acts has server only to get the access of auth = payload. 1)A send IKE_INIT to indented server. 2) X[ intruder ] receives the INIT and process just has the protocol and = replies with the generated public value for DH. IKE_INT response is from Intruder instead of Server = by creating the packet using=20 a raw socket using [ IP spoofing]. 3)A and X now generate the Sk key which is used to encrypt the next = IKE_AUTH message. 4)A sends IKE_AUTH and intruder receives the same and he is able to = decrypt the message and get access to IDR and Auth payload. 5)Intrudes gets hold of the AUTH data and work on it to derive the = Pre-shared Secret { eg. Brute force}. 6) Since The Pre-shared secret is not changes the Intruder can now = behave has the Initiator to server[IDR]=20 And complete the Ikev2 flow.=20 Kindly share your view on the above . Thanks and Regards Naveen -----Original Message----- From: Scott Fluhrer (sfluhrer)=20 Sent: Friday, August 26, 2011 7:27 PM To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' Cc: 'ipsec@ietf.org' Subject: RE: [IPsec] DH keys calculation performance > -----Original Message----- > From: Naveen B N (nbn) > Sent: Friday, August 26, 2011 1:37 AM > To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav > Nir' > Cc: 'ipsec@ietf.org' > Subject: RE: [IPsec] DH keys calculation performance >=20 > Hi Scott, > if we can take care of the "Forward Secrecy", > When using Asymetric keys from certificates > To negotiate symmetric keys, then certificate > Can be used in place of DH Computation. >=20 > "TO maintain "Forward Secrecy", we have to change the keys from > time to time based on the key length, which can be achieved by re- > negotiating" No, you'd have the change the asymmetric keys all well; with the private = key, the attacker can still recover the session (symmetric) keys. Now, it's not impossible to change the public keys; however, it does = involve generating a fresh private/public key pair. With RSA, at least, = that's a lot more expensive than doing a single exchange (or, for that = matter, several dozen simple exchanges), and so if the point of this is = to reduce the total amount of computation, well, that rather misses the = point. >=20 > If this is possible then I can present a draft for the same. >=20 > Thanks & Regards > Naveen >=20 >=20 > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Thursday, August 25, 2011 10:18 PM > To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- > users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; > 'ipsec-tools-devel@lists.sourceforge.net' > Subject: RE: [IPsec] DH keys calculation performance >=20 >=20 > > -----Original Message----- > > From: Naveen B N (nbn) > > Sent: Thursday, August 25, 2011 12:34 PM > > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; > > timo.teras@iki.fi > > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- > > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; > ipsec- > > tools-devel@lists.sourceforge.net > > Subject: RE: [IPsec] DH keys calculation performance > > > > Hi Scott, > > > > Please find the queries and comments inline .. > > > > Scott>- Transporting keying material lacks forward secrecy. = "Forward > > secrecy" is the property that, if some actually recovers the entire > > state of one (or both) of the sides, they still won't be able to > > decrypt a transcript of a session that had happened earlier (because > > the state needed to decrypt it was zeroized when the session was > > closed). With key transport, it is impractical to zeroize the > private > > key used during the exchange, and with that, the attacker can = decrypt > > the keying material, and from there, rederive the session keys. In > > contrast, with DH, as long as both sides zeroize the private > exponents > > and shared secrets (along with the session state), the attacker does > > not have enough information. > > > > Naveen>> TO maintain "Forward Secrecy", we have to change the keys > from > > time to time based on the key length, which can be achieved by re- > > negotiating > > new keys with the communicated Symmetric key. > > But if you say that the first session used is to derive the > > private key of the peer, then Asymmetric key should never be used = for > > deriving symmetric keys > > Or to protect data. If Certificate are still used in TLS for > > negotiation of Symmetric keys, this is a major issue because they = are > > used in important places. >=20 > I believe you misunderstand; we're not using the asymmetric key to > "derive" the symmetric keys, but instead just to transport it. >=20 > Here's the scenario: > - Side A picks some keying material ("premaster secret" is TLS's > terminology for it) > - Side A encrypts it with Side B's public key, and sends it to B > - Side B decrypts it with his own private key > - Both side A and side B use that keying material (and possibly other > information that has been exchanged) to derive the real session keys >=20 > The problem I was discussing: what if, after the session has been shut > down, the attacker recovers side B's private key? This private key is > unlikely to be zeroized along with the session (at least, with the > current CA infrastructure); using this private key, the attacker could > decrypt the encrypted keying material (just like B did), and rederive > the session keys (again, just like B did). >=20 > > > > Naveen>>So, Certificates should only be used for authentication in a > > protected environment is it. > > What could be the life time of the RSA keys then, how long will > > it take to derive a private key from a public key with the best > > available resources. > > Then it comes down to DH method being the best secured > > available solution for negotiating Symmetric key on the fly, without > > having shared keying material with the peer. > > > > Scott>- IKEv2 allows other types of authentication beyond > certificates; > > using public key encryption as a step in generating keying material > > would imply that we would need a different mechanism to generate > keying > > material for other types of authentication. This is certainly not > > impossible (in fact, IKEv1 did have different mechanisms based on > > authentication type, although for different reasons); the IKEv2 > > designers decided to unify that. > > > > Naveen>>May be Ikev2 designers feel that the intruder may selects a > > week authentication type if exposed in plan message, But I think we > are > > authenticating the INIT_MESSAGE in IKE_AUTH > > Message, so they could have provided a authentication method > in > > IKE_INIT message. > > > > > > Thanks and Regards > > Naveen > > > > -----Original Message----- > > From: Scott Fluhrer (sfluhrer) > > Sent: Thursday, August 25, 2011 6:57 PM > > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > Subject: RE: [IPsec] DH keys calculation performance > > > > > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > Behalf > > > Of Naveen B N (nbn) > > > Sent: Thursday, August 25, 2011 6:48 AM > > > To: Yaron Sheffer; Yoav Nir > > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) > > > Subject: Re: [IPsec] DH keys calculation performance > > > > > > Hi , > > > Can we not use the existing RSA keys to get the shared secret > without > > > using the DH computation > > > Because of the calculation that are involved. > > > Let's say A wants to initiate a session with B. > > > Let A get the Public key of B from CA by sending a protected > message > > > using public key of CA. > > > Use the obtained public key for sending the shared secret to B and > > same > > > from the other > > > End has well, this will ensure authentication and avoiding DH > > > computation. > > > > > > I feel that certificate can be used for authentication and as well > > has > > > negotiated Symmetric key using the > > > Concept of Asymmetric cryptography which is one of the good > features > > > of certificate. > > > > > > Why in Ikev2, certificates are just used for authentication and = why > > > they are not used for > > > negotiating Symmetric key instead in place of DH computation. Is = it > > to > > > avoid use of Trusted CA negotiation. > > > > Well, you certainly can use certificates (with public key encryption > > keys) to transport keying material; indeed, the ciphersuite of TLS > that > > is in general use does exactly that. > > > > However, it does have a few drawbacks. Here are some of the reasons > > that the IKEv2 designers may have chosen not to use it: > > > > - Transporting keying material lacks forward secrecy. "Forward > > secrecy" is the property that, if some actually recovers the entire > > state of one (or both) of the sides, they still won't be able to > > decrypt a transcript of a session that had happened earlier (because > > the state needed to decrypt it was zeroized when the session was > > closed). With key transport, it is impractical to zeroize the > private > > key used during the exchange, and with that, the attacker can = decrypt > > the keying material, and from there, rederive the session keys. In > > contrast, with DH, as long as both sides zeroize the private > exponents > > and shared secrets (along with the session state), the attacker does > > not have enough information. > > > > - IKEv2 allows other types of authentication beyond certificates; > using > > public key encryption as a step in generating keying material would > > imply that we would need a different mechanism to generate keying > > material for other types of authentication. This is certainly not > > impossible (in fact, IKEv1 did have different mechanisms based on > > authentication type, although for different reasons); the IKEv2 > > designers decided to unify that. > > > > > > > > Thanks and Regards > > > Naveen > > > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > Behalf > > > Of Prashant Batra (prbatra) > > > Sent: Tuesday, July 26, 2011 6:33 PM > > > To: Yaron Sheffer; Yoav Nir > > > Cc: ipsec@ietf.org > > > Subject: Re: [IPsec] DH keys calculation performance > > > > > > Thanks Yoav and Yaron =A0for the suggestions. > > > Even I was thinking and tried generating and storing the key pair > > =A0well > > > in the beginning,.=A0 This helped to some extent. > > > > > > The secret calculation is also very expensive, but this has to be > > done > > > in midst of the exchange only. > > > > > > Regards, > > > Prashant > > > > > > > > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > > Sent: Tuesday, July 26, 2011 4:47 PM > > > To: Yoav Nir > > > Cc: Prashant Batra (prbatra); ipsec@ietf.org > > > Subject: Re: [IPsec] DH keys calculation performance > > > > > > You might want to review > http://tools.ietf.org/html/rfc5996#section- > > > 2.12. > > > > > > Also, session resumption (http://tools.ietf.org/html/rfc5723) > reduces > > > the computational costs of renewing an IKE SA when a client needs > to > > > reconnect to a gateway a second time after some failure. > > > > > > Thanks, > > > =A0=A0=A0 Yaron > > > > > > On 07/26/2011 01:40 PM, Yoav Nir wrote: > > > > > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > > > > > > Hello, > > > > > > The DH exchange (Calculation of Public/Private key and the Secret) > in > > > IKEV2 Initial exchange > > > seems to be very expensive. This is slowing down the overall IKEv2 > > > tunnel establishment. > > > Is there a way to optimize it? > > > > > > Hi Prashant. > > > > > > I know of three ways to optimize the D-H exchange. > > > > > > First, note that each peer has to perform two operations: > > > =A01. Generate: create a random x and calculate X=3D2^x mod p > > > 2. Derive: calculate the shared secret S=3DY^x mod p > > > The "Derive" operation has to be done during the exchange, but the > > > "Generate" operation can be done long before the exchange. If your > > > problem is degraded performance at some peak, you can pre-generate > > some > > > values. This has a high cost in memory, but can be useful for > dealing > > > with peaks. > > > > > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * = (2^1 > mod > > > p)) mod p > > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x = mod > p > > > for 0<=3Dx<=3D2048 and store these values. After that, both the > generate > > > and derive operations become simple multiplications of the > resulting > > > values. This has a fixed cost in memory, but can accelerate = things. > > > > > > Third, you may want to look at the EC groups. The EC operations > > require > > > less computation. > > > > > > Hope this helps > > > > > > Yoav > > > > > > > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sun Aug 28 23:03:43 2011 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 C2FB121F886D for ; Sun, 28 Aug 2011 23:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mLXPV5TxGiA for ; Sun, 28 Aug 2011 23:03:42 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0221F877F for ; Sun, 28 Aug 2011 23:03:39 -0700 (PDT) X-CheckPoint: {4E5B3958-F-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p7T64t4X021682; Mon, 29 Aug 2011 09:04:55 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 29 Aug 2011 09:04:55 +0300 From: Yoav Nir To: "Naveen B N (nbn)" , "Scott Fluhrer (sfluhrer)" , Yaron Sheffer , "Rajeshwar Singh Jenwar (rsj)" Date: Mon, 29 Aug 2011 09:04:53 +0300 Thread-Topic: [IPsec] Perfect Forward secrecy Thread-Index: AcxmEZKeyMwFzOFNS568O0v9+UFx+Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Perfect Forward secrecy 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, 29 Aug 2011 06:03:43 -0000 Hi Naveen If you use a 128-bit or 256-bit truly random shared secret (like you should, although probably nobody does), brute force will never work. If you use a weaker shared secret, such as something with 20-40 bits of entropy, then your offline dictionary attack becomes practical. For suggested ways of counteracting this, take a look at these: http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2 http://tools.ietf.org/html/draft-shin-augmented-pake On 8/29/11 8:54 AM, "Naveen B N (nbn)" wrote: >Hi Scott, >Even with the Pre-shared secret, the protocol can't keep up the property >of " perfect Forward secrecy". >I have assumed the both the server and client use pre-shared secret, same >below methods applies to Certificate based >Authentication has well. >Below steps show why. > >Subject: Intruder X acts has server only to get the access of auth >payload. > >1)A send IKE_INIT to indented server. >2) X[ intruder ] receives the INIT and process just has the protocol and >replies with the generated >public value for DH. IKE_INT response is from Intruder instead of Server >by creating the packet using >a raw socket using [ IP spoofing]. >3)A and X now generate the Sk key which is used to encrypt the next >IKE_AUTH message. >4)A sends IKE_AUTH and intruder receives the same and he is able to >decrypt the message and get access to IDR and Auth payload. >5)Intrudes gets hold of the AUTH data and work on it to derive the >Pre-shared Secret { eg. Brute force}. >6) Since The Pre-shared secret is not changes the Intruder can now behave >has the Initiator to server[IDR] >And complete the Ikev2 flow. > >Kindly share your view on the above . > >Thanks and Regards >Naveen > >-----Original Message----- >From: Scott Fluhrer (sfluhrer) >Sent: Friday, August 26, 2011 7:27 PM >To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >Cc: 'ipsec@ietf.org' >Subject: RE: [IPsec] DH keys calculation performance > > >> -----Original Message----- >> From: Naveen B N (nbn) >> Sent: Friday, August 26, 2011 1:37 AM >> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav >> Nir' >> Cc: 'ipsec@ietf.org' >> Subject: RE: [IPsec] DH keys calculation performance >> >> Hi Scott, >> if we can take care of the "Forward Secrecy", >> When using Asymetric keys from certificates >> To negotiate symmetric keys, then certificate >> Can be used in place of DH Computation. >> >> "TO maintain "Forward Secrecy", we have to change the keys from >> time to time based on the key length, which can be achieved by re- >> negotiating" > >No, you'd have the change the asymmetric keys all well; with the private >key, the attacker can still recover the session (symmetric) keys. > >Now, it's not impossible to change the public keys; however, it does >involve generating a fresh private/public key pair. With RSA, at least, >that's a lot more expensive than doing a single exchange (or, for that >matter, several dozen simple exchanges), and so if the point of this is >to reduce the total amount of computation, well, that rather misses the >point. > >> >> If this is possible then I can present a draft for the same. >> >> Thanks & Regards >> Naveen >> >> >> -----Original Message----- >> From: Scott Fluhrer (sfluhrer) >> Sent: Thursday, August 25, 2011 10:18 PM >> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' >> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >> 'ipsec-tools-devel@lists.sourceforge.net' >> Subject: RE: [IPsec] DH keys calculation performance >> >> >> > -----Original Message----- >> > From: Naveen B N (nbn) >> > Sent: Thursday, August 25, 2011 12:34 PM >> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; >> > timo.teras@iki.fi >> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >> > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >> ipsec- >> > tools-devel@lists.sourceforge.net >> > Subject: RE: [IPsec] DH keys calculation performance >> > >> > Hi Scott, >> > >> > Please find the queries and comments inline .. >> > >> > Scott>- Transporting keying material lacks forward secrecy. "Forward >> > secrecy" is the property that, if some actually recovers the entire >> > state of one (or both) of the sides, they still won't be able to >> > decrypt a transcript of a session that had happened earlier (because >> > the state needed to decrypt it was zeroized when the session was >> > closed). With key transport, it is impractical to zeroize the >> private >> > key used during the exchange, and with that, the attacker can decrypt >> > the keying material, and from there, rederive the session keys. In >> > contrast, with DH, as long as both sides zeroize the private >> exponents >> > and shared secrets (along with the session state), the attacker does >> > not have enough information. >> > >> > Naveen>> TO maintain "Forward Secrecy", we have to change the keys >> from >> > time to time based on the key length, which can be achieved by re- >> > negotiating >> > new keys with the communicated Symmetric key. >> > But if you say that the first session used is to derive the >> > private key of the peer, then Asymmetric key should never be used for >> > deriving symmetric keys >> > Or to protect data. If Certificate are still used in TLS for >> > negotiation of Symmetric keys, this is a major issue because they are >> > used in important places. >> >> I believe you misunderstand; we're not using the asymmetric key to >> "derive" the symmetric keys, but instead just to transport it. >> >> Here's the scenario: >> - Side A picks some keying material ("premaster secret" is TLS's >> terminology for it) >> - Side A encrypts it with Side B's public key, and sends it to B >> - Side B decrypts it with his own private key >> - Both side A and side B use that keying material (and possibly other >> information that has been exchanged) to derive the real session keys >> >> The problem I was discussing: what if, after the session has been shut >> down, the attacker recovers side B's private key? This private key is >> unlikely to be zeroized along with the session (at least, with the >> current CA infrastructure); using this private key, the attacker could >> decrypt the encrypted keying material (just like B did), and rederive >> the session keys (again, just like B did). >> >> > >> > Naveen>>So, Certificates should only be used for authentication in a >> > protected environment is it. >> > What could be the life time of the RSA keys then, how long will >> > it take to derive a private key from a public key with the best >> > available resources. >> > Then it comes down to DH method being the best secured >> > available solution for negotiating Symmetric key on the fly, without >> > having shared keying material with the peer. >> > >> > Scott>- IKEv2 allows other types of authentication beyond >> certificates; >> > using public key encryption as a step in generating keying material >> > would imply that we would need a different mechanism to generate >> keying >> > material for other types of authentication. This is certainly not >> > impossible (in fact, IKEv1 did have different mechanisms based on >> > authentication type, although for different reasons); the IKEv2 >> > designers decided to unify that. >> > >> > Naveen>>May be Ikev2 designers feel that the intruder may selects a >> > week authentication type if exposed in plan message, But I think we >> are >> > authenticating the INIT_MESSAGE in IKE_AUTH >> > Message, so they could have provided a authentication method >> in >> > IKE_INIT message. >> > >> > >> > Thanks and Regards >> > Naveen >> > >> > -----Original Message----- >> > From: Scott Fluhrer (sfluhrer) >> > Sent: Thursday, August 25, 2011 6:57 PM >> > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir >> > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >> > Subject: RE: [IPsec] DH keys calculation performance >> > >> > >> > >> > > -----Original Message----- >> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> > Behalf >> > > Of Naveen B N (nbn) >> > > Sent: Thursday, August 25, 2011 6:48 AM >> > > To: Yaron Sheffer; Yoav Nir >> > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >> > > Subject: Re: [IPsec] DH keys calculation performance >> > > >> > > Hi , >> > > Can we not use the existing RSA keys to get the shared secret >> without >> > > using the DH computation >> > > Because of the calculation that are involved. >> > > Let's say A wants to initiate a session with B. >> > > Let A get the Public key of B from CA by sending a protected >> message >> > > using public key of CA. >> > > Use the obtained public key for sending the shared secret to B and >> > same >> > > from the other >> > > End has well, this will ensure authentication and avoiding DH >> > > computation. >> > > >> > > I feel that certificate can be used for authentication and as well >> > has >> > > negotiated Symmetric key using the >> > > Concept of Asymmetric cryptography which is one of the good >> features >> > > of certificate. >> > > >> > > Why in Ikev2, certificates are just used for authentication and why >> > > they are not used for >> > > negotiating Symmetric key instead in place of DH computation. Is it >> > to >> > > avoid use of Trusted CA negotiation. >> > >> > Well, you certainly can use certificates (with public key encryption >> > keys) to transport keying material; indeed, the ciphersuite of TLS >> that >> > is in general use does exactly that. >> > >> > However, it does have a few drawbacks. Here are some of the reasons >> > that the IKEv2 designers may have chosen not to use it: >> > >> > - Transporting keying material lacks forward secrecy. "Forward >> > secrecy" is the property that, if some actually recovers the entire >> > state of one (or both) of the sides, they still won't be able to >> > decrypt a transcript of a session that had happened earlier (because >> > the state needed to decrypt it was zeroized when the session was >> > closed). With key transport, it is impractical to zeroize the >> private >> > key used during the exchange, and with that, the attacker can decrypt >> > the keying material, and from there, rederive the session keys. In >> > contrast, with DH, as long as both sides zeroize the private >> exponents >> > and shared secrets (along with the session state), the attacker does >> > not have enough information. >> > >> > - IKEv2 allows other types of authentication beyond certificates; >> using >> > public key encryption as a step in generating keying material would >> > imply that we would need a different mechanism to generate keying >> > material for other types of authentication. This is certainly not >> > impossible (in fact, IKEv1 did have different mechanisms based on >> > authentication type, although for different reasons); the IKEv2 >> > designers decided to unify that. >> > >> > > >> > > Thanks and Regards >> > > Naveen >> > > >> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> > Behalf >> > > Of Prashant Batra (prbatra) >> > > Sent: Tuesday, July 26, 2011 6:33 PM >> > > To: Yaron Sheffer; Yoav Nir >> > > Cc: ipsec@ietf.org >> > > Subject: Re: [IPsec] DH keys calculation performance >> > > >> > > Thanks Yoav and Yaron for the suggestions. >> > > Even I was thinking and tried generating and storing the key pair >> > well >> > > in the beginning,. This helped to some extent. >> > > >> > > The secret calculation is also very expensive, but this has to be >> > done >> > > in midst of the exchange only. >> > > >> > > Regards, >> > > Prashant >> > > >> > > >> > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> > > Sent: Tuesday, July 26, 2011 4:47 PM >> > > To: Yoav Nir >> > > Cc: Prashant Batra (prbatra); ipsec@ietf.org >> > > Subject: Re: [IPsec] DH keys calculation performance >> > > >> > > You might want to review >> http://tools.ietf.org/html/rfc5996#section- >> > > 2.12. >> > > >> > > Also, session resumption (http://tools.ietf.org/html/rfc5723) >> reduces >> > > the computational costs of renewing an IKE SA when a client needs >> to >> > > reconnect to a gateway a second time after some failure. >> > > >> > > Thanks, >> > > Yaron >> > > >> > > On 07/26/2011 01:40 PM, Yoav Nir wrote: >> > > >> > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >> > > >> > > Hello, >> > > >> > > The DH exchange (Calculation of Public/Private key and the Secret) >> in >> > > IKEV2 Initial exchange >> > > seems to be very expensive. This is slowing down the overall IKEv2 >> > > tunnel establishment. >> > > Is there a way to optimize it? >> > > >> > > Hi Prashant. >> > > >> > > I know of three ways to optimize the D-H exchange. >> > > >> > > First, note that each peer has to perform two operations: >> > > 1. Generate: create a random x and calculate X=3D2^x mod p >> > > 2. Derive: calculate the shared secret S=3DY^x mod p >> > > The "Derive" operation has to be done during the exchange, but the >> > > "Generate" operation can be done long before the exchange. If your >> > > problem is degraded performance at some peak, you can pre-generate >> > some >> > > values. This has a high cost in memory, but can be useful for >> dealing >> > > with peaks. >> > > >> > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 >> mod >> > > p)) mod p >> > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod >> p >> > > for 0<=3Dx<=3D2048 and store these values. After that, both the >> generate >> > > and derive operations become simple multiplications of the >> resulting >> > > values. This has a fixed cost in memory, but can accelerate things. >> > > >> > > Third, you may want to look at the EC groups. The EC operations >> > require >> > > less computation. >> > > >> > > Hope this helps >> > > >> > > Yoav >> > > >> > > >> > > >> > > _______________________________________________ >> > > IPsec mailing list >> > > IPsec@ietf.org >> > > https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ >> > > IPsec mailing list >> > > IPsec@ietf.org >> > > https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. From dharkins@lounge.org Sun Aug 28 23:29:45 2011 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 274E121F855B for ; Sun, 28 Aug 2011 23:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfPBGI1lE-Dd for ; Sun, 28 Aug 2011 23:29:43 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A082F21F86EE for ; Sun, 28 Aug 2011 23:29:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3FCDD1022404C; Sun, 28 Aug 2011 23:31:06 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 28 Aug 2011 23:31:06 -0700 (PDT) Message-ID: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> In-Reply-To: References: Date: Sun, 28 Aug 2011 23:31:06 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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" , Naveen B N , Rajeshwar Singh Jenwar , Scott Fluhrer Subject: Re: [IPsec] Perfect Forward secrecy 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, 29 Aug 2011 06:29:45 -0000 Hi Naveen, Yoav is right that increasing the size of the secret, and ensuring it is uniformly random, will mitigate this sort of dictionary attack. And the 3 drafts he mentions will basically foil it entirely. But the attack you mention does not affect "perfect forward secrecy". That is the property that even with the loss of a long term credential (like the pre-shared secret learned by dictionary attack) the adversary is unable to determine the session key from a different run of the protocol. This property still holds even with a successful dictionary attack against a pre-shared key. regards, Dan. On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote: > Hi Naveen > > If you use a 128-bit or 256-bit truly random shared secret (like you > should, although probably nobody does), brute force will never work. If > you use a weaker shared secret, such as something with 20-40 bits of > entropy, then your offline dictionary attack becomes practical. > > For suggested ways of counteracting this, take a look at these: > http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut > http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2 > http://tools.ietf.org/html/draft-shin-augmented-pake > > On 8/29/11 8:54 AM, "Naveen B N (nbn)" wrote: > >>Hi Scott, >>Even with the Pre-shared secret, the protocol can't keep up the property >>of " perfect Forward secrecy". >>I have assumed the both the server and client use pre-shared secret, same >>below methods applies to Certificate based >>Authentication has well. >>Below steps show why. >> >>Subject: Intruder X acts has server only to get the access of auth >>payload. >> >>1)A send IKE_INIT to indented server. >>2) X[ intruder ] receives the INIT and process just has the protocol and >>replies with the generated >>public value for DH. IKE_INT response is from Intruder instead of Server >>by creating the packet using >>a raw socket using [ IP spoofing]. >>3)A and X now generate the Sk key which is used to encrypt the next >>IKE_AUTH message. >>4)A sends IKE_AUTH and intruder receives the same and he is able to >>decrypt the message and get access to IDR and Auth payload. >>5)Intrudes gets hold of the AUTH data and work on it to derive the >>Pre-shared Secret { eg. Brute force}. >>6) Since The Pre-shared secret is not changes the Intruder can now behave >>has the Initiator to server[IDR] >>And complete the Ikev2 flow. >> >>Kindly share your view on the above . >> >>Thanks and Regards >>Naveen >> >>-----Original Message----- >>From: Scott Fluhrer (sfluhrer) >>Sent: Friday, August 26, 2011 7:27 PM >>To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >>Cc: 'ipsec@ietf.org' >>Subject: RE: [IPsec] DH keys calculation performance >> >> >>> -----Original Message----- >>> From: Naveen B N (nbn) >>> Sent: Friday, August 26, 2011 1:37 AM >>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav >>> Nir' >>> Cc: 'ipsec@ietf.org' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> Hi Scott, >>> if we can take care of the "Forward Secrecy", >>> When using Asymetric keys from certificates >>> To negotiate symmetric keys, then certificate >>> Can be used in place of DH Computation. >>> >>> "TO maintain "Forward Secrecy", we have to change the keys from >>> time to time based on the key length, which can be achieved by re- >>> negotiating" >> >>No, you'd have the change the asymmetric keys all well; with the private >>key, the attacker can still recover the session (symmetric) keys. >> >>Now, it's not impossible to change the public keys; however, it does >>involve generating a fresh private/public key pair. With RSA, at least, >>that's a lot more expensive than doing a single exchange (or, for that >>matter, several dozen simple exchanges), and so if the point of this is >>to reduce the total amount of computation, well, that rather misses the >>point. >> >>> >>> If this is possible then I can present a draft for the same. >>> >>> Thanks & Regards >>> Naveen >>> >>> >>> -----Original Message----- >>> From: Scott Fluhrer (sfluhrer) >>> Sent: Thursday, August 25, 2011 10:18 PM >>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' >>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >>> 'ipsec-tools-devel@lists.sourceforge.net' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> >>> > -----Original Message----- >>> > From: Naveen B N (nbn) >>> > Sent: Thursday, August 25, 2011 12:34 PM >>> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; >>> > timo.teras@iki.fi >>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >>> > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >>> ipsec- >>> > tools-devel@lists.sourceforge.net >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > Hi Scott, >>> > >>> > Please find the queries and comments inline .. >>> > >>> > Scott>- Transporting keying material lacks forward secrecy. "Forward >>> > secrecy" is the property that, if some actually recovers the entire >>> > state of one (or both) of the sides, they still won't be able to >>> > decrypt a transcript of a session that had happened earlier (because >>> > the state needed to decrypt it was zeroized when the session was >>> > closed). With key transport, it is impractical to zeroize the >>> private >>> > key used during the exchange, and with that, the attacker can decrypt >>> > the keying material, and from there, rederive the session keys. In >>> > contrast, with DH, as long as both sides zeroize the private >>> exponents >>> > and shared secrets (along with the session state), the attacker does >>> > not have enough information. >>> > >>> > Naveen>> TO maintain "Forward Secrecy", we have to change the keys >>> from >>> > time to time based on the key length, which can be achieved by re- >>> > negotiating >>> > new keys with the communicated Symmetric key. >>> > But if you say that the first session used is to derive the >>> > private key of the peer, then Asymmetric key should never be used for >>> > deriving symmetric keys >>> > Or to protect data. If Certificate are still used in TLS for >>> > negotiation of Symmetric keys, this is a major issue because they are >>> > used in important places. >>> >>> I believe you misunderstand; we're not using the asymmetric key to >>> "derive" the symmetric keys, but instead just to transport it. >>> >>> Here's the scenario: >>> - Side A picks some keying material ("premaster secret" is TLS's >>> terminology for it) >>> - Side A encrypts it with Side B's public key, and sends it to B >>> - Side B decrypts it with his own private key >>> - Both side A and side B use that keying material (and possibly other >>> information that has been exchanged) to derive the real session keys >>> >>> The problem I was discussing: what if, after the session has been shut >>> down, the attacker recovers side B's private key? This private key is >>> unlikely to be zeroized along with the session (at least, with the >>> current CA infrastructure); using this private key, the attacker could >>> decrypt the encrypted keying material (just like B did), and rederive >>> the session keys (again, just like B did). >>> >>> > >>> > Naveen>>So, Certificates should only be used for authentication in a >>> > protected environment is it. >>> > What could be the life time of the RSA keys then, how long will >>> > it take to derive a private key from a public key with the best >>> > available resources. >>> > Then it comes down to DH method being the best secured >>> > available solution for negotiating Symmetric key on the fly, without >>> > having shared keying material with the peer. >>> > >>> > Scott>- IKEv2 allows other types of authentication beyond >>> certificates; >>> > using public key encryption as a step in generating keying material >>> > would imply that we would need a different mechanism to generate >>> keying >>> > material for other types of authentication. This is certainly not >>> > impossible (in fact, IKEv1 did have different mechanisms based on >>> > authentication type, although for different reasons); the IKEv2 >>> > designers decided to unify that. >>> > >>> > Naveen>>May be Ikev2 designers feel that the intruder may selects a >>> > week authentication type if exposed in plan message, But I think we >>> are >>> > authenticating the INIT_MESSAGE in IKE_AUTH >>> > Message, so they could have provided a authentication method >>> in >>> > IKE_INIT message. >>> > >>> > >>> > Thanks and Regards >>> > Naveen >>> > >>> > -----Original Message----- >>> > From: Scott Fluhrer (sfluhrer) >>> > Sent: Thursday, August 25, 2011 6:57 PM >>> > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir >>> > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Naveen B N (nbn) >>> > > Sent: Thursday, August 25, 2011 6:48 AM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > Hi , >>> > > Can we not use the existing RSA keys to get the shared secret >>> without >>> > > using the DH computation >>> > > Because of the calculation that are involved. >>> > > Let's say A wants to initiate a session with B. >>> > > Let A get the Public key of B from CA by sending a protected >>> message >>> > > using public key of CA. >>> > > Use the obtained public key for sending the shared secret to B and >>> > same >>> > > from the other >>> > > End has well, this will ensure authentication and avoiding DH >>> > > computation. >>> > > >>> > > I feel that certificate can be used for authentication and as well >>> > has >>> > > negotiated Symmetric key using the >>> > > Concept of Asymmetric cryptography which is one of the good >>> features >>> > > of certificate. >>> > > >>> > > Why in Ikev2, certificates are just used for authentication and why >>> > > they are not used for >>> > > negotiating Symmetric key instead in place of DH computation. Is it >>> > to >>> > > avoid use of Trusted CA negotiation. >>> > >>> > Well, you certainly can use certificates (with public key encryption >>> > keys) to transport keying material; indeed, the ciphersuite of TLS >>> that >>> > is in general use does exactly that. >>> > >>> > However, it does have a few drawbacks. Here are some of the reasons >>> > that the IKEv2 designers may have chosen not to use it: >>> > >>> > - Transporting keying material lacks forward secrecy. "Forward >>> > secrecy" is the property that, if some actually recovers the entire >>> > state of one (or both) of the sides, they still won't be able to >>> > decrypt a transcript of a session that had happened earlier (because >>> > the state needed to decrypt it was zeroized when the session was >>> > closed). With key transport, it is impractical to zeroize the >>> private >>> > key used during the exchange, and with that, the attacker can decrypt >>> > the keying material, and from there, rederive the session keys. In >>> > contrast, with DH, as long as both sides zeroize the private >>> exponents >>> > and shared secrets (along with the session state), the attacker does >>> > not have enough information. >>> > >>> > - IKEv2 allows other types of authentication beyond certificates; >>> using >>> > public key encryption as a step in generating keying material would >>> > imply that we would need a different mechanism to generate keying >>> > material for other types of authentication. This is certainly not >>> > impossible (in fact, IKEv1 did have different mechanisms based on >>> > authentication type, although for different reasons); the IKEv2 >>> > designers decided to unify that. >>> > >>> > > >>> > > Thanks and Regards >>> > > Naveen >>> > > >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Prashant Batra (prbatra) >>> > > Sent: Tuesday, July 26, 2011 6:33 PM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > Thanks Yoav and Yaron for the suggestions. >>> > > Even I was thinking and tried generating and storing the key pair >>> > well >>> > > in the beginning,. This helped to some extent. >>> > > >>> > > The secret calculation is also very expensive, but this has to be >>> > done >>> > > in midst of the exchange only. >>> > > >>> > > Regards, >>> > > Prashant >>> > > >>> > > >>> > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> > > Sent: Tuesday, July 26, 2011 4:47 PM >>> > > To: Yoav Nir >>> > > Cc: Prashant Batra (prbatra); ipsec@ietf.org >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > You might want to review >>> http://tools.ietf.org/html/rfc5996#section- >>> > > 2.12. >>> > > >>> > > Also, session resumption (http://tools.ietf.org/html/rfc5723) >>> reduces >>> > > the computational costs of renewing an IKE SA when a client needs >>> to >>> > > reconnect to a gateway a second time after some failure. >>> > > >>> > > Thanks, >>> > > Yaron >>> > > >>> > > On 07/26/2011 01:40 PM, Yoav Nir wrote: >>> > > >>> > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >>> > > >>> > > Hello, >>> > > >>> > > The DH exchange (Calculation of Public/Private key and the Secret) >>> in >>> > > IKEV2 Initial exchange >>> > > seems to be very expensive. This is slowing down the overall IKEv2 >>> > > tunnel establishment. >>> > > Is there a way to optimize it? >>> > > >>> > > Hi Prashant. >>> > > >>> > > I know of three ways to optimize the D-H exchange. >>> > > >>> > > First, note that each peer has to perform two operations: >>> > > 1. Generate: create a random x and calculate X=2^x mod p >>> > > 2. Derive: calculate the shared secret S=Y^x mod p >>> > > The "Derive" operation has to be done during the exchange, but the >>> > > "Generate" operation can be done long before the exchange. If your >>> > > problem is degraded performance at some peak, you can pre-generate >>> > some >>> > > values. This has a high cost in memory, but can be useful for >>> dealing >>> > > with peaks. >>> > > >>> > > Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 >>> mod >>> > > p)) mod p >>> > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod >>> p >>> > > for 0<=x<=2048 and store these values. After that, both the >>> generate >>> > > and derive operations become simple multiplications of the >>> resulting >>> > > values. This has a fixed cost in memory, but can accelerate things. >>> > > >>> > > Third, you may want to look at the EC groups. The EC operations >>> > require >>> > > less computation. >>> > > >>> > > Hope this helps >>> > > >>> > > Yoav >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >> >>Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From prbatra@cisco.com Sun Aug 28 23:30:30 2011 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 557DE21F88B6 for ; Sun, 28 Aug 2011 23:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-4.225, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMfwQQyVnS1n for ; Sun, 28 Aug 2011 23:30:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 87BDD21F886F for ; Sun, 28 Aug 2011 23:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=1990; q=dns/txt; s=iport; t=1314599510; x=1315809110; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6iE1zbtOCD0frl/mMvVaiClhNVRHqMeUJU9Wc0Du8IM=; b=dIqNaiT38QTFlWmDcP3/WZ183ax6ESG4hhoMB1z2Jtv3q8lvgkbEHRQ+ T6j8nvqF2ku/7yBVZ7Ki2AXCcxlPu/mrag2oIkjWQtsHj72r5Ufrg/YPm 9a773u4upgXdH+6dI0Usbdxxv4lraXi0aPUYabQF3SmcN6dWJ9yRcC9rI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAABQyW06rRDoH/2dsb2JhbAA5CZgZj153gUABAQEBAgESAR0KPwUHBAIBCBEEAQELBhcBBgFFCQgBAQQLCAgah1CYKwGddoMpgkNgBIdikFSLdQ X-IronPort-AV: E=Sophos;i="4.68,295,1312156800"; d="scan'208";a="17318360" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 29 Aug 2011 06:31:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7T6VSwU030136; Mon, 29 Aug 2011 06:31:48 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 12:01:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 12:01:40 +0530 Message-ID: In-Reply-To: <38DBEE0E-51CA-4808-8D04-F1EF54E1E601@vpnc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IKEv2 for load-sharing Thread-Index: AcxkIGLTHZQYfgbBRQSFOF3wK5tgCAB9DtEg References: <38DBEE0E-51CA-4808-8D04-F1EF54E1E601@vpnc.org> From: "Prashant Batra (prbatra)" To: "Paul Hoffman" X-OriginalArrivalTime: 29 Aug 2011 06:31:40.0552 (UTC) FILETIME=[4FC46880:01CC6615] Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 for load-sharing 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, 29 Aug 2011 06:30:30 -0000 Hi Paul,=20 I think, if we are able to deduce some efficient way of doing this, it can add value. A highly scalable and redundant deployment might use some good amount of load-sharing(can scale upto 4/5 sessions). In such scenarios, doing complete IKEv2 exchanges doesn't seems efficient or seems redundant. If you or the group can appreciate this, I can think and come up with some ideas. Regards, Prashant -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Saturday, August 27, 2011 12:16 AM To: Prashant Batra (prbatra) Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 for load-sharing On Aug 26, 2011, at 11:06 AM, Prashant Batra (prbatra) wrote: > Hello, > =20 > RFC-4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) defines the extension of IKEv2 to support mobile users to offer seamless services when connected using IPSec > and also the support for SCTP multi-homing in override mode. > =20 > To support a load-share model for SCTP(2 associations) or for that matter for any transport protocol between 2 gateways/nodes, 2 IKEv2 tunnels are needed between the same pair of gw/nodes. > According to the current standards, the same pair of gateways has to go through complete IKEv2 exchange twice(atleast 2, INIT and AUTH) to provide such a service. > So, speaking the number of IKEv2 and IPSec tunnels needed between the gateways will increase with the increase in the amount of load-sharing and thus time to establish these tunnels. > =20 > Going by the fact that the identity at both the gateways would be authenticated in the first tunnel establishment, is there a better way to achieve load-sharing? By "better" I assume you mean "more efficient". If so, there probably is a "better" way to do it, but at the cost of greater complexity. I vaguely remember this being discussed in MOBIKE, but dismissed as too complicated for the value. Others here might remember more. --Paul Hoffman From nbn@cisco.com Mon Aug 29 01:39:01 2011 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 5A3E521F8A91 for ; Mon, 29 Aug 2011 01:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ7390U9s-e5 for ; Mon, 29 Aug 2011 01:39:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 19AF221F852E for ; Mon, 29 Aug 2011 01:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=17082; q=dns/txt; s=iport; t=1314607223; x=1315816823; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vP4hyR1NVfHEb1Wjjhi7DNZrkg34MZuFjxjx45E6XM0=; b=kZ9R3I1kWrnncrACrpImonYl5/ayuVql/URMUpHPuE9vXDMWOii28PNb FwOr8xB5xWk6pBnlgq2FnCegtulz8RKwR3pkYf9dQJjmaR6FlA0wgQRMZ o2OMGmEK4Z7Nh02xurOnHJEkfz7Z6eGU0L4igpLP+zKQI66TaqWpl9KgR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAAZPW05Io8UR/2dsb2JhbABCmBuPXneBQAEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEgBgEeCQgBAQQBCggIEQIHh1SXZgGeFYVsYASHYokshyiEYocT X-IronPort-AV: E=Sophos;i="4.68,296,1312156800"; d="scan'208";a="112931919" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2011 08:40:17 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7T8eH5H006617; Mon, 29 Aug 2011 08:40:17 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 14:10:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 14:10:16 +0530 Message-ID: In-Reply-To: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Tokes = Session key + lifetime thread-index: AcxmFT7HSJrT7ZNdSCu10vugR9oW1QAD1Xkg References: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> From: "Naveen B N (nbn)" To: "Dan Harkins" , "Yoav Nir" X-OriginalArrivalTime: 29 Aug 2011 08:40:17.0566 (UTC) FILETIME=[47774BE0:01CC6627] Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Tokes = Session key + lifetime 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, 29 Aug 2011 08:39:01 -0000 Hi Dan and Yoav, Thank you and appreciate for the timely comments on my view and=20 sharing the drafts for the same. I was thinking to bring a Token concept in Ikev2 which will be=20 Given by the responder, so that the session keys is bound to a=20 life time and If the Key is still valid IKE_INIT can be skipped and IKE_AUTH is directly used even in the next sessions.=20 Tokens=3D Session key + Life time. The above will save DH computation and key negotiation in case=20 the session was aborted for some reason and if the client has=20 multiple make break of sessions. The above will save multiple times of authentication of client=20 who was already authenticated. Kindly share your views on token to be used has authenticators. Thanks and Regards Naveen -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org]=20 Sent: Monday, August 29, 2011 12:01 PM To: Yoav Nir Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar Singh Jenwar (rsj); ipsec@ietf.org Subject: Re: [IPsec] Perfect Forward secrecy Hi Naveen, Yoav is right that increasing the size of the secret, and ensuring it is uniformly random, will mitigate this sort of dictionary attack. And the 3 drafts he mentions will basically foil it entirely. But the attack you mention does not affect "perfect forward secrecy". That is the property that even with the loss of a long term credential (like the pre-shared secret learned by dictionary attack) the adversary is unable to determine the session key from a different run of the protocol. This property still holds even with a successful dictionary attack against a pre-shared key. regards, Dan. On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote: > Hi Naveen > > If you use a 128-bit or 256-bit truly random shared secret (like you > should, although probably nobody does), brute force will never work. If > you use a weaker shared secret, such as something with 20-40 bits of > entropy, then your offline dictionary attack becomes practical. > > For suggested ways of counteracting this, take a look at these: > http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut > http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2 > http://tools.ietf.org/html/draft-shin-augmented-pake > > On 8/29/11 8:54 AM, "Naveen B N (nbn)" wrote: > >>Hi Scott, >>Even with the Pre-shared secret, the protocol can't keep up the property >>of " perfect Forward secrecy". >>I have assumed the both the server and client use pre-shared secret, same >>below methods applies to Certificate based >>Authentication has well. >>Below steps show why. >> >>Subject: Intruder X acts has server only to get the access of auth >>payload. >> >>1)A send IKE_INIT to indented server. >>2) X[ intruder ] receives the INIT and process just has the protocol and >>replies with the generated >>public value for DH. IKE_INT response is from Intruder instead of Server >>by creating the packet using >>a raw socket using [ IP spoofing]. >>3)A and X now generate the Sk key which is used to encrypt the next >>IKE_AUTH message. >>4)A sends IKE_AUTH and intruder receives the same and he is able to >>decrypt the message and get access to IDR and Auth payload. >>5)Intrudes gets hold of the AUTH data and work on it to derive the >>Pre-shared Secret { eg. Brute force}. >>6) Since The Pre-shared secret is not changes the Intruder can now behave >>has the Initiator to server[IDR] >>And complete the Ikev2 flow. >> >>Kindly share your view on the above . >> >>Thanks and Regards >>Naveen >> >>-----Original Message----- >>From: Scott Fluhrer (sfluhrer) >>Sent: Friday, August 26, 2011 7:27 PM >>To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >>Cc: 'ipsec@ietf.org' >>Subject: RE: [IPsec] DH keys calculation performance >> >> >>> -----Original Message----- >>> From: Naveen B N (nbn) >>> Sent: Friday, August 26, 2011 1:37 AM >>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav >>> Nir' >>> Cc: 'ipsec@ietf.org' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> Hi Scott, >>> if we can take care of the "Forward Secrecy", >>> When using Asymetric keys from certificates >>> To negotiate symmetric keys, then certificate >>> Can be used in place of DH Computation. >>> >>> "TO maintain "Forward Secrecy", we have to change the keys from >>> time to time based on the key length, which can be achieved by re- >>> negotiating" >> >>No, you'd have the change the asymmetric keys all well; with the private >>key, the attacker can still recover the session (symmetric) keys. >> >>Now, it's not impossible to change the public keys; however, it does >>involve generating a fresh private/public key pair. With RSA, at least, >>that's a lot more expensive than doing a single exchange (or, for that >>matter, several dozen simple exchanges), and so if the point of this is >>to reduce the total amount of computation, well, that rather misses the >>point. >> >>> >>> If this is possible then I can present a draft for the same. >>> >>> Thanks & Regards >>> Naveen >>> >>> >>> -----Original Message----- >>> From: Scott Fluhrer (sfluhrer) >>> Sent: Thursday, August 25, 2011 10:18 PM >>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' >>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >>> 'ipsec-tools-devel@lists.sourceforge.net' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> >>> > -----Original Message----- >>> > From: Naveen B N (nbn) >>> > Sent: Thursday, August 25, 2011 12:34 PM >>> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; >>> > timo.teras@iki.fi >>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >>> > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >>> ipsec- >>> > tools-devel@lists.sourceforge.net >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > Hi Scott, >>> > >>> > Please find the queries and comments inline .. >>> > >>> > Scott>- Transporting keying material lacks forward secrecy. "Forward >>> > secrecy" is the property that, if some actually recovers the entire >>> > state of one (or both) of the sides, they still won't be able to >>> > decrypt a transcript of a session that had happened earlier (because >>> > the state needed to decrypt it was zeroized when the session was >>> > closed). With key transport, it is impractical to zeroize the >>> private >>> > key used during the exchange, and with that, the attacker can decrypt >>> > the keying material, and from there, rederive the session keys. In >>> > contrast, with DH, as long as both sides zeroize the private >>> exponents >>> > and shared secrets (along with the session state), the attacker does >>> > not have enough information. >>> > >>> > Naveen>> TO maintain "Forward Secrecy", we have to change the keys >>> from >>> > time to time based on the key length, which can be achieved by re- >>> > negotiating >>> > new keys with the communicated Symmetric key. >>> > But if you say that the first session used is to derive the >>> > private key of the peer, then Asymmetric key should never be used for >>> > deriving symmetric keys >>> > Or to protect data. If Certificate are still used in TLS for >>> > negotiation of Symmetric keys, this is a major issue because they are >>> > used in important places. >>> >>> I believe you misunderstand; we're not using the asymmetric key to >>> "derive" the symmetric keys, but instead just to transport it. >>> >>> Here's the scenario: >>> - Side A picks some keying material ("premaster secret" is TLS's >>> terminology for it) >>> - Side A encrypts it with Side B's public key, and sends it to B >>> - Side B decrypts it with his own private key >>> - Both side A and side B use that keying material (and possibly other >>> information that has been exchanged) to derive the real session keys >>> >>> The problem I was discussing: what if, after the session has been shut >>> down, the attacker recovers side B's private key? This private key is >>> unlikely to be zeroized along with the session (at least, with the >>> current CA infrastructure); using this private key, the attacker could >>> decrypt the encrypted keying material (just like B did), and rederive >>> the session keys (again, just like B did). >>> >>> > >>> > Naveen>>So, Certificates should only be used for authentication in a >>> > protected environment is it. >>> > What could be the life time of the RSA keys then, how long will >>> > it take to derive a private key from a public key with the best >>> > available resources. >>> > Then it comes down to DH method being the best secured >>> > available solution for negotiating Symmetric key on the fly, without >>> > having shared keying material with the peer. >>> > >>> > Scott>- IKEv2 allows other types of authentication beyond >>> certificates; >>> > using public key encryption as a step in generating keying material >>> > would imply that we would need a different mechanism to generate >>> keying >>> > material for other types of authentication. This is certainly not >>> > impossible (in fact, IKEv1 did have different mechanisms based on >>> > authentication type, although for different reasons); the IKEv2 >>> > designers decided to unify that. >>> > >>> > Naveen>>May be Ikev2 designers feel that the intruder may selects a >>> > week authentication type if exposed in plan message, But I think we >>> are >>> > authenticating the INIT_MESSAGE in IKE_AUTH >>> > Message, so they could have provided a authentication method >>> in >>> > IKE_INIT message. >>> > >>> > >>> > Thanks and Regards >>> > Naveen >>> > >>> > -----Original Message----- >>> > From: Scott Fluhrer (sfluhrer) >>> > Sent: Thursday, August 25, 2011 6:57 PM >>> > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir >>> > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Naveen B N (nbn) >>> > > Sent: Thursday, August 25, 2011 6:48 AM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > Hi , >>> > > Can we not use the existing RSA keys to get the shared secret >>> without >>> > > using the DH computation >>> > > Because of the calculation that are involved. >>> > > Let's say A wants to initiate a session with B. >>> > > Let A get the Public key of B from CA by sending a protected >>> message >>> > > using public key of CA. >>> > > Use the obtained public key for sending the shared secret to B and >>> > same >>> > > from the other >>> > > End has well, this will ensure authentication and avoiding DH >>> > > computation. >>> > > >>> > > I feel that certificate can be used for authentication and as well >>> > has >>> > > negotiated Symmetric key using the >>> > > Concept of Asymmetric cryptography which is one of the good >>> features >>> > > of certificate. >>> > > >>> > > Why in Ikev2, certificates are just used for authentication and why >>> > > they are not used for >>> > > negotiating Symmetric key instead in place of DH computation. Is it >>> > to >>> > > avoid use of Trusted CA negotiation. >>> > >>> > Well, you certainly can use certificates (with public key encryption >>> > keys) to transport keying material; indeed, the ciphersuite of TLS >>> that >>> > is in general use does exactly that. >>> > >>> > However, it does have a few drawbacks. Here are some of the reasons >>> > that the IKEv2 designers may have chosen not to use it: >>> > >>> > - Transporting keying material lacks forward secrecy. "Forward >>> > secrecy" is the property that, if some actually recovers the entire >>> > state of one (or both) of the sides, they still won't be able to >>> > decrypt a transcript of a session that had happened earlier (because >>> > the state needed to decrypt it was zeroized when the session was >>> > closed). With key transport, it is impractical to zeroize the >>> private >>> > key used during the exchange, and with that, the attacker can decrypt >>> > the keying material, and from there, rederive the session keys. In >>> > contrast, with DH, as long as both sides zeroize the private >>> exponents >>> > and shared secrets (along with the session state), the attacker does >>> > not have enough information. >>> > >>> > - IKEv2 allows other types of authentication beyond certificates; >>> using >>> > public key encryption as a step in generating keying material would >>> > imply that we would need a different mechanism to generate keying >>> > material for other types of authentication. This is certainly not >>> > impossible (in fact, IKEv1 did have different mechanisms based on >>> > authentication type, although for different reasons); the IKEv2 >>> > designers decided to unify that. >>> > >>> > > >>> > > Thanks and Regards >>> > > Naveen >>> > > >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Prashant Batra (prbatra) >>> > > Sent: Tuesday, July 26, 2011 6:33 PM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > Thanks Yoav and Yaron for the suggestions. >>> > > Even I was thinking and tried generating and storing the key pair >>> > well >>> > > in the beginning,. This helped to some extent. >>> > > >>> > > The secret calculation is also very expensive, but this has to be >>> > done >>> > > in midst of the exchange only. >>> > > >>> > > Regards, >>> > > Prashant >>> > > >>> > > >>> > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> > > Sent: Tuesday, July 26, 2011 4:47 PM >>> > > To: Yoav Nir >>> > > Cc: Prashant Batra (prbatra); ipsec@ietf.org >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > You might want to review >>> http://tools.ietf.org/html/rfc5996#section- >>> > > 2.12. >>> > > >>> > > Also, session resumption (http://tools.ietf.org/html/rfc5723) >>> reduces >>> > > the computational costs of renewing an IKE SA when a client needs >>> to >>> > > reconnect to a gateway a second time after some failure. >>> > > >>> > > Thanks, >>> > > Yaron >>> > > >>> > > On 07/26/2011 01:40 PM, Yoav Nir wrote: >>> > > >>> > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >>> > > >>> > > Hello, >>> > > >>> > > The DH exchange (Calculation of Public/Private key and the Secret) >>> in >>> > > IKEV2 Initial exchange >>> > > seems to be very expensive. This is slowing down the overall IKEv2 >>> > > tunnel establishment. >>> > > Is there a way to optimize it? >>> > > >>> > > Hi Prashant. >>> > > >>> > > I know of three ways to optimize the D-H exchange. >>> > > >>> > > First, note that each peer has to perform two operations: >>> > > 1. Generate: create a random x and calculate X=3D2^x mod p >>> > > 2. Derive: calculate the shared secret S=3DY^x mod p >>> > > The "Derive" operation has to be done during the exchange, but the >>> > > "Generate" operation can be done long before the exchange. If your >>> > > problem is degraded performance at some peak, you can pre-generate >>> > some >>> > > values. This has a high cost in memory, but can be useful for >>> dealing >>> > > with peaks. >>> > > >>> > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 >>> mod >>> > > p)) mod p >>> > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod >>> p >>> > > for 0<=3Dx<=3D2048 and store these values. After that, both the >>> generate >>> > > and derive operations become simple multiplications of the >>> resulting >>> > > values. This has a fixed cost in memory, but can accelerate things. >>> > > >>> > > Third, you may want to look at the EC groups. The EC operations >>> > require >>> > > less computation. >>> > > >>> > > Hope this helps >>> > > >>> > > Yoav >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >> >>Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kent@bbn.com Mon Aug 29 02:21:47 2011 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 5FCCB21F8839 for ; Mon, 29 Aug 2011 02:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8W4UtzUl-fk for ; Mon, 29 Aug 2011 02:21:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6859C21F8802 for ; Mon, 29 Aug 2011 02:21:46 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48354 helo=[218.146.105.109]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qxy3J-00089o-56; Mon, 29 Aug 2011 05:23:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20013.29623.491247.654466@fireball.kivinen.iki.fi><90AEF529-7273-4695-BA31-4F221A4A CF45@checkpoint.com><4E2EA248.70708@gmail.com> Date: Mon, 29 Aug 2011 05:21:20 -0400 To: "Naveen B N (nbn)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org, Yoav Nir , "Rajeshwar Singh Jenwar \(rsj\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Perfect Forward secrecy 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, 29 Aug 2011 09:21:47 -0000 At 11:24 AM +0530 8/29/11, Naveen B N (nbn) wrote: >Hi Scott, >Even with the Pre-shared secret, the protocol can't keep up the >property of " perfect Forward secrecy". >I have assumed the both the server and client use pre-shared secret, >same below methods applies to Certificate based >Authentication has well. >Below steps show why. PFS refers to the ability of an adversary to recover the symmetric key(s) used to encrypt traffic. The analysis you provided does not address that concern. IKE's use of ephemeral DH provides PFS. Steve From nbn@cisco.com Mon Aug 29 03:18:18 2011 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 0F60B21F886A for ; Mon, 29 Aug 2011 03:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20UGlaesTzkA for ; Mon, 29 Aug 2011 03:18:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 822E821F8ACE for ; Mon, 29 Aug 2011 03:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=17247; q=dns/txt; s=iport; t=1314613178; x=1315822778; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=E24nGvrCvSgLmlK9R6A+BHcb3sYs5a9r0J9W0KaFcBU=; b=eMCyKRIq3Lz6c6NG3UxqwQ2RAuV0xz9fAjKKRG0p6M//3a9WWCHOKYvL DAI08uAVpaKn+9dowQvGzyxKT4eZn9QxmAWMEq6OeJM2kCSYvornM17v1 1A+kYYlbZtkS4ibb6mTBJPWzbpcAplTNVOEyKE1KgD7uEaO04/q4kxGak A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAINmW05Io8US/2dsb2JhbABCmCePWHeBQAEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEgBgEeCQgBAQQBCggIEQIHh1SYUgGeGYVsYASHYokshyiEYocT X-IronPort-AV: E=Sophos;i="4.68,296,1312156800"; d="scan'208";a="112948733" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2011 10:19:35 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7TAJZiv031847; Mon, 29 Aug 2011 10:19:35 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 15:49:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 15:49:34 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Avoid multiple authentication's thread-index: AcxmFT7HSJrT7ZNdSCu10vugR9oW1QAD1XkgAAQSDlA= References: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> From: "Naveen B N (nbn)" To: "Dan Harkins" , "Yoav Nir" X-OriginalArrivalTime: 29 Aug 2011 10:19:35.0373 (UTC) FILETIME=[26987FD0:01CC6635] Cc: ipsec@ietf.org, "Saravana Ravindran \(sarravin\)" , "Sastry SK \(sassk\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Avoid multiple authentication's 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, 29 Aug 2011 10:18:18 -0000 Hi Dan and Yoav Nir, Thank you and appreciate for the timely comments on my view and=20 sharing the drafts for the same. I was thinking to bring a Token concept in Ikev2 which will be=20 Given by the responder, so that the session keys is bound to a=20 life time and If the Key is still valid IKE_INIT can be skipped and IKE_AUTH is directly used even in the next sessions.=20 Tokens=3D Session key + Life time. The above will save DH computation and key negotiation in case=20 the session was aborted for some reason and if the client has=20 multiple make break of sessions. The above will save multiple times of authentication of client=20 who was already authenticated. Kindly share your views on token to be used has authenticators For multiple sessions. Thanks and Regards Naveen -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org]=20 Sent: Monday, August 29, 2011 12:01 PM To: Yoav Nir Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar Singh Jenwar (rsj); ipsec@ietf.org Subject: Re: [IPsec] Perfect Forward secrecy Hi Naveen, Yoav is right that increasing the size of the secret, and ensuring it is uniformly random, will mitigate this sort of dictionary attack. And the 3 drafts he mentions will basically foil it entirely. But the attack you mention does not affect "perfect forward secrecy". That is the property that even with the loss of a long term credential (like the pre-shared secret learned by dictionary attack) the adversary is unable to determine the session key from a different run of the protocol. This property still holds even with a successful dictionary attack against a pre-shared key. regards, Dan. On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote: > Hi Naveen > > If you use a 128-bit or 256-bit truly random shared secret (like you > should, although probably nobody does), brute force will never work. If > you use a weaker shared secret, such as something with 20-40 bits of > entropy, then your offline dictionary attack becomes practical. > > For suggested ways of counteracting this, take a look at these: > http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut > http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2 > http://tools.ietf.org/html/draft-shin-augmented-pake > > On 8/29/11 8:54 AM, "Naveen B N (nbn)" wrote: > >>Hi Scott, >>Even with the Pre-shared secret, the protocol can't keep up the property >>of " perfect Forward secrecy". >>I have assumed the both the server and client use pre-shared secret, same >>below methods applies to Certificate based >>Authentication has well. >>Below steps show why. >> >>Subject: Intruder X acts has server only to get the access of auth >>payload. >> >>1)A send IKE_INIT to indented server. >>2) X[ intruder ] receives the INIT and process just has the protocol and >>replies with the generated >>public value for DH. IKE_INT response is from Intruder instead of Server >>by creating the packet using >>a raw socket using [ IP spoofing]. >>3)A and X now generate the Sk key which is used to encrypt the next >>IKE_AUTH message. >>4)A sends IKE_AUTH and intruder receives the same and he is able to >>decrypt the message and get access to IDR and Auth payload. >>5)Intrudes gets hold of the AUTH data and work on it to derive the >>Pre-shared Secret { eg. Brute force}. >>6) Since The Pre-shared secret is not changes the Intruder can now behave >>has the Initiator to server[IDR] >>And complete the Ikev2 flow. >> >>Kindly share your view on the above . >> >>Thanks and Regards >>Naveen >> >>-----Original Message----- >>From: Scott Fluhrer (sfluhrer) >>Sent: Friday, August 26, 2011 7:27 PM >>To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >>Cc: 'ipsec@ietf.org' >>Subject: RE: [IPsec] DH keys calculation performance >> >> >>> -----Original Message----- >>> From: Naveen B N (nbn) >>> Sent: Friday, August 26, 2011 1:37 AM >>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav >>> Nir' >>> Cc: 'ipsec@ietf.org' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> Hi Scott, >>> if we can take care of the "Forward Secrecy", >>> When using Asymetric keys from certificates >>> To negotiate symmetric keys, then certificate >>> Can be used in place of DH Computation. >>> >>> "TO maintain "Forward Secrecy", we have to change the keys from >>> time to time based on the key length, which can be achieved by re- >>> negotiating" >> >>No, you'd have the change the asymmetric keys all well; with the private >>key, the attacker can still recover the session (symmetric) keys. >> >>Now, it's not impossible to change the public keys; however, it does >>involve generating a fresh private/public key pair. With RSA, at least, >>that's a lot more expensive than doing a single exchange (or, for that >>matter, several dozen simple exchanges), and so if the point of this is >>to reduce the total amount of computation, well, that rather misses the >>point. >> >>> >>> If this is possible then I can present a draft for the same. >>> >>> Thanks & Regards >>> Naveen >>> >>> >>> -----Original Message----- >>> From: Scott Fluhrer (sfluhrer) >>> Sent: Thursday, August 25, 2011 10:18 PM >>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.teras@iki.fi' >>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >>> 'ipsec-tools-devel@lists.sourceforge.net' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> >>> > -----Original Message----- >>> > From: Naveen B N (nbn) >>> > Sent: Thursday, August 25, 2011 12:34 PM >>> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; >>> > timo.teras@iki.fi >>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >>> > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >>> ipsec- >>> > tools-devel@lists.sourceforge.net >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > Hi Scott, >>> > >>> > Please find the queries and comments inline .. >>> > >>> > Scott>- Transporting keying material lacks forward secrecy. "Forward >>> > secrecy" is the property that, if some actually recovers the entire >>> > state of one (or both) of the sides, they still won't be able to >>> > decrypt a transcript of a session that had happened earlier (because >>> > the state needed to decrypt it was zeroized when the session was >>> > closed). With key transport, it is impractical to zeroize the >>> private >>> > key used during the exchange, and with that, the attacker can decrypt >>> > the keying material, and from there, rederive the session keys. In >>> > contrast, with DH, as long as both sides zeroize the private >>> exponents >>> > and shared secrets (along with the session state), the attacker does >>> > not have enough information. >>> > >>> > Naveen>> TO maintain "Forward Secrecy", we have to change the keys >>> from >>> > time to time based on the key length, which can be achieved by re- >>> > negotiating >>> > new keys with the communicated Symmetric key. >>> > But if you say that the first session used is to derive the >>> > private key of the peer, then Asymmetric key should never be used for >>> > deriving symmetric keys >>> > Or to protect data. If Certificate are still used in TLS for >>> > negotiation of Symmetric keys, this is a major issue because they are >>> > used in important places. >>> >>> I believe you misunderstand; we're not using the asymmetric key to >>> "derive" the symmetric keys, but instead just to transport it. >>> >>> Here's the scenario: >>> - Side A picks some keying material ("premaster secret" is TLS's >>> terminology for it) >>> - Side A encrypts it with Side B's public key, and sends it to B >>> - Side B decrypts it with his own private key >>> - Both side A and side B use that keying material (and possibly other >>> information that has been exchanged) to derive the real session keys >>> >>> The problem I was discussing: what if, after the session has been shut >>> down, the attacker recovers side B's private key? This private key is >>> unlikely to be zeroized along with the session (at least, with the >>> current CA infrastructure); using this private key, the attacker could >>> decrypt the encrypted keying material (just like B did), and rederive >>> the session keys (again, just like B did). >>> >>> > >>> > Naveen>>So, Certificates should only be used for authentication in a >>> > protected environment is it. >>> > What could be the life time of the RSA keys then, how long will >>> > it take to derive a private key from a public key with the best >>> > available resources. >>> > Then it comes down to DH method being the best secured >>> > available solution for negotiating Symmetric key on the fly, without >>> > having shared keying material with the peer. >>> > >>> > Scott>- IKEv2 allows other types of authentication beyond >>> certificates; >>> > using public key encryption as a step in generating keying material >>> > would imply that we would need a different mechanism to generate >>> keying >>> > material for other types of authentication. This is certainly not >>> > impossible (in fact, IKEv1 did have different mechanisms based on >>> > authentication type, although for different reasons); the IKEv2 >>> > designers decided to unify that. >>> > >>> > Naveen>>May be Ikev2 designers feel that the intruder may selects a >>> > week authentication type if exposed in plan message, But I think we >>> are >>> > authenticating the INIT_MESSAGE in IKE_AUTH >>> > Message, so they could have provided a authentication method >>> in >>> > IKE_INIT message. >>> > >>> > >>> > Thanks and Regards >>> > Naveen >>> > >>> > -----Original Message----- >>> > From: Scott Fluhrer (sfluhrer) >>> > Sent: Thursday, August 25, 2011 6:57 PM >>> > To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir >>> > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Naveen B N (nbn) >>> > > Sent: Thursday, August 25, 2011 6:48 AM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > Hi , >>> > > Can we not use the existing RSA keys to get the shared secret >>> without >>> > > using the DH computation >>> > > Because of the calculation that are involved. >>> > > Let's say A wants to initiate a session with B. >>> > > Let A get the Public key of B from CA by sending a protected >>> message >>> > > using public key of CA. >>> > > Use the obtained public key for sending the shared secret to B and >>> > same >>> > > from the other >>> > > End has well, this will ensure authentication and avoiding DH >>> > > computation. >>> > > >>> > > I feel that certificate can be used for authentication and as well >>> > has >>> > > negotiated Symmetric key using the >>> > > Concept of Asymmetric cryptography which is one of the good >>> features >>> > > of certificate. >>> > > >>> > > Why in Ikev2, certificates are just used for authentication and why >>> > > they are not used for >>> > > negotiating Symmetric key instead in place of DH computation. Is it >>> > to >>> > > avoid use of Trusted CA negotiation. >>> > >>> > Well, you certainly can use certificates (with public key encryption >>> > keys) to transport keying material; indeed, the ciphersuite of TLS >>> that >>> > is in general use does exactly that. >>> > >>> > However, it does have a few drawbacks. Here are some of the reasons >>> > that the IKEv2 designers may have chosen not to use it: >>> > >>> > - Transporting keying material lacks forward secrecy. "Forward >>> > secrecy" is the property that, if some actually recovers the entire >>> > state of one (or both) of the sides, they still won't be able to >>> > decrypt a transcript of a session that had happened earlier (because >>> > the state needed to decrypt it was zeroized when the session was >>> > closed). With key transport, it is impractical to zeroize the >>> private >>> > key used during the exchange, and with that, the attacker can decrypt >>> > the keying material, and from there, rederive the session keys. In >>> > contrast, with DH, as long as both sides zeroize the private >>> exponents >>> > and shared secrets (along with the session state), the attacker does >>> > not have enough information. >>> > >>> > - IKEv2 allows other types of authentication beyond certificates; >>> using >>> > public key encryption as a step in generating keying material would >>> > imply that we would need a different mechanism to generate keying >>> > material for other types of authentication. This is certainly not >>> > impossible (in fact, IKEv1 did have different mechanisms based on >>> > authentication type, although for different reasons); the IKEv2 >>> > designers decided to unify that. >>> > >>> > > >>> > > Thanks and Regards >>> > > Naveen >>> > > >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Prashant Batra (prbatra) >>> > > Sent: Tuesday, July 26, 2011 6:33 PM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > Thanks Yoav and Yaron for the suggestions. >>> > > Even I was thinking and tried generating and storing the key pair >>> > well >>> > > in the beginning,. This helped to some extent. >>> > > >>> > > The secret calculation is also very expensive, but this has to be >>> > done >>> > > in midst of the exchange only. >>> > > >>> > > Regards, >>> > > Prashant >>> > > >>> > > >>> > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> > > Sent: Tuesday, July 26, 2011 4:47 PM >>> > > To: Yoav Nir >>> > > Cc: Prashant Batra (prbatra); ipsec@ietf.org >>> > > Subject: Re: [IPsec] DH keys calculation performance >>> > > >>> > > You might want to review >>> http://tools.ietf.org/html/rfc5996#section- >>> > > 2.12. >>> > > >>> > > Also, session resumption (http://tools.ietf.org/html/rfc5723) >>> reduces >>> > > the computational costs of renewing an IKE SA when a client needs >>> to >>> > > reconnect to a gateway a second time after some failure. >>> > > >>> > > Thanks, >>> > > Yaron >>> > > >>> > > On 07/26/2011 01:40 PM, Yoav Nir wrote: >>> > > >>> > > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >>> > > >>> > > Hello, >>> > > >>> > > The DH exchange (Calculation of Public/Private key and the Secret) >>> in >>> > > IKEV2 Initial exchange >>> > > seems to be very expensive. This is slowing down the overall IKEv2 >>> > > tunnel establishment. >>> > > Is there a way to optimize it? >>> > > >>> > > Hi Prashant. >>> > > >>> > > I know of three ways to optimize the D-H exchange. >>> > > >>> > > First, note that each peer has to perform two operations: >>> > > 1. Generate: create a random x and calculate X=3D2^x mod p >>> > > 2. Derive: calculate the shared secret S=3DY^x mod p >>> > > The "Derive" operation has to be done during the exchange, but the >>> > > "Generate" operation can be done long before the exchange. If your >>> > > problem is degraded performance at some peak, you can pre-generate >>> > some >>> > > values. This has a high cost in memory, but can be useful for >>> dealing >>> > > with peaks. >>> > > >>> > > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 >>> mod >>> > > p)) mod p >>> > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod >>> p >>> > > for 0<=3Dx<=3D2048 and store these values. After that, both the >>> generate >>> > > and derive operations become simple multiplications of the >>> resulting >>> > > values. This has a fixed cost in memory, but can accelerate things. >>> > > >>> > > Third, you may want to look at the EC groups. The EC operations >>> > require >>> > > less computation. >>> > > >>> > > Hope this helps >>> > > >>> > > Yoav >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >> >>Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Mon Aug 29 11:34:40 2011 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 9532F21F8C8C for ; Mon, 29 Aug 2011 11:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrX1+p3BFhvE for ; Mon, 29 Aug 2011 11:34:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE621F8C76 for ; Mon, 29 Aug 2011 11:34:35 -0700 (PDT) Received: by wyg8 with SMTP id 8so4861066wyg.31 for ; Mon, 29 Aug 2011 11:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=unSFfw6BJCVsVgb5z5464XWX+JrT5uf+UTFPLvC85cA=; b=Uz9R/Z461pXZ1Fls8QfxCjm/LL8HpZgDpiR7vPSEH6GZPiXd9PwEuLU5vrW/4+wsmn EeR03YIEsJdbays6H19djn1/NLOn1Sog77uMPzYwnkQ/y8v4vMjkk+eLB3QQP9SLD4Gp OhOXdpwFk47uIbRY1cnd+axTNusF6gmcDjuHU= Received: by 10.227.24.146 with SMTP id v18mr4019257wbb.84.1314642960681; Mon, 29 Aug 2011 11:36:00 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-242-252.red.bezeqint.net [79.181.242.252]) by mx.google.com with ESMTPS id et16sm3958544wbb.53.2011.08.29.11.35.56 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 11:35:59 -0700 (PDT) Message-ID: <4E5BDC0B.6000207@gmail.com> Date: Mon, 29 Aug 2011 21:35:55 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Naveen B N (nbn)" References: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yoav Nir , Dan Harkins , "Sastry SK \(sassk\)" , ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" , "Saravana Ravindran \(sarravin\)" Subject: Re: [IPsec] Avoid multiple authentication's 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, 29 Aug 2011 18:34:40 -0000 Hi Naveen, please take a look at RFC 5723, which is very similar to your idea. Thanks, Yaron On 29.8.2011 13:19, Naveen B N (nbn) wrote: > Hi Dan and Yoav Nir, > > Thank you and appreciate for the timely comments on my view and > sharing the drafts for the same. > > I was thinking to bring a Token concept in Ikev2 which will be > Given by the responder, so that the session keys is bound to a > life time and If the Key is still valid IKE_INIT can be skipped > and IKE_AUTH is directly used even in the next sessions. > > Tokens= Session key + Life time. > > The above will save DH computation and key negotiation in case > the session was aborted for some reason and if the client has > multiple make break of sessions. > > The above will save multiple times of authentication of client > who was already authenticated. > > Kindly share your views on token to be used has authenticators > For multiple sessions. > > Thanks and Regards > Naveen > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Monday, August 29, 2011 12:01 PM > To: Yoav Nir > Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar > Singh Jenwar (rsj); ipsec@ietf.org > Subject: Re: [IPsec] Perfect Forward secrecy > > > Hi Naveen, > > Yoav is right that increasing the size of the secret, and ensuring it > is uniformly random, will mitigate this sort of dictionary attack. And > the 3 drafts he mentions will basically foil it entirely. > > But the attack you mention does not affect "perfect forward secrecy". > That is the property that even with the loss of a long term credential > (like the pre-shared secret learned by dictionary attack) the adversary > is unable to determine the session key from a different run of the > protocol. This property still holds even with a successful dictionary > attack against a pre-shared key. > > regards, > > Dan. > > On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote: >> Hi Naveen >> >> If you use a 128-bit or 256-bit truly random shared secret (like you >> should, although probably nobody does), brute force will never work. > If >> you use a weaker shared secret, such as something with 20-40 bits of >> entropy, then your offline dictionary attack becomes practical. >> >> For suggested ways of counteracting this, take a look at these: >> http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut >> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2 >> http://tools.ietf.org/html/draft-shin-augmented-pake >> >> On 8/29/11 8:54 AM, "Naveen B N (nbn)" wrote: >> >>> Hi Scott, >>> Even with the Pre-shared secret, the protocol can't keep up the > property >>> of " perfect Forward secrecy". >>> I have assumed the both the server and client use pre-shared secret, > same >>> below methods applies to Certificate based >>> Authentication has well. >>> Below steps show why. >>> >>> Subject: Intruder X acts has server only to get the access of auth >>> payload. >>> >>> 1)A send IKE_INIT to indented server. >>> 2) X[ intruder ] receives the INIT and process just has the protocol > and >>> replies with the generated >>> public value for DH. IKE_INT response is from Intruder instead of > Server >>> by creating the packet using >>> a raw socket using [ IP spoofing]. >>> 3)A and X now generate the Sk key which is used to encrypt the next >>> IKE_AUTH message. >>> 4)A sends IKE_AUTH and intruder receives the same and he is able to >>> decrypt the message and get access to IDR and Auth payload. >>> 5)Intrudes gets hold of the AUTH data and work on it to derive the >>> Pre-shared Secret { eg. Brute force}. >>> 6) Since The Pre-shared secret is not changes the Intruder can now > behave >>> has the Initiator to server[IDR] >>> And complete the Ikev2 flow. >>> >>> Kindly share your view on the above . >>> >>> Thanks and Regards >>> Naveen >>> >>> -----Original Message----- >>> From: Scott Fluhrer (sfluhrer) >>> Sent: Friday, August 26, 2011 7:27 PM >>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >>> Cc: 'ipsec@ietf.org' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> >>>> -----Original Message----- >>>> From: Naveen B N (nbn) >>>> Sent: Friday, August 26, 2011 1:37 AM >>>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; > 'Yoav >>>> Nir' >>>> Cc: 'ipsec@ietf.org' >>>> Subject: RE: [IPsec] DH keys calculation performance >>>> >>>> Hi Scott, >>>> if we can take care of the "Forward Secrecy", >>>> When using Asymetric keys from certificates >>>> To negotiate symmetric keys, then certificate >>>> Can be used in place of DH Computation. >>>> >>>> "TO maintain "Forward Secrecy", we have to change the keys from >>>> time to time based on the key length, which can be achieved by re- >>>> negotiating" >>> No, you'd have the change the asymmetric keys all well; with the > private >>> key, the attacker can still recover the session (symmetric) keys. >>> >>> Now, it's not impossible to change the public keys; however, it does >>> involve generating a fresh private/public key pair. With RSA, at > least, >>> that's a lot more expensive than doing a single exchange (or, for that >>> matter, several dozen simple exchanges), and so if the point of this > is >>> to reduce the total amount of computation, well, that rather misses > the >>> point. >>> >>>> If this is possible then I can present a draft for the same. >>>> >>>> Thanks& Regards >>>> Naveen >>>> >>>> >>>> -----Original Message----- >>>> From: Scott Fluhrer (sfluhrer) >>>> Sent: Thursday, August 25, 2011 10:18 PM >>>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; > 'timo.teras@iki.fi' >>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >>>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >>>> 'ipsec-tools-devel@lists.sourceforge.net' >>>> Subject: RE: [IPsec] DH keys calculation performance >>>> >>>> >>>>> -----Original Message----- >>>>> From: Naveen B N (nbn) >>>>> Sent: Thursday, August 25, 2011 12:34 PM >>>>> To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; >>>>> timo.teras@iki.fi >>>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >>>>> users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >>>> ipsec- >>>>> tools-devel@lists.sourceforge.net >>>>> Subject: RE: [IPsec] DH keys calculation performance >>>>> >>>>> Hi Scott, >>>>> >>>>> Please find the queries and comments inline .. >>>>> >>>>> Scott>- Transporting keying material lacks forward secrecy. > "Forward >>>>> secrecy" is the property that, if some actually recovers the > entire >>>>> state of one (or both) of the sides, they still won't be able to >>>>> decrypt a transcript of a session that had happened earlier > (because >>>>> the state needed to decrypt it was zeroized when the session was >>>>> closed). With key transport, it is impractical to zeroize the >>>> private >>>>> key used during the exchange, and with that, the attacker can > decrypt >>>>> the keying material, and from there, rederive the session keys. > In >>>>> contrast, with DH, as long as both sides zeroize the private >>>> exponents >>>>> and shared secrets (along with the session state), the attacker > does >>>>> not have enough information. >>>>> >>>>> Naveen>> TO maintain "Forward Secrecy", we have to change the keys >>>> from >>>>> time to time based on the key length, which can be achieved by re- >>>>> negotiating >>>>> new keys with the communicated Symmetric key. >>>>> But if you say that the first session used is to derive the >>>>> private key of the peer, then Asymmetric key should never be used > for >>>>> deriving symmetric keys >>>>> Or to protect data. If Certificate are still used in TLS > for >>>>> negotiation of Symmetric keys, this is a major issue because they > are >>>>> used in important places. >>>> I believe you misunderstand; we're not using the asymmetric key to >>>> "derive" the symmetric keys, but instead just to transport it. >>>> >>>> Here's the scenario: >>>> - Side A picks some keying material ("premaster secret" is TLS's >>>> terminology for it) >>>> - Side A encrypts it with Side B's public key, and sends it to B >>>> - Side B decrypts it with his own private key >>>> - Both side A and side B use that keying material (and possibly > other >>>> information that has been exchanged) to derive the real session keys >>>> >>>> The problem I was discussing: what if, after the session has been > shut >>>> down, the attacker recovers side B's private key? This private key > is >>>> unlikely to be zeroized along with the session (at least, with the >>>> current CA infrastructure); using this private key, the attacker > could >>>> decrypt the encrypted keying material (just like B did), and > rederive >>>> the session keys (again, just like B did). >>>> >>>>> Naveen>>So, Certificates should only be used for authentication in > a >>>>> protected environment is it. >>>>> What could be the life time of the RSA keys then, how long > will >>>>> it take to derive a private key from a public key with the best >>>>> available resources. >>>>> Then it comes down to DH method being the best secured >>>>> available solution for negotiating Symmetric key on the fly, > without >>>>> having shared keying material with the peer. >>>>> >>>>> Scott>- IKEv2 allows other types of authentication beyond >>>> certificates; >>>>> using public key encryption as a step in generating keying > material >>>>> would imply that we would need a different mechanism to generate >>>> keying >>>>> material for other types of authentication. This is certainly not >>>>> impossible (in fact, IKEv1 did have different mechanisms based on >>>>> authentication type, although for different reasons); the IKEv2 >>>>> designers decided to unify that. >>>>> >>>>> Naveen>>May be Ikev2 designers feel that the intruder may selects > a >>>>> week authentication type if exposed in plan message, But I think > we >>>> are >>>>> authenticating the INIT_MESSAGE in IKE_AUTH >>>>> Message, so they could have provided a authentication > method >>>> in >>>>> IKE_INIT message. >>>>> >>>>> >>>>> Thanks and Regards >>>>> Naveen >>>>> >>>>> -----Original Message----- >>>>> From: Scott Fluhrer (sfluhrer) >>>>> Sent: Thursday, August 25, 2011 6:57 PM >>>>> To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir >>>>> Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>>>> Subject: RE: [IPsec] DH keys calculation performance >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Naveen B N (nbn) >>>>>> Sent: Thursday, August 25, 2011 6:48 AM >>>>>> To: Yaron Sheffer; Yoav Nir >>>>>> Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>>>>> Subject: Re: [IPsec] DH keys calculation performance >>>>>> >>>>>> Hi , >>>>>> Can we not use the existing RSA keys to get the shared secret >>>> without >>>>>> using the DH computation >>>>>> Because of the calculation that are involved. >>>>>> Let's say A wants to initiate a session with B. >>>>>> Let A get the Public key of B from CA by sending a protected >>>> message >>>>>> using public key of CA. >>>>>> Use the obtained public key for sending the shared secret to B > and >>>>> same >>>>>> from the other >>>>>> End has well, this will ensure authentication and avoiding DH >>>>>> computation. >>>>>> >>>>>> I feel that certificate can be used for authentication and as > well >>>>> has >>>>>> negotiated Symmetric key using the >>>>>> Concept of Asymmetric cryptography which is one of the good >>>> features >>>>>> of certificate. >>>>>> >>>>>> Why in Ikev2, certificates are just used for authentication and > why >>>>>> they are not used for >>>>>> negotiating Symmetric key instead in place of DH computation. Is > it >>>>> to >>>>>> avoid use of Trusted CA negotiation. >>>>> Well, you certainly can use certificates (with public key > encryption >>>>> keys) to transport keying material; indeed, the ciphersuite of TLS >>>> that >>>>> is in general use does exactly that. >>>>> >>>>> However, it does have a few drawbacks. Here are some of the > reasons >>>>> that the IKEv2 designers may have chosen not to use it: >>>>> >>>>> - Transporting keying material lacks forward secrecy. "Forward >>>>> secrecy" is the property that, if some actually recovers the > entire >>>>> state of one (or both) of the sides, they still won't be able to >>>>> decrypt a transcript of a session that had happened earlier > (because >>>>> the state needed to decrypt it was zeroized when the session was >>>>> closed). With key transport, it is impractical to zeroize the >>>> private >>>>> key used during the exchange, and with that, the attacker can > decrypt >>>>> the keying material, and from there, rederive the session keys. > In >>>>> contrast, with DH, as long as both sides zeroize the private >>>> exponents >>>>> and shared secrets (along with the session state), the attacker > does >>>>> not have enough information. >>>>> >>>>> - IKEv2 allows other types of authentication beyond certificates; >>>> using >>>>> public key encryption as a step in generating keying material > would >>>>> imply that we would need a different mechanism to generate keying >>>>> material for other types of authentication. This is certainly not >>>>> impossible (in fact, IKEv1 did have different mechanisms based on >>>>> authentication type, although for different reasons); the IKEv2 >>>>> designers decided to unify that. >>>>> >>>>>> Thanks and Regards >>>>>> Naveen >>>>>> >>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Prashant Batra (prbatra) >>>>>> Sent: Tuesday, July 26, 2011 6:33 PM >>>>>> To: Yaron Sheffer; Yoav Nir >>>>>> Cc: ipsec@ietf.org >>>>>> Subject: Re: [IPsec] DH keys calculation performance >>>>>> >>>>>> Thanks Yoav and Yaron for the suggestions. >>>>>> Even I was thinking and tried generating and storing the key > pair >>>>> well >>>>>> in the beginning,. This helped to some extent. >>>>>> >>>>>> The secret calculation is also very expensive, but this has to > be >>>>> done >>>>>> in midst of the exchange only. >>>>>> >>>>>> Regards, >>>>>> Prashant >>>>>> >>>>>> >>>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>>>> Sent: Tuesday, July 26, 2011 4:47 PM >>>>>> To: Yoav Nir >>>>>> Cc: Prashant Batra (prbatra); ipsec@ietf.org >>>>>> Subject: Re: [IPsec] DH keys calculation performance >>>>>> >>>>>> You might want to review >>>> http://tools.ietf.org/html/rfc5996#section- >>>>>> 2.12. >>>>>> >>>>>> Also, session resumption (http://tools.ietf.org/html/rfc5723) >>>> reduces >>>>>> the computational costs of renewing an IKE SA when a client > needs >>>> to >>>>>> reconnect to a gateway a second time after some failure. >>>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> >>>>>> On 07/26/2011 01:40 PM, Yoav Nir wrote: >>>>>> >>>>>> On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> The DH exchange (Calculation of Public/Private key and the > Secret) >>>> in >>>>>> IKEV2 Initial exchange >>>>>> seems to be very expensive. This is slowing down the overall > IKEv2 >>>>>> tunnel establishment. >>>>>> Is there a way to optimize it? >>>>>> >>>>>> Hi Prashant. >>>>>> >>>>>> I know of three ways to optimize the D-H exchange. >>>>>> >>>>>> First, note that each peer has to perform two operations: >>>>>> 1. Generate: create a random x and calculate X=2^x mod p >>>>>> 2. Derive: calculate the shared secret S=Y^x mod p >>>>>> The "Derive" operation has to be done during the exchange, but > the >>>>>> "Generate" operation can be done long before the exchange. If > your >>>>>> problem is degraded performance at some peak, you can > pre-generate >>>>> some >>>>>> values. This has a high cost in memory, but can be useful for >>>> dealing >>>>>> with peaks. >>>>>> >>>>>> Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * > (2^1 >>>> mod >>>>>> p)) mod p >>>>>> If you're using a 2048-bit D-H group, you can pre-calculate 2^x > mod >>>> p >>>>>> for 0<=x<=2048 and store these values. After that, both the >>>> generate >>>>>> and derive operations become simple multiplications of the >>>> resulting >>>>>> values. This has a fixed cost in memory, but can accelerate > things. >>>>>> Third, you may want to look at the EC groups. The EC operations >>>>> require >>>>>> less computation. >>>>>> >>>>>> Hope this helps >>>>>> >>>>>> Yoav >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>> Scanned by Check Point Total Security Gateway. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nbn@cisco.com Mon Aug 29 22:45:18 2011 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 6DBEC21F8AB8 for ; Mon, 29 Aug 2011 22:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbZ3g4qguSpi for ; Mon, 29 Aug 2011 22:45:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E263621F8AAC for ; Mon, 29 Aug 2011 22:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=19117; q=dns/txt; s=iport; t=1314683202; x=1315892802; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1/ZzqkvdtJSZZXYXTfrdpsMLxUV6fNn/yOGA+KXMMOE=; b=B1GXt3ToRyK/HJxShXhii+ejFvIVwy8iQv8eDxTWIPabSoeFzYE+zlxP 0KD/ONg3+17nMtRHgvDpV0eTnmHx/tw5F71SSLxA8XZYrQrGqbpKaVYYP Q3fifXVxGgSN+MFRacpWOm1y8EAjf/F3Jj7pUP1hzGKwHdrwMnHK1oBu4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcAALJ4XE5Io8UQ/2dsb2JhbABDmCqPXXeBQAEBAQEDAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASAGAR4JCAEBBAsICBECB4dUl3ABn0iFbWAEh2SJL4cohGKHE4Fy X-IronPort-AV: E=Sophos;i="4.68,300,1312156800"; d="scan'208";a="113137490" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2011 05:46:34 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7U5kXsY030473; Tue, 30 Aug 2011 05:46:34 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 11:16:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 11:16:32 +0530 Message-ID: In-Reply-To: <4E5BDC0B.6000207@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Avoid multiple authentication's thread-index: AcxmeoRYjATZPkZSRmSoXvZPHQM0nAAWgtKQ References: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> <4E5BDC0B.6000207@gmail.com> From: "Naveen B N (nbn)" To: "Yaron Sheffer" X-OriginalArrivalTime: 30 Aug 2011 05:46:33.0989 (UTC) FILETIME=[2CF16B50:01CC66D8] Cc: Yoav Nir , Dan Harkins , "Sastry SK \(sassk\)" , ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" , "Saravana Ravindran \(sarravin\)" Subject: Re: [IPsec] Avoid multiple authentication's 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, 30 Aug 2011 05:45:18 -0000 Hi Yaorn, Pleased to know that there is an RFC which is similar to=20 My idea already, but I am happy to know that I am thinking in right direction, thanks you for your reply. Also please find the below idea has well. In the years to come since there are plenty of=20 IPv6 address available. An organization may have=20 Multiple entry points to its network and hope=20 Most of the organization want to provider Work=20 >From home has well :).=20 Don't you think that the gateway needs to handle all the Authentication by itself for so many users, will it=20 Not be better to offload only authentication process to=20 a IKEV2 server, so that there is one dedicates server=20 to perform the token based authentication. What i really want to propose is a Ikev2 client - server=20 Model, where the gateway needs to only accept a part=20 Of the message has authenticator and dedicate itself=20 to perform what it is really meant for. Kindly share your views on the above. Thanks and Regards Naveen -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Tuesday, August 30, 2011 12:06 AM To: Naveen B N (nbn) Cc: Dan Harkins; Yoav Nir; ipsec@ietf.org; Saravana Ravindran (sarravin); Sastry SK (sassk); Scott Fluhrer (sfluhrer) Subject: Re: [IPsec] Avoid multiple authentication's Hi Naveen, please take a look at RFC 5723, which is very similar to your idea. Thanks, Yaron On 29.8.2011 13:19, Naveen B N (nbn) wrote: > Hi Dan and Yoav Nir, > > Thank you and appreciate for the timely comments on my view and > sharing the drafts for the same. > > I was thinking to bring a Token concept in Ikev2 which will be > Given by the responder, so that the session keys is bound to a > life time and If the Key is still valid IKE_INIT can be skipped > and IKE_AUTH is directly used even in the next sessions. > > Tokens=3D Session key + Life time. > > The above will save DH computation and key negotiation in case > the session was aborted for some reason and if the client has > multiple make break of sessions. > > The above will save multiple times of authentication of client > who was already authenticated. > > Kindly share your views on token to be used has authenticators > For multiple sessions. > > Thanks and Regards > Naveen > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Monday, August 29, 2011 12:01 PM > To: Yoav Nir > Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar > Singh Jenwar (rsj); ipsec@ietf.org > Subject: Re: [IPsec] Perfect Forward secrecy > > > Hi Naveen, > > Yoav is right that increasing the size of the secret, and ensuring it > is uniformly random, will mitigate this sort of dictionary attack. And > the 3 drafts he mentions will basically foil it entirely. > > But the attack you mention does not affect "perfect forward secrecy". > That is the property that even with the loss of a long term credential > (like the pre-shared secret learned by dictionary attack) the adversary > is unable to determine the session key from a different run of the > protocol. This property still holds even with a successful dictionary > attack against a pre-shared key. > > regards, > > Dan. > > On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote: >> Hi Naveen >> >> If you use a 128-bit or 256-bit truly random shared secret (like you >> should, although probably nobody does), brute force will never work. > If >> you use a weaker shared secret, such as something with 20-40 bits of >> entropy, then your offline dictionary attack becomes practical. >> >> For suggested ways of counteracting this, take a look at these: >> http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut >> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2 >> http://tools.ietf.org/html/draft-shin-augmented-pake >> >> On 8/29/11 8:54 AM, "Naveen B N (nbn)" wrote: >> >>> Hi Scott, >>> Even with the Pre-shared secret, the protocol can't keep up the > property >>> of " perfect Forward secrecy". >>> I have assumed the both the server and client use pre-shared secret, > same >>> below methods applies to Certificate based >>> Authentication has well. >>> Below steps show why. >>> >>> Subject: Intruder X acts has server only to get the access of auth >>> payload. >>> >>> 1)A send IKE_INIT to indented server. >>> 2) X[ intruder ] receives the INIT and process just has the protocol > and >>> replies with the generated >>> public value for DH. IKE_INT response is from Intruder instead of > Server >>> by creating the packet using >>> a raw socket using [ IP spoofing]. >>> 3)A and X now generate the Sk key which is used to encrypt the next >>> IKE_AUTH message. >>> 4)A sends IKE_AUTH and intruder receives the same and he is able to >>> decrypt the message and get access to IDR and Auth payload. >>> 5)Intrudes gets hold of the AUTH data and work on it to derive the >>> Pre-shared Secret { eg. Brute force}. >>> 6) Since The Pre-shared secret is not changes the Intruder can now > behave >>> has the Initiator to server[IDR] >>> And complete the Ikev2 flow. >>> >>> Kindly share your view on the above . >>> >>> Thanks and Regards >>> Naveen >>> >>> -----Original Message----- >>> From: Scott Fluhrer (sfluhrer) >>> Sent: Friday, August 26, 2011 7:27 PM >>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir' >>> Cc: 'ipsec@ietf.org' >>> Subject: RE: [IPsec] DH keys calculation performance >>> >>> >>>> -----Original Message----- >>>> From: Naveen B N (nbn) >>>> Sent: Friday, August 26, 2011 1:37 AM >>>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; > 'Yoav >>>> Nir' >>>> Cc: 'ipsec@ietf.org' >>>> Subject: RE: [IPsec] DH keys calculation performance >>>> >>>> Hi Scott, >>>> if we can take care of the "Forward Secrecy", >>>> When using Asymetric keys from certificates >>>> To negotiate symmetric keys, then certificate >>>> Can be used in place of DH Computation. >>>> >>>> "TO maintain "Forward Secrecy", we have to change the keys from >>>> time to time based on the key length, which can be achieved by re- >>>> negotiating" >>> No, you'd have the change the asymmetric keys all well; with the > private >>> key, the attacker can still recover the session (symmetric) keys. >>> >>> Now, it's not impossible to change the public keys; however, it does >>> involve generating a fresh private/public key pair. With RSA, at > least, >>> that's a lot more expensive than doing a single exchange (or, for that >>> matter, several dozen simple exchanges), and so if the point of this > is >>> to reduce the total amount of computation, well, that rather misses > the >>> point. >>> >>>> If this is possible then I can present a draft for the same. >>>> >>>> Thanks& Regards >>>> Naveen >>>> >>>> >>>> -----Original Message----- >>>> From: Scott Fluhrer (sfluhrer) >>>> Sent: Thursday, August 25, 2011 10:18 PM >>>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; > 'timo.teras@iki.fi' >>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >>>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >>>> 'ipsec-tools-devel@lists.sourceforge.net' >>>> Subject: RE: [IPsec] DH keys calculation performance >>>> >>>> >>>>> -----Original Message----- >>>>> From: Naveen B N (nbn) >>>>> Sent: Thursday, August 25, 2011 12:34 PM >>>>> To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir'; >>>>> timo.teras@iki.fi >>>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >>>>> users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >>>> ipsec- >>>>> tools-devel@lists.sourceforge.net >>>>> Subject: RE: [IPsec] DH keys calculation performance >>>>> >>>>> Hi Scott, >>>>> >>>>> Please find the queries and comments inline .. >>>>> >>>>> Scott>- Transporting keying material lacks forward secrecy. > "Forward >>>>> secrecy" is the property that, if some actually recovers the > entire >>>>> state of one (or both) of the sides, they still won't be able to >>>>> decrypt a transcript of a session that had happened earlier > (because >>>>> the state needed to decrypt it was zeroized when the session was >>>>> closed). With key transport, it is impractical to zeroize the >>>> private >>>>> key used during the exchange, and with that, the attacker can > decrypt >>>>> the keying material, and from there, rederive the session keys. > In >>>>> contrast, with DH, as long as both sides zeroize the private >>>> exponents >>>>> and shared secrets (along with the session state), the attacker > does >>>>> not have enough information. >>>>> >>>>> Naveen>> TO maintain "Forward Secrecy", we have to change the keys >>>> from >>>>> time to time based on the key length, which can be achieved by re- >>>>> negotiating >>>>> new keys with the communicated Symmetric key. >>>>> But if you say that the first session used is to derive the >>>>> private key of the peer, then Asymmetric key should never be used > for >>>>> deriving symmetric keys >>>>> Or to protect data. If Certificate are still used in TLS > for >>>>> negotiation of Symmetric keys, this is a major issue because they > are >>>>> used in important places. >>>> I believe you misunderstand; we're not using the asymmetric key to >>>> "derive" the symmetric keys, but instead just to transport it. >>>> >>>> Here's the scenario: >>>> - Side A picks some keying material ("premaster secret" is TLS's >>>> terminology for it) >>>> - Side A encrypts it with Side B's public key, and sends it to B >>>> - Side B decrypts it with his own private key >>>> - Both side A and side B use that keying material (and possibly > other >>>> information that has been exchanged) to derive the real session keys >>>> >>>> The problem I was discussing: what if, after the session has been > shut >>>> down, the attacker recovers side B's private key? This private key > is >>>> unlikely to be zeroized along with the session (at least, with the >>>> current CA infrastructure); using this private key, the attacker > could >>>> decrypt the encrypted keying material (just like B did), and > rederive >>>> the session keys (again, just like B did). >>>> >>>>> Naveen>>So, Certificates should only be used for authentication in > a >>>>> protected environment is it. >>>>> What could be the life time of the RSA keys then, how long > will >>>>> it take to derive a private key from a public key with the best >>>>> available resources. >>>>> Then it comes down to DH method being the best secured >>>>> available solution for negotiating Symmetric key on the fly, > without >>>>> having shared keying material with the peer. >>>>> >>>>> Scott>- IKEv2 allows other types of authentication beyond >>>> certificates; >>>>> using public key encryption as a step in generating keying > material >>>>> would imply that we would need a different mechanism to generate >>>> keying >>>>> material for other types of authentication. This is certainly not >>>>> impossible (in fact, IKEv1 did have different mechanisms based on >>>>> authentication type, although for different reasons); the IKEv2 >>>>> designers decided to unify that. >>>>> >>>>> Naveen>>May be Ikev2 designers feel that the intruder may selects > a >>>>> week authentication type if exposed in plan message, But I think > we >>>> are >>>>> authenticating the INIT_MESSAGE in IKE_AUTH >>>>> Message, so they could have provided a authentication > method >>>> in >>>>> IKE_INIT message. >>>>> >>>>> >>>>> Thanks and Regards >>>>> Naveen >>>>> >>>>> -----Original Message----- >>>>> From: Scott Fluhrer (sfluhrer) >>>>> Sent: Thursday, August 25, 2011 6:57 PM >>>>> To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir >>>>> Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>>>> Subject: RE: [IPsec] DH keys calculation performance >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Naveen B N (nbn) >>>>>> Sent: Thursday, August 25, 2011 6:48 AM >>>>>> To: Yaron Sheffer; Yoav Nir >>>>>> Cc: ipsec@ietf.org; Prashant Batra (prbatra) >>>>>> Subject: Re: [IPsec] DH keys calculation performance >>>>>> >>>>>> Hi , >>>>>> Can we not use the existing RSA keys to get the shared secret >>>> without >>>>>> using the DH computation >>>>>> Because of the calculation that are involved. >>>>>> Let's say A wants to initiate a session with B. >>>>>> Let A get the Public key of B from CA by sending a protected >>>> message >>>>>> using public key of CA. >>>>>> Use the obtained public key for sending the shared secret to B > and >>>>> same >>>>>> from the other >>>>>> End has well, this will ensure authentication and avoiding DH >>>>>> computation. >>>>>> >>>>>> I feel that certificate can be used for authentication and as > well >>>>> has >>>>>> negotiated Symmetric key using the >>>>>> Concept of Asymmetric cryptography which is one of the good >>>> features >>>>>> of certificate. >>>>>> >>>>>> Why in Ikev2, certificates are just used for authentication and > why >>>>>> they are not used for >>>>>> negotiating Symmetric key instead in place of DH computation. Is > it >>>>> to >>>>>> avoid use of Trusted CA negotiation. >>>>> Well, you certainly can use certificates (with public key > encryption >>>>> keys) to transport keying material; indeed, the ciphersuite of TLS >>>> that >>>>> is in general use does exactly that. >>>>> >>>>> However, it does have a few drawbacks. Here are some of the > reasons >>>>> that the IKEv2 designers may have chosen not to use it: >>>>> >>>>> - Transporting keying material lacks forward secrecy. "Forward >>>>> secrecy" is the property that, if some actually recovers the > entire >>>>> state of one (or both) of the sides, they still won't be able to >>>>> decrypt a transcript of a session that had happened earlier > (because >>>>> the state needed to decrypt it was zeroized when the session was >>>>> closed). With key transport, it is impractical to zeroize the >>>> private >>>>> key used during the exchange, and with that, the attacker can > decrypt >>>>> the keying material, and from there, rederive the session keys. > In >>>>> contrast, with DH, as long as both sides zeroize the private >>>> exponents >>>>> and shared secrets (along with the session state), the attacker > does >>>>> not have enough information. >>>>> >>>>> - IKEv2 allows other types of authentication beyond certificates; >>>> using >>>>> public key encryption as a step in generating keying material > would >>>>> imply that we would need a different mechanism to generate keying >>>>> material for other types of authentication. This is certainly not >>>>> impossible (in fact, IKEv1 did have different mechanisms based on >>>>> authentication type, although for different reasons); the IKEv2 >>>>> designers decided to unify that. >>>>> >>>>>> Thanks and Regards >>>>>> Naveen >>>>>> >>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Prashant Batra (prbatra) >>>>>> Sent: Tuesday, July 26, 2011 6:33 PM >>>>>> To: Yaron Sheffer; Yoav Nir >>>>>> Cc: ipsec@ietf.org >>>>>> Subject: Re: [IPsec] DH keys calculation performance >>>>>> >>>>>> Thanks Yoav and Yaron for the suggestions. >>>>>> Even I was thinking and tried generating and storing the key > pair >>>>> well >>>>>> in the beginning,. This helped to some extent. >>>>>> >>>>>> The secret calculation is also very expensive, but this has to > be >>>>> done >>>>>> in midst of the exchange only. >>>>>> >>>>>> Regards, >>>>>> Prashant >>>>>> >>>>>> >>>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>>>> Sent: Tuesday, July 26, 2011 4:47 PM >>>>>> To: Yoav Nir >>>>>> Cc: Prashant Batra (prbatra); ipsec@ietf.org >>>>>> Subject: Re: [IPsec] DH keys calculation performance >>>>>> >>>>>> You might want to review >>>> http://tools.ietf.org/html/rfc5996#section- >>>>>> 2.12. >>>>>> >>>>>> Also, session resumption (http://tools.ietf.org/html/rfc5723) >>>> reduces >>>>>> the computational costs of renewing an IKE SA when a client > needs >>>> to >>>>>> reconnect to a gateway a second time after some failure. >>>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> >>>>>> On 07/26/2011 01:40 PM, Yoav Nir wrote: >>>>>> >>>>>> On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> The DH exchange (Calculation of Public/Private key and the > Secret) >>>> in >>>>>> IKEV2 Initial exchange >>>>>> seems to be very expensive. This is slowing down the overall > IKEv2 >>>>>> tunnel establishment. >>>>>> Is there a way to optimize it? >>>>>> >>>>>> Hi Prashant. >>>>>> >>>>>> I know of three ways to optimize the D-H exchange. >>>>>> >>>>>> First, note that each peer has to perform two operations: >>>>>> 1. Generate: create a random x and calculate X=3D2^x mod p >>>>>> 2. Derive: calculate the shared secret S=3DY^x mod p >>>>>> The "Derive" operation has to be done during the exchange, but > the >>>>>> "Generate" operation can be done long before the exchange. If > your >>>>>> problem is degraded performance at some peak, you can > pre-generate >>>>> some >>>>>> values. This has a high cost in memory, but can be useful for >>>> dealing >>>>>> with peaks. >>>>>> >>>>>> Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * > (2^1 >>>> mod >>>>>> p)) mod p >>>>>> If you're using a 2048-bit D-H group, you can pre-calculate 2^x > mod >>>> p >>>>>> for 0<=3Dx<=3D2048 and store these values. After that, both the >>>> generate >>>>>> and derive operations become simple multiplications of the >>>> resulting >>>>>> values. This has a fixed cost in memory, but can accelerate > things. >>>>>> Third, you may want to look at the EC groups. The EC operations >>>>> require >>>>>> less computation. >>>>>> >>>>>> Hope this helps >>>>>> >>>>>> Yoav >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>> Scanned by Check Point Total Security Gateway. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From prbatra@cisco.com Mon Aug 29 23:16:16 2011 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 C2D2A21F84F2 for ; Mon, 29 Aug 2011 23:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.678 X-Spam-Level: X-Spam-Status: No, score=-9.678 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y9qFT41-3aM for ; Mon, 29 Aug 2011 23:16:15 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 62F1221F84EF for ; Mon, 29 Aug 2011 23:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=4247; q=dns/txt; s=iport; t=1314685062; x=1315894662; h=mime-version:subject:date:message-id:from:to; bh=5FvrZiCuo/32HzijeBX0PWcOQCuMaWbU9JYL694WPh4=; b=QJj7Rws3BtCeHoFz0G+owfBPij6oisjjBbWf3/vQkqXlpQJlsXLmZz3I xDAvkSiMr6wGnuf6pOseQFS55PLYt5jwFh3oTm3KdSYvjobspWM3QTUad 77dvRBw0ibrZQYEVXGbvGlhGpQ2cxP8JqwcnUrh8En7ZeIZSGwnz4brG7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8HAEeAXE5Io8UQ/2dsb2JhbABCgk2WIY8Yd4FCAQEDEgEJEQNbAQweBhgHVwEECxAanX6BIwGfTIVtYASHZJBXi3U X-IronPort-AV: E=Sophos;i="4.68,300,1312156800"; d="scan'208,217";a="52499198" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 30 Aug 2011 06:17:40 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7U6Hdcg004202 for ; Tue, 30 Aug 2011 06:17:39 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 11:47:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC66DC.84F2D532" Date: Tue, 30 Aug 2011 11:47:39 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Child-SA in a single exchnage Thread-Index: Acxm3ISjEIiByzBoTvC76INRN5AJPQ== From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 30 Aug 2011 06:17:39.0811 (UTC) FILETIME=[850F4330:01CC66DC] Subject: [IPsec] Multiple Child-SA in a single exchnage 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, 30 Aug 2011 06:16:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC66DC.84F2D532 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 The Ikev2 protocol seems to be very flexible in sending payloads in the messages. We can specify multiple proposals of same protocol or of different protocol (AH/ESP) in SA payload. We can also specify multiple traffic selectors in the TS payload. But all this will result in one IPsec SA to be established. =20 If the user knows that it has to establish 2/3 CHILD_SA, will it not be good to have a provision to specify the information for all in a single message (IKE_AUTH). This might save a lot of CHILD_SA exchanges. =20 This will be similar to including multiple DELETE payloads or including multiple SPI's in a single DELETE payload in INFO exchange to delete CHILD_SA's =20 Kindly share your valuable views on the same. =20 Regards, Prashant Batra ------_=_NextPart_001_01CC66DC.84F2D532 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

The Ikev2 protocol seems to be very flexible in = sending payloads in the messages.

We can specify multiple proposals of same protocol = or of different protocol (AH/ESP) in SA payload.  We can also specify = multiple traffic selectors in the TS payload.

But all this will result in one IPsec SA to = be established.

 

If the user knows that it has to establish =  2/3 CHILD_SA, will it not be good to have a provision to specify the = information for all in a single message (IKE_AUTH).

This might save a lot of CHILD_SA = exchanges.

 

This will be similar to including multiple DELETE = payloads or including multiple SPI’s in a single DELETE payload in INFO = exchange to delete CHILD_SA’s

 

Kindly share your valuable views on the = same.

 

Regards,

Prashant Batra

------_=_NextPart_001_01CC66DC.84F2D532-- From kivinen@iki.fi Tue Aug 30 02:09:54 2011 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 28D0621F8B84 for ; Tue, 30 Aug 2011 02:09:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nQmCgjL8Abh for ; Tue, 30 Aug 2011 02:09:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id A436C21F8B9B for ; Tue, 30 Aug 2011 02:09:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p7U9B8pD005969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2011 12:11:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p7U9B6U4006827; Tue, 30 Aug 2011 12:11:06 +0300 (EEST) 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: <20060.43306.157789.942917@fireball.kivinen.iki.fi> Date: Tue, 30 Aug 2011 12:11:06 +0300 From: Tero Kivinen To: "ramaswamy" In-Reply-To: <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net Subject: [IPsec] New method to resist replay attack in ikev2 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, 30 Aug 2011 09:09:54 -0000 ramaswamy writes: > Proposed new negotiations > > Before initial exchange begins initiator looks up to the pre shared > secret with the intended responder and does the hash value on first > half of pre shared secret, nonce of the initiator. Once the > responder receives the request it looks up the correspondence pre > shared key in its table and it takes the nonce form initiator > request message then it does a hash value to authenticate the > initiator. This is bit like how IKEv1 did it, and it has same problem than IKEv1 had with that, meaning it does not provide ANY identity protection at all. The responder needs to find the pre-shared key for the initiator based only with the information that are in the first IKE_SA_INIT packet. This DOES NOT include identity of the initiator, and SAi1, KEi, and Ni does not help at all in this process. The only information that responder has which it can use is the source IP-address of the IKE_SA_INIT packet. This has the effect that the pre-shared key will be tied to the source IP-address of the initiator, which mean every passive listener will also see that same IP-address and will know the identity of the initiator. The method in IKEv2 where the PSK is not tied to the IP-address of the initiator offers much better identity protection, as now the responder identity is only releaved to the active attacker. -- kivinen@iki.fi From kivinen@iki.fi Tue Aug 30 02:55:42 2011 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 1FA7721F89B8 for ; Tue, 30 Aug 2011 02:55:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvVF6ucdBg6i for ; Tue, 30 Aug 2011 02:55:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B509F21F8742 for ; Tue, 30 Aug 2011 02:55:40 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p7U9v1Jb000316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2011 12:57:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p7U9v1CZ029319; Tue, 30 Aug 2011 12:57:01 +0300 (EEST) 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: <20060.46061.588657.688457@fireball.kivinen.iki.fi> Date: Tue, 30 Aug 2011 12:57:01 +0300 From: Tero Kivinen To: "Prashant Batra (prbatra)" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: [IPsec] Multiple Child-SA in a single exchnage 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, 30 Aug 2011 09:55:42 -0000 Prashant Batra (prbatra) writes: > If the user knows that it has to establish 2/3 CHILD_SA, will it not be > good to have a provision to specify the information for all in a single > message (IKE_AUTH). > > This might save a lot of CHILD_SA exchanges. CREATE_CHILD_SA exchange is quite light weight exchange, especially if no Diffie-Hellman is needed. If your SAs are between same endpoints and has similar lifetimes there is no need to do Diffie-Hellman exchanges in the CREATE_CHILD_SA, meaning the cost of doing CREATE_CHILD_SA is just sending and receiving one packet. If your implementation also supports window size larger than 1 then you can send those 2-3 CREATE_CHILD_SA request at the same time and then start waiting reply to them. Also why do you need those multiple Child SAs? What is the difference between them. If they just have different Traffic Selectors, then you could also consider combining all the traffic selectors to the one Child SA. If they have different algorithms, then the question is why do they need different algorithms? Why some one algorithm is not safe for all of the them? IKEv1 did have feature of negotiating multiple Child SAs in one exchange, but that was not taken in to the IKEv2. I do not know any implementation which properly supported that IKEv1 feature and I have not seen anybody asking for that feature before this for IKEv2. What is the use case you have that would require that feature? -- kivinen@iki.fi From prbatra@cisco.com Tue Aug 30 05:02:26 2011 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 6DE9021F8B88 for ; Tue, 30 Aug 2011 05:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.532 X-Spam-Level: X-Spam-Status: No, score=-9.532 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lodeGbCSjyR for ; Tue, 30 Aug 2011 05:02:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3A04E21F8B73 for ; Tue, 30 Aug 2011 05:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=4294; q=dns/txt; s=iport; t=1314705832; x=1315915432; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PyLssD83MbbWOCAhC9qQkSLyLZAApdbWTWzMY6b8QPI=; b=IhBJ5wwPS1P+OZARYINEDS4YikYbJPhPRXuHhmevWtkfhmgwH+GOYo+U 0a56a+mf+Cmj56/6mOb1qAgbhLk84gIqY+pFNLJJVCVRoTcMhqepUSLRG n/Wq+g7ZfwdYgai/H43Rt1CAkJ+FBpsjfaadCwB4kAi90HgmkowTKIN4o o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAOjQXE5Io8UQ/2dsb2JhbABCmDKPY3eBQAEBAQEDAQEBDwEUCQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQLCAgah1SZIQGfTYVtYASHZJBXi3Y X-IronPort-AV: E=Sophos;i="4.68,302,1312156800"; d="scan'208";a="52553796" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 30 Aug 2011 12:03:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7UC3j3X005273; Tue, 30 Aug 2011 12:03:49 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 17:33:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 17:33:47 +0530 Message-ID: In-Reply-To: <20060.46061.588657.688457@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Multiple Child-SA in a single exchnage Thread-Index: Acxm+zO4MyHwYqCuTZqW6Y1SAB5eoQADcP6w References: <20060.46061.588657.688457@fireball.kivinen.iki.fi> From: "Prashant Batra (prbatra)" To: "Tero Kivinen" X-OriginalArrivalTime: 30 Aug 2011 12:03:48.0702 (UTC) FILETIME=[E04887E0:01CC670C] Cc: ipsec@ietf.org Subject: Re: [IPsec] Multiple Child-SA in a single exchnage 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, 30 Aug 2011 12:02:26 -0000 Thanks Tero for the reply. What my intention was to combine this idea with draft - "Alternate Tunnel Addresses for IKEv2" that is already there,=20 which says something like this (for tunnel mode IPSec)- IKE_AUTH - IKE_IP_I:500 -> IKE_IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr, [N(TUNNEL_ADDRESS)]} --> (IKE_IP_R:500 -> IKE_IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, [N(TUNNEL_ADDRESS)]} Here, [TUNNEL_ADDRESS] will specify the IPSec tunnel outer IP pairs, which might be different from IKEv2 IP pairs. So, if there is a load-sharing between two gateways and the user/application starting the IKEv2 negotiation,=20 knows that the gateway has 5 ip-addresses used for this purpose, 5 different IPSec tunnels need to be established=20 between the gateways. This can be achieved by 4 CREATE_CHILD_SA exchanges following IKE_AUTH specifying the rest of 4 [TUNNEL_ADDRESS]. Using my idea, we can do it in a single AUTH, maybe with same set of algorithms or different. If we have to use same set of algorithms then only a single SA payload will suffice. So, the exchange will become -=20 IKE_AUTH -=20 IKE_IP_I:500 -> IKE_IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi [TSi], TSr [TSr], [N(TUNNEL_ADDRESS_LIST)]} --> (IKE_IP_R:500 -> IKE_IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi [TSi], TSr [TSr], [N(TUNNEL_ADDRESS_LIST)]} [TUNNEL_ADDRESS_LIST] might contain a range of addresses. Also, these addresses might belong to same ID,=20 if ID_TYPE is FQDN, or to different IDs for ID_TYPE IPv4/IPv6 address. In which case ID_LIST can be used. There will be different traffic_selectors for different IPSec SA. To club this idea for CHILD_SA might not be really beneficial if the traffic selectors can be clubbed. So for all CHILD_SAs we can have a single child accommodating all CHILD's TS. But, any valid use-case requiring creation of multiple CHILD_SAs can become beneficial, by clubbing them into one exchnage if we consider the cost of authentication, encryption-decryption and network congestion on a highly loaded gateway. Regards, Prashant Batra -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Tuesday, August 30, 2011 3:27 PM To: Prashant Batra (prbatra) Cc: ipsec@ietf.org Subject: [IPsec] Multiple Child-SA in a single exchnage Prashant Batra (prbatra) writes: > If the user knows that it has to establish 2/3 CHILD_SA, will it not be > good to have a provision to specify the information for all in a single > message (IKE_AUTH). >=20 > This might save a lot of CHILD_SA exchanges. CREATE_CHILD_SA exchange is quite light weight exchange, especially if no Diffie-Hellman is needed. If your SAs are between same endpoints and has similar lifetimes there is no need to do Diffie-Hellman exchanges in the CREATE_CHILD_SA, meaning the cost of doing CREATE_CHILD_SA is just sending and receiving one packet. If your implementation also supports window size larger than 1 then you can send those 2-3 CREATE_CHILD_SA request at the same time and then start waiting reply to them. Also why do you need those multiple Child SAs? What is the difference between them. If they just have different Traffic Selectors, then you could also consider combining all the traffic selectors to the one Child SA. If they have different algorithms, then the question is why do they need different algorithms? Why some one algorithm is not safe for all of the them? IKEv1 did have feature of negotiating multiple Child SAs in one exchange, but that was not taken in to the IKEv2. I do not know any implementation which properly supported that IKEv1 feature and I have not seen anybody asking for that feature before this for IKEv2. What is the use case you have that would require that feature? --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Tue Aug 30 06:13:08 2011 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 5BCF921F8B31 for ; Tue, 30 Aug 2011 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oyEC5nASecC for ; Tue, 30 Aug 2011 06:13:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB41621F8B2E for ; Tue, 30 Aug 2011 06:13:05 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p7UDEINM009325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2011 16:14:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p7UDEIcn004988; Tue, 30 Aug 2011 16:14:18 +0300 (EEST) 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: <20060.57898.125813.457002@fireball.kivinen.iki.fi> Date: Tue, 30 Aug 2011 16:14:18 +0300 From: Tero Kivinen To: "Prashant Batra (prbatra)" In-Reply-To: References: <20060.46061.588657.688457@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 24 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Multiple Child-SA in a single exchnage 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, 30 Aug 2011 13:13:08 -0000 Prashant Batra (prbatra) writes: > What my intention was to combine this idea with draft - "Alternate > Tunnel Addresses for IKEv2" that is already there, > which says something like this (for tunnel mode IPSec)- > > IKE_AUTH - > IKE_IP_I:500 -> IKE_IP_R:500) > HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] > [IDr,]AUTH, SAi2, TSi, TSr, [N(TUNNEL_ADDRESS)]} --> > > (IKE_IP_R:500 -> IKE_IP_I:500) > <-- HDR(A,B), SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr, [N(TUNNEL_ADDRESS)]} > Here, [TUNNEL_ADDRESS] will specify the IPSec tunnel outer IP pairs, > which might be different from IKEv2 IP pairs. I do not know abou the "Alternate Tunnel Addresses for IKEv2", but I can see that it would have all kind of problems with the NAT-Travelsal and also with MOBIKE, at least if I understood correctly what it is (i.e. if the outer IP-address of the IKE SA and the Child SAs are different you will have all kind of issues with NAT-T and MOBIKE). > So, if there is a load-sharing between two gateways and the > user/application starting the IKEv2 negotiation, > knows that the gateway has 5 ip-addresses used for this purpose, 5 > different IPSec tunnels need to be established > between the gateways. Actually if both ends have multiple addresses you might need n * m tunnels. > This can be achieved by 4 CREATE_CHILD_SA > exchanges following IKE_AUTH specifying the rest of 4 [TUNNEL_ADDRESS]. Usually it is easier to do load balancing by moving different clients to different hosts, which solution does not have this problem. If load balancing is needed between two big load-balanced servers because the traffic between them is so much that one host cannot cope with it (i.e. 10 Gbit/s or faster, as current high end PCs can already do several Gbit/s with software crypto), I would not assume there is that many servers connecting to the same load balancing cluster. Also as in such setups the IKE SAs will be up and running mostly for ever, meaning the initial exchange setup overhead will most likely be very small compared to the things like Child SA rekeys and so on. In such setups doing the initial IKE SA creation and the associated few CREATE_CHILD_SAs once should not be a problem. > Using my idea, we can do it in a single AUTH, maybe with same set of > algorithms or different. If we have to use same set of algorithms > then only a single SA payload will suffice. That will add lots of complexity to the system. I think the complexity added is way too much, when the benefit is just omitting few extra packets at the initial setup time that happens very rarely. I mean that kind of load balancing servers are most likely also using high-availibity features, meaning the same IKE SA might be up for years, even when the hardware of the system is updated on the fly... > [TUNNEL_ADDRESS_LIST] might contain a range of addresses. Also, > these addresses might belong to same ID, if ID_TYPE is FQDN, or to > different IDs for ID_TYPE IPv4/IPv6 address. In which case ID_LIST > can be used. ID_LIST is for IKEv1, it is not defined for the IKEv2. > But, any valid use-case requiring creation of multiple CHILD_SAs can > become beneficial, by clubbing them into one exchnage > if we consider the cost of authentication, encryption-decryption and > network congestion on a highly loaded gateway. Highly loaded gateway will most likely be loaded because of the Child SA traffic, not because of the IKEv2 SA traffic. There is already redirection mechanisms which allows moving the IKEv2 SAs from the one node to another node in case the IKEv2 SA traffic comes an issue. Those CREATE_CHILD_SAs exchanges are extremly fast. The actual saving of number of packets between the gateways should not even be visible. The major overhead in such system, will most likely come when the IKEv2 server pushes the created Child SA information to the crypto hardware doing the actual Child SA processing. That operation might be much more costly than what the actual CREATE_CHILD_SAs exchange itself is. -- kivinen@iki.fi