From ipsec-bounces@ietf.org Mon Oct 02 04:18:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIxj-00081h-1a; Mon, 02 Oct 2006 04:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIxh-0007zZ-Ja for ipsec@ietf.org; Mon, 02 Oct 2006 04:15:41 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUIxg-0006zB-3k for ipsec@ietf.org; Mon, 02 Oct 2006 04:15:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k928FccO020413; Mon, 2 Oct 2006 11:15:38 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:15:38 +0300 Received: from 4FIL09356 ([10.162.83.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 2 Oct 2006 11:15:38 +0300 From: "Pasi Eronen" To: "'ext Narayanan, Vidya'" , Subject: RE: [Ipsec] Clarification on EAP MSK usage in IKEv2 Date: Mon, 2 Oct 2006 11:15:38 +0300 Message-ID: <000001c6e5fa$f1a624e0$f39cb70a@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbkJyyPFyVUxZoaSo6+yR8iWuf/RwB0NW4w In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 02 Oct 2006 08:15:38.0151 (UTC) FILETIME=[F16A7B70:01C6E5FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Vidya Narayanan wrote: > > All, > RFC4306, in section 2.16, states: > > "For EAP methods that create a shared key as a side effect of > authentication, that shared key MUST be used by both the > initiator and responder to generate AUTH payloads in messages 7 > and 8 using the syntax for shared secrets specified in section > 2.15. The shared key from EAP is the field from the EAP > specification named MSK. The shared key generated during an IKE > exchange MUST NOT be used for any other purpose." > > This seems to be a bit ambiguous in what constitutes "other > purposes". For instance, let's consider two entities A & B > running IKEv2-EAP and establishing an IKE_SA between themselves, > using the MSK for authentication of the IKE_SA. If A & B were to > subsequently run IKEv2 again and establish another IKE_SA, could > the same MSK be then used for authentication here as well? > > In other words, it seems confusing whether "other purposes" also > means "for other IKEv2 runs between the same initiator and responder". I believe the intent was that MSK is used once to calculate/verify the AUTH payload, and not used for anything else afterwards. > If we drew an analogy from the MSK usage on other EAP lower > layers (e.g., IEEE 802.11i), the same MSK can be used to re-key > TSKs between the same peer and authenticator until expiry of that > MSK. By the same argument, I don't see a reason why the MSK > cannot be used again for the authentication of a subsequent > IKE_SA between the IKEv2 initiator and responder. I can see some > exceptions (e.g., where the IKEv2 entity acting as the EAP peer > actually wishes to use different identity/credentials for the two > exchanges, requiring a separate EAP run for those), but, in > general, it seems like we should be able to use the same MSK for > the multiple exchanges. > > One potential concern is perhaps due to the fact that the MSK is > used directly in the generation of the AUTH payload and if the > multiple IKEv2 runs used different prf's for generating the AUTH > payload, that could result in a bad use of the MSK. But, if the > same algorithm is used in the multiple runs, is there still > something to be concerned about? And, would it be a violation of > RFC4306? > > I'd appreciate any clarification on the above. Also, if someone > can provide clarity on what implementations do (e.g., is the MSK > deleted after authenticating the IKE_SA or is it cached for a > certain duration, etc.), that would be very helpful. Currently, it makes no sense to cache the MSK, since RFC4306 does not include any functionality that would use it (e.g. establishing another IKE_SA using the same MSK). So I guess you're asking that if someone would write an Intenet- Draft "establishing multiple IKE_SAs without re-running EAP" (or something), would that be an acceptable extension to RFC4306, or un unacceptable violation of the "MUST NOT be used..." requirement? That's a difficult question. I think such a draft could be written in a way that would be reasonable secure (and would not be very long document, except maybe the security considerations text), but being somehow "secure" has not usually been a sufficient criterion for being an acceptable use of EAP :-) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 02 09:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO3V-0001wP-KA; Mon, 02 Oct 2006 09:42:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUO3T-0001wJ-Su for ipsec@ietf.org; Mon, 02 Oct 2006 09:41:59 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUO3Q-0003Y4-Iv for ipsec@ietf.org; Mon, 02 Oct 2006 09:41:59 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k92DfrVM013569; Mon, 2 Oct 2006 09:41:53 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k92DeqAG013834; Mon, 2 Oct 2006 09:41:51 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Oct 2006 09:41:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Oct 2006 09:41:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: AcbmCozgS1x9wBpHT+iMb8LHSyJ9fgAHPd1w To: X-OriginalArrivalTime: 02 Oct 2006 13:41:26.0349 (UTC) FILETIME=[750CC7D0:01C6E628] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.10.2.61442 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, fred@cisco.com, saag@MIT.EDU, hartmans-ietf@MIT.EDU, Black_David@emc.com Subject: [Ipsec] RE: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Francois, The concern about how to use a PHB consisting of multiple DSCPs (e.g., AF) also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may help address this, and this concern may also affect RFC 3175. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 > Sent: Monday, October 02, 2006 6:03 AM > To: Black, David > Cc: Francois Le Faucheur; hartmans-ietf@MIT.EDU;=20 > saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org;=20 > fred@cisco.com > Subject: Re: [saag] tsvwg,preemption and rsvp: exposing=20 > characteristics of confidentialtraffic >=20 > Hello, >=20 > Just expanding on Dave's observation: >=20 > >> These drafts set up a model under which each precedence class of data > >> from a preemption standpoint goes over its own SA and uses its own > >> aggregate RSVP reservation. What that means is you expose on the > >> unprotected side of the interface what fraction of your traffic is at > >> each precedence level. > > > > Actually, only the vpn-signaled-preemption draft appears to do this. > > > > The rsvp-ipsec draft allows multiple reservations between the same > > endpoints for the same DSCP, which would allow such traffic to use > > different tunnels but if it requires traffic for different > > reservations to use different tunnels, I was not able to find > > a statement of that requirement. > > >=20 > Right. > The rsvp-ipsec draft effectively decorelates the aggregate =20 > reservations from the security associations (this was done as a =20 > result of the first round of Security Experts review we got). So, for > example,: > * it allows to set up multiple aggregate reservations using a single SA > * it allows to setup one aggregate reservation per SA > * it does not force/mandate either of these modes. >=20 > The logic is to provide a generic mechanism which may be used in =20 > different ways, in particular in the way(s) discussed in vpn-signaled-preemption. > rsvp-ipsec refers to vpn-signaled-preemption's Security =20 > Considerations for when used as per vpn-signaled-preemption. >=20 > Cheers >=20 > Francois _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 02 12:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQzC-0006TV-66; Mon, 02 Oct 2006 12:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQzA-0006TP-Or for ipsec@ietf.org; Mon, 02 Oct 2006 12:49:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQz9-0005NT-95 for ipsec@ietf.org; Mon, 02 Oct 2006 12:49:44 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k92Gnecm001590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Oct 2006 09:49:42 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k92GnbXC020627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Oct 2006 09:49:39 -0700 (PDT) Message-Id: <7.0.1.0.2.20061002093151.06e92190@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 02 Oct 2006 09:49:31 -0700 To: "Pasi Eronen" , "'ext Narayanan, Vidya'" , From: Lakshminath Dondeti Subject: RE: [Ipsec] Clarification on EAP MSK usage in IKEv2 In-Reply-To: <000001c6e5fa$f1a624e0$f39cb70a@NOE.Nokia.com> References: <000001c6e5fa$f1a624e0$f39cb70a@NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org At 01:15 AM 10/2/2006, Pasi Eronen wrote: >Vidya Narayanan wrote: > > > > All, > > RFC4306, in section 2.16, states: > > > > "For EAP methods that create a shared key as a side effect of > > authentication, that shared key MUST be used by both the > > initiator and responder to generate AUTH payloads in messages 7 > > and 8 using the syntax for shared secrets specified in section > > 2.15. The shared key from EAP is the field from the EAP > > specification named MSK. The shared key generated during an IKE > > exchange MUST NOT be used for any other purpose." > > > > This seems to be a bit ambiguous in what constitutes "other > > purposes". For instance, let's consider two entities A & B > > running IKEv2-EAP and establishing an IKE_SA between themselves, > > using the MSK for authentication of the IKE_SA. If A & B were to > > subsequently run IKEv2 again and establish another IKE_SA, could > > the same MSK be then used for authentication here as well? > > > > In other words, it seems confusing whether "other purposes" also > > means "for other IKEv2 runs between the same initiator and responder". > >I believe the intent was that MSK is used once to calculate/verify >the AUTH payload, and not used for anything else afterwards. > > > If we drew an analogy from the MSK usage on other EAP lower > > layers (e.g., IEEE 802.11i), the same MSK can be used to re-key > > TSKs between the same peer and authenticator until expiry of that > > MSK. By the same argument, I don't see a reason why the MSK > > cannot be used again for the authentication of a subsequent > > IKE_SA between the IKEv2 initiator and responder. I can see some > > exceptions (e.g., where the IKEv2 entity acting as the EAP peer > > actually wishes to use different identity/credentials for the two > > exchanges, requiring a separate EAP run for those), but, in > > general, it seems like we should be able to use the same MSK for > > the multiple exchanges. > > > > One potential concern is perhaps due to the fact that the MSK is > > used directly in the generation of the AUTH payload and if the > > multiple IKEv2 runs used different prf's for generating the AUTH > > payload, that could result in a bad use of the MSK. But, if the > > same algorithm is used in the multiple runs, is there still > > something to be concerned about? And, would it be a violation of > > RFC4306? > > > > I'd appreciate any clarification on the above. Also, if someone > > can provide clarity on what implementations do (e.g., is the MSK > > deleted after authenticating the IKE_SA or is it cached for a > > certain duration, etc.), that would be very helpful. > >Currently, it makes no sense to cache the MSK, since RFC4306 does >not include any functionality that would use it (e.g. establishing >another IKE_SA using the same MSK). > >So I guess you're asking that if someone would write an Intenet- >Draft "establishing multiple IKE_SAs without re-running EAP" (or >something), would that be an acceptable extension to RFC4306, or >un unacceptable violation of the "MUST NOT be used..." requirement? > >That's a difficult question. I think such a draft could be written >in a way that would be reasonable secure (and would not be >very long document, except maybe the security considerations >text), but being somehow "secure" has not usually been a sufficient >criterion for being an acceptable use of EAP :-) I am curious about the security implications here. Let's dig a bit further. From the first IKEv2-EAP exchange, the Responder would have received an MSK and a lifetime. The EAP keying draft says the following about that lifetime: IKEv2 as specified in [RFC4306] does not cache EAP keying material or parameters; once IKEv2 authentication completes it is assumed that EAP keying material and parameters are discarded. The Session-Timeout attribute is therefore interpreted as a limit on the VPN session time, rather than an indication of the MSK key lifetime. I am sure saving the MSK for re-use as a PSK makes sense, if the VPN session happens to drop due to non-security reasons and the two parties need to authenticate each other. What security issues do you see here, Pasi? I can think of some, but the lifetime parameter is very effective here. As long as the resultant IPsec SAs are deleted by the IPsec GW pursuant to the Session-Timeout rules, I don't see a problem. Sure, we need further specification (and an edit of the eap-keying draft), but that can be done. thanks, Lakshminath >Best regards, >Pasi > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 02 13:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURjE-00014C-DI; Mon, 02 Oct 2006 13:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURjD-000141-2C for ipsec@ietf.org; Mon, 02 Oct 2006 13:37:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GURj9-0006UN-LD for ipsec@ietf.org; Mon, 02 Oct 2006 13:37:19 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k92HbDXV010806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Oct 2006 10:37:14 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.na.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k92HYrYx007033; Mon, 2 Oct 2006 10:37:10 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:37:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarification on EAP MSK usage in IKEv2 Date: Mon, 2 Oct 2006 10:37:03 -0700 Message-ID: In-Reply-To: <7.0.1.0.2.20061002093151.06e92190@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Clarification on EAP MSK usage in IKEv2 thread-index: AcbmQsLMUVZRtsRNTDOirWdkqhTdAAABb/WA From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Pasi Eronen" , X-OriginalArrivalTime: 02 Oct 2006 17:37:05.0843 (UTC) FILETIME=[60D85830:01C6E649] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi Pasi, Lakshminath,=20 > > > >Currently, it makes no sense to cache the MSK, since RFC4306=20 > does not=20 > >include any functionality that would use it (e.g.=20 > establishing another=20 > >IKE_SA using the same MSK). > > > >So I guess you're asking that if someone would write an=20 > Intenet- Draft=20 > >"establishing multiple IKE_SAs without re-running EAP" (or=20 > something),=20 > >would that be an acceptable extension to RFC4306, or un unacceptable=20 > >violation of the "MUST NOT be used..." requirement? > > > >That's a difficult question. I think such a draft could be=20 > written in a=20 > >way that would be reasonable secure (and would not be very long=20 > >document, except maybe the security considerations text), but being=20 > >somehow "secure" has not usually been a sufficient criterion=20 > for being=20 > >an acceptable use of EAP :-) >=20 I wonder what you mean by "reasonably secure" - I am not sure why using the MSK for establishing muultiple IKE_SAs without re-running EAP would be any less secure than the use of a PSK for the same purpose. If anything, I expect the MSKs to be stronger (depending on the EAP method used) and bound by lifetimes, making it more secure than a configured PSK.=20 > I am curious about the security implications here. Let's dig=20 > a bit further. From the first IKEv2-EAP exchange, the=20 > Responder would have received an MSK and a lifetime. The EAP=20 > keying draft says the following about that lifetime: >=20 > IKEv2 as specified in [RFC4306] does > not cache EAP keying material or parameters; once IKEv2 > authentication completes it is assumed that EAP keying=20 > material and > parameters are discarded. The Session-Timeout attribute is > therefore interpreted as a limit on the VPN session time, rather > than an indication of the MSK key lifetime. >=20 > I am sure saving the MSK for re-use as a PSK makes sense, if=20 > the VPN session happens to drop due to non-security reasons=20 > and the two parties need to authenticate each other. What=20 > security issues do you see here, Pasi? I can think of some,=20 > but the lifetime parameter is very effective here. As long=20 > as the resultant IPsec SAs are deleted by the IPsec GW=20 > pursuant to the Session-Timeout rules, I don't see a problem.=20 > Sure, we need further specification (and an edit of the=20 > eap-keying draft), but that can be done. >=20 I agree. Also, I don't see why this would not be an acceptable use of EAP, since there are lower layers already that use the same MSK (without re-running EAP) for multiple TSK generations (i.e., TSK re-keying can be done today without re-running EAP).=20 Vidya _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 03 04:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfmh-0004EV-5i; Tue, 03 Oct 2006 04:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfmf-0004Bx-DG for ipsec@ietf.org; Tue, 03 Oct 2006 04:37:49 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfmd-0008RO-UZ for ipsec@ietf.org; Tue, 03 Oct 2006 04:37:49 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k938bkmu008296; Tue, 3 Oct 2006 11:37:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:36:56 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:36:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarification on EAP MSK usage in IKEv2 Date: Tue, 3 Oct 2006 11:37:00 +0300 Message-ID: In-Reply-To: <7.0.1.0.2.20061002093151.06e92190@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Clarification on EAP MSK usage in IKEv2 Thread-Index: AcbmQuZdb9WxoaOiRXmAry15tY7P2gAg+YEw From: To: , , X-OriginalArrivalTime: 03 Oct 2006 08:36:56.0162 (UTC) FILETIME=[15953C20:01C6E6C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Lakshminath Dondeti wrote: > I am curious about the security implications here. Let's dig a bit=20 > further. From the first IKEv2-EAP exchange, the Responder would have=20 > received an MSK and a lifetime. The EAP keying draft says the=20 > following about that lifetime: >=20 > IKEv2 as specified in [RFC4306] does not cache EAP keying > material or parameters; once IKEv2 authentication completes it > is assumed that EAP keying material and parameters are > discarded. The Session-Timeout attribute is therefore > interpreted as a limit on the VPN session time, rather than an > indication of the MSK key lifetime. >=20 > I am sure saving the MSK for re-use as a PSK makes sense, if the VPN=20 > session happens to drop due to non-security reasons and the two=20 > parties need to authenticate each other. What security issues do you=20 > see here, Pasi? I can think of some, but the lifetime parameter is=20 > very effective here. As long as the resultant IPsec SAs are deleted=20 > by the IPsec GW pursuant to the Session-Timeout rules, I don't see a=20 > problem. Sure, we need further specification (and an edit of the=20 > eap-keying draft), but that can be done. We don't necessarily need an edit for the eap-keying draft, because it is correct: IKEv2 as specified in [RFC4306] doesn't cache the MSK. An extension to IKEv2 (not part of RFC4306) could to it, though. The extension would need to specify e.g. how to indicate in IKEv2 that you want to re-use the same MSK, identify the right MSK (which just username doesn't do), handle lifetime issues (the initiator doesn't know what the Session-Timeout attribute was), ensure that single MSK is used only with single PRF algorithm, and so on. I also agree that all this can be done; whether it should be done is a somewhat different question (e.g., as for any optimization, are the benefits worth the added complexity?). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 03 04:40:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfp5-0004ta-1Y; Tue, 03 Oct 2006 04:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfp3-0004tV-Rk for ipsec@ietf.org; Tue, 03 Oct 2006 04:40:17 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfp2-0000Iv-Dg for ipsec@ietf.org; Tue, 03 Oct 2006 04:40:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k938eD0X009516; Tue, 3 Oct 2006 11:40:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:40:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:40:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarification on EAP MSK usage in IKEv2 Date: Tue, 3 Oct 2006 11:40:06 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Clarification on EAP MSK usage in IKEv2 Thread-Index: AcbmQsLMUVZRtsRNTDOirWdkqhTdAAABb/WAAB+rIHA= From: To: , , X-OriginalArrivalTime: 03 Oct 2006 08:40:01.0125 (UTC) FILETIME=[83D45950:01C6E6C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Vidya Narayanan wrote: > I wonder what you mean by "reasonably secure" - I am not sure why > using the MSK for establishing muultiple IKE_SAs without re-running > EAP would be any less secure than the use of a PSK for the same > purpose. If anything, I expect the MSKs to be stronger (depending on > the EAP method used) and bound by lifetimes, making it more secure > than a configured PSK. Well, re-using the MSK is probably not more secure than re-running EAP for each IKE_SA (but might save some roundtrips and other resources).=20 But by "reasonably secure", I meant that this can be made "secure=20 enough", provided that the details are right. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 03 20:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUu9C-0000vY-8U; Tue, 03 Oct 2006 19:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUu9A-0000v6-GG for ipsec@ietf.org; Tue, 03 Oct 2006 19:58:00 -0400 Received: from www.nabble.com ([72.21.53.35] helo=talk.nabble.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUu99-0006jl-8d for ipsec@ietf.org; Tue, 03 Oct 2006 19:58:00 -0400 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GUu99-0004Yv-3D for ipsec@ietf.org; Tue, 03 Oct 2006 16:57:59 -0700 Message-ID: <6630902.post@talk.nabble.com> Date: Tue, 3 Oct 2006 16:29:17 -0700 (PDT) From: venkyee To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: venkyee_s@yahoo.com X-Spam-Score: 2.7 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] IKEV2, INTERNAL_IP4_DHCP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hello, I would like some clarificaiton on IKEV2 CP for INTERNAL_IP4_DHCP. My host would like to recieve the DHCP options information such as SIP servers(120 , SIP Servers DHCP Option N SIP Servers DHCP Option [RFC3361] ) Considering the RFC 4306: o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send any internal DHCP requests to the address contained within the attribute. Multiple DHCP servers MAY be requested. The responder MAY respond with zero or more DHCP server attributes. It says, host can send dhcp requests to the address in INTERNAL_IP4_DHCP. However the Dchp requests can only be sent to server during 1. DHCPREQUEST generated during RENEWING state 2. DHCPREQUEST generated during INIT-REBOOT state 3. DHCPREQUEST generated during SELECTING state Can anyone throw light on: a. If dhcp request has to be performed it must be done once after the IKEv2 AUTH? b. If my host recieve the DHCP address, is it a over head to receive the IP address? c. I think there should be CP ( INTERNAL_DHCP_OPTIONS). Since the DHCP binding is done by the DHCP client at the other end of tunnel which is on the remote leg. d. If not, how to retrieve the DHCP options. thanks for your clarifications. _Venkyee -- View this message in context: http://www.nabble.com/IKEV2%2C-INTERNAL_IP4_DHCP-tf2379330.html#a6630902 Sent from the IETF - Ipsec mailing list archive at Nabble.com. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 05 05:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPKX-0003Xe-El; Thu, 05 Oct 2006 05:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPKW-0003Wi-2J; Thu, 05 Oct 2006 05:15:48 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVPKT-0005Qf-CY; Thu, 05 Oct 2006 05:15:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k959FIY4020703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Oct 2006 12:15:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k959FDhM010355; Thu, 5 Oct 2006 12:15:13 +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: <17700.52513.861679.673271@fireball.kivinen.iki.fi> Date: Thu, 5 Oct 2006 12:15:13 +0300 From: Tero Kivinen To: jasani_rohan@bah.com, pezeshki_jonah@bah.com, ertekin_emre@bah.com, christou_chris@bah.com Subject: [Ipsec] I-D ACTION:draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 25 min X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: IPsec WG , rohc@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Internet-Drafts@ietf.org writes: > Title : Extensions to IKEv2 to Support Header > Compression over IPsec (HCoIPsec) > Author(s) : R. Jasani, et al. > Filename : draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt > Pages : 15 > Date : 2006-9-29 Some comments: > 3.1. Header Compression Scheme Negotiation ... > Protocol ID (1 octet) > If this notification concerns an existing SA, this field indicates > the SA type. This field must contain either (2) to indicate AH or > (3) to indicate ESP on the Child SA. For notifications that do > not relate to an existing SA, this field must be sent as zero and > ignored on receipt. This value must not be set to (1), since this > refers to IKE_SA notifications. All other values for this field > are reserved to IANA for future assignment. The draft-eronen-ipsec-ikev2-clarifications-09.txt (now in the RFC editor queue) states that: > 7.8. Protocol ID/SPI fields in Notify payloads ... > Since the main purpose of the Protocol ID field is to specify the > type of the SPI, our interpretation is that the Protocol ID field > should be non-zero only when the SPI field is non-empty. I.e. as we do not have SPI in this HC_SUPPORTED notify the protocol ID MUST be 0, not 1. Also I think the Notify payload body should contain exactly one HC ID and configuration parameters for that scheme, and instead of combining all HC parameters inside that one notify add multiple notify payloads each specifying exactly one HC scheme, and the priority order comes from the order of notify payloads (similarly what MOBIKE does with the ADDITIONAL_IP*_ADDRESS notifies, see RFC4621 section 6.3 for more information about the description of the issue). Also I do not understand why do you have HC ID twice, i.e. first the current HC ID and then the next HC ID in the same block and then the next block again repeats the HC ID (i.e. hopefully the same as the Next HC ID as listed before) and so on. This makes implementations harder as the implementator needs to check that those numbers match and needs to decide what to do if they do not match (tear down IKE SA? Ignore HC_SUPPORTED notify? etc). So my proposal would be change the current format of : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID(0)! SPI Size(0) ! Notify Message Type (HC_SUPP) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC ID(X) | Next HC ID(Y) | HC Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ HC Scheme Configuration Parameters ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC ID(Y) | Next HC ID(0) | HC Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ HC Scheme Configuration Parameters ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with multiple IKEv2 Notify payloads: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID(0)! SPI Size(0) ! Notify Message Type (HC_SUPP) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC ID(X) | HC Scheme Confuguration Parameters | +-+-+-+-+-+-+-+-+ | ~ ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID(0)! SPI Size(0) ! Notify Message Type (HC_SUPP) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC ID(Y) | HC Scheme Confuguration Parameters | +-+-+-+-+-+-+-+-+ | ~ ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this format there is no need to have separate HC Parameter Length field, as the length can be seen from the notify payload length. This also removes the double HC ID issue and is probably easier to implement as IKEv2 implementations already know how to parse notify payloads so they will do the parsing of that and just give the notify data to the HC module. I do not also understand the reason why we need to explicitly offer NONE HC ID. Does that mean that if we do not offer it all packets MUST have header compression enabled and cannot be sent without compression at all? What should recipient do if it receives such packet without header compression. If this is negotiated security parameter then it should actually detect this as a violation of the security policy and throw away of that packet, but I do not think we want to do that. If recipient always needs to accept packets without header compression then I do not think it is useful to even include NONE to the list at all. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 05 07:02:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQxn-0000mb-W2; Thu, 05 Oct 2006 07:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQxm-0000mV-9S for ipsec@ietf.org; Thu, 05 Oct 2006 07:00:26 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVQxj-0007mb-Np for ipsec@ietf.org; Thu, 05 Oct 2006 07:00:26 -0400 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k95AxWmi018132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Oct 2006 13:59:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k95AxUVk005602; Thu, 5 Oct 2006 13:59:30 +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: <17700.58769.998616.156927@fireball.kivinen.iki.fi> Date: Thu, 5 Oct 2006 13:59:29 +0300 From: Tero Kivinen To: "Scott G. Kelly" Subject: Re: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt In-Reply-To: <31324918.1159564931917.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31324918.1159564931917.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 91 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ipsec list , "Steven M. Bellovin" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Scott G. Kelly writes: > We added the PRF support after that text was written (rather than > writing a separate doc), and in the interest of flexibility, chose > to allow variable length keys. I'm wondering now if that was a > mistake, and we should have had a single position on key sizes. That > would definitely simplify things. No, you definately want to support variable length keys for the PRF in the IKEv2 use. Otherwise you end up similar problems than what happened with the PRF_AES128_XCBC. The problem there was that EAP MSK is at minimum 512 bits long and that is given as a key to the PRF, so PRF must be able to handle keys that long to be able to be used with EAP. > As for padding short keys, it certainly adds no security. It is > there to explicitly tell implementors what to do (so they don't > instead hash the key, and use the output). It's called out for the > sake of interoperability. That also makes it possible to use IKEv2 shared secret that do not match the key length required for the PRF_HMAC_SHA2_256. If PRF was defined to use fixed length keys then the shared secret would be required to be exactly the length of that fixed key and that could cause problems (i.e. for example you could not update from the PRF_AES128_XCBC to PRF_HMAC_SHA2_256 without changing the keying material too. > >Stepping back a bit, I personally would rather see a single RFC describing > >how to use a number of different hash functions with HMAC. I could almost > >use a set of text editor substitution patterns to change this draft from > >SHA-256 to SHA-384 or SHA-512. The core of such a document would be a > >table listing acceptable key sizes and truncation sizes for each function > >considered. An appendix could list test vectors. > > Russ just mentioned that NSA-B requires SHA-384 support, and I was > looking at the draft to see if that could be cleanly dropped in - > this might be one way to do it. If there is general support for > this approach, we can look at what it would take to re-spin the doc. Yes, I think it would be better to add SHA-384 and SHA-512 to this draft too. On the other hand I think it is better not to have too many different combinations, i.e. I can see use for PRF_HMAC_SHA2_384 and PRF_HMAC_SHA2_512, but I do not know how many different truncation lengths we need. Perhaps it would be enough to define AUTH_HMAC_SHA2_256_128, AUTH_HMAC_SHA2_384_192 and AUTH_HMAC_SHA2_512_256, and skip all other truncation lengths (including the AUTH_HMAC_SHA2_256_192 already defined in the draft). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Oct 14 13:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnS9-0004yU-OY; Sat, 14 Oct 2006 13:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnS7-0004rh-Mo for ipsec@ietf.org; Sat, 14 Oct 2006 13:37:39 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYnS5-0006yX-9p for ipsec@ietf.org; Sat, 14 Oct 2006 13:37:39 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9EHbann011853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 Oct 2006 10:37:36 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9EHbZ17016189 for ; Sat, 14 Oct 2006 10:37:35 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 10:37:34 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 14 Oct 2006 10:37:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPD Checks for IPsec Inbound Processing Thread-Index: Acbvt2wfc57vY2hSQPaLfgqhN8CVZA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 14 Oct 2006 17:37:34.0954 (UTC) FILETIME=[6F2754A0:01C6EFB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ipsec] SPD Checks for IPsec Inbound Processing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi, RFC2401 had SPD checks for inbound packet processing after processing with a matching SA, while RFC4301 only advocates SPD checks for bypassed or discarded inbound packets. Can anyone throw some light on why the SPD checks on packets with a matching SA were not preserved?=20 Thanks, Vidya _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 16 11:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZURb-0005Kz-Ql; Mon, 16 Oct 2006 11:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZURZ-0005Kq-NO for ipsec@ietf.org; Mon, 16 Oct 2006 11:31:57 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZURV-0002lQ-FI for ipsec@ietf.org; Mon, 16 Oct 2006 11:31:57 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GZURS-0002cF-6L; Mon, 16 Oct 2006 11:31:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 16 Oct 2006 11:31:49 -0400 To: "Narayanan, Vidya" From: Stephen Kent Subject: Re: [Ipsec] SPD Checks for IPsec Inbound Processing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org At 10:37 AM -0700 10/14/06, Narayanan, Vidya wrote: >Hi, >RFC2401 had SPD checks for inbound packet processing after processing >with a matching SA, while RFC4301 only advocates SPD checks for bypassed >or discarded inbound packets. Can anyone throw some light on why the SPD >checks on packets with a matching SA were not preserved? > >Thanks, >Vidya We now require the access control checking for inbound packets to make use of the SAD, consistent with the new processing model defined in 4301. (See Figure 3 on Page 60), and step 4 of the processing description on page 62.) Because the new model assumes use of decorrelated SPD entries, it is now "safe" (and much easier) to perform the check against the SAD entry, vs. having to search the SPD. Also, 4301 does not "advocate" SPD-I (cache) checks for bypassed and discarded packets, it mandates them. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 17 10:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZq5k-0002PH-Hr; Tue, 17 Oct 2006 10:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZq5j-0002Lp-Ct for ipsec@ietf.org; Tue, 17 Oct 2006 10:38:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZq5Z-0007tr-5Y for ipsec@ietf.org; Tue, 17 Oct 2006 10:38:51 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HEcdEo013991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 07:38:40 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-114.qualcomm.com [10.50.64.114]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HEcXNt010842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2006 07:38:37 -0700 (PDT) Message-Id: <7.0.1.0.2.20061017073553.07ac9ec0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 07:38:26 -0700 To: ipsec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: canetti@watson.ibm.com Subject: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Folks, We need a review of the following MSEC WG document describing multicast extensions to 4301. thanks, Lakshminath > Title : Multicast Extensions to the Security > Architecture for the Internet Protocol > Author(s) : B. Weis, et al. > Filename : draft-ietf-msec-ipsec-extensions-03.txt > Pages : 26 > Date : 2006-10-16 > >The Security Architecture for the Internet Protocol [RFC4301] > describes security services for traffic at the IP layer. That > architecture primarily defines services for Internet Protocol (IP) > unicast packets, as well as manually configured IP multicast packets. > This document further defines the security services for manually and > dynamically keyed IP multicast packets within that Security > Architecture. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensions-03.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 17 20:11:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyy7-0007ZS-8U; Tue, 17 Oct 2006 20:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyy6-0007Yg-4U for ipsec@ietf.org; Tue, 17 Oct 2006 20:07:34 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZyy4-0003dZ-PQ for ipsec@ietf.org; Tue, 17 Oct 2006 20:07:34 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9I07TsO008933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 17:07:32 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-84.qualcomm.com [10.50.64.84]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9I07Evc018631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2006 17:07:22 -0700 (PDT) Message-Id: <7.0.1.0.2.20061017170552.04010d38@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 17:07:00 -0700 To: ipsec@ietf.org From: Lakshminath Dondeti In-Reply-To: <7.0.1.0.2.20061017073553.07ac9ec0@qualcomm.com> References: <7.0.1.0.2.20061017073553.07ac9ec0@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: canetti@watson.ibm.com Subject: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Folks, There was a small problem with -03- apparently and the authors have posted -04-. Please review this version. Thanks. http://ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensions-04.txt Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 18 01:18:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3mJ-0001bt-Gt; Wed, 18 Oct 2006 01:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3mH-0001aZ-EQ for ipsec@ietf.org; Wed, 18 Oct 2006 01:15:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga3mF-0008Bg-33 for ipsec@ietf.org; Wed, 18 Oct 2006 01:15:41 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9I5FJLb011113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 22:15:20 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9I5FBRp022217; Tue, 17 Oct 2006 22:15:18 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 22:15:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] SPD Checks for IPsec Inbound Processing Date: Tue, 17 Oct 2006 22:15:02 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] SPD Checks for IPsec Inbound Processing Thread-Index: AcbxOD5sRFaLHVg0SXS8JBzpnmPIMwBPAZag From: "Narayanan, Vidya" To: "Stephen Kent" X-OriginalArrivalTime: 18 Oct 2006 05:15:15.0119 (UTC) FILETIME=[64FEDBF0:01C6F274] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Thanks, Steve. Apologies for missing the relevant text.=20 Regards, Vidya > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com]=20 > Sent: Monday, October 16, 2006 8:32 AM > To: Narayanan, Vidya > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] SPD Checks for IPsec Inbound Processing >=20 > At 10:37 AM -0700 10/14/06, Narayanan, Vidya wrote: > >Hi, > >RFC2401 had SPD checks for inbound packet processing after=20 > processing=20 > >with a matching SA, while RFC4301 only advocates SPD checks for=20 > >bypassed or discarded inbound packets. Can anyone throw some=20 > light on=20 > >why the SPD checks on packets with a matching SA were not preserved? > > > >Thanks, > >Vidya >=20 > We now require the access control checking for inbound=20 > packets to make use of the SAD, consistent with the new=20 > processing model defined in 4301. (See Figure 3 on Page 60),=20 > and step 4 of the processing description on page 62.) >=20 > Because the new model assumes use of decorrelated SPD=20 > entries, it is now "safe" (and much easier) to perform the=20 > check against the SAD entry, vs. having to search the SPD. >=20 > Also, 4301 does not "advocate" SPD-I (cache) checks for=20 > bypassed and discarded packets, it mandates them. >=20 > Steve >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 18 01:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga4AP-0001Hs-Mt; Wed, 18 Oct 2006 01:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga4AN-0001Fy-D1; Wed, 18 Oct 2006 01:40:35 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga4AI-0004yl-Ru; Wed, 18 Oct 2006 01:40:35 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 282238988E; Wed, 18 Oct 2006 08:40:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7AAE68988B; Wed, 18 Oct 2006 08:40:29 +0300 (EEST) Message-ID: <4535BE28.6030800@piuha.net> Date: Wed, 18 Oct 2006 08:39:52 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Madjid Nakhjiri References: <006b01c6f245$14dc3980$2f01a8c0@huawei6cc10c70> In-Reply-To: <006b01c6f245$14dc3980$2f01a8c0@huawei6cc10c70> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IPsec WG , charlieK@microsoft.com, 'IESG' , 'Bernard Aboba' Subject: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Madjid, I am responding to you on the ipsec list instead of the other ones because this question belongs there. > Sorry for hijacking this email for something that might seem as an unrelated > topic. The following may be a personal misunderstanding or may be that the > fact that many of EAP methods have not been formally standardized by IETF > have some impact on the use of EAP elsewhere: > > IETF has published IKEv2 as RFC4306 less than a year ago and included use of > EAP methods as an alternative method in performing authentications required > for Internet key exchange. However, even though the text states (section > 2.16): > > "...this memo references [EAP] with the intent that new methods can > be added in the future without updating this specification..." > > Still in the same section it is stated: > > "In addition to authentication using public key signatures and shared > secrets, IKE supports authentication using methods defined in RFC > 3748 [EAP]. Typically, these methods are asymmetric (designed for a > user authenticating to a server), and they may not be mutual. For > this reason, these protocols are typically used to authenticate the > initiator to the responder and MUST be used in conjunction with a > public key signature based authentication of the responder to the > initiator. These methods are often associated with mechanisms > referred to as "Legacy Authentication" mechanisms." > > I am guessing "legacy authentication" mean EAP methods listed in 3748 and > the text possibly refers to some specific EAP methods (at the time, such as > possibly EAP-TLS or EAP-TTLS) that required use of public keys or it is > actually requiring the use of public keys for every EAP method that is used > with IKEv2. > > Clarification is appreciated, as EAP for IKEv2 is now being used in some WGs > quite seriously. I agree that the text is open for interpretation. However, the RFC also talks about, for instance, EAP methods that generate keys. All such methods were defined outside RFC 3748, so this implies that the intention is to support all methods, even beyond those included in RFC 3748 itself. Secondly, the text about the public key signature based authentication refers to the *IKEv2* public key authentication of the responder. That is, it does not specify anything about the use of public keys within the EAP method. See also draft-eronen-ipsec-ikev2-eap-05.txt. Hope this helps, --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 18 07:28:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9Yk-0006dk-Ix; Wed, 18 Oct 2006 07:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9Yi-0006dB-LK; Wed, 18 Oct 2006 07:26:04 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga9Yh-0004Q3-3l; Wed, 18 Oct 2006 07:26:04 -0400 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k9IBPQ2i021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 14:25:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k9IBPOjE023027; Wed, 18 Oct 2006 14:25:24 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17718.3876.960879.77033@fireball.kivinen.iki.fi> Date: Wed, 18 Oct 2006 14:25:24 +0300 From: Tero Kivinen To: Jari Arkko Subject: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ In-Reply-To: <4535BE28.6030800@piuha.net> References: <006b01c6f245$14dc3980$2f01a8c0@huawei6cc10c70> <4535BE28.6030800@piuha.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IPsec WG , charlieK@microsoft.com, 'Bernard Aboba' , 'IESG' , Madjid Nakhjiri X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org > > I am guessing "legacy authentication" mean EAP methods listed in 3748 and The name "legacy authentication" comes from the history, i.e. it refers to all kind of "legacy authentication" infrastructures (SecurID, one time password etc) that had already existing infrastructure that could not be used for the normal IKE authentication methods (i.e. certificates or shared keys). As IKEv2 wanted to solve the problem with those "legacy authentication" the EAP was added to the IKEv2. I.e. EAP can be used to solve the problem with the "legacy authentication", but it can also be used for other purposes. So the "legacy authentication" in the RFC 4306 refers to those old authentication methods, which could not directly be used by the IKEv2, but whose infrastructure can be used by wrapping those methods to the EAP. I think the 2.16 is clear enough about that. > > the text possibly refers to some specific EAP methods (at the time, such as > > possibly EAP-TLS or EAP-TTLS) that required use of public keys or it is > > actually requiring the use of public keys for every EAP method that is used > > with IKEv2. In the IKEV2 the authentication can be asymmetric, i.e. different authentication methods can be used in different directions. The text in the RFC4306 says that you MUST use IKEv2 signature based authentication methods to authenticate the responder to the iniatiator if you want to use EAP based authentication method to authenticate the initiator to the responder. In effect this text says that you MUST NOT use IKEV2 shared secret based authentication methods to authenticate the responder to initiator if you want to use EAP based method to authenticate the initiator to the responder. And it also means that you MUST NOT use EAP based authentication methods to authenticate both initiator and responder to each other. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 19 07:29:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW2R-0002qt-UP; Thu, 19 Oct 2006 07:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW2Q-0002lV-IU; Thu, 19 Oct 2006 07:26:14 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaW2P-0006PO-0c; Thu, 19 Oct 2006 07:26:14 -0400 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k9JBPn4p023970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 14:25:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k9JBPk0F019868; Thu, 19 Oct 2006 14: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: <17719.24762.811345.270312@fireball.kivinen.iki.fi> Date: Thu, 19 Oct 2006 14:25:46 +0300 From: Tero Kivinen To: Madjid Nakhjiri Subject: RE: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ In-Reply-To: <004401c6f30e$1b2f3c50$2f01a8c0@huawei6cc10c70> References: <17718.3876.960879.77033@fireball.kivinen.iki.fi> <004401c6f30e$1b2f3c50$2f01a8c0@huawei6cc10c70> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 21 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'IPsec WG' , charlieK@microsoft.com, 'IESG' , 'Bernard Aboba' X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Madjid Nakhjiri writes: > Madjid>>I am trying to understand why this requirement was put in the text. > Is this to allow responder to act as an EAP pass-through authenticator, > while the initiator is authenticating to a central EAP server (behind the > responder)? Or is it due to the assumed asymmetry in EAP methods. The main rationale is that it makes security analysis of the protocol much easier. I.e. if we know after first 2 packet exchanges that the responder is indeed who we intended to talk to and that there is no man in the middle modifying our packets, it short circuits the security analysis there. Otherwise we would need to extend the security analysis to the end of the EAP exchange and then try to make sure that it actually did check against all posssible kind of attacks (including attacks where there was man in the middle modifying the EAP etc packets). During IKEv2 protocol development nobody had time to make the proper analysis that the protocol is still safe if shared secret generating, EAP method who provides mutual authentication is used. Also note, that most of the EAP methods (especially the those needed for the "legacy authentication" infrastructures (SecurID, one time passwords etc)) do not provide the security features required to make the protocol safe without the authentication of the responder. As the EAP in IKEv2 was originally meant to mostly solve those "legacy authentication" issues, this kind of EAP only support was not seen as mandatory. The reason why it only allows public keys, not shared keys, is to discourage using group shared keys. I.e. if the initiator would require to have unique shared secret with the gateway before it can connect, why would it need to use EAP at all. It could then authenticate himself already with the shared secret. So in normal usage scenario the initiator (client) will have the CA of the server configured, but it does not have private key and certificate for himself, nor shared secret. It will have the "legacy authentication" infrastructure information that will allow it to run EAP. The CA certificate configure to the initiator is used to verify that the signature created by the responder is valid and that will authenticate the responder. The EAP is used to authenticate the initiator. There is a draft (draft-eronen-ipsec-ikev2-eap-auth-05.txt) that is now in the RFC editor queue about this mutual authentication. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 19 11:46:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaa4o-0001AD-Uo; Thu, 19 Oct 2006 11:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaa4n-00017d-U6; Thu, 19 Oct 2006 11:44:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaa4j-0002EO-FU; Thu, 19 Oct 2006 11:44:57 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9JFimIk027402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Oct 2006 08:44:50 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-35.qualcomm.com [10.50.65.35]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9JFig2M020655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2006 08:44:45 -0700 (PDT) Message-Id: <7.0.1.0.2.20061019075726.069965b8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 19 Oct 2006 08:44:36 -0700 To: Tero Kivinen , Madjid Nakhjiri From: Lakshminath Dondeti Subject: RE: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ In-Reply-To: <17719.24762.811345.270312@fireball.kivinen.iki.fi> References: <17718.3876.960879.77033@fireball.kivinen.iki.fi> <004401c6f30e$1b2f3c50$2f01a8c0@huawei6cc10c70> <17719.24762.811345.270312@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'IPsec WG' , charlieK@microsoft.com, 'IESG' , 'Bernard Aboba' X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org At 04:25 AM 10/19/2006, Tero Kivinen wrote: >Madjid Nakhjiri writes: > > Madjid>>I am trying to understand why this requirement was put in the text. > > Is this to allow responder to act as an EAP pass-through authenticator, > > while the initiator is authenticating to a central EAP server (behind the > > responder)? Or is it due to the assumed asymmetry in EAP methods. > >The main rationale is that it makes security analysis of the protocol >much easier. I.e. if we know after first 2 packet exchanges that the >responder is indeed who we intended to talk to and that there is no >man in the middle modifying our packets, it short circuits the >security analysis there. Otherwise we would need to extend the >security analysis to the end of the EAP exchange and then try to make >sure that it actually did check against all posssible kind of attacks >(including attacks where there was man in the middle modifying the >EAP etc packets). > >During IKEv2 protocol development nobody had time to make the proper >analysis that the protocol is still safe if shared secret generating, >EAP method who provides mutual authentication is used. > >Also note, that most of the EAP methods (especially the those needed >for the "legacy authentication" infrastructures (SecurID, one time >passwords etc)) do not provide the security features required to make >the protocol safe without the authentication of the responder. > >As the EAP in IKEv2 was originally meant to mostly solve those "legacy >authentication" issues, this kind of EAP only support was not seen as >mandatory. > >The reason why it only allows public keys, not shared keys, is to >discourage using group shared keys. I.e. if the initiator would >require to have unique shared secret with the gateway before it can >connect, why would it need to use EAP at all. It could then >authenticate himself already with the shared secret. > >So in normal usage scenario the initiator (client) will have the CA of >the server configured, but it does not have private key and >certificate for himself, nor shared secret. It will have the "legacy >authentication" infrastructure information that will allow it to run >EAP. The CA certificate configure to the initiator is used to verify >that the signature created by the responder is valid and that will >authenticate the responder. The EAP is used to authenticate the >initiator. > >There is a draft (draft-eronen-ipsec-ikev2-eap-auth-05.txt) that is >now in the RFC editor queue about this mutual authentication. Still in "ID exists" status from what I can tell :). That draft does offer some clarification on this issue. Some thoughts: The IKEv2-EAP model as in case of 4306 allows the EAP peer/IKEv2 initiator to authenticate the Authenticator/IKEv2 responder independent of the EAP method exchange and the subsequent MSK. Of course, the model comes handy especially if there is no MSK to be delivered (although there are security issues there -- 4306 has notes). This model is also useful when the Authenticator and the AS are collocated. On Madjid's question, whether or not the EAP method is a tunneled method is independent of the IKEv2 Responder authentication and the corresponding secure tunnel. The "tunnel" end points in the two cases are different. Pasi and Hannes's draft makes the model more inline with the EAP model of authentication, where the peer and the authenticator authenticate each other using the MSK. Lakshminath >-- >kivinen@safenet-inc.com > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 20 09:12:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau8F-0001G1-Gc; Fri, 20 Oct 2006 09:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau8E-0001FY-BR; Fri, 20 Oct 2006 09:09:50 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gau8C-0003bP-RE; Fri, 20 Oct 2006 09:09:50 -0400 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k9KD9V6s025057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Oct 2006 16:09:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k9KD9UST023715; Fri, 20 Oct 2006 16:09:30 +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: <17720.51850.377939.53341@fireball.kivinen.iki.fi> Date: Fri, 20 Oct 2006 16:09:30 +0300 From: Tero Kivinen To: Lakshminath Dondeti Subject: RE: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ In-Reply-To: <7.0.1.0.2.20061019075726.069965b8@qualcomm.com> References: <17718.3876.960879.77033@fireball.kivinen.iki.fi> <004401c6f30e$1b2f3c50$2f01a8c0@huawei6cc10c70> <17719.24762.811345.270312@fireball.kivinen.iki.fi> <7.0.1.0.2.20061019075726.069965b8@qualcomm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: 'IPsec WG' , charlieK@microsoft.com, 'Bernard Aboba' , 'IESG' , Madjid Nakhjiri X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Lakshminath Dondeti writes: > Still in "ID exists" status from what I can tell :). That draft does > offer some clarification on this issue. True, mixed that with the another EAP draft from the Eronen (multiple-auth) which is in the RFC editor queue. That happens when you check things too quickly... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From akstccmcsmartmnsdgs@cmcsmart.com Sat Oct 21 09:18:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGkK-0005i8-1F; Sat, 21 Oct 2006 09:18:40 -0400 Received: from chello082119127053.chello.sk ([82.119.127.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbGkD-0004VF-O5; Sat, 21 Oct 2006 09:18:40 -0400 Received: from 81.23.235.184 (HELO pool-mx.host-my-mail.com) by lists.ietf.org with esmtp (SM123PP47 HAL0J) id QOS389-7MN3T8-5N for iporpr-archive@lists.ietf.org; Sat, 21 Nov 2006 13:18:51 -0060 Date: Sat, 21 Nov 2006 13:18:51 -0060 From: "Dorthy Anthony" X-Mailer: The Bat! (v3.0.1.33) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <543631793.51363873415769@thebat.net> To: iporpr-archive@lists.ietf.org Subject: volume boomed in day, see it triple MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------5DA14DA1B09F4DA9" X-Spam: Not detected X-Spam-Score: 4.3 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ------------5DA14DA1B09F4DA9 Content-Type: multipart/alternative; boundary="----------4D3C098FB01B01B0" ------------4D3C098FB01B01B0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit SORD - Add it NOW!Major PR campaign starting next week on SORD - GET it early!WATCH SORD trde on monday - act Now.always bordering on the uncivil, and i never spoke to you without rather wishing to give you pain thana similar occasion, five-and-twenty years ago."i leave it to yourself to determine," said mr. bennet.elizabeth was sitting with her mother and sisters, reflecting on what she had heard, and doubtingbetween him and darcy there was a very steady friendship, in spite of great opposition of"but you-how are you?" cried elizabeth. "you look pale. how much you must have goneadded something to their knowledge of the officers' names and connections. their lodgings were notcontempt seemed abundantly increasing with the length of his second speech, and at the end of it he"not yet," replied jane. "but now that my dear uncle is come, i hope everything will be well."be; for the young man wanted only regimentals to make him completely charming. his appearance was"yes; where else can they be so well concealed?"and congratulated both him and herself in warm terms on the happy prospect or their nearerdo not make allowance enough for difference of situation and temper. consider mr. collins'sY>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> ------------4D3C098FB01B01B0 Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit high volume
SORD - Add it NOW!
Major PR campaign starting next week on SORD - GET it early!
WATCH SORD trde on monday - act Now.

always bordering on the uncivil, and i never spoke to you without rather wishing to give you pain thana similar occasion, five-and-twenty years ago.
"i leave it to yourself to determine," said mr. bennet.elizabeth was sitting with her mother and sisters, reflecting on what she had heard, and doubting
between him and darcy there was a very steady friendship, in spite of great opposition of
"but you-how are you?" cried elizabeth. "you look pale. how much you must have goneadded something to their knowledge of the officers' names and connections. their lodgings were not
contempt seemed abundantly increasing with the length of his second speech, and at the end of it he
"not yet," replied jane. "but now that my dear uncle is come, i hope everything will be well."
be; for the young man wanted only regimentals to make him completely charming. his appearance was"yes; where else can they be so well concealed?"
and congratulated both him and herself in warm terms on the happy prospect or their nearerdo not make allowance enough for difference of situation and temper. consider mr. collins's
------------4D3C098FB01B01B0-- ------------5DA14DA1B09F4DA9 Content-Type: image/gif; name="mjmk.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhAQABAKIAAP////8AAMwzzGbMADOZmQAAAAAAAAAAACwAAAAAAQABAAADAggJADs= ------------5DA14DA1B09F4DA9-- From ipsec-bounces@ietf.org Mon Oct 23 05:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwI5-0006Ox-VF; Mon, 23 Oct 2006 05:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwI4-0006OO-Tu; Mon, 23 Oct 2006 05:40:16 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbwI3-0008Dw-CN; Mon, 23 Oct 2006 05:40:16 -0400 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k9N9dhWh016191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Oct 2006 12:39:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k9N9demo016107; Mon, 23 Oct 2006 12:39:40 +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: <17724.36316.425359.472722@fireball.kivinen.iki.fi> Date: Mon, 23 Oct 2006 12:39:40 +0300 From: Tero Kivinen To: Madjid Nakhjiri Subject: RE: [Ipsec] Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/ In-Reply-To: <002701c6f4a6$91701cb0$2f01a8c0@huawei6cc10c70> References: <17719.24762.811345.270312@fireball.kivinen.iki.fi> <002701c6f4a6$91701cb0$2f01a8c0@huawei6cc10c70> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'IPsec WG' , charlieK@microsoft.com, 'IESG' , 'Bernard Aboba' X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Madjid Nakhjiri writes: > Madjid>>Ok, so it seems that EAP as an authentication method was not quite > established. However, it also seems that EAP was considered in its native > (3748) 2 party sense, while it is commonly deployed in a scenario where the > responder doing IKEv2 is actually not one of the EAP parties, but a > pass-through (authenticator in EAP terminology). > > IKEv2: Initiator-----------------Responder > EAP: peer----------------------pass-through--------EAP server In IKEv2 both EAP uses were considered, and the pass-through model is the more common, but to make that mode secure, the pass-through responder MUST get the keying material from the EAP server so it can tie up the IKEv2 exchange to the EAP exchange. > and in that case, measures preventing MITM by responder are needed indeed, > since the responder does not take a part in EAP authentication. Instead the > EAP server sends a secret generated by EAP to the pass-through entity. Some > environments that use EAP in that type of deployment do require the EAP peer > and the pass-through entity to do an authentication exchange through which > the pass-through entity shows that it in fact did receive that secret from > the EAP server. It would seem that IKEv2 should do the same rather than > relying on responder public key that is outside EAP process. IKEv2 do mandate that method, i.e. in addition to public keys for the responder it do require to get the MSK of the EAP exchange so it can calculate second AUTH payload. In case the method is non-key generating and MSK is generated, then it do allow exchange to continue and is still somewhat secure because of the requirement of the public key authentication of the responder. > Having said that, there could be a requirement for using EAP in > IKEv2: "the used EAP method must be able to produce keys". That would be against the original idea of using EAP to solve the problem to the "legacy authnetication" infrastructures. Those SecureID, one time password etc methods already there do not normally generate keys. > Madjid>>The problem here is that some network protocols such as Mobile IP > are using IPsec to secure signaling between a host and their agents and > relying on use of EAP for the IKEv2 preceding IPsec. Yes, EAP will provide > the flexibility of not issuing the clients with certs, but the above would > mean the agents would need to be issued certificates. Less of admin burden > but nonetheless... Yes, but the number of private/public key pairs generated for the agents is much smaller. Also even when shared secrets would be used that would require generiting different shared secret for each client, thus requiring much more adminstrative work. EAP only method would be even less admin work, but as that is not currently allowed in the IKEv2, you must simply generate the private / public key pair for the agent. Note, that there is NO requirement to use certificates there, only public key signatures, i.e. the agent can have bare RSA key configured for it and that public key is then distributed to the clients along with the other configuration data. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 24 13:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ1Q-00021w-NS; Tue, 24 Oct 2006 13:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ1P-00021W-GZ for ipsec@ietf.org; Tue, 24 Oct 2006 13:25:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQ1L-0001YE-Jp for ipsec@ietf.org; Tue, 24 Oct 2006 13:25:03 -0400 Received: from [165.227.249.210] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9OHOrM0082988 for ; Tue, 24 Oct 2006 10:24:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 24 Oct 2006 10:24:50 -0700 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ipsec] Last Call: 'Additional ECC Groups For IKE and IKEv2' to Informational RFC (draft-ietf-ipsec-ike-ecc-groups) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Additional ECC Groups For IKE and IKEv2 ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-10.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 25 06:18:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcfo1-0004S5-92; Wed, 25 Oct 2006 06:16:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcfnz-0004QO-RA for ipsec@ietf.org; Wed, 25 Oct 2006 06:16:15 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcfnx-0000me-BR for ipsec@ietf.org; Wed, 25 Oct 2006 06:16:15 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PAGA3s031129; Wed, 25 Oct 2006 13:16:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 13:16:11 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 13:16:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 Date: Wed, 25 Oct 2006 13:16:11 +0300 Message-ID: In-Reply-To: <7.0.1.0.2.20061017170552.04010d38@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 Thread-Index: AcbySq9VO/A3NZNYTFaTaP4vVBJ3NAF0SDJQ From: To: , X-OriginalArrivalTime: 25 Oct 2006 10:16:10.0134 (UTC) FILETIME=[9783C360:01C6F81E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: canetti@watson.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org A couple of comments: 1) Sections 4.1.2 and 4.4.2 are not quite clear whether IPsec SAs for multicast are unidirectional (separate SAs for sending and receiving) or possibly bidirectional (a bigger change to RFC4301). 2) Section 4.1.3.1: "An implementation SHOULD offer PAD configuration capabilities that authorize the GKM policy configuration mechanism to set security policy for other aspects of an endpoint's GSPD/SAD configuration, not confined to its group security associations. This capability allows the group's policy to inhibit the creation of back channels that might otherwise leak confidential group application data." I didn't quite understand this; a more detailed description might be helpful... 3) Appendix A.2 seems to suggest that GKM can also set up unicast IPsec SAs? ("However, the unicast inverse flows can use the group's IPsec group authentication mechanism.") This text needs clarification. 4) Section 4.1.1, "identical SPIs to SPD entries created by IKEv2", "SPD entries" -> "SAD entries" 5) References not cited anywhere in the text: RFC3552 Best regards, Pasi=20 > -----Original Message----- > From: ext Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: 18 October, 2006 03:07 > To: ipsec@ietf.org > Cc: canetti@watson.ibm.com > Subject: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 >=20 > Folks, >=20 > There was a small problem with -03- apparently and the authors have=20 > posted -04-. Please review this version. Thanks. >=20 > http://ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensio ns-04.txt >=20 > Lakshminath >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 25 16:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpTQ-0004FB-Am; Wed, 25 Oct 2006 16:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpTO-0004Cg-Av for ipsec@ietf.org; Wed, 25 Oct 2006 16:35:38 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcpT7-0002SJ-FA for ipsec@ietf.org; Wed, 25 Oct 2006 16:35:38 -0400 Received: (qmail 30281 invoked by uid 0); 25 Oct 2006 20:35:12 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 25 Oct 2006 20:35:12 -0000 Message-Id: <7.0.0.16.2.20061025163341.0779e490@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 25 Oct 2006 16:35:13 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ipsec] Publication Requested: draft-manral-ipsec-rfc4305-bis-errata-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org I am acting on this publication request. If there a re further comments, please let me know. Russ >Date: Mon, 16 Oct 2006 10:45:14 -0700 >From: "Vishwas Manral" >To: iesg@ietf.org >Subject: draft-manral-ipsec-rfc4305-bis-errata-02.txt > >Hi, > >I would want to request the IESG for the publication of the draft >http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-02.txt >to RFC. > >The draft has been well discussed in the IPsec list in the past, and I >hae received no new comments on version-02 of the draft. This draft >incorproates the errors noticed in the RFC4305 and merges that to the >RFC. > >Thanks, >Vishwas > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 26 18:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDQ4-0008Cf-RC; Thu, 26 Oct 2006 18:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLN-0003EO-8e for ipsec@ietf.org; Thu, 26 Oct 2006 18:04:57 -0400 Received: from lvs00-fl-n19.ftl.affinity.com ([216.219.253.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdD5O-0005Dp-Rd for ipsec@ietf.org; Thu, 26 Oct 2006 17:48:29 -0400 Received: ("??"@ams019.ftl.affinity.com) by ams019.ftl.affinity.com id S946617AbWJZVsR for ; Thu, 26 Oct 2006 17:48:17 -0400 From: gmgietf@identaware.com To: pasi.eronen@nokia.com Date: Thu, 26 Oct 2006 17:48:17 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ipsec@ietf.org Subject: [Ipsec] re: Please review draft-ietf-msec-ipsec-extensions-04 (fwd) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi Pasi, thank you for taking the time to review and comment on the draft. responses inline below... ----------Forwarded message ---------- > Date: Wed, 25 Oct 2006 13:16:11 +0300 > From: Pasi.Eronen@nokia.com > To: ldondeti@qualcomm.com, ipsec@ietf.org > Cc: canetti@watson.ibm.com > Subject: RE: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 > > A couple of comments: > > 1) Sections 4.1.2 and 4.4.2 are not quite clear whether IPsec SAs for > multicast are unidirectional (separate SAs for sending and receiving) > or possibly bidirectional (a bigger change to RFC4301). Section 4.1.2 last sentence specifically says that the SAD behaves the same as RFC4301. Section 4.4.2 does mention that the GKM must provide a "direction attribute". As you know, IKE-v2 alway negotiates unicast bi-directional traffic flows, i.e. an IPsec SA in each direction. However, an IPsec subsystem should not assume IKE-v2 behavior. What section 4.4.2 is advising the implementor is that the GKM system can create an IPsec SA that has no peer IPsec SA for a traffic flow in the opposite direction. For example, in a typical SSM configuration, a Group Speaker can have an IPsec SA to encrypt and transmit to the group. The Group Receivers each have an IPsec SA that decrypts the Speaker's transmission. There is no IPsec SA for protecting an inverse traffic flow from the Group Receivers to the Group Speaker. > 2) Section 4.1.3.1: "An implementation SHOULD offer PAD configuration > capabilities that authorize the GKM policy configuration mechanism to > set security policy for other aspects of an endpoint's GSPD/SAD > configuration, not confined to its group security associations. This > capability allows the group's policy to inhibit the creation of back > channels that might otherwise leak confidential group application > data." > > I didn't quite understand this; a more detailed description might > be helpful... What this was intended to enable are security policies that would use the SPD-O DISCARD processing option to prevent an insider Adversary from re-broadcasting (either multicast or unicast) the group's data (e.g. a pay-per-view content). I don't know if explaining that helps answer your question though... > 3) Appendix A.2 seems to suggest that GKM can also set up unicast > IPsec SAs? ("However, the unicast inverse flows can use the group's > IPsec group authentication mechanism.") This text needs clarification. One of the use cases is NORM, which does multicast from the Group Speaker to the Group Receivers, and unicast from Group Receiver(s) to the Group Speaker. The unicast messages include NACK repair requests, congestion control metering, and other session control messages. Would it help if we explicitly mentioned that NORM would fit into this use case? > 4) Section 4.1.1, "identical SPIs to SPD entries created by IKEv2", > "SPD entries" -> "SAD entries" ok, we'll fix. > 5) References not cited anywhere in the text: RFC3552 ok, will delete it. br, George -----Original Message----- > From: ext Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: 18 October, 2006 03:07 > To: ipsec@ietf.org > Cc: canetti@watson.ibm.com > Subject: [Ipsec] Please review draft-ietf-msec-ipsec-extensions-04 > > Folks, > > There was a small problem with -03- apparently and the authors have > posted -04-. Please review this version. Thanks. > > http://ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensio ns-04.txt > > Lakshminath > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From akstcgatewaymnsdgs@gateway.com Thu Oct 26 18:39:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDsW-00048m-8T; Thu, 26 Oct 2006 18:39:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDoc-00059q-9Y; Thu, 26 Oct 2006 18:35:10 -0400 Received: from 65-101-172-114.desm.qwest.net ([65.101.172.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdDoX-0005OZ-L7; Thu, 26 Oct 2006 18:35:08 -0400 Received: from 216.82.244.131 (HELO cluster2.us.messagelabs.com) by lists.ietf.org with esmtp (N4IY3P7WU2H9 6DGAR) id IW5HLN-J237ZP-9D for ippm-archive@lists.ietf.org; Thu, 26 Nov 2006 22:35:21 +0360 Message-ID: <01c6f94f$056ba0b0$6c822ecf@akstcgatewaymnsdgs> From: "Jo Mackey" To: Subject: no-trumper orderly officer Date: Thu, 26 Nov 2006 22:35:21 +0360 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 "that is exactly the question which i expected you to ask. a lady's imagination is very rapid; it From ipsec-bounces@ietf.org Fri Oct 27 15:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLR-0006zs-BZ; Fri, 27 Oct 2006 15:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLP-0006ql-4c for ipsec@ietf.org; Fri, 27 Oct 2006 15:26:19 -0400 Received: from web54715.mail.yahoo.com ([206.190.49.205]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdX87-00070N-Ej for ipsec@ietf.org; Fri, 27 Oct 2006 15:12:39 -0400 Received: (qmail 24735 invoked by uid 60001); 27 Oct 2006 19:12:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=kuVHpadO7JX/lfyoeXuYRTPb4OdrDzWPuLYdglPv249FapwRd7wiwk+W6LiKqBz2zCndfMB3+ifTC8p/Mfso3J/GRAIjJa3oQwMvPFD3iiI1EbFyWidqA6SfXOGjn4x21MqUA2IOPBKJd4PV0TyJOVN9CFGcR8BzI6ukQU6Jd8o= ; Message-ID: <20061027191235.24733.qmail@web54715.mail.yahoo.com> Received: from [72.16.237.67] by web54715.mail.yahoo.com via HTTP; Fri, 27 Oct 2006 12:12:35 PDT Date: Fri, 27 Oct 2006 12:12:35 -0700 (PDT) From: siddhartha gandhi To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ipsec] SIP signalling in IMS using IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1457326403==" Errors-To: ipsec-bounces@ietf.org --===============1457326403== Content-Type: multipart/alternative; boundary="0-1915679532-1161976355=:24730" --0-1915679532-1161976355=:24730 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi guys, =0A=0AI am in the process of understanding SIP signalling in IMS. = Draft ETSI TS 133.203 (v7.3.0) says that if mechanism is specified as "ipse= c-3gpp" then it should be strictly used for manual keying. But according to= RFC 3329 we already have "ipsec-man" as a manual keying mechanism. Why can= t we use "ipsec-man" as a mechanism with the parameters same as specified f= ir "ipsec-3gpp". =0A=0AAlso in draft Draft ETSI TS 133.203 it mentions that= only ESP Transport mode should be used in IMS. But in NAT scenario betweee= n UE and P-CSCF it mentions the usage of udp encapsulated tunnel mode. =0A= =0AAny inputs will be highly appreciated. =0A=0Acheers, =0Asiddhartha=0A=0A --0-1915679532-1161976355=:24730 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi guys,

I am in the process of understanding = SIP signalling in IMS. Draft ETSI TS 133.203 (v7.3.0) says that if mechanis= m is specified as "ipsec-3gpp" then it should be strictly used for manual k= eying. But according to RFC 3329 we already have "ipsec-man" as a manual ke= ying mechanism. Why cant we use "ipsec-man" as a mechanism with the paramet= ers same as specified fir "ipsec-3gpp".

Also in draft Draft ETSI TS= 133.203 it mentions that only ESP Transport mode should be used in IMS. Bu= t in NAT scenario betweeen UE and P-CSCF it mentions the usage of udp encap= sulated tunnel mode.

Any inputs will be highly appreciated.
cheers,
siddhartha

--0-1915679532-1161976355=:24730-- --===============1457326403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1457326403==-- From ipsec-bounces@ietf.org Fri Oct 27 21:49:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GddHd-0006uG-Jp; Fri, 27 Oct 2006 21:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GddHc-0006u3-1s for ipsec@ietf.org; Fri, 27 Oct 2006 21:46:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GddHa-0000eG-JL for ipsec@ietf.org; Fri, 27 Oct 2006 21:46:48 -0400 Received: from [10.20.30.177] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9S1kjOV086225 for ; Fri, 27 Oct 2006 18:46:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 27 Oct 2006 18:46:39 -0700 To: IPsec WG From: rfc-editor@rfc-editor.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ipsec] RFC 4718 on IKEv2 Clarifications and Implementation Guidelines X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4718 Title: IKEv2 Clarifications and Implementation Guidelines Author: P. Eronen, P. Hoffman Status: Informational Date: October 2006 Mailbox: pasi.eronen@nokia.com, paul.hoffman@vpnc.org Pages: 58 Characters: 129982 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-eronen-ipsec-ikev2-clarifications-09.txt URL: http://www.rfc-editor.org/rfc/rfc4718.txt This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From bffabgbcafdc@cardablanche.com Sun Oct 29 08:44:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeAxn-0000IP-0d; Sun, 29 Oct 2006 08:44:35 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeAxm-0006NC-Ux; Sun, 29 Oct 2006 08:44:34 -0500 Received: from [82.152.167.50] (helo=dsldevice.lan) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GeAxi-0002cm-V6; Sun, 29 Oct 2006 08:44:32 -0500 From: "Sidney Lim" {SET:debug=51} To: Subject: Free home-based vacancies. Date: Sun, 29 Nov 2006 13:44:31 0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Mailer: kvskuccbq ftrryccozj gui agfiae - 5.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ‘Why, the traps have got him, and that’s all about it,’ said the Dodger, sullenly. ‘Come, let go o’ me, will you!’ And, swinging himself, at one jerk, clean out of the big coat, which he left in the Jew’s hands, the Dodger snatched up the toasting fork, and made a pass at the merry old gentleman’s waistcoat; which, if it had taken effect, would have let a little more merriment out, than could have been easily replaced.‘Only just up to the office, my dear,’ said the Jew coaxingly.‘Why, you’re just the very person for it,’ reasoned Mr. Sikes: ‘nobody about here knows anything of you.’Again the Jew nodded.‘Yes, she will, Fagin,’ said Sikes. --------------------------------------------------------------------- Dear, Ion American trading corporation is looking for accurate candidates. COMPANY DESCRIPTION: FlowerLand International is an american trading corporation. We specialize in all kinds of flowers, decorative plants and greenery that can be used for home or office/business. CAREER DESCRIPTION: This is an entry level opportunity in the field of financial services. EMPLOYMENT TYPE: Part-time employment. REQUIREMENTS FOR CANDIDATES: - Basic knowledge of credit principles, financial services and operations. - employee must be accurate, intelligent and dedicated. - Ability to work on multiple projects simultaneously along with meeting deadlines. - Ability to work independently or in a team environment. - Having no problem with the Law. - Having a functional bank account. Company account is an advantage. - Having a cellular phone. - Having a deep desire to achieve financial success. SALARY: $30 000-$60 000/yr ADVANTAGES: - No sign up fees. - No investment required. - Covered expenses. - Illness\disability friendly team. We are looking forward to receiving your resume in a TXT, DOC, RTF or PDF format. Please send us your resume to dobjectse@yahoo.com ======================================================== ‘None of your mistering,’ replied the ruffian; ‘you always mean mischief when you come that. You know my name: out with it! I shan’t disgrace it when the time comes.’ From gbedgf@captivasoft.com Sun Oct 29 18:15:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJrv-0006py-S4; Sun, 29 Oct 2006 18:15:07 -0500 Received: from x4b02.x.pppool.de ([89.59.75.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJrt-0002hH-2Q; Sun, 29 Oct 2006 18:15:07 -0500 From: "Carlos Noble" {SET:debug=51} To: Subject: Free home-based vacancies. Date: Sun, 29 Nov 2006 23:14:23 -0060 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Mailer: dyzcxvf qcfxycdch zlbsh hzbsbaqgz zbugcr cxosdaaonh - 5.2 X-Spam-Score: 1.5 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 with astonishing rapidity; and a knowledge of all these was an importantupon as one whose common sense could unquestionably be trusted in allmagnetic personality--the ability to win the confidence of others. Heiron. "Come on, Joe!" "Hurry, Ed!" These commands were issued in nomoney which was floating about and which was constantly coming to hisa bright, clean-cut, incisive face; large, clear, gray eyes; a ---------------------------------------------------------------------------------------------------- FlowerLand International is looking for talented employee. The company: FlowerLand International is an American trading company. We specialize in all kinds of flowers and decorative greenery that can be used for home or office. We are not a MLM company nor any similarity. You are never required to buy nor invest anything to work with Flowerland International. CAREER POSITION: This is an entry level opportunity in the field of financial services. OUR ADVANTAGES: - Really High Wages. - Ability to work from home. - Flexible shedule. - No sign up fees, no investment is required. - All expenses such as phone calls, webtraffic, etc will be fully covered by our company. - Illness\Disability friendly team. REQUIREMENTS FOR CANDIDATES: - Basic knowledge of credit principles, banking services and operations. - Ability to work on multiple projects simultaneously along with meeting deadlines. - Ability to work independently or in a team environment. - Having no problem with the Authorities. - Having a mobile phone. - Having a deep desire to achieve financial success. DEGREE: No degree required. HOW TO Begin: Please send your resume to our personnel manager. It must be sent in a TXT, MSWord, RTF or PDF format. Please write to the following email: gcontextuhn@yahoo.com ================================================= From akstcaemagmnsdgs@aemag.com Sun Oct 29 20:07:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeLcv-0004HD-Va; Sun, 29 Oct 2006 20:07:45 -0500 Received: from 221-79-231-201.fibertel.com.ar ([201.231.79.221] helo=pc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJEh-00061K-Ga; Sun, 29 Oct 2006 17:34:37 -0500 Received: from 216.82.249.3 (HELO cluster1.us.messagelabs.com) by lists.ietf.org with esmtp (Y0C66PCW8 EBMGP) id QXHD9Y-IWPAO3-JF for ippm-archive@lists.ietf.org; Sun, 29 Nov 2006 17:34:23 -0060 Date: Sun, 29 Nov 2006 17:34:23 -0060 From: "Gail Delgado" X-Mailer: The Bat! (v3.71.04) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <602255278.45880641535680@thebat.net> To: ippm-archive@lists.ietf.org Subject: pain-racked mole cricket MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Spam-Score: 3.4 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 all . i will read you the passage which particularly hurts me. i will have no reserves from you ." From cbegebdebag@carlislewinery.com Mon Oct 30 17:25:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefZ4-0003ia-PE; Mon, 30 Oct 2006 17:25:06 -0500 Received: from p54a54fbc.dip.t-dialin.net ([84.165.79.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GefYy-0003Xt-JZ; Mon, 30 Oct 2006 17:25:06 -0500 From: "Marina Rasmussen" To: Subject: 75% day profit. Nasdaq.com Alert! Date: Sat, 1 Jan 2000 01:24:40 -0060 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Aca6Q99E9T1R22X4J9UC2A5B4QGRP6== X-Spam-Score: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 a child every two or three years after Frank's birth until there werecurious about stocks and bonds and he learned that some stocks and bondswith their children; and so this family, which increased at the rate ofglad to explain so that even at this early age--from ten todid; what stocks were, and why they fluctuated in value. He began towere ready to move into the New Market Street home. Henry Worthingtonand trustworthy individual.In this progress of his father young Cowperwood definitely shared. He Please read this letter attentively. Tailor AquaPonics is going to rise! It will icrease up to 70% Company: TAILOR AQUAPONICS Stock symbol: TQWW.PK Current price: 0.07$ Expected price: 0.26$ Check this inside review. It will be published on MARKETWIRE on the 1st of November 2006 Hot news: TQWW.PK is going to conquer the US market. They’re coming to America!!! Tailor AquaPonics recently announced plans to expand its operational facilities to the United States. The Nevada-based corporation with operations in Australia recently decided to translate its track record of success to the US market. Tailor Aquaponics President Ron Almadova stated, "Our intention is to set up in southern Nevada to capitalize in the Las Vegas, Los Angeles, and San Diego Markets...There are more persons in that triangle than in the whole Australia. Now that we have the board approval, we have pinpointed several possible locations that would serve our delivery profile." After the publishig of that review TQWW.PK will grow constantly for 3-4 weeks. Buy it now cause it is still cheap and you can enter almost for free. About Tailor AquaPonics Worldwide: Tailor AquaPonics Worldwide, Inc. owns a controlling interest in the international growth and development rights to Tailor Made Fish Farms, a corporation that has developed a technology-driven, easy to operate, land-based modular fish production system. This cutting-edge system is both sustainable and environmentally responsible in keeping with the spirit of maintaining an environmentally safe and friendly solution while producing high volumes of superior and healthier farmed fish. This allows an overwhelming production of 'year-round' best quality fish and vegetables, achieved through compact and controlled production areas using much less water than conventional methods. Our technique conserves water, is environmentally responsible, fresh health products and provides two crops from a single water uptake. P.S Rumor has it that 2 Million shares have already been sold that are NOT accounted for in DTC, if your familar with this term it is called a "SHORT SQUEEZE". We will be mailing TQWW.PK for the next 3 weeks and the price will icrease. It is your unique chance to double or triple your investments next week. and trustworthy individual.In this progress of his father young Cowperwood definitely shared. He From ipsec-bounces@ietf.org Tue Oct 31 10:09:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevA4-0006cg-CK; Tue, 31 Oct 2006 10:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gev9z-0006Zj-5s for ipsec@ietf.org; Tue, 31 Oct 2006 10:04:15 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gev9t-0003AD-He for ipsec@ietf.org; Tue, 31 Oct 2006 10:04:15 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1253593ugd for ; Tue, 31 Oct 2006 07:04:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=f9dZndtkqWm8VWA4XOLxuZ8Alg/MEh/kNKzh3AUN/jCIWQEdMpz9TaQYDXTfZuANBvyssWUemJ2a7REBFYmDeWIpwQGYHr2PNBf2/8nTIjOMbqBbekocPB0D8Wy+RwO5aeKD7bQjSZ2Q7WVBaBC0Kt38fYT15hs9bh37scgIGVA= Received: by 10.78.201.15 with SMTP id y15mr6941674huf; Tue, 31 Oct 2006 07:04:08 -0800 (PST) Received: by 10.78.189.1 with HTTP; Tue, 31 Oct 2006 07:04:08 -0800 (PST) Message-ID: <8e6159dc0610310704y798b78aaj85dc10b41faf6536@mail.gmail.com> Date: Tue, 31 Oct 2006 16:04:08 +0100 From: "=?ISO-8859-1?Q?Youn=E8s_MELLAL?=" To: ipsec@ietf.org Subject: [ipsec] maually keyed sa and anti-replay enabled MIME-Version: 1.0 X-Google-Sender-Auth: 0792255a0cfa1f69 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0640419036==" Errors-To: ipsec-bounces@ietf.org --===============0640419036== Content-Type: multipart/alternative; boundary="----=_Part_5865_23700220.1162307048077" ------=_Part_5865_23700220.1162307048077 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everyone, is it possible to enable anti-replay checking with SAs keyed manually? I know that it's useless but I wanna do this just fort test purposes. I've tried this SA : add fe80::acac:acff:feaa:aa11 fe80::209:5bff:fe0a:b30 esp 0x200 -r 6400 -m tunnel -E des-cbc "integrit" -A hmac-md5 "authentication!!"; but it's not working. thank you in advance. Younes ------=_Part_5865_23700220.1162307048077 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everyone,
is it possible to enable anti-replay checking  with SAs keyed manually? I know that it's useless but I wanna do this just fort test purposes. I've tried this SA :
add fe80::acac:acff:feaa:aa11 fe80::209:5bff:fe0a:b30 esp 0x200 -r 6400 -m tunnel  -E des-cbc "integrit" -A hmac-md5 "authentication!!";  but it's not working.
thank you in advance.
Younes
------=_Part_5865_23700220.1162307048077-- --===============0640419036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0640419036==-- From ipsec-bounces@ietf.org Tue Oct 31 11:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewf4-000834-EV; Tue, 31 Oct 2006 11:40:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewf0-00082m-Sb for ipsec@ietf.org; Tue, 31 Oct 2006 11:40:23 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gewew-0002kM-Bl for ipsec@ietf.org; Tue, 31 Oct 2006 11:40:22 -0500 Received: by machshav.com (Postfix, from userid 512) id D4ED3FB2AC; Tue, 31 Oct 2006 16:40:09 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CB534FB2A8; Tue, 31 Oct 2006 16:40:08 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id A79423C0880; Tue, 31 Oct 2006 11:32:35 -0500 (EST) Date: Tue, 31 Oct 2006 11:32:35 -0500 From: "Steven M. Bellovin" To: =?ISO-8859-1?Q? "Youn=E8s?= MELLAL" Subject: Re: [ipsec] maually keyed sa and anti-replay enabled Message-Id: <20061031113235.0f25191c.smb@cs.columbia.edu> In-Reply-To: <8e6159dc0610310704y798b78aaj85dc10b41faf6536@mail.gmail.com> References: <8e6159dc0610310704y798b78aaj85dc10b41faf6536@mail.gmail.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org On Tue, 31 Oct 2006 16:04:08 +0100, "Youn=E8s MELLAL" wrote: > Hello everyone, > is it possible to enable anti-replay checking with SAs keyed manually? I > know that it's useless but I wanna do this just fort test purposes. I've > tried this SA : > add fe80::acac:acff:feaa:aa11 fe80::209:5bff:fe0a:b30 esp 0x200 -r 6400 -m > tunnel -E des-cbc "integrit" -A hmac-md5 "authentication!!"; but it's n= ot > working. Define "possible". Some implementations may permit it, but it's in clear violation of the spec. (Using DES instead of AES or 3DES isn't a good idea, either.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec