From ynir@checkpoint.com Mon May 2 04:31: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 C6413E0742; Mon, 2 May 2011 04:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=4.129, 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 1nwlzUKi+juG; Mon, 2 May 2011 04:31:09 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD61E0678; Mon, 2 May 2011 04:31:06 -0700 (PDT) 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 p42BV4gr030282; Mon, 2 May 2011 14:31:05 +0300 X-CheckPoint: {4DBEA33D-A-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 2 May 2011 14:31:04 +0300 From: Yoav Nir To: "ipsec@ietf.org" , "'hokey@ietf.org'" Date: Mon, 2 May 2011 14:31:04 +0300 Thread-Topic: New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwIvGxAunpC79zhQuOaCfwwzT5+Ng== Message-ID: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.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] New I-D: draft-nir-ipsecme-erx-00 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, 02 May 2011 11:31:10 -0000 Hi. Qin and I have just posted the subject draft. The title is "An IKEv2 Exten= sion for Supporting ERP", although it has nothing to do with enterprise res= ource planning. This draft brings the ERP extension for EAP, which is developed by the Hoke= y group into the IKEv2 authentication exchange, allowing a client ("peer" o= r "initiator") to authenticate to a VPN gateway ("Authenticator" or "respon= der") in only three round-trips, and without user intervention, provided th= at this client has unexpired keys from a previous run of EAP. It doesn't ma= tter whether the previous run was done in the context of another IKE exchan= ge, attachment to a 802.1x LAN or over PPP. We would like this draft to be accepted as a working-group item in IPsecME,= although serious review in hokey will also be needed. I'd like to use this one-time cross-posted mail message to explain some of = the design decisions in this -00 version of the draft. The EAP-Initiate/Re-auth-Start message is missing from the protocol. Instea= d, a notification payload carries the domain name. This was done because an= EAP payload in the IKE_SA_INIT response would be weird, whereas unknown No= tifications are common. We are not sure whether placing the domain name is = necessary, because in IKE, the client usually connects to a pre-configured = gateway, rather than attaching to any network available as in 802.1x. We do not run two EAP protocols in parallel (re-auth and something else) as= in RFC 5296 and the bis document, because IKEv2 ususally doesn't have iden= tity requests (they identity protocol is replaced by the user identity in t= he IDi payload), and running a real EAP protocol would put us in a weird st= ate with the backend EAP server. Instead, we send the domain name in the no= tification payload, and the client may either send the EAP-Initiate/Re-auth= message or the IDi payload (but not both). Alternatively we could have the client indicate support in the IKE_SA_INIT = request, and then have a proper EAP-Initiate/Re-auth-Start message in the I= KE_SA_INIT response. I don't see much advantage in this, so in version -00 = we did not do this. We would very much appreciate feedback from both groups. Qin & Yoav From yaronf.ietf@gmail.com Mon May 2 13:54: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 D599AE0663 for ; Mon, 2 May 2011 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 r1G83p2mfi6L for ; Mon, 2 May 2011 13:54:21 -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 016D0E0659 for ; Mon, 2 May 2011 13:54:17 -0700 (PDT) Received: by wyb29 with SMTP id 29so5181369wyb.31 for ; Mon, 02 May 2011 13:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2MPD7Zkp09j4n4u/1+i+cVFqREcVDpSSpaNEpuT+E18=; b=fyQz3oGb7+WV1ai+YcAZtQQ5vbU0Xr6/hxdUA4xzXIOLp5tW4N+jVXrrYSC2lc3jUG MuYVoZdWPSflIXCA462xP6eyU0Dwx3uwqIcorpWG2N/k1DnaW6YStUgbFX2ilH0WVRIs rfqYfu8lSAMwR6tgRPxOvI4ixKKQivs+GwyRY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=dfhXCOtNjoxCzYFCM8cWmzkUnqy93KmB18HxtWjSwPOAN5dazzSqRojVklCQksmqYr cmoq2/3Gi1n1hc439mEFuQn0RouUROahDfRtWPGou4JTVC29rcaxWiRt2MaQ+WgGkqJX HHsZ9/JAiu1oLM4hn6d4BNwmi+6oH4IKTUv6A= Received: by 10.227.201.148 with SMTP id fa20mr4475841wbb.39.1304369656955; Mon, 02 May 2011 13:54:16 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-30-144.red.bezeqint.net [79.178.30.144]) by mx.google.com with ESMTPS id l24sm3172526wbc.47.2011.05.02.13.54.14 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 13:54:15 -0700 (PDT) Message-ID: <4DBF19F4.6050804@gmail.com> Date: Mon, 02 May 2011 23:54:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110419 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 02 May 2011 20:54:21 -0000 [Responding to IPsec only:] Hi Yoav, thanks for the new draft. I'm afraid one needs to read RFC5296bis before commenting, but here's a few questions anyway: - Sending the domain in the IKE_SA_INIT response obviously contradicts the usual IKEv2 identity protection. This is not really a question :-) - I am missing the "authenticated peer identity", which I would assume should arrive from the AAA server. This should be the basis of RFC4301 policy decisions on the IKE gateway. Does ERP provide this identity? - Does this draft coexist with certificate-less mutual EAP authentication, as per RFC5998? Thanks, Yaron On 05/02/2011 02:31 PM, Yoav Nir wrote: > Hi. > > Qin and I have just posted the subject draft. The title is "An IKEv2 > Extension for Supporting ERP", although it has nothing to do with > enterprise resource planning. > > This draft brings the ERP extension for EAP, which is developed by the > Hokey group into the IKEv2 authentication exchange, allowing a client > ("peer" or "initiator") to authenticate to a VPN gateway > ("Authenticator" or "responder") in only three round-trips, and > without user intervention, provided that this client has unexpired > keys from a previous run of EAP. It doesn't matter whether the > previous run was done in the context of another IKE exchange, > attachment to a 802.1x LAN or over PPP. > > We would like this draft to be accepted as a working-group item in > IPsecME, although serious review in hokey will also be needed. > > I'd like to use this one-time cross-posted mail message to explain > some of the design decisions in this -00 version of the draft. > > The EAP-Initiate/Re-auth-Start message is missing from the protocol. > Instead, a notification payload carries the domain name. This was done > because an EAP payload in the IKE_SA_INIT response would be weird, > whereas unknown Notifications are common. We are not sure whether > placing the domain name is necessary, because in IKE, the client > usually connects to a pre-configured gateway, rather than attaching to > any network available as in 802.1x. > > We do not run two EAP protocols in parallel (re-auth and something > else) as in RFC 5296 and the bis document, because IKEv2 ususally > doesn't have identity requests (they identity protocol is replaced by > the user identity in the IDi payload), and running a real EAP protocol > would put us in a weird state with the backend EAP server. Instead, we > send the domain name in the notification payload, and the client may > either send the EAP-Initiate/Re-auth message or the IDi payload (but > not both). > > Alternatively we could have the client indicate support in the > IKE_SA_INIT request, and then have a proper EAP-Initiate/Re-auth-Start > message in the IKE_SA_INIT response. I don't see much advantage in > this, so in version -00 we did not do this. > > We would very much appreciate feedback from both groups. > > Qin& Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue May 3 03:49:48 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 A3799E07A4 for ; Tue, 3 May 2011 03:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.987 X-Spam-Level: X-Spam-Status: No, score=-6.987 tagged_above=-999 required=5 tests=[AWL=3.612, 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 eKiWO33mwThe for ; Tue, 3 May 2011 03:49:47 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 58623E069E for ; Tue, 3 May 2011 03:49:47 -0700 (PDT) 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 p43An2wd018286; Tue, 3 May 2011 13:49:02 +0300 X-CheckPoint: {4DBFEADE-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 3 May 2011 13:49:02 +0300 From: Yoav Nir To: Yaron Sheffer , Qin Wu Date: Tue, 3 May 2011 13:49:03 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwJf7a1ikCVR1+iTyaJB2ll+sUQ/w== Message-ID: <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> In-Reply-To: <4DBF19F4.6050804@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: "ipsec@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 03 May 2011 10:49:48 -0000 On May 2, 2011, at 11:54 PM, Yaron Sheffer wrote: > [Responding to IPsec only:] >=20 > Hi Yoav, >=20 > thanks for the new draft. I'm afraid one needs to read RFC5296bis before= =20 > commenting, but here's a few questions anyway: >=20 > - Sending the domain in the IKE_SA_INIT response obviously contradicts=20 > the usual IKEv2 identity protection. This is not really a question :-) True, but identity protection for the responder never made sense for remote= access gateways. I haven't gone over the archives, but I remember that som= eone proposed having an extra EAP-Identity round so that the server shows i= ts certificate first. If we get feedback that this is a serious issue to so= me, we can always add a round-trip. > - I am missing the "authenticated peer identity", which I would assume=20 > should arrive from the AAA server. This should be the basis of RFC4301=20 > policy decisions on the IKE gateway. Does ERP provide this identity? The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent= from the client (or "peer") to the authentication server through the gatew= ay. (section 5.3.2 of the bis document) The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is s= ent from the authentication server through the gateway to the client. But these don't really help, because the username part of NAI is the 64-bit= EMSKname, which is not directly related to user name. However, these messages come within an Access-Accept packet from the RADIUS= server, and those include a proper user name. > - Does this draft coexist with certificate-less mutual EAP=20 > authentication, as per RFC5998? I think the handed-over keying material is cryptographic proof enough and t= hat certificates will usually be unnecessary, so I think yes. >=20 > Thanks, > Yaron From sunseawq@huawei.com Tue May 3 18:47: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 25E4EE07B9 for ; Tue, 3 May 2011 18:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=3.376, BAYES_00=-2.599, 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 Hx1DCd1FFZhG for ; Tue, 3 May 2011 18:47:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 614CEE07C2 for ; Tue, 3 May 2011 18:47:23 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00CPVEAWIJ@szxga04-in.huawei.com> for ipsec@ietf.org; Wed, 04 May 2011 09:47:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN0041TEAWPC@szxga04-in.huawei.com> for ipsec@ietf.org; Wed, 04 May 2011 09:47:20 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN00HKMEAVQE@szxml06-in.huawei.com> for ipsec@ietf.org; Wed, 04 May 2011 09:47:20 +0800 (CST) Date: Wed, 04 May 2011 09:50:48 +0800 From: Qin Wu To: Yoav Nir , Yaron Sheffer Message-id: <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 01:47:24 -0000 >> - I am missing the "authenticated peer identity", which I would assume >> should arrive from the AAA server. This should be the basis of RFC4301 >> policy decisions on the IKE gateway. Does ERP provide this identity? > > The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent from the client (or "peer") to the authentication server through the gateway. (section 5.3.2 of the bis document) > The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is sent from the authentication server through the gateway to the client. > But these don't really help, because the username part of NAI is the 64-bit EMSKname, which is not directly related to user name. > However, these messages come within an Access-Accept packet from the RADIUS server, and those include a proper user name. [Qin]: If you are talking about the second identity specified in section 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity. ERP only define two types: one is Re-auth-Start, the other is Re-Auth. KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first idenity described in section 6.4 of RFC5998. As decribed in section 5.1 of RFC5296, " When an ERP-capable authenticator receives the EAP-Initiate/ Re-auth message from a peer, it copies the contents of the ^^^^^^^^^^^^^^^^^^^^ keyName-NAI into the User-Name attribute of RADIUS [13]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ " > >> - Does this draft coexist with certificate-less mutual EAP >> authentication, as per RFC5998? > > I think the handed-over keying material is cryptographic proof enough and that certificates will usually be unnecessary, so I think yes. [Qin]: Correct. >> >> Thanks, >> Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue May 3 22:30:32 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 20566E06EE for ; Tue, 3 May 2011 22:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[AWL=3.211, 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 NN8Pc1to1-1P for ; Tue, 3 May 2011 22:30:24 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8773DE0651 for ; Tue, 3 May 2011 22:30:23 -0700 (PDT) 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 p445U6L5022454; Wed, 4 May 2011 08:30:06 +0300 X-CheckPoint: {4DC0F199-0-1B221DC2-FFFF} 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; Wed, 4 May 2011 08:30:06 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 4 May 2011 08:30:06 +0300 From: Yoav Nir To: Qin Wu Date: Wed, 4 May 2011 08:30:01 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwKHFL8zeaZlhjRQTG0VKbc9VGyIQ== Message-ID: <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> In-Reply-To: <00a401cc09fd$b152ef00$46298a0a@china.huawei.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: "ipsec@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 05:30:32 -0000 On May 4, 2011, at 4:50 AM, Qin Wu wrote: >>> - I am missing the "authenticated peer identity", which I would assume= =20 >>> should arrive from the AAA server. This should be the basis of RFC4301= =20 >>> policy decisions on the IKE gateway. Does ERP provide this identity? >>=20 >> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is s= ent from the client (or "peer") to the authentication server through the ga= teway. (section 5.3.2 of the bis document) >> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that i= s sent from the authentication server through the gateway to the client. >> But these don't really help, because the username part of NAI is the 64-= bit EMSKname, which is not directly related to user name. >> However, these messages come within an Access-Accept packet from the RAD= IUS server, and those include a proper user name. >=20 > [Qin]: If you are talking about the second identity specified in section = 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity. > ERP only define two types: one is Re-auth-Start, the other is Re-Auth. >=20 > KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the fir= st idenity described in section 6.4 of RFC5998. > As decribed in section 5.1 of RFC5296, > " > When an ERP-capable authenticator receives the EAP-Initiate/ > Re-auth message from a peer, it copies the contents of the > ^^^^^^^^^^^^^^^^^^^= ^ > keyName-NAI into the User-Name attribute of RADIUS [13].=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > " But what does the RADIUS send in the User-Name attribute of Access-Accept? = How does the Authenticator know who the user is? The Authenticator needs = the true identity to make policy decisions.= From sunseawq@huawei.com Tue May 3 23:15:03 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 50021E06FA; Tue, 3 May 2011 23:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=2.563, BAYES_00=-2.599, 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 HNt-U2oO8ooV; Tue, 3 May 2011 23:14:59 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 23151E06E6; Tue, 3 May 2011 23:14:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN006ULQOTZI@szxga03-in.huawei.com>; Wed, 04 May 2011 14:14:53 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00CXUQOTXZ@szxga03-in.huawei.com>; Wed, 04 May 2011 14:14:53 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN005RXQOSAZ@szxml06-in.huawei.com>; Wed, 04 May 2011 14:14:53 +0800 (CST) Date: Wed, 04 May 2011 14:18:22 +0800 From: Qin Wu To: Yoav Nir Message-id: <029301cc0a23$11dcadf0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> Cc: ipsec@ietf.org, hokey@ietf.org Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 06:15:03 -0000 Hi, ----- Original Message ----- From: "Yoav Nir" To: "Qin Wu" Cc: Sent: Wednesday, May 04, 2011 1:30 PM Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 > > On May 4, 2011, at 4:50 AM, Qin Wu wrote: > >>>> - I am missing the "authenticated peer identity", which I would assume >>>> should arrive from the AAA server. This should be the basis of RFC4301 >>>> policy decisions on the IKE gateway. Does ERP provide this identity? >>> >>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent from the client (or "peer") to the authentication server through the gateway. (section 5.3.2 of the bis document) >>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is sent from the authentication server through the gateway to the client. >>> But these don't really help, because the username part of NAI is the 64-bit EMSKname, which is not directly related to user name. >>> However, these messages come within an Access-Accept packet from the RADIUS server, and those include a proper user name. >> >> [Qin]: If you are talking about the second identity specified in section 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity. >> ERP only define two types: one is Re-auth-Start, the other is Re-Auth. >> >> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first idenity described in section 6.4 of RFC5998. >> As decribed in section 5.1 of RFC5296, >> " >> When an ERP-capable authenticator receives the EAP-Initiate/ >> Re-auth message from a peer, it copies the contents of the >> ^^^^^^^^^^^^^^^^^^^^ >> keyName-NAI into the User-Name attribute of RADIUS [13]. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> " > > But what does the RADIUS send in the User-Name attribute of Access-Accept? How does the Authenticator know who the user is? The Authenticator needs the true identity to make policy decisions. [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS server as User-Name during authentication. Also I think it is not necessarily to couple authorization with authentication. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed May 4 00:01: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 ACA24E0727; Wed, 4 May 2011 00:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.972 X-Spam-Level: X-Spam-Status: No, score=-7.972 tagged_above=-999 required=5 tests=[AWL=2.627, 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 S3KtF5C1aV-1; Wed, 4 May 2011 00:01:15 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 89EDFE071B; Wed, 4 May 2011 00:01:14 -0700 (PDT) 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 p4470vfP002715; Wed, 4 May 2011 10:01:02 +0300 X-CheckPoint: {4DC106E4-A-1B221DC2-FFFF} 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; Wed, 4 May 2011 10:00:57 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 4 May 2011 10:00:56 +0300 From: Yoav Nir To: Qin Wu Date: Wed, 4 May 2011 10:00:54 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwKKQNNa2aJl1BqREKUQGoAYw++jg== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <029301cc0a23$11dcadf0$46298a0a@china.huawei.com> In-Reply-To: <029301cc0a23$11dcadf0$46298a0a@china.huawei.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: "ipsec@ietf.org" , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 07:01:15 -0000 On May 4, 2011, at 9:18 AM, Qin Wu wrote: > Hi, > ----- Original Message -----=20 > From: "Yoav Nir" > To: "Qin Wu" > Cc: > Sent: Wednesday, May 04, 2011 1:30 PM > Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 >=20 >=20 >>=20 >> On May 4, 2011, at 4:50 AM, Qin Wu wrote: >>=20 >>>>> - I am missing the "authenticated peer identity", which I would assum= e=20 >>>>> should arrive from the AAA server. This should be the basis of RFC430= 1=20 >>>>> policy decisions on the IKE gateway. Does ERP provide this identity? >>>>=20 >>>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is= sent from the client (or "peer") to the authentication server through the = gateway. (section 5.3.2 of the bis document) >>>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that= is sent from the authentication server through the gateway to the client. >>>> But these don't really help, because the username part of NAI is the 6= 4-bit EMSKname, which is not directly related to user name. >>>> However, these messages come within an Access-Accept packet from the R= ADIUS server, and those include a proper user name. >>>=20 >>> [Qin]: If you are talking about the second identity specified in sectio= n 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity. >>> ERP only define two types: one is Re-auth-Start, the other is Re-Auth. >>>=20 >>> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the f= irst idenity described in section 6.4 of RFC5998. >>> As decribed in section 5.1 of RFC5296, >>> " >>> When an ERP-capable authenticator receives the EAP-Initiate/ >>> Re-auth message from a peer, it copies the contents of the >>> ^^^^^^^^^^^^^^^^^^= ^^ >>> keyName-NAI into the User-Name attribute of RADIUS [13].=20 >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> " >>=20 >> But what does the RADIUS send in the User-Name attribute of Access-Accep= t? How does the Authenticator know who the user is? The Authenticator nee= ds the true identity to make policy decisions. >=20 > [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS s= erver as User-Name during authentication. RFC 3579 says: "The User-Name attribute within the Access- Accept packet need not be the same as the User-Name attribute in the Access-Request." Do current implementations copy the KeyName-NAI to the Access-Accept? =20 > Also I think it is not necessarily to couple authorization with authenti= cation. They may not be coupled in other EAP contexts, but IPsec requires policy de= cisions based on authenticated identity. One way or another, the IKE implem= entation needs to get the real user identity for policy decisions. Yoav From sunseawq@huawei.com Wed May 4 00:25: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 14B68E06A2; Wed, 4 May 2011 00:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[AWL=2.330, BAYES_00=-2.599, 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 JqIL713rc3M5; Wed, 4 May 2011 00:25:37 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3CEE0691; Wed, 4 May 2011 00:25:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN004D7TVPW2@szxga03-in.huawei.com>; Wed, 04 May 2011 15:23:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00CESTVP5D@szxga03-in.huawei.com>; Wed, 04 May 2011 15:23:49 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN00IR0TVPUU@szxml06-in.huawei.com>; Wed, 04 May 2011 15:23:49 +0800 (CST) Date: Wed, 04 May 2011 15:27:19 +0800 From: Qin Wu To: Yoav Nir Message-id: <02e701cc0a2c$b39ab0c0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <029301cc0a23$11dcadf0$46298a0a@china.huawei.com> Cc: ipsec@ietf.org, hokey@ietf.org Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 07:25:39 -0000 Hi, ----- Original Message ----- From: "Yoav Nir" To: "Qin Wu" Cc: ; Sent: Wednesday, May 04, 2011 3:00 PM Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 > > On May 4, 2011, at 9:18 AM, Qin Wu wrote: > >> Hi, >> ----- Original Message ----- >> From: "Yoav Nir" >> To: "Qin Wu" >> Cc: >> Sent: Wednesday, May 04, 2011 1:30 PM >> Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 >> >> >>> >>> On May 4, 2011, at 4:50 AM, Qin Wu wrote: >>> >>>>>> - I am missing the "authenticated peer identity", which I would assume >>>>>> should arrive from the AAA server. This should be the basis of RFC4301 >>>>>> policy decisions on the IKE gateway. Does ERP provide this identity? >>>>> >>>>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is sent from the client (or "peer") to the authentication server through the gateway. (section 5.3.2 of the bis document) >>>>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is sent from the authentication server through the gateway to the client. >>>>> But these don't really help, because the username part of NAI is the 64-bit EMSKname, which is not directly related to user name. >>>>> However, these messages come within an Access-Accept packet from the RADIUS server, and those include a proper user name. >>>> >>>> [Qin]: If you are talking about the second identity specified in section 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity. >>>> ERP only define two types: one is Re-auth-Start, the other is Re-Auth. >>>> >>>> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first idenity described in section 6.4 of RFC5998. >>>> As decribed in section 5.1 of RFC5296, >>>> " >>>> When an ERP-capable authenticator receives the EAP-Initiate/ >>>> Re-auth message from a peer, it copies the contents of the >>>> ^^^^^^^^^^^^^^^^^^^^ >>>> keyName-NAI into the User-Name attribute of RADIUS [13]. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> " >>> >>> But what does the RADIUS send in the User-Name attribute of Access-Accept? How does the Authenticator know who the user is? The Authenticator needs the true identity to make policy decisions. >> >> [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS server as User-Name during authentication. > > RFC 3579 says: > "The User-Name attribute within the Access- > Accept packet need not be the same as the User-Name attribute in the > Access-Request." [Qin]: RFC5296 does not specify how UserName is copied into Access-Accept. The reason this part is about authorization which is beyond scope of ERP document. But I agree the different user name can be used. One way in my mind is Radius Server could use KeyName-NAI to look up real user name and add it into the Accss-Request. > Do current implementations copy the KeyName-NAI to the Access-Accept? [Qin]: I am not aware of it. But it could be. >> Also I think it is not necessarily to couple authorization with authentication. > > They may not be coupled in other EAP contexts, but IPsec requires policy decisions based on authenticated identity. One way or another, the IKE implementation needs to get the real user identity for policy decisions. [Qin]: Okay. the authenticated identity you mentioned is user identity, right? I think we should be careful to differentiate these identities. becos it seems there are lots of identities: e.g., EAP identity, IKEv2 identity and User identity. > Yoav > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Wed May 4 11:47: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 7D756E0700 for ; Wed, 4 May 2011 11:47:57 -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 DPQ+M6wHUH0H for ; Wed, 4 May 2011 11:47:56 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 96A45E0795 for ; Wed, 4 May 2011 11:47:56 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 102531022400A; Wed, 4 May 2011 11:47:56 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 May 2011 11:47:56 -0700 (PDT) Message-ID: In-Reply-To: <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> Date: Wed, 4 May 2011 11:47:56 -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" , Qin Wu Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 18:47:57 -0000 On Tue, May 3, 2011 10:30 pm, Yoav Nir wrote: [snip] > The Authenticator needs the true identity to make policy decisions. Well then DO NOT use EAP for authentication. Dan. From ynir@checkpoint.com Wed May 4 12:12: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 715ABE07BE; Wed, 4 May 2011 12:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.191 X-Spam-Level: X-Spam-Status: No, score=-8.191 tagged_above=-999 required=5 tests=[AWL=2.408, 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 g0fpVeRTjSou; Wed, 4 May 2011 12:12:06 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E0FDDE07C2; Wed, 4 May 2011 12:12:05 -0700 (PDT) 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 p44JBtK0009266; Wed, 4 May 2011 22:11:55 +0300 X-CheckPoint: {4DC1B234-0-1B221DC2-FFFF} 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; Wed, 4 May 2011 22:11:55 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 4 May 2011 22:11:55 +0300 From: Yoav Nir To: Dan Harkins Date: Wed, 4 May 2011 22:11:53 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwKjyENsFiPZoIpQ/CsK4nhAizRfg== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> In-Reply-To: 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: "ipsec@ietf.org" , Qin Wu , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 19:12:07 -0000 Hi Dan, On May 4, 2011, at 9:47 PM, Dan Harkins wrote: >=20 > On Tue, May 3, 2011 10:30 pm, Yoav Nir wrote: > [snip] >> The Authenticator needs the true identity to make policy decisions. >=20 > Well then DO NOT use EAP for authentication. >=20 > Dan. I'm sure I don't understand your point. The IKE responder does not need to = know whether the user's true identity in the sense of whether she is a cat = person or a dog person. "alice@example.com" is good enough for policy looku= ps and policy decisions, as well as for generating meaningful logs. "1542a0= f74aef5011@example.com", where the part before the at-sign is a hex represe= ntation of an ephemeral key is not.= From dharkins@lounge.org Wed May 4 13:45:02 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 E38E4E07A7; Wed, 4 May 2011 13:45:02 -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=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfErrot9iK04; Wed, 4 May 2011 13:45:02 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 13877E07C9; Wed, 4 May 2011 13:45:02 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5B8471022400A; Wed, 4 May 2011 13:45:01 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 May 2011 13:45:01 -0700 (PDT) Message-ID: <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> Date: Wed, 4 May 2011 13:45:01 -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" , Qin Wu , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 04 May 2011 20:45:03 -0000 On Wed, May 4, 2011 12:11 pm, Yoav Nir wrote: > Hi Dan, > > On May 4, 2011, at 9:47 PM, Dan Harkins wrote: > >> >> On Tue, May 3, 2011 10:30 pm, Yoav Nir wrote: >> [snip] >>> The Authenticator needs the true identity to make policy decisions. >> >> Well then DO NOT use EAP for authentication. >> >> Dan. > > I'm sure I don't understand your point. The IKE responder does not need to > know whether the user's true identity in the sense of whether she is a cat > person or a dog person. "alice@example.com" is good enough for policy > lookups and policy decisions, as well as for generating meaningful logs. > "1542a0f74aef5011@example.com", where the part before the at-sign is a hex > representation of an ephemeral key is not. Well my comment certainly wasn't a flippant one (cat person versus dog person?). So let me expand on it a bit. RFC 5996 says in section 2.16: "When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity, if different from that in the IDi payload, has to be sent from the AAA server to the IKEv2 responder." When sending EAP traffic over a AAA connection, the IKEv2 responder has no guarantee that the EAP conversation will be terminating on the AAA server he is passing the EAP traffic to. IDi might be an obfuscated identity used solely for AAA routing purposes and that routing might send it via a few proxies somewhere to a AAA server who has no idea what IKEv2 is, and even if it knew what IKEv2 is it might not know if IKEv2 was being used in this particular case. While proxies shouldn't be mucking with the EAP identity in the forwarded packet (the obfuscated and non-"true identity" one that isn't useful to the IKEv2 responder) they certainly can modify the Username attribute in the RADIUS packet that encapsulates it. That means that the identity a particular AAA server/proxy might get to see might not be what was originally put into the initial Access-Request by the IKEv2 responder and it might be different than the one, ultimately, obtained by the AAA server that actually speaks EAP. Furthermore, one or more of those proxies along the way might not even know what EAP is! Even if one assumes that the AAA server that terminated EAP will include the identity it authenticated as the Username attribute in the Access-Accept it sends back (and that it's included in all proxied Access-Accepts and ultimately reaches the IKEv2 responder) there is nothing that says that identity has any relevance or significance to the IKEv2 responder. It could be a SIM identity from EAP-SIM. It could be "emp12876" used in EAP-MD5 (yea, I know it's not supposed to be used, so tunnel it in PEAP and then you have a nice, compliant, key generating EAP method for IKEv2). Which means the IKEv2 responder has an obfuscated identity that is not useful for authentication purposes and, maybe, just maybe, it also has some identifier that was useful for a method it does not know in a realm/domain/whatever it also does not know. To sum, while the identity "has to be sent" (note the non-normative nature of that statement) there is no guarantee that it will. And even if it is sent, there is no guarantee that it will be useful in the way you need to use it. Therefore, if the authenticator needs to know the true identity (as you suggest it must) then don't use try to authenticate the IKEv2 peer in a way that might not get you what you need. regards, Dan. From ynir@checkpoint.com Wed May 4 22:45:19 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 4D05DE06DD; Wed, 4 May 2011 22:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.376 X-Spam-Level: X-Spam-Status: No, score=-8.376 tagged_above=-999 required=5 tests=[AWL=2.223, 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 iDkmeKsJYiJt; Wed, 4 May 2011 22:45:18 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1F124E06C0; Wed, 4 May 2011 22:45:17 -0700 (PDT) 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 p455j73M019418; Thu, 5 May 2011 08:45:07 +0300 X-CheckPoint: {4DC24699-0-1B221DC2-FFFF} 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; Thu, 5 May 2011 08:45:06 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 May 2011 08:45:06 +0300 From: Yoav Nir To: Dan Harkins Date: Thu, 5 May 2011 08:45:05 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwK55W7b3obDmz6QiC+tkvJnN9fTQ== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> In-Reply-To: <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> 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: "ipsec@ietf.org" , Qin Wu , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 05 May 2011 05:45:19 -0000 On May 4, 2011, at 11:45 PM, Dan Harkins wrote: >=20 > RFC 5996 says in section 2.16: >=20 > "When the initiator authentication uses EAP, it is possible that the > contents of the IDi payload is used only for Authentication, > Authorization, and Accounting (AAA) routing purposes and selecting > which EAP method to use. This value may be different from the > identity authenticated by the EAP method. It is important that > policy lookups and access control decisions use the actual > authenticated identity. Often the EAP server is implemented in a > separate AAA server that communicates with the IKEv2 responder. In > this case, the authenticated identity, if different from that in the > IDi payload, has to be sent from the AAA server to the IKEv2 > responder." >=20 > When sending EAP traffic over a AAA connection, the IKEv2 responder has > no guarantee that the EAP conversation will be terminating on the AAA > server he is passing the EAP traffic to. IDi might be an obfuscated > identity used solely for AAA routing purposes and that routing might send > it via a few proxies somewhere to a AAA server who has no idea what IKEv2 > is, and even if it knew what IKEv2 is it might not know if IKEv2 was > being used in this particular case. While proxies shouldn't be mucking > with the EAP identity in the forwarded packet (the obfuscated and > non-"true identity" one that isn't useful to the IKEv2 responder) they > certainly can modify the Username attribute in the RADIUS packet that > encapsulates it. That means that the identity a particular AAA > server/proxy might get to see might not be what was originally put into > the initial Access-Request by the IKEv2 responder and it might be > different than the one, ultimately, obtained by the AAA server that > actually speaks EAP. Furthermore, one or more of those proxies along the > way might not even know what EAP is! >=20 > Even if one assumes that the AAA server that terminated EAP will > include the identity it authenticated as the Username attribute in the > Access-Accept it sends back (and that it's included in all proxied > Access-Accepts and ultimately reaches the IKEv2 responder) there is > nothing that says that identity has any relevance or significance to > the IKEv2 responder. It could be a SIM identity from EAP-SIM. It could > be "emp12876" used in EAP-MD5 (yea, I know it's not supposed to be > used, so tunnel it in PEAP and then you have a nice, compliant, key > generating EAP method for IKEv2). Which means the IKEv2 responder has > an obfuscated identity that is not useful for authentication purposes > and, maybe, just maybe, it also has some identifier that was useful for > a method it does not know in a realm/domain/whatever it also does not > know. >=20 > To sum, while the identity "has to be sent" (note the non-normative > nature of that statement) there is no guarantee that it will. And even > if it is sent, there is no guarantee that it will be useful in the way > you need to use it. >=20 > Therefore, if the authenticator needs to know the true identity (as you > suggest it must) then don't use try to authenticate the IKEv2 peer in a > way that might not get you what you need. OK. I see what you mean. Certificates are not necessarily better. She might= have a certificate with a subject like "UID=3Dalice,OU=3Dpeople,O=3Dintran= et,DC=3Dexample,DC=3Dcom", or the AAA server might call her "emp715". Eith= er can serve. The VPN gateway needs the identity for two thing: - For policy lookup. As long as the policy database uses the same name, we= 're fine. - For generating logs. There should be a way to map the name in the logs t= o the real person, but I guess this re-conciliation of usernames and real n= ames can be done either in generating the logs or in viewing the logs. Any implementation using EAP has users that are either satisfied with "emp7= 15" or use a directory to convert that in the logs to a more meaningful nam= es. In ERP the value used in KeyName-NAI is the EMSKName (as defined in section= 3.2 or RFC 5295), or actually a hex representation of this value. The valu= e is 64-bit, so the username part of the KeyName-NAI is just 16 hex digits,= and they change each time the user does a full authentication. This value = is later copied to the UserName attribute in the RADIUS AccessRequest, and = probably also returned in the AccessAccept, although we're not sure that's = what really happens. This ephemeral value is much harder to map to either policy or to a meaning= ful name or to policy. Even if such a mapping can be done in real-time, it = cannot be done later after the EMSK expires and is deleted. Even for real-t= ime, it requires either the AAA server to store the policy and transmit it = in the AccessAccept, or else to have the directory closely working with the= RADIUS server to immediately map the EMSKName to a user record. From dharkins@lounge.org Wed May 4 23:18: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 52758E0789; Wed, 4 May 2011 23:18:01 -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 LvzKlq0ogJ5f; Wed, 4 May 2011 23:18:00 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 76DCAE073C; Wed, 4 May 2011 23:17:59 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 99B631022400A; Wed, 4 May 2011 23:17:58 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 May 2011 23:17:58 -0700 (PDT) Message-ID: <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> Date: Wed, 4 May 2011 23:17:58 -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" , Qin Wu , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 05 May 2011 06:18:01 -0000 Hello, On Wed, May 4, 2011 10:45 pm, Yoav Nir wrote: > > On May 4, 2011, at 11:45 PM, Dan Harkins wrote: >> >> RFC 5996 says in section 2.16: >> >> "When the initiator authentication uses EAP, it is possible that the >> contents of the IDi payload is used only for Authentication, >> Authorization, and Accounting (AAA) routing purposes and selecting >> which EAP method to use. This value may be different from the >> identity authenticated by the EAP method. It is important that >> policy lookups and access control decisions use the actual >> authenticated identity. Often the EAP server is implemented in a >> separate AAA server that communicates with the IKEv2 responder. In >> this case, the authenticated identity, if different from that in the >> IDi payload, has to be sent from the AAA server to the IKEv2 >> responder." >> >> When sending EAP traffic over a AAA connection, the IKEv2 responder has >> no guarantee that the EAP conversation will be terminating on the AAA >> server he is passing the EAP traffic to. IDi might be an obfuscated >> identity used solely for AAA routing purposes and that routing might >> send >> it via a few proxies somewhere to a AAA server who has no idea what >> IKEv2 >> is, and even if it knew what IKEv2 is it might not know if IKEv2 was >> being used in this particular case. While proxies shouldn't be mucking >> with the EAP identity in the forwarded packet (the obfuscated and >> non-"true identity" one that isn't useful to the IKEv2 responder) they >> certainly can modify the Username attribute in the RADIUS packet that >> encapsulates it. That means that the identity a particular AAA >> server/proxy might get to see might not be what was originally put into >> the initial Access-Request by the IKEv2 responder and it might be >> different than the one, ultimately, obtained by the AAA server that >> actually speaks EAP. Furthermore, one or more of those proxies along the >> way might not even know what EAP is! >> >> Even if one assumes that the AAA server that terminated EAP will >> include the identity it authenticated as the Username attribute in the >> Access-Accept it sends back (and that it's included in all proxied >> Access-Accepts and ultimately reaches the IKEv2 responder) there is >> nothing that says that identity has any relevance or significance to >> the IKEv2 responder. It could be a SIM identity from EAP-SIM. It could >> be "emp12876" used in EAP-MD5 (yea, I know it's not supposed to be >> used, so tunnel it in PEAP and then you have a nice, compliant, key >> generating EAP method for IKEv2). Which means the IKEv2 responder has >> an obfuscated identity that is not useful for authentication purposes >> and, maybe, just maybe, it also has some identifier that was useful for >> a method it does not know in a realm/domain/whatever it also does not >> know. >> >> To sum, while the identity "has to be sent" (note the non-normative >> nature of that statement) there is no guarantee that it will. And even >> if it is sent, there is no guarantee that it will be useful in the way >> you need to use it. >> >> Therefore, if the authenticator needs to know the true identity (as you >> suggest it must) then don't use try to authenticate the IKEv2 peer in a >> way that might not get you what you need. > > OK. I see what you mean. Certificates are not necessarily better. She > might have a certificate with a subject like > "UID=alice,OU=people,O=intranet,DC=example,DC=com", or the AAA server > might call her "emp715". Either can serve. The VPN gateway needs the > identity for two thing: > - For policy lookup. As long as the policy database uses the same name, > we're fine. > - For generating logs. There should be a way to map the name in the logs > to the real person, but I guess this re-conciliation of usernames and > real names can be done either in generating the logs or in viewing the > logs. Assuming the CA is trustworthy and the peer authenticated with that certificate then you know that the identity named by the subject name in the certificate is who that peer is. You can make a definitive statement about it (although I'm not sure what attributes UID or DC are). "emp715" returned in an Access-Accept means nothing because it's meaningful when used with an EAP method of X inside a realm/domain of Y and you don't know what either X or Y are. So you can't make any definitive statement about "emp715". > Any implementation using EAP has users that are either satisfied with > "emp715" or use a directory to convert that in the logs to a more > meaningful names. Not to belabor the point, but a user could have an authenticated identity of "emp715" in one realm/domain (that you don't know) and a completely different user could have an authenticated identity of "emp715" in a completely different realm/domain (that you also don't know). Treating them the same is probably not a wise thing to do from a policy enforcement standpoint. (There's a guy named "Dan Harkins" that owns a chain of theaters in the state of Arizona in the US. I am not that man and I don't live in Arizona, but I have received phone calls expressing outrage over the kind of films that "I" show in "my" family theater, and asking why "I" stopped giving out free popcorn to patrons on their birthday. I receive these calls because people take a name, stripped of all context, and assume something about it. And that is a mistake). regards, Dan. From ynir@checkpoint.com Wed May 4 23:59:56 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 DA7BFE06EC; Wed, 4 May 2011 23:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.535 X-Spam-Level: X-Spam-Status: No, score=-8.535 tagged_above=-999 required=5 tests=[AWL=2.064, 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 b9+42aWPmQ-m; Wed, 4 May 2011 23:59:55 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3B6E0692; Wed, 4 May 2011 23:59:55 -0700 (PDT) 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 p456xC2G030400; Thu, 5 May 2011 09:59:12 +0300 X-CheckPoint: {4DC257F6-0-1B221DC2-FFFF} 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; Thu, 5 May 2011 09:59:12 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 May 2011 09:59:11 +0300 From: Yoav Nir To: Dan Harkins Date: Thu, 5 May 2011 09:59:08 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwK8e8soLcUNJjRSJCsl/y2/yGw/g== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> In-Reply-To: <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> 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: "ipsec@ietf.org" , Qin Wu , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 05 May 2011 06:59:57 -0000 On May 5, 2011, at 9:17 AM, Dan Harkins wrote: >=20 > Hello, >=20 > On Wed, May 4, 2011 10:45 pm, Yoav Nir wrote: >>=20 >>>=20 >>=20 >> OK. I see what you mean. Certificates are not necessarily better. She >> might have a certificate with a subject like >> "UID=3Dalice,OU=3Dpeople,O=3Dintranet,DC=3Dexample,DC=3Dcom", or the AAA= server >> might call her "emp715". Either can serve. The VPN gateway needs the >> identity for two thing: >> - For policy lookup. As long as the policy database uses the same name, >> we're fine. >> - For generating logs. There should be a way to map the name in the logs >> to the real person, but I guess this re-conciliation of usernames and >> real names can be done either in generating the logs or in viewing the >> logs. >=20 > Assuming the CA is trustworthy and the peer authenticated with that > certificate then you know that the identity named by the subject name > in the certificate is who that peer is. You can make a definitive > statement about it (although I'm not sure what attributes UID or DC are). >=20 > "emp715" returned in an Access-Accept means nothing because it's > meaningful when used with an EAP method of X inside a realm/domain of Y > and you don't know what either X or Y are. So you can't make any > definitive statement about "emp715". Depending on how large your federation is, "emp715" may be unique. In the s= implest setup - one RADIUS server that holds records for all employees, it = probably is unique. Otherwise, it should probably be in the form of emp715@= example.com. In both cases it should be enough to later map to a real perso= n. If it's not, then the AAA setup has not been done right. >=20 >> Any implementation using EAP has users that are either satisfied with >> "emp715" or use a directory to convert that in the logs to a more >> meaningful names. >=20 > Not to belabor the point, but a user could have an authenticated > identity of "emp715" in one realm/domain (that you don't know) and > a completely different user could have an authenticated identity of > "emp715" in a completely different realm/domain (that you also don't > know). Treating them the same is probably not a wise thing to do from > a policy enforcement standpoint. I think it's up to administrators to make sure that names are unique and tr= aceable. If RADIUS has a record for Alice, with identifier "emp715", and wh= en the VPN gateway looks up this string it gets an entry for Bob, it's a de= ployment error. Besides, I think we're derailing the conversation. We have to assume that E= AP works somehow, otherwise we're not going to do ERP. The question is how = to get around the ephemeral identities transmitted in ERP. >=20 > (There's a guy named "Dan Harkins" that owns a chain of theaters in > the state of Arizona in the US. I am not that man and I don't live in > Arizona, but I have received phone calls expressing outrage over the kind > of films that "I" show in "my" family theater, and asking why "I" stopped > giving out free popcorn to patrons on their birthday. I receive these > calls because people take a name, stripped of all context, and assume > something about it. And that is a mistake). Strange. I never get calls from people asking for diaper advice. http://www.yoavnir.com Yoav (not a diaper consultant) From balaji.1manarmy@gmail.com Thu May 5 04:06: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 9B865E086A for ; Thu, 5 May 2011 04:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHUoar4yhpLn for ; Thu, 5 May 2011 04:06:56 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77841E0861 for ; Thu, 5 May 2011 04:06:56 -0700 (PDT) Received: by eye13 with SMTP id 13so729125eye.31 for ; Thu, 05 May 2011 04:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=0iZh/gStriPBvKTpHi/+4sRtDnDVFBqyeW/8LLQ9qP8=; b=VO++wfTzOCmkp4nvoQ72hJ2+LdAOgWSE3HiywGoU3LmLM/87y4UwK8NV16pTxwx27D iAViwioMomkrdEpvDZcB/X+9hmY/TFPGWdB569VyOQfCStd4MNytCDWK5OOuVItOfygC o1JRpuOSnHzoxshwgforiu8qVCv78YqhdsNJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UJkMUqhQ+1gMjNZ8VkEsu1A3dj3sOnY5sLgXCghI4AdX4BToPLzv4+8vQQGWLGIqpR mJuAWCNJcdj5bmx1FyT/4lABoDy9CCWbCK3jYN/RcI5EB1TIfZ4c1AYYyix5Up1E7Tbq Bk3U0WuwZVplqrSjKgEWV19VZnLeLycubJer0= MIME-Version: 1.0 Received: by 10.213.26.155 with SMTP id e27mr223499ebc.136.1304593615407; Thu, 05 May 2011 04:06:55 -0700 (PDT) Received: by 10.213.19.203 with HTTP; Thu, 5 May 2011 04:06:55 -0700 (PDT) Date: Thu, 5 May 2011 16:36:55 +0530 Message-ID: From: Balaji J To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0015174c138e05c9d704a2855f44 Subject: [IPsec] Clarification needed on ipv6 address assignment 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, 05 May 2011 11:06:57 -0000 --0015174c138e05c9d704a2855f44 Content-Type: text/plain; charset=ISO-8859-1 Hi ppl, Could anyone please clarify the following statement in the IKEv2 RFC 5996: ****** The Configuration payloads for IPv6 are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing things". In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used, neither is neighbor discovery.****** Does it mean that we should not do Router-Solicitation/Router-Advertisement messages over the established IPSEC-SA also for Stateless AutoConf? Even though the IPV6 address is assigned using IKEv2 Configuration Payload, what stops the node from doing the Stateless AutoConf using Router Solicitation/Advertisement messages sent over the IPSEC tunnel by making sure that the same Prefix assigned during IKE-AUTH exchange is communicated in the Router-Advertisement also? Because i believe this makes us compliant to IPV6 way of configuring the ip-address even though IKEv2 is used. Please clarify. Thanks, ...Balaji.J --0015174c138e05c9d704a2855f44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi ppl,

Could anyone please clarify the following statement in the I= KEv2 RFC 5996:

****** The Configuration payloads for IPv6 are based = on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doin= g things".
=A0 =A0 =A0 =A0=A0 In particular, IPv6 stateless autoc= onfiguration or router advertisement messages are not used, neither is neighbor discovery.*****= *

Does it mean that we should not do Route= r-Solicitation/Router-Advertisement messages over the established IPSEC-SA = also for Stateless AutoConf?
Even though the IPV6 address is assigned using IKEv2 Configuration Payload,= what stops the node from doing the Stateless AutoConf using
Router Sol= icitation/Advertisement messages sent over the IPSEC tunnel by making sure = that the same Prefix assigned during IKE-AUTH exchange
is communicated in the Router-Advertisement also?

Because i believe = this makes us compliant to IPV6 way of configuring the ip-address even thou= gh IKEv2 is used.

Please clarify.

Thanks,
...Balaji.J

--0015174c138e05c9d704a2855f44-- From ynir@checkpoint.com Thu May 5 04:34:35 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 C1367E06F2 for ; Thu, 5 May 2011 04:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.672 X-Spam-Level: X-Spam-Status: No, score=-8.672 tagged_above=-999 required=5 tests=[AWL=1.927, 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 L5+f6zf0n4fD for ; Thu, 5 May 2011 04:34:35 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2AE0721 for ; Thu, 5 May 2011 04:34:34 -0700 (PDT) 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 p45BQffh008425; Thu, 5 May 2011 14:34:32 +0300 X-CheckPoint: {4DC296A5-1-1B221DC2-FFFF} 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; Thu, 5 May 2011 14:33:02 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 May 2011 14:33:02 +0300 From: Yoav Nir To: Balaji J Date: Thu, 5 May 2011 14:32:59 +0300 Thread-Topic: [IPsec] Clarification needed on ipv6 address assignment Thread-Index: AcwLGDEZryGVLJ0jRWaN8tsefoPqQA== Message-ID: <4BB9FAB6-3527-40FD-B4A3-90FAB282D194@checkpoint.com> References: In-Reply-To: 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: "ipsec@ietf.org" Subject: Re: [IPsec] Clarification needed on ipv6 address assignment 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, 05 May 2011 11:34:35 -0000 Hi Balaji.J For the most part, a VPN gateway uses sufficiently few addresses (hundreds = or a few thousands) that IPv6 is not necessary. This is the reason that the= re was little interest in changing the way IPv6 addresses are assigned in C= ONFIG payloads. There's also the idea that with IPv6 there will be sufficient routable addr= esses to negate the necessity of using CONFIG payloads. Either way, there's an RFC that covers assignment of IPv6 addresses in CFG = payloads in a more IPv6-y way. RFC 5739. http://tools.ietf.org/html/rfc5739 Hope this helps Yoav On May 5, 2011, at 2:06 PM, Balaji J wrote: > Hi ppl, >=20 > Could anyone please clarify the following statement in the IKEv2 RFC 5996= : >=20 > ****** The Configuration payloads for IPv6 are based on the corresponding= IPv4 payloads, and do not fully follow the "normal IPv6 way of doing thing= s".=20 > In particular, IPv6 stateless autoconfiguration or router advert= isement messages are not used, neither is neighbor discovery.****** >=20 > Does it mean that we should not do Router-Solicitation/Router-Advertiseme= nt messages over the established IPSEC-SA also for Stateless AutoConf? > Even though the IPV6 address is assigned using IKEv2 Configuration Payloa= d, what stops the node from doing the Stateless AutoConf using=20 > Router Solicitation/Advertisement messages sent over the IPSEC tunnel by = making sure that the same Prefix assigned during IKE-AUTH exchange > is communicated in the Router-Advertisement also? >=20 > Because i believe this makes us compliant to IPV6 way of configuring the = ip-address even though IKEv2 is used. >=20 > Please clarify. >=20 > Thanks, > ...Balaji.J >=20 > From yaronf.ietf@gmail.com Thu May 5 13:41:22 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 9D5AEE0799; Thu, 5 May 2011 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 fXO25+vU6Pw8; Thu, 5 May 2011 13:41:21 -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 4314AE0778; Thu, 5 May 2011 13:41:21 -0700 (PDT) Received: by wyb29 with SMTP id 29so2194975wyb.31 for ; Thu, 05 May 2011 13:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wnYFm51CaB5fR1VsXM4CumoVOONAu9cLhjYvu7kBWoc=; b=RRoDcPQQrDx5nxFVNrI/u1Te9XFdfZDbUaLNIna71OdFqzfryL4lrgqzuYB8s8C73h ezTKrFGukwaD5MLmyLTA/akQhxQMKtzeWZJBY96wHtfm6nEMlrMC2Vk3gLsbBaBQBIeH 9PviLL3enuXY9plI4aFYnUw604we5qowlAIbo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=PY6ZOC79QkrS0RCIOBHP4ZpjfV2BomP0/lf2lf2+kOeIlZj/QBIHZ6FpACLwNsmzEt p1YePO06+4JTpNlW1bXPE0J+2uQtB0g3mIkBnKMT74hXq/QtKPIyprJQK/68EcsK/5fI 07T1Oi3w6Fy/lat2spj7ZaaeJ2jyq7wa6BcrE= Received: by 10.227.128.20 with SMTP id i20mr3041642wbs.3.1304628077246; Thu, 05 May 2011 13:41:17 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-181-31-81.red.bezeqint.net [79.181.31.81]) by mx.google.com with ESMTPS id w12sm1585295wby.24.2011.05.05.13.41.14 (version=SSLv3 cipher=OTHER); Thu, 05 May 2011 13:41:15 -0700 (PDT) Message-ID: <4DC30B68.70202@gmail.com> Date: Thu, 05 May 2011 23:41:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Qin Wu , Dan Harkins , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 05 May 2011 20:41:22 -0000 Hi,

I think we are going down a rathole on the issue of "authenticated identity". Most IKE gateways, like many other security devices, normally make policy decisions based on groups. I will provide secure connectivity to anybody@this-isp.com, but not to anybody@that-isp.com. But I don't want to differentiate john@isp.com from jane@isp.com.

It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.

So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.

Thanks,
    Yaron
From yaronf.ietf@gmail.com Fri May 6 02:05: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 301B8E0659 for ; Fri, 6 May 2011 02:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 SZd14u8iADDn for ; Fri, 6 May 2011 02:04:59 -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 9DA7FE0701 for ; Fri, 6 May 2011 02:04:59 -0700 (PDT) Received: by wyb29 with SMTP id 29so2581168wyb.31 for ; Fri, 06 May 2011 02:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Oi/IwwW/CmWLtpUeGCI/MdGZl4AlV2UGVR46RmAWIBQ=; b=UJuireful3g9NeqtKsJsddVLuqnPNWsoF/KY9tOs/ZoMexmECLei8WErV+tbJhb5Ls x2VDdEau/noNrXXkJ3vCUjIzI+761mj3bN3RryXuOrQEquwQoJFV7W2aL/TI/CM5lvxB 0sbM9sekV13bwy4Wj9prJJG2DooDr2UjG/vc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=o45GGbzDsvyaGb15qyK7C3rztaXQx5EGil6jWbgzVogqUYzhQM0O/eLz54u2nN5owG yykd1fqOwUfHiPwLOpquthgVC4xXthnShPZgcqE5rm/71uddu4FxP8FGp9a/F6hk5M0x qfhZtZGyl6Nqfq2VKmFDkvTVbIA4f8R1YTU3s= Received: by 10.227.162.200 with SMTP id w8mr1932480wbx.114.1304672698331; Fri, 06 May 2011 02:04:58 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-181-31-81.red.bezeqint.net [79.181.31.81]) by mx.google.com with ESMTPS id x13sm1370944wby.42.2011.05.06.02.04.57 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 02:04:57 -0700 (PDT) Message-ID: <4DC3B9B7.3030402@gmail.com> Date: Fri, 06 May 2011 12:04:55 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [IPsec] Fwd: New Version Notification for draft-ietf-ipsecme-ipsecha-protocol-06 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, 06 May 2011 09:05:01 -0000 We have submitted a new version of the draft, addressing a large number of (mostly minor) comments from the IESG, as well as from Pekka Riikonen on this list. The most significant changes are a new architectural diagram and an improvement to the Examples appendix.

Thanks,
    Yaron

-------- Original Message --------
Subject: New Version Notification for draft-ietf-ipsecme-ipsecha-protocol-06
Date: Fri, 6 May 2011 02:01:12 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: yaronf.ietf@gmail.com
CC: ynir@checkpoint.com,kagarigi@cisco.com,rsj@cisco.com,zhangdacheng@huawei.com 


A new version of I-D, draft-ietf-ipsecme-ipsecha-protocol-06.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository.

Filename:	 draft-ietf-ipsecme-ipsecha-protocol
Revision:	 06
Title:		 Protocol Support for High Availability of IKEv2/IPsec
Creation_date:	 2011-05-06
WG ID:		 ipsecme
Number_of_pages: 26

Abstract:
The IPsec protocol suite is widely used for business-critical network
traffic.  In order to make IPsec deployments highly available, more
scalable and failure-resistant, they are often implemented as IPsec
High Availability (HA) clusters.  However there are many issues in
IPsec HA clustering, and in particular in IKEv2 clustering.  An
earlier document, "IPsec Cluster Problem Statement", enumerates the
issues encountered in the IKEv2/IPsec HA cluster environment.  This
document resolves these issues with the least possible change to the
protocol.

This document defines an extension to the IKEv2 protocol to solve the
main issues of "IPsec Cluster Problem Statement" in the commonly
deployed hot-standby cluster, and provides implementation advice for
other issues.  The main issues solved are the synchronization of
IKEv2 Message ID counters, and of IPsec Replay Counters.
                                                                                  


The IETF Secretariat.
From Internet-Drafts@ietf.org Fri May 6 02:15:03 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 31088E0715; Fri, 6 May 2011 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 VMoNrPEoKrGE; Fri, 6 May 2011 02:15:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF13E0694; Fri, 6 May 2011 02:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 02:15:01 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-06.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: Fri, 06 May 2011 09:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Protocol Support for High Availability of IKEv2/IPsec Author(s) : R. Jenwar, et al. Filename : draft-ietf-ipsecme-ipsecha-protocol-06.txt Pages : 26 Date : 2011-05-06 The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol. This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ipsecha-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06020112.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Fri May 6 11:03: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 83A8BE07CD; Fri, 6 May 2011 11:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 19-Jxaovi9f8; Fri, 6 May 2011 11:02:59 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EB707E07CC; Fri, 6 May 2011 11:02:58 -0700 (PDT) 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 p46I2TXS008219; Fri, 6 May 2011 21:02:30 +0300 X-CheckPoint: {4DC444E3-1-1B221DC2-FFFF} 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; Fri, 6 May 2011 21:02:29 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 6 May 2011 21:02:29 +0300 From: Yoav Nir To: Yaron Sheffer Date: Fri, 6 May 2011 21:02:27 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwMF8NZEbl1lUmmQRi8xpHfWp0UsA== Message-ID: <624EB8DD-96F6-422A-A2DE-B02A0507BF14@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> <4DC30B68.70202@gmail.com> In-Reply-To: <4DC30B68.70202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_624EB8DD96F6422AA2DEB02A0507BF14checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Qin Wu , Dan Harkins , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 06 May 2011 18:03:00 -0000 --_000_624EB8DD96F6422AA2DEB02A0507BF14checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 5, 2011, at 11:41 PM, Yaron Sheffer wrote: Hi, I think we are going down a rathole on the issue of "authenticated identity= ". Most IKE gateways, like many other security devices, normally make polic= y decisions based on groups. I will provide secure connectivity to anybody@= this-isp.com, but not to anybody@that-isp.com<= mailto:anybody@that-isp.com>. But I don't want to differentiate john@isp.co= m from jane@isp.com. True, but often we cut the groups finer than that. If John works in sales a= nd Jane works in R&D, they may have different authorizations (John does not= go near the source control, Jane does not get to see the financial stateme= nt to be published next week). To negotiate the appropriate selectors, the = gateway needs some group information. This can be done by abusing some RADI= US attribute to convey policy information, or else by querying a directory = with the username received in EAP. With ephemeral identities I don't see how this could work, unless we assume= that there is a way for the gateway to query the AAA about some attributes= of the user behind the EMSKNAme. It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 e= ver intended (in fact I believe the text is new to RFC 5996). Presumably, w= hen we talk about identity-based policy decisions, we refer to http://tools= .ietf.org/html/rfc4301#section-4.4.3. This text (and the following section)= explicitly allows for "bulk" policies that apply to "@example.com", i.e. a= nybody at that domain. And such coarse granularity may be sufficient in pra= ctice for inter-ISP traffic: ISP1 may be happy to provide secure connectivi= ty to ISP2's customers and take a cut of the business, even if it doesn't k= now the exact identity of each customer and cannot contact them, bill them = or log their names. So I would suggest that the draft should mention that no individual authent= icated identity is available in the typical case (and this is unfortunately= in conflict with RFC 5996), but the obscured identity provided in RADIUS A= ccess-Accept can be used to make legitimate policy decisions. I'm not even sure of that. Qin, does ERP give us the domain name of the ori= ginal authenticating server? Do we even know if the user came from this-is= p or that-isp? Thanks, Yaron --_000_624EB8DD96F6422AA2DEB02A0507BF14checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On May 5, 20= 11, at 11:41 PM, Yaron Sheffer wrote:

Hi,

I think we are going down a rathole on the issue of "authenticated identity". Most IKE gateways, like many other security devices, normally make policy decisions based on groups. I will provide secure connectivity to anybody@this-isp.com, but not to anybody@that-isp.com. But I don't want to differentiate john@isp.com from jane@isp.com.

True, but ofte= n we cut the groups finer than that. If John works in sales and Jane works = in R&D, they may have different authorizations (John does not go near t= he source control, Jane does not get to see the financial statement to be p= ublished next week). To negotiate the appropriate selectors, the gateway ne= eds some group information. This can be done by abusing some RADIUS attribu= te to convey policy information, or else by querying a directory with the u= sername received in EAP.

With ephemeral identities= I don't see how this could work, unless we assume that there is a way for = the gateway to query the AAA about some attributes of the user behind the E= MSKNAme.


It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to h= ttp://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.

So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.

I'm not even sur= e of that. Qin, does ERP give us the domain name of the original authentica= ting server?  Do we even know if the user came from this-isp or that-i= sp?


Thanks,
    Yaron

= --_000_624EB8DD96F6422AA2DEB02A0507BF14checkpointcom_-- From sunseawq@huawei.com Fri May 6 17:42: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 75F5FE07A2; Fri, 6 May 2011 17:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 ZMvTRNy8PvK8; Fri, 6 May 2011 17:42:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D7E06B1; Fri, 6 May 2011 17:42:29 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKS00DEDVAQVQ@szxga05-in.huawei.com>; Sat, 07 May 2011 08:42:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKS0046HVAPJT@szxga05-in.huawei.com>; Sat, 07 May 2011 08:42:26 +0800 (CST) Received: from C863D63E94E7457 ([220.114.250.53]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKS006EFVAOGE@szxml11-in.huawei.com>; Sat, 07 May 2011 08:42:25 +0800 (CST) Date: Sat, 07 May 2011 08:42:53 +0800 From: Qin Wu To: Yoav Nir , Yaron Sheffer Message-id: <007301cc0c4f$b3c45540$ff5afea9@C863D63E94E7457> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_tWwmbNxaE4yr7NJCVV5ruA)" X-Priority: 3 X-MSMail-priority: Normal References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> <4DC30B68.70202@gmail.com> <624EB8DD-96F6-422A-A2DE-B02A0507BF14@checkpoint.com> Cc: ipsec@ietf.org, Dan Harkins , hokey@ietf.org Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 07 May 2011 00:42:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tWwmbNxaE4yr7NJCVV5ruA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names. So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions. I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server? Do we even know if the user came from this-isp or that-isp? Thanks, Yaron [Qin]: Sure. The domain name of the original authenticating server you are talking about is actually home domain name. The peer bootstraps from the home domain at the first time and should know home domain name or home ER server name wherever it moves around. The peer learns local domain name through ERP message or other lower layer mechanism. Therefore the peer can identify which domain it move to. The local ER server and ER authenticator can know domain name through realm part of KeyName-NAI TLV carried in the ERP message sent from the peer. Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain. ------------------------------------------------------------------------------ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_tWwmbNxaE4yr7NJCVV5ruA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
 


It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.

So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.

I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server?  Do we even know if the user came from this-isp or that-isp?


Thanks,
    Yaron
 
[Qin]: Sure.
 
The domain name of the original authenticating server you are talking about is actually home domain name.
The peer bootstraps from the home domain at the first time and should know home domain name or home ER server name wherever it moves around.
The peer learns local domain name through ERP message or other lower layer mechanism. Therefore the peer can identify which domain it move to.
The local ER server and ER  authenticator can know domain name through realm part of KeyName-NAI TLV carried in the ERP message sent from the peer.
Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain.
 
 
 
 

 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--Boundary_(ID_tWwmbNxaE4yr7NJCVV5ruA)-- From iesg-secretary@ietf.org Mon May 9 06:33: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 3A763E0752; Mon, 9 May 2011 06:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 kw6oLntWR79m; Mon, 9 May 2011 06:33:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE9E074D; Mon, 9 May 2011 06:33:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509133320.22730.62164.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 06:33:20 -0700 Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Protocol Action: 'Protocol Support for High Availability of IKEv2/IPsec' to Proposed Standard (draft-ietf-ipsecme-ipsecha-protocol-06.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: Mon, 09 May 2011 13:33:21 -0000 The IESG has approved the following document: - 'Protocol Support for High Availability of IKEv2/IPsec' (draft-ietf-ipsecme-ipsecha-protocol-06.txt) as a Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipsecha-protocol/ Technical Summary The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec and IKEv2 HA clustering. This document proposes an extension to the IKEv2 protocol to solve the main issues raised in the "IPsec Cluster Problem Statement" for the commonly deployed hot- standby cluster, and provides implementation advice for other issues. The main issues to be solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters. Working Group Summary There were no notable issues with the WG process. The initial document review was more than satisfactory. More recently the WG has had a lower level of energy, and consequently fewer reviews of ongoing work. Document Quality We are not aware of implementations of this protocol. However this protocol is solving a set of well-known issues, so we expect vendors to implement it as IKEv2 becomes mainstream. Personnel Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd. Sean Turner (turners@ieca.com) is the responsible AD. Tero Kivinen (kivinen@iki.fi) is the expert reviewer. From tena@huawei.com Tue May 10 12:46: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 6F785E074F for ; Tue, 10 May 2011 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvRNa9qwHNaz for ; Tue, 10 May 2011 12:46:14 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 1E96EE0761 for ; Tue, 10 May 2011 12:46:14 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKZ008LQW911B@usaga03-in.huawei.com> for ipsec@ietf.org; Tue, 10 May 2011 14:46:13 -0500 (CDT) Received: from TingZousc1 ([12.133.183.34]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKZ00HCYW90VS@usaga03-in.huawei.com> for ipsec@ietf.org; Tue, 10 May 2011 14:46:13 -0500 (CDT) Date: Tue, 10 May 2011 12:45:37 -0700 From: Tina Tsou To: ipsec@ietf.org Message-id: <000301cc0f4a$eb671660$c2354320$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwPStKwaGbJjd6kR22PFAz3m8+Orw== x-cr-hashedpuzzle: Aw39 CQGW CvBz DmEH EO1Z HEOj JKc4 J3QR M56M QY/E RXGL TJAw UduC Vc8J XRvz XhVu; 2; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAeABpAGEAbgBnAHkAYQBuAGcALgB6AGgAYQBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {E0DB0DC8-ADA0-44FD-8DF6-EEBE7CE21B99}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 10 May 2011 19:45:32 GMT; RAByAGEAZgB0AC0AegBoAGEAbgBnAC0AaQBwAHMAZQBjAG0AZQAtAGEAbgB0AGkALQByAGUAcABsAGEAeQA6ACAASQBQAHMAZQBjACAAYQBuAHQAaQAtAHIAZQBwAGwAYQB5ACAAYQBsAGcAbwByAGkAdABoAG0AIAB3AGkAdABoAG8AdQB0ACAAYgBpAHQALQBzAGgAaQBmAHQAaQBuAGcA x-cr-puzzleid: {E0DB0DC8-ADA0-44FD-8DF6-EEBE7CE21B99} Cc: 'Xiangyang zhang' Subject: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 10 May 2011 19:46:15 -0000 Hi, Victor and I just submitted https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/ IPsec anti-replay algorithm without bit-shifting This document presents a new method to do anti-replay check and update, which becomes one alternative to the anti-replay algorithm in RFC 4302 and RFC4303. The new method will deem the bit-shifting unnecessary. It will reduce the number of times to slide the window. In addition, it makes bit-check and bit-update easier as it does not depend on the low index of the sliding window. It is especially beneficial when the window size is much bigger than 64 bits, for example, 1024 bits. IPsec employs one anti-replay sliding window protocol to secure against an adversary that can insert the messages inside the network tunnel. This method still inherits the sliding window protocol, but use one or more redundant bytes to ease the update of sliding window. The bit-shifting is deemed unnecessary with updating the high and low index of the window, which is especially efficient in case of the big window size. Thus the method reduces the number of times to update the window. In addition, the bit location is fixed for one sequence number, thus makes the bit check easier and faster. Comments are more than welcome. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From ynir@checkpoint.com Wed May 11 07:19: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 B4F9DE0728; Wed, 11 May 2011 07:19: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1W9PZsYpzTB; Wed, 11 May 2011 07:19:55 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0A0E069E; Wed, 11 May 2011 07:19:54 -0700 (PDT) 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 p4BEJ8Jg009322; Wed, 11 May 2011 17:19:12 +0300 X-CheckPoint: {4DCAA7EE-1-1B221DC2-FFFF} 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; Wed, 11 May 2011 17:19:08 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 11 May 2011 17:19:07 +0300 From: Yoav Nir To: Qin Wu Date: Wed, 11 May 2011 17:19:10 +0300 Thread-Topic: [IPsec] New I-D: draft-nir-ipsecme-erx-00 Thread-Index: AcwP5mPOfoyqw3WJRgu+tl0wnmewUA== Message-ID: <6754CE76-DC10-4912-8D13-33A4CDC764CC@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> <4DC30B68.70202@gmail.com> <624EB8DD-96F6-422A-A2DE-B02A0507BF14@checkpoint.com> <007301cc0c4f$b3c45540$ff5afea9@C863D63E94E7457> In-Reply-To: <007301cc0c4f$b3c45540$ff5afea9@C863D63E94E7457> 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: "ipsec@ietf.org" , Dan Harkins , "hokey@ietf.org" Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 11 May 2011 14:19:55 -0000 On May 7, 2011, at 3:42 AM, Qin Wu wrote: > =20 >=20 >>=20 >> It seems to me RFC 4306/5996 took the concept a bit further than RFC 430= 1 ever intended (in fact I believe the text is new to RFC 5996). Presumably= , when we talk about identity-based policy decisions, we refer to http://to= ols.ietf.org/html/rfc4301#section-4.4.3. This text (and the following secti= on) explicitly allows for "bulk" policies that apply to "@example.com", i.e= . anybody at that domain. And such coarse granularity may be sufficient in = practice for inter-ISP traffic: ISP1 may be happy to provide secure connect= ivity to ISP2's customers and take a cut of the business, even if it doesn'= t know the exact identity of each customer and cannot contact them, bill th= em or log their names. >>=20 >> So I would suggest that the draft should mention that no individual auth= enticated identity is available in the typical case (and this is unfortunat= ely in conflict with RFC 5996), but the obscured identity provided in RADIU= S Access-Accept can be used to make legitimate policy decisions. >=20 > I'm not even sure of that. Qin, does ERP give us the domain name of the o= riginal authenticating server? Do we even know if the user came from this-= isp or that-isp? >=20 >>=20 >> Thanks, >> Yaron > =20 > [Qin]: Sure. > =20 > The domain name of the original authenticating server you are talking abo= ut is actually home domain name. > The peer bootstraps from the home domain at the first time and should kno= w home domain name or home ER server name wherever it moves around. > The peer learns local domain name through ERP message or other lower laye= r mechanism. Therefore the peer can identify which domain it move to. > The local ER server and ER authenticator can know domain name through re= alm part of KeyName-NAI TLV carried in the ERP message sent from the peer. > Comparing realm part of KeyName-NAI and the domain which they belong to, = they also can identify if the user come from home domain or local domain. I wonder if local domain is ever distinct from home domain with IKE. IKE/IPsec is usually used for site-to-site and for remote access VPNs. Ther= e is also some use for host-to-host, but I don't know what they use for aut= hentication. In the case of remote-access, the client connects to some home gateway. Unl= ess there's some complex federation going with a single gateway answering f= or multiple domains, everyone connects to a gateway that is connected direc= tly to the home RADIUS server. Even phones with an Internet (not 3G/4G) con= nection will connect to their "home" operator network rather than to a loca= l operator network. So I don't think there's a case where the AAA server is not the home server= . And in that case, the AAA server has the real user name. So if we're usin= g re-authentication, the VPN gateway has the domain (it is the same domain)= and an ephemeral identity generated by the original EAP, which may have be= en done with another authenticator (such as a 802.1x access point) This reduces the problem to getting the real ID from the ephemeral ID, assu= ming that you are talking to the real RADIUS server, or else being able to = fetch policy from such a server or from an LDAP server. I guess vendors cou= ld have proprietary solutions, but I'm wondering if there's a standardized = way to do this. From sunseawq@huawei.com Thu May 12 00:07:36 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 57875E06E3; Thu, 12 May 2011 00:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, 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 99LJ+kWy1ers; Thu, 12 May 2011 00:07:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 328EBE06B7; Thu, 12 May 2011 00:07:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200AZ5MGJVF@szxga04-in.huawei.com>; Thu, 12 May 2011 15:07:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200EG7MGJYH@szxga04-in.huawei.com>; Thu, 12 May 2011 15:07:31 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL200GFMMGJPN@szxml04-in.huawei.com>; Thu, 12 May 2011 15:07:31 +0800 (CST) Date: Thu, 12 May 2011 15:11:14 +0800 From: Qin Wu To: Yoav Nir Message-id: <020501cc1073$c807f570$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> <4DC30B68.70202@gmail.com> <624EB8DD-96F6-422A-A2DE-B02A0507BF14@checkpoint.com> <007301cc0c4f$b3c45540$ff5afea9@C863D63E94E7457> <6754CE76-DC10-4912-8D13-33A4CDC764CC@checkpoint.com> Cc: ipsec@ietf.org, Dan Harkins , hokey@ietf.org Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 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, 12 May 2011 07:07:36 -0000 Hi, ----- Original Message ----- From: "Yoav Nir" To: "Qin Wu" Cc: ; "Dan Harkins" ; Sent: Wednesday, May 11, 2011 10:19 PM Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 > > On May 7, 2011, at 3:42 AM, Qin Wu wrote: > >> >> >>> >>> It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names. >>> >>> So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions. >> >> I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server? Do we even know if the user came from this-isp or that-isp? >> >>> >>> Thanks, >>> Yaron >> >> [Qin]: Sure. >> >> The domain name of the original authenticating server you are talking about is actually home domain name. >> The peer bootstraps from the home domain at the first time and should know home domain name or home ER server name wherever it moves around. >> The peer learns local domain name through ERP message or other lower layer mechanism. Therefore the peer can identify which domain it move to. >> The local ER server and ER authenticator can know domain name through realm part of KeyName-NAI TLV carried in the ERP message sent from the peer. >> Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain. > > I wonder if local domain is ever distinct from home domain with IKE. [Qin]: From AAA perspective, local domain or visited domain should be distinct from home domain. >From IKE perspective, I am not sure. > IKE/IPsec is usually used for site-to-site and for remote access VPNs. There is also some use for host-to-host, but I don't know what they use for authentication. > > In the case of remote-access, the client connects to some home gateway. Unless there's some complex federation going with a single gateway answering for multiple domains, everyone connects to a gateway that is connected directly to the home RADIUS server. Even phones with an Internet (not 3G/4G) connection will connect to their "home" operator network rather than to a local operator network. > > So I don't think there's a case where the AAA server is not the home server. And in that case, the AAA server has the real user name. So if we're using re-authentication, the VPN gateway has the domain (it is the same domain) and an ephemeral identity generated by the original EAP, which may have been done with another authenticator (such as a 802.1x access point) [Qin]: It depdents on the scenario you are talking about. When you are doing authorization, you should go back to home domain to talk with home AAA server since Home AAA server maintain user profile. When you are doing authentication, it is not necessary to go back to talk with home server each time since keying materails can be transported to the domain which the client currectly connected to. If you assume authorization and authentication are doing together each time, Fine, ERP described in RFC5296 allows this case. In such case, there is no local ER server deployed in the visited domain, therefore each time the client or the peer should go back to talk with home server. Also I should point out EAP server or ER server may be separated from AAA server. > This reduces the problem to getting the real ID from the ephemeral ID, assuming that you are talking to the real RADIUS server, or else being able to fetch policy from such a server or from an LDAP server. I guess vendors could have proprietary solutions, but I'm wondering if there's a standardized way to do this. [Qin] We can go to do authorization in home domain each time. In this way, we can be easy to get real ID. BTW:I remember this similar issue had been discussed in DIME and Hokey Working group. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Thu May 12 06:34: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 F0C0EE074A for ; Thu, 12 May 2011 06:34:06 -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 jCwKxYH7j1YL for ; Thu, 12 May 2011 06:34:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788FE06BE for ; Thu, 12 May 2011 06:34:01 -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 p4CDXxkE026742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2011 16:33:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4CDXxqU003004; Thu, 12 May 2011 16:33:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="QNfLBaKe+4" Content-Transfer-Encoding: 7bit Message-ID: <19915.57799.238001.125161@fireball.kivinen.iki.fi> Date: Thu, 12 May 2011 16:33:59 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Subject: [IPsec] New draft draft-kivinen-ipsecme-secure-password-framework-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 13:34:07 -0000 --QNfLBaKe+4 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit As the last discussion attempt about trying to create common way to put those multiple symmetric secure password methods IKEv2 was bit side-railed by misunderstandings etc, I decided it is better to write bit more about the issue before continue on the issue. Here is the draft that includes bit more of introduction and rationale what I want to do and what I hope the draft authors would agree to do on. This draft is not necessarely something that requires to be published, we could simply also make sure all three secure password methods cut & paste the relevant stuff from here and put all the relevant text to their own documents, as long as all of them agree that they do things in the same way so they can all co-exists together in one implemtation. On the other hand documenting the common grounds in separate document might be easier for the implementor to understand what he needs to do and what he can assume from the secure password methods, i.e. implementor does not need to verify that all of the methods do method negotiation in the same way, if all of them refer to same document (compared to the case where they copy the same text and put it in to their document). Hopefully this draft will clarify things bit more. http://www.ietf.org/id/draft-kivinen-ipsecme-secure-password-framework-00.txt --QNfLBaKe+4 Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit CONTENT-TRANSFER-ENCODING: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fireball.kivinen.iki.fi X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_50,IKI_FI_RECEIVED, KIVINEN_DIPLOM_TEXT,KIVINEN_GOOD_TEXT,KIVINEN_INVESTMENT_FOUND, RCVD_IN_DNSWL_MED autolearn=no version=3.2.5 Received: from ikiaikainen.iki.fi (root@ikiaikainen.iki.fi [212.16.98.54]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p4CDKa4R020985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2011 16:20:36 +0300 (EEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by ikiaikainen.iki.fi (8.14.4/8.14.4) with ESMTP id p4CDKYRi006288 for ; Thu, 12 May 2011 16:20:35 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378E9E0770 for ; Thu, 12 May 2011 06:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 fGQFTp-f0bFe for ; Thu, 12 May 2011 06:20:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C15E078F; Thu, 12 May 2011 06:20:32 -0700 (PDT) X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110512132032.7757.12880.idtracker@ietfa.amsl.com> From: internet-drafts@ietf.org To: kivinen@iki.fi Cc: kivinen@iki.fi Subject: New Version Notification for draft-kivinen-ipsecme-secure-password-framework-00.txt Date: Thu, 12 May 2011 06:20:32 -0700 A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-0= 0.txt has been successfully submitted by Tero Kivinen and posted to the= IETF repository. Filename:=09 draft-kivinen-ipsecme-secure-password-framework Revision:=09 00 Title:=09=09 Secure Password Framework for IKEv2 Creation date:=09 2011-05-12 WG ID:=09=09 Individual Submission Number of pages: 14 Abstract: The IPsecME working group was chartered to provide IKEv2 a symmetric= secure password authentication protocol that supports using of low- entropy shared secrets, but which is protected against off-line dictionary attacks without requiring the use of certificates of EAP.= There are multiple of such methods and working group was supposed to= pick one. Unfortunately the working group failed to get pick one protocol and there are multiple candidates going forward as separate= documents. As each of those documents uses different method to negotiate the use of the method and also uses different payload formats it is very hard to try to make implementation where multiple= of those systems could co-exists. This document tries to create generic way for those methods to negotiate which one is used and provides one new payload which can b= e used to transmit method specific data. = =20 The IETF Secretariat --QNfLBaKe+4-- From xiangyang.zhang@huawei.com Wed May 18 16:30: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 300CDE06DF for ; Wed, 18 May 2011 16:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WdvpBQAfC8k5 for ; Wed, 18 May 2011 16:30:53 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3C916E0651 for ; Wed, 18 May 2011 16:30:53 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLE00C4CZZEJE@usaga02-in.huawei.com> for ipsec@ietf.org; Wed, 18 May 2011 16:30:51 -0700 (PDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLE00HZOZZE4H@usaga02-in.huawei.com> for ipsec@ietf.org; Wed, 18 May 2011 16:30:50 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 16:30:51 -0700 Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 18 May 2011 16:30:46 -0700 Date: Wed, 18 May 2011 23:30:45 +0000 From: Xiangyang zhang In-reply-to: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> X-Originating-IP: [10.193.34.108] To: Tina Tsou , "ipsec@ietf.org" Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 18 May 2011 23:30:54 -0000 This proposal addresses two major issues in IPsec anti-replay service: 1. Some high end security router can configure thousands of bits for anti-replay window. For example, Juniper can configure up to 4096 bits. The bit-shifting for this window is a tremendous burden, resulting in the performance drop. 2. High-end network processor could have multiple crypto cores to access the window. In order to check and update the window, the exclusive lock must be obtained. -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Tuesday, May 10, 2011 12:46 PM To: 'ipsec@ietf.org' Cc: 'Xiangyang zhang' Subject: Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Hi, Victor and I just submitted https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/ IPsec anti-replay algorithm without bit-shifting This document presents a new method to do anti-replay check and update, which becomes one alternative to the anti-replay algorithm in RFC 4302 and RFC4303. The new method will deem the bit-shifting unnecessary. It will reduce the number of times to slide the window. In addition, it makes bit-check and bit-update easier as it does not depend on the low index of the sliding window. It is especially beneficial when the window size is much bigger than 64 bits, for example, 1024 bits. IPsec employs one anti-replay sliding window protocol to secure against an adversary that can insert the messages inside the network tunnel. This method still inherits the sliding window protocol, but use one or more redundant bytes to ease the update of sliding window. The bit-shifting is deemed unnecessary with updating the high and low index of the window, which is especially efficient in case of the big window size. Thus the method reduces the number of times to update the window. In addition, the bit location is fixed for one sequence number, thus makes the bit check easier and faster. Comments are more than welcome. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From kivinen@iki.fi Thu May 19 06:26:41 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 50DFFE07B3 for ; Thu, 19 May 2011 06:26:41 -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 MYuhUKeL6EoN for ; Thu, 19 May 2011 06:26:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC2E066A for ; Thu, 19 May 2011 06:26:39 -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 p4JDPnsm028091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2011 16:25:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4JDPk4j020692; Thu, 19 May 2011 16:25:46 +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: <19925.6746.823649.293241@fireball.kivinen.iki.fi> Date: Thu, 19 May 2011 16:25:46 +0300 From: Tero Kivinen To: Xiangyang zhang In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" , Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 19 May 2011 13:26:41 -0000 Xiangyang zhang writes: > This proposal addresses two major issues in IPsec anti-replay service: > 1. Some high end security router can configure thousands of bits for > anti-replay window. For example, Juniper can configure up to 4096 > bits. The bit-shifting for this window is a tremendous burden, > resulting in the performance drop. > 2. High-end network processor could have multiple crypto cores to > access the window. In order to check and update the window, the > exclusive lock must be obtained. If I have understood correctly the algorith listed in the rfc4302 etc is only for illustrative pseudo-code, the actual implementations may be different (and at least our implementation do not use bit-shifting at all as it would be way too inefficient). The anti-replay checking in the IPsec is local matter to the implementation and does not have any interoperability requirements in addition that the sequence number field is always present. This draft provides nice alternative algorithm to the one provided in the RFC, but as the algorithm listed in the current rfc is not mandated anyways and there is no externally visible differences in the algorithms I do not see reason to document this as RFC. This would be better as techinal paper about providing faster algorithm for the anti-replay checking. -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu May 19 06:44: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 0E582E06D9 for ; Thu, 19 May 2011 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 1JB0QWme+neV for ; Thu, 19 May 2011 06:44: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 54F52E06AC for ; Thu, 19 May 2011 06:44:39 -0700 (PDT) Received: by wyb29 with SMTP id 29so2275594wyb.31 for ; Thu, 19 May 2011 06:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ccc165jyMiS7bvIAlfuoH2wA7dklUxeV1VfY/jNq8sU=; b=ffLfRJVcT5Cq0q36vWBpFwSYzd5m/rExm98jNYtMiiFW5dB5/GJL1EkhTeaCrKF7k+ O4EGZB4W2H4hUhoKTYRjVHrexrFXOC4rj7XxjTCpcvpCn5WNXJFvDWWYJiJN5ZTtcG4+ Zb1nSK5X/6hnN2YxyKqX3vbT1wFOlBgIMtIHA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=fde65JdIkKF2nrEM6tjeBW2VvhrB+jX0noAz7/ANsXQ1/+hXV9hBOpSrykQQd+AWl4 ca/84G7cIspbemyXJJtU2XNNlpwhcSAZe1qpb/2c/WqHCejXShAJu70YFQYKHdbnE1DB cqB1uG102hyYL8sb1mdjDv0kn3vXbHtvXS4Wg= Received: by 10.227.5.193 with SMTP id 1mr3283456wbw.33.1305812677942; Thu, 19 May 2011 06:44:37 -0700 (PDT) Received: from [10.0.0.5] (93-173-12-70.bb.netvision.net.il [93.173.12.70]) by mx.google.com with ESMTPS id k12sm1361445wby.33.2011.05.19.06.44.36 (version=SSLv3 cipher=OTHER); Thu, 19 May 2011 06:44:37 -0700 (PDT) Message-ID: <4DD51EC2.2030709@gmail.com> Date: Thu, 19 May 2011 16:44:34 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tero Kivinen References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> <19925.6746.823649.293241@fireball.kivinen.iki.fi> In-Reply-To: <19925.6746.823649.293241@fireball.kivinen.iki.fi> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xiangyang zhang , "ipsec@ietf.org" , Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 19 May 2011 13:44:40 -0000 I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC.

Thanks,
    Yaron

On 05/19/2011 04:25 PM, Tero Kivinen wrote: 
Xiangyang zhang writes:

This proposal addresses two major issues in IPsec anti-replay service:
1. Some high end security router can configure thousands of bits for
anti-replay window. For example, Juniper can configure up to 4096
bits.  The bit-shifting for this window is a tremendous burden,
resulting in the performance drop. 
2. High-end network processor could have multiple crypto cores to
access the window.  In order to check and update the window, the
exclusive lock must be obtained.   

If I have understood correctly the algorith listed in the rfc4302 etc
is only for illustrative pseudo-code, the actual implementations may
be different (and at least our implementation do not use bit-shifting
at all as it would be way too inefficient).

The anti-replay checking in the IPsec is local matter to the
implementation and does not have any interoperability requirements in
addition that the sequence number field is always present.

This draft provides nice alternative algorithm to the one provided in
the RFC, but as the algorithm listed in the current rfc is not
mandated anyways and there is no externally visible differences in the
algorithms I do not see reason to document this as RFC.

This would be better as techinal paper about providing faster
algorithm for the anti-replay checking.
From turners@ieca.com Thu May 19 07:47: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 ACD15E06DD for ; Thu, 19 May 2011 07:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.268 X-Spam-Level: X-Spam-Status: No, score=-101.268 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_40=-0.185, 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 SrgOWM+Dr4-R for ; Thu, 19 May 2011 07:47:57 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with SMTP id A6564E06A1 for ; Thu, 19 May 2011 07:47:57 -0700 (PDT) Received: from [98.139.212.151] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 19 May 2011 14:47:54 -0000 Received: from [98.139.212.221] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 19 May 2011 14:47:54 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 19 May 2011 14:47:54 -0000 X-Yahoo-Newman-Id: 537054.44106.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 32141 invoked from network); 19 May 2011 14:47:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305816473; bh=dn2FO4NuLXMiKlb7gES37BbFroHt1tdgIn6so2okRnY=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bPQTylF9UaUbkmi6PJocZAl49c1eL6hSTflHc/SM4SVSabr7dCDwKkFylo4q+72co+dZAS0Hw9xCxgoIv7In6S0F2SRZEFCNh5z9NNZsniqJIrNGRu1jqNUeqQZ5DRvpyStHRpFMm6S6YRmhKIiv10tLa1IZ9fUSq/PRlDIOR4Q= Received: from thunderfish.local (turners@96.231.126.154 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 19 May 2011 07:47:53 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 7KkEhqQVM1mQ0Wq8Ad6plzTTimKKneb61piLqHeSQTky96g V14YHVf3aZQU9gbePpV1FH7fWIpt9xgPw2R4mXlOP_hYG3_b9VcTIHT3yrTQ VoYr.3QHnYRCsNAwLtY05GNeJGV_wbiM8U6jbAJMv_ovW8NxqJZ7hIoIdDKz kutYwiD066rqYUsTyL8Sqj.ziLTN26cOpx4oq5B1_bsajNw_4Bn_sWb8hSR9 leLLtM0yDpEKrwY7y.iBnF73npdZ4ejXEFkY51q5ricd_D4WTaZPO.CCsEru b..Shtt2Py9dCmGtO0KdF0ySu7BPA8o.21tvgbJb_Af_NwF_oEe9UoUnX_2a jZQJR437SaylDfE_31mMxXvk7WyDveeoMBIUYLLe1AvjIFNumGTxfmah18OI Sgnjira8nQ8RwLCWeZ5SYctvHBOOSqfOvRFyGveSviF6vtEjllgN4gYoCFpi dIHyW X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DD52D97.2010209@ieca.com> Date: Thu, 19 May 2011 10:47:51 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tina Tsou References: <000301cc0f4a$eb671660$c2354320$@com> In-Reply-To: <000301cc0f4a$eb671660$c2354320$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, 'Xiangyang zhang' Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 19 May 2011 14:47:58 -0000 In section 3 please add the appropriate license for code components (http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.pdf). In a nutshell encapsulate the code with: code goes here and right after include the following: /* Copyright (c) 2011 IETF Trust and the persons identified as authors of this code. All rights reserved. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ In section 6 you need to say whether the references are normative or not. I assume normative. spt On 5/10/11 3:45 PM, Tina Tsou wrote: > Hi, > Victor and I just submitted > https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/ > > IPsec anti-replay algorithm without bit-shifting > > This document presents a new method to do anti-replay check and > update, which becomes one alternative to the anti-replay > algorithm in RFC 4302 and RFC4303. The new method will deem the > bit-shifting unnecessary. It will reduce the number of times > to slide the window. In addition, it makes bit-check and > bit-update easier as it does not depend on the low index of the > sliding window. It is especially beneficial when the window size > is much bigger than 64 bits, for example, 1024 bits. > > IPsec employs one anti-replay sliding window protocol to secure > against an adversary that can insert the messages inside the > network tunnel. This method still inherits the sliding window > protocol, but use one or more redundant bytes to ease the update > of sliding window. The bit-shifting is deemed unnecessary with > updating the high and low index of the window, which is especially > efficient in case of the big window size. Thus the method reduces > the number of times to update the window. > > In addition, the bit location is fixed for one sequence number, > thus makes the bit check easier and faster. > > Comments are more than welcome. > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From smoonen@us.ibm.com Thu May 19 08:01: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 0551FE071A for ; Thu, 19 May 2011 08:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RZLlm54EUNXl for ; Thu, 19 May 2011 08:01:46 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id F053FE0669 for ; Thu, 19 May 2011 08:01:45 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4JEjAFu025573 for ; Thu, 19 May 2011 08:45:10 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4JF0jWO119784 for ; Thu, 19 May 2011 09:00:51 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4J90MJQ012674 for ; Thu, 19 May 2011 03:00:22 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4J90I9L012215 for ; Thu, 19 May 2011 03:00:18 -0600 X-KeepSent: 01B03854:CD669DAC-85257895:004F44EE; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Thu, 19 May 2011 10:52:04 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 05/19/2011 09:00:18 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF206DFDCC27E8f9e8a93df938690918c0ABBF206DFDCC27E" Content-Disposition: inline Subject: [IPsec] RFC 5996 and INITIAL_CONTACT 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, 19 May 2011 15:01:47 -0000 --0__=0ABBF206DFDCC27E8f9e8a93df938690918c0ABBF206DFDCC27E Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable RFC 5996 says this about INITIAL_CONTACT: The INITIAL_CONTACT notification asserts that this IKE SA is the onl= y IKE SA currently active between the authenticated identities. . . . The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards . . . IKEv1 was unclear about the scope of this notification, and I'm glad th= at IKEv2 made clear that it applies to identities and not IP addresses. Bu= t there is an unfortunate chicken-and-egg problem here, and I'm kicking myself for not noticing this back in 2009. The paragraph makes it clear= that the decision to send INITIAL_CONTACT is based on the authenticated= identities, and that the notify is sent in IKE_AUTH. However, the initi= ator does not know the authenticated identities until it receives the IKE_AU= TH response. Even if the initiator sends an optional IDr payload, the responder is not obligated to choose the same identity. So it seems to me that the initiator can only confidently send INITIAL_CONTACT based on IDi, and maybe based on IDr if it makes a comprehensive search of its PAD. I.e., the initiator can send INITIAL_CONTACT only if (1) its IDi is not in use by any other active IKE_SA, or (2) the combination of its IDi and all permitted IDr's that = may be used for the remote address, based on an exhaustive search of the PA= D, is not in use by any other active IKE_SA. This suggests to me that in general the usefulness of INITIAL_CONTACT i= s limited. I wonder about a couple things. First, is there any interest i= n an extension that allows for INITIAL_CONTACT after the IKE_AUTH completes?= (And is that something that would be worth piggybacking onto the QCD draft?) Second, is there room to stipulate, perhaps in an erratum or in= a clarifications draft, that when the initiator sends an optional IDr, th= e INITIAL_CONTACT notification applies only if the responder ends up choo= sing that identity as its IDr? I'm interested in any other thoughts or experience folks on the list ha= ve to offer, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen= --0__=0ABBF206DFDCC27E8f9e8a93df938690918c0ABBF206DFDCC27E Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

RFC 5996 says this about INITIAL_CONTACT:

The INITIAL_CONTACT notification asserts that this IKE SA is the onl= y
IKE SA currently active between the authenticated identities. . . .<= br> The INITIAL_CONTACT notification, if sent, MUST
be in the first IKE_AUTH request or response, not as a separate
exchange afterwards . . .

IKEv1 was unclear about the scope of this notification, and I'm glad th= at IKEv2 made clear that it applies to identities and not IP addresses.= But there is an unfortunate chicken-and-egg problem here, and I'm kick= ing myself for not noticing this back in 2009. The paragraph makes it c= lear that the decision to send INITIAL_CONTACT is based on the authenti= cated identities, and that the notify is sent in IKE_AUTH. However, the= initiator does not know the authenticated identities until it receives= the IKE_AUTH response. Even if the initiator sends an optional IDr pay= load, the responder is not obligated to choose the same identity.

So it seems to me that the initiator can only confidently send INITIAL_= CONTACT based on IDi, and maybe based on IDr if it makes a comprehensiv= e search of its PAD. I.e., the initiator can send INITIAL_CONTACT only = if (1) its IDi is not in use by any other active IKE_SA, or (2) the com= bination of its IDi and all permitted IDr's that may be used for the re= mote address, based on an exhaustive search of the PAD, is not in use b= y any other active IKE_SA.

This suggests to me that in general the usefulness of INITIAL_CONTACT i= s limited. I wonder about a couple things. First, is there any interest= in an extension that allows for INITIAL_CONTACT after the IKE_AUTH com= pletes? (And is that something that would be worth piggybacking onto th= e QCD draft?) Second, is there room to stipulate, perhaps in an erratum= or in a clarifications draft, that when the initiator sends an optiona= l IDr, the INITIAL_CONTACT notification applies only if the responder e= nds up choosing that identity as its IDr?

I'm interested in any other thoughts or experience folks on the list ha= ve to offer,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen= --0__=0ABBF206DFDCC27E8f9e8a93df938690918c0ABBF206DFDCC27E-- From xiangyang.zhang@huawei.com Thu May 19 15:56: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 A9252E06E0 for ; Thu, 19 May 2011 15:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FMDKRS425WXL for ; Thu, 19 May 2011 15:56:17 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id DFD16E068B for ; Thu, 19 May 2011 15:56:17 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLG009ZFT1RF2@usaga02-in.huawei.com> for ipsec@ietf.org; Thu, 19 May 2011 15:56:15 -0700 (PDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLG00368T1R9W@usaga02-in.huawei.com> for ipsec@ietf.org; Thu, 19 May 2011 15:56:15 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 19 May 2011 15:56:16 -0700 Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 19 May 2011 15:56:12 -0700 Date: Thu, 19 May 2011 22:56:12 +0000 From: Xiangyang zhang In-reply-to: <4DD52D97.2010209@ieca.com> X-Originating-IP: [10.193.34.108] To: Sean Turner , Tina Tsou Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A08F4@dfweml502-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Thread-index: AcwPStKwaGbJjd6kR22PFAz3m8+OrwHI5PiAAAHqaMA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <000301cc0f4a$eb671660$c2354320$@com> <4DD52D97.2010209@ieca.com> Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 19 May 2011 22:56:18 -0000 Sean, Thanks for the comments 1. The code will be encapsulated including the copyright. Is the pseudo-code better than actual C code? 2. The reference is normative. Regards Xiangyang -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Thursday, May 19, 2011 7:48 AM To: Tina Tsou Cc: ipsec@ietf.org; Xiangyang zhang Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting In section 3 please add the appropriate license for code components (http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.pdf). In a nutshell encapsulate the code with: code goes here and right after include the following: /* Copyright (c) 2011 IETF Trust and the persons identified as authors of this code. All rights reserved. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ In section 6 you need to say whether the references are normative or not. I assume normative. spt On 5/10/11 3:45 PM, Tina Tsou wrote: > Hi, > Victor and I just submitted > https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/ > > IPsec anti-replay algorithm without bit-shifting > > This document presents a new method to do anti-replay check and > update, which becomes one alternative to the anti-replay > algorithm in RFC 4302 and RFC4303. The new method will deem the > bit-shifting unnecessary. It will reduce the number of times > to slide the window. In addition, it makes bit-check and > bit-update easier as it does not depend on the low index of the > sliding window. It is especially beneficial when the window size > is much bigger than 64 bits, for example, 1024 bits. > > IPsec employs one anti-replay sliding window protocol to secure > against an adversary that can insert the messages inside the > network tunnel. This method still inherits the sliding window > protocol, but use one or more redundant bytes to ease the update > of sliding window. The bit-shifting is deemed unnecessary with > updating the high and low index of the window, which is especially > efficient in case of the big window size. Thus the method reduces > the number of times to update the window. > > In addition, the bit location is fixed for one sequence number, > thus makes the bit check easier and faster. > > Comments are more than welcome. > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From turners@ieca.com Fri May 20 05:28: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 3F8CCE0799 for ; Fri, 20 May 2011 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 xnUIxKQxZLEx for ; Fri, 20 May 2011 05:28:09 -0700 (PDT) Received: from nm11-vm0.bullet.mail.bf1.yahoo.com (nm11-vm0.bullet.mail.bf1.yahoo.com [98.139.213.136]) by ietfa.amsl.com (Postfix) with SMTP id CE2B4E0788 for ; Fri, 20 May 2011 05:28:04 -0700 (PDT) Received: from [98.139.212.153] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 20 May 2011 12:28:04 -0000 Received: from [98.139.221.62] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 20 May 2011 12:28:04 -0000 Received: from [127.0.0.1] by smtp103.biz.mail.bf1.yahoo.com with NNFMP; 20 May 2011 12:28:04 -0000 X-Yahoo-Newman-Id: 301077.75736.bm@smtp103.biz.mail.bf1.yahoo.com Received: from thunderfish.local (turners@96.231.114.36 with plain) by smtp103.biz.mail.bf1.yahoo.com with SMTP; 20 May 2011 05:28:03 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: YdR25a0VM1l0.fVKAlK40NoF7B1r2Vgr5WMhd6G5OF1dwyL uoCGAf2n.wc0JYiqMu2iyNjFIQRJfyfsE48OV1rexAWnFtaPhnlS7Z40_jtW XmwJyhihaGW8k3O8kuGjnwb7TzS6R94PaMnNQ16g0XYwSzPro9Ivaibxdn3u q7Nxnopr1B9PIVXuaD.weo7XSfN0OqvTCNGcZqleeKWD3lTXN38XPtat_ACq yL1z7BTmiD6dqBSFWbZTPoE9U9o8rB8ZthZgtagjdt4SAFB8PK_3oikvMnUg cAG9a6MmrwTTF6Op7W8QD8CWR6YlYBFwOl7XfseSoRI2I7whqYP6IZ8XbGSG xk.u5F2MxMJgnjeuFjBiDvk9sYpRAnJXzoO1IaoSUAEhEZcrebhYjDqZVo2B 0kASX2ieC680.fm7Z8PrQUloQ0.wcnrdR9b_e9SG1UUrtARfqoegkx4VNXQ- - X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DD65E52.5020607@ieca.com> Date: Fri, 20 May 2011 08:28:02 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Xiangyang zhang References: <000301cc0f4a$eb671660$c2354320$@com> <4DD52D97.2010209@ieca.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A08F4@dfweml502-mbx.china.huawei.com> In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A030C3A08F4@dfweml502-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 20 May 2011 12:28:10 -0000 On 5/19/11 6:56 PM, Xiangyang zhang wrote: > Sean, > > Thanks for the comments > > 1. The code will be encapsulated including the copyright. Is the pseudo-code better than actual C code? I think that's up to you. I don't have strong preference either way. > 2. The reference is normative. Figured ;) spt > > Regards > > Xiangyang > > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Thursday, May 19, 2011 7:48 AM > To: Tina Tsou > Cc: ipsec@ietf.org; Xiangyang zhang > Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting > > In section 3 please add the appropriate license for code components > (http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.pdf). > In a nutshell encapsulate the code with: > > > code goes here > > > and right after include the following: > > /* > Copyright (c) 2011 IETF Trust and the persons identified as authors > of this code. All rights reserved. > > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > > In section 6 you need to say whether the references are normative or > not. I assume normative. > > spt > > On 5/10/11 3:45 PM, Tina Tsou wrote: >> Hi, >> Victor and I just submitted >> https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/ >> >> IPsec anti-replay algorithm without bit-shifting >> >> This document presents a new method to do anti-replay check and >> update, which becomes one alternative to the anti-replay >> algorithm in RFC 4302 and RFC4303. The new method will deem the >> bit-shifting unnecessary. It will reduce the number of times >> to slide the window. In addition, it makes bit-check and >> bit-update easier as it does not depend on the low index of the >> sliding window. It is especially beneficial when the window size >> is much bigger than 64 bits, for example, 1024 bits. >> >> IPsec employs one anti-replay sliding window protocol to secure >> against an adversary that can insert the messages inside the >> network tunnel. This method still inherits the sliding window >> protocol, but use one or more redundant bytes to ease the update >> of sliding window. The bit-shifting is deemed unnecessary with >> updating the high and low index of the window, which is especially >> efficient in case of the big window size. Thus the method reduces >> the number of times to update the window. >> >> In addition, the bit location is fixed for one sequence number, >> thus makes the bit check easier and faster. >> >> Comments are more than welcome. >> >> >> We keep our promises with one another - no matter what! >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > From xiangyang.zhang@huawei.com Fri May 20 12:18: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 1AEF1E07B4 for ; Fri, 20 May 2011 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eXISfNDWk-BR for ; Fri, 20 May 2011 12:18:05 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 734C7E06A6 for ; Fri, 20 May 2011 12:18:05 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI008NADM4CW@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 14:18:04 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00269DM32D@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 14:18:03 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 20 May 2011 12:18:05 -0700 Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 20 May 2011 12:17:59 -0700 Date: Fri, 20 May 2011 19:17:58 +0000 From: Xiangyang zhang In-reply-to: <19925.6746.823649.293241@fireball.kivinen.iki.fi> X-Originating-IP: [10.193.34.108] To: Tero Kivinen Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A09E0@dfweml502-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkZSUmnYAgAF8T7A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> <19925.6746.823649.293241@fireball.kivinen.iki.fi> Cc: "ipsec@ietf.org" , Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 20 May 2011 19:18:06 -0000 -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Thursday, May 19, 2011 6:26 AM To: Xiangyang zhang Cc: Tina Tsou; ipsec@ietf.org Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Xiangyang zhang writes: > This proposal addresses two major issues in IPsec anti-replay service: > 1. Some high end security router can configure thousands of bits for > anti-replay window. For example, Juniper can configure up to 4096 > bits. The bit-shifting for this window is a tremendous burden, > resulting in the performance drop. > 2. High-end network processor could have multiple crypto cores to > access the window. In order to check and update the window, the > exclusive lock must be obtained. If I have understood correctly the algorith listed in the rfc4302 etc is only for illustrative pseudo-code, the actual implementations may be different (and at least our implementation do not use bit-shifting at all as it would be way too inefficient). [xiangyang] Three RFCs describe almost the same algorithm. For illustrative pseudo-code, it shifts bits when the window is updated (Page 41 in RFC4303). Definitely it is efficient if bit-shifting is bypassed. In addition, the check and set of the specific bit is also simplified here. In old method, the location of the bit depends on both the largest sequence number received and the current sequence number. Instead, it only depends on the sequence number currently received. The anti-replay checking in the IPsec is local matter to the implementation and does not have any interoperability requirements in addition that the sequence number field is always present. This draft provides nice alternative algorithm to the one provided in the RFC, but as the algorithm listed in the current rfc is not mandated anyways and there is no externally visible differences in the algorithms I do not see reason to document this as RFC. This would be better as techinal paper about providing faster algorithm for the anti-replay checking. -- kivinen@iki.fi From xiangyang.zhang@huawei.com Fri May 20 13:26: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 CF082E0742 for ; Fri, 20 May 2011 13:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 euM7fCCJiy3N for ; Fri, 20 May 2011 13:26:43 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 22490E0710 for ; Fri, 20 May 2011 13:26:43 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00I26GSHSR@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 15:26:42 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00203GSG2D@usaga04-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 15:26:41 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 20 May 2011 13:26:33 -0700 Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 20 May 2011 13:26:38 -0700 Date: Fri, 20 May 2011 20:26:37 +0000 From: Xiangyang zhang In-reply-to: <4DD51EC2.2030709@gmail.com> X-Originating-IP: [10.193.34.108] To: Yaron Sheffer , Tero Kivinen Message-id: <00E6CDB229A4CF4487D6E0326EDE5A030C3A09FA@dfweml502-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8mgek0TasQyJtYAwog/o1Q)" Content-language: en-US Accept-Language: en-US Thread-topic: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkZSUmnYAgAAFQQCAAXqVAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> <19925.6746.823649.293241@fireball.kivinen.iki.fi> <4DD51EC2.2030709@gmail.com> Cc: "ipsec@ietf.org" , Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 20 May 2011 20:26:43 -0000 --Boundary_(ID_8mgek0TasQyJtYAwog/o1Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I agree. Actually our intention is to provide informational RFC. We do not change the sliding window protocol for integrity service. It just provide one alternative, or better alternative in most cases, to the one specified in IPsec RFCs. Thanks, Xiangyang From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Thursday, May 19, 2011 6:45 AM To: Tero Kivinen Cc: Xiangyang zhang; ipsec@ietf.org; Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC. Thanks, Yaron On 05/19/2011 04:25 PM, Tero Kivinen wrote: Xiangyang zhang writes: This proposal addresses two major issues in IPsec anti-replay service: 1. Some high end security router can configure thousands of bits for anti-replay window. For example, Juniper can configure up to 4096 bits. The bit-shifting for this window is a tremendous burden, resulting in the performance drop. 2. High-end network processor could have multiple crypto cores to access the window. In order to check and update the window, the exclusive lock must be obtained. If I have understood correctly the algorith listed in the rfc4302 etc is only for illustrative pseudo-code, the actual implementations may be different (and at least our implementation do not use bit-shifting at all as it would be way too inefficient). The anti-replay checking in the IPsec is local matter to the implementation and does not have any interoperability requirements in addition that the sequence number field is always present. This draft provides nice alternative algorithm to the one provided in the RFC, but as the algorithm listed in the current rfc is not mandated anyways and there is no externally visible differences in the algorithms I do not see reason to document this as RFC. This would be better as techinal paper about providing faster algorithm for the anti-replay checking. --Boundary_(ID_8mgek0TasQyJtYAwog/o1Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I agree.   Actually our intention is to provide informational RFC.  We do not change the sliding

window protocol for integrity service.  It just provide one alternative, or better alternative

in most cases, to the one specified in IPsec RFCs.

 

Thanks,

 

Xiangyang

 

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; ipsec@ietf.org; Tina Tsou
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

 

I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC.

Thanks,
    Yaron

On 05/19/2011 04:25 PM, Tero Kivinen wrote: 

Xiangyang zhang writes:
This proposal addresses two major issues in IPsec anti-replay service:
1. Some high end security router can configure thousands of bits for
anti-replay window. For example, Juniper can configure up to 4096
bits.  The bit-shifting for this window is a tremendous burden,
resulting in the performance drop. 
2. High-end network processor could have multiple crypto cores to
access the window.  In order to check and update the window, the
exclusive lock must be obtained.   
 
If I have understood correctly the algorith listed in the rfc4302 etc
is only for illustrative pseudo-code, the actual implementations may
be different (and at least our implementation do not use bit-shifting
at all as it would be way too inefficient).
 
The anti-replay checking in the IPsec is local matter to the
implementation and does not have any interoperability requirements in
addition that the sequence number field is always present.
 
This draft provides nice alternative algorithm to the one provided in
the RFC, but as the algorithm listed in the current rfc is not
mandated anyways and there is no externally visible differences in the
algorithms I do not see reason to document this as RFC.
 
This would be better as techinal paper about providing faster
algorithm for the anti-replay checking.
--Boundary_(ID_8mgek0TasQyJtYAwog/o1Q)-- From tena@huawei.com Fri May 20 15:55:36 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 96BB9E06CA for ; Fri, 20 May 2011 15:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd9zcVIMenhQ for ; Fri, 20 May 2011 15:55:34 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 53CE1E06BE for ; Fri, 20 May 2011 15:55:34 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00AI6NOLB5@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 15:55:33 -0700 (PDT) Received: from TingZousc1 ([10.193.34.188]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLI005RONOJ85@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 20 May 2011 15:55:32 -0700 (PDT) Date: Fri, 20 May 2011 15:55:35 -0700 From: Tina Tsou In-reply-to: <00E6CDB229A4CF4487D6E0326EDE5A030C3A09FA@dfweml502-mbx.china.huawei.com> To: 'Xiangyang zhang' , 'Yaron Sheffer' , 'Tero Kivinen' Message-id: <014001cc1741$080dd8a0$182989e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EeRT7EbXzsks2ksUz97l/A)" Content-language: en-us Thread-index: AQHMFbOcHfxoosMvWkSdG/frQ+fnkZSUmnYAgAAFQQCAAXqVAIAAO+5g References: <20110506091501.19592.66261.idtracker@ietfa.amsl.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A073B@dfweml502-mbx.china.huawei.com> <19925.6746.823649.293241@fireball.kivinen.iki.fi> <4DD51EC2.2030709@gmail.com> <00E6CDB229A4CF4487D6E0326EDE5A030C3A09FA@dfweml502-mbx.china.huawei.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting 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, 20 May 2011 22:55:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EeRT7EbXzsks2ksUz97l/A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yaron, Tero, and Sean, If Sean could be the sponsor AD, I'm happy to submit it as an independent submission. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Xiangyang zhang [mailto:xiangyang.zhang@huawei.com] Sent: Friday, May 20, 2011 1:27 PM To: Yaron Sheffer; Tero Kivinen Cc: ipsec@ietf.org; Tina Tsou Subject: RE: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting I agree. Actually our intention is to provide informational RFC. We do not change the sliding window protocol for integrity service. It just provide one alternative, or better alternative in most cases, to the one specified in IPsec RFCs. Thanks, Xiangyang From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Thursday, May 19, 2011 6:45 AM To: Tero Kivinen Cc: Xiangyang zhang; ipsec@ietf.org; Tina Tsou Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC. Thanks, Yaron On 05/19/2011 04:25 PM, Tero Kivinen wrote: Xiangyang zhang writes: This proposal addresses two major issues in IPsec anti-replay service: 1. Some high end security router can configure thousands of bits for anti-replay window. For example, Juniper can configure up to 4096 bits. The bit-shifting for this window is a tremendous burden, resulting in the performance drop. 2. High-end network processor could have multiple crypto cores to access the window. In order to check and update the window, the exclusive lock must be obtained. If I have understood correctly the algorith listed in the rfc4302 etc is only for illustrative pseudo-code, the actual implementations may be different (and at least our implementation do not use bit-shifting at all as it would be way too inefficient). The anti-replay checking in the IPsec is local matter to the implementation and does not have any interoperability requirements in addition that the sequence number field is always present. This draft provides nice alternative algorithm to the one provided in the RFC, but as the algorithm listed in the current rfc is not mandated anyways and there is no externally visible differences in the algorithms I do not see reason to document this as RFC. This would be better as techinal paper about providing faster algorithm for the anti-replay checking. --Boundary_(ID_EeRT7EbXzsks2ksUz97l/A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Yaron, Tero, and Sean,

If Sean could be the sponsor AD, I’m happy to submit it as an independent submission.

 

We keep our promises with one another – no matter what!

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: Xiangyang zhang [mailto:xiangyang.zhang@huawei.com]
Sent: Friday, May 20, 2011 1:27 PM
To: Yaron Sheffer; Tero Kivinen
Cc: ipsec@ietf.org; Tina Tsou
Subject: RE: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

 

I agree.   Actually our intention is to provide informatio nal RFC. he sliding

window protocol for integrity service.  It just provide one alternative, or better alternative

in most cases, to the one specified in IPsec RFCs.

 

Thanks,

 

Xiangyang

 

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; ipsec@ietf.org; Tina Tsou
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

 

I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC.

Thanks,
    Yaron

On 05/19/2011 04:25 PM, Tero Kivinen wrote: 

Xiangyang zhang writes:
This proposal addresses two major issues in IPsec anti-replay service:
1. Some high end security router can configure thousands of bits for
anti-replay window. For example, Juniper can configure up to 4096
bits.  The bit-shifting for this window is a tremendous burden,
resulting in the performance drop. 
2. High-end network processor could have multiple crypto cores to
access the window.  In order to check and update the window, the
exclusive lock must be obtained.   
 
If I have understood correctly the algorith listed in the rfc4302 etc
is only for illustrative pseudo-code, the actual implementations may
be different (and at least our implementation do not use bit-shifting
at 
 all as i
cient).
 
The anti-replay checking in the IPsec is local matter to the
implementation and does not have any interoperability requirements in
addition that the sequence number field is always present.
 
This draft provides nice alternative algorithm to the one provided in
the RFC, but as the algorithm listed in the current rfc is not
mandated anyways and there is no externally visible differences in the
algorithms I do not see reason to document this as RFC.
 
This would be better as techinal paper about providing faster
algorithm for the anti-replay checking.
--Boundary_(ID_EeRT7EbXzsks2ksUz97l/A)-- From yaronf.ietf@gmail.com Sun May 22 11:46: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 D31E2E06B5; Sun, 22 May 2011 11:46:07 -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 Xdao4rCIrjD9; Sun, 22 May 2011 11:46:07 -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 38EC8E0696; Sun, 22 May 2011 11:46:06 -0700 (PDT) Received: by wwk4 with SMTP id 4so886981wwk.1 for ; Sun, 22 May 2011 11:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t/5ue5V1yzE8DUrO+EUJQRSrP5jWsWRzWmTQ02ZBFlg=; b=dPlykchcZjNhafc4TFqu/xmf877D5qprxs5KrhJUm7nkvU9H1G/Ser9vQy5j+iRLOE Q75wCYNRmZ6VoMSx4CmQmQWVkDeHOMvmFqaNII9VPrtZRqxSY4J0q3yiQYSb9RLdSjdz ci43xQ5JONa4Fg5blnDg1ve9BrJ3ZewHGVUw0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=wQSZJk2Qbov2xbtQPBmUozWePawf1siZMIs3H5VnCh/j4JlyAzNaTDrfNE1PeYBBdQ TtX6kyMuZ2bm++SMXKSSvbsBOqFwx4f5JDBocRvhkI818zWnIsnjt4ZZnlKQ/2C8FaEl 68NOJTyvLn+oYFKALRBwWM7VBgOAHBIqtST9A= Received: by 10.227.197.201 with SMTP id el9mr1492325wbb.22.1306089505722; Sun, 22 May 2011 11:38:25 -0700 (PDT) Received: from [10.0.0.4] ([109.66.41.131]) by mx.google.com with ESMTPS id w25sm3602096wbd.5.2011.05.22.11.38.22 (version=SSLv3 cipher=OTHER); Sun, 22 May 2011 11:38:24 -0700 (PDT) Message-ID: <4DD9581C.3070900@gmail.com> Date: Sun, 22 May 2011 21:38:20 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf@ietf.org References: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> In-Reply-To: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG , draft-ietf-dime-ikev2-psk-diameter@tools.ietf.og, dime@ietf.org Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard 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: Sun, 22 May 2011 18:46:08 -0000 Hi, Having read this document only now, I think there's a number of serious issues with it. This document was sent to the ipsec mailing list a while ago but unfortunately got no review. Summary: 1. I think the wrong architectural choice was made, in preferring PSK over EAP authentication. 2. There is not enough detail in the document to result in interoperable implementations. Detailed comments: • The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the shepherd review back in March. • The document notes that EAP is one of the authentication modes supported by IKEv2. EAP is designed for interaction with backend AAA servers, and is quite capable of performing shared-secret authentication, using a variety of EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet the document does not explain why EAP is not used, instead preferring the IKE PSK authentication method. • 4.1: how can the incoming SPI be used to identify the peer? • Packing additional semantics into SPI may conflict with elements of the IPsec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure-detection-08). • 4.1, 2nd paragraph: generation of the PSK is central to this solution, so it cannot be "outside the scope" of the document. There is no way to interoperate otherwise. • Moreover, if a single client is expected to sometimes use EAP and sometimes PSK, there must be a way to notify it which one to use. • How does key-lifetime relate to the lifetime of the IKE SA? • Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK is only used for authentication and does not encrypt anything. • The same paragraph is very vague about the security properties of PSK. RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets." Again, I believe the document should specify how the PSK is derived. • Why "if nonces are included" where the document says that they *must* be included (in the AVP occurrence table). Thanks, Yaron On 05/20/2011 04:50 PM, The IESG wrote: > The IESG has received a request from the Diameter Maintenance and > Extensions WG (dime) to consider the following document: > - 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server > to Diameter Server Interaction' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Internet Key Exchange protocol version 2 (IKEv2) is a component > of the IPsec architecture and is used to perform mutual > authentication as well as to establish and to maintain IPsec security > associations (SAs) between the respective parties. IKEv2 supports > several different authentication mechanisms, such as the Extensible > Authentication Protocol (EAP), certificates, and pre-shared secrets. > > With [RFC5778] the Diameter interworking for Mobile IPv6 between the > Home Agent, as a Diameter client, and the Diameter server has been > specified. However, that specification focused on the usage of EAP > and did not include support for pre-shared secret based > authentication available with IKEv2. This document specifies IKEv2 > server, as a Diameter client, to the Diameter server communication > for IKEv2 with pre-shared secret based authentication. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From kivinen@iki.fi Thu May 26 07:09: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 0419CE06F3 for ; Thu, 26 May 2011 07:09:53 -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 r2yn+yzP8dfc for ; Thu, 26 May 2011 07:09:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15F3E06F8 for ; Thu, 26 May 2011 07:09:49 -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 p4QE9gH0017175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2011 17:09:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4QE9f1a001057; Thu, 26 May 2011 17:09:41 +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: <19934.24357.318265.873660@fireball.kivinen.iki.fi> Date: Thu, 26 May 2011 17:09:41 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: ipsec@ietf.org Subject: [IPsec] RFC 5996 and INITIAL_CONTACT 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, 26 May 2011 14:09:53 -0000 Scott C Moonen writes: > IKEv1 was unclear about the scope of this notification, and I'm glad that > IKEv2 made clear that it applies to identities and not IP addresses. But > there is an unfortunate chicken-and-egg problem here, and I'm kicking > myself for not noticing this back in 2009. The paragraph makes it clear > that the decision to send INITIAL_CONTACT is based on the authenticated > identities, and that the notify is sent in IKE_AUTH. However, the initiator > does not know the authenticated identities until it receives the IKE_AUTH > response. Even if the initiator sends an optional IDr payload, the > responder is not obligated to choose the same identity. I do not think this is real issue. The initiator who is initiating the connection is initiating the IKEv2 connection only because it thinks it does not have existing usable IKEv2 SA / Child SA with the peer it wants to talk to. If it would have usable IKEv2 SA / Child SA with the peer it wants to talk to, it would be using that instead of creating a new one. So when initiator is sending this new connection it will know whether this is initial contact or whether it is creating multiple connections with the same peer with some other reasons (for example with different IDi). Also note that INITIAL_CONTACT is only fall back crash recovery system, in normal case the normal IKEv2 liveness checks will destroy old SAs after a while. > So it seems to me that the initiator can only confidently send > INITIAL_CONTACT based on IDi, and maybe based on IDr if it makes a > comprehensive search of its PAD. I.e., the initiator can send > INITIAL_CONTACT only if (1) its IDi is not in use by any other active > IKE_SA, or (2) the combination of its IDi and all permitted IDr's that may > be used for the remote address, based on an exhaustive search of the PAD, > is not in use by any other active IKE_SA. Yes. > This suggests to me that in general the usefulness of INITIAL_CONTACT is > limited. I wonder about a couple things. First, is there any interest in an > extension that allows for INITIAL_CONTACT after the IKE_AUTH completes? As this is backup crash recovery system, I think there is no point of making it more complicated than what it already is. The current rfc already says that you should send it "after a crash". I.e. it is not normally meant to be sent for every single new IKEv2 connection, altought I think most of the implementations do send it. > (And is that something that would be worth piggybacking onto the QCD > draft?) Second, is there room to stipulate, perhaps in an erratum or in a > clarifications draft, that when the initiator sends an optional IDr, the > INITIAL_CONTACT notification applies only if the responder ends up choosing > that identity as its IDr? I think interpreting the INITIAL_CONTACT in such a way that it only applies to the IDi, and IDr sent by the initiator, and if the responder selects different IDr, it should not delete the IKE SA between the original IDi and IDr it selected. Note, that the currect text says "recipient MAY use this information to delete any other IKE SAs it has to the same authenticated identity without waiting for a timeout." In most cases if the initiator's IDr is not acceptable most likely the created IKE SA will not be very useful at all. Also initiator IDr is not very commonly used, and was meant to be used in cases where same server hosts several security gateways and the IDr is used to select one of them. What happens if the proposed IDr is not acceptable, is not covered by the RFCs. I myself would classify that case as a corner case which might require special handling in some scenarios, but that special handling can be done by the implementation without affecting the interoperability, i.e. the security gateway implementation supporting multiple local identities, and getting connection in where the initiator's IDr is not acceptable, it should interpert INITIAL_CONTACT to only apply to the proposed original initiator's IDi/IDr pair, not the newly selected one. -- kivinen@iki.fi From mpeck@mitre.org Thu May 26 13:01: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 E08A3E0714 for ; Thu, 26 May 2011 13:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VCdciDz3y+2R for ; Thu, 26 May 2011 13:01:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3A732E0694 for ; Thu, 26 May 2011 13:01:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 998D721B211C; Thu, 26 May 2011 16:01:41 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 929AC21B0515; Thu, 26 May 2011 16:01:41 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 26 May 2011 16:01:41 -0400 From: "Peck, Michael A" To: Dan Harkins Date: Thu, 26 May 2011 16:01:39 -0400 Thread-Topic: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt Thread-Index: AcvJxAZMd7SawBQRQB+jeTPaXy4LwhSFqhtw Message-ID: <4FD125153A070D45BC87645D3B880288025A13CC02@IMCMBX3.MITRE.ORG> References: <5946_1297359752_4D542388_5946_124519_1_4D54237F.2070308@ieca.com> <4FD125153A070D45BC87645D3B8802880248A1F484@IMCMBX3.MITRE.ORG> In-Reply-To: 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: "ipsec@ietf.org" , "kwburgi@tycho.ncsc.mil" Subject: Re: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 20:01:44 -0000 Dan, Thanks for your comments. My responses are below. Mike Peck >-----Original Message----- >From: Dan Harkins [mailto:dharkins@lounge.org] >Sent: Friday, February 11, 2011 3:17 AM >To: Peck, Michael A >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.= txt > > > Hello, > > I have a couple of comments after a quick read. > > - instead of mentioning vague things like the "Diffie-Hellman common > value" and the "x value", I think it would improve the draft to note > that the shared result of a successful ECDH exchange will be a point > (x,y) on the elliptic curve with x- and y-coordinates that satisfy > the equation of the curve. > > Then I think it would be better to say that the the secret used > in computation of SKEYSEED is the x-coordinate, treated as an > unsigned integer, and represented as an octet string per section 6.2 > of RFC 6090. For consistency with RFC 5903, we have decided to keep the text of this doc= ument as it currently stands. > > - section 6 of this draft mentions additional requirements. This draft > may be necessary but it certainly is not sufficient for an IPsec > implementation to claim "Suite B compliance". There are other > requirements set out by various US government agencies that dictate > whether a particular implementation can be so blessed or not. In > other words, this draft is not a complete and authoritative statement > on what it means to be "Suite B compliant". Looks like you mean section 8 of the draft. This proposed informational RF= C when published will be a statement of the requirements for Suite B IPsec = implementations. We acknowledge that procurements can add additional requi= rements, but they will not contradict the IPsec RFCs, Suite B Certificate a= nd CRL Profile (RFC 5759), or this document. We don't believe any addition= al text is required. > > That being the case, the following statement does not seem technical > and, while it may be true when considering the other requirements > for "Suite B compliance" (that come out of US government agencies), > seems out-of-place and unnecessary here in an IETF document: "Suite > B IPsec compliant systems MUST support IKEv2 and MUST NOT use IKEv1." > > The various US government agencies that deem "Suite B compliance" > may forbid IKEv1 but it does not seem to be reason for an IETF > document to forbid an IKEv1 implementation from deciding to use > P-256 (P-384) with ECDH and ECDSA, and SHA256 (SHA384) and, in all > other respects, be compliant with this draft. I feel the language in > the draft is too restrictive and suggest it be removed (from section > 6 and similar wording in section 1). "IKE" is referred to in other > places in the draft. Just leave it at that and leave the statements > of what it means to have "Suite B compliance" to the agency(-ies) > that actually do that. We have nothing against nor are we preventing IPsec implementations from su= pporting IKEv1 and using Suite B algorithms. However, that would not be Su= ite B compliant. =20 The second sentence of this paragraph from section 8 may address your conce= rn: Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use IKEv1. However, to accommodate backward compatibility, a Suite B IPsec compliant system can be configured to use IKEv1 so long as only IKEv2 is used between a Suite B compliant initiator and responder. We don't believe any additional text is required here. > > regards, > > Dan. > >On Thu, February 10, 2011 11:21 am, Peck, Michael A wrote: >> We've submitted draft-burgin-ipsec-suiteb-profile-00.txt, Suite B Profil= e >> for IPsec, and would appreciate any comments. >> >> The draft should be read in conjunction with draft-law-rfc4869bis-01.txt >> (Suite B Cryptographic Suites for IPsec), which has been submitted and >> should be available shortly. >> >> The new RFC4869bis -01 draft removes the authentication requirements >that >> were previously in its IPsec cryptographic suite definitions. Instead, >> revised authentication requirements have been incorporated into the Suit= e >> B Profile for IPsec draft. >> >> Thanks, >> Mike Peck >> >> >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of >> Sean Turner >> Sent: Thursday, February 10, 2011 12:42 PM >> To: ipsec@ietf.org >> Subject: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.tx= t >> >> This might be of interest to some on this list. >> >> spt >> >> -------- Original Message -------- >> Subject: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt >> Date: Thu, 10 Feb 2011 09:00:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Suite B Profile for Internet Protocol Security (IPsec= ) >> Author(s) : K. Burgin, M. Peck >> Filename : draft-burgin-ipsec-suiteb-profile-00.txt >> Pages : 10 >> Date : 2011-02-10 >> >> The United States Government has published guidelines for "NSA >> Suite B Cryptography" dated July, 2005, which defines cryptographic >> algorithm policy for national security applications. This document >> specifies the conventions for using Suite B cryptography in IP >> Security (IPsec). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-burgin-ipsec-suiteb-profile-00= .txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > From smoonen@us.ibm.com Fri May 27 12:27:09 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 00FBBE07EF for ; Fri, 27 May 2011 12:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 lYDKmtISM6Bt for ; Fri, 27 May 2011 12:27:03 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED74E07EC for ; Fri, 27 May 2011 12:27:03 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4RJO0dM027162 for ; Fri, 27 May 2011 13:24:00 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4RJPkvk037046 for ; Fri, 27 May 2011 13:26:14 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4RJPLSu004195 for ; Fri, 27 May 2011 13:25:22 -0600 Received: from f16n241e (d03nmc07h.boulder.ibm.com [9.17.195.22]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4RJPLcf004184; Fri, 27 May 2011 13:25:21 -0600 In-Reply-To: <19934.24357.318265.873660@fireball.kivinen.iki.fi> References: <19934.24357.318265.873660@fireball.kivinen.iki.fi> X-KeepSent: A7AB316B:1FE334D8-8525789D:004D21BB; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Fri, 27 May 2011 10:18:33 -0400 X-MIMETrack: Serialize by Router on D03NMC07/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/27/2011 13:25:20 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B" Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC 5996 and INITIAL_CONTACT 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, 27 May 2011 19:27:09 -0000 --0__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B Content-type: multipart/alternative; Boundary="1__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B" --1__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Tero Kivinen writes: > I do not think this is real issue. > > The initiator who is initiating the connection is initiating the IKEv= 2 > connection only because it thinks it does not have existing usable > IKEv2 SA / Child SA with the peer it wants to talk to. If it would > have usable IKEv2 SA / Child SA with the peer it wants to talk to, it= > would be using that instead of creating a new one. > > So when initiator is sending this new connection it will know whether= > this is initial contact or whether it is creating multiple connection= s > with the same peer with some other reasons (for example with differen= t > IDi). The problem is that we've defined "same peer" for INITIAL_CONTACT purpo= ses to be based only on identities. Until the connection is complete, the initiator cannot know for sure if this peer will be using the same iden= tity as some other peer that it's already connected to. The RFC even explici= tly admits that this is a possibility ("may be replicated"). The implication is that *even after a crash* the initiator may not be a= ble to send INITIAL_CONTACT in every case. > > So it seems to me that the initiator can only confidently send > > INITIAL_CONTACT based on IDi, and maybe based on IDr if it makes a > > comprehensive search of its PAD. I.e., the initiator can send > > INITIAL_CONTACT only if (1) its IDi is not in use by any other acti= ve > > IKE_SA, or (2) the combination of its IDi and all permitted IDr's t= hat may > > be used for the remote address, based on an exhaustive search of th= e PAD, > > is not in use by any other active IKE_SA. > > Yes. Ok, thanks. > I think interpreting the INITIAL_CONTACT in such a way that it only > applies to the IDi, and IDr sent by the initiator, and if the > responder selects different IDr, it should not delete the IKE SA > between the original IDi and IDr it selected. Ok, thanks. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development 1-919-254-1388 (T/L: 444-1388) http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 05/26/2011 10:10 AM Subject: [IPsec] RFC 5996 and INITIAL_CONTACT Scott C Moonen writes: > IKEv1 was unclear about the scope of this notification, and I'm glad = that > IKEv2 made clear that it applies to identities and not IP addresses. = But > there is an unfortunate chicken-and-egg problem here, and I'm kicking= > myself for not noticing this back in 2009. The paragraph makes it cle= ar > that the decision to send INITIAL_CONTACT is based on the authenticat= ed > identities, and that the notify is sent in IKE_AUTH. However, the initiator > does not know the authenticated identities until it receives the IKE_= AUTH > response. Even if the initiator sends an optional IDr payload, the > responder is not obligated to choose the same identity. I do not think this is real issue. The initiator who is initiating the connection is initiating the IKEv2 connection only because it thinks it does not have existing usable IKEv2 SA / Child SA with the peer it wants to talk to. If it would have usable IKEv2 SA / Child SA with the peer it wants to talk to, it would be using that instead of creating a new one. So when initiator is sending this new connection it will know whether this is initial contact or whether it is creating multiple connections with the same peer with some other reasons (for example with different IDi). Also note that INITIAL_CONTACT is only fall back crash recovery system, in normal case the normal IKEv2 liveness checks will destroy old SAs after a while. > So it seems to me that the initiator can only confidently send > INITIAL_CONTACT based on IDi, and maybe based on IDr if it makes a > comprehensive search of its PAD. I.e., the initiator can send > INITIAL_CONTACT only if (1) its IDi is not in use by any other active= > IKE_SA, or (2) the combination of its IDi and all permitted IDr's tha= t may > be used for the remote address, based on an exhaustive search of the = PAD, > is not in use by any other active IKE_SA. Yes. > This suggests to me that in general the usefulness of INITIAL_CONTACT= is > limited. I wonder about a couple things. First, is there any interest= in an > extension that allows for INITIAL_CONTACT after the IKE_AUTH complete= s? As this is backup crash recovery system, I think there is no point of making it more complicated than what it already is. The current rfc already says that you should send it "after a crash". I.e. it is not normally meant to be sent for every single new IKEv2 connection, altought I think most of the implementations do send it. > (And is that something that would be worth piggybacking onto the QCD > draft?) Second, is there room to stipulate, perhaps in an erratum or = in a > clarifications draft, that when the initiator sends an optional IDr, = the > INITIAL_CONTACT notification applies only if the responder ends up choosing > that identity as its IDr? I think interpreting the INITIAL_CONTACT in such a way that it only applies to the IDi, and IDr sent by the initiator, and if the responder selects different IDr, it should not delete the IKE SA between the original IDi and IDr it selected. Note, that the currect text says "recipient MAY use this information to delete any other IKE SAs it has to the same authenticated identity without waiting for a timeout." In most cases if the initiator's IDr is not acceptable most likely the created IKE SA will not be very useful at all. Also initiator IDr is not very commonly used, and was meant to be used in cases where same server hosts several security gateways and the IDr is used to select one of them. What happens if the proposed IDr is not acceptable, is not covered by the RFCs. I myself would classify that case as a corner case which might require special handling in some scenarios, but that special handling can be done by the implementation without affecting the interoperability, i.e. the security gateway implementation supporting multiple local identities, and getting connection in where the initiator's IDr is not acceptable, it should interpert INITIAL_CONTACT to only apply to the proposed original initiator's IDi/IDr pair, not the newly selected one. -- kivinen@iki.fi = --1__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Tero Kivinen writes:
> I do not think this is real issue.
>
> The initiator who is initiating the connection is initiating the I= KEv2
> connection only because it thinks it does not have existing usable=
> IKEv2 SA / Child SA with the peer it wants to talk to. If it would=
> have usable IKEv2 SA / Child SA with the peer it wants to talk to,= it
> would be using that instead of creating a new one.
>
> So when initiator is sending this new connection it will know = whether
> this is initial contact or whether it is creating multiple connect= ions
> with the same peer with some other reasons (for example with diffe= rent
> IDi).

The problem is that we've defined "same peer" for INITIAL_CON= TACT purposes to be based only on identities. Until the connection is c= omplete, the initiator cannot know for sure if this peer will be using = the same identity as some other peer that it's already connected to. Th= e RFC even explicitly admits that this is a possibility ("may be r= eplicated").

The implication is that *even after a crash* the initiator may not be a= ble to send INITIAL_CONTACT in every case.

> > So it seems to me that the initiator can only confidently= send
> > INITIAL_CONTACT based on IDi, and maybe based on IDr if it ma= kes a
> > comprehensive search of its PAD. I.e., the initiator can send=
> > INITIAL_CONTACT only if (1) its IDi is not in use by any othe= r active
> > IKE_SA, or (2) the combination of its IDi and all permitted I= Dr's that may
> > be used for the remote address, based on an exhaustive search= of the PAD,
> > is not in use by any other active IKE_SA.
>
> Yes.

Ok, thanks.

> I think interpreting the INITIAL_CONTACT in such a way that it= only
> applies to the IDi, and IDr sent by the initiator, and if the
> responder selects different IDr, it should not delete the IKE SA > between the original IDi and IDr it selected.

Ok, thanks.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
1-919-254-1388 (T/L: 444-1388)
http://www.linkedin.com/= in/smoonen

3D"InactiveTero Kivinen ---0= 5/26/2011 10:10:36 AM---Scott C Moonen writes: > IKEv1 was unclear a= bout the scope of this notification, and I'm glad that

From: Tero K= ivinen <kivinen@iki.fi>
To: Scott C = Moonen/Raleigh/IBM@IBMUS
Cc: ipsec@ie= tf.org
Date: 05/26/= 2011 10:10 AM
Subject: [IP= sec] RFC 5996 and INITIAL_CONTACT




Scott C Moonen writes:
> IKEv1 was unclear about the scope of this notification, and I'm gl= ad that
> IKEv2 made clear that it applies to identities and not IP addresse= s. But
> there is an unfortunate chicken-and-egg problem here, and I'm kick= ing
> myself for not noticing this back in 2009. The paragraph makes it = clear
> that the decision to send INITIAL_CONTACT is based on the authenti= cated
> identities, and that the notify is sent in IKE_AUTH. However, the = initiator
> does not know the authenticated identities until it receives the I= KE_AUTH
> response. Even if the initiator sends an optional IDr payload, the=
> responder is not obligated to choose the same identity.

I do not think this is real issue.

The initiator who is initiating the connection is initiating the IKEv2<= br> connection only because it thinks it does not have existing usable
IKEv2 SA / Child SA with the peer it wants to talk to. If it would
have usable IKEv2 SA / Child SA with the peer it wants to talk to, it would be using that instead of creating a new one.

So when initiator is sending this new connection it will know whether this is initial contact or whether it is creating multiple connections<= br> with the same peer with some other reasons (for example with different<= br> IDi).

Also note that INITIAL_CONTACT is only fall back crash recovery
system, in normal case the normal IKEv2 liveness checks will destroy old SAs after a while.

> So it seems to me that the initiator can only confidently send
= > INITIAL_CONTACT based on IDi, and maybe based on IDr if it makes a=
> comprehensive search of its PAD. I.e., the initiator can send
> INITIAL_CONTACT only if (1) its IDi is not in use by any other act= ive
> IKE_SA, or (2) the combination of its IDi and all permitted IDr's = that may
> be used for the remote address, based on an exhaustive search of t= he PAD,
> is not in use by any other active IKE_SA.

Yes.

> This suggests to me that in general the usefulness of INITIAL_CONT= ACT is
> limited. I wonder about a couple things. First, is there any inter= est in an
> extension that allows for INITIAL_CONTACT after the IKE_AUTH compl= etes?

As this is backup crash recovery system, I think there is no point of making it more complicated than what it already is. The current rfc
= already says that you should send it "after a crash". I.e. it= is not
normally meant to be sent for every single new IKEv2 connection,
altought I think most of the implementations do send it.

> (And is that something that would be worth piggybacking onto the Q= CD
> draft?) Second, is there room to stipulate, perhaps in an erratum = or in a
> clarifications draft, that when the initiator sends an optional ID= r, the
> INITIAL_CONTACT notification applies only if the responder ends up= choosing
> that identity as its IDr?

I think interpreting the INITIAL_CONTACT in such a way that it only
= applies to the IDi, and IDr sent by the initiator, and if the
responder selects different IDr, it should not delete the IKE SA
between the original IDi and IDr it selected. Note, that the currect text says "recipient MAY use this information to delete any other = IKE
SAs it has to the same authenticated identity without waiting for a
= timeout."

In most cases if the initiator's IDr is not acceptable most likely the<= br> created IKE SA will not be very useful at all. Also initiator IDr
is not very commonly used, and was meant to be used in cases where
same server hosts several security gateways and the IDr is used to
select one of them. What happens if the proposed IDr is not
acceptable, is not covered by the RFCs.

I myself would classify that case as a corner case which might require<= br> special handling in some scenarios, but that special handling can be done by the implementation without affecting the interoperability,
i.e. the security gateway implementation supporting multiple local
identities, and getting connection in where the initiator's IDr is not<= br> acceptable, it should interpert INITIAL_CONTACT to only apply to the proposed original initiator's IDi/IDr pair, not the newly selected
one.
--
kivinen@iki.fi

= --1__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B-- --0__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF20EDFDEA72B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF20EDFDEA72B8f9e8a93df938690918c0ABBF20EDFDEA72B-- From venkatgiri.t@globaledgesoft.com Sun May 29 23:58:52 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 15E81E0771 for ; Sun, 29 May 2011 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.849 X-Spam-Level: * X-Spam-Status: No, score=1.849 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RELAY_IS_203=0.994] 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 zh4uxgj5mtWc for ; Sun, 29 May 2011 23:58:50 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by ietfa.amsl.com (Postfix) with ESMTP id BC683E0766 for ; Sun, 29 May 2011 23:58:49 -0700 (PDT) Received: from venkatgiri_t.globaledgesoft.com (venkatgiri_t.globaledgesoft.com [172.16.8.60]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 1E52258806A for ; Mon, 30 May 2011 12:31:10 +0530 (IST) Message-ID: <4DE33F57.9050701@globaledgesoft.com> Date: Mon, 30 May 2011 12:25:19 +0530 From: venkatgiri User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="------------090101020605020808050809" Subject: [IPsec] [PF_KEY] Kernel is not identifying the SADB_ACQUIRE (error) message to indicate key management failure [SADB_ACQUIRE message from a user process to the kernel]. 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, 30 May 2011 07:00:45 -0000 This is a multi-part message in MIME format. --------------090101020605020808050809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm receiving the SADB_ACQUIRE message from the kernel to establish the required SA, as i have registered my *pfkey* socket with the kernel. The Key management in my application is failing to get the require key information from the server, so I'm sending the same SADB_ACQUIRE message to the kernel with same sequence number which have received in the SADB_ACQUIRE message with errno set to ENOENT to indicate the Key management has failed. Here i'm constructing only the base header (struct sadb_msg) as described in the RFC 2367. As per the RFC 2367 it has to return me the SADB_ACQUIRE message with the same errno set. The problem here I'm facing is, the kernel is dropping the message which i have sent to the kernel to indicate the Key management has failed. The Kernel is sending the same (last SADB_ACQUIRE for which key management is failed) SADB_ACQUIRE message with *errno* set to ZERO. The OS i'm using is Fedora core 8 (2.6.23.1-42.fc8). Is this feature(kernel should respond with SADB_ACQUIRE with error no ) handled in the above mentioned Linux Kernel version ? can any please let me know what is wrong i'm doing here. It will be very helpful for me. This is code snippet which i'm sending to kernel. /* * send error against acquire message to kenrel. */ int send_acquire_msg_fail(struct acquire *acquire) { struct sadb_msg *newmsg; int len; len = sizeof(struct sadb_msg); newmsg = calloc(1, len); if (newmsg == NULL) { ERROR_RETURN("failed to get buffer to send acquire.\n"); return -1; } memset(newmsg, 0, len); newmsg->sadb_msg_version = PF_KEY_V2; newmsg->sadb_msg_type = SADB_ACQUIRE; newmsg->sadb_msg_errno = ENOENT; newmsg->sadb_msg_satype = SADB_SATYPE_ESP; newmsg->sadb_msg_len = (len/8); newmsg->sadb_msg_reserved = 0; newmsg->sadb_msg_seq = acquire->seq; newmsg->sadb_msg_pid = (u_int32_t)getpid(); /* send message */ if (len != write(pfkey_socket, (void*)msg, len)) { ERROR_RETURN (("SORRY, failed to write the SADB_ACQUIRE message to the kernel\n")); } free(newmsg); return 0; } *Rfc 2367 reference :* If a KMd has any error at all during its negotiation, it can send down: KMd->Kernel: SADB_ACQUIRE for AH, assoc (with an error) *Kernel->All: SADB_ACQUIRE for AH, assoc (same error)* -- Regards, Venkatgiri --------------090101020605020808050809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,
 
I'm receiving the SADB_ACQUIRE message from the kernel to establish the required SA, as i have registered my pfkey socket with the kernel.
The Key management in my application is failing to get the require key information from the server, so I'm sending the same SADB_ACQUIRE message to the kernel with same sequence number which have received in the SADB_ACQUIRE message with errno set to ENOENT to indicate the Key management has failed.
 
Here i'm constructing only the base header (struct sadb_msg) as described in the RFC 2367. As per the RFC 2367 it has to return me the SADB_ACQUIRE message with the same errno set.
 
The problem here I’m facing is, the kernel is dropping the message which i have sent to the kernel to indicate the Key management has failed. The Kernel is sending the same (last SADB_ACQUIRE for which key management is failed) SADB_ACQUIRE message with errno set to ZERO.  The OS i'm using is Fedora core 8 (2.6.23.1-42.fc8).
 
Is this feature(kernel should respond with SADB_ACQUIRE with error no ) handled in the above mentioned Linux Kernel version ?
 
can any please let me know what is wrong i'm doing here. It will be very helpful for me.
 
This is code snippet which i'm sending to kernel.
 
/*
 * send error against acquire message to kenrel.
 */
int
send_acquire_msg_fail(struct acquire *acquire)
{
    struct sadb_msg *newmsg;
    int len;
 
    len = sizeof(struct sadb_msg);
    newmsg = calloc(1, len);
    if (newmsg == NULL) {
        ERROR_RETURN("failed to get buffer to send acquire.\n");
        return -1;
    }
 
    memset(newmsg, 0, len);
    newmsg->sadb_msg_version = PF_KEY_V2; 
    newmsg->sadb_msg_type = SADB_ACQUIRE;
    newmsg->sadb_msg_errno = ENOENT;  
    newmsg->sadb_msg_satype = SADB_SATYPE_ESP;
    newmsg->sadb_msg_len = (len/8);
    newmsg->sadb_msg_reserved = 0;
    newmsg->sadb_msg_seq = acquire->seq;
    newmsg->sadb_msg_pid = (u_int32_t)getpid();
 
    /* send message */
    if (len != write(pfkey_socket, (void*)msg, len)) {
          ERROR_RETURN (("SORRY, failed to write the SADB_ACQUIRE message to the kernel\n"));
     }
     free(newmsg);
     return 0;
}
 
 
Rfc 2367 reference :
 
If a KMd has any error at all during its negotiation, it can send
   down:
 
KMd->Kernel:         SADB_ACQUIRE for AH, assoc (with an error)
Kernel->All:         SADB_ACQUIRE for AH, assoc (same error)
 
--
Regards,
Venkatgiri
--------------090101020605020808050809-- From muhammadnasirmumtaz@gmail.com Tue May 31 23:23: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 209DBE0697 for ; Tue, 31 May 2011 23:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp7OHWPitZiW for ; Tue, 31 May 2011 23:23:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4385E0689 for ; Tue, 31 May 2011 23:23:25 -0700 (PDT) Received: by pvh18 with SMTP id 18so2646803pvh.31 for ; Tue, 31 May 2011 23:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=JhE2/CrJ7677hp5sNpe3dapfM4QvrmAdpuTDP3M1w64=; b=Bfeog/kixwr8Uki+MMcXLfEQMbaIreoN6jmjpwgMj+jMymKxYj2GrOl1/Gr/GkmWxT c+6tmBv49cCDAAfsuNG3f/J9TtPi4YdRY0K/mKyy2+uJNckqt/GS4BnIVtzO96Bt83Mk XUlrcWUGtzbYaraMP3/8rfGZ1sFwelFpSjwOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FqU+2Ku9ip2pOyfg9IBt/NxsCUcXS6gJ5FH8z16fpdf5YV7jUgetIRyhfXuqoVYC92 Hh7+7n7j/KVR2Jim3OwdtHZE6gxDmTsfaUbApKki2+rAj/bCu1qD3YZxGgOd1G51h8Oy OaK5cy3VW50kWolT2fbrDONt9UnnHQZhO9SMQ= MIME-Version: 1.0 Received: by 10.142.141.18 with SMTP id o18mr1014893wfd.303.1306909405179; Tue, 31 May 2011 23:23:25 -0700 (PDT) Received: by 10.143.92.18 with HTTP; Tue, 31 May 2011 23:23:25 -0700 (PDT) Date: Wed, 1 Jun 2011 07:23:25 +0100 Message-ID: From: Muhammad Nasir Mumtaz Bhutta To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32ed0d96f3e04a4a08e07 Subject: [IPsec] IPSec implementation 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, 01 Jun 2011 06:23:26 -0000 --000e0cd32ed0d96f3e04a4a08e07 Content-Type: text/plain; charset=ISO-8859-1 hi, i need to change the IPSec functionality, is there any implementation of IPSec in higher order languages like java, .net (vb, c#, c++) ... it can be on any platform windows or linux ... is there any good starting point for linux kernel implementation of IPSec... many thanks for any one's help and time .. kind regards, Nasir --000e0cd32ed0d96f3e04a4a08e07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,=A0
i need to change the IPSec functionality, is there any implementation = of IPSec in higher order languages like java, .net (vb, c#, c++) ... it can= be on any platform windows or linux ...=A0

is the= re any good starting point for linux kernel implementation of IPSec...=A0

many thanks for any one's help and time ..=A0
=

kind regards,
Nasir=A0
--000e0cd32ed0d96f3e04a4a08e07-- From ynir@checkpoint.com Tue May 31 23:33: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 64F2CE074F for ; Tue, 31 May 2011 23:33:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLc9z5pCBIi8 for ; Tue, 31 May 2011 23:33:25 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4683AE065D for ; Tue, 31 May 2011 23:33:25 -0700 (PDT) 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 p516X7xS014169; Wed, 1 Jun 2011 09:33:22 +0300 X-CheckPoint: {4DE5E9C4-0-1B221DC2-FFFF} 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; Wed, 1 Jun 2011 09:33:14 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 1 Jun 2011 09:33:14 +0300 From: Yoav Nir To: Muhammad Nasir Mumtaz Bhutta Date: Wed, 1 Jun 2011 09:33:12 +0300 Thread-Topic: [IPsec] IPSec implementation Thread-Index: AcwgJciiapESspoQSCGfS+11HyFNSQ== Message-ID: References: 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: "ipsec@ietf.org" Subject: Re: [IPsec] IPSec implementation 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, 01 Jun 2011 06:33:26 -0000 IPsec usually runs in kernels, so C seems to be the norm I'm not aware of any C++ implementations. On Jun 1, 2011, at 9:23 AM, Muhammad Nasir Mumtaz Bhutta wrote: > hi,=20 > i need to change the IPSec functionality, is there any implementation of = IPSec in higher order languages like java, .net (vb, c#, c++) ... it can be= on any platform windows or linux ...=20 >=20 > is there any good starting point for linux kernel implementation of IPSec= ...=20 >=20 > many thanks for any one's help and time ..=20 >=20 > kind regards, > Nasir=20 >=20 >=20 > Scanned by Check Point Total Security Gateway.=20 >=20 >