From owner-ipsec@lists.tislabs.com Mon Nov 1 09:41:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27980; Mon, 1 Nov 1999 09:41:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20808 Mon, 1 Nov 1999 09:07:34 -0500 (EST) Message-Id: <4.1.19991029121401.00b83480@sj-email> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Oct 1999 12:25:49 -0700 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The next VPN Interoperability Workshop will be held January 9-14, 2000, at the Paradise Point Resort in San Diego, California. The Workshop is being sponsored by Cisco. The protocols being tested are: IPSec- IKE- CA IPComp L2TP over Transport-Mode IPSec CCP with MPPC and MPPE MS CHAP V2 EAP PPTP PPPoE PPPoATM L2TPoATM Another email will be sent to the mailing lists when the workshop application is available on the CIUG web site (www.ciug.org). Hotel reservations may be made by calling Paradise Point Resort at 800-344-2626. Please register under the Cisco VPN Workshop room block for the discounted rate of $140 per night (plus tax). Thanks, Anita From owner-ipsec@lists.tislabs.com Mon Nov 1 10:30:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28753; Mon, 1 Nov 1999 10:30:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21344 Mon, 1 Nov 1999 11:15:32 -0500 (EST) Message-ID: <381DBC60.F3ED9701@ennovatenetworks.com> Date: Mon, 01 Nov 1999 11:14:24 -0500 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: dfox@ennovatenetworks.com Subject: Phase 2 ID's for different VPN's with different Address Space Content-Type: multipart/mixed; boundary="------------E227A11859FBB4A389272A7C" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------E227A11859FBB4A389272A7C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have an interesting problem, and I am hoping that someone on the list can help with the solution. I am implementing a sgw that has many physical interfaces (T1, T3, etc.) to different private networks. Each private network has its own address space. A very simple architecture looks like this: VPN 1, site A VPN 1, site B -------+ +------+ +------+ +------- | | | | | | +--------+ | | +--------+ | GW A +----------+ GW B | +--------+ | | +--------+ | | | | | | -------+ +------+ +------+ +------- VPN 2, site A VPN 2, site B My thinking is, I do a phase 1 IKE between GW A and GW B. To set up the ESP tunnel for VPN 1, I do a phase 2 IKE between GW A and GW B, using PFS. I do another similar phase 2 exchange for VPN 2 to set up the ESP tunnel for this VPN. Question: how do I identify that my clients are a particular VPN? I can't use ID_IPV4_ADDR_SUBNET, since each VPN has its own address space. I could use ID_FQDN, but then I couldn't specify the IP addresses (plus it's ugly). What I'd really like is to specify a 32-bit VPN identifier, along with the IP subnet and transport port. Can I do this without defining new ID types? I could use ID_KEYID, but it really doesn't identify a key, and, of course, it wouldn't be interoperable. However, I will use this if this seems to be the preferred method. Any help would be greatly appreciated. --------------E227A11859FBB4A389272A7C Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-795-5405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------E227A11859FBB4A389272A7C-- From owner-ipsec@lists.tislabs.com Mon Nov 1 12:05:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00614; Mon, 1 Nov 1999 12:05:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21900 Mon, 1 Nov 1999 13:21:34 -0500 (EST) Message-ID: <000a01bf2494$9667ad80$11feffc2@lars> From: "Lars Schultz" To: Subject: IPSec Date: Mon, 1 Nov 1999 19:11:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BF249C.F7411940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF249C.F7411940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi We are implementing a vpn with IPSec. Our question is if IPSec is a protocol or is it a range of protocols. Thanks ------=_NextPart_000_0007_01BF249C.F7411940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
We are implementing a vpn with = IPSec. Our=20 question is
if IPSec is a protocol or is it a = range of=20 protocols.
 
Thanks
------=_NextPart_000_0007_01BF249C.F7411940-- From owner-ipsec@lists.tislabs.com Mon Nov 1 14:51:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02799; Mon, 1 Nov 1999 14:51:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22465 Mon, 1 Nov 1999 15:54:37 -0500 (EST) Message-ID: <381DFDEF.9A69EE35@ennovatenetworks.com> Date: Mon, 01 Nov 1999 15:54:08 -0500 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: dfox@ennovatenetworks.com, ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space References: <381DBC60.F3ED9701@ennovatenetworks.com> <381DD891.99F1EA00@redcreek.com> Content-Type: multipart/mixed; boundary="------------FBE5638FC4B835677CA17CE0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------FBE5638FC4B835677CA17CE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott, I thought of that, but I wanted to avoid having a different certificate for each VPN on each gateway. I also wanted to avoid having to do a separate phase one for each VPN. The number of VPN's I will need to support is large. But perhaps that's what I ought to do. Either that or go ahead and try to get new ID types defined. Thanks for your input. -Dan "Scott G. Kelly" wrote: > Hi Daniel, > > One way to accomplish what you ask is by using DNs as identifiers, each > with their own certs, one for each vpn group. > > Daniel Fox wrote: > > > > I have an interesting problem, and I am hoping that someone on the list > > can help with the solution. > > > > I am implementing a sgw that has many physical interfaces (T1, T3, etc.) > > to different private networks. Each private network has its own address > > space. A very simple architecture looks like this: > > > > VPN 1, site A VPN 1, site B > > -------+ +------+ +------+ +------- > > | | | | | | > > +--------+ | | +--------+ > > | GW A +----------+ GW B | > > +--------+ | | +--------+ > > | | | | | | > > -------+ +------+ +------+ +------- > > VPN 2, site A VPN 2, site B > > > > My thinking is, I do a phase 1 IKE between GW A and GW B. > > > > To set up the ESP tunnel for VPN 1, I do a phase 2 IKE between GW A and > > GW B, using PFS. I do another similar phase 2 exchange for VPN 2 to set > > up the ESP tunnel for this VPN. > > > > Question: how do I identify that my clients are a particular VPN? > > > > I can't use ID_IPV4_ADDR_SUBNET, since each VPN has its own address > > space. > > > > I could use ID_FQDN, but then I couldn't specify the IP addresses (plus > > it's ugly). What I'd really like is to specify a 32-bit VPN identifier, > > along with the IP subnet and transport port. Can I do this without > > defining new ID types? > > > > I could use ID_KEYID, but it really doesn't identify a key, and, of > > course, it wouldn't be interoperable. However, I will use this if this > > seems to be the preferred method. > > > > Any help would be greatly appreciated. --------------FBE5638FC4B835677CA17CE0 Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-795-5405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------FBE5638FC4B835677CA17CE0-- From owner-ipsec@lists.tislabs.com Mon Nov 1 14:57:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02867; Mon, 1 Nov 1999 14:57:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22558 Mon, 1 Nov 1999 16:28:51 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE5AD@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: IPSEc VPN Client for Apple Mac? Date: Mon, 1 Nov 1999 21:29:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there any IPSEC Client products for Apple O/S out there? Cheers, Steve. From owner-ipsec@lists.tislabs.com Mon Nov 1 15:51:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03442; Mon, 1 Nov 1999 15:51:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22727 Mon, 1 Nov 1999 17:24:44 -0500 (EST) Message-Id: <199911012225.OAA24094@potassium.network-alchemy.com> To: Daniel Fox cc: ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space In-reply-to: Your message of "Mon, 01 Nov 1999 11:14:24 EST." <381DBC60.F3ED9701@ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24091.941495111.1@network-alchemy.com> Date: Mon, 01 Nov 1999 14:25:11 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 01 Nov 1999 11:14:24 EST you wrote > > I have an interesting problem, and I am hoping that someone on the list > can help with the solution. > > I am implementing a sgw that has many physical interfaces (T1, T3, etc.) > to different private networks. Each private network has its own address > space. A very simple architecture looks like this: > > VPN 1, site A VPN 1, site B > -------+ +------+ +------+ +------- > | | | | | | > +--------+ | | +--------+ > | GW A +----------+ GW B | > +--------+ | | +--------+ > | | | | | | > -------+ +------+ +------+ +------- > VPN 2, site A VPN 2, site B > > My thinking is, I do a phase 1 IKE between GW A and GW B. > > To set up the ESP tunnel for VPN 1, I do a phase 2 IKE between GW A and > GW B, using PFS. I do another similar phase 2 exchange for VPN 2 to set > up the ESP tunnel for this VPN. > > Question: how do I identify that my clients are a particular VPN? > > I can't use ID_IPV4_ADDR_SUBNET, since each VPN has its own address > space. That should be fine. They're gonna be separate negotiations. Assuming that site A is initiating to site B, the first packet from VPN{1,2} will hit GWA who will queue it up and do a phase 1 IKE exchange with GWB. The ID used there depends on how you're authenticating. Then the phase 2 exchange happens. The IDs are constructed from the selector that the packet hit. So if your selector is from one subnet to another then they're both ID_IPV4_ADDR_SUBNET. If it's a subnet to a paricular host then the 1st is an ID_IPV4_ADDR_SUBNET and the 2nd one is a ID_IPV4_ADDR. When another packet for the other VPN hits the GWA it will do another phase 2 exchange and this one will be identified by the specifics of the particular selector that matched that packet which will necessarily be different than the specifics of the selector that matched the first packet. > I could use ID_FQDN, but then I couldn't specify the IP addresses (plus > it's ugly). What I'd really like is to specify a 32-bit VPN identifier, > along with the IP subnet and transport port. Can I do this without > defining new ID types? An ID_FQDN can't be used because it doesn't convey any addressing information, as you noted. ID_FQDN is intended for phase 1 exchanges. What is this VPN identifier? Where is that defined? IKE doesn't define VPNs so you can't specify that somebody is "in a VPN" using IKE. > I could use ID_KEYID, but it really doesn't identify a key, and, of > course, it wouldn't be interoperable. However, I will use this if this > seems to be the preferred method. ID_KEYID does identify a key but it too is for phase 1 exchanges. Whatever the parameters of an RFC2401 selector there are corresponding RFC2407/RFC2408 identities to use with RFC2409. In fact, it was limitations of the ID payload that caused the port range to be removed as an RFC2401 selector parameter. Hopefully the next rev of the documents will allow that to be added back. Dan. From owner-ipsec@lists.tislabs.com Mon Nov 1 16:33:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04092; Mon, 1 Nov 1999 16:33:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22808 Mon, 1 Nov 1999 18:05:05 -0500 (EST) Message-ID: <381E1CFA.AB7C8AF5@cyphers.net> Date: Mon, 01 Nov 1999 15:06:40 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Waters, Stephen" CC: ipsec@lists.tislabs.com Subject: Re: IPSEc VPN Client for Apple Mac? References: <29752A74B6C5D211A4920090273CA3DCCDE5AD@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are two that I'm aware of. PGP VPN is available for the Macintosh, currently at version 6.5.1. It supports PGP authentication, and X.509 authentication with Entrust, Verisign, and NetTools. It also supports shared secret. The freeware version for non-commercial use supports transport mode only and does not do X.509. The commercial version supports all of the above. TimeStep PERMIT/Client is also available for the Mac, but the last time I looked at it it was limited to shared secret auth. "Waters, Stephen" wrote: > > Are there any IPSEC Client products for Apple O/S out there? > > Cheers, Steve. - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5 iQA/AwUBOB4c6ay7FkvPc+xMEQIBrACePBhVqR24AS9OdL8H8urDbvOtdPcAoL7K ZUd6e/TydjPI7+pSgcmgO7fE =EtC9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 1 17:40:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05034; Mon, 1 Nov 1999 17:40:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22929 Mon, 1 Nov 1999 18:54:05 -0500 (EST) Date: Tue, 2 Nov 1999 00:56:43 +0100 From: Markus Friedl To: Ricky Charlet Cc: ipsec@lists.tislabs.com, Andrew Krywaniuk Subject: Re: Shared Secret mismatch in AM3/MM5 Message-ID: <19991102005643.A4946@folly.informatik.uni-erlangen.de> References: <319A1C5F94C8D11192DE00805FBBADDFEC8E1B@exchange> <38188EC5.D30BBAC0@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <38188EC5.D30BBAC0@redcreek.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Oct 28, 1999 at 05:58:29PM +0000, Ricky Charlet wrote: > Why is SKEYID defined that way? What were the > modivators? And specifically why is SKEYID not some direct derivation of > g^xy in all cases? Are there pointers to reference material? Please read the mailing list archive, reference material is: Message-Id: <199703250446.XAA49412@mailhub1.watson.ibm.com> Message-Id: <199709290728.KAA23246@ee.technion.ac.il> Content-ID: <11917.901560442.1@cisco.com> Message-ID: In <11917.901560442.1@cisco.com> Daniel Harkins wrote: > Hugo Krawczyk (a cryptographer) suggested the -02 to -03 key derivation > changes. His rationale was to _directly_ authenticate SKEYID. Therefore > information known only to the peers should be included in the computation. > For the encrypted nonce method of authentication, including the plain-text > nonces in SKEYID satisfies this; in pre-shared key authentication, including > the pre-shared key in SKEYID satisfies this. Signature based authentication > does not have anything known only to the peers and Hugo said that it is > weaker because of it. -markus From owner-ipsec@lists.tislabs.com Mon Nov 1 18:58:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07297; Mon, 1 Nov 1999 18:58:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23240 Mon, 1 Nov 1999 20:27:50 -0500 (EST) Message-Id: <199911020128.RAA00503@potassium.network-alchemy.com> To: Daniel Fox cc: ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space In-reply-to: Your message of "Mon, 01 Nov 1999 20:12:47 EST." <381E3A8F.C85CF59@ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <494.941506102.1@network-alchemy.com> Date: Mon, 01 Nov 1999 17:28:23 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I think the key here is "Each VPN has its own address space which may or may not overlap." In that case the answer is that there is no way to handle this using IPSec (today). At least I don't see a way. If you could rule out overlapping address space it would work the way I described; if you can't then I don't think there's an a way to do this which would guarantee interoperability. There's no concept of a VPN as a selector parameter. Dan. On Mon, 01 Nov 1999 20:12:47 EST you wrote > > Dan, > > Thanks for the reply. > > I think amending my architecture to include the subnets will clarify things. > > VPN 1, site A VPN 1, site B > ---------+ +------+ +------+ +--------- > 10.1/16 | | | | | | 10.2/16 > +--------+ | | +--------+ > | GW A +----------+ GW B | > +--------+ | | +--------+ > 10.1/16 | | | | | | 10.2/16 > ---------+ +------+ +------+ +--------- > VPN 2, site A VPN 2, site B > > Each VPN has its own address space which may or may not overlap. In the abov >e > example, VPN 1 has two sites with 10.1/16 subnet and 10.2/16 subnet. VPN 2 a >lso > has two sites, one with a 10.1/16 subnet, and the other a 10.2/16 subnet. (T >his > is a requirement as we don't want to mandate which addresses each VPN chooses > to > use). > > The first packet arrives from VPN1, site A (and I know this from the L2 inter >face > it uses), destined for VPN1, site B. > > GWA initiates phase 1 with GWB. They use DN ID's (because each has a certifi >cate) > for this phase. > > Then GWA initiates phase 2 with GWB. Let's say they use ID_IPV4_ADDR_SUBNET >for > both IDci and IDcr. Then IDci=10.1/16 and IDcr=10.2/16. When GWB sees the p >hase > 2 ID's, GWB has no way of knowing whether the ID's correspond to the address >space > of VPN1 or VPN2. Therefore, when GWB receives an ESP packet from GWA with th >e SPI > negotiated, GWB has no idea whether to forward the packet to VPN 1, site B or > VPN > 2, site B. > > I hope this make it clearer. Dan, does this change your answer? Or did I > misunderstand your answer? > > -Dan From owner-ipsec@lists.tislabs.com Mon Nov 1 19:37:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09548; Mon, 1 Nov 1999 19:37:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23429 Mon, 1 Nov 1999 21:19:53 -0500 (EST) Message-ID: From: Sankar Ramamoorthi To: "'Dan Harkins'" , Daniel Fox Cc: ipsec@lists.tislabs.com Subject: RE: Phase 2 ID's for different VPN's with different Address Space Date: Mon, 1 Nov 1999 18:22:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Would'nt VPNs with operlapping address space cause a problem only when the address spaces intersect on both ends? If they are just intersecting on one side then the address selectors should be able uniquely determine which vpn the phase2 exchange belongs to - right? Also in the diagram shown below, would'nt using identifiers of type IP_ADDRESS_RANGE solve the problem. Thanks, -- sankar -- -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Monday, November 01, 1999 5:28 PM To: Daniel Fox Cc: ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space Dan, I think the key here is "Each VPN has its own address space which may or may not overlap." In that case the answer is that there is no way to handle this using IPSec (today). At least I don't see a way. If you could rule out overlapping address space it would work the way I described; if you can't then I don't think there's an a way to do this which would guarantee interoperability. There's no concept of a VPN as a selector parameter. Dan. On Mon, 01 Nov 1999 20:12:47 EST you wrote > > Dan, > > Thanks for the reply. > > I think amending my architecture to include the subnets will clarify things. > > VPN 1, site A VPN 1, site B > ---------+ +------+ +------+ +--------- > 10.1/16 | | | | | | 10.2/16 > +--------+ | | +--------+ > | GW A +----------+ GW B | > +--------+ | | +--------+ > 10.1/16 | | | | | | 10.2/16 > ---------+ +------+ +------+ +--------- > VPN 2, site A VPN 2, site B > > Each VPN has its own address space which may or may not overlap. In the abov >e > example, VPN 1 has two sites with 10.1/16 subnet and 10.2/16 subnet. VPN 2 a >lso > has two sites, one with a 10.1/16 subnet, and the other a 10.2/16 subnet. (T >his > is a requirement as we don't want to mandate which addresses each VPN chooses > to > use). > > The first packet arrives from VPN1, site A (and I know this from the L2 inter >face > it uses), destined for VPN1, site B. > > GWA initiates phase 1 with GWB. They use DN ID's (because each has a certifi >cate) > for this phase. > > Then GWA initiates phase 2 with GWB. Let's say they use ID_IPV4_ADDR_SUBNET >for > both IDci and IDcr. Then IDci=10.1/16 and IDcr=10.2/16. When GWB sees the p >hase > 2 ID's, GWB has no way of knowing whether the ID's correspond to the address >space > of VPN1 or VPN2. Therefore, when GWB receives an ESP packet from GWA with th >e SPI > negotiated, GWB has no idea whether to forward the packet to VPN 1, site B or > VPN > 2, site B. > > I hope this make it clearer. Dan, does this change your answer? Or did I > misunderstand your answer? > > -Dan From owner-ipsec@lists.tislabs.com Mon Nov 1 19:47:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10260; Mon, 1 Nov 1999 19:47:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23177 Mon, 1 Nov 1999 20:14:01 -0500 (EST) Message-ID: <381E3A8F.C85CF59@ennovatenetworks.com> Date: Mon, 01 Nov 1999 20:12:47 -0500 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com, dfox@ennovatenetworks.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space References: <199911012225.OAA24094@potassium.network-alchemy.com> Content-Type: multipart/mixed; boundary="------------E0CDE56110652117BFE88357" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------E0CDE56110652117BFE88357 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan, Thanks for the reply. I think amending my architecture to include the subnets will clarify things. VPN 1, site A VPN 1, site B ---------+ +------+ +------+ +--------- 10.1/16 | | | | | | 10.2/16 +--------+ | | +--------+ | GW A +----------+ GW B | +--------+ | | +--------+ 10.1/16 | | | | | | 10.2/16 ---------+ +------+ +------+ +--------- VPN 2, site A VPN 2, site B Each VPN has its own address space which may or may not overlap. In the above example, VPN 1 has two sites with 10.1/16 subnet and 10.2/16 subnet. VPN 2 also has two sites, one with a 10.1/16 subnet, and the other a 10.2/16 subnet. (This is a requirement as we don't want to mandate which addresses each VPN chooses to use). The first packet arrives from VPN1, site A (and I know this from the L2 interface it uses), destined for VPN1, site B. GWA initiates phase 1 with GWB. They use DN ID's (because each has a certificate) for this phase. Then GWA initiates phase 2 with GWB. Let's say they use ID_IPV4_ADDR_SUBNET for both IDci and IDcr. Then IDci=10.1/16 and IDcr=10.2/16. When GWB sees the phase 2 ID's, GWB has no way of knowing whether the ID's correspond to the address space of VPN1 or VPN2. Therefore, when GWB receives an ESP packet from GWA with the SPI negotiated, GWB has no idea whether to forward the packet to VPN 1, site B or VPN 2, site B. I hope this make it clearer. Dan, does this change your answer? Or did I misunderstand your answer? -Dan Dan Harkins wrote: > On Mon, 01 Nov 1999 11:14:24 EST you wrote > > > > I have an interesting problem, and I am hoping that someone on the list > > can help with the solution. > > > > I am implementing a sgw that has many physical interfaces (T1, T3, etc.) > > to different private networks. Each private network has its own address > > space. A very simple architecture looks like this: > > > > VPN 1, site A VPN 1, site B > > -------+ +------+ +------+ +------- > > | | | | | | > > +--------+ | | +--------+ > > | GW A +----------+ GW B | > > +--------+ | | +--------+ > > | | | | | | > > -------+ +------+ +------+ +------- > > VPN 2, site A VPN 2, site B > > > > My thinking is, I do a phase 1 IKE between GW A and GW B. > > > > To set up the ESP tunnel for VPN 1, I do a phase 2 IKE between GW A and > > GW B, using PFS. I do another similar phase 2 exchange for VPN 2 to set > > up the ESP tunnel for this VPN. > > > > Question: how do I identify that my clients are a particular VPN? > > > > I can't use ID_IPV4_ADDR_SUBNET, since each VPN has its own address > > space. > > That should be fine. They're gonna be separate negotiations. Assuming that > site A is initiating to site B, the first packet from VPN{1,2} will hit > GWA who will queue it up and do a phase 1 IKE exchange with GWB. The ID > used there depends on how you're authenticating. Then the phase 2 exchange > happens. The IDs are constructed from the selector that the packet hit. > So if your selector is from one subnet to another then they're both > ID_IPV4_ADDR_SUBNET. If it's a subnet to a paricular host then the 1st > is an ID_IPV4_ADDR_SUBNET and the 2nd one is a ID_IPV4_ADDR. When another > packet for the other VPN hits the GWA it will do another phase 2 exchange > and this one will be identified by the specifics of the particular selector > that matched that packet which will necessarily be different than the > specifics of the selector that matched the first packet. > > > I could use ID_FQDN, but then I couldn't specify the IP addresses (plus > > it's ugly). What I'd really like is to specify a 32-bit VPN identifier, > > along with the IP subnet and transport port. Can I do this without > > defining new ID types? > > An ID_FQDN can't be used because it doesn't convey any addressing information, > as you noted. ID_FQDN is intended for phase 1 exchanges. > > What is this VPN identifier? Where is that defined? IKE doesn't define > VPNs so you can't specify that somebody is "in a VPN" using IKE. > > > I could use ID_KEYID, but it really doesn't identify a key, and, of > > course, it wouldn't be interoperable. However, I will use this if this > > seems to be the preferred method. > > ID_KEYID does identify a key but it too is for phase 1 exchanges. > > Whatever the parameters of an RFC2401 selector there are corresponding > RFC2407/RFC2408 identities to use with RFC2409. In fact, it was limitations > of the ID payload that caused the port range to be removed as an RFC2401 > selector parameter. Hopefully the next rev of the documents will allow > that to be added back. > > Dan. --------------E0CDE56110652117BFE88357 Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-795-5405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------E0CDE56110652117BFE88357-- From owner-ipsec@lists.tislabs.com Tue Nov 2 00:12:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22683; Tue, 2 Nov 1999 00:12:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24189 Tue, 2 Nov 1999 01:39:27 -0500 (EST) Message-ID: <381E77AB.70067E52@cs.stanford.edu> Date: Mon, 01 Nov 1999 21:33:46 -0800 From: Brian Korver X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: -ipsec-pki-req-03 - EKU's References: <38164C72.6E1A7A23@cs.stanford.edu> <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> <4.2.1.19991026092935.0302c5b0@mail.vpnc.org> <4.2.1.19991027150203.01c23a50@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman wrote: > > At 12:24 PM 10/27/99 +0200, Rodney Thayer wrote: > >Regarding the EKU discussion... > > > >I originally put in two kinds of EKU's -- one for end systems and > >one for intermediate systems. It is my opinion that you want to be > >able to label a certificate with this information: > > > > -- it's for IPsec > > -- it's for an end system (only this machine) > > -- it's for a gateway ("intermediate") system (it can do IPsec > > for packets it forwards > > Question to the group: is there a value for both the second and third > requirements? I have heard arguments both ways. Paul, Are you asking whether there is value in making the second and third mandatory in the spec? No surprise, but my vote is that all of them might have value in certain circumstances, but that none should be mandatory. > I think we need to require it in the profile so that there is a definitive > way for an IKE system to say "this cert can be used for IKE". Without such > a requirement, the IKE system has to make too many guesses that can lead to > lack of interoperability. We seem to be interoperating fine right now without EKU. ;) > I will play PKIX lawyer for a moment (even though I hear guffaws from the > peanut gallery). We can put this either in EKU or policy. There are many > folks in the PKIX WG who have argued (I think persuasively) that key usage > is a type of policy. Having said that, there is no advantage of one over > the other, so I think that we should leave whatever we do in EKU. Leaving it in the policy means less stuff to process in the certificate. In some environments that might be an advantage. > > I agree. > > --Paul Hoffman, Director > --VPN Consortium brian briank@cs.stanford.edu (play) briank@network-alchemy.com (work) From owner-ipsec@lists.tislabs.com Tue Nov 2 03:25:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00554; Tue, 2 Nov 1999 03:25:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA24673 Tue, 2 Nov 1999 04:38:20 -0500 (EST) Message-ID: <381EB1F6.5AFCF6FE@DataFellows.com> Date: Tue, 02 Nov 1999 11:42:14 +0200 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Daniel Fox , ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space References: <199911020128.RAA00503@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about using either SIT_SECRECY or SIT_INTEGRITY together with the secrecy/integrity category being either VPN1 or VPN2? Ari Dan Harkins wrote: > Dan, > > I think the key here is "Each VPN has its own address space which may > or may not overlap." In that case the answer is that there is no way > to handle this using IPSec (today). At least I don't see a way. If you > could rule out overlapping address space it would work the way I > described; if you can't then I don't think there's an a way to do this > which would guarantee interoperability. There's no concept of a VPN > as a selector parameter. > > Dan. > > On Mon, 01 Nov 1999 20:12:47 EST you wrote > > > > Dan, > > > > Thanks for the reply. > > > > I think amending my architecture to include the subnets will clarify things. > > > > VPN 1, site A VPN 1, site B > > ---------+ +------+ +------+ +--------- > > 10.1/16 | | | | | | 10.2/16 > > +--------+ | | +--------+ > > | GW A +----------+ GW B | > > +--------+ | | +--------+ > > 10.1/16 | | | | | | 10.2/16 > > ---------+ +------+ +------+ +--------- > > VPN 2, site A VPN 2, site B > > > > Each VPN has its own address space which may or may not overlap. In the abov > >e > > example, VPN 1 has two sites with 10.1/16 subnet and 10.2/16 subnet. VPN 2 a > >lso > > has two sites, one with a 10.1/16 subnet, and the other a 10.2/16 subnet. (T > >his > > is a requirement as we don't want to mandate which addresses each VPN chooses > > to > > use). > > > > The first packet arrives from VPN1, site A (and I know this from the L2 inter > >face > > it uses), destined for VPN1, site B. > > > > GWA initiates phase 1 with GWB. They use DN ID's (because each has a certifi > >cate) > > for this phase. > > > > Then GWA initiates phase 2 with GWB. Let's say they use ID_IPV4_ADDR_SUBNET > >for > > both IDci and IDcr. Then IDci=10.1/16 and IDcr=10.2/16. When GWB sees the p > >hase > > 2 ID's, GWB has no way of knowing whether the ID's correspond to the address > >space > > of VPN1 or VPN2. Therefore, when GWB receives an ESP packet from GWA with th > >e SPI > > negotiated, GWB has no idea whether to forward the packet to VPN 1, site B or > > VPN > > 2, site B. > > > > I hope this make it clearer. Dan, does this change your answer? Or did I > > misunderstand your answer? > > > > -Dan -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Tue Nov 2 06:31:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02488; Tue, 2 Nov 1999 06:31:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25330 Tue, 2 Nov 1999 08:04:24 -0500 (EST) Message-ID: <462720E13B20D311BF170008C75D2820B50256@hrm08.house.gov> From: "Mousa, Sami" To: "Waters, Stephen" , ipsec@lists.tislabs.com Subject: FW: AppleTalk VPN Client Date: Tue, 2 Nov 1999 08:05:53 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, I will share with you when I ask this question. I hope this help. Sami, tnk -----Original Message----- From: Charles Kaplan [mailto:ckaplan@norsec.com] Sent: Monday, October 25, 1999 2:30 PM To: Mousa, Sami Subject: AppleTalk VPN Client We have deployed the NTS TunnelBuilder/TunnelMaster client/server for customers that required AppleTalk VPNs. As far as I know it is the only product out their that does Appletalk VPN. Their is a server component that runs on an Intel Box (runs under Wind River imbeded OS I think) and then their are the clients which support 40 and 128 bit encryption, Appletalk traffic and IP traffic. Performance is OK, nothing amazing. I guess it depends on your end users link speeds. Modems are so/so. Price is about $5K for the server, about $50 each for the clients. You can check out nts at www.nts.com. BTW, if you want to purchase one, please do think of us. Good luck. -Charles Kaplan Date: Mon, 25 Oct 1999 07:19:00 -0400 From: "Mousa, Sami" Subject: [FW1] AppleTalk VPN Client Hello, Has anyone in this list test or install a VPN in an AppleTalk client? if so can you share your experience? Thanks in advance. Sami, tnk --- Charles B. Kaplan, President norSEC Inc. Who's watching over YOUR network? 61 East Cottage Street Norwood, MA 02062 877.4norSEC From owner-ipsec@lists.tislabs.com Tue Nov 2 07:04:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02931; Tue, 2 Nov 1999 07:04:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25499 Tue, 2 Nov 1999 08:42:12 -0500 (EST) Message-ID: From: "Salzman, Noah" To: "Waters, Stephen" , ipsec@lists.tislabs.com Subject: RE: IPSEc VPN Client for Apple Mac? Date: Mon, 1 Nov 1999 14:46:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, The Mac versions of PGP 6.5.1 and up contain PGPnet which is our IPSec client. We support CAST, Triple-DES, SHA-1, MD5, PFS, OpenPGP, X.509, and compression to name a few. http://www.nai.com (for corporate versions) or http://www.mcafee.com (for retail versions) Noah Salzman noah@nai.com 408.346.5186 > -----Original Message----- > From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] > Sent: Monday, November 01, 1999 1:30 PM > To: ipsec@lists.tislabs.com > Subject: IPSEc VPN Client for Apple Mac? > > > > Are there any IPSEC Client products for Apple O/S out there? > > Cheers, Steve. > From owner-ipsec@lists.tislabs.com Tue Nov 2 08:13:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04045; Tue, 2 Nov 1999 08:13:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25713 Tue, 2 Nov 1999 09:26:14 -0500 (EST) Message-ID: <381EF400.F7D33422@ennovatenetworks.com> Date: Tue, 02 Nov 1999 09:24:00 -0500 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sankar Ramamoorthi CC: ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space References: Content-Type: multipart/mixed; boundary="------------2035D19A76DFFE1FCC591601" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------2035D19A76DFFE1FCC591601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sankar, Thanks for the reply. Comments below. Sankar Ramamoorthi wrote: > Would'nt VPNs with operlapping address space cause a problem > only when the address spaces intersect on both ends? > If they are just intersecting on one side then the address selectors > should be able uniquely determine which vpn the phase2 exchange > belongs to - right? Yeah, but that's not the problem I'm trying to solve. > > > Also in the diagram shown below, would'nt using identifiers of > type IP_ADDRESS_RANGE solve the problem. > I don't think so. I think they would still overlap, but I must admit I'm not sure what you are getting at. Would this solve the general case? If so, could you elaborate further? Thanks. --------------2035D19A76DFFE1FCC591601 Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-795-5405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------2035D19A76DFFE1FCC591601-- From owner-ipsec@lists.tislabs.com Tue Nov 2 08:26:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04288; Tue, 2 Nov 1999 08:26:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25928 Tue, 2 Nov 1999 09:57:18 -0500 (EST) Date: Tue, 2 Nov 1999 09:48:36 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <17408.991102@lucent.com> To: "Waters, Stephen" CC: ipsec@lists.tislabs.com Subject: Re: IPSEc VPN Client for Apple Mac? In-reply-To: <29752A74B6C5D211A4920090273CA3DCCDE5AD@new-exc1.ctron.com> References: <29752A74B6C5D211A4920090273CA3DCCDE5AD@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Stephen, To add to Will Price... Compatible Systems supports Mac (3DES only) AtDhVaAnNkCsE Best regards, Jim Tiller, CISSP, MCSE+I, CCDA jtiller@lucent.com Network Security Consultant, Lucent Tampa, Florida "Faber est suae quisque fortunae." - Appius Claudius Caecus Monday, November 01, 1999, 4:29:38 PM, you wrote: Waters> Are there any IPSEC Client products for Apple O/S out there? Waters> Cheers, Steve. From owner-ipsec@lists.tislabs.com Tue Nov 2 08:26:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04305; Tue, 2 Nov 1999 08:26:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25908 Tue, 2 Nov 1999 09:56:34 -0500 (EST) Message-ID: <381EFB11.23A6AEC1@ennovatenetworks.com> Date: Tue, 02 Nov 1999 09:54:09 -0500 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen CC: ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space References: <199911020128.RAA00503@potassium.network-alchemy.com> <381EB1F6.5AFCF6FE@DataFellows.com> Content-Type: multipart/mixed; boundary="------------A90028211CAC49D2928E22B5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------A90028211CAC49D2928E22B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, Ari. I like this solution. So I would obtain an assigned Labeled Domain Identifer from IANA and use SIT_SECRECY with a defined secrecy category as the ID of the VPN. Comments from others on the list on this solution? -Dan Ari Huttunen wrote: > How about using either SIT_SECRECY or SIT_INTEGRITY > together with the secrecy/integrity category being either VPN1 > or VPN2? > > Ari > > Dan Harkins wrote: > > > Dan, > > > > I think the key here is "Each VPN has its own address space which may > > or may not overlap." In that case the answer is that there is no way > > to handle this using IPSec (today). At least I don't see a way. If you > > could rule out overlapping address space it would work the way I > > described; if you can't then I don't think there's an a way to do this > > which would guarantee interoperability. There's no concept of a VPN > > as a selector parameter. > > > > Dan. > > > > On Mon, 01 Nov 1999 20:12:47 EST you wrote > > > > > > Dan, > > > > > > Thanks for the reply. > > > > > > I think amending my architecture to include the subnets will clarify things. > > > > > > VPN 1, site A VPN 1, site B > > > ---------+ +------+ +------+ +--------- > > > 10.1/16 | | | | | | 10.2/16 > > > +--------+ | | +--------+ > > > | GW A +----------+ GW B | > > > +--------+ | | +--------+ > > > 10.1/16 | | | | | | 10.2/16 > > > ---------+ +------+ +------+ +--------- > > > VPN 2, site A VPN 2, site B > > > > > > Each VPN has its own address space which may or may not overlap. In the abov > > >e > > > example, VPN 1 has two sites with 10.1/16 subnet and 10.2/16 subnet. VPN 2 a > > >lso > > > has two sites, one with a 10.1/16 subnet, and the other a 10.2/16 subnet. (T > > >his > > > is a requirement as we don't want to mandate which addresses each VPN chooses > > > to > > > use). > > > > > > The first packet arrives from VPN1, site A (and I know this from the L2 inter > > >face > > > it uses), destined for VPN1, site B. > > > > > > GWA initiates phase 1 with GWB. They use DN ID's (because each has a certifi > > >cate) > > > for this phase. > > > > > > Then GWA initiates phase 2 with GWB. Let's say they use ID_IPV4_ADDR_SUBNET > > >for > > > both IDci and IDcr. Then IDci=10.1/16 and IDcr=10.2/16. When GWB sees the p > > >hase > > > 2 ID's, GWB has no way of knowing whether the ID's correspond to the address > > >space > > > of VPN1 or VPN2. Therefore, when GWB receives an ESP packet from GWA with th > > >e SPI > > > negotiated, GWB has no idea whether to forward the packet to VPN 1, site B or > > > VPN > > > 2, site B. > > > > > > I hope this make it clearer. Dan, does this change your answer? Or did I > > > misunderstand your answer? > > > > > > -Dan > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > Data Fellows Corporation http://www.DataFellows.com > > F-Secure products: Integrated Solutions for Enterprise Security --------------A90028211CAC49D2928E22B5 Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-795-5405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------A90028211CAC49D2928E22B5-- From owner-ipsec@lists.tislabs.com Tue Nov 2 09:52:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06004; Tue, 2 Nov 1999 09:52:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26202 Tue, 2 Nov 1999 10:58:51 -0500 (EST) Message-ID: <381ED27C.236F5F92@sympatico.ca> Date: Tue, 02 Nov 1999 12:01:00 +0000 From: Sandy Harris X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Waters, Stephen" CC: ipsec@lists.tislabs.com Subject: Re: IPSEc VPN Client for Apple Mac? References: <29752A74B6C5D211A4920090273CA3DCCDE5AD@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Waters, Stephen" wrote: > > Are there any IPSEC Client products for Apple O/S out there? > > Cheers, Steve. Helsinki U of Techology: IPSEC for Solaris, Mac, and a Java version: http://www.tcm.hut.fi/Tutkimus/IPSEC/ From owner-ipsec@lists.tislabs.com Tue Nov 2 10:58:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07871; Tue, 2 Nov 1999 10:58:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26330 Tue, 2 Nov 1999 11:20:19 -0500 (EST) To: ipsec@lists.tislabs.com Subject: RE: Phase 2 ID's for different VPN's with different Address Space Date: Tue, 2 Nov 1999 16:20:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CFDBE@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This may overlap with what Ari wrote, but could you put security labels on IP datagrams to identify which VPN they belong to? This would be an additional selector you could use in the SPD to differentiate between datagrams from different VPNs. You could label the datagrams when you receive them from a VPN and remove the label when you transmit them back again. I must confess I'm not at all familiar with these labels so I'm not sure if this is a valid thing to do, but if it is then it would allow you to create multiple IP address spaces. Chris > -----Original Message----- > From: Daniel Fox [mailto:dfox@ennovatenetworks.com] > Sent: 02 November 1999 14:24 > To: Sankar Ramamoorthi > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 2 ID's for different VPN's with different Address > Space > > > Sankar, > > Thanks for the reply. Comments below. > > Sankar Ramamoorthi wrote: > > > Would'nt VPNs with operlapping address space cause a problem > > only when the address spaces intersect on both ends? > > If they are just intersecting on one side then the address selectors > > should be able uniquely determine which vpn the phase2 exchange > > belongs to - right? > > Yeah, but that's not the problem I'm trying to solve. > > > > > > > Also in the diagram shown below, would'nt using identifiers of > > type IP_ADDRESS_RANGE solve the problem. > > > > I don't think so. I think they would still overlap, but I > must admit I'm not > sure what you are getting at. Would this solve the general > case? If so, could > you elaborate further? Thanks. > > > From owner-ipsec@lists.tislabs.com Tue Nov 2 11:02:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07958; Tue, 2 Nov 1999 11:02:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26527 Tue, 2 Nov 1999 12:26:23 -0500 (EST) Date: Tue, 2 Nov 1999 12:26:54 -0500 (EST) From: "David M. Balenson" Message-Id: <199911021726.MAA25862@clipper.gw.tislabs.com> To: ipsec@tislabs.com Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - Intrusion Detection Research, Instructor TBD FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ipsec@lists.tislabs.com Tue Nov 2 13:22:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10986; Tue, 2 Nov 1999 13:22:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26874 Tue, 2 Nov 1999 13:44:56 -0500 (EST) Message-ID: From: "Stoler, David J" To: "'Waters, Stephen'" , "'ipsec@lists.tislabs.com'" Subject: RE: IPSEc VPN Client for Apple Mac? Date: Tue, 2 Nov 1999 10:47:20 -0800 X-Mailer: Internet Mail Service (5.0.1460.8) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is also NetLOCK, which supports many platforms including Macintosh. See http://www.netlock.com -----Original Message----- From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] Sent: Monday, November 01, 1999 1:30 PM To: ipsec@lists.tislabs.com Subject: IPSEc VPN Client for Apple Mac? Are there any IPSEC Client products for Apple O/S out there? Cheers, Steve. From owner-ipsec@lists.tislabs.com Tue Nov 2 13:22:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11009; Tue, 2 Nov 1999 13:22:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26858 Tue, 2 Nov 1999 13:43:14 -0500 (EST) Message-ID: From: "Stoler, David J" To: "'Waters, Stephen'" , "'ipsec@lists.tislabs.com'" Subject: RE: IPSEc VPN Client for Apple Mac? Date: Tue, 2 Nov 1999 10:45:39 -0800 X-Mailer: Internet Mail Service (5.0.1460.8) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] Sent: Monday, November 01, 1999 1:30 PM To: ipsec@lists.tislabs.com Subject: IPSEc VPN Client for Apple Mac? Are there any IPSEC Client products for Apple O/S out there? Cheers, Steve. From owner-ipsec@lists.tislabs.com Tue Nov 2 16:06:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13671; Tue, 2 Nov 1999 16:06:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27733 Tue, 2 Nov 1999 17:21:52 -0500 (EST) Message-ID: From: Sankar Ramamoorthi To: "'Daniel Fox'" , Sankar Ramamoorthi Cc: ipsec@lists.tislabs.com Subject: RE: Phase 2 ID's for different VPN's with different Address Space Date: Tue, 2 Nov 1999 14:24:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My mistake. I assumed that the host-pair belonging to VPN1 and VPN2 are different. -- sankar -- -----Original Message----- From: Daniel Fox [mailto:dfox@ennovatenetworks.com] Sent: Tuesday, November 02, 1999 6:24 AM To: Sankar Ramamoorthi Cc: ipsec@lists.tislabs.com Subject: Re: Phase 2 ID's for different VPN's with different Address Space Sankar, Thanks for the reply. Comments below. Sankar Ramamoorthi wrote: > Would'nt VPNs with operlapping address space cause a problem > only when the address spaces intersect on both ends? > If they are just intersecting on one side then the address selectors > should be able uniquely determine which vpn the phase2 exchange > belongs to - right? Yeah, but that's not the problem I'm trying to solve. > > > Also in the diagram shown below, would'nt using identifiers of > type IP_ADDRESS_RANGE solve the problem. > I don't think so. I think they would still overlap, but I must admit I'm not sure what you are getting at. Would this solve the general case? If so, could you elaborate further? Thanks. From owner-ipsec@lists.tislabs.com Wed Nov 3 01:53:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29198; Wed, 3 Nov 1999 01:53:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29108 Wed, 3 Nov 1999 03:20:15 -0500 (EST) Message-Id: <3.0.6.32.19991103075139.00795c50@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 03 Nov 1999 07:51:39 +0000 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: agenda for Washington? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has the agenda for Washington posted to the list? I've been having troubles with lists.tislabs.com bouncing email. From owner-ipsec@lists.tislabs.com Wed Nov 3 03:43:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03371; Wed, 3 Nov 1999 03:43:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29468 Wed, 3 Nov 1999 05:20:40 -0500 (EST) Message-ID: <38200C69.3D458863@ire-ma.com> Date: Wed, 03 Nov 1999 05:20:25 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec , ipsra , Dan Harkins Subject: CRACK questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I couldn't find any IKE SA re-keying considerations in the draft, and I have a couple questions on the subject: 1) How does re-keying scenario look like, esp. with the time-base SecureID authentication? I am sure we do not want to re-prompt user each time when re-keying takes place. 2) How does re-keying scenario look like when the roles of the Initiator and Responder are reversed (in other words - if the Gateway decides to re-key)? Thank you Slava From owner-ipsec@lists.tislabs.com Wed Nov 3 11:35:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13650; Wed, 3 Nov 1999 11:35:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01737 Wed, 3 Nov 1999 12:47:47 -0500 (EST) Message-Id: <199911031748.JAA10632@potassium.network-alchemy.com> To: Bronislav Kavsan cc: ipsec , ipsra Subject: Re: CRACK questions In-reply-to: Your message of "Wed, 03 Nov 1999 05:20:25 EST." <38200C69.3D458863@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10629.941651333.1@network-alchemy.com> Date: Wed, 03 Nov 1999 09:48:53 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava, On Wed, 03 Nov 1999 05:20:25 EST you wrote > > I couldn't find any IKE SA re-keying considerations in the draft, and I > have a couple questions on the subject: > > 1) How does re-keying scenario look like, esp. with the time-base > SecureID authentication? > I am sure we do not want to re-prompt user each time when re-keying > takes place. Then how does the gateway know its's still talking to the "user"? Part of IKE SA re-keying is re-authenticating. You can't do a token card authentication unless you get some input from the token card. > 2) How does re-keying scenario look like when the roles of the Initiator > and Responder are reversed (in other words - if the Gateway decides to > re-key)? The gateway doesn't initiate a phase 1 to re-key. The gateway can initiate phase 2 rekeys because he has authenticated someone at that particular IP address. But when the IKE SA, which provides that binding, goes away the gateway has no knowledge that that someone is still at that IP address. Client policy is promiscuous; it's me to anybody. You can't initiate a phase 1 to "anybody" and just because someone used to be at a random IP address does not mean he still is. If you don't want to re-prompt the user to reauthenticate and expect a gateway to initiate an IKE SA rekey then the gateway can end up initiating to someone who has just got the lease on that IP address and not require him to prove he is who it thinks he is. Any properly implemented security gateway would not allow that to happen. Dan. From owner-ipsec@lists.tislabs.com Fri Nov 5 07:56:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26583; Fri, 5 Nov 1999 07:56:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09975 Fri, 5 Nov 1999 08:54:11 -0500 (EST) Message-ID: <3822E237.45F3FE03@ire-ma.com> Date: Fri, 05 Nov 1999 08:57:11 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec , ipsra Subject: Re: CRACK questions References: <199911031748.JAA10632@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In other words - you are saying that: 1) for SecureID-based authentication - CRACK prohibits Phase 1 re-keying without re-prompting the User (while other proposed authentiication schemes have an option to skip authentication when re-keying Phase 1) 2) CRACK prohibits Gateways to initiate Phase 1 re-keying (while previous standards are symmetrical in this respect) Could anyone comment on this? Dan Harkins wrote: > Slava, > > On Wed, 03 Nov 1999 05:20:25 EST you wrote > > > > I couldn't find any IKE SA re-keying considerations in the draft, and I > > have a couple questions on the subject: > > > > 1) How does re-keying scenario look like, esp. with the time-base > > SecureID authentication? > > I am sure we do not want to re-prompt user each time when re-keying > > takes place. > > Then how does the gateway know its's still talking to the "user"? Part of > IKE SA re-keying is re-authenticating. You can't do a token card > authentication unless you get some input from the token card. > > > 2) How does re-keying scenario look like when the roles of the Initiator > > and Responder are reversed (in other words - if the Gateway decides to > > re-key)? > > The gateway doesn't initiate a phase 1 to re-key. The gateway can initiate > phase 2 rekeys because he has authenticated someone at that particular IP > address. But when the IKE SA, which provides that binding, goes away the > gateway has no knowledge that that someone is still at that IP address. > Client policy is promiscuous; it's me to anybody. You can't initiate a > phase 1 to "anybody" and just because someone used to be at a random IP > address does not mean he still is. > > If you don't want to re-prompt the user to reauthenticate and expect a > gateway to initiate an IKE SA rekey then the gateway can end up initiating > to someone who has just got the lease on that IP address and not require > him to prove he is who it thinks he is. Any properly implemented security > gateway would not allow that to happen. > > Dan. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Nov 5 07:59:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26648; Fri, 5 Nov 1999 07:59:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10024 Fri, 5 Nov 1999 08:59:32 -0500 (EST) Message-ID: <3822E43B.A491B545@ibm.net> Date: Fri, 05 Nov 1999 09:05:48 -0500 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec Subject: Meeting agenda Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is the agenda for next weeks ipsec wg meeting available yet? From owner-ipsec@lists.tislabs.com Fri Nov 5 08:25:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27368; Fri, 5 Nov 1999 08:25:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10172 Fri, 5 Nov 1999 09:33:18 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF1F369@exchange> From: Stephane Beaulieu To: Slava Kavsan , Dan Harkins Cc: ipsec , ipsra Subject: RE: CRACK questions Date: Fri, 5 Nov 1999 09:35:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Slava, > In other words - you are saying that: > > 1) for SecureID-based authentication - CRACK prohibits Phase > 1 re-keying > without re-prompting the User (while other proposed > authentiication schemes > have an option to skip authentication when re-keying Phase 1) Even though other authentication schemes give you this option, you must be very careful while using it. For example XAUTH gives an implementor the option of allowing this by binding the ID of the phase 1 SA to the XAUTH state. However, this mechanism MUST NOT be used in cases where ID checking is not done. There may be other ways to bind the two in the future, but for now checking the ID seems to be the best way. XAUTH will go into more detail on this subject in the next rev. regards, Stephane. From owner-ipsec@lists.tislabs.com Fri Nov 5 08:54:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27947; Fri, 5 Nov 1999 08:54:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10372 Fri, 5 Nov 1999 10:05:32 -0500 (EST) Message-Id: <3.0.32.19991105095744.00ac15e0@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 05 Nov 1999 09:57:45 -0500 To: Slava Kavsan From: "Shawn Mamros" Subject: Re: CRACK questions Cc: ipsec , ipsra Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:57 AM 11/5/99 -0500, Slava Kavsan wrote: >In other words - you are saying that: > >1) for SecureID-based authentication - CRACK prohibits Phase 1 re-keying >without re-prompting the User (while other proposed authentiication schemes >have an option to skip authentication when re-keying Phase 1) Do they really? That strikes me as being a really bad idea from a security standpoint. The word "re-keying" is somewhat of a misnomer, especially when applied to Phase 1. What you're really doing is reauthenticating (and generating new keying material in the bargain). You can't just blindly assume that someone proposing a new Phase 1 SA from the same IP address and the same ID is, in fact, the same party with which you've authenticated before. Would you not require a new digital signature from someone for a new Phase 1 SA, if that's what they'd used before? Why should any other authentication method (even if done in a "phase 1.5" like XAUTH) be any different? >2) CRACK prohibits Gateways to initiate Phase 1 re-keying (while previous >standards are symmetrical in this respect) In a true peer-to-peer environment, I would be concerned. But this is a client-to-gateway (and typically user-to-gateway) scenario. Should the gateway be wasting its time trying to initiate to a user who's gone away? If I'm trying to support thousands of users, that's going to be a big concern. If the user wants to reconnect, let them reinitiate the connection, especially since they do have to reauthenticate anyways (see above). Seems like common sense to me. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Fri Nov 5 09:11:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28187; Fri, 5 Nov 1999 09:11:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10129 Fri, 5 Nov 1999 09:26:02 -0500 (EST) Message-ID: <3822E99F.3BD0423@ire-ma.com> Date: Fri, 05 Nov 1999 09:28:47 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec , ipsra Subject: COOKIES in STATUS NOTIFY Messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is the purpose of having COOKIES in STATUS NOTIFY Messages? Aren't these COOKIES the same as in the ISAKMP Header that accompanies these messages? If this is the case - does anyone checks if they are the same? Or these COOKIES simply useless stuff and no one cares? -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Nov 5 09:53:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29109; Fri, 5 Nov 1999 09:53:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10419 Fri, 5 Nov 1999 10:16:08 -0500 (EST) Message-ID: <3822F590.A1B1B569@ire-ma.com> Date: Fri, 05 Nov 1999 10:19:44 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shawn Mamros CC: ipsec , ipsra Subject: Re: CRACK questions References: <3.0.32.19991105095744.00ac15e0@zbl6c000.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is the difference - re-authentication with time-based tokens (SecureID) requires prompting user each time re-keying/re-authentication occurs. Of course - it is very secure.... but also could be very annoying if it is done too frequently. Other non-time-based re-authentications could be silent (or skipped, at the compromise of security) - but at least the local policy administrator has this alternative for this network to be less secure, but less annoying. Shawn Mamros wrote: > At 08:57 AM 11/5/99 -0500, Slava Kavsan wrote: > >In other words - you are saying that: > > > >1) for SecureID-based authentication - CRACK prohibits Phase 1 re-keying > >without re-prompting the User (while other proposed authentiication schemes > >have an option to skip authentication when re-keying Phase 1) > > Do they really? That strikes me as being a really bad idea from a > security standpoint. The word "re-keying" is somewhat of a misnomer, > especially when applied to Phase 1. What you're really doing is > reauthenticating (and generating new keying material in the bargain). > You can't just blindly assume that someone proposing a new Phase 1 > SA from the same IP address and the same ID is, in fact, the same > party with which you've authenticated before. Would you not require > a new digital signature from someone for a new Phase 1 SA, if that's > what they'd used before? Why should any other authentication method > (even if done in a "phase 1.5" like XAUTH) be any different? > > >2) CRACK prohibits Gateways to initiate Phase 1 re-keying (while previous > >standards are symmetrical in this respect) > > In a true peer-to-peer environment, I would be concerned. But this > is a client-to-gateway (and typically user-to-gateway) scenario. > Should the gateway be wasting its time trying to initiate to a user > who's gone away? If I'm trying to support thousands of users, that's > going to be a big concern. If the user wants to reconnect, let them > reinitiate the connection, especially since they do have to reauthenticate > anyways (see above). Seems like common sense to me. > > -Shawn Mamros > E-mail to: smamros@nortelnetworks.com -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Nov 5 11:32:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00787; Fri, 5 Nov 1999 11:32:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10923 Fri, 5 Nov 1999 12:02:07 -0500 (EST) Message-Id: <4.2.1.19991105090308.00cfb820@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 05 Nov 1999 09:03:35 -0800 To: Slava Kavsan , Shawn Mamros From: Paul Hoffman Subject: Re: CRACK questions Cc: ipsec , ipsra In-Reply-To: <3822F590.A1B1B569@ire-ma.com> References: <3.0.32.19991105095744.00ac15e0@zbl6c000.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could this thread be moved to *only* the IPSRA mailing list? The WG chair asked us once already... --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Nov 5 11:51:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01123; Fri, 5 Nov 1999 11:51:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11183 Fri, 5 Nov 1999 13:23:11 -0500 (EST) Message-ID: From: Sankar Ramamoorthi To: "'Shawn Mamros'" , Slava Kavsan Cc: ipsec , ipsra Subject: RE: CRACK questions Date: Fri, 5 Nov 1999 10:25:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Somes points to consider is - Re-authentication of end-user typically occurs after a period of inactivity. This is different from time based rekeying. Should 'CRACK' take that into account? - In the case of client-gateway scenario should phase 1 rekeying authenticate the end-user or the device? CRACK seems to need that phase1 rekeying MUST reauthenticate the end-user always. For example a design may want to reauthencticate the end-user once per session (and after a period of inactivity) Reauthenticate of the device periodically during phase1 rekeying -- Looks like such a design is not possible using CRACK alone. Thanks, -- sankar -- -----Original Message----- From: Shawn Mamros [mailto:smamros@nortelnetworks.com] Sent: Friday, November 05, 1999 6:58 AM To: Slava Kavsan Cc: ipsec; ipsra Subject: Re: CRACK questions At 08:57 AM 11/5/99 -0500, Slava Kavsan wrote: >In other words - you are saying that: > >1) for SecureID-based authentication - CRACK prohibits Phase 1 re-keying >without re-prompting the User (while other proposed authentiication schemes >have an option to skip authentication when re-keying Phase 1) Do they really? That strikes me as being a really bad idea from a security standpoint. The word "re-keying" is somewhat of a misnomer, especially when applied to Phase 1. What you're really doing is reauthenticating (and generating new keying material in the bargain). You can't just blindly assume that someone proposing a new Phase 1 SA from the same IP address and the same ID is, in fact, the same party with which you've authenticated before. Would you not require a new digital signature from someone for a new Phase 1 SA, if that's what they'd used before? Why should any other authentication method (even if done in a "phase 1.5" like XAUTH) be any different? >2) CRACK prohibits Gateways to initiate Phase 1 re-keying (while previous >standards are symmetrical in this respect) In a true peer-to-peer environment, I would be concerned. But this is a client-to-gateway (and typically user-to-gateway) scenario. Should the gateway be wasting its time trying to initiate to a user who's gone away? If I'm trying to support thousands of users, that's going to be a big concern. If the user wants to reconnect, let them reinitiate the connection, especially since they do have to reauthenticate anyways (see above). Seems like common sense to me. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Fri Nov 5 18:06:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06253; Fri, 5 Nov 1999 18:06:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12472 Fri, 5 Nov 1999 19:20:17 -0500 (EST) Message-Id: <4.2.1.19991105161043.00a8fba0@mail.imc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 05 Nov 1999 16:22:56 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: RSIP and IPsec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pre-DC greetings. There has been almost zero discussion of the RSIP protocol on this mailing list, even though much of the purpose of RSIP is for helping carry IPsec into and out of NATs. People should be aware of this so we can help advise the authors of the protocol. The three relevant drafts are: draft-ietf-nat-rsip-framework-02.txt draft-ietf-nat-rsip-protocol-03.txt draft-ietf-nat-rsip-ipsec-00.txt (As usual, the latest copies are also at the VPNC web site.) The NAT WG is meeting on Monday from 1530-1730, which is the slot after the IPsec WG. The agenda for the NAT WG is at . BTW, I'm not promoting this protocol, just noting that it is being written to answer one of our problems and we don't seem very involved it in. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Nov 6 13:09:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26612; Sat, 6 Nov 1999 13:09:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14517 Sat, 6 Nov 1999 14:40:13 -0500 (EST) Date: Sat, 6 Nov 1999 21:43:01 +0200 (EET) Message-Id: <199911061943.VAA10526@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Slava Kavsan Cc: ipsec , ipsra Subject: COOKIES in STATUS NOTIFY Messages In-Reply-To: <3822E99F.3BD0423@ire-ma.com> References: <3822E99F.3BD0423@ire-ma.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan writes: > What is the purpose of having COOKIES in STATUS NOTIFY Messages? In normal case the cookies identify the IKE SA for which the notify message conserns. > Aren't these COOKIES the same as in the ISAKMP Header that accompanies > these messages? Not always. For example if you have already existing IKE SA and you start rekeying which will fail, then you might send the AUTHENTICATION FAILED notification using that old IKE SA to get protection for that. In this case the ISAKMP header cookies are the old existing IKE SA and the cookies inside the notify payload inidicate failed IKE SA. > If this is the case - does anyone checks if they are the same? Or these > COOKIES simply useless stuff and no one cares? I think most of the people just don't care. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Nov 7 22:15:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA20733; Sun, 7 Nov 1999 22:15:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17812 Sun, 7 Nov 1999 23:38:26 -0500 (EST) Date: Sun, 7 Nov 1999 23:29:13 -0500 Message-Id: <199911080429.XAA01846@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: ipsec@lists.tislabs.com Subject: IPSEC wg agenda (first draft) From: tytso@mit.edu Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apologies for getting a draft agenda out so late. Life was a bit busy in the last couple of weeks, and I wasn't able to get to this sooner. I believe this agenda represents all of the requests for time slots which I received, with the exception of topics which are related to IPSEC RA, and which properly be addressed in that BOF session later this week. If you have an agenda topic you would like to add to this list, please let me know, either via e-mail or in person before the meeting tomorrow (Monday) at 1pm. One potential topic to add to this list is a status report on the IKE update work being done by Harkins/Carrel, although since I don't believe I got an explicit timeslot request for this, it hasn't be included on the agenda yet. - Ted 1300 -- 1305 Agenda bashing -- Ts'o 1305 -- 1310 ECN -- Black 1310 -- 1320 Notify Messages Draft Revision -- Kelley 1320 -- 1330 IPSEC MIB -- Jenkins 1330 -- 1340 IPSEC High-level MIB -- Timms 1340 -- 1355 ESP Transforms for Integrity-aware PCBC modes -- Bellovin 1355 -- 1410 PKI Infrastructure -- Thayer 1410 -- 1420 IPSEC Resource Management Issues -- Walker From owner-ipsec@lists.tislabs.com Mon Nov 8 07:16:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29424; Mon, 8 Nov 1999 07:15:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18889 Mon, 8 Nov 1999 08:26:49 -0500 (EST) Message-ID: <19991106112233.9514.rocketmail@web1705.mail.yahoo.com> Date: Sat, 6 Nov 1999 03:22:33 -0800 (PST) From: Nishant Mishra Subject: VPN<->Firewall To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Can any one elaborate what interaction is required between a VPN software and Firewall? Apart from keeping holes in Firewall for VPN channels are there any interaction required ? Thanks, Nishant Mishra ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Mon Nov 8 07:16:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29425; Mon, 8 Nov 1999 07:16:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18880 Mon, 8 Nov 1999 08:25:49 -0500 (EST) Date: Sat, 6 Nov 1999 16:48:53 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <15700.991106@lucent.com> To: Jianying Zhou CC: Qiang Zhang , ipsec mailling list Subject: Re[2]: Main mode using pre-shared keys In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Jianying, Is the peer's IP address derived from the payload (i.e. the HASH_I/R) or just the source defined in the IP header of the packet? If it is derived from the HASH_I/R...does that have to be the same as the IP Header's source address? Also, if the HASH gets the IP address from the ID, that is used in the hashing process, why can't it search the shared secret based on some of the other attributes available in the ID? Here is the issue. I have read the RFCs inside and out, books and more books. But I can seem to only get so deep until I think I'm missing a basic point. If some one could shed some light on this: Zhou> In fact, there is no identity protection in main mode with pre-shared Zhou> key for authentication. The peer's IP address has to be used to select Zhou> pre-shared key. No identity protection in MM or AM (?) I thought ID protection WAS available? I understand that AM does not provide any, but MM? Is this because there is no signature process like with the other authentication types? I feel like I'm missing something obvious and it's effecting my ability to increase my knowledge of IKE and IPSec in general. To be frank...I don't have anyone to really discuss this with on a regular basis. So, I humbly request the assistance of the kind folk of this mail list. Thank you in advance for your time. -jim P.S. Just so you know, I have been reading everything on this list for the past three months in an attempt to learn as much as I can prior to asking poor question. I fear that this may be a poor question. Wednesday, October 27, 1999, 8:43:13 PM, you wrote: Zhou> In fact, there is no identity protection in main mode with pre-shared Zhou> key for authentication. The peer's IP address has to be used to select Zhou> pre-shared key. Zhou> One solution is to re-define SKEYID. We may not use pre-shared key for Zhou> the generation of SKEYID. Instead, we can use the definition of SKEYID Zhou> for digital signature, i.e. Zhou> SKEYID = prf (Ni_b|Nr_b, g^xy) Zhou> We only need to use pre-shared key for authentication of IKE exchanges. Zhou> So we can replace HASH_I and HASH_R with AUTH_I and AUTH_R respectively Zhou> in the protocol, where Zhou> AUTH_I = prf (pre-shared-key, HASH_I) Zhou> AUTH_R = prf (pre-shared-key, HASH_R) Zhou> Jianying Zhou> On Wed, 27 Oct 1999, Qiang Zhang wrote: >> At 10:24 AM 10/27/99 -0700, CHINNA N.R. PELLACURU wrote: >> >RFC 2409 >> > >> >5.4 Phase 1 Authenticated With a Pre-Shared Key >> > >> > Initiator Responder >> > ---------- ----------- >> > HDR, SA --> >> > <-- HDR, SA >> > HDR, KE, Ni --> >> > <-- HDR, KE, Nr >> > HDR*, IDii, HASH_I --> >> > <-- HDR*, IDir, HASH_R >> > >> > When using pre-shared key authentication with Main Mode the key can >> > only be identified by the IP address of the peers since HASH_I must >> > be computed before the initiator has processed IDir. Aggressive Mode >> > allows for a wider range of identifiers of the pre-shared secret to >> > be used. In addition, Aggressive Mode allows two parties to maintain >> > multiple, different pre-shared keys and identify the correct one for >> > a particular exchange. >> >" >> > >> > >> >"identified by the IP address of the peers" >> > >> >Does this mean that the ID payload content must be an IP Address, and it >> >should be the same as the source IP address on the IKE packet that the >> >peers are using? >> > >> >If the source IP address on the packet is used to search the pre-shared >> >key, then we authenticate the peer, by the fact that the peer knows the >> >shared secret associated with the IP address he is using. Inspite of that, >> >is the RFC also advicing that we enforce, the ID payload content is the >> >source IP address that was used to search the shared secret? >> >> Chinna, notice that the HASHi computation HAS to use the peer-address to >> search the preshared secret thus I think at least in this circumstance, the >> ID payload won't work. Further one thing to worry about is that the >> source address is not trustable due to all kinds of IP routing scheme. >> >> This is something I think the WG should give a solution. >> >> Qiang >> >> >> > >> >If so, the confidentiality part of the Identity protection is not there, >> >when using pre-shared keys. >> > >> >What are the consequenses of not enforceing the above requirement? We are >> >authenticating the peer using the IP source address he is using, because >> >we search the pre-shared key based on it, but we accept his ID to be >> >anything. >> > >> >TIA, chinna >> > >> >chinna narasimha reddy pellacuru >> >s/w engineer >> > >> > >> > >> >> From owner-ipsec@lists.tislabs.com Mon Nov 8 09:55:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02097; Mon, 8 Nov 1999 09:55:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19244 Mon, 8 Nov 1999 09:54:22 -0500 (EST) Reply-To: From: "Scott Davidson" To: "Nishant Mishra" , Subject: RE: VPN<->Firewall Date: Mon, 8 Nov 1999 08:56:48 -0600 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004D_01BF29C6.FB786CA0" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <19991106112233.9514.rocketmail@web1705.mail.yahoo.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004D_01BF29C6.FB786CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Well, that question has 2 answers, depending on what you mean by "VPN software". If you mean a remote client connecting to a firewalled network then you do not necessarily need a "hole" in the firewall so much as a rule to authenticate and then take a "decrypt" action for remote clients attempting to access internal resources. IF you mean a remote network (another firewalled network) connecting to your network then both networks must reside in the same encryption domain so that they can encrypt and decrypt appropriately. This assume that the VPN tunnel was establish as a part of configuration on install. There is typically no "keep alive" beacon of any type required for this as there often is in remote client software. Scott Davidson Central US Systems Engineer Nokia House - Dallas 6000 Connection Drive 1:319 Irving, Texas 75039 MOB 214.632.6191 OFC 972.894.6269 scott.davidson@iprg.nokia.com www.iprg.nokia.com support.iprg.nokia.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Nishant Mishra Sent: Saturday, November 06, 1999 5:23 AM To: ipsec@lists.tislabs.com Subject: VPN<->Firewall Hello, Can any one elaborate what interaction is required between a VPN software and Firewall? Apart from keeping holes in Firewall for VPN channels are there any interaction required ? Thanks, Nishant Mishra ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com ------=_NextPart_000_004D_01BF29C6.FB786CA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKTCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/ LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIEszCCBBygAwIBAgIQTRW6AR01IOqQtMIC5JkT9jANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTEwMTQw MDAwMDBaFw05OTEyMTMyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEnMCUGA1UECxMeRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 MRcwFQYDVQQDFA5TY290dCBEYXZpZHNvbjEsMCoGCSqGSIb3DQEJARYdc2NvdHQuZGF2aWRzb25A aXByZy5ub2tpYS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwQ8DP/5+MvNL0IdjQUCAOPYZ J8EIBidEZLbpFn2WslY09KQZP8Rd4EZsMmwQSVmPeimEQWxMmid7j8p01S32JQIDAQABo4IBjzCC AYswCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0 NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcw MTc0N2RhNWQzZjIxNDFiZWFkYjJiZDJlODkyMTFhODY5ZjJkZjExNDg5Y2EzYmQ0NGY1ZjNlYTQ1 MGMwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDAN BgkqhkiG9w0BAQQFAAOBgQB2A7Xm+uE+uHzE8upMojmjvL5IHNhDfkS7ZJoOkxAZ10QS6RurD69I lKHxAxf/EdT0gsEYvqYg2W/dFB/TC4I5sLhgvEyCzjyohOHODcxUzTEokGCyteXgZgIksFnyrVb4 /NNKy6MQq/eLeaNZkQtNy4V2ogtxflkmKgnmeuAdbjGCAtIwggLOAgEBMIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmli ZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBNFboBHTUg6pC0wgLkmRP2MAkGBSsOAwIaBQCgggGH MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTEwODE0NTUxOFow IwYJKoZIhvcNAQkEMRYEFKifuHk2XZKyDZlHICkH87QYH6gzMDMGCSqGSIb3DQEJDzEmMCQwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQTRW6AR01IOqQtMIC5JkT9jANBgkqhkiG 9w0BAQEFAARAasfLIV1+7Xm6vISNbKIjlbzU9p0Sl/JM1+WZ7Ky8gSVXR88kk1TLI56LoBTbVp5U t+r4fiN1tcOm0FzJAxMfOgAAAAAAAA== ------=_NextPart_000_004D_01BF29C6.FB786CA0-- From owner-ipsec@lists.tislabs.com Mon Nov 8 10:47:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02912; Mon, 8 Nov 1999 10:47:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19951 Mon, 8 Nov 1999 12:07:23 -0500 (EST) Message-Id: <199911081701.MAA08581@pzero.sandelman.ottawa.on.ca> To: Nishant Mishra cc: ipsec@lists.tislabs.com Subject: Re: VPN<->Firewall In-reply-to: Your message of "Sat, 06 Nov 1999 03:22:33 PST." <19991106112233.9514.rocketmail@web1705.mail.yahoo.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 08 Nov 1999 12:01:25 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Nishant" == Nishant Mishra writes: Nishant> Can any one elaborate what interaction is Nishant> required between a VPN software and Firewall? Nishant> Apart from keeping holes in Firewall for Nishant> VPN channels are there any interaction required ? Ideally you don't poke holes in the firewall randomly. The firewall gets to continue auditing if desired. You support IPsec for gateway-gateway, and client-gateway work, and you provide that a connection (telnet, http, etc.) that comes in protected by IPsec will be accorded increased priveledges by any higher layer proxies than if it wasn't protected by IPsec. (What that means is up to the admin) ] At IETF46 in Washington, DC | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Nov 8 13:04:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08822; Mon, 8 Nov 1999 13:04:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20488 Mon, 8 Nov 1999 14:03:10 -0500 (EST) Date: Mon, 8 Nov 1999 13:52:44 -0500 (EST) From: Michael Richardson Message-Id: <199911081852.NAA00504@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: iaPCBC design Sender: owner-ipsec@lists.tislabs.com Precedence: bulk http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt This is Steve's draft on doing both integrity and privacy in one operation that he presented at today's session. From owner-ipsec@lists.tislabs.com Tue Nov 9 13:07:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21314; Tue, 9 Nov 1999 13:07:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24887 Tue, 9 Nov 1999 14:00:40 -0500 (EST) Message-Id: <3.0.5.32.19991109210415.00ce2e30@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 09 Nov 1999 21:04:15 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: draft-ietf-ipsec-isakmp-mode-cfg-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA24884 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just noticed that the cfg-mode and the xauth drafts both define atrributes 13 and 14. INTERNAL_IP4_SUBNET 13 Variable 0 or 4 octets SUPPORTED_ATTRIBUTES 14 Variable 0 or multiples of 2 XAUTH_TYPE 13 Basic XAUTH_USER_NAME 14 Variable ASCII string And the INTERNAL_IP4_SUBNET should probably have 8 octets. My apologies if this has been discussed before in this list, I lost 2 weeks of my archives. Jörn From owner-ipsec@lists.tislabs.com Tue Nov 9 13:12:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21395; Tue, 9 Nov 1999 13:12:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24995 Tue, 9 Nov 1999 14:23:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF1F5B5C@exchange> From: Stephane Beaulieu To: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-isakmp-mode-cfg-05.txt Date: Tue, 9 Nov 1999 14:28:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA24992 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Joern, Yes, Roy and I got our messages crossed when we both published v5 of XAUTH and CFG. We will be fixing the problem in the next couple of weeks. Sorry for the inconvenience. Stephane. <-----Original Message----- Date: Wed, 10 Nov 1999 15:13:58 -0500 To: ipsec@lists.tislabs.com Subject: ike and elliptic curves Reply-To: jerome@psti.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hello, i would like to know which vendors implements the elliptics curves group of ike. thanks From owner-ipsec@lists.tislabs.com Wed Nov 10 20:10:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28670; Wed, 10 Nov 1999 20:10:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00854 Wed, 10 Nov 1999 21:11:35 -0500 (EST) Message-Id: <199911110214.VAA28350@india.citi.umich.edu> Subject: Re: ike and elliptic curves From: Niels Provos In-Reply-To: jerome@psti.com, Wed, 10 Nov 1999 15:13:58 EST To: jerome@psti.com Cc: ipsec@lists.tislabs.com Date: Wed, 10 Nov 1999 21:14:29 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <19991110151358.A6224@jerome.psti.com>, jerome@psti.com writes: >i would like to know which vendors implements the elliptics curves >group of ike. The free isakmpd implementation that is part of OpenBSD supports the two specified elliptic curve groups. You can find the sources at http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmp/ There has been concern on this mailing list in the past that the groups might be too small. The two mails that I cound find in my archive refering to that are: <35D380DF.1F7B4A62@Certicom.com> Greetings, Niels. From owner-ipsec@lists.tislabs.com Wed Nov 10 21:49:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA04679; Wed, 10 Nov 1999 21:49:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01141 Wed, 10 Nov 1999 23:15:35 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: jerome@psti.com cc: ipsec@lists.tislabs.com, provos@citi.umich.edu Message-ID: <85256826.00177474.00@domino2.certicom.com> Date: Wed, 10 Nov 1999 20:23:25 -0800 Subject: Re: ike and elliptic curves Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >There has been concern on this mailing list in the past that the >groups might be too small. the groups are not necessarily too small, but of questionable security (they were excluded by ansi and the national institute of standards and technology) and don't align with the fips curves as well. we've actually submitted a draft: draft-ietf-ipsec-ike-ecc-groups-00.txt to address this. cheers - john ---------------------- Forwarded by John Harleman/Certicom on 10.11.1999 20:06 --------------------------- Niels Provos on 10.11.1999 18:14:29 To: jerome@psti.com cc: ipsec@lists.tislabs.com (bcc: John Harleman/Certicom) Subject: Re: ike and elliptic curves In message <19991110151358.A6224@jerome.psti.com>, jerome@psti.com writes: >i would like to know which vendors implements the elliptics curves >group of ike. The free isakmpd implementation that is part of OpenBSD supports the two specified elliptic curve groups. You can find the sources at http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmp/ There has been concern on this mailing list in the past that the groups might be too small. The two mails that I cound find in my archive refering to that are: <35D380DF.1F7B4A62@Certicom.com> Greetings, Niels. From owner-ipsec@lists.tislabs.com Thu Nov 11 07:26:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26287; Thu, 11 Nov 1999 07:26:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02481 Thu, 11 Nov 1999 08:37:39 -0500 (EST) Message-Id: <199911102255.XAA30229@waldorf.appli.se> To: jerome@psti.com cc: ipsec@lists.tislabs.com Subject: Re: ike and elliptic curves In-reply-to: Your message of "Wed, 10 Nov 1999 15:13:58 EST." <19991110151358.A6224@jerome.psti.com> Date: Wed, 10 Nov 1999 23:55:05 +0100 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: jerome@psti.com > Date: Wed, 10 Nov 1999 15:13:58 -0500 > i would like to know which vendors implements the elliptics curves > group of ike. isakmpd in OpenBSD do. I think we interoped with SSH's IKE test site, but I cannot recall ever hearing an interop test with anyone else. As it is not commonly used, it hasn't been optimized, and is therefore pretty slow, defaeating its purpose somehow. Someday I'll go in there and profile it. Niklas From owner-ipsec@lists.tislabs.com Thu Nov 11 08:10:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27143; Thu, 11 Nov 1999 08:10:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02993 Thu, 11 Nov 1999 09:42:06 -0500 (EST) Message-Id: <199911111444.JAA08939@india.citi.umich.edu> Subject: Re: ike and elliptic curves From: Niels Provos In-Reply-To: "John Harleman", Wed, 10 Nov 1999 20:23:25 PST To: "John Harleman" Cc: jerome@psti.com, ipsec@lists.tislabs.com Date: Thu, 11 Nov 1999 09:44:53 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <85256826.00177474.00@domino2.certicom.com>, "John Harleman" writes: >the groups are not necessarily too small, but of questionable security (they >were excluded by ansi and the national institute of standards and technology) >and don't align with the fips curves as well. we've actually submitted a draft Too small meaning the it takes less time to compute the ECDL than to search for a 3DES key. That the groups are defined over subfields is another problem, though not that serious. Greetings, Niels. From owner-ipsec@lists.tislabs.com Thu Nov 11 09:36:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28457; Thu, 11 Nov 1999 09:36:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03112 Thu, 11 Nov 1999 10:20:30 -0500 (EST) Date: Thu, 11 Nov 1999 17:23:20 +0200 (EET) Message-Id: <199911111523.RAA04217@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: jerome@psti.com Cc: ipsec@lists.tislabs.com Subject: ike and elliptic curves In-Reply-To: <19991110151358.A6224@jerome.psti.com> References: <19991110151358.A6224@jerome.psti.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk jerome@psti.com writes: > i would like to know which vendors implements the elliptics curves > group of ike. We (SSH) have a support for them, and our test site (isakmp-test.ssh.fi) also includes them. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Nov 11 11:09:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00475; Thu, 11 Nov 1999 11:09:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03628 Thu, 11 Nov 1999 11:52:25 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Paul Hoffman cc: ipsec@lists.tislabs.com Message-ID: <86256826.005D8CBC.00@mwgate02.mw.3com.com> Date: Thu, 11 Nov 1999 10:50:05 -0600 Subject: Re: RSIP and IPsec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the pointer. We'll be producing a -02 version of the IPSEC draft RSN. At that time I'll post a formal "request for review" to this list. However, comments are always welcome. -Mike Paul Hoffman on 11/05/99 06:22:56 PM Sent by: Paul Hoffman To: ipsec@lists.tislabs.com cc: (Mike Borella/MW/US/3Com) Subject: RSIP and IPsec Pre-DC greetings. There has been almost zero discussion of the RSIP protocol on this mailing list, even though much of the purpose of RSIP is for helping carry IPsec into and out of NATs. People should be aware of this so we can help advise the authors of the protocol. The three relevant drafts are: draft-ietf-nat-rsip-framework-02.txt draft-ietf-nat-rsip-protocol-03.txt draft-ietf-nat-rsip-ipsec-00.txt (As usual, the latest copies are also at the VPNC web site.) The NAT WG is meeting on Monday from 1530-1730, which is the slot after the IPsec WG. The agenda for the NAT WG is at . BTW, I'm not promoting this protocol, just noting that it is being written to answer one of our problems and we don't seem very involved it in. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Nov 11 13:16:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02897; Thu, 11 Nov 1999 13:16:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04456 Thu, 11 Nov 1999 14:31:58 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Paul Fahn" To: Niels Provos cc: ipsec@lists.tislabs.com Message-ID: <85256826.006B56A6.00@domino2.certicom.com> Date: Thu, 11 Nov 1999 11:34:38 -0800 Subject: Re: ike and elliptic curves Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk the original IKE (OAKLEY) groups had elliptic curves over binary fields GF_2^m where m is a composite number. This is considered less secure than using fields GF_2^m where m is a prime number. The new elliptic curve groups recently introduced address those security concerns (as well as align with other standards). See on the IPSec site for details. Paul Niels Provos on 11/11/99 06:44:53 AM To: John Harleman/Certicom@Certicom cc: jerome@psti.com, ipsec@lists.tislabs.com (bcc: Paul Fahn/Certicom) Subject: Re: ike and elliptic curves In message <85256826.00177474.00@domino2.certicom.com>, "John Harleman" writes: >the groups are not necessarily too small, but of questionable security (they >were excluded by ansi and the national institute of standards and technology) >and don't align with the fips curves as well. we've actually submitted a draft Too small meaning the it takes less time to compute the ECDL than to search for a 3DES key. That the groups are defined over subfields is another problem, though not that serious. Greetings, Niels. From owner-ipsec@lists.tislabs.com Thu Nov 11 13:31:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03227; Thu, 11 Nov 1999 13:31:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04627 Thu, 11 Nov 1999 14:50:02 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Bellovin To: ipsec@lists.tislabs.com Subject: Virgil Gligor's iaPCBC paper Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Nov 1999 14:50:13 -0500 Message-Id: <19991111195018.84155ACAE7@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll be hosting Virgil Gligor's paper on iaPCBC on my web site. I'll put it up as soon as I receive it, which will probably be some time tomorrow. It will be on http://www.research.att.com/~smb/papers/iapcbc.ps (and probably .pdf). --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Nov 11 14:34:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04991; Thu, 11 Nov 1999 14:34:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04831 Thu, 11 Nov 1999 16:07:27 -0500 (EST) Message-Id: <199911112108.NAA09445@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Re: IPSEC wg agenda (first draft) In-reply-to: Your message of "Sun, 07 Nov 1999 23:29:13 EST." <199911080429.XAA01846@trampoline.thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9442.942354526.1@network-alchemy.com> Date: Thu, 11 Nov 1999 13:08:46 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 07 Nov 1999 23:29:13 EST you wrote > > One potential topic to add to this list is a status report on the IKE > update work being done by Harkins/Carrel, although since I don't believe > I got an explicit timeslot request for this, it hasn't be included on > the agenda yet. Sorry 'bout that. No explicit timeslot requested and I got to the meeting a little late (I didn't plan on having to wait almost 2 hours to get lunch). The status is that we encorporated most all the requests we got but didn't have enought time to get a new draft out before the I-D cutoff. A new version will be out soon. I belive the DOI is similarly being rev'd. There were issues with RFC2408 as well but I haven't heard from the authors whether they intend on rev'ing that one. Doug are you out there? Dan. From owner-ipsec@lists.tislabs.com Thu Nov 11 18:41:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15887; Thu, 11 Nov 1999 18:41:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05454 Thu, 11 Nov 1999 20:00:46 -0500 (EST) Message-ID: <382B6848.137D418C@ibondinc.com> Date: Thu, 11 Nov 1999 17:07:21 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Deflate Chip vendors Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Anybody aware of any chip vendors who support DEFLATE compression in a chip? Thanks Srini From owner-ipsec@lists.tislabs.com Fri Nov 12 07:31:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17304; Fri, 12 Nov 1999 07:31:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07274 Fri, 12 Nov 1999 08:39:00 -0500 (EST) From: shganguly@hss.hns.com X-Lotus-FromDomain: HSS To: ipsec@lists.tislabs.com Message-ID: <65256827.0022353F.00@sandesh.hss.hns.com> Date: Fri, 12 Nov 1999 11:43:37 +0530 Subject: Some queries regarding IP security Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a couple of issues to be clarified regarding IPsec. First regarding ESP protocol. ESP provides authentication as well as confidentiality. The authentication provided by ESP is not as effective as the one provided by AH. It does not authenticate the IP header, both in transport as well as tunnel (in tunnel mode the new IP header) mode. So my query is why is the feature of authentication provided for in ESP, when it is there in AH which is also better than the one in ESP? Secondly, this is regarding IPsec inbound packet processing. During inbound packet processing, the receiver first matches the packet to its corresponding SAs, does IPsec processing, after this it refers to the SPD to verify whether the ordering of the SAs, the SAs itself that were applied, were correct. If the ordering does not match the packet is rejected. My question is, what is the purpose for the last step. Once the packet has matched the SAs and has undergone IPsec processing successfully what is need to again check from the SPD whether the policy applied is correct. And since SPDs can be big this will lead to some extra processing overhead? ( ref RFC 2401, Page -33, Section 5.2.1, Step 4) -Shamik From owner-ipsec@lists.tislabs.com Fri Nov 12 10:09:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19161; Fri, 12 Nov 1999 10:09:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07844 Fri, 12 Nov 1999 11:42:24 -0500 (EST) Message-Id: <1.5.4.32.19991112162527.0170dcf0@hub.ecutel.com> X-Sender: qzhang@hub.ecutel.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1999 11:25:27 -0500 To: shganguly@hss.hns.com From: Qiang Zhang Subject: Re: Some queries regarding IP security Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, To me the ESP's AH trailor is an alternative so that it is not necessary to have adjacent (AH + ESP) bundles regarding the IKE and your SA database's effort to keep them. SP should be verified after inbound processing, I can think of an example: if somebody else (not the peer sends a fake packet, say ESP transport-mode encryption only and happenly this fits into what the inbound SA says, then you decrypt it(decryption is silent, it might just a junk data in there) and would accept it (if not consulting the policy). Thus it is a kind of DoS attack. The SP will be the last protection, just like a packet filtering. Correct me... Regards, Qiang At 11:43 AM 11/12/99 +0530, shganguly@hss.hns.com wrote: > > > >Hi, > >I have a couple of issues to be clarified regarding IPsec. > >First regarding ESP protocol. ESP provides authentication as well >as confidentiality. The authentication provided by ESP is not as >effective as the one provided by AH. It does not authenticate the >IP header, both in transport as well as tunnel (in tunnel mode the new >IP header) mode. So my query is why is the feature of authentication >provided for in ESP, when it is there in AH which is also better than the >one in ESP? > >Secondly, this is regarding IPsec inbound packet processing. During >inbound packet processing, the receiver first matches the packet to its >corresponding SAs, does IPsec processing, after this it refers to the SPD >to verify whether the ordering of the SAs, the SAs itself that were applied, >were correct. If the ordering does not match the packet is rejected. My >question is, what is the purpose for the last step. Once the >packet has matched the SAs and has undergone IPsec processing >successfully what is need to again check from the SPD whether the >policy applied is correct. And since SPDs can be big this will lead to >some extra processing overhead? ( ref RFC 2401, Page -33, Section 5.2.1, >Step 4) > >-Shamik > > > > > -Qiang 1100 Warnings! --Line 100000: 3 cokes shut down your immune system for 24 hours, so stay away from sodas! From owner-ipsec@lists.tislabs.com Fri Nov 12 10:12:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19233; Fri, 12 Nov 1999 10:12:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07829 Fri, 12 Nov 1999 11:40:33 -0500 (EST) Date: Fri, 12 Nov 1999 11:43:28 -0500 Message-Id: <199911121643.LAA08300@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: shganguly@hss.hns.com Cc: ipsec@lists.tislabs.com Subject: Re: Some queries regarding IP security References: <65256827.0022353F.00@sandesh.hss.hns.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "shganguly" == shganguly writes: shganguly> Hi, shganguly> I have a couple of issues to be clarified regarding IPsec. shganguly> First regarding ESP protocol. ESP provides authentication shganguly> as well as confidentiality. The authentication provided by shganguly> ESP is not as effective as the one provided by AH. It does shganguly> not authenticate the IP header, both in transport as well shganguly> as tunnel (in tunnel mode the new IP header) mode. So my shganguly> query is why is the feature of authentication provided for shganguly> in ESP, when it is there in AH which is also better than shganguly> the one in ESP? I don't know all the history, but here's one view: for tunnel mode at least, the authentication provided by ESP is sufficient. The added checks that AH provides then are not needed. And ESP authentication is much easier to do in hardware with a single pass than AH. In particular, if compression is used, you *cannot* do AH in the same pass as IPCOMP/ESP. paul From owner-ipsec@lists.tislabs.com Fri Nov 12 10:53:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19745; Fri, 12 Nov 1999 10:53:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07997 Fri, 12 Nov 1999 12:35:40 -0500 (EST) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B372@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'shganguly@hss.hns.com'" , ipsec@lists.tislabs.com Subject: RE: Some queries regarding IP security Date: Fri, 12 Nov 1999 09:38:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I will not speak to the differences between the authentication between AH and ESP, however there are different security threats that are covered by each of these headers... As for why you check the SPD after correctly decrypting the packet try this scenario I want you to have access to several mounts on my machine (securely of course) so I grant you access to the NFS/SMB ports of my machine... However I do not want you to have access to some other protocol on my machine, SMTP, HTTP, or something... I can easily negotiate a SA between our machines for the first case that will allow you to talk to my NFS port, however being the willey hacker that you are, you start sending traffic to the SMTP port using the SPI negotiated for the NFS port. I can not tell which port you are destined for until the packet is decrypted, so I apply (unapply) the SAs and get a IP packet out of it. I MUST check to see if the ports that you are destined to apply under the SPI that you sent the packet, or my machine is wide open to ANYONE that can negotiate on ANY port. Does a concrete threat help, or do you want a more abstract threat analysis... Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: shganguly@hss.hns.com [mailto:shganguly@hss.hns.com] > Sent: Thursday, November 11, 1999 10:14 PM > To: ipsec@lists.tislabs.com > Subject: Some queries regarding IP security > > > > > > Hi, > > I have a couple of issues to be clarified regarding IPsec. > > First regarding ESP protocol. ESP provides authentication as well > as confidentiality. The authentication provided by ESP is not as > effective as the one provided by AH. It does not authenticate the > IP header, both in transport as well as tunnel (in tunnel mode the new > IP header) mode. So my query is why is the feature of authentication > provided for in ESP, when it is there in AH which is also > better than the > one in ESP? > > Secondly, this is regarding IPsec inbound packet processing. During > inbound packet processing, the receiver first matches the > packet to its > corresponding SAs, does IPsec processing, after this it > refers to the SPD > to verify whether the ordering of the SAs, the SAs itself > that were applied, > were correct. If the ordering does not match the packet is > rejected. My > question is, what is the purpose for the last step. Once the > packet has matched the SAs and has undergone IPsec processing > successfully what is need to again check from the SPD whether the > policy applied is correct. And since SPDs can be big this will lead to > some extra processing overhead? ( ref RFC 2401, Page -33, > Section 5.2.1, > Step 4) > > -Shamik > > > From owner-ipsec@lists.tislabs.com Fri Nov 12 14:33:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22305; Fri, 12 Nov 1999 14:33:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08786 Fri, 12 Nov 1999 16:00:10 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 12 Nov 1999 13:58:28 -0700 From: "Hilarie Orman" To: , Cc: , Subject: Re: ike and elliptic curves Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA08782 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If wishes were crypto bits, we'd all have zillion bit keys. The question of whether or not an IKE group is strong enough to protect a 3DES key seems to depend on what the overall security and performance goals are. The bottom line is that the numbers used for the Diffie-Hellman computations must be as small as possible, because the performance is dominated by the cost of the basic arithmetic operations. If this weren't such a computationally costly operation, we'd just use 20K bits for the regular groups and a few hundred for the elliptic curve groups. But, it isn't so, and it is necessary to find just the right balance point. Now, how strong should the key exchange for a 3DES key really be? The effective key strength for 3DES is 112 bits. Who chose that number? It's only a happenstance, because 56 is too short and the simplest way to get to anything stronger is to use 2*56. Then comes the bottom line question: is 112 the minimum requirement for protecting the data? If it isn't, if 80 or 90 bits is the security requirement, then a key exchange that matches the lesser strength is perfectly OK. And that means that the DH key exchange can be much faster. A NRC report of a couple of years ago recommended 90 bits, I believe, as a reasonable default value for data protection. I'm more concerned about reports I've heard that some of the elliptic curve implementations are quite slow. I'm extremely puzzled about how that could come about, being as there is a reasonable amount of literature on how to code up fast routines. Hilarie From owner-ipsec@lists.tislabs.com Fri Nov 12 16:13:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23553; Fri, 12 Nov 1999 16:13:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09089 Fri, 12 Nov 1999 17:48:45 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: "Hilarie Orman" cc: provos@citi.umich.edu, ipsec@lists.tislabs.com, jerome@psti.com Message-ID: <85256827.007D5C91.00@domino2.certicom.com> Date: Fri, 12 Nov 1999 14:46:35 -0800 Subject: Re: ike and elliptic curves Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie: Now, how strong should the key exchange for a 3DES Hilarie: key really be? The effective key strength for 3DES Hilarie: is 112 bits. Who chose that number? It's only a Hilarie: happenstance, because 56 is too short and the Hilarie: simplest way to get to anything stronger is to Hilarie: use 2*56. Agreed that key sizes should be choosen based upon best known attacks and the desire to protect data; however, while 112 may have been choosen since it was next logical step after 56-bits, I see many systems out there advertising 168-bit security. In these cases, the asymettric key sizes needs to correspond in strength to the symettric key ones or it is simply a marketing ploy. This will also be readily apparent with aes coming on-line with key strengths of 128, 192, and 256 bits. "Hilarie Orman" on 12.11.1999 12:58:28 To: provos@citi.umich.edu, John Harleman/Certicom@Certicom cc: ipsec@lists.tislabs.com, jerome@psti.com Subject: Re: ike and elliptic curves If wishes were crypto bits, we'd all have zillion bit keys. The question of whether or not an IKE group is strong enough to protect a 3DES key seems to depend on what the overall security and performance goals are. The bottom line is that the numbers used for the Diffie-Hellman computations must be as small as possible, because the performance is dominated by the cost of the basic arithmetic operations. If this weren't such a computationally costly operation, we'd just use 20K bits for the regular groups and a few hundred for the elliptic curve groups. But, it isn't so, and it is necessary to find just the right balance point. Now, how strong should the key exchange for a 3DES key really be? The effective key strength for 3DES is 112 bits. Who chose that number? It's only a happenstance, because 56 is too short and the simplest way to get to anything stronger is to use 2*56. Then comes the bottom line question: is 112 the minimum requirement for protecting the data? If it isn't, if 80 or 90 bits is the security requirement, then a key exchange that matches the lesser strength is perfectly OK. And that means that the DH key exchange can be much faster. A NRC report of a couple of years ago recommended 90 bits, I believe, as a reasonable default value for data protection. I'm more concerned about reports I've heard that some of the elliptic curve implementations are quite slow. I'm extremely puzzled about how that could come about, being as there is a reasonable amount of literature on how to code up fast routines. Hilarie From owner-ipsec@lists.tislabs.com Fri Nov 12 17:30:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24173; Fri, 12 Nov 1999 17:30:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09210 Fri, 12 Nov 1999 18:44:36 -0500 (EST) From: Sheela Rowles Message-Id: <199911122347.PAA12146@sigma.cisco.com> Subject: aggressive mode & draft-ietf-ipsec-isakmp-gss-auth-04.txt To: ipsec@lists.tislabs.com Date: Fri, 12 Nov 1999 15:47:06 -0800 (PST) Cc: srowles@cisco.com (Sheela Rowles) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have a question regarding the gssapi spec: draft-ietf-ipsec-isakmp-gss-auth-04.txt. It doesn't seem like aggressive mode can work based on the comments in the draft, yet the draft implies that aggressive mode is possible. The draft comments that aggressive mode works for a single token exchange, and if either side encounters GSS_S_CONTINUE_NEEDED, aggressive mode can't be used: "Aggressive Mode works only for a single token exchange. If either side encounters GSS_S_CONTINUE_NEEDED, Aggressive Mode cannot be used and each side should fall back to Main Mode." And for mutual authentication to occur, the mutual_req_flag should be specified to the GSS_Init_sec_context on the initiating side. Rfc2078, the GSSAPI document, specifies that: "GSS_Init_sec_context() returns an output token to be passed to ther server, and indicates GSS_S_CONTINUE_NEEDED status pending completion of the mutual authentication sequence." So, according to the GSS IKE draft, if GSS_S_CONTINUE_NEEDED is encountered then aggressive mode can't be used, and if mutual authentication is specified, then according to the GSSAPI spec, GSS_S_CONTINUE_NEEDED must be returned from the GSS_Init_sec_context. Am I reading too much into the above comments? Is the implication that if the CONTINUE_NEEDED variable is encountered due to clock skew issues, then aggressive mode is not possible, but it's ok if it's encountered due to needing mutual authentication. So, in the normal aggressive mode case based on the last statement, we would have: Initiator Responder ----------- ----------- GSS_Init_sec_context returning GSS_S_CONTINUE_NEEDED HDR, SA, KE, Ni, IDii, GSSi --> GSS_Accept_sec_context returning GSS_S_COMPLETE <-- HDR, SA, KE, Nr, IDir, GSSr, HASH_R GSS_Init_sec_context returning GSS_S_COMPLETE HDR, HASH_I --> Thanks, Sheela From owner-ipsec@lists.tislabs.com Sat Nov 13 10:41:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21658; Sat, 13 Nov 1999 10:41:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12452 Sat, 13 Nov 1999 12:04:37 -0500 (EST) Message-Id: <199911121834.NAA00262@thunk.epilogue.com> From: Bill Sommerfeld To: shganguly@hss.hns.com cc: ipsec@lists.tislabs.com Subject: Re: Some queries regarding IP security In-Reply-To: Message from shganguly@hss.hns.com of "Fri, 12 Nov 1999 11:43:37 +0530." <65256827.0022353F.00@sandesh.hss.hns.com> Date: Fri, 12 Nov 1999 13:34:16 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Secondly, this is regarding IPsec inbound packet processing. During > inbound packet processing, the receiver first matches the packet to its > corresponding SAs, does IPsec processing, after this it refers to the SPD > to verify whether the ordering of the SAs, the SAs itself that were applied, > were correct. If the ordering does not match the packet is rejected. My > question is, what is the purpose for the last step. Once the > packet has matched the SAs and has undergone IPsec processing > successfully what is need to again check from the SPD whether the > policy applied is correct. assume you're a security gateway, and have tunnels to two different peers, A and B. If you don't do the SPD check after decapsulating/decrypting the packet, it is trivial for peer B to impersonate peer A and vice versa. - Bi From owner-ipsec@lists.tislabs.com Sat Nov 13 15:15:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23240; Sat, 13 Nov 1999 15:15:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12874 Sat, 13 Nov 1999 16:26:47 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7A8C3@exchange> From: Andrew Krywaniuk To: "Strahm, Bill" , "'shganguly@hss.hns.com'" , ipsec@lists.tislabs.com Subject: RE: Some queries regarding IP security Date: Sat, 13 Nov 1999 16:32:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think you guys are missing the point of Shamik was asking. Of course you have to check the SPD for every packet to verify the IPs, ports, etc., but he was asking specifically about verifying the order of SAs in a bundle. I.e. if you negotiate to do IPCOMP ESP AH and the other guy sends you a packet with ESP AH IPCOMP (not that this order makes any sense), should you drop the packet? I seem to remember that this was an issue about 6 months ago, but I'm not sure what conclusion, if any, was reached. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Strahm, Bill [mailto:bill.strahm@intel.com] > Sent: Friday, November 12, 1999 12:39 PM > To: 'shganguly@hss.hns.com'; ipsec@lists.tislabs.com > Subject: RE: Some queries regarding IP security > > > I will not speak to the differences between the > authentication between AH > and ESP, however there are different security threats that > are covered by > each of these headers... > > As for why you check the SPD after correctly decrypting the > packet try this > scenario > > I want you to have access to several mounts on my machine (securely of > course) so I grant you access to the NFS/SMB ports of my machine... > > However I do not want you to have access to some other protocol on my > machine, SMTP, HTTP, or something... > > I can easily negotiate a SA between our machines for the > first case that > will allow you to talk to my NFS port, however being the > willey hacker that > you are, you start sending traffic to the SMTP port using the > SPI negotiated > for the NFS port. > > I can not tell which port you are destined for until the packet is > decrypted, so I apply (unapply) the SAs and get a IP packet > out of it. I > MUST check to see if the ports that you are destined to apply > under the SPI > that you sent the packet, or my machine is wide open to > ANYONE that can > negotiate on ANY port. > > Does a concrete threat help, or do you want a more abstract threat > analysis... > > Bill > ______________________________________________ > Bill Strahm Programming today is a race between > bill.strahm@ software engineers striving to build > intel.com bigger and better idiot-proof programs, > (503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook > I am not speaking for Intel. And Intel rarely speaks for me > > > > -----Original Message----- > > From: shganguly@hss.hns.com [mailto:shganguly@hss.hns.com] > > Sent: Thursday, November 11, 1999 10:14 PM > > To: ipsec@lists.tislabs.com > > Subject: Some queries regarding IP security > > > > > > > > > > > > Hi, > > > > I have a couple of issues to be clarified regarding IPsec. > > > > First regarding ESP protocol. ESP provides authentication as well > > as confidentiality. The authentication provided by ESP is not as > > effective as the one provided by AH. It does not authenticate the > > IP header, both in transport as well as tunnel (in tunnel > mode the new > > IP header) mode. So my query is why is the feature of authentication > > provided for in ESP, when it is there in AH which is also > > better than the > > one in ESP? > > > > Secondly, this is regarding IPsec inbound packet processing. During > > inbound packet processing, the receiver first matches the > > packet to its > > corresponding SAs, does IPsec processing, after this it > > refers to the SPD > > to verify whether the ordering of the SAs, the SAs itself > > that were applied, > > were correct. If the ordering does not match the packet is > > rejected. My > > question is, what is the purpose for the last step. Once the > > packet has matched the SAs and has undergone IPsec processing > > successfully what is need to again check from the SPD whether the > > policy applied is correct. And since SPDs can be big this > will lead to > > some extra processing overhead? ( ref RFC 2401, Page -33, > > Section 5.2.1, > > Step 4) > > > > -Shamik > > > > > > > From owner-ipsec@lists.tislabs.com Sun Nov 14 18:30:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26031; Sun, 14 Nov 1999 18:30:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16186 Sun, 14 Nov 1999 19:36:37 -0500 (EST) Message-ID: <51C0AF25889FD211AC3F00A0C984090DC0BE30@orsmsx50.jf.intel.com> From: "Saint-Hilaire, Ylian" To: ipsec@lists.tislabs.com, "'gab@sun.com'" , "'Mike Borella'" Subject: IKE negotiation/rekeying problem with RSIP Date: Sun, 14 Nov 1999 16:39:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is a possible problem IKE initiation/rekeying over RSIP. If two inner computers use an RSIP gateway to establish IPsec sessions to one destination, the destination computers will see 2 IKE phase1's from the gateway. If the destination computer ever needs to rekey a phase 2 or negotiate a new phase 2, he may select an incorrect phase 1 to negotiate with. Here is an example: A ---> +---------+ | Gateway | ---> C B ---> +---------+ A negotiates a phase 1 with C using the gateway (called phase 1a) A negotiates a phase 2 with C using the phase 1a (called phase 2a) B negotiates a phase 1 with C using the gateway (called phase 1b) B negotiates a phase 2 with C using the phase 1b (called phase 2b) The lifetime of phase 2a is about to expire; C wants to negotiate a new SA before phase 1a expires completely. Since phase 1a is established to G (the gateway), C looks in his state table for a phase 1 he could re-use to G, he finds Phase1b and uses it to negotiate. The new phase2 negotiation is encrypted end-to-end from B to C. The gateway cannot do anything about it, he forwards the packets based on the cookies in the header. B will receive a negotiation intended to go to A and may or may not accept it. I would note that this example is likely to happen. In IKE the responder may have a phase 2 SA lifetime lower than the initiator without the initiator knowing. In this case, the responder will be the one re-keying and causing the problem. This problem could also occur frequently if the initiator only negotiates SA's with very specific ports/protocols. The destination could be unable to reply back since all it's SA's are negotiated to the wrong computer inside the gateway. I also note that the phase 1 selection process varies from an IKE implementation to another. I don't have any simple solution that come to mind, maybe this is out of scope or we can live with this. Ylian Saint-Hilaire INTEL - Communication Architecture Labs From owner-ipsec@lists.tislabs.com Sun Nov 14 20:41:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04196; Sun, 14 Nov 1999 20:41:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16493 Sun, 14 Nov 1999 22:01:11 -0500 (EST) Message-Id: <199911150304.WAA20042@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: Your message of "Sun, 14 Nov 1999 16:39:34 PST." <51C0AF25889FD211AC3F00A0C984090DC0BE30@orsmsx50.jf.intel.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 14 Nov 1999 22:04:09 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian writes: Saint-Hilaire,> There is a possible problem IKE initiation/rekeying over Saint-Hilaire,> RSIP. If two inner computers use an RSIP gateway to Saint-Hilaire,> establish IPsec sessions to one destination, the Saint-Hilaire,> destination computers will see 2 IKE phase1's from the 1) this in itself may be a problem for some gateways. Saint-Hilaire,> gateway. If the destination computer ever needs to rekey Saint-Hilaire,> a phase 2 or negotiate a new phase 2, he may select an Saint-Hilaire,> incorrect phase 1 to negotiate with. 2) worse, they can't both get UDP port 500. There are choices to resolve this: a) permit initiators to use other than port 500, and have the remote gateway respond to the correct port. b) have the gateway demux based upon cookies instead of port numbers. This makes the gateway aware of IKE, but it needs to know proto 50/51 anyway. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Sun Nov 14 21:11:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA04791; Sun, 14 Nov 1999 21:11:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16579 Sun, 14 Nov 1999 22:49:11 -0500 (EST) From: shganguly@hss.hns.com X-Lotus-FromDomain: HSS To: Andrew Krywaniuk cc: "Strahm, Bill" , ipsec@lists.tislabs.com Message-ID: <6525682A.0014B964.00@sandesh.hss.hns.com> Date: Mon, 15 Nov 1999 09:16:21 +0530 Subject: RE: Some queries regarding IP security Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was mainly concerned with checking the order of SA application from SPD. My point is if your order is not right you will not get back the original packet anyway. So what is the point of rechecking it from the SPD. -Shamik Hughes Software Systems, India Andrew Krywaniuk on 11/14/99 03:02:14 AM To: "Strahm, Bill" , Shamik Ganguly/HSS@HSS, ipsec@lists.tislabs.com cc: Subject: RE: Some queries regarding IP security I think you guys are missing the point of Shamik was asking. Of course you have to check the SPD for every packet to verify the IPs, ports, etc., but he was asking specifically about verifying the order of SAs in a bundle. I.e. if you negotiate to do IPCOMP ESP AH and the other guy sends you a packet with ESP AH IPCOMP (not that this order makes any sense), should you drop the packet? I seem to remember that this was an issue about 6 months ago, but I'm not sure what conclusion, if any, was reached. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Strahm, Bill [mailto:bill.strahm@intel.com] > Sent: Friday, November 12, 1999 12:39 PM > To: 'shganguly@hss.hns.com'; ipsec@lists.tislabs.com > Subject: RE: Some queries regarding IP security > > > I will not speak to the differences between the > authentication between AH > and ESP, however there are different security threats that > are covered by > each of these headers... > > As for why you check the SPD after correctly decrypting the > packet try this > scenario > > I want you to have access to several mounts on my machine (securely of > course) so I grant you access to the NFS/SMB ports of my machine... > > However I do not want you to have access to some other protocol on my > machine, SMTP, HTTP, or something... > > I can easily negotiate a SA between our machines for the > first case that > will allow you to talk to my NFS port, however being the > willey hacker that > you are, you start sending traffic to the SMTP port using the > SPI negotiated > for the NFS port. > > I can not tell which port you are destined for until the packet is > decrypted, so I apply (unapply) the SAs and get a IP packet > out of it. I > MUST check to see if the ports that you are destined to apply > under the SPI > that you sent the packet, or my machine is wide open to > ANYONE that can > negotiate on ANY port. > > Does a concrete threat help, or do you want a more abstract threat > analysis... > > Bill > ______________________________________________ > Bill Strahm Programming today is a race between > bill.strahm@ software engineers striving to build > intel.com bigger and better idiot-proof programs, > (503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook > I am not speaking for Intel. And Intel rarely speaks for me > > > > -----Original Message----- > > From: shganguly@hss.hns.com [mailto:shganguly@hss.hns.com] > > Sent: Thursday, November 11, 1999 10:14 PM > > To: ipsec@lists.tislabs.com > > Subject: Some queries regarding IP security > > > > > > > > > > > > Hi, > > > > I have a couple of issues to be clarified regarding IPsec. > > > > First regarding ESP protocol. ESP provides authentication as well > > as confidentiality. The authentication provided by ESP is not as > > effective as the one provided by AH. It does not authenticate the > > IP header, both in transport as well as tunnel (in tunnel > mode the new > > IP header) mode. So my query is why is the feature of authentication > > provided for in ESP, when it is there in AH which is also > > better than the > > one in ESP? > > > > Secondly, this is regarding IPsec inbound packet processing. During > > inbound packet processing, the receiver first matches the > > packet to its > > corresponding SAs, does IPsec processing, after this it > > refers to the SPD > > to verify whether the ordering of the SAs, the SAs itself > > that were applied, > > were correct. If the ordering does not match the packet is > > rejected. My > > question is, what is the purpose for the last step. Once the > > packet has matched the SAs and has undergone IPsec processing > > successfully what is need to again check from the SPD whether the > > policy applied is correct. And since SPDs can be big this > will lead to > > some extra processing overhead? ( ref RFC 2401, Page -33, > > Section 5.2.1, > > Step 4) > > > > -Shamik > > > > > > > From owner-ipsec@lists.tislabs.com Mon Nov 15 00:34:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06492; Mon, 15 Nov 1999 00:34:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17070 Mon, 15 Nov 1999 02:08:56 -0500 (EST) Date: Mon, 15 Nov 1999 09:10:29 +0200 (EET) From: Devrim Unal To: shganguly@hss.hns.com cc: Andrew Krywaniuk , "Strahm, Bill" , ipsec@lists.tislabs.com Subject: RE: Some queries regarding IP security In-Reply-To: <6525682A.0014B964.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shamik, It is not correct that you'll not get the message when the order does not match the SPD. This is because you don't look at the SPD until you get the clear tunnelled packet. You just process the received tunnel packet according to the sa you found by the help of the tuple from the packet, not the SPD. Someone may send you a packet with only ESP without AH when it also requires AH. You'll simply decrypt the packet and let it go without authentication if you do not check all the sa's referred from the SPD. Regards D. Unal National Institute of Scientific and Technological Research of Turkey On Mon, 15 Nov 1999 shganguly@hss.hns.com wrote: > > > > I was mainly concerned with checking the order of SA application from SPD. > My point is if your order is not right you will not get back the original packet > anyway. So what is the point of rechecking it from the SPD. > > -Shamik > Hughes Software Systems, India > > > > > > Andrew Krywaniuk on 11/14/99 03:02:14 AM > > To: "Strahm, Bill" , Shamik Ganguly/HSS@HSS, > ipsec@lists.tislabs.com > cc: > > Subject: RE: Some queries regarding IP security > > > > > I think you guys are missing the point of Shamik was asking. Of course you > have to check the SPD for every packet to verify the IPs, ports, etc., but > he was asking specifically about verifying the order of SAs in a bundle. > > I.e. if you negotiate to do IPCOMP ESP AH and the other guy sends you a > packet with ESP AH IPCOMP (not that this order makes any sense), should you > drop the packet? > > I seem to remember that this was an issue about 6 months ago, but I'm not > sure what conclusion, if any, was reached. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: Strahm, Bill [mailto:bill.strahm@intel.com] > > Sent: Friday, November 12, 1999 12:39 PM > > To: 'shganguly@hss.hns.com'; ipsec@lists.tislabs.com > > Subject: RE: Some queries regarding IP security > > > > > > I will not speak to the differences between the > > authentication between AH > > and ESP, however there are different security threats that > > are covered by > > each of these headers... > > > > As for why you check the SPD after correctly decrypting the > > packet try this > > scenario > > > > I want you to have access to several mounts on my machine (securely of > > course) so I grant you access to the NFS/SMB ports of my machine... > > > > However I do not want you to have access to some other protocol on my > > machine, SMTP, HTTP, or something... > > > > I can easily negotiate a SA between our machines for the > > first case that > > will allow you to talk to my NFS port, however being the > > willey hacker that > > you are, you start sending traffic to the SMTP port using the > > SPI negotiated > > for the NFS port. > > > > I can not tell which port you are destined for until the packet is > > decrypted, so I apply (unapply) the SAs and get a IP packet > > out of it. I > > MUST check to see if the ports that you are destined to apply > > under the SPI > > that you sent the packet, or my machine is wide open to > > ANYONE that can > > negotiate on ANY port. > > > > Does a concrete threat help, or do you want a more abstract threat > > analysis... > > > > Bill > > ______________________________________________ > > Bill Strahm Programming today is a race between > > bill.strahm@ software engineers striving to build > > intel.com bigger and better idiot-proof programs, > > (503) 264-4632 and the Universe trying to produce > > bigger and better idiots. So far, the > > Universe is winning.--Rich Cook > > I am not speaking for Intel. And Intel rarely speaks for me > > > > > > > -----Original Message----- > > > From: shganguly@hss.hns.com [mailto:shganguly@hss.hns.com] > > > Sent: Thursday, November 11, 1999 10:14 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Some queries regarding IP security > > > > > > > > > > > > > > > > > > Hi, > > > > > > I have a couple of issues to be clarified regarding IPsec. > > > > > > First regarding ESP protocol. ESP provides authentication as well > > > as confidentiality. The authentication provided by ESP is not as > > > effective as the one provided by AH. It does not authenticate the > > > IP header, both in transport as well as tunnel (in tunnel > > mode the new > > > IP header) mode. So my query is why is the feature of authentication > > > provided for in ESP, when it is there in AH which is also > > > better than the > > > one in ESP? > > > > > > Secondly, this is regarding IPsec inbound packet processing. During > > > inbound packet processing, the receiver first matches the > > > packet to its > > > corresponding SAs, does IPsec processing, after this it > > > refers to the SPD > > > to verify whether the ordering of the SAs, the SAs itself > > > that were applied, > > > were correct. If the ordering does not match the packet is > > > rejected. My > > > question is, what is the purpose for the last step. Once the > > > packet has matched the SAs and has undergone IPsec processing > > > successfully what is need to again check from the SPD whether the > > > policy applied is correct. And since SPDs can be big this > > will lead to > > > some extra processing overhead? ( ref RFC 2401, Page -33, > > > Section 5.2.1, > > > Step 4) > > > > > > -Shamik > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Nov 15 08:43:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17631; Mon, 15 Nov 1999 08:43:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18410 Mon, 15 Nov 1999 09:53:00 -0500 (EST) Date: Mon, 15 Nov 1999 09:55:42 -0500 Message-Id: <199911151455.JAA19264@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: akrywaniuk@TimeStep.com Cc: bill.strahm@intel.com, shganguly@hss.hns.com, ipsec@lists.tislabs.com Subject: RE: Some queries regarding IP security References: <319A1C5F94C8D11192DE00805FBBADDFF7A8C3@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> I think you guys are missing the point of Shamik was Andrew> asking. Of course you have to check the SPD for every packet Andrew> to verify the IPs, ports, etc., but he was asking Andrew> specifically about verifying the order of SAs in a bundle. Andrew> I.e. if you negotiate to do IPCOMP ESP AH and the other guy Andrew> sends you a packet with ESP AH IPCOMP (not that this order Andrew> makes any sense), should you drop the packet? Yes, you should. Chances are you will not so much because of a policy that says "accept only what you negotiated" but simply because the implementation flat out refuses to accept weird transform orders like that. paul From owner-ipsec@lists.tislabs.com Mon Nov 15 14:34:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22268; Mon, 15 Nov 1999 14:34:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20025 Mon, 15 Nov 1999 15:37:24 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: "Michael C. Richardson" cc: ipsec@lists.tislabs.com Message-ID: <8625682A.00727329.00@mwgate02.mw.3com.com> Date: Mon, 15 Nov 1999 14:38:51 -0600 Subject: Re: IKE negotiation/rekeying problem with RSIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Point (2): - IMO, IKE should be allowed to choose an ephemeral port just like any other application. Is there a reason why this isn't the case? - We currently specify exactly that - looking at i-cookies to differentiate clients. -Mike "Michael C. Richardson" on 11/14/99 09:04:09 PM Sent by: "Michael C. Richardson" To: ipsec@lists.tislabs.com cc: (Mike Borella/MW/US/3Com) Subject: Re: IKE negotiation/rekeying problem with RSIP >>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian writes: Saint-Hilaire,> There is a possible problem IKE initiation/rekeying over Saint-Hilaire,> RSIP. If two inner computers use an RSIP gateway to Saint-Hilaire,> establish IPsec sessions to one destination, the Saint-Hilaire,> destination computers will see 2 IKE phase1's from the 1) this in itself may be a problem for some gateways. Saint-Hilaire,> gateway. If the destination computer ever needs to rekey Saint-Hilaire,> a phase 2 or negotiate a new phase 2, he may select an Saint-Hilaire,> incorrect phase 1 to negotiate with. 2) worse, they can't both get UDP port 500. There are choices to resolve this: a) permit initiators to use other than port 500, and have the remote gateway respond to the correct port. b) have the gateway demux based upon cookies instead of port numbers. This makes the gateway aware of IKE, but it needs to know proto 50/51 anyway. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Mon Nov 15 15:10:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22849; Mon, 15 Nov 1999 15:10:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20383 Mon, 15 Nov 1999 16:42:03 -0500 (EST) Date: Mon, 15 Nov 1999 23:44:49 +0200 (EET) Message-Id: <199911152144.XAA18783@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Mike Borella" Cc: "Michael C. Richardson" , ipsec@lists.tislabs.com Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: <8625682A.00727329.00@mwgate02.mw.3com.com> References: <8625682A.00727329.00@mwgate02.mw.3com.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike Borella writes: > - IMO, IKE should be allowed to choose an ephemeral port just like any other > application. Is there a reason why this isn't the case? Mostly because the draft authors wanted to make things easy for the implementators and testing. No need to ask from the other which port they use because everybody must be able to support port 500. RFC2408 does not limit that the port 500 must be the only one to be support, it just says that at least that must be supported. I think most of the implementations have support for answering to different port than port 500 (i.e the initiator sends packet from port xxxx to 500, and responder is sending back packets to port xxxx instead of 500). Quite a lot of implementations have support for specifying the server port. Here is a relevant part of the RFC2408: ---------------------------------------------------------------------- 2.5.1 Transport Protocol ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbers Authority (IANA). Implementations MAY additionally support ISAKMP over other transport protocols or over IP itself. ---------------------------------------------------------------------- -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Nov 15 15:18:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22963; Mon, 15 Nov 1999 15:18:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20119 Mon, 15 Nov 1999 15:55:27 -0500 (EST) Message-ID: <383073BA.983A2436@nt.com> Date: Mon, 15 Nov 1999 15:57:30 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: A test Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, I just needed to test my subscription. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Mon Nov 15 15:27:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23226; Mon, 15 Nov 1999 15:27:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20018 Mon, 15 Nov 1999 15:36:40 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: "Saint-Hilaire, Ylian" cc: ipsec@lists.tislabs.com, "'gab@sun.com'" , nat@livingston.com, "David Grabelsky" Message-ID: <8625682A.00724DB9.00@mwgate02.mw.3com.com> Date: Mon, 15 Nov 1999 14:37:16 -0600 Subject: Re: IKE negotiation/rekeying problem with RSIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let's try to scope the problem. - The reason that the two phase 1's are identical to C is because the identity of the initiator can only be determined by the IP address of the gateway (assuming preshared keys and main mode). This suggests a number of work arounds: 1) Don't use pre-shared keys. Problem: many current implementations only use pre-shared keys 2) Use aggressive rather than main mode. Problems: No group negotiation, responders may not implement (or prefer) aggressive mode). 3) Allocate an IP address per initiator (RSA-IP method). Problem: If we can do this, then RSIP itself may be overkill. - It makes no sense to use preshared keys with RSIP/IPSEC in any case. If we have n identities sharing the same IP address such that they can only be differentiated by the port numbers that they use and/or out of band authentication such as public keys, then *there is no way* for the responder to tell these n identities apart. Since RSIP is meant to be used in situations where a roaming client plugs into a LAN and shares the gateway's IP with other roaming clients, we need something other than the gateway's IP for authentication. - For phase 2, we can still negotiate on a port-by-port (socket-by-socket) basis and since gateway-side ports are tied to IDs, this should work. This whole problem is a reiteration of the IPSEC remote access problem with respect to preshared keys. I think that the RSIP/IPSEC draft should document the issues and explain where RSIP / IPSEC will not work, but it is not in our scope to solve this problem. Yet another reason to speed the move from preshared keys and IP based authentication to something better. -Mike "Saint-Hilaire, Ylian" on 11/14/99 06:39:34 PM Sent by: "Saint-Hilaire, Ylian" To: ipsec@lists.tislabs.com, "'gab @sun.com'" , Mike Borella/MW/US/3Com cc: Subject: IKE negotiation/rekeying problem with RSIP There is a possible problem IKE initiation/rekeying over RSIP. If two inner computers use an RSIP gateway to establish IPsec sessions to one destination, the destination computers will see 2 IKE phase1's from the gateway. If the destination computer ever needs to rekey a phase 2 or negotiate a new phase 2, he may select an incorrect phase 1 to negotiate with. Here is an example: A ---> +---------+ | Gateway | ---> C B ---> +---------+ A negotiates a phase 1 with C using the gateway (called phase 1a) A negotiates a phase 2 with C using the phase 1a (called phase 2a) B negotiates a phase 1 with C using the gateway (called phase 1b) B negotiates a phase 2 with C using the phase 1b (called phase 2b) The lifetime of phase 2a is about to expire; C wants to negotiate a new SA before phase 1a expires completely. Since phase 1a is established to G (the gateway), C looks in his state table for a phase 1 he could re-use to G, he finds Phase1b and uses it to negotiate. The new phase2 negotiation is encrypted end-to-end from B to C. The gateway cannot do anything about it, he forwards the packets based on the cookies in the header. B will receive a negotiation intended to go to A and may or may not accept it. I would note that this example is likely to happen. In IKE the responder may have a phase 2 SA lifetime lower than the initiator without the initiator knowing. In this case, the responder will be the one re-keying and causing the problem. This problem could also occur frequently if the initiator only negotiates SA's with very specific ports/protocols. The destination could be unable to reply back since all it's SA's are negotiated to the wrong computer inside the gateway. I also note that the phase 1 selection process varies from an IKE implementation to another. I don't have any simple solution that come to mind, maybe this is out of scope or we can live with this. Ylian Saint-Hilaire INTEL - Communication Architecture Labs From owner-ipsec@lists.tislabs.com Mon Nov 15 18:40:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29272; Mon, 15 Nov 1999 18:40:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20877 Mon, 15 Nov 1999 19:40:06 -0500 (EST) Message-ID: <51C0AF25889FD211AC3F00A0C984090DC0BE38@orsmsx50.jf.intel.com> From: "Saint-Hilaire, Ylian" To: "'Mike Borella'" , "Saint-Hilaire, Ylian" Cc: ipsec@lists.tislabs.com, "'gab@sun.com'" , nat@livingston.com, David Grabelsky Subject: RE: IKE negotiation/rekeying problem with RSIP Date: Mon, 15 Nov 1999 16:42:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Even if we get out of using pre-shared keys and start using certs, there is no requirement in the IKE standard to choose one phase 1 over another. For example, IKE standards don't require that a re-key of a phase 2 MUST be done over the same phase 1 as the original SA. Even if we use certs, I would guess that no IKE implementations will currently look at the cert of a phase 1 before selecting it for a phase 2. Ylian Saint-Hilaire -----Original Message----- From: Mike Borella [mailto:Mike_Borella@mw.3com.com] Sent: Monday, November 15, 1999 12:37 PM To: Saint-Hilaire, Ylian Cc: ipsec@lists.tislabs.com; 'gab@sun.com'; nat@livingston.com; David Grabelsky Subject: Re: IKE negotiation/rekeying problem with RSIP Let's try to scope the problem. - The reason that the two phase 1's are identical to C is because the identity of the initiator can only be determined by the IP address of the gateway (assuming preshared keys and main mode). This suggests a number of work arounds: 1) Don't use pre-shared keys. Problem: many current implementations only use pre-shared keys 2) Use aggressive rather than main mode. Problems: No group negotiation, responders may not implement (or prefer) aggressive mode). 3) Allocate an IP address per initiator (RSA-IP method). Problem: If we can do this, then RSIP itself may be overkill. - It makes no sense to use preshared keys with RSIP/IPSEC in any case. If we have n identities sharing the same IP address such that they can only be differentiated by the port numbers that they use and/or out of band authentication such as public keys, then *there is no way* for the responder to tell these n identities apart. Since RSIP is meant to be used in situations where a roaming client plugs into a LAN and shares the gateway's IP with other roaming clients, we need something other than the gateway's IP for authentication. - For phase 2, we can still negotiate on a port-by-port (socket-by-socket) basis and since gateway-side ports are tied to IDs, this should work. This whole problem is a reiteration of the IPSEC remote access problem with respect to preshared keys. I think that the RSIP/IPSEC draft should document the issues and explain where RSIP / IPSEC will not work, but it is not in our scope to solve this problem. Yet another reason to speed the move from preshared keys and IP based authentication to something better. -Mike "Saint-Hilaire, Ylian" on 11/14/99 06:39:34 PM Sent by: "Saint-Hilaire, Ylian" To: ipsec@lists.tislabs.com, "'gab @sun.com'" , Mike Borella/MW/US/3Com cc: Subject: IKE negotiation/rekeying problem with RSIP There is a possible problem IKE initiation/rekeying over RSIP. If two inner computers use an RSIP gateway to establish IPsec sessions to one destination, the destination computers will see 2 IKE phase1's from the gateway. If the destination computer ever needs to rekey a phase 2 or negotiate a new phase 2, he may select an incorrect phase 1 to negotiate with. Here is an example: A ---> +---------+ | Gateway | ---> C B ---> +---------+ A negotiates a phase 1 with C using the gateway (called phase 1a) A negotiates a phase 2 with C using the phase 1a (called phase 2a) B negotiates a phase 1 with C using the gateway (called phase 1b) B negotiates a phase 2 with C using the phase 1b (called phase 2b) The lifetime of phase 2a is about to expire; C wants to negotiate a new SA before phase 1a expires completely. Since phase 1a is established to G (the gateway), C looks in his state table for a phase 1 he could re-use to G, he finds Phase1b and uses it to negotiate. The new phase2 negotiation is encrypted end-to-end from B to C. The gateway cannot do anything about it, he forwards the packets based on the cookies in the header. B will receive a negotiation intended to go to A and may or may not accept it. I would note that this example is likely to happen. In IKE the responder may have a phase 2 SA lifetime lower than the initiator without the initiator knowing. In this case, the responder will be the one re-keying and causing the problem. This problem could also occur frequently if the initiator only negotiates SA's with very specific ports/protocols. The destination could be unable to reply back since all it's SA's are negotiated to the wrong computer inside the gateway. I also note that the phase 1 selection process varies from an IKE implementation to another. I don't have any simple solution that come to mind, maybe this is out of scope or we can live with this. Ylian Saint-Hilaire INTEL - Communication Architecture Labs From owner-ipsec@lists.tislabs.com Mon Nov 15 19:55:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04434; Mon, 15 Nov 1999 19:55:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21277 Mon, 15 Nov 1999 21:21:01 -0500 (EST) Message-ID: <3830C06C.A4261790@redcreek.com> Date: Mon, 15 Nov 1999 18:24:44 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Saint-Hilaire, Ylian" CC: "'Mike Borella'" , ipsec@lists.tislabs.com, "'gab@sun.com'" , nat@livingston.com, David Grabelsky Subject: Re: IKE negotiation/rekeying problem with RSIP References: <51C0AF25889FD211AC3F00A0C984090DC0BE38@orsmsx50.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Saint-Hilaire, Ylian" wrote: > > Even if we get out of using pre-shared keys and start using certs, there is > no requirement in the IKE standard to choose one phase 1 over another. For > example, IKE standards don't require that a re-key of a phase 2 MUST be done > over the same phase 1 as the original SA. Even if we use certs, I would > guess that no IKE implementations will currently look at the cert of a phase > 1 before selecting it for a phase 2. > > Ylian Saint-Hilaire Actually, I think this may be incorrect. Ostensibly, the 2 users behind the rsip server would use separate authenticators (not the same preshared key or cert). If this is true, then the phase 2 SAs are bound to the respective phase 1 SAs by the authentication materials used in each case. If the kernel (or whatever you want to call the ipsec portion of the stack) requests a phase 2 negotiation from IKE, it must provide IKE with identifying information (and authentication requirements) with which IKE can determine whether an existing phase 1 SA is appropriate. If the IKE implementation does not verify that the phase 1 SA meets the authentication requirements before using it, I think the IKE implementation is badly broken. Scott From owner-ipsec@lists.tislabs.com Tue Nov 16 07:38:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28005; Tue, 16 Nov 1999 07:38:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23394 Tue, 16 Nov 1999 08:53:42 -0500 (EST) Message-Id: <4.1.19991115194415.00afd980@sj-email> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Nov 1999 19:48:57 -0800 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: Application available for VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The application for the January 2000 VPN Interoperability Workshop is now available at: http://www.calbug.org:8080/vpnworkshop/ The deadline for the VPN workshop application and hotel reservations is December 15, 1999. The VPN Interoperability Workshop will be held January 9-14, 2000, at the Paradise Point Resort in San Diego, California. The Workshop is being sponsored by Cisco. The protocols being tested are: IPsec IKE IKE-CFG IKE-XAUTH CA IPComp L2TP over Transport-Mode IPsec CCP with MPPC and MPPE MS CHAP V2 EAP PPTP PPPoE PPPoATM L2TPoATM L2TP Hotel reservations may be made by calling Paradise Point Resort at 800-344-2626. Please register under the Cisco VPN Workshop room block for the discounted rate of $140 per night (plus tax). Thanks, Anita From owner-ipsec@lists.tislabs.com Tue Nov 16 07:42:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28118; Tue, 16 Nov 1999 07:42:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23392 Tue, 16 Nov 1999 08:53:37 -0500 (EST) From: Gabriel.Montenegro@Eng.Sun.Com (Gabriel Montenegro) Message-Id: <199911160852.AAA01694@ha1mpk-mail.eng.sun.com> Date: Tue, 16 Nov 1999 01:01:13 -0800 To: "Michael C. Richardson" , Cc: "Ylian" Reply-To: Subject: Re: IKE negotiation/rekeying problem with RSIP X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian >writes: > Saint-Hilaire,> There is a possible problem IKE initiation/rekeying over > Saint-Hilaire,> RSIP. If two inner computers use an RSIP gateway to > Saint-Hilaire,> establish IPsec sessions to one destination, the > Saint-Hilaire,> destination computers will see 2 IKE phase1's from the > > 1) this in itself may be a problem for some gateways. well, they should be separate phase 1 because they must use different cookies. that's what the cookie parameter in rsip support for ike is for. the initiator/responder cookie pair in phase 1 is the isakmp spi. from isakmp (rfc 2408): In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,... so they should be seen as separate phase 1 sa's. this goes hand in hand with the requirement to not rely only on IP address for authentication. IDii and IDir must be exchanged (from the rsipsec draft). > > Saint-Hilaire,> gateway. If the destination computer ever needs to rekey > Saint-Hilaire,> a phase 2 or negotiate a new phase 2, he may select an > Saint-Hilaire,> incorrect phase 1 to negotiate with. > > 2) worse, they can't both get UDP port 500. There are choices to resolve >this: > a) permit initiators to use other than port 500, and have the > remote gateway respond to the correct port. > i asked for this back in orlando (dec 98). these are my slides for the presentation i gave at the ipsec wg to ask for this (the DOI document is very explicit about not allowing these port numbers to vary, at least for purposes of including themin the hash): http://playground.sun.com/~gab/talks/ipsec-nat-issues.PDF note: see slides 7-9 in the above. i got no answer from the working group on this matter, so i decided not to rely on ports for demultiplexing... > b) have the gateway demux based upon cookies instead of port numbers. > This makes the gateway aware of IKE, but it needs to know proto 50/51 > anyway. this has been in the draft since 00. please see sections 3 and 5.1 in http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-01.txt notice that the draft does allow use of ports other than 500, but does not assume this is possible, hence the cookie parameter negotiation. so given that (1) the draft already spells out the requirements at the end of section 3 as follows: To prevent Y from mistakenly deriving the identity of its IKE peer based on the source address of the packets (Nb), X MUST exchange client identifiers with Y: - IDii, IDir if in Phase 1, and - IDci, IDcr if in Phase 2. The proper use of identifiers allows the clear separation between those identities and the source IP address of the packets. that (2) phase 1 sa's are uniquely identified by the spi comprising the initiator/responder cookie pair is there still a problem? -gabriel From owner-ipsec@lists.tislabs.com Tue Nov 16 09:03:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29174; Tue, 16 Nov 1999 09:03:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23923 Tue, 16 Nov 1999 10:20:52 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7AD31@exchange> From: Tim Jenkins To: "'ipsec@lists.tislabs.com'" Subject: Phase 1 Re-keying Implementation Identification Date: Tue, 16 Nov 1999 10:25:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, At the 46th IETF last week, I again presented the re-keying document. In that presentation and in the re-keying document, I described two methods of phase 1 re-keying. One of these I called "phase 2 SA dangling". In this method, an implementation does not necessarily keep any valid phase 1 SAs alive while there are phased 2 SAs between it and another peer. In other words, the phase 2 SAs may "dangle" without the existence of a control channel. The other method is what I called the "continuous channel" method. In this method, an implementation always keeps at least one phase 1 SA up between itself and a peer when there are any phase 2 SAs up between them. If, for any reason, there are no phase 1 SAs between the peers, all phase 2 SAs would be torn down as well. However, this leads to a potential interoperability issue between the two methods, since a continuous channel implementation would delete phase 2 SAs when a dangling phase 2 SA peer deletes the phase 1 SA between them. To correct this, a continuous channel implementation could choose to not delete phase 2 SAs when it received a delete notification for the only phase 1 SA that exists. However, this leads to problems if the peer is also a continuous channel model. Note that this can occur since delete notifications for all SAs are both optional and send without acknowledgement over UDP. So, I asked if there was interest in allowing vendors to be able to determine if the peer is also a continuous channel model. Obviously, if a vendor sends a vendor ID payload, the implementation can determine that it is talking to itself, and thus determine which phase 1 re-keying model it uses. So: Is there any interest in this? How many vendors are using the continuous channel model? Please note that this has absolutely no effect on dangling phase 2 SA implementations. It has already been stated that continuous channel model implementation should be dangling phase 2 SA implementation aware if they cannot determine the nature of the peer implementation. If there is, what method would be suggested? (One potential method is the exchange of a specific vendor ID, but this goes against the intent of the vendor ID payload. Unfortunately, there doesn't seem to be a feature negotiation capability in IKE.) Thanks, Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Tue Nov 16 10:03:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00188; Tue, 16 Nov 1999 10:03:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24371 Tue, 16 Nov 1999 11:20:32 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7ADA6@exchange> From: Tim Jenkins To: Slava Kavsan Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Phase 1 Re-keying Implementation Identification Date: Tue, 16 Nov 1999 11:25:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The differences between the implementations is also in the document, and was also presented. In one sense it's irrelevant. If you prefer dangling, just do it, and you will be unaffected by the discussion on how to identify it. Regardless, I think we need an extension mechanism to IKE anyway. The primary advantage of the continuous channel model is that the logical control channel created by the existence of the phase 1 SAs may not be available in the dangling phase 2 SA implementation. This can then lead to loss of synchronization of phase 2 SAs, which you may or may not care about, depending on what you want to do. I would recommend reading the document, and commenting on it, so that specific issues can be dealt with there. I plan on updating it once more, perhaps for the final time. Suggestions as to what to do with the document are welcome; the obvious rude ones excepted. My current thought is to make it informational. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Slava Kavsan [mailto:bkavsan@ire-ma.com] Sent: November 16, 1999 11:11 AM To: Tim Jenkins Cc: 'ipsec@lists.tislabs.com' Subject: Re: Phase 1 Re-keying Implementation Identification Wouldn't be simpler to eliminate "continious" model instead of creating additional protocol extensions to support it. What are advantages of "continious" model vs. "dangling"? From owner-ipsec@lists.tislabs.com Tue Nov 16 10:57:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01153; Tue, 16 Nov 1999 10:57:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24212 Tue, 16 Nov 1999 11:07:23 -0500 (EST) Message-ID: <383181FE.DD44C0AA@ire-ma.com> Date: Tue, 16 Nov 1999 11:10:39 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: "'ipsec@lists.tislabs.com'" Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7AD31@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wouldn't be simpler to eliminate "continious" model instead of creating additional protocol extensions to support it. What are advantages of "continious" model vs. "dangling"? Tim Jenkins wrote: > Greetings, > > At the 46th IETF last week, I again presented the re-keying document. In > that presentation and in the re-keying document, I described two methods of > phase 1 re-keying. > > One of these I called "phase 2 SA dangling". In this method, an > implementation does not necessarily keep any valid phase 1 SAs alive while > there are phased 2 SAs between it and another peer. In other words, the > phase 2 SAs may "dangle" without the existence of a control channel. > > The other method is what I called the "continuous channel" method. In this > method, an implementation always keeps at least one phase 1 SA up between > itself and a peer when there are any phase 2 SAs up between them. If, for > any reason, there are no phase 1 SAs between the peers, all phase 2 SAs > would be torn down as well. > > However, this leads to a potential interoperability issue between the two > methods, since a continuous channel implementation would delete phase 2 SAs > when a dangling phase 2 SA peer deletes the phase 1 SA between them. > > To correct this, a continuous channel implementation could choose to not > delete phase 2 SAs when it received a delete notification for the only phase > 1 SA that exists. > > However, this leads to problems if the peer is also a continuous channel > model. Note that this can occur since delete notifications for all SAs are > both optional and send without acknowledgement over UDP. > > So, I asked if there was interest in allowing vendors to be able to > determine if the peer is also a continuous channel model. > > Obviously, if a vendor sends a vendor ID payload, the implementation can > determine that it is talking to itself, and thus determine which phase 1 > re-keying model it uses. > > So: Is there any interest in this? How many vendors are using the continuous > channel model? > > Please note that this has absolutely no effect on dangling phase 2 SA > implementations. It has already been stated that continuous channel model > implementation should be dangling phase 2 SA implementation aware if they > cannot determine the nature of the peer implementation. > > If there is, what method would be suggested? > > (One potential method is the exchange of a specific vendor ID, but this goes > against the intent of the vendor ID payload. Unfortunately, there doesn't > seem to be a feature negotiation capability in IKE.) > > Thanks, > > Tim > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Nov 16 11:52:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01921; Tue, 16 Nov 1999 11:52:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24903 Tue, 16 Nov 1999 12:59:52 -0500 (EST) Message-ID: <38319C45.A1432706@cyphers.net> Date: Tue, 16 Nov 1999 10:02:53 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7AD31@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Jenkins wrote: > The other method is what I called the "continuous channel" method. > In this method, an implementation always keeps at least one phase 1 > SA up between itself and a peer when there are any phase 2 SAs up > between them. If, for any reason, there are no phase 1 SAs between > the peers, all phase 2 SAs would be torn down as well. The first thought that comes to mind WRT continuous channel is what happens with PFS? If I intentionally tear down my P1 immediately after negotiating my P2 due to PFS, I would now need to make sure a new P1 gets negotiated prior to doing that, thus creating a potentially lengthy delay before PFS actually takes effect. Use of PFS without correcting for this would make the peers unable to communicate because the P2 SA would get nuked when the P1 SA gets nuked. > However, this leads to a potential interoperability issue between > the two methods, since a continuous channel implementation would > delete phase 2 SAs when a dangling phase 2 SA peer deletes the > phase 1 SA between them. > > To correct this, a continuous channel implementation could choose > to not delete phase 2 SAs when it received a delete notification > for the only phase 1 SA that exists. > > However, this leads to problems if the peer is also a continuous > channel model. Note that this can occur since delete notifications > for all SAs are both optional and send without acknowledgement over > UDP. Isn't it about time we all acknowledged that IKE without Delete notifications has serious rekeying problems and made these a MUST anyway (as Acknowledged Notifications in the new IKE draft)? Your draft is like a proof for this. If rekeying worked reliably without these things we wouldn't need your draft as much as we do. > So, I asked if there was interest in allowing vendors to be able to > determine if the peer is also a continuous channel model. > > Obviously, if a vendor sends a vendor ID payload, the > implementation can determine that it is talking to itself, and thus > determine which phase 1 re-keying model it uses. > > So: Is there any interest in this? How many vendors are using the > continuous channel model? If we make Acknowledged Notifications a requirement, I think the need for continuous channel mode goes away, correct? That seems like a cleaner solution than creating a permanent hack Vendor ID payload shared by all the vendors who "do things right". We currently try our best to keep a "continuous channel" open, but if through PFS or some other reason the other side deletes the P1, we don't care. We'll just negotiate a new one if we need it... and if we can. The only reasons we would ever need to negotiate a new P1 if it had been deleted are (1) the P2 needs to be rekeyed, (2) the user told us to rekey, (3) the user told us to kill the P2 and we want to send a protected Delete. For (1), if we can't make a new P1, we might as well kill the P2 anyway. For (2), again if we can't make a P1 we might as well kill the P2. For (3), we could send an unauthenticated Delete -- not ideal but if the devices have lost the ability to negotiate a Phase 1 it really doesn't seem critical. > Please note that this has absolutely no effect on dangling phase 2 > SA implementations. It has already been stated that continuous > channel model implementation should be dangling phase 2 SA > implementation aware if they cannot determine the nature of the > peer implementation. > > If there is, what method would be suggested? > > (One potential method is the exchange of a specific vendor ID, but > this goes against the intent of the vendor ID payload. > Unfortunately, there doesn't seem to be a feature negotiation > capability in IKE.) > > Thanks, > > Tim > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. Direct (408)346-5906 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBODGcPqy7FkvPc+xMEQKKvgCg9PE7J8qOeyeeAlAy35XKKWYKd+IAoIW1 BncBN9cR75o6WC3sX6BqMYk0 =G6Ie -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Nov 16 12:11:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02348; Tue, 16 Nov 1999 12:11:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25071 Tue, 16 Nov 1999 13:28:56 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7AE58@exchange> From: Tim Jenkins To: wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Tue, 16 Nov 1999 13:34:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk comments below. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Will Price [mailto:wprice@cyphers.net] > Sent: November 16, 1999 1:03 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 1 Re-keying Implementation Identification > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tim Jenkins wrote: > > The other method is what I called the "continuous channel" method. > > In this method, an implementation always keeps at least one phase 1 > > SA up between itself and a peer when there are any phase 2 SAs up > > between them. If, for any reason, there are no phase 1 SAs between > > the peers, all phase 2 SAs would be torn down as well. > > The first thought that comes to mind WRT continuous channel is what > happens with PFS? If I intentionally tear down my P1 immediately > after negotiating my P2 due to PFS, I would now need to make sure a > new P1 gets negotiated prior to doing that, thus creating a > potentially lengthy delay before PFS actually takes effect. Use of > PFS without correcting for this would make the peers unable to > communicate because the P2 SA would get nuked when the P1 SA gets > nuked. How to do PFS with the continuous channel model is described in the document. Basically, you create two phase 1 SAs as you mentioned above, but you use the newest one to do phase 2 negotiations and immediately delete it. The first and oldest remains as the channel to send notifications and deletes and heart beats and keep-alives and whatever else you need to send in the channel. > > > However, this leads to a potential interoperability issue between > > the two methods, since a continuous channel implementation would > > delete phase 2 SAs when a dangling phase 2 SA peer deletes the > > phase 1 SA between them. > > > > To correct this, a continuous channel implementation could choose > > to not delete phase 2 SAs when it received a delete notification > > for the only phase 1 SA that exists. > > > > However, this leads to problems if the peer is also a continuous > > channel model. Note that this can occur since delete notifications > > for all SAs are both optional and send without acknowledgement over > > UDP. > > Isn't it about time we all acknowledged that IKE without Delete > notifications has serious rekeying problems and made these a MUST > anyway (as Acknowledged Notifications in the new IKE draft)? Your > draft is like a proof for this. If rekeying worked reliably without > these things we wouldn't need your draft as much as we do. Perhaps not as much. But it doesn't change the fact that there can be distinct advantages in keeping the channel available at all times. Consider premature tear down of the entire channel. The acknowledged delete can't be used if you can't get the control channel back up. Then, you've got to count on (still proprietary) heart beats to determine that the peer has died to clean up. And until that happens you've got SAs at one end that might be spewing out encryted useless data. The clean-up is messy, and it doesn't need to be. > > > So, I asked if there was interest in allowing vendors to be able to > > determine if the peer is also a continuous channel model. > > > > Obviously, if a vendor sends a vendor ID payload, the > > implementation can determine that it is talking to itself, and thus > > determine which phase 1 re-keying model it uses. > > > > So: Is there any interest in this? How many vendors are using the > > continuous channel model? > > If we make Acknowledged Notifications a requirement, I think the need > for continuous channel mode goes away, correct? That seems like a > cleaner solution than creating a permanent hack Vendor ID payload > shared by all the vendors who "do things right". It doesn't go away. One of the conditions that makes it more useful goes away (dropped phase 2 delete before phase 1 delete). See above as well. Also, you appear to be making an issue about how we do feature extension with IKE. That's a separate issue. Right now, I don't know how it's done, and I've already said I don't like using the vendor ID for that. But I don't know how else to do it without being proprietary. So there's two questions: 1) Are other interested in recognizing that the peer is contuous channel? If the answer to 1 is yes, then: 2) How should that be done? > > We currently try our best to keep a "continuous channel" open, but if > through PFS or some other reason the other side deletes the P1, we > don't care. We'll just negotiate a new one if we need it... and if > we can. The only reasons we would ever need to negotiate a new P1 if > it had been deleted are (1) the P2 needs to be rekeyed, (2) the user > told us to rekey, (3) the user told us to kill the P2 and we want to > send a protected Delete. > > For (1), if we can't make a new P1, we might as well kill the P2 > anyway. For (2), again if we can't make a P1 we might as well kill > the P2. For (3), we could send an unauthenticated Delete -- not > ideal but if the devices have lost the ability to negotiate a Phase 1 > it really doesn't seem critical. This is the termination case I described above. If you don't think it's critical, that's fine. Personally, I think it is important and I think that the people who have to use our products will think it's important. Some of them want to see alarms when they get encrypted packets for SAs that no longer exist. Implementations that don't clean up well will not be as popular with these customers. >From the sounds of it, your implementation is a continuous channel model that is dangling phase 2 SA aware. That's exactly what the draft recommends in the absence of knowledge about the peer. So, if you don't think there's an advantage knowing that the peer is also a continuous channel implementation, just say no to question 1. For now, I'll assume you have. From owner-ipsec@lists.tislabs.com Tue Nov 16 13:03:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02988; Tue, 16 Nov 1999 13:02:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25207 Tue, 16 Nov 1999 14:20:34 -0500 (EST) Message-ID: <3831AEBF.AB6D35BD@indusriver.com> Date: Tue, 16 Nov 1999 14:21:35 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: "'ipsec@lists.tislabs.com'" Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7AD31@exchange> <383181FE.DD44C0AA@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan wrote: > > Wouldn't be simpler to eliminate "continious" model instead of creating > additional protocol extensions to support it. > What are advantages of "continious" model vs. "dangling"? > The continuous model provides a 'session' metaphor that is appropriate for remote access accounting and billing. P2 SA deletion upon P1 termination also garbage collects any open SA's when a remote access user 'logs out' of a VPN. This releases resources on the security gateway and closes P2 SA's that would otherwise be used to send data to a client who is no longer connected. (I recognize DELETE's can be issued for each P2 SA but I believe that any dangling P2 SA's should be deleted when a remote access user's P1 SA is terminated). -Ben McCann > Tim Jenkins wrote: > > > Greetings, > > > > At the 46th IETF last week, I again presented the re-keying document. In > > that presentation and in the re-keying document, I described two methods of > > phase 1 re-keying. > > > > One of these I called "phase 2 SA dangling". In this method, an > > implementation does not necessarily keep any valid phase 1 SAs alive while > > there are phased 2 SAs between it and another peer. In other words, the > > phase 2 SAs may "dangle" without the existence of a control channel. > > > > The other method is what I called the "continuous channel" method. In this > > method, an implementation always keeps at least one phase 1 SA up between > > itself and a peer when there are any phase 2 SAs up between them. If, for > > any reason, there are no phase 1 SAs between the peers, all phase 2 SAs > > would be torn down as well. > > > > However, this leads to a potential interoperability issue between the two > > methods, since a continuous channel implementation would delete phase 2 SAs > > when a dangling phase 2 SA peer deletes the phase 1 SA between them. > > > > To correct this, a continuous channel implementation could choose to not > > delete phase 2 SAs when it received a delete notification for the only phase > > 1 SA that exists. > > > > However, this leads to problems if the peer is also a continuous channel > > model. Note that this can occur since delete notifications for all SAs are > > both optional and send without acknowledgement over UDP. > > > > So, I asked if there was interest in allowing vendors to be able to > > determine if the peer is also a continuous channel model. > > > > Obviously, if a vendor sends a vendor ID payload, the implementation can > > determine that it is talking to itself, and thus determine which phase 1 > > re-keying model it uses. > > > > So: Is there any interest in this? How many vendors are using the continuous > > channel model? > > > > Please note that this has absolutely no effect on dangling phase 2 SA > > implementations. It has already been stated that continuous channel model > > implementation should be dangling phase 2 SA implementation aware if they > > cannot determine the nature of the peer implementation. > > > > If there is, what method would be suggested? > > > > (One potential method is the exchange of a specific vendor ID, but this goes > > against the intent of the vendor ID payload. Unfortunately, there doesn't > > seem to be a feature negotiation capability in IKE.) > > > > Thanks, > > > > Tim > > > > --- > > Tim Jenkins TimeStep Corporation > > tjenkins@timestep.com http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-539-4816 > http://www.ire.com -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Tue Nov 16 13:35:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03640; Tue, 16 Nov 1999 13:35:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25544 Tue, 16 Nov 1999 15:14:28 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7AF05@exchange> From: Tim Jenkins To: Slava Kavsan Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Phase 1 Re-keying Implementation Identification Date: Tue, 16 Nov 1999 15:19:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: November 16, 1999 2:59 PM > To: Ben McCann > Cc: 'ipsec@lists.tislabs.com' > Subject: Re: Phase 1 Re-keying Implementation Identification > > > I have a question on "continious" model re-keying: > > If P1 lifetime is set to 7 min and P2 lifetime is set to 5 > min - what do you do when > P1 re-keyes after 7 min - do you re-key P2 after 5+2 minutes also? > > (Of course, in the "dangling" model - both phases re-key on > their own schedule > independent from each other). > There's no reason that any phase 2 re-keying changes with the continuous channel model. Only the phase 1 SA re-keying is affected. In the continuous channel model, you re-key the phase 1 SA some time *before* the 7 minutes is up. In the dangling case, you let it expire if you haven't already deleted it. Phase 2 is re-keyed as needed, with the oldest phase 1 SA available (continuous channel model), or with a new one if needed (dangling phase 2 model). From owner-ipsec@lists.tislabs.com Tue Nov 16 13:43:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03730; Tue, 16 Nov 1999 13:43:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25412 Tue, 16 Nov 1999 14:55:59 -0500 (EST) Message-ID: <3831B78C.78905F65@ire-ma.com> Date: Tue, 16 Nov 1999 14:59:09 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ben McCann CC: "'ipsec@lists.tislabs.com'" Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7AD31@exchange> <383181FE.DD44C0AA@ire-ma.com> <3831AEBF.AB6D35BD@indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question on "continious" model re-keying: If P1 lifetime is set to 7 min and P2 lifetime is set to 5 min - what do you do when P1 re-keyes after 7 min - do you re-key P2 after 5+2 minutes also? (Of course, in the "dangling" model - both phases re-key on their own schedule independent from each other). Ben McCann wrote: > Slava Kavsan wrote: > > > > Wouldn't be simpler to eliminate "continious" model instead of creating > > additional protocol extensions to support it. > > What are advantages of "continious" model vs. "dangling"? > > > > The continuous model provides a 'session' metaphor that is appropriate > for remote access accounting and billing. P2 SA deletion upon P1 termination > also garbage collects any open SA's when a remote access user 'logs out' > of a VPN. This releases resources on the security gateway and closes > P2 SA's that would otherwise be used to send data to a client who is no > longer connected. > > (I recognize DELETE's can be issued for each P2 SA but I believe that > any dangling P2 SA's should be deleted when a remote access user's P1 > SA is terminated). > > -Ben McCann > > > Tim Jenkins wrote: > > > > > Greetings, > > > > > > At the 46th IETF last week, I again presented the re-keying document. In > > > that presentation and in the re-keying document, I described two methods of > > > phase 1 re-keying. > > > > > > One of these I called "phase 2 SA dangling". In this method, an > > > implementation does not necessarily keep any valid phase 1 SAs alive while > > > there are phased 2 SAs between it and another peer. In other words, the > > > phase 2 SAs may "dangle" without the existence of a control channel. > > > > > > The other method is what I called the "continuous channel" method. In this > > > method, an implementation always keeps at least one phase 1 SA up between > > > itself and a peer when there are any phase 2 SAs up between them. If, for > > > any reason, there are no phase 1 SAs between the peers, all phase 2 SAs > > > would be torn down as well. > > > > > > However, this leads to a potential interoperability issue between the two > > > methods, since a continuous channel implementation would delete phase 2 SAs > > > when a dangling phase 2 SA peer deletes the phase 1 SA between them. > > > > > > To correct this, a continuous channel implementation could choose to not > > > delete phase 2 SAs when it received a delete notification for the only phase > > > 1 SA that exists. > > > > > > However, this leads to problems if the peer is also a continuous channel > > > model. Note that this can occur since delete notifications for all SAs are > > > both optional and send without acknowledgement over UDP. > > > > > > So, I asked if there was interest in allowing vendors to be able to > > > determine if the peer is also a continuous channel model. > > > > > > Obviously, if a vendor sends a vendor ID payload, the implementation can > > > determine that it is talking to itself, and thus determine which phase 1 > > > re-keying model it uses. > > > > > > So: Is there any interest in this? How many vendors are using the continuous > > > channel model? > > > > > > Please note that this has absolutely no effect on dangling phase 2 SA > > > implementations. It has already been stated that continuous channel model > > > implementation should be dangling phase 2 SA implementation aware if they > > > cannot determine the nature of the peer implementation. > > > > > > If there is, what method would be suggested? > > > > > > (One potential method is the exchange of a specific vendor ID, but this goes > > > against the intent of the vendor ID payload. Unfortunately, there doesn't > > > seem to be a feature negotiation capability in IKE.) > > > > > > Thanks, > > > > > > Tim > > > > > > --- > > > Tim Jenkins TimeStep Corporation > > > tjenkins@timestep.com http://www.timestep.com > > > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > -- > > Bronislav Kavsan > > IRE Secure Solutions, Inc. > > 100 Conifer Hill Drive Suite 513 > > Danvers, MA 01923 > > voice: 978-539-4816 > > http://www.ire.com > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Nov 16 14:37:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04528; Tue, 16 Nov 1999 14:37:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25828 Tue, 16 Nov 1999 15:58:15 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: ipsec@lists.tislabs.com Subject: iaPCBC papers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Nov 1999 16:01:15 -0500 Message-Id: <19991116210120.3DB7741F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A slightly-revised version of the draft is at http:/home/smb/lib/wwwfiles/papers/draft-bellovin-iapcbc-00.txt -- the claim that this mode is resistant to exhaustive key search has been deleted, since several people found successful attacks on that. The Gligor-Donescu paper it's based on is at file:/home/smb/lib/wwwfiles/papers/iapcbc.ps. A further change is needed (but has not yet been made) to the Internet draft: as written, it is suspectible to some truncation attacks. While the practical significance of those attacks is unclear, the issue should certainly be addressed; there are several possible ways to do that. But I wanted to first post a version that deletes the key search claim. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Nov 16 14:48:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04716; Tue, 16 Nov 1999 14:48:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25956 Tue, 16 Nov 1999 16:23:29 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: wu@csc.ncsu.edu Cc: ipsec@lists.tislabs.com Subject: Re: iaPCBC papers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Nov 1999 16:26:25 -0500 Message-Id: <19991116212630.BEE0341F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3831D259.16F4F400@eos.ncsu.edu>, "S. Felix Wu" writes: > Dear Steve, > > I think you forgot to put the hostname or ip address of the web > server. > -Felix You are, of course correct. The proper URLs are http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt and http://www.research.att.com/~smb/papers/iapcbc.ps > > > "Steven M. Bellovin" wrote: > > > A slightly-revised version of the draft is at > > http:/home/smb/lib/wwwfiles/papers/draft-bellovin-iapcbc-00.txt -- the clai > m > > that this mode is resistant to exhaustive key search has been deleted, sinc > e > > several people found successful attacks on that. The Gligor-Donescu paper > > it's based on is at file:/home/smb/lib/wwwfiles/papers/iapcbc.ps. > > > > A further change is needed (but has not yet been made) to the Internet draf > t: > > as written, it is suspectible to some truncation attacks. While the practi > cal > > significance of those attacks is unclear, the issue should certainly be > > addressed; there are several possible ways to do that. But I wanted to fir > st > > post a version that deletes the key search claim. > > > > --Steve Bellovin > > --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Nov 16 16:08:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05897; Tue, 16 Nov 1999 16:08:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26311 Tue, 16 Nov 1999 17:20:50 -0500 (EST) Date: Wed, 17 Nov 1999 00:23:45 +0200 (EET) Message-Id: <199911162223.AAA29181@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Cc: "Michael C. Richardson" , , "Ylian" Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: <199911160852.AAA01694@ha1mpk-mail.eng.sun.com> References: <199911160852.AAA01694@ha1mpk-mail.eng.sun.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gabriel Montenegro writes: > the presentation i gave at the ipsec wg to ask for this (the DOI > document is very explicit about not allowing these port numbers > to vary, at least for purposes of including themin the hash): No, the DOI document is very clear that there is only two possible port numbers for ID payload, any (== zero), or 500. If you use port ANY (== zero), then you may also use any port you want. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Nov 16 16:19:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06243; Tue, 16 Nov 1999 16:19:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26426 Tue, 16 Nov 1999 17:45:23 -0500 (EST) Date: Tue, 16 Nov 1999 14:48:21 -0800 (PST) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: IKE negotiation/rekeying problem with RSIP To: Tero Kivinen Cc: ipsec@lists.tislabs.com, Ylian In-Reply-To: "Your message with ID" <199911162223.AAA29181@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Tero Kivinen" wrote: > No, the DOI document is very clear that there is only two possible > port numbers for ID payload, any (== zero), or 500. If you use port > ANY (== zero), then you may also use any port you want. cool. thanks for clearing that up. how common (beyond the testing sites) is this capability of using other-than-port-500 in commercial ipsec implementations? this would mean that it is quite possible to allow different rsip clients behind an rsip server to register each their own ike listener at their own port number and so enable ike sessions to be initiated from the outside to an inside rsip client. how the outside host learns about the particular port number to use for any given rsip client is another matter. srv rr's? out of band? tnx, -gabriel From owner-ipsec@lists.tislabs.com Tue Nov 16 18:06:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08446; Tue, 16 Nov 1999 18:06:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26830 Tue, 16 Nov 1999 19:50:02 -0500 (EST) Date: Wed, 17 Nov 1999 02:53:03 +0200 (EET) Message-Id: <199911170053.CAA07544@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: wprice@cyphers.net, ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFF7AE58@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFF7AE58@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 17 min X-Total-Time: 16 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins writes: > Perhaps not as much. But it doesn't change the fact that there can be > distinct advantages in keeping the channel available at all times. Is there? Lets put it this way, the draft-jenkins-ipsec-rekeying-02.txt doesn't list any of real advantages in keeping the channel available at all times. At least I couldn't find them. Only thing I found there was some very special case where somebody's credentials are revoked and the phase 2 SA cannot be deleted because there is no phase 1 SA there. In that case I would say "so what". The server will just delete the Phase 2 SA which should be deleted because that connection is no longer allowed by policy, and if the client continues to send packets to it it doesn't matter. Removing somebody's permission to use gateway doesn't happen that often, and usually there is good reason that, so there is really no need to have very clear error message for that (black hole approach is completely valid there). Anyways the user will get an error message when he tries to rekey to the server when he notices that the gateway doesn't respond at all anymore. There are some very good reasons for dangling SAs, because you might want to do resource limitations for phase 1 SAs. For example we will delete phase 1 SAs if there is too many of those. Phase 1 SAs are just needed in the rekeying, we do not need to have one phase 1 SA for each phase 2 SA, just in case. We usually need to maximize the number of phase 2 SAs we can handle, so we might want to delete phase 1 SAs to get more resources for phase 2 SAs. I don't relly see any point having phase 1 SA up there for 8 hours, just to be able to send again few hundred bytes of traffic for rekeying, and then again sitting idle for next 8 hours. If I have cpu power to do the DH (quite often we have), I would rather recreate the phase 1 SAs every time they are needed. So the real question is: Could you please summarize the advantages of continuous channel mode? In most cases it seems to be used only in very special cases, where you have something completely broken anyways. I think it is not usefull to try to optimize the system for those cases happening 0.01% of time, but for those happening 99.99% of time. (BTW, I think my numbers are way too big, I think it should be something like 0.000001% instead of 0.01%) > 1) Are other interested in recognizing that the peer is contuous channel? > If the answer to 1 is yes, then: I am not interested implementing special code for very special cases which usually means undebuggable bugs, because those cases are so special. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Nov 16 18:06:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08472; Tue, 16 Nov 1999 18:06:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26781 Tue, 16 Nov 1999 19:41:30 -0500 (EST) Message-Id: <199911170044.TAA04775@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: Your message of "Tue, 16 Nov 1999 14:48:21 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Nov 1999 19:44:32 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Gabriel" == Gabriel Montenegro writes: Gabriel> "Tero Kivinen" wrote: >> No, the DOI document is very clear that there is only two possible >> port numbers for ID payload, any (== zero), or 500. If you use port >> ANY (== zero), then you may also use any port you want. Gabriel> cool. thanks for clearing that up. how common (beyond the Gabriel> testing sites) is this capability of using other-than-port-500 Gabriel> in commercial ipsec implementations? I want to emphasis that if you use other-than-port-500 in most implementations then you use it for both initiator and responder. IKE does *NOT* use the typical "swap src/dst port and reply" method that one is used to. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Tue Nov 16 18:44:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11871; Tue, 16 Nov 1999 18:44:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26968 Tue, 16 Nov 1999 20:25:06 -0500 (EST) Date: Wed, 17 Nov 1999 03:28:11 +0200 (EET) Message-Id: <199911170128.DAA08180@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Michael C. Richardson" Cc: ipsec@lists.tislabs.com Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: <199911170044.TAA04775@istari.sandelman.ottawa.on.ca> References: <199911170044.TAA04775@istari.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael C. Richardson writes: > I want to emphasis that if you use other-than-port-500 in most > implementations then you use it for both initiator and responder. > IKE does *NOT* use the typical "swap src/dst port and reply" method > that one is used to. What? I think almost all the implementations are doing exactly that. At least we are doing it... I might of course be wrong in this case... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Nov 16 19:42:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15435; Tue, 16 Nov 1999 19:42:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27111 Tue, 16 Nov 1999 21:15:00 -0500 (EST) Message-ID: <38321094.82855414@redcreek.com> Date: Tue, 16 Nov 1999 18:19:00 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: Tim Jenkins , wprice@cyphers.net, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7AE58@exchange> <199911170053.CAA07544@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I tend to agree with Tero. I've been following this discussion for around a year now, and have always had a hard time understanding why "dangling SAs" are such an issue. I have come to the conclusion that it has something to do with the architectural viewpoint one takes with respect to isakmp. Below is a diagram from RFC2408: +------------+ +--------+ +--------------+ ! DOI ! ! ! ! Application ! ! Definition ! <----> ! ISAKMP ! ! Process ! +------------+ --> ! ! !--------------! +--------------+ ! +--------+ ! Appl Protocol! ! Key Exchange ! ! ^ ^ +--------------+ ! Definition !<-- ! ! ^ +--------------+ ! ! ! ! ! ! !----------------! ! ! v ! ! +-------+ v v ! API ! +---------------------------------------------+ +-------+ ! Socket Layer ! ! !---------------------------------------------! v ! Transport Protocol (TCP / UDP) ! +----------+ !---------------------------------------------! ! Security ! <----> ! IP ! ! Protocol ! !---------------------------------------------! +----------+ ! Link Layer Protocol ! +---------------------------------------------+ ISAKMP is clearly an application protocol which provides services to the kernel, and the notion of binding ISAKMP constructs (sessions, SAs, or what have you) to kernel constructs (SAs, in this case), really rubs me the wrong way. The IKE SAs and the protocol SAs (despite the unfortunate fact that they share a name) are distinctly different constructs in distinctly different architectural layers. It seems incorrect to assert that deletion of an application layer session should justify deletion of a kernel-level session. I understand the keep-alive issue in the remote access scenario, but I don't think this justifies cutting across the architectural layers here in the name of a quick fix. IKE SAs really have no binding to the protocol SAs they negotiate once they've been instantiated, and assuming that it is okay to delete a protocol SA just because the IKE session used to instantiate it goes away seems incorrect to me. Scott From owner-ipsec@lists.tislabs.com Tue Nov 16 20:20:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17498; Tue, 16 Nov 1999 20:20:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27174 Tue, 16 Nov 1999 21:57:55 -0500 (EST) Message-Id: <199911170301.WAA05043@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: Your message of "Wed, 17 Nov 1999 03:28:11 +0200." <199911170128.DAA08180@torni.ssh.fi> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Nov 1999 22:00:59 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael C. Richardson writes: >> I want to emphasis that if you use other-than-port-500 in most >> implementations then you use it for both initiator and responder. >> IKE does *NOT* use the typical "swap src/dst port and reply" method >> that one is used to. Tero> What? I think almost all the implementations are doing exactly that. Tero> At least we are doing it... I might of course be wrong in this case... That was my understanding from awhile ago. Looking at rfc2408, section 2.5.1, doesn't say anything about this. Hmm. I recall us discussing that at some point when isakmp.ssh.fi was going up... it made sense for the test bench to have that behaviour, and so long as they send from 500, everything works right. Hmm. OpenBSD isakmpd works as you suggest, ditto for racoon. I won't look any further... you are probably right. Now, where did I get this idea? Was it in previous drafts? :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface Charset: noconv iQDVAwUBODIaaHMJp3VWzPepAQHcXQX9Ea5QeuCKYoYSqtkX9I56S6UR5iTMaw7O Bs+I4MeRZMHRs1d8B5HfrltwiWOEs/vvp6XudRicEH8yVuG6hfEsGrqCrwEmXCAF 6wFWhTbZ2K9BO0o5OHY3SYttGio7WAPTwaJY8AQN/OL2dZ3QcJ2XT3jqz2FW5EBA uuN1WZPkNePqs5OSXCsJgHoHji1d+Hx16rHIciVUai/8eWMelGRdLNWZQ8MDWvhC M4n+b4m2Atmwk9hbq6SN86G3tFOFkbdE =F0Vn -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Nov 16 20:21:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17618; Tue, 16 Nov 1999 20:21:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27204 Tue, 16 Nov 1999 22:10:23 -0500 (EST) Message-Id: <199911170313.WAA05060@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKE negotiation/rekeying problem with RSIP In-Reply-To: Your message of "Wed, 17 Nov 1999 03:28:11 +0200." <199911170128.DAA08180@torni.ssh.fi> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Nov 1999 22:13:27 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> What? I think almost all the implementations are doing exactly that. Tero> At least we are doing it... I might of course be wrong in this case... ike source port (was: issues with IKE that need resolution) http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00102.html from: http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00064.html * Subject: issues with IKE that need resolution * From: Daniel Harkins * Date: Fri, 11 Sep 1998 10:48:12 -0700 I thought there was a followup that lead to the first part. Aha... http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00124.html according to section 5 of IKE: The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. However, I looked at the DOI, and it does impose severe constraints on the port number used: During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable. Well, I can see why I beleived that the source port had to 500. An implementation which replies to any port would work seemlessly with implementations that sent from port 500, and if you have port 500 open to receive, it seems simple enough to receive on that port as well. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface Charset: noconv iQDVAwUBODIdVXMJp3VWzPepAQFyCwYAo96CvWYai+x+P/WophlwwMkCpsJAdcx3 wUW3hfsntjBWjxjn2vJE73XwCP8Z/S4B7/L7tgzfhd+MILm9uxY5+shpaneVMWJD NIy02FKd0ylMM/WG6k3F2tlfNbPQ/ZdvU5OpOwCgp3KRowRZd8KmPS6boilVkrFo Tw7F9q3CBAPIpYn4lN6eniYiRdVdNtEHhjm6lyaYvYdtZB/RkGK7W56ozDfFwevQ ifuOG+tyGTeTO2FzOL0/4l3/DSFDdxtv =csFY -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Nov 17 05:31:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02254; Wed, 17 Nov 1999 05:31:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28623 Wed, 17 Nov 1999 06:54:57 -0500 (EST) Message-Id: <199911171157.GAA16375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-05.txt Date: Wed, 17 Nov 1999 06:57:56 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Method for IKE Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-05.txt Pages : 12 Date : 16-Nov-99 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. For a list of changes since the previous version of this document, please see Section 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-gss-auth-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991116110319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991116110319.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 17 07:12:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04369; Wed, 17 Nov 1999 07:12:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28951 Wed, 17 Nov 1999 08:31:37 -0500 (EST) From: Gabriel.Montenegro@Eng.Sun.Com (Gabriel Montenegro) Message-Id: <199911170451.UAA06955@ha1mpk-mail.eng.sun.com> Date: Tue, 16 Nov 1999 20:59:48 -0800 To: , "Michael C. Richardson" Reply-To: Subject: Re: IKE negotiation/rekeying problem with RSIP X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael C. Richardson" wrote: (some stuff elided...) >Aha... > http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00124.html > >according to section 5 of IKE: > > The entire ID payload (including ID type, > port, and protocol but excluding the generic header) is hashed into > both HASH_I and HASH_R. > >However, I looked at the DOI, and it does impose severe constraints >on the port number used: > > During Phase I negotiations, the ID port and protocol fields MUST be > set to zero or to UDP port 500. If an implementation receives any > other values, this MUST be treated as an error and the security > association setup MUST be aborted. This event SHOULD be auditable. yes, the above text is from a message i sent to the list. > Well, I can see why I beleived that the source port had to 500. > An implementation which replies to any port would work seemlessly >with implementations that sent from port 500, and if you have port 500 >open to receive, it seems simple enough to receive on that port as well. are you saying my msg had the opposite effect from what was intended? hmmm... good thing i'm not a peace negotiator... anyway, after all the exchange between tero and mcr it can be concluded that (notice it starts with 'if'): If an implementation allows other-than-port-500 for IKE, it no longer sets the value of the port numbers as reported in the ID payload to 500, but 0 (meaning "any port"). UDP port numbers (500 or not) are handled by the common "swap src/dst port and reply" method. should some wording to clarify this (perhaps along the lines above) go into the currently-being-updated ike document? -gabriel From owner-ipsec@lists.tislabs.com Wed Nov 17 08:04:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05427; Wed, 17 Nov 1999 08:04:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29112 Wed, 17 Nov 1999 09:22:25 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B06B@exchange> From: Tim Jenkins To: Tero Kivinen , "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Wed, 17 Nov 1999 09:27:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would look for more examples of the use of continuous channel model if I wanted to debate it. But I've already conceded that dangling SAs is not only allowed, but has to be assumed as the default behaviour. (I've tried again below, anyway.) And, as I keep saying, it you don't think it's important, don't do a continuous channel implementation. You won't be affected by a continuous channel implementation because it has to be aware that the peer may not be. The reality is, no matter what architectural view you choose, the phase 1 SAs are the control channel for the management of the phase 2 SAs. By allowing dangling phase 2 SAs, you allow for the possibility that the control channel cannot be used to manage the SAs. I've tried to illustrate a couple places where this may be important. And for the umpteenth time, if it's not important to you, don't worry about it. The point is that it is useful whenever premature termination of communications occurs when the phase 1 SAs cannot be re-created. These conditions occur potentially under the following conditions (and likely others) 1) A time-based policy that restricts user access to specific hours of the day. 2) A user's permission are totally revoked. 3) A token card-based user removes the token card from the system. 4) Some other policy or configuration change. 5) Others that no-one has thought of yet... Also, if you were the initial responder, and your phase 2 SA lifetimes are shorter, how do you re-key the phase 2 SAs? Do you keep enough information about the initiator that you can initiate back for both phase 1 and phase 2? Or do you drop the SAs, and the other end figure it out? How did you send the deletes for them? This case is not uncommon, and is potentially more normal, since the gate side in a remote access application would need to defend against dial-up users using excessively long expiration times. Is it okay to drop traffic while this situation clears itself up? Perhaps, but it's easily preventable. The fact that one of the cases is potentially rare is of little relevance to me when the additional complexity to make the whole thing cleaner is so little. It's not like 20% increase in complexity is to gain 1% in usefulness. And, yet again, if you don't care, don't worry about it, you won't be affected. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: November 16, 1999 7:53 PM > To: Tim Jenkins > Cc: wprice@cyphers.net; ipsec@lists.tislabs.com > Subject: RE: Phase 1 Re-keying Implementation Identification > > > Tim Jenkins writes: > > Perhaps not as much. But it doesn't change the fact that > there can be > > distinct advantages in keeping the channel available at all times. > > Is there? Lets put it this way, the > draft-jenkins-ipsec-rekeying-02.txt doesn't list any of real > advantages in keeping the channel available at all times. At least I > couldn't find them. Only thing I found there was some very special > case where somebody's credentials are revoked and the phase 2 > SA cannot > be deleted because there is no phase 1 SA there. > > In that case I would say "so what". The server will just delete the > Phase 2 SA which should be deleted because that connection is no > longer allowed by policy, and if the client continues to send packets > to it it doesn't matter. Removing somebody's permission to use gateway > doesn't happen that often, and usually there is good reason that, so > there is really no need to have very clear error message for that > (black hole approach is completely valid there). Anyways the user will > get an error message when he tries to rekey to the server when he > notices that the gateway doesn't respond at all anymore. > > There are some very good reasons for dangling SAs, because you might > want to do resource limitations for phase 1 SAs. For example we will > delete phase 1 SAs if there is too many of those. Phase 1 SAs are just > needed in the rekeying, we do not need to have one phase 1 SA for each > phase 2 SA, just in case. We usually need to maximize the number of > phase 2 SAs we can handle, so we might want to delete phase 1 SAs to > get more resources for phase 2 SAs. > > I don't relly see any point having phase 1 SA up there for 8 hours, > just to be able to send again few hundred bytes of traffic for > rekeying, and then again sitting idle for next 8 hours. If I have cpu > power to do the DH (quite often we have), I would rather recreate the > phase 1 SAs every time they are needed. > > So the real question is: Could you please summarize the advantages of > continuous channel mode? > > In most cases it seems to be used only in very special cases, where > you have something completely broken anyways. I think it is not > usefull to try to optimize the system for those cases happening 0.01% > of time, but for those happening 99.99% of time. (BTW, I think my > numbers are way too big, I think it should be something like 0.000001% > instead of 0.01%) > > > 1) Are other interested in recognizing that the peer is > contuous channel? > > If the answer to 1 is yes, then: > > I am not interested implementing special code for very special cases > which usually means undebuggable bugs, because those cases are so > special. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Wed Nov 17 10:24:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07852; Wed, 17 Nov 1999 10:24:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29372 Wed, 17 Nov 1999 10:44:25 -0500 (EST) Message-Id: <199911171546.JAA15928@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Scott G. Kelly" cc: Tero Kivinen , Tim Jenkins , wprice@cyphers.net, ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Phase 1 Re-keying Implementation Identification In-reply-to: Your message of "Tue, 16 Nov 1999 18:19:00 PST." <38321094.82855414@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Nov 1999 09:46:47 -0600 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, While the IKE SA is indeed a seperate entity from the IPSec or protocol SA, the IKE SA is used to authenticate/authorize the IPSec/Protocol SA. If it is important to "your" implementation to have precise boundries when authentication/authorization is removed (given a peer who may not cooperate), then dangling Phase 2's should be restricted. This is a similar issue to allowing phase 2 lifetimes to extend beyond the validity period of the certificate that authenticated the phase 1 used to negotiate the phase 2. It is impossible be absolutely precise in revocation of authorization. If in "your" application it is "close enough" to revoke authorization within the limits of a phase 2 lifetime, there is no need expend the extra development effort required to restrict dangling phase 2's. Regards, Michael Carney > I tend to agree with Tero. I've been following this discussion for > around a year now, and have always had a hard time understanding why > "dangling SAs" are such an issue. I have come to the conclusion that it > has something to do with the architectural viewpoint one takes with > respect to isakmp. Below is a diagram from RFC2408: > ISAKMP is clearly an application protocol which provides services to the > kernel, and the notion of binding ISAKMP constructs (sessions, SAs, or > what have you) to kernel constructs (SAs, in this case), really rubs me > the wrong way. The IKE SAs and the protocol SAs (despite the unfortunate > fact that they share a name) are distinctly different constructs in > distinctly different architectural layers. It seems incorrect to assert > that deletion of an application layer session should justify deletion of > a kernel-level session. > > I understand the keep-alive issue in the remote access scenario, but I > don't think this justifies cutting across the architectural layers here > in the name of a quick fix. IKE SAs really have no binding to the > protocol SAs they negotiate once they've been instantiated, and assuming > that it is okay to delete a protocol SA just because the IKE session > used to instantiate it goes away seems incorrect to me. > > Scott From owner-ipsec@lists.tislabs.com Wed Nov 17 12:11:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11539; Wed, 17 Nov 1999 12:11:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29881 Wed, 17 Nov 1999 12:38:43 -0500 (EST) Message-ID: <51C0AF25889FD211AC3F00A0C984090DC0BE3F@orsmsx50.jf.intel.com> From: "Saint-Hilaire, Ylian" To: "'Tim Jenkins'" , wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Wed, 17 Nov 1999 08:41:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't believe outside-in phase 1's are addressed in the current RSIP document. If there is an outside phase 1 coming to the gateway, there is just no way to know to witch inner computer this phase 1 should be sent to. (I note that the first phase 1 packet will have the outside initiator cookie and zeros in the responder cookie, routing based on cookies is not possible). Systems like "continuous channel model" cause RSIP is have more problems since they cause more outside-in phase 1's to occur. The only way RSIP will work fine with IPsec is to have one inside-out phase 1 that is kept open at all times, and require IKE vendors to properly re-key on the right phase 1. I don't see how the authentication method (Pre-shared key, certs...) can help in demultiplexing and outside-in phase 1 or make a outside machine select the right phase 1 for a new phase 2. Ylian Saint-Hilaire Intel Communication Architecture Labs -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Tuesday, November 16, 1999 10:34 AM To: wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification comments below. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Will Price [mailto:wprice@cyphers.net] > Sent: November 16, 1999 1:03 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 1 Re-keying Implementation Identification > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tim Jenkins wrote: > > The other method is what I called the "continuous channel" method. > > In this method, an implementation always keeps at least one phase 1 > > SA up between itself and a peer when there are any phase 2 SAs up > > between them. If, for any reason, there are no phase 1 SAs between > > the peers, all phase 2 SAs would be torn down as well. > > The first thought that comes to mind WRT continuous channel is what > happens with PFS? If I intentionally tear down my P1 immediately > after negotiating my P2 due to PFS, I would now need to make sure a > new P1 gets negotiated prior to doing that, thus creating a > potentially lengthy delay before PFS actually takes effect. Use of > PFS without correcting for this would make the peers unable to > communicate because the P2 SA would get nuked when the P1 SA gets > nuked. > How to do PFS with the continuous channel model is described in the > document. Basically, you create two phase 1 SAs as you mentioned above, but > you use the newest one to do phase 2 negotiations and immediately delete it. > The first and oldest remains as the channel to send notifications and > deletes and heart beats and keep-alives and whatever else you need to send > in the channel. > > > However, this leads to a potential interoperability issue between > > the two methods, since a continuous channel implementation would > > delete phase 2 SAs when a dangling phase 2 SA peer deletes the > > phase 1 SA between them. > > > > To correct this, a continuous channel implementation could choose > > to not delete phase 2 SAs when it received a delete notification > > for the only phase 1 SA that exists. > > > > However, this leads to problems if the peer is also a continuous > > channel model. Note that this can occur since delete notifications > > for all SAs are both optional and send without acknowledgement over > > UDP. > > Isn't it about time we all acknowledged that IKE without Delete > notifications has serious rekeying problems and made these a MUST > anyway (as Acknowledged Notifications in the new IKE draft)? Your > draft is like a proof for this. If rekeying worked reliably without > these things we wouldn't need your draft as much as we do. Perhaps not as much. But it doesn't change the fact that there can be distinct advantages in keeping the channel available at all times. Consider premature tear down of the entire channel. The acknowledged delete can't be used if you can't get the control channel back up. Then, you've got to count on (still proprietary) heart beats to determine that the peer has died to clean up. And until that happens you've got SAs at one end that might be spewing out encryted useless data. The clean-up is messy, and it doesn't need to be. > > > So, I asked if there was interest in allowing vendors to be able to > > determine if the peer is also a continuous channel model. > > > > Obviously, if a vendor sends a vendor ID payload, the > > implementation can determine that it is talking to itself, and thus > > determine which phase 1 re-keying model it uses. > > > > So: Is there any interest in this? How many vendors are using the > > continuous channel model? > > If we make Acknowledged Notifications a requirement, I think the need > for continuous channel mode goes away, correct? That seems like a > cleaner solution than creating a permanent hack Vendor ID payload > shared by all the vendors who "do things right". It doesn't go away. One of the conditions that makes it more useful goes away (dropped phase 2 delete before phase 1 delete). See above as well. Also, you appear to be making an issue about how we do feature extension with IKE. That's a separate issue. Right now, I don't know how it's done, and I've already said I don't like using the vendor ID for that. But I don't know how else to do it without being proprietary. So there's two questions: 1) Are other interested in recognizing that the peer is contuous channel? If the answer to 1 is yes, then: 2) How should that be done? > > We currently try our best to keep a "continuous channel" open, but if > through PFS or some other reason the other side deletes the P1, we > don't care. We'll just negotiate a new one if we need it... and if > we can. The only reasons we would ever need to negotiate a new P1 if > it had been deleted are (1) the P2 needs to be rekeyed, (2) the user > told us to rekey, (3) the user told us to kill the P2 and we want to > send a protected Delete. > > For (1), if we can't make a new P1, we might as well kill the P2 > anyway. For (2), again if we can't make a P1 we might as well kill > the P2. For (3), we could send an unauthenticated Delete -- not > ideal but if the devices have lost the ability to negotiate a Phase 1 > it really doesn't seem critical. This is the termination case I described above. If you don't think it's critical, that's fine. Personally, I think it is important and I think that the people who have to use our products will think it's important. Some of them want to see alarms when they get encrypted packets for SAs that no longer exist. Implementations that don't clean up well will not be as popular with these customers. >From the sounds of it, your implementation is a continuous channel model that is dangling phase 2 SA aware. That's exactly what the draft recommends in the absence of knowledge about the peer. So, if you don't think there's an advantage knowing that the peer is also a continuous channel implementation, just say no to question 1. For now, I'll assume you have. From owner-ipsec@lists.tislabs.com Wed Nov 17 12:14:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11645; Wed, 17 Nov 1999 12:14:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29864 Wed, 17 Nov 1999 12:37:05 -0500 (EST) Date: Wed, 17 Nov 1999 12:40:05 -0500 Message-Id: <199911171740.MAA22934@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: carney@securecomputing.com Cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <38321094.82855414@redcreek.com> <199911171546.JAA15928@jumpsrv.stp.securecomputing.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mike" == Mike Carney writes: Mike> Scott, While the IKE SA is indeed a seperate entity from the Mike> IPSec or protocol SA, the IKE SA is used to Mike> authenticate/authorize the IPSec/Protocol SA. If it is Mike> important to "your" implementation to have precise boundries Mike> when authentication/authorization is removed (given a peer who Mike> may not cooperate), then dangling Phase 2's should be Mike> restricted. I may be overlooking something simple, but is there a real issue here? If one side has reason to believe that communication is no longer authorized, it can (and should) unilaterally remove the phase 2 SAs that relate to that communication. You learn about the authorization properties during phase 1 negotiation, but it doesn't follow you need to keep the IKE SA open. You gain no additional knowledge from the fact that it remains open. It is clearly desirable for that fact to be communicated to the other end. With an active phase 1 SA that's easy. If there isn't one but you can establish it, that's likewise not a problem. If you can't establish it, what exactly is the problem? As Tero pointed out, all you get is a black hole. The side that recognized the absence of authority is perfectly well entitled to remove the phase 2 SAs unilaterally; it doesn't need permission from the other end to do so. If the other end isn't cooperating well enough to be told, that's its problem. Mike> This is a similar issue to allowing phase 2 lifetimes to extend Mike> beyond the validity period of the certificate that Mike> authenticated the phase 1 used to negotiate the phase 2. I don't see the similarity. In what way does limiting the phase 2 lifetime according to cert expiration times relate to the question of "dangling" SAs? You don't need to keep the IKE SA open to know about cert expiration times, nor do you even need to remember the cert expiration time in the first place once you've used it to bound the phase 2 SA lifetime. If you believe that phase 2 lifetimes shouldn't be extended like that (which sounds reasonable to me), don't do it. Again, you need no one's permission to do so; if you think it's time for an SA to be considered expired, that's all that's needed. (In particular, the notion of "negotiating" SA lifetime doesn't make much sense.) paul From owner-ipsec@lists.tislabs.com Wed Nov 17 14:26:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14637; Wed, 17 Nov 1999 14:26:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00342 Wed, 17 Nov 1999 14:24:44 -0500 (EST) Message-Id: <199911171926.NAA16174@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Paul Koning cc: carney@jumpsrv.stp.securecomputing.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-reply-to: Your message of "Wed, 17 Nov 1999 12:40:05 EST." <199911171740.MAA22934@tonga.xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Nov 1999 13:26:37 -0600 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Mike" == Mike Carney writes: > > Mike> Scott, While the IKE SA is indeed a seperate entity from the > Mike> IPSec or protocol SA, the IKE SA is used to > Mike> authenticate/authorize the IPSec/Protocol SA. If it is > Mike> important to "your" implementation to have precise boundries > Mike> when authentication/authorization is removed (given a peer who > Mike> may not cooperate), then dangling Phase 2's should be > Mike> restricted. > > I may be overlooking something simple, but is there a real issue here? > > If one side has reason to believe that communication is no longer > authorized, it can (and should) unilaterally remove the phase 2 SAs > that relate to that communication. You learn about the authorization > properties during phase 1 negotiation, but it doesn't follow you need > to keep the IKE SA open. You gain no additional knowledge from the > fact that it remains open. Well of course this is very implementation dependent, but in our situation, we store the identify information used for authorization of phase 1's with the rest of the information regarding the phase 1. We also keep track of the phase 2's negotiated under the phase 1 within the structures pertaining to the phase 1. If we discard all of this information when we discard a phase 1 (again implementation dependent) then we have no way of associating phase 2 SA's with a potential authorization change that may effect the phase 1. > It is clearly desirable for that fact to be communicated to the other > end. With an active phase 1 SA that's easy. If there isn't one but > you can establish it, that's likewise not a problem. If the identity used to establish the phase 1 is no longer valid, you cannot establish the phase 1 in order to inform the remote peer to discard the phase 2's. > If you can't > establish it, what exactly is the problem? > No problem, just discard the phase 2's associated with the phase 1 you had discarded early then later tried to renegotiate (If you can figure out which phase 2's fall into that category) > As Tero pointed out, all you get is a black hole. The side that > recognized the absence of authority is perfectly well entitled to > remove the phase 2 SAs unilaterally; it doesn't need permission from > the other end to do so. If the other end isn't cooperating well > enough to be told, that's its problem. I think we are in violent agreement but permit me to continue. I don't see the need to require the lack of dangling phase 2's. However, I feel there may be some benefit to implementations that prevent dangling phase 2's. > Mike> This is a similar issue to allowing phase 2 lifetimes to extend > Mike> beyond the validity period of the certificate that > Mike> authenticated the phase 1 used to negotiate the phase 2. > > I don't see the similarity. In what way does limiting the phase 2 > lifetime according to cert expiration times relate to the question of > "dangling" SAs? You don't need to keep the IKE SA open to know about > cert expiration times, nor do you even need to remember the cert > expiration time in the first place once you've used it to bound the > phase 2 SA lifetime. > It is similar only in the tradeoff being made for promptness of revocation of permission. I was not trying to say that you needed to keep a phase 1 SA in order to properly set the lifetime of the phase 2 SA. > If you believe that phase 2 lifetimes shouldn't be extended like that > (which sounds reasonable to me), don't do it. Again, you need no > one's permission to do so; if you think it's time for an SA to be > considered expired, that's all that's needed. (In particular, the > notion of "negotiating" SA lifetime doesn't make much sense.) > > > paul Regards, Michael Carney From owner-ipsec@lists.tislabs.com Wed Nov 17 16:15:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16807; Wed, 17 Nov 1999 16:15:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00816 Wed, 17 Nov 1999 16:29:19 -0500 (EST) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B38B@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: ipsec@lists.tislabs.com Subject: Placement of IPCOMP header in IPSEC Tunnel mode Date: Wed, 17 Nov 1999 13:32:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am confused about the placement of the IPComp header when used in Tunnel mode. >From RFC 2393 Section 2.1 In IP version 4 [RFC-0791], the compression is applied to the upper layer protocol (ULP) payload of the IP datagram. No portion of the IP header or the IP header options is compressed. Now in Tunnel mode I am building an IP packet that looks like this IP(outer)- IPSEC transform - IP(inner) - data I am convinced that the correct placement of a tunnel mode compression header is IP(outer) - IPSEC transform - IPCOMP - IP(inner) - data However from section 2.1 I can see a reading that says I am not to compress the IP header or options, so a packet would be built like this IP(outer) - IPSEC transform - IP(inner) - IPCOMP - data If this later packet is correct I would have a hard time determining if I should unapply compression at the gateway or the end host. Can I get some clarification on this point please ? Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me From owner-ipsec@lists.tislabs.com Wed Nov 17 16:16:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16852; Wed, 17 Nov 1999 16:16:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00942 Wed, 17 Nov 1999 17:09:05 -0500 (EST) Message-ID: <3833287D.2C98E520@redcreek.com> Date: Wed, 17 Nov 1999 14:13:17 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Carney CC: Paul Koning , carney@jumpsrv.stp.securecomputing.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <199911171926.NAA16174@jumpsrv.stp.securecomputing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike, Mike Carney wrote: > Paul Koning wrote: > > I may be overlooking something simple, but is there a real issue here? > > > > If one side has reason to believe that communication is no longer > > authorized, it can (and should) unilaterally remove the phase 2 SAs > > that relate to that communication. You learn about the authorization > > properties during phase 1 negotiation, but it doesn't follow you need > > to keep the IKE SA open. You gain no additional knowledge from the > > fact that it remains open. > > Well of course this is very implementation dependent, but in our > situation, we store the identify information used for authorization > of phase 1's with the rest of the information regarding the phase 1. > We also keep track of the phase 2's negotiated under the phase 1 within > the structures pertaining to the phase 1. > > If we discard all of this information when we discard a phase 1 (again > implementation dependent) then we have no way of associating phase 2 > SA's with a potential authorization change that may effect the phase 1. If you implement a policy db as specificied in RFC2401, this information will be associated with the phase 2 SA via the policy db entry, and the presence of the IKE SA will not be necessary in order to make the connection. Scott From owner-ipsec@lists.tislabs.com Wed Nov 17 17:10:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20047; Wed, 17 Nov 1999 17:10:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01142 Wed, 17 Nov 1999 18:41:53 -0500 (EST) From: rmonsour@hifn.com Message-ID: To: bill.strahm@intel.com Cc: ipsec@lists.tislabs.com Subject: RE: Placement of IPCOMP header in IPSEC Tunnel mode Date: Wed, 17 Nov 1999 15:44:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe the new draft removes this confusion. See section 2.1. http://search.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-01.txt Regards, -Bob ---------------------------------- Bob Monsour Hi/fn, Inc. 750 University Avenue Los Gatos, CA 95032 bmonsour@hifn.com 408-399-3539 tel 408-399-3501 fax > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Strahm, Bill > Sent: Wednesday, November 17, 1999 1:32 PM > To: ipsec@lists.tislabs.com > Subject: Placement of IPCOMP header in IPSEC Tunnel mode > > > I am confused about the placement of the IPComp header when > used in Tunnel > mode. > > >From RFC 2393 Section 2.1 > In IP version 4 [RFC-0791], the compression is applied to the upper > layer protocol (ULP) payload of the IP datagram. No portion of the > IP header or the IP header options is compressed. > > Now in Tunnel mode I am building an IP packet that looks like this > > IP(outer)- IPSEC transform - IP(inner) - data > > I am convinced that the correct placement of a tunnel mode compression > header is > > IP(outer) - IPSEC transform - IPCOMP - IP(inner) - data > > However from section 2.1 I can see a reading that says I am > not to compress > the IP header or options, so a packet would be built like this > > IP(outer) - IPSEC transform - IP(inner) - IPCOMP - data > > If this later packet is correct I would have a hard time > determining if I > should unapply compression at the gateway or the end host. > > Can I get some clarification on this point please ? > > Bill > > ______________________________________________ > Bill Strahm Programming today is a race between > bill.strahm@ software engineers striving to build > intel.com bigger and better idiot-proof programs, > (503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook > I am not speaking for Intel. And Intel rarely speaks for me > > From owner-ipsec@lists.tislabs.com Wed Nov 17 18:17:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24660; Wed, 17 Nov 1999 18:17:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01279 Wed, 17 Nov 1999 19:46:41 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B2D8@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Wed, 17 Nov 1999 19:52:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think this is really a security issue. If the certificate expires, it doesn't stop the user from being who they were when they negotiated the phase 2s (there's no retroactive MitM attack). The SAs will go away by themselves if the deletes are not sent (and we can't currently guarantee that they get there anyway). Although, the deletes are nice from a recovery perspective (and they are user-friendly). This is more of an issue from a speed/latency vs. memory usage perspective. Some of us would like to have the advantage of being able to send Isakmp packets at any time during the phase 2 lifetime without having to negotiate a new phase 1 (especially if this requires user intervention). And ifo ur products are memory hogs because of this strategy then so be it. There are many reasons for wanting a continuous channel besides for sending deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry), negotiating different phase 2 SAs with the same endpoints (for whatever conceivable reason), heartbeat/keep-alive protocols, legacy authentication protocols (e.g. periodic reauthentication), configuration protocols (e.g. private address renewal), the ability to carry information across a phase 1 rekey, lifetime notifies or other informational messages, other protocols that we haven't even imagined yet. If you don't want to support continuous channel mode, you don't have to. However, we find it useful. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Nov 17 20:56:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA09247; Wed, 17 Nov 1999 20:56:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01789 Wed, 17 Nov 1999 22:10:47 -0500 (EST) Date: Thu, 18 Nov 1999 05:13:45 +0200 (EET) Message-Id: <199911180313.FAA01770@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFF7B06B@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFF7B06B@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 23 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins writes: > Also, if you were the initial responder, and your phase 2 SA > lifetimes are shorter, how do you re-key the phase 2 SAs? I report my shorter lifetimes to the initiator using RESPONDER-LIFETIME notification, and if he doesn't care about it, it is his fault... > The fact that one of the cases is potentially rare is of > little relevance to me when the additional complexity to > make the whole thing cleaner is so little. It's not like > 20% increase in complexity is to gain 1% in usefulness. No it is more likely to have 5% increase in complexity to gain 0.000001% in usefulness. > And, yet again, if you don't care, don't worry about it, you > won't be affected. Lets put it this way. I see points keeping the Phase 1 SA up. Our implementation does that too, it tries to keep phase 1 up, but if it is short of resources, it will start throwing away phase 1 SA before throwing out phase 2 SAs. Anyways I don't see any point for adding special mode just for that. The benefits for knowing that the other end is following this rule of keeping the phase 1 up always hasn't even been considered at all. All of the points you had was only to have the phase 1 up for most of the time. I don't plan to implement a IKE server which will throw away phase 1 SAs immediately when phase 2 SAs are created, just to annoy people who want to have phase 1 up. I can create that kind of server for example in cases where I know that the phase 2 SA is going to be very short lived, and it is not going to be rekeyed at all. For example of that kind of system is daily currency rates server. I know that everybody will connect to the server only once per day, just to fetch one kilobyte. I might want to configure the phase 2 SA lifetime to 20 kB (because of possible retransmits), and 300 seconds (for those having very slow connection, or congested network). The phase 1 SA is not needed at all after the phase 2 is established, so I might want to remove it immediately after phase 2 is ready. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Nov 17 21:19:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10077; Wed, 17 Nov 1999 21:19:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01854 Wed, 17 Nov 1999 22:50:18 -0500 (EST) Message-Id: <199911171903.OAA00379@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-reply-to: Your message of "Wed, 17 Nov 1999 02:53:03 +0200." <199911170053.CAA07544@torni.ssh.fi> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Nov 1999 14:03:22 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> I don't relly see any point having phase 1 SA up there for 8 hours, Tero> just to be able to send again few hundred bytes of traffic for Tero> rekeying, and then again sitting idle for next 8 hours. If I have If you rekey only at these relatively long intervals, then you are completely correct. My impression of this issue is that the gateways in the client/gateway scenarios is far better off to drop phase 1 SAs. Odds are that the client won't be online for long enough to rekey anyway. It seems that there is a lot of advantage to doing "keepalives" in phase 2 SAs. An ICMP ping sent from the gateway's private network address (which likely is an acceptable source address for the phase 2 SA) sent to the client periodically will discover clients that have disappeared. The client doesn't even need to keep its IKE daemon alive for this, just its IPsec SA alive. For the gateway/gateway situation, where there may be the need to negotiate a continuing stream of per-host SAs, send decent error notifications, etc. it seems that keeping the phase 1 SA alive is a good thing, and my impression is that it is here that continuous mode gets the most benefit as well. So, my opinion is that everyone is right. (That should make me popular) ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQB1AwUBODL79o5hrHmwwFrtAQETGwL9HviXKjvRgSj4zNwON06C/Cpgplh5oc6y RphQKrbJ9i6/nebPWfjEyhkTtptLl2c9hLeZ9N1Zx+pvvb8uKdN+vHNBARo6T6bp YvBBsNCzQn44ZFm2ZW9XUJPAsGfgbIiO =Br7r -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Nov 17 23:52:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15986; Wed, 17 Nov 1999 23:52:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02386 Thu, 18 Nov 1999 01:26:36 -0500 (EST) Message-Id: <199911180627.WAA03444@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-reply-to: Your message of "Wed, 17 Nov 1999 19:52:09 EST." <319A1C5F94C8D11192DE00805FBBADDFF7B2D8@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3441.942906468.1@network-alchemy.com> Date: Wed, 17 Nov 1999 22:27:48 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 17 Nov 1999 19:52:09 EST you wrote > > This is more of an issue from a speed/latency vs. memory usage perspective. > Some of us would like to have the advantage of being able to send Isakmp > packets at any time during the phase 2 lifetime without having to negotiate > a new phase 1 (especially if this requires user intervention). And ifo ur > products are memory hogs because of this strategy then so be it. No it's not just speed/latency vs. memory usage it's complexity, and from the perspective of quite a few people it's unnecessary complex. This document does not prevent packet loss-- one of its stated goals-- because it requires the responder to delete all phase 2 SAs created with the "old" phase 1 SA upon a phase 1 "rekey". That means that packets will be dropped while a Quick Mode is done on the new IKE SA. It also causes more problems that it does not attempt to solve. The description of the "Continuous Channel Implementations" says: "Note that this automatic re-keying of phase 1 SAs means that SAs could live independent of traffic, since re-keying of both phase 1 and phase 2 SAs takes place with no traffic triggers (if they expire by time). In other words, SAs that are no longer necessary may never disappear. This suggests that a traffic monitoring capability should be part of implementations that need to delete idle or unused SAs. As such, it is not given further consideration, since it is beyond the scope of this document." SAs that never disappear?! > There are many reasons for wanting a continuous channel besides for sending > deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry), > negotiating different phase 2 SAs with the same endpoints (for whatever > conceivable reason), heartbeat/keep-alive protocols, legacy authentication > protocols (e.g. periodic reauthentication), configuration protocols (e.g. > private address renewal), the ability to carry information across a phase 1 > rekey, lifetime notifies or other informational messages, other protocols > that we haven't even imagined yet. IKE is a session establishment and key exchange protocol, it is not a catch-all transport for "other protocols that we haven't even imagined yet." This may be part of the problem: you have a hammer and now everything looks like a nail. > If you don't want to support continuous channel mode, you don't have to. > However, we find it useful. The issue is whether those of us who do not want to implement "continuous channel mode" will have to take certain precautions for those of you who do. If a side effect of doing "continuous channel mode" is that you will continue to re-key an SA which should be deleted, and unnecessarily use up resources on my box, then I'm going to have to take that into account and take some different behavior when I notice the vendor ID payload (or whatever mechanism you decide to use) indicating a "continuous channel mode" implementation. Also, Kivinen noted a good reason why one might want to do "dangling SA mode": resource concerns. What would you, as a "continuous channel mode" implementation do in this case? He would delete the IKE SA as it is not necessary to keep around. You would then delete your phase 2 SAs, causing a temporary blackhole, and re-negotiate. Then, some time later, he would again delete the IKE SA and the whole blackhole would repeat. This would not happen if you did the "dangling SA mode". It seems to me that you can't just say "if you don't want to do it you don't have to". Everybody will have to implement some portion of this Rube Goldberg machine just to remain interoperable. Dan. From owner-ipsec@lists.tislabs.com Thu Nov 18 06:23:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27252; Thu, 18 Nov 1999 06:23:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03342 Thu, 18 Nov 1999 07:35:55 -0500 (EST) From: shganguly@hss.hns.com X-Lotus-FromDomain: HSS To: ipsec@lists.tislabs.com Message-ID: <6525682D.0044FCFF.00@sandesh.hss.hns.com> Date: Thu, 18 Nov 1999 18:03:18 +0530 Subject: Buffer Management for IPsec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, This is regarding the buffer management issues for IPsec implementation. Protocols like AH, ESP require that some extra fields have to be inserted in between the original buffer. As a result of this, for doing authentication, encrption requires that the original buffer be copied to another buffer, and then do the processing. This buffer copy operation will result in a noticeable degradation in the performance of the system. Is there any way of getting over this? This problem is specifically for BITS and BITW kind of implementation. -Shamik Ganguly Hughes Software Systems, India From owner-ipsec@lists.tislabs.com Thu Nov 18 07:43:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29015; Thu, 18 Nov 1999 07:43:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03683 Thu, 18 Nov 1999 08:41:20 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B336@exchange> From: Tim Jenkins To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Thu, 18 Nov 1999 08:46:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: November 17, 1999 10:14 PM > To: Tim Jenkins > Cc: Scott G. Kelly; ipsec@lists.tislabs.com > Subject: RE: Phase 1 Re-keying Implementation Identification > > > Tim Jenkins writes: ... > > > The fact that one of the cases is potentially rare is of > > little relevance to me when the additional complexity to > > make the whole thing cleaner is so little. It's not like > > 20% increase in complexity is to gain 1% in usefulness. > > No it is more likely to have 5% increase in complexity to gain > 0.000001% in usefulness. I think we're going to have to agree to disagree on this one. We've already implemented it, so we know the increase in complexity to do that. > > > And, yet again, if you don't care, don't worry about it, you > > won't be affected. > ... > > Anyways I don't see any point for adding special mode just for that. > The benefits for knowing that the other end is following this rule of > keeping the phase 1 up always hasn't even been considered at all. All > of the points you had was only to have the phase 1 up for most of the > time. > The advantage in knowing how the other end operates is when you receive a delete for the last phase 1 SA between you, and there still exists 1 or more phase 2 SAs between you that you did not get a delete for. This can happen due to the optional and unreliable of the existing delete notifications. (Yes, I know there is a proposal to replace them.) In this case, if you know the peer uses a continuous channel model, then you know you can delete all the remaining phase 2 SAs. However, if you don't know which model the peer uses, you have to keep the phase 2 SAs. Maybe you should have, maybe you shouldn't. That's all; it helps in synchronisation between the end points. And as I keep saying, if you don't care, it won't affect you. From owner-ipsec@lists.tislabs.com Thu Nov 18 08:05:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29575; Thu, 18 Nov 1999 08:05:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03764 Thu, 18 Nov 1999 09:00:36 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B34E@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Thu, 18 Nov 1999 09:05:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: November 18, 1999 1:28 AM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 1 Re-keying Implementation Identification > > > On Wed, 17 Nov 1999 19:52:09 EST you wrote > > ... > > This document does not prevent packet loss-- one of its > stated goals-- > because it requires the responder to delete all phase 2 SAs > created with > the "old" phase 1 SA upon a phase 1 "rekey". That means that > packets will > be dropped while a Quick Mode is done on the new IKE SA. What are you talking about? Where does it say that? Once the phase 2 SAs are up, they get re-keyed independently of phase 1. The only that might change is which phase 1 SA was used to protect the quick mode. >From the document: ==> Therefore, the rules for phase 1 re-keying are: Initial Phase 1 Negotiation: -responder deletes any pre-existing phase 1 SA with the peer -use Initial Contact notification -responder deletes all phase 2 SAs with the peer Phase 1 Expires: -delete notification may be sent New Phase 1 is Negotiated -responder deletes any pre-existing phase 1 SA with the peer -no Initial Contact notification; phase 2 SAs are kept ^^^^^^^^^^^^^^^^^^^^ -if attempt fails, all other SAs are also deleted (no delete notification is used, since there is no valid SA) <== If somewhere else it suggests that the phase 2 SAs have to go away when the phase 1 SA expires and there exists a new phase 1, I need to know where that is to clean it up. > > It also causes more problems that it does not attempt to solve. The > description of the "Continuous Channel Implementations" says: > > "Note that this automatic re-keying of phase 1 SAs means that SAs > could live independent of traffic, since re-keying of both phase 1 > and phase 2 SAs takes place with no traffic triggers (if > they expire > by time). In other words, SAs that are no longer necessary > may never > disappear. > > This suggests that a traffic monitoring capability should > be part of > implementations that need to delete idle or unused SAs. As such, it > is not given further consideration, since it is beyond the scope of > this document." > > SAs that never disappear?! That was badly phrased. It should have said: In other words, SAs that are no longer necessary may continue to be re-keyed indefinitely. But I think you knew that. Further, it doesn't case this problem. This problem could exist with any phase 1 re-keying model except for the one you seemed to think that it proposed when you thought it said that the phase 2 SAs should go away. > > > There are many reasons for wanting a continuous channel > besides for sending > > deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry), > > negotiating different phase 2 SAs with the same endpoints > (for whatever > > conceivable reason), heartbeat/keep-alive protocols, legacy > authentication > > protocols (e.g. periodic reauthentication), configuration > protocols (e.g. > > private address renewal), the ability to carry information > across a phase 1 > > rekey, lifetime notifies or other informational messages, > other protocols > > that we haven't even imagined yet. > > IKE is a session establishment and key exchange protocol, it is not a > catch-all transport for "other protocols that we haven't even > imagined yet." > This may be part of the problem: you have a hammer and now > everything looks > like a nail. > So, you're saying that a phase 1 SA should be used to protect key exchanges only. So, we should outlaw the New Group exchange and no other exchanges? Andrew wasn't suggesting that IKE be used as transport. He's suggesting that the protection offered by the phase 1 SA can be used for other things. New Group Mode is an example of this, as is Configuration-Exchange. IKE daemon heartbeats is a potential example of this as well. ... > > It seems to me that you can't just say "if you don't want to > do it you don't > have to". Everybody will have to implement some portion of > this Rube Goldberg > machine just to remain interoperable. I don't agree with this. If this was correct, it would mean the continuous channel model violates the protocol. Can you point out where it violates the protocol? The resources argument is valid, but that means it's related to implementation and application. I think we need to agree to disagree on this one, if that's possible. And similarly for the complexity. > > Dan. > Tim From owner-ipsec@lists.tislabs.com Thu Nov 18 09:28:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01179; Thu, 18 Nov 1999 09:28:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04263 Thu, 18 Nov 1999 10:25:49 -0500 (EST) Message-Id: <199911181511.KAA04134@lists.tislabs.com> Date: Thu, 18 Nov 1999 10:14:10 -0500 (EST) From: "Kim Edwards" Reply-To: "Kim Edwards" Subject: Public Key Encryption Authentication To: ipsec@lists.tislabs.com X-Mailer: Rosa 2.1 SunOS5.5.1 X-Rosa-Trace: kimed@bcarsc7d <47.209.144.151> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA04135 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is anyone using this authentication method in their implementations? Assuming you are using RSA public keys, what key format does your interface accept? Do you enter the raw RSA key ( i.e. public modulus n with the public exponent e concatenated ) in hex format? Or do you enter the RSA key encoded with ASN.1? Kim From owner-ipsec@lists.tislabs.com Thu Nov 18 12:16:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04940; Thu, 18 Nov 1999 12:16:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04675 Thu, 18 Nov 1999 12:17:49 -0500 (EST) Message-ID: <383435C0.CECF9FDB@redcreek.com> Date: Thu, 18 Nov 1999 09:22:08 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <199911171903.OAA00379@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > So, my opinion is that everyone is right. (That should make me popular) Yes, you're a popular guy. I'd like to draw attention to something that has been alluded to by both Dan and Tero, but that seems to be missed in the chatter. Nobody here is advocating the wholesale disposal of phase 1 SAs after phase 2 is negotiated. I think we all agree that they remain useful under many circumstances. I think the point is that there is no requirement that the phase 1 SA remains. This doesn't mean that it won't under most circumstances, but only that it is not required to do so. Adding a "continuous mode" means adding a requirement that the phase 1 SA remain as long as there are related phase 2 SAs. This requires changing the behavior of everyone's IKE implementation (even if they do not implement it), as Dan noted; it has architectural implications, as I noted; and it has other implications, as Tero noted. I guess the question before us is, what is the case for modifying everyone's IKE implementation? That is, what are the benefits if we do vs. what are the costs if we do not? So far, I don't think that a convincing case has been made for the requested modifications. Scott From owner-ipsec@lists.tislabs.com Thu Nov 18 12:16:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04952; Thu, 18 Nov 1999 12:16:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05015 Thu, 18 Nov 1999 13:37:50 -0500 (EST) Message-ID: <3834475B.8D0422EC@greendragon.com> Date: Thu, 18 Nov 1999 13:37:46 -0500 From: William Allen Simpson X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: raven@ietf.org CC: ietf-ppp@merit.edu, ipsec@lists.tislabs.com Subject: FBI secret police References: <21565C751365D211BB2D0060089624CC1FBB16@TERRA> <199910140052.UAA06953@ietf.org> <380588A3.FE15BF86@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I prefer to give specific examples from life, rather than speculation, here's a long post that might give a hint as to why we do not trust our government agencies. Jacob Palme wrote: > This is also, perhaps, a difference of the view on > law enforcement agencies. In the U.S. you seem to be > much more afraid of misuse by law enforcement agencies, > you do not seem to trust your police as much as we do > in some other countries. > William Allen Simpson wrote: > And just to top it off, I've been unable to get my own personal > FBI records in 6 years. The law states they have 20 days. Their > most recent excuse says they have to search over a million records. > Wonder of wonders, I just received a portion of my FBI Freedom of Information records yesterday. Apparently, their very existance was classified "SECRET", by "G-3", and was supposed to be "declassified on: OADR". Any idea what that means? However, most of the contents were still classified secret again by 60267NLS/BCE/JMS for reason 1.5(C), on May 25, 1999, to be declassified on "X.1". So, virtually the entire documents are blacked out, labeled "b1". The included handy reference guide lists "(b)(1)" as: "(A) specifically authorized under criteria established by an Executive order to be kept secret in the interest of national defense or foreign policy and (B) are in fact properly classified pursuant to such Executive order" These records are from 1991, 1992, and 1993. The "predication for this investigation" is secret. The "Basis of the Investigation" is secret. The "Objectives of the Investigation" are secret. The "Status of the Investigation" is secret. Other smaller sections are blacked out with labels (b)(2): "related solely to the internal personnel rules and practices of the agency" and (b)(7)(D): "could reasonably be expected to disclose the identity of a confidential source, including a State, local, or foreign agent or authority or any private institution which furnished information on a confidential basis, and, in the case of records or information compiled by a criminal law enforcement agency in the course of a criminal investigation, or by an agency conducting a lawful national security intelligence investigation, information furnished by confidential source" It is particularly amusing that the latter is used to black out records of contact with my own parents (who refused to talk with them), copies of email that I sent, and my vehicle title (where I have the original copy). Somebody had a very heavy hand in the censorship. (Also amusing, the FBI was still using all cap teletype in '92 :-) What is less amusing is that the FBI spent over a year going to each place that I had email access and tried to convince them to revoke my access. They were successful in (at least) two places. They interviewed at least 11 people out of their Albuquerque, Boston, Detroit, Minneapolis and San Francisco offices. Apparently, they investigated my IETF activities at Santa Fe, San Diego, Boston and Washington DC. They quote the Santa Fe and San Diego proceedings. They direct agents to IETF meetings, "to ascertain if subject came to any notice at the PPPWG meetings." They make specific reference to CHAP and DES. Various clear sentence fragments indicate a concern that the PPPWG meeting was taking place sponsored by Los Alamos, and that "these meetings attract interested persons worldwide." Another fragment indicates a concern that my PPP software was distributed by servers at White Sands Missile Base and mirrored at various universities. The most legible interview, still mostly blacked out, gives a hint as to the questions that were being raised: " stated that he believes the PPP is legal technology. However, if the government is attempting to restrict the dissemination of authentication protocols, he believes it is too late. It is like locking the barn after the horse has escaped (per ). "In summary, does not believe Simpson has engaged in breaking United States export laws regarding the export of cryptographic devices or is interested in violating such laws at the behest of a foreign power." The name blacked out appears to occupy 3 letters. My thanks to Karl Fox or Craig Fox! The instigator of the investigation appears to have a surname of 4 or maybe 5 letters. Thus, it is probably not "Atkinson". Perhaps it's the former IAB member that required the removal of the PPP LCP encryption option, refused to publish CHAP, and refused to grant the IPSec charter.... When the NomCom replaced the IAB, he was first against the wall. "Sources whose identities are concealed herein have furnished reliable information in the past except when otherwise noted." Gentlefolk, we have a stool pigeon in the roost, whose interests are contrary to the interests of the IETF and the Internet as a whole. It is a male. And he is regularly reporting IETF member activities for secret investigation. Beware. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Thu Nov 18 12:18:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04982; Thu, 18 Nov 1999 12:18:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04985 Thu, 18 Nov 1999 13:36:11 -0500 (EST) Date: Thu, 18 Nov 1999 13:38:34 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Public Key Encryption Authentication In-Reply-To: <199911181511.KAA04134@lists.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 18 Nov 1999, Kim Edwards wrote: > Is anyone using this authentication method in their implementations? > Assuming you are using RSA public keys, what key format does your > interface accept? Do you enter the raw RSA key ( i.e. public modulus n > with the public exponent e concatenated ) in hex format? Or do you enter > the RSA key encoded with ASN.1? Reading RFC 2537 section 2 (encoding of RSA public keys) and RFC 2535 section 7.1 (ASCII representation of KEY records) will be informative. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Nov 18 12:52:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05467; Thu, 18 Nov 1999 12:52:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04916 Thu, 18 Nov 1999 13:15:43 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B517@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Thu, 18 Nov 1999 13:19:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan. I think Tim already answered most of your questions, but I have one additional comment: > The issue is whether those of us who do not want to implement > "continuous > channel mode" will have to take certain precautions for those > of you who do. > If a side effect of doing "continuous channel mode" is that you will > continue to re-key an SA which should be deleted, and > unnecessarily use up > resources on my box, then I'm going to have to take that into > account and > take some different behavior when I notice the vendor ID payload (or > whatever mechanism you decide to use) indicating a > "continuous channel mode" > implementation. The reason for the vendor id is so you don't have to change your behaviour. If a continuous channel implementation detects a peer that is also continuous channel then it may make certain assumptions: 1) It is ok to always rekey phase 1s before they go down. 2) If the phase 1 goes down without being rekeyed it is because the peer is unreachable (so the phase 2s can be deleted). If we recognize that the peer is a dangling phase 2 implementation then we alter our behaviour in order to cooperate. However, our boxes currently have to distinguish between dangling implementations and continuous channel implementations by observing their behaviour (looking for an early phase 1 delete). This is unreliable, since the phase 1 delete may be lost (or never sent). We need a method of reliably detecting cooperating peers in the field. Hence, the vendor id. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Nov 18 13:56:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06744; Thu, 18 Nov 1999 13:56:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05508 Thu, 18 Nov 1999 15:15:14 -0500 (EST) Date: Thu, 18 Nov 1999 15:18:18 -0500 Message-Id: <199911182018.PAA28737@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: akrywaniuk@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7B517@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> Hi Dan. I think Tim already answered most of your questions, Andrew> but I have one additional comment: >> The issue is whether those of us who do not want to implement >> "continuous channel mode" will have to take certain precautions >> for those of you who do. If a side effect of doing "continuous >> channel mode" is that you will continue to re-key an SA which >> should be deleted, and unnecessarily use up resources on my box, >> then I'm going to have to take that into account and take some >> different behavior when I notice the vendor ID payload (or >> whatever mechanism you decide to use) indicating a "continuous >> channel mode" implementation. Andrew> The reason for the vendor id is so you don't have to change Andrew> your behaviour. If a continuous channel implementation Andrew> detects a peer that is also continuous channel then it may Andrew> make certain assumptions: Andrew> 1) It is ok to always rekey phase 1s before they go down. 2) Andrew> If the phase 1 goes down without being rekeyed it is because Andrew> the peer is unreachable (so the phase 2s can be deleted). Andrew> If we recognize that the peer is a dangling phase 2 Andrew> implementation then we alter our behaviour in order to Andrew> cooperate. That's a nice idea but you CANNOT do this with Vendor ID. If in running a protocol you need to know whether feature X is implemented at the other end, the ONLY correct way to do this is to encode that fact directly in the protocol. If X is mandatory in version Y, the version number is one way to do that. Alternatively, a flag that says "I implement X" works. But it is never correct to infer from the identity of the vendor that X is, or isn't, implemented. paul From owner-ipsec@lists.tislabs.com Thu Nov 18 14:00:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06784; Thu, 18 Nov 1999 14:00:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05481 Thu, 18 Nov 1999 15:12:59 -0500 (EST) Message-Id: <199911182014.MAA04975@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-reply-to: Your message of "Thu, 18 Nov 1999 09:05:52 EST." <319A1C5F94C8D11192DE00805FBBADDFF7B34E@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4972.942956055.1@network-alchemy.com> Date: Thu, 18 Nov 1999 12:14:15 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 18 Nov 1999 09:05:52 EST you wrote > > This document does not prevent packet loss-- one of its > > stated goals-- > > because it requires the responder to delete all phase 2 SAs > > created with > > the "old" phase 1 SA upon a phase 1 "rekey". That means that > > packets will > > be dropped while a Quick Mode is done on the new IKE SA. > > What are you talking about? Where does it say that? > > Once the phase 2 SAs are up, they get re-keyed independently > of phase 1. The only that might change is which phase 1 SA was > used to protect the quick mode. OK, that was my mistake. That text was under "Initial Phase 1 Negotiation" from a previous page. > That was badly phrased. It should have said: > > In other words, SAs that are no longer necessary may continue > to be re-keyed indefinitely. > > But I think you knew that. But that text isn't any better. Re-keying an SA indefinitely is definitely a problem. This is an example of how a non-continuous channel mode implementation will have to change because of the existance of continuous channel mode implementations. Basically, if someone initiates IKE with me I think he does so for a reason. This being IPSec the reason is that he wants to negotiate IPSec SAs. If you just negotiate an IKE SA and do nothing or negotiate IPSec SAs that are not used that is a problem for me. I will now have to take into account the possibility that someone will unnecessarily negotiate with me ad nauseum. If the possibility of talking to you is that you will never shut up then I will have to decide whether I ever want to talk to you. That is a problem from an interoperability point of view. > Further, it doesn't case this problem. This problem could exist > with any phase 1 re-keying model except for the one you seemed > to think that it proposed when you thought it said that the > phase 2 SAs should go away. No. This problem doesn't exist in my rekeying model. There are plenty of fielded implementations that do not follow your document but don't have the problems you describe nor do they suffer from the problems which arise if they did follow your document. There are lots of people that are very happy with the rekeying done by our product. No loss of packets for tunnels which are long-term (up always, continuously rekeyed, both the IPSec SAs and, independently, the IKE SAs) nor for tunnels which are short-term (on demand, when the demand stops the tunnel goes away and we don't continue to negotiate things that will not be used). So the issue now is what do I have to do to make sure that things will continue to work the same way if a continuous channel mode implementation is on the other end? > > > There are many reasons for wanting a continuous channel > > besides for sending > > > deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry), > > > negotiating different phase 2 SAs with the same endpoints > > (for whatever > > > conceivable reason), heartbeat/keep-alive protocols, legacy > > authentication > > > protocols (e.g. periodic reauthentication), configuration > > protocols (e.g. > > > private address renewal), the ability to carry information > > across a phase 1 > > > rekey, lifetime notifies or other informational messages, > > other protocols > > > that we haven't even imagined yet. > > > > IKE is a session establishment and key exchange protocol, it is not a > > catch-all transport for "other protocols that we haven't even > > imagined yet." > > This may be part of the problem: you have a hammer and now > > everything looks > > like a nail. > > So, you're saying that a phase 1 SA should be used to protect > key exchanges only. So, we should outlaw the New Group exchange > and no other exchanges? I'm saying nothing as hyperbolic as that. What I'm saying is that when you ascribe certain characteristics to an IKE SA that it was not designed to have then you have problems. If you stopped ascribing those characteristics to the IKE SA then the problems would go away. If you want to continue to ascribe characteristics for future, as yet unknown, protocols then you'll continue to have problems. And several of these wheels you're inventing have been invented before (e.g. DHCP) so welding them onto IKE might not necessarily be the wisest thing to do. Since this seems to be the genesis of rekeying problems I think it absolutely is not the wisest thing to do. > > It seems to me that you can't just say "if you don't want to > > do it you don't > > have to". Everybody will have to implement some portion of > > this Rube Goldberg > > machine just to remain interoperable. > > I don't agree with this. If this was correct, it would mean > the continuous channel model violates the protocol. Can you > point out where it violates the protocol? It doesn't violate the protocol but it requires internal bookeeping that forces the protocol to behave in a way that it naturally does not behave and implementations that do not behave that way will have to take such behavior into account. Just because something does not violate a protocol does not mean that it is not pathologic. > The resources argument is valid, but that means it's related to > implementation and application. Yes it is. And the issue is does my implementation have to change because of the way you're behaving. It looks like the answer is yes and that's a problem. Some very legitimate behavior that I may want to do-- clean up unneeded IKE SAs for instance-- can result in temporary blackholes and, more egregiously, exacerbate the situation that caused my behavior! In other words, I'm trying to conserve resources and every attempt I make to conserve resources causes you to make me chew up more resources. Dan. From owner-ipsec@lists.tislabs.com Thu Nov 18 15:27:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08357; Thu, 18 Nov 1999 15:27:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06059 Thu, 18 Nov 1999 16:34:53 -0500 (EST) Date: Thu, 18 Nov 1999 23:37:54 +0200 (EET) Message-Id: <199911182137.XAA14416@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Kim Edwards" Cc: ipsec@lists.tislabs.com Subject: Public Key Encryption Authentication In-Reply-To: <199911181511.KAA04134@lists.tislabs.com> References: <199911181511.KAA04134@lists.tislabs.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kim Edwards writes: > Is anyone using this authentication method in their implementations? Yes. We are supporting it. Also our test-site (isakmp-test.ssh.fi) supports it. > Assuming you are using RSA public keys, what key format does your > interface accept? Normally we use normal X.509 certificates. > Do you enter the raw RSA key ( i.e. public modulus n with the public > exponent e concatenated ) in hex format? Or do you enter the RSA key > encoded with ASN.1? We have some tools to process different kind of public key formats, and creating something new to import keys in different format is quite easy. If you are testing with the test-site, you must send your public key before it is needed inside the IKE CERT payloads (X.509 certificate). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Nov 18 15:41:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08580; Thu, 18 Nov 1999 15:41:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06192 Thu, 18 Nov 1999 16:55:30 -0500 (EST) Date: Thu, 18 Nov 1999 23:58:37 +0200 (EET) Message-Id: <199911182158.XAA15526@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFF7B336@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFF7B336@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins writes: > The advantage in knowing how the other end operates is when you > receive a delete for the last phase 1 SA between you, and there > still exists 1 or more phase 2 SAs between you that you did not > get a delete for. This can happen due to the optional and > unreliable of the existing delete notifications. (Yes, I know > there is a proposal to replace them.) So, what you really gain from the information that you know that the other end support continuous channel mode is, that you can delete one unused phase 2 SA before its natural lifetime, in the case of the lost phase 2 SA delete. So we save up the resources used by one unused phase 2 SA, but only in special case where we lost the phase 2 SA delete notification. But we waste much more resources to keep the all the phase 1 SAs up until the phase 2 SAs are deleted. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Nov 18 16:08:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09028; Thu, 18 Nov 1999 16:08:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06360 Thu, 18 Nov 1999 17:18:58 -0500 (EST) From: "Scott Fanning" To: "Paul Koning" , Cc: Subject: RE: Phase 1 Re-keying Implementation Identification Date: Thu, 18 Nov 1999 14:19:33 -0800 Message-ID: <000001bf3212$fdd10f80$ab2647ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199911182018.PAA28737@tonga.xedia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think we want to start having to configure multiple behaviors (or have knowledge of them) based upon a particular vendors implementation. The whole point of a protocol to facilitate common communication framework. Vendor ID usage for enabling standard based features are fine, but basing behavior (slight variants of the standard) on a vendors interpretation of the standard gives me the willies. Scott > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning > Sent: Thursday, November 18, 1999 12:18 PM > To: akrywaniuk@TimeStep.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Re-keying Implementation Identification > > > >>>>> "Andrew" == Andrew Krywaniuk writes: > > Andrew> Hi Dan. I think Tim already answered most of your questions, > Andrew> but I have one additional comment: > > >> The issue is whether those of us who do not want to implement > >> "continuous channel mode" will have to take certain precautions > >> for those of you who do. If a side effect of doing "continuous > >> channel mode" is that you will continue to re-key an SA which > >> should be deleted, and unnecessarily use up resources on my box, > >> then I'm going to have to take that into account and take some > >> different behavior when I notice the vendor ID payload (or > >> whatever mechanism you decide to use) indicating a "continuous > >> channel mode" implementation. > > Andrew> The reason for the vendor id is so you don't have to change > Andrew> your behaviour. If a continuous channel implementation > Andrew> detects a peer that is also continuous channel then it may > Andrew> make certain assumptions: > > Andrew> 1) It is ok to always rekey phase 1s before they go down. 2) > Andrew> If the phase 1 goes down without being rekeyed it is because > Andrew> the peer is unreachable (so the phase 2s can be deleted). > > Andrew> If we recognize that the peer is a dangling phase 2 > Andrew> implementation then we alter our behaviour in order to > Andrew> cooperate. > > That's a nice idea but you CANNOT do this with Vendor ID. > > If in running a protocol you need to know whether feature X is > implemented at the other end, the ONLY correct way to do this is to > encode that fact directly in the protocol. If X is mandatory in > version Y, the version number is one way to do that. Alternatively, a > flag that says "I implement X" works. But it is never correct to > infer from the identity of the vendor that X is, or isn't, > implemented. > > paul > > > From owner-ipsec@lists.tislabs.com Thu Nov 18 17:13:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10749; Thu, 18 Nov 1999 17:13:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06616 Thu, 18 Nov 1999 18:23:40 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Thu, 18 Nov 1999 18:28:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is from Tero's draft, [EXT-METH]: "The second use [of vendor ids] is to allow for vendor specific extensions, after both ends have sent and received familiar vendor IDs. [...] If familiar vendor ID payloads have been exchanged (both sent and received) then implementations MAY do anything, including using private extensions, private payloads, new identity types, running nethack over the ISAKMP SA, etc." This is from [ISAKMP]: "The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well." By my interpretation of the drafts, if both peers send a vendor id which says "I do continuous channels" then it is appropriate for them to modify their behaviour accordingly. However, if a host sends the vendor id and the peer does not return it then he should not make any assumptions about the peer's implementation. Therefore, he should not delete the phase 2s if the phase 1 is not rekeyed. As you can see, this means that (contrary to popular belief) continuous channel support is ***UNOBTRUSIVE***. If you don't want to support it then don't send the vendor id and the continuous channel feature will be automatically disabled. Our belief is that the benefits of continuous channels outweigh the disadvantages. Even if other vendors will be using dangling phase 2s, we want to use it when negotiating with our own products. Tim was merely proposing that the vendor id be made public so that other vendors who use this mode can use it when interoperating with us. As for the more general question of whether it is appropriate to use vendor ids to advertise a feature, this appears to be the only method available in IKE at the moment. All I can say is that the drafts do not disallow this, and they specifically allow an implementation to send as many version ids as it wants. If you have a better solution then let's talk. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Thursday, November 18, 1999 3:18 PM > To: akrywaniuk@TimeStep.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Re-keying Implementation Identification > > > >>>>> "Andrew" == Andrew Krywaniuk writes: > > Andrew> Hi Dan. I think Tim already answered most of your questions, > Andrew> but I have one additional comment: > > >> The issue is whether those of us who do not want to implement > >> "continuous channel mode" will have to take certain precautions > >> for those of you who do. If a side effect of doing "continuous > >> channel mode" is that you will continue to re-key an SA which > >> should be deleted, and unnecessarily use up resources on my box, > >> then I'm going to have to take that into account and take some > >> different behavior when I notice the vendor ID payload (or > >> whatever mechanism you decide to use) indicating a "continuous > >> channel mode" implementation. > > Andrew> The reason for the vendor id is so you don't have to change > Andrew> your behaviour. If a continuous channel implementation > Andrew> detects a peer that is also continuous channel then it may > Andrew> make certain assumptions: > > Andrew> 1) It is ok to always rekey phase 1s before they go down. 2) > Andrew> If the phase 1 goes down without being rekeyed it is because > Andrew> the peer is unreachable (so the phase 2s can be deleted). > > Andrew> If we recognize that the peer is a dangling phase 2 > Andrew> implementation then we alter our behaviour in order to > Andrew> cooperate. > > That's a nice idea but you CANNOT do this with Vendor ID. > > If in running a protocol you need to know whether feature X is > implemented at the other end, the ONLY correct way to do this is to > encode that fact directly in the protocol. If X is mandatory in > version Y, the version number is one way to do that. > Alternatively, a > flag that says "I implement X" works. But it is never correct to > infer from the identity of the vendor that X is, or isn't, > implemented. > > paul > From owner-ipsec@lists.tislabs.com Thu Nov 18 20:28:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA24786; Thu, 18 Nov 1999 20:28:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07182 Thu, 18 Nov 1999 21:18:36 -0500 (EST) Message-Id: <4.2.1.19991118181403.00c4cc20@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 18 Nov 1999 18:20:16 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: RE: Phase 1 Re-keying Implementation Identification In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:28 PM 11/18/99 -0500, Andrew Krywaniuk wrote: >As for the more general question of whether it is appropriate to use vendor >ids to advertise a feature, this appears to be the only method available in >IKE at the moment. Then you should change IKE (or ISAKMP). The first sentence of section 3.16 in ISAKMP says "The Vendor ID Payload contains a vendor defined constant." You are not proposing a vendor-defined constant, you're proposing an announcement of feature that may be standards-track. These are completely different. If you want continuous channel support to be TimeStep-only, it is appropriate to use the Vendor ID payload. Otherwise, some other mechanism for both sides to be sure that the other side is using it must be developed. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Nov 18 21:52:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA28335; Thu, 18 Nov 1999 21:52:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07455 Thu, 18 Nov 1999 23:15:29 -0500 (EST) Mime-Version: 1.0 X-Sender: rah@shell3.shore.net Message-Id: Date: Thu, 18 Nov 1999 23:02:11 -0500 To: William Allen Simpson , raven@ietf.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Robert Hettinga Subject: Re: FBI secret police Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- begin forwarded text Date: Thu, 18 Nov 1999 20:51:02 -0500 To: Robert Hettinga , CYBERIA-L@LISTSERV.AOL.COM, cryptography@c2.net, cypherpunks@cyberpass.net From: Matthew Lyle Subject: Re: FBI secret police At 5:58 PM -0500 11/18/99, Robert Hettinga wrote: >--- begin forwarded text > > >Date: Thu, 18 Nov 1999 13:37:46 -0500 >From: William Allen Simpson >To: raven@ietf.org >CC: ietf-ppp@merit.edu, ipsec@lists.tislabs.com >Subject: FBI secret police >Sender: owner-ipsec@lists.tislabs.com > >As I prefer to give specific examples from life, rather than speculation, >here's a long post that might give a hint as to why we do not trust our >government agencies. > >William Allen Simpson wrote: > > And just to top it off, I've been unable to get my own personal > > FBI records in 6 years. The law states they have 20 days. Their > > most recent excuse says they have to search over a million records. > > >Wonder of wonders, I just received a portion of my FBI Freedom of >Information records yesterday. Apparently, their very existance was >classified "SECRET", by "G-3", and was supposed to be "declassified on: >OADR". Any idea what that means? > OADR is the acronym for "Originating Agency's Determination Required". -- Matthew Lyle matt@nova.org 703-573-8895 603-388-8054 Fax (yes, 603) 703-477-8789 Cell --- end forwarded text ----------------- Robert A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From owner-ipsec@lists.tislabs.com Fri Nov 19 05:40:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13335; Fri, 19 Nov 1999 05:40:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08661 Fri, 19 Nov 1999 06:55:09 -0500 (EST) Message-Id: <199911191158.GAA16457@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt Date: Fri, 19 Nov 1999 06:58:07 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec Flow Monitoring MIB Author(s) : C. Madson, L. Temoshenko, C. Pellacuru, N. Timms, R. Somasundaram Filename : draft-ietf-ipsec-flow-monitoring-mib-00.txt Pages : 107 Date : 18-Nov-99 This document describes a high-level MIB for monitoring, accounting and error detection for IPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-flow-monitoring-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991118122918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-flow-monitoring-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991118122918.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Nov 19 07:13:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15163; Fri, 19 Nov 1999 07:13:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08888 Fri, 19 Nov 1999 08:27:13 -0500 (EST) Message-ID: <383482FC.52FC1EDB@americasm01.nt.com> Date: Thu, 18 Nov 1999 17:51:40 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: Re: Public Key Encryption Authentication References: <199911181511.KAA04134@lists.tislabs.com> <199911182137.XAA14416@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > > Kim Edwards writes: > > Is anyone using this authentication method in their implementations? > > Yes. We are supporting it. Also our test-site (isakmp-test.ssh.fi) > supports it. > > > Assuming you are using RSA public keys, what key format does your > > interface accept? > > Normally we use normal X.509 certificates. So do we. I was thinking more on the line of negotiating with an implementation that can only support the authentication with public key encryption ( i.e. it does not have a CA or access to certificates ). When this implementation would generate an RSA public key pair, what is the common format to pass the public portion to another party? --- Kim Edwards ILS Software Engineer, Nortel Networks (613)765-8551 From owner-ipsec@lists.tislabs.com Fri Nov 19 07:14:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15194; Fri, 19 Nov 1999 07:14:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08905 Fri, 19 Nov 1999 08:29:13 -0500 (EST) Message-Id: <4.1.19991119082100.009bcde0@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 19 Nov 1999 08:21:49 -0500 To: William Allen Simpson , raven@ietf.org From: Christian Huitema Subject: Re: [Raven] FBI secret police Cc: ietf-ppp@merit.edu, ipsec@lists.tislabs.com In-Reply-To: <3834475B.8D0422EC@greendragon.com> References: <21565C751365D211BB2D0060089624CC1FBB16@TERRA> <199910140052.UAA06953@ietf.org> <380588A3.FE15BF86@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, The IETF operate in public, under public scrutiny. There is no way we can hide our debates from nayone, let alone the FBI. -- Christian Huitema From owner-ipsec@lists.tislabs.com Fri Nov 19 07:29:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15433; Fri, 19 Nov 1999 07:29:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09144 Fri, 19 Nov 1999 08:57:12 -0500 (EST) Message-ID: <3835577A.2F12FBCC@indusriver.com> Date: Fri, 19 Nov 1999 08:58:18 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <4.2.1.19991118181403.00c4cc20@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman wrote: > If you want continuous channel support to be TimeStep-only, it is > appropriate to use the Vendor ID payload. Otherwise, some other mechanism > for both sides to be sure that the other side is using it must be developed. Is ISAKMP Mode Config (draft-ietf-ipsec-isakmp-mode-config-05.txt) an appropriate mechanism to negotiate optional features such as Continuous Mode if we conclude that continuous mode is needed? -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Fri Nov 19 07:32:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15488; Fri, 19 Nov 1999 07:32:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09169 Fri, 19 Nov 1999 09:00:13 -0500 (EST) Message-ID: <38355829.EF9A8ABF@indusriver.com> Date: Fri, 19 Nov 1999 09:01:13 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Tim Jenkins , ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <199911182014.MAA04975@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, you wrote that your rekeying model doesn't suffer from the problems that arise from Tim's model as defined in Tim's rekeying draft. I don't recall seeing a definition of your rekeying model. Can you spend a minute defining it on the list so we can compare it to the model proposed by Tim? -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Fri Nov 19 08:03:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16042; Fri, 19 Nov 1999 08:03:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09269 Fri, 19 Nov 1999 09:24:00 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B65C@exchange> From: Tim Jenkins To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Fri, 19 Nov 1999 09:28:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to clarify a point, but I think we will not pursue attempting to recognize continuous channel implementations any further. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: November 18, 1999 4:59 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Re-keying Implementation Identification > > > Tim Jenkins writes: > > The advantage in knowing how the other end operates is when you > > receive a delete for the last phase 1 SA between you, and there > > still exists 1 or more phase 2 SAs between you that you did not > > get a delete for. This can happen due to the optional and > > unreliable of the existing delete notifications. (Yes, I know > > there is a proposal to replace them.) > > So, what you really gain from the information that you know that the > other end support continuous channel mode is, that you can delete one > unused phase 2 SA before its natural lifetime, in the case of the lost > phase 2 SA delete. > > So we save up the resources used by one unused phase 2 SA, but only in > special case where we lost the phase 2 SA delete notification. But we > waste much more resources to keep the all the phase 1 SAs up until the > phase 2 SAs are deleted. It isn't just a resource issue. It's also related to how well the protocol behaves from a customer point of view. It seems to me that no one seems to care that one end can have an SA that will potentially spew invalid packets at another end. Here's an example of why I think we should minimize this: One of the MIBs has a trap for reporting when invalid ESP packets are received. If applications do not clean themselves up as well as possible, this trap effectively becomes useless, since it will cry "wolf" so much that customers will shut if off. If someone says that we shouldn't define the protocol based on the MIB, they're right, but they're also missing the point. I'm having explaining it better. Further, as I'm starting to say elsewhere, this isn't a protocol issue, it's an application-specific-use-of-the-protocol issue. Tim From owner-ipsec@lists.tislabs.com Fri Nov 19 08:05:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16064; Fri, 19 Nov 1999 08:05:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09292 Fri, 19 Nov 1999 09:24:38 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFF7B65E@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Fri, 19 Nov 1999 09:29:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me that one of the reasons we're having problems here is that we're all trying to define SA management (both phase 1 and phase 2) to cover all possible applications. Since we have, in general, different products, we're going to have different perspectives. It may be that there is no single method that covers all the possible uses of IKE as a key exchange protocol, or all possible uses of the resulting phase 1 SAs. Perhaps this is what Michael Richardson was trying to say? In any case, I'd like to continue the discussion below, just a bit more(?). --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: November 18, 1999 3:14 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 1 Re-keying Implementation Identification > > > On Thu, 18 Nov 1999 09:05:52 EST you wrote ... > > > That was badly phrased. It should have said: > > > > In other words, SAs that are no longer necessary may continue > > to be re-keyed indefinitely. > > > > But I think you knew that. > > But that text isn't any better. Re-keying an SA indefinitely > is definitely > a problem. This is an example of how a non-continuous channel mode > implementation will have to change because of the existance > of continuous > channel mode implementations. Indefinite re-keying of phase 2 SAs might occur independent of how you model your phase 1 re-keying. In other words, the triggers that require the existence of a specific phase 2 SA (based on selectors). (See more on this below...) However, you are right that the continuous channel model will cause indefinite re-keying of phase 1 SAs. But that's what it's designed to do: to provide continuously available service if needed. It doesn't dis-allow a mechanism to shut everything down between two peers. > > Basically, if someone initiates IKE with me I think he does > so for a reason. > This being IPSec the reason is that he wants to negotiate > IPSec SAs. If you > just negotiate an IKE SA and do nothing or negotiate IPSec > SAs that are not > used that is a problem for me. I will now have to take into > account the > possibility that someone will unnecessarily negotiate with me > ad nauseum. > If an IPsec SA is not needed, it can be deleted, by either end. What I'm suggesting does not mean I will arbitrarily bring phase 2 SAs back up; this continuous channel model applies only to phase 1 SAs, and only applies to provide a control channel for any phase 2 SAs that exist. There seem to be two parts of the proposal that fit your concerns. The first part of the continuous channel model that seems to relate to your concern here is this line from table 1. -phase 1 SA deletion -re-key phase 1 SA (1) If the action to re-key the phase 1 SA when there is only one and it is deleted by the peer is removed, then this would effectively cause a continuous channel model to revert to a dangling model. The second is the automatic re-keying of phase 1 SAs. You seem to object to this under the assumption that the new SA that is created will never get used. First, it is assumed that phase 1 SAs lifetimes are longer than phase 2 SA lifetimes. This assumption was, I believe, the reason the authorization lifetime argument was decided to have no significance in determining phase 1 re-keying. (The argument went that the potential time that the phase 2 SAs could live beyond the authenticated lifetime was small.) So, if phase 2 SA lifetimes are smaller than phase 1 SA lifetimes, then the new phase 1 SA will definitely be used to re-key the phase 2 SAs. If for some reason the phase 2 SA is not to be re-keyed, and deleted either before the end of its lifetime or when it expires, then the new phase 1 SA is used to send the delete notification to the peer. Now, your memory resource issue is valid: Why keep the phase 1 SA in memory when it may not be needed until the phase 2 SA needs re-keying or deletion? If the re-keying line from the table above is removed, then that could solve the problem. The endpoint that is running out of resources can delete the phase 1 SA. Hopefully, it can be re-generated later when it is really needed. Would that reduce your concerns about interoperating with a continuous channel implementation (in the general case; not the application specific case)? > If the possibility of talking to you is that you will never > shut up then I > will have to decide whether I ever want to talk to you. That > is a problem > from an interoperability point of view. Again, these models don't preclude some sort of over-all management. > > > Further, it doesn't case this problem. This problem could exist > > with any phase 1 re-keying model except for the one you seemed > > to think that it proposed when you thought it said that the > > phase 2 SAs should go away. > > No. This problem doesn't exist in my rekeying model. There > are plenty of > fielded implementations that do not follow your document but > don't have > the problems you describe nor do they suffer from the > problems which arise > if they did follow your document. There are lots of people > that are very > happy with the rekeying done by our product. No loss of > packets for tunnels > which are long-term (up always, continuously rekeyed, both > the IPSec SAs and, > independently, the IKE SAs) nor for tunnels which are > short-term (on demand, > when the demand stops the tunnel goes away and we don't > continue to negotiate > things that will not be used). Once again, if we're talking about phase 2 SA re-keying, if you limit yourself to talking with a like implementation, you might be right. Remember that the phase 2 re-keying suggestions made are an attempt to cover as many of the different interpretations out there, and to provide lossless re-keying of phase 2 SAs under as many different circumstances as possible. Since I don't know exactly how your implementation re-keys, I can't do an analysis of it to suggest where you might have problems in circumstances that your customers haven't yet encountered. > > So the issue now is what do I have to do to make sure that things will > continue to work the same way if a continuous channel mode > implementation > is on the other end? Again, would removing that one line from the state table help? > ... > > > > So, you're saying that a phase 1 SA should be used to protect > > key exchanges only. So, we should outlaw the New Group exchange > > and no other exchanges? > > I'm saying nothing as hyperbolic as that. What I'm saying is > that when you > ascribe certain characteristics to an IKE SA that it was not > designed to > have then you have problems. If you stopped ascribing those > characteristics > to the IKE SA then the problems would go away. If you want to > continue to > ascribe characteristics for future, as yet unknown, protocols > then you'll > continue to have problems. And several of these wheels you're > inventing have > been invented before (e.g. DHCP) so welding them onto IKE might not > necessarily be the wisest thing to do. Since this seems to be > the genesis > of rekeying problems I think it absolutely is not the wisest > thing to do. Sorry, I don't understand what characteristics we're ascribing to an IKE SA that it doesn't have. Doesn't it have the ability to protect exchanges using packet formats as defined in RFC2408? Maybe we're running into application specific concepts here. And it's related to how we want to manage the SAs. > ... > > > The resources argument is valid, but that means it's related to > > implementation and application. > > Yes it is. And the issue is does my implementation have to > change because > of the way you're behaving. It looks like the answer is yes > and that's a > problem. Some very legitimate behavior that I may want to > do-- clean up > unneeded IKE SAs for instance-- can result in temporary > blackholes and, > more egregiously, exacerbate the situation that caused my > behavior! In > other words, I'm trying to conserve resources and every > attempt I make to > conserve resources causes you to make me chew up more resources. Again, would the change I'm suggesting remove your concern about being able to control your SAs in a manner you want? I'll repeat this: my proposal does not preclude the use of idle timeouts, or anything like that. In fact, it suggests that they should be used. Or is that the concern? That they become necessary? But if they aren't, how do you losslessly re-key? Do you drop phase 2 SAs when they expire and wait until traffic starts up again to re-generate new ones? What if there's no let up traffic? How do you do this without packet loss? Or do you really lose a packet here and there, and no one seems to notice? In other words, I don't see how you can losslessly re-key phase 2 SAs without doing it automatically. This then leads to needed some kind of idle time-out detection to automatically delete the unused phase 2 SAs. And all of this is independent of phase 1 re-keying. > > Dan. > Tim From owner-ipsec@lists.tislabs.com Fri Nov 19 09:32:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17464; Fri, 19 Nov 1999 09:32:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09350 Fri, 19 Nov 1999 09:38:14 -0500 (EST) Date: Fri, 19 Nov 1999 08:31:48 -0600 From: Matthew Saroff Subject: Re: [Raven] FBI secret police In-reply-to: Christian Huitema <"Re: [Raven] FBI secret police"@[138.209.240.12]> To: raven@ietf.org Cc: ietf-ppp@merit.edu, ipsec@lists.tislabs.com Reply-to: msaroff@pobox.com Message-id: <9911190831.ZM17057@apollo.vs.lmco.com> MIME-version: 1.0 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <21565C751365D211BB2D0060089624CC1FBB16@TERRA> <199910140052.UAA06953@ietf.org> <380588A3.FE15BF86@greendragon.com> <4.1.19991119082100.009bcde0@mailee.research.telcordia.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Nov 19, 8:21am, Christian Huitema wrote: > Subject: Re: [Raven] FBI secret police > Bill, > > The IETF operate in public, under public scrutiny. There is no way we can > hide our debates from nayone, let alone the FBI. > -- Christian Huitema Hi, I believe that the issue about this that is concerning is that the FBI has in the past said to people involved in security and networking standards on the internet that supporting privacy and strond encryption are "anti-social". This is a not so veiled threat that supporting privacy will mean that the FBI will conduct surveillance, which seems to be accurate in Bill's case. -- Matthew Saroff Do not reply directly to this message. Reply to msaroff@pobox.com From owner-ipsec@lists.tislabs.com Fri Nov 19 11:29:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24139; Fri, 19 Nov 1999 11:29:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09976 Fri, 19 Nov 1999 11:41:38 -0500 (EST) Date: Fri, 19 Nov 1999 10:44:12 -0500 Message-Id: <199911191544.KAA00707@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: akrywaniuk@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> This is from Tero's draft, [EXT-METH]: "The second use [of Andrew> vendor ids] is to allow for vendor specific extensions, after Andrew> both ends have sent and received familiar vendor IDs. [...] Andrew> If familiar vendor ID payloads have been exchanged (both sent Andrew> and received) then implementations MAY do anything, including Andrew> using private extensions, private payloads, new identity Andrew> types, running nethack over the ISAKMP SA, etc." Andrew> This is from [ISAKMP]: Andrew> "The Vendor ID payload is not an announcement from the sender Andrew> that it will send private payload types. A vendor sending Andrew> the Vendor ID MUST not make any assumptions about private Andrew> payloads that it may send unless a Vendor ID is received as Andrew> well." Andrew> By my interpretation of the drafts, if both peers send a Andrew> vendor id which says "I do continuous channels" then it is Andrew> appropriate for them to modify their behaviour Andrew> accordingly. NO! Vendor ID is for enabling private extensions. It is NOT for enabling optional features in the standard. I don't think Tero is saying otherwise, though if the wording is being misinterpreted that way it should be clarified so it's obvious that it must not be interpreted that way. Now, if you're proposing that continuous channels should remain a private extension that's not standardized, that's different (but then of course this discussion doesn't belong on this list). paul From owner-ipsec@lists.tislabs.com Fri Nov 19 11:44:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25731; Fri, 19 Nov 1999 11:44:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10244 Fri, 19 Nov 1999 13:03:19 -0500 (EST) Date: Fri, 19 Nov 1999 19:01:34 +0100 (MET) From: Hans-Joachim Knobloch X-Sender: hajo@lagavulin.xlink.net. Reply-To: hans-joachim@knobloch.de To: ipsec@lists.tislabs.com Subject: Error recovery? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please excuse, if this is a FAQ or if I was simply too blind to find the answer in the RFCs and drafts on IPSec. Consider the case that two hosts communicate via two IPSec security gateways A <---> SG1 <-----> SG2 <---> B and that appropriate ISAKMP and IPSec SAs are established. Let us call these SAs SA1, SA2AB and SA2BA respectively. Now what happens, when SG2 is reset? When B sends a packet to A everything should be fine, since SG2 will initiate new phase 1 and phase 2 exchanges. But what if A sends a packet to B? SG1 will process the packet with the old IPsec SA2AB and SG2 will receive a packet with a most probably unknown SPI. Is this supposed to happen until SA2AB does "naturally expire"? Do we have to set SA lifetime short enough and/or hope that B will also send a packet more sooner than later? Alternatively one could imagine that SG2 sends SG1 some kind of (ICMP?) message to tell it to invalidate SA2AB. But then, this might be abused by an attacker to cause unnecessary ISAKMP traffic and a service disruption until new SAs are installed. In the above example, when SA2AB expires, SG1 will probably initiate a phase 2 exchange with the old SA1. What is the correct way for SG2 to respond to this? Initiate a nes phase 1 exchange? Send an error notification to SG2 (then necessarily unencrypted due to nonexistant ISAKMP SA)? The latter might open up a denial-of-service attack by sending spoofed error notifications to make SG1 invalidate its existing SAs and thus cause lots of unnecessary ISAKMP traffic and service disruption. Hansi From owner-ipsec@lists.tislabs.com Fri Nov 19 12:00:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26657; Fri, 19 Nov 1999 12:00:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10112 Fri, 19 Nov 1999 12:22:26 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Tero Kivinen cc: gab@sun.com, "Michael C. Richardson" , ipsec@lists.tislabs.com, "Ylian" Message-ID: <8625682E.00609091.00@mwgate02.mw.3com.com> Date: Fri, 19 Nov 1999 11:23:25 -0600 Subject: Re: IKE negotiation/rekeying problem with RSIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IMO, this should be clearly explained in the next IKE draft. And if there's a reason to go with one approach over the other, that should be documented as well. Preferably, the draft should recommend one. -Mike Tero Kivinen on 11/16/99 04:23:45 PM Sent by: Tero Kivinen To: gab@sun.com cc: "Michael C. Richardson" , ipsec@lists.tislabs.com, "Ylian" (Mike Borella/MW/US/3Com) Subject: Re: IKE negotiation/rekeying problem with RSIP Gabriel Montenegro writes: > the presentation i gave at the ipsec wg to ask for this (the DOI > document is very explicit about not allowing these port numbers > to vary, at least for purposes of including themin the hash): No, the DOI document is very clear that there is only two possible port numbers for ID payload, any (== zero), or 500. If you use port ANY (== zero), then you may also use any port you want. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Nov 19 12:28:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27353; Fri, 19 Nov 1999 12:28:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10424 Fri, 19 Nov 1999 13:50:25 -0500 (EST) Message-ID: <38359C77.87434F6@greendragon.com> Date: Fri, 19 Nov 1999 13:53:18 -0500 From: William Allen Simpson X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: raven@ietf.org CC: cryptography@c2.net, cypherpunks@cyberpass.net, CYBERIA-L@LISTSERV.AOL.COM, ietf-ppp@merit.edu, ipsec@lists.tislabs.com Subject: FBI secret police FAQ#1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This has gotten forwarded to many groups, and I have been overwhelmed by the response. Here are the answers to several of the most frequently asked questions, so that I don't have to answer so many private messages. 1) Why ask for the FBI records? 2) Why were the records kept secret? 3) How to ask for FOIA records? ==== At the Columbus IETF meeting in March 1993, a couple of PPP working group members told me that the FBI had come and questioned them for a "treason" investigation. My own parents had been contacted (the agent left a card). According to neighbors, my residence had been staked out for weeks. As a consultant, I travel a lot, so they were disappointed. Also, the IRS started a 7 (now 8) year investigation of my tax records, citing a criminal investigation. This is still ongoing today -- it takes years to work through the courts. I have "substantially prevailed" on every issue in these cases. Through the grapevine, John Gilmore (whom I had not yet met) told Phil Karn that I ought to request my records through the Freedom of Information and Privacy Acts. I requested the records from both the FBI and IRS. After several years of repeated requests, and a refusal to provide those records under Discovery during the court cases, the IRS gave me some of my records last June, and the FBI apparently was examining their records at about the same time (May). In both cases, they only filled part of the requests. ==== The folder title page says: Subject: William Allen Simpson File: Classified File Number The FBI cover sheets read as follows (special typed paragraph): "The enclosed documents responsive to your request are exempt from disclosure in their entirety pursuant to the Privacy Act, Title 5, United States Code, Section 552(a), subsection (j)(2). However, these records have been processed pursuant to the Freedom of Information Act, Title 5, United States Code, Section 552, thereby affording you the greatest degree of access authorized by both laws." subsection (j)(2) reads: "material reporting investigative efforts pertaining to the enforcement of criminal law including efforts to prevent, control, or reduce crime or apprehend criminals;" As explained by others: G-3: Assuming a .mil-like hierarchy, G3 would be Operations -- G1 is Personnel and Admin, G2 is Intel and Security, G4 is Logistics. OADR: Originating Agency's Determination Required, which means the FBI didn't generate that information, some other agency did, and they're the ones who get to make classification determinations regarding it. I understand these indications to mean that the various agencies are hiding behind one another, probably requested by the "security" part of an organization of the "operations" part, the very source of the file is secret -- and that they interpret the law to mean that this material is forever secret, by simply claiming that this is an enforcement of criminal law, even though no criminal acts were ever discovered. I've started to scan in the documents. You can view the first two pages that they've given me (clearly not the real first two pages, as these pages reference earlier dates), at the "Proceedings of the Institute for Obscure Studies": http://potifos.com/was/ (Hopefully, this will not get my freindly lawyer in too much trouble.) ==== The initial roadblocks in submitting a FOIPA request turned out to be (1) finding where to submit it, and (2) giving them lots of personal identification. They want it to be notarized, include a social security number, and be accompanied by a copy of a photographic identification, such as driver's licence. AFAIK, none of this is required by the statute, but both FBI and IRS kept returning my requests. I laboriously found the FBI offices that I used, in the local phone books, and from the rejection letters. Glen L. Roberts, editor of Full Disclosure, has a good list on-line. I wish I'd known about it when I started: http://www.glr.com/fbiform.txt The FOIPA statute requires that they answer within 20 days. In my case, each time a year or so had gone by, they sent me a letter asking whether I still wanted the information. Here's what my FBI request looked like. Replace with your information. Don't forget to get each copy notarized as you send them out.... Freedom of Information and Privacy Act Request Director, Attention FOIPA FBI Headquarters J Edgar Hoover Bldg 9th St & Pennsylvania Ave NW Washington DC 20535 Special Agent in Charge, FBI, Attention FOIPA P O Box 2118 Detroit MI 48231 Special Agent in Charge, FBI, Attention FOIPA 200 E Liberty Ann Arbor MI 48104 313-995-1310 Special Agent in Charge, FBI, Attention FOIPA P O Box 14195 Lansing MI 48901 517-487-1850 Special Agent in Charge, FBI, Attention FOIPA 2 Northfield Plaza Troy MI Pursuant to the provisions of the Freedom of Information and Privacy Acts, 5 USC 552, I am requesting copies of all information maintained by this agency in the past 38 years that pertain to myself as described below: Full Name: William Allen Simpson Also Known As: Bill Simpson Current Address: --- Social Security No.: --- Date and Place of Birth: --- Other pertinent locations: Ann Arbor, Michigan East Lansing, Michigan Lansing, Michigan Okemos, Michigan Waterford, Michigan Date:____________ Signature:_______________________________________________ Subscribed and sworn to before me, this ____ day of ________________________, of the year ____________. Signature of Notary: ________________________________________________________ My commission expires: ____________ From owner-ipsec@lists.tislabs.com Fri Nov 19 18:26:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07595; Fri, 19 Nov 1999 18:26:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11455 Fri, 19 Nov 1999 19:56:43 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA7F99@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Error recovery? Date: Fri, 19 Nov 1999 20:02:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hansi, I've done a fairly exhaustive analysis of this situation, and it seems apparent that the only way to really fix the problem is with some kind of keep-alive protocol. It doesn't really matter if it's a stateless asynchronous query protocol: E.g. "Are you still there?" "Yes." or a stateful synchronous uni-directional protocol: E.g. "I'm still here (seq no=1234)." The problem is that if the SA really has gone down then the peer can't communicate with you without performing some kind of time-consuming operation (e.g. negotiating a new SA, signing a packet with RSA, etc). This makes it very easy for an attacker to spoof a packet which will elicit a response from one of the peers, thus effecting a DoS attack. The only way to detect a lost SA without the DoS vulnerability is to rely on a timeout. As for the keep-alive alternatives, the query protocol will yield a faster recovery time, but the synchronous protocol is easier to write. Unfortunately, there is currently no standardized keep-alive protocol in IKE/IPSec. BTW, the other solution is to keep all state information in non-volatile storage so it sticks around after a reboot. That's not very practical for most of us, though. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Hans-Joachim Knobloch [mailto:hajo@knobloch.de] > Sent: Friday, November 19, 1999 1:02 PM > To: ipsec@lists.tislabs.com > Subject: Error recovery? > > > Please excuse, if this is a FAQ or if I was simply too blind > to find the > answer in the RFCs and drafts on IPSec. > > Consider the case that two hosts communicate via two IPSec security > gateways > A <---> SG1 <-----> SG2 <---> B > > and that appropriate ISAKMP and IPSec SAs are established. Let us call > these SAs SA1, SA2AB and SA2BA respectively. > Now what happens, when SG2 is reset? > > When B sends a packet to A everything should be fine, since SG2 will > initiate new phase 1 and phase 2 exchanges. > But what if A sends a packet to B? SG1 will process the > packet with the > old IPsec SA2AB and SG2 will receive a packet with a most > probably unknown > SPI. Is this supposed to happen until SA2AB does "naturally expire"? > Do we have to set SA lifetime short enough and/or hope that B > will also > send a packet more sooner than later? > > Alternatively one could imagine that SG2 sends SG1 some kind of > (ICMP?) message to tell it to invalidate SA2AB. But then, > this might be > abused by an attacker to cause unnecessary ISAKMP traffic and > a service > disruption until new SAs are installed. > > In the above example, when SA2AB expires, SG1 will probably initiate a > phase 2 exchange with the old SA1. What is the correct way for SG2 to > respond to this? Initiate a nes phase 1 exchange? Send an error > notification to SG2 (then necessarily unencrypted due to nonexistant > ISAKMP SA)? The latter might open up a denial-of-service > attack by sending > spoofed error notifications to make SG1 invalidate its > existing SAs and > thus cause lots of unnecessary ISAKMP traffic and service disruption. > > Hansi > > From owner-ipsec@lists.tislabs.com Fri Nov 19 21:12:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17752; Fri, 19 Nov 1999 21:12:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11674 Fri, 19 Nov 1999 22:31:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA7FB1@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: Lack of negotiation capability (was RE: Phase 1 Re-keying Implementation Identification) Date: Fri, 19 Nov 1999 22:36:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think we're hitting a roadblock in the development of IKE. It seems like we can't develop new features because there is no feature negotiation capability in IKE. How can we expect a feature to gain support if no one can implement it and use it because it is not standardized? Look at how the dangling phase 2 vs. continuous channel implementation got resolved. It wasn't that after an enlightened, intellectual chat, everyone agreed that dangling phase 2s were better. Basically what happened is that both groups released their products, they didn't work well together, and the dangling implementations prevailed because they were the lowest common denominator. Anyone who waits for all the drafts to become RFCs before implementing them is going to get killed in the marketplace. Currently, whenever we develop a new feature that has not been standardized, that feature has to be enabled by policy which is set manually on both sides (which is a bitch to manage). Hindering interoperability between vendors who show initiative is tantamount to discouraging innovation. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Fri Nov 19 22:53:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA19607; Fri, 19 Nov 1999 22:53:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11815 Sat, 20 Nov 1999 00:23:22 -0500 (EST) Message-ID: <007101bf3318$1f78b7e0$2805010a@tatra.trinc.com> From: "Muthukumar" To: Cc: Subject: Re : Error recovery ? Date: Fri, 19 Nov 1999 21:28:48 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01BF32D5.11018B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_006E_01BF32D5.11018B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >Hans-Joachim Knobloch wrote: > Consider the case that two hosts communicate via two IPSec security > gateways > A <---> SG1 <-----> SG2 <---> B > > and that appropriate ISAKMP and IPSec SAs are established. Let us call > these SAs SA1, SA2AB and SA2BA respectively. > Now what happens, when SG2 is reset? > > When B sends a packet to A everything should be fine, since SG2 will > initiate new phase 1 and phase 2 exchanges. > But what if A sends a packet to B? SG1 will process the packet with = the > old IPsec SA2AB and SG2 will receive a packet with a most probably = unknown > SPI. Is this supposed to happen until SA2AB does "naturally expire"? > Do we have to set SA lifetime short enough and/or hope that B will = also > send a packet more sooner than later? Currently, there is no standard way to do this and I guess it is left to the implementation. For phase1 SA: Assume SG1 has phase1 SA where as SG2 does not have corresponding phase1 SA. If phase2 is initiated by SG2, there is no problem,because it = negotiaties new phase1 SA with the SG1. If phase2 is initiated by SG1, then the SG1 never receives second quick mode message, since SG2 does not have phase1 SA. SG1 quick mode negotiation fails and then SG1 can take action based on implementation. In our implementation, we delete the phase1 SA if the initiator(SG1) does not receive second message for all = retries. ( Note that we have configuration option to do this or not ). For phase2 SA: This is tricky. Again here, assume SG1 has phase2 SA whereas SG2 does not have corresponding phase2 SA. If the packet comes on SG2 destined to SG1, there is no problem as SG2 negotiates new phase2 SA. If the packet comes on SG1 destined to SG2, SG1 applies security and sends it to the SG2 and SG2 drops the packet. There will be no packets transferred between these two SG for that session. Here, following can be done: Using IKE, you always get two SAs. One for oubound and other for inbound. Here, I feel we can use some sort of timeouts. That is whenever packet is sent, start software timer with some preconfigured value ( say 5 minutes ) Whenever packet is receieved on the corresponding inbound SA, then disable the timer on the outbound SA. If no packets are received within 5 minutes on inbound SA, then delete both SAs. Here, basic assumption is that the there will be always some packets coming inbound within 5 minutes after sending any outbound packet. This mechanism still works otherwise, but at the expense of one quick mode negotiation. > > Alternatively one could imagine that SG2 sends SG1 some kind of > (ICMP?) message to tell it to invalidate SA2AB. But then, this might = be > abused by an attacker to cause unnecessary ISAKMP traffic and a = service > disruption until new SAs are installed. > > In the above example, when SA2AB expires, SG1 will probably initiate a > phase 2 exchange with the old SA1. What is the correct way for SG2 to > respond to this? Initiate a nes phase 1 exchange? Send an error > notification to SG2 (then necessarily unencrypted due to nonexistant > ISAKMP SA)? The latter might open up a denial-of-service attack by = sending > spoofed error notifications to make SG1 invalidate its existing SAs = and > thus cause lots of unnecessary ISAKMP traffic and service disruption. See above. The above is a possible means of addressing the problem, = though not explicitly stated in any RFC. There are, obviously other alternative = solutions possible. Regards. - Kumar Product Manager Intoto Inc. 3160, de La Cruz Blvd; Ste #100 Santa Clara,=20 CA 95054 www.intotoinc.com ------=_NextPart_000_006E_01BF32D5.11018B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
>Hans-Joachim = Knobloch=20 wrote:

> Consider the case that two hosts communicate via two = IPSec=20 security
>=20 gateways
>         &nb= sp;   =20 A <---> SG1 <-----> SG2 <---> B
>
> and = that=20 appropriate ISAKMP and IPSec SAs are established. Let us call
> = these SAs=20 SA1, SA2AB and SA2BA respectively.
> Now what happens, when SG2 is = reset?
>
> When B sends a packet to A everything should be = fine,=20 since SG2 will
> initiate new phase 1 and phase 2 = exchanges.
> But=20 what if A sends a packet to B? SG1 will process the packet with = the
> old=20 IPsec SA2AB and SG2 will receive a packet with a most probably = unknown
>=20 SPI. Is this supposed to happen until SA2AB does "naturally=20 expire"?
> Do we have to set SA lifetime short enough and/or = hope=20 that B will also
> send a packet more sooner than=20 later?
 
  Currently, there is no standard = way to do=20 this and I guess it is left
  to the = implementation.

  For=20 phase1 SA:
    Assume SG1 has phase1 SA where as SG2 = does not=20 have corresponding
    phase1 = SA.
    If=20 phase2 is initiated by SG2, there is no problem,because it=20 negotiaties
    new phase1 SA with the=20 SG1.

    If phase2 is initiated by SG1, then the = SG1 never=20 receives second
    quick mode message, since SG2 does = not=20 have phase1 SA.
    SG1 quick mode negotiation fails = and then=20 SG1 can take action based
    on implementation. In = our=20 implementation, we delete the phase1 SA
    if the=20 initiator(SG1) does not receive second message for all=20 retries.
    ( Note that we have configuration option = to do=20 this or not ).

For phase2 SA:
    This is=20 tricky.
    Again here, assume SG1 has phase2 SA = whereas SG2=20 does not have
    corresponding phase2=20 SA.

    If the packet comes on SG2 destined to = SG1, there=20 is no problem as
    SG2 negotiates new phase2=20 SA.

    If the packet comes on SG1 destined to = SG2, SG1=20 applies security
    and sends it to the SG2 and SG2 = drops the=20 packet.  There will be
    no packets transferred = between=20 these two SG for that session.

    Here, following = can be=20 done:
    Using IKE, you always get two SAs. One for = oubound=20 and other for
    inbound.
    Here, = I feel=20 we can use some sort of timeouts.
    That is whenever = packet=20 is sent, start software timer with some
    = preconfigured=20 value ( say 5 minutes )
    Whenever packet is = receieved on=20 the corresponding inbound SA,
    then disable the = timer on=20 the outbound SA.
    If no packets are received within = 5=20 minutes on inbound SA, then
    delete both=20 SAs.
    Here, basic assumption is that the there will = be=20 always some packets
    coming inbound within 5 = minutes after=20 sending any outbound packet.
    This mechanism still = works=20 otherwise, but at the expense of one
    quick mode=20 negotiation.
>
> = Alternatively one=20 could imagine that SG2 sends SG1 some kind of
> (ICMP?) message to = tell it=20 to invalidate SA2AB. But then, this might be
> abused by an = attacker to=20 cause unnecessary ISAKMP traffic and a service
> disruption until = new SAs=20 are installed.
>
> In the = above=20 example, when SA2AB expires, SG1 will probably initiate a
> phase = 2=20 exchange with the old SA1. What is the correct way for SG2 to
> = respond to=20 this? Initiate a nes phase 1 exchange? Send an error
> = notification to SG2=20 (then necessarily unencrypted due to nonexistant
> ISAKMP SA)? The = latter=20 might open up a denial-of-service attack by sending
> spoofed = error=20 notifications to make SG1 invalidate its existing SAs and
> thus = cause=20 lots of unnecessary ISAKMP traffic and service=20 disruption.
 
See above. The above = is a=20 possible means of addressing the problem, though
not explicitly stated = in any RFC.=20 There are, obviously other alternative
solutions possible.
 
Regards.
- = Kumar
 
Product=20 Manager
Intoto = Inc.
3160, de La = Cruz Blvd;=20 Ste #100
Santa = Clara,
CA=20 95054
www.intotoinc.com
------=_NextPart_000_006E_01BF32D5.11018B80-- From owner-ipsec@lists.tislabs.com Sat Nov 20 07:05:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29065; Sat, 20 Nov 1999 07:05:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12499 Sat, 20 Nov 1999 08:19:42 -0500 (EST) Message-ID: <001801bf335a$3a7088b0$9106b0d0@corp.certifiedtime.com> From: "Todd Glassey @ GMTsw" To: "Andrew Krywaniuk" , References: <319A1C5F94C8D11192DE00805FBBADDFFA7F99@exchange> Subject: Re: Error recovery? Date: Sat, 20 Nov 1999 05:21:19 -0800 Organization: GMTsw MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gentlemen, Check out the ISIS transaction transport or the TibCO's Information Bus, these systems all have process control and restart built into them and it has worked over IP based connections for years. Restart and control parsing are key parts of distributed control functions and have been worked out by folks that had real-world events to control, like 1.5 ton autos rolling down a conveyor belt. The reality is that Policy and Service Management is exactly analogous to the Industrial Automation technologies pioneered in the 60's-80's and we should learn from the mistakes and successes these folks have had... Todd I suggest that the ----- Original Message ----- From: "Andrew Krywaniuk" To: Sent: Friday, November 19, 1999 05:02 PM Subject: RE: Error recovery? > Hansi, > > I've done a fairly exhaustive analysis of this situation, and it seems > apparent that the only way to really fix the problem is with some kind of > keep-alive protocol. > > It doesn't really matter if it's a stateless asynchronous query protocol: > > E.g. "Are you still there?" "Yes." > > or a stateful synchronous uni-directional protocol: > > E.g. "I'm still here (seq no=1234)." > > > The problem is that if the SA really has gone down then the peer can't > communicate with you without performing some kind of time-consuming > operation (e.g. negotiating a new SA, signing a packet with RSA, etc). This > makes it very easy for an attacker to spoof a packet which will elicit a > response from one of the peers, thus effecting a DoS attack. The only way to > detect a lost SA without the DoS vulnerability is to rely on a timeout. > > As for the keep-alive alternatives, the query protocol will yield a faster > recovery time, but the synchronous protocol is easier to write. > Unfortunately, there is currently no standardized keep-alive protocol in > IKE/IPSec. > > BTW, the other solution is to keep all state information in non-volatile > storage so it sticks around after a reboot. That's not very practical for > most of us, though. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: Hans-Joachim Knobloch [mailto:hajo@knobloch.de] > > Sent: Friday, November 19, 1999 1:02 PM > > To: ipsec@lists.tislabs.com > > Subject: Error recovery? > > > > > > Please excuse, if this is a FAQ or if I was simply too blind > > to find the > > answer in the RFCs and drafts on IPSec. > > > > Consider the case that two hosts communicate via two IPSec security > > gateways > > A <---> SG1 <-----> SG2 <---> B > > > > and that appropriate ISAKMP and IPSec SAs are established. Let us call > > these SAs SA1, SA2AB and SA2BA respectively. > > Now what happens, when SG2 is reset? > > > > When B sends a packet to A everything should be fine, since SG2 will > > initiate new phase 1 and phase 2 exchanges. > > But what if A sends a packet to B? SG1 will process the > > packet with the > > old IPsec SA2AB and SG2 will receive a packet with a most > > probably unknown > > SPI. Is this supposed to happen until SA2AB does "naturally expire"? > > Do we have to set SA lifetime short enough and/or hope that B > > will also > > send a packet more sooner than later? > > > > Alternatively one could imagine that SG2 sends SG1 some kind of > > (ICMP?) message to tell it to invalidate SA2AB. But then, > > this might be > > abused by an attacker to cause unnecessary ISAKMP traffic and > > a service > > disruption until new SAs are installed. > > > > In the above example, when SA2AB expires, SG1 will probably initiate a > > phase 2 exchange with the old SA1. What is the correct way for SG2 to > > respond to this? Initiate a nes phase 1 exchange? Send an error > > notification to SG2 (then necessarily unencrypted due to nonexistant > > ISAKMP SA)? The latter might open up a denial-of-service > > attack by sending > > spoofed error notifications to make SG1 invalidate its > > existing SAs and > > thus cause lots of unnecessary ISAKMP traffic and service disruption. > > > > Hansi > > > > From owner-ipsec@lists.tislabs.com Sat Nov 20 11:14:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01470; Sat, 20 Nov 1999 11:14:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12942 Sat, 20 Nov 1999 12:35:47 -0500 (EST) Message-ID: <3836DC77.746E4BAB@ix.netcom.com> Date: Sat, 20 Nov 1999 09:37:59 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Lack of negotiation capability (was RE: Phase 1 Re-keying Implementation Identification) References: <319A1C5F94C8D11192DE00805FBBADDFFA7FB1@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Andrew, Andrew Krywaniuk wrote: > > I think we're hitting a roadblock in the development of IKE. It seems like > we can't develop new features because there is no feature negotiation > capability in IKE. How can we expect a feature to gain support if no one can > implement it and use it because it is not standardized? > You are welcome to implement and test new functionality using a (private) vendor ID payload. If the functions are truly useful, you shouldn't have much trouble convincing people of this, at which time they can be added to IKE (sans vendor ID). The problem is, not many think the "feature" you're proposing is required, or even marginally useful. You can't expect capricious changes to a deployed security protocol whenever you have some pet "feature" you want implemented. You have to first convincingly demonstrate the requirement. You have not done that. > Look at how the dangling phase 2 vs. continuous channel implementation got > resolved. It wasn't that after an enlightened, intellectual chat, everyone > agreed that dangling phase 2s were better. Basically what happened is that > both groups released their products, they didn't work well together, and the > dangling implementations prevailed because they were the lowest common > denominator. This is just plain wrong, perhaps even misleading - another term springs to mind, but I'll hold my tongue. There was a significant discussion about this, and the majority of participants agreed that this is a non-issue. > Anyone who waits for all the drafts to become RFCs before implementing them > is going to get killed in the marketplace. Currently, whenever we develop a > new feature that has not been standardized, that feature has to be enabled > by policy which is set manually on both sides (which is a bitch to manage). > Hindering interoperability between vendors who show initiative is tantamount > to discouraging innovation. Welcome to the bleeding edge. I will point out again that you are welcome to use a vendor ID to test this function with anyone you wish, but vendor IDs are, by definition, private, so you have no basis for attempting to "standardize" on one. I find your post a bit astonishing. You've completely mischaracterized the history of this discussion, as well as its current status. I suggest you go back to the archives to see previous threads on the same topic. Scott From owner-ipsec@lists.tislabs.com Sat Nov 20 17:56:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05186; Sat, 20 Nov 1999 17:56:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13627 Sat, 20 Nov 1999 19:08:08 -0500 (EST) Message-Id: <199911210009.QAA14379@potassium.network-alchemy.com> To: gab@sun.com cc: ipsec@lists.tislabs.com, carrel@rback.net Subject: Re: suggested clarification regarding port handling in ike In-reply-to: Your message of "Sat, 20 Nov 1999 10:54:45 PST." <199911201845.KAA04956@ha1mpk-mail.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14376.943142967.1@network-alchemy.com> Date: Sat, 20 Nov 1999 16:09:27 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Gabriel, On Sat, 20 Nov 1999 10:54:45 PST you wrote > dan and dave, > > judging from exchanges on the mailing list, it seems like it is > worthwhile to document further details about common practices > regarding port handling in ike. > > since the ike document is currently being revised: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-01.txt > > may i suggest the following blurb (or something along its lines) > be added perhaps as a further clarification in section 2.3?: > > IKE implementations MUST support UDP port 500 for both source > and destination, but other port numbers are also allowed. > If an implementation allows other-than-port-500 for IKE, > it sets the value of the port numbers as reported in the > ID payload to 0 (meaning "any port"), instead of 500. UDP port numbers > (500 or not) are handled by the common "swap src/dst port and reply" > method. IKE uses ISAKMP as a transport and it seems to me that any verbage needed to clarify the use of that transport should go in a son-of-ISAKMP draft. In addition, the ID payloads are typically exchanged so late in the exchange that this information would not be useful. A Main Mode exchange will have 4 packets be exchanged before the Responder would obtain the Initiator's ID payload informing him that the Initiator allows for an other-than-port-500 port. Dan. From owner-ipsec@lists.tislabs.com Mon Nov 22 07:47:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18447; Mon, 22 Nov 1999 07:47:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18420 Mon, 22 Nov 1999 08:55:16 -0500 (EST) From: Gabriel.Montenegro@Eng.Sun.Com (Gabriel Montenegro) Message-Id: <199911201845.KAA04956@ha1mpk-mail.eng.sun.com> Date: Sat, 20 Nov 1999 10:54:45 -0800 To: , , Reply-To: Subject: suggested clarification regarding port handling in ike X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk dan and dave, judging from exchanges on the mailing list, it seems like it is worthwhile to document further details about common practices regarding port handling in ike. since the ike document is currently being revised: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-01.txt may i suggest the following blurb (or something along its lines) be added perhaps as a further clarification in section 2.3?: IKE implementations MUST support UDP port 500 for both source and destination, but other port numbers are also allowed. If an implementation allows other-than-port-500 for IKE, it sets the value of the port numbers as reported in the ID payload to 0 (meaning "any port"), instead of 500. UDP port numbers (500 or not) are handled by the common "swap src/dst port and reply" method. tnx, -gabriel From owner-ipsec@lists.tislabs.com Mon Nov 22 07:47:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18459; Mon, 22 Nov 1999 07:47:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18392 Mon, 22 Nov 1999 08:54:15 -0500 (EST) From: "John C. Kennedy" To: "Ben Laurie" Cc: , , , , , , , Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Date: Sun, 21 Nov 1999 13:43:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3837CD01.1910F28A@algroup.co.uk> Disposition-Notification-To: "John C. Kennedy" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I recall, I argued the same point and lost. I believe the prevailing argument was that including both j and q saved a parameter validator the cost of doing a division to derive the other value. If j=2, the most common case, the division is simply a right-shift, and the argument is moot. If you are using a q of 160 and j>>2, say in the case where DSA parameters are being overloaded for use as DH parameters, the p/q calculation is more expensive. If you are doing the calculation on a memory/CPU limited smart card the inclusion of p,q,j may be useful. The values q and j are made available for verification of domain parameters and for guiding selection of appropriately sized private keys. -John jkennedy@trustpoint.com -----Original Message----- From: Ben Laurie [mailto:ben@algroup.co.uk] Sent: Sunday, November 21, 1999 2:44 AM To: John C. Kennedy Cc: pgut001@cs.auckland.ac.nz; ietf-pkix@imc.org; ietf-smime@imc.org; ipsec@lists.tislabs.com; ekr@rtfm.com; robert.zuccherato@entrust.com; djohnson@certicom.com; wpolk@nist.gov; housley@spyrus.com; jis@mit.edu; mleech@nortelnetworks.com Subject: Re: FIPS 186 and X9.42: One of these things is not like the other "John C. Kennedy" wrote: > (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: > DomainParameters ::= SEQUENCE { > p INTEGER, -- odd prime, p=jq +1 > g INTEGER, -- generator, g > q INTEGER, -- factor of p-1 > j INTEGER OPTIONAL, -- subgroup factor > validationParms ValidationParms OPTIONAL } I was perusing the OpenSSL DH code recently, and I noticed that DH was using a Germain prime for p (miscommented as a strong prime, btw), which, of course, makes j=2. But q and j are not kept - what are they actually used for? (Answers in the form "read XXX" are welcome) BTW, why the redundancy? If you have any two of p, j and q, you don't need the other, and surely the work involved to recover the third one is minimal in comparison to anything else you'd need to do, sumswise? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi From owner-ipsec@lists.tislabs.com Mon Nov 22 07:49:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18480; Mon, 22 Nov 1999 07:49:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18433 Mon, 22 Nov 1999 08:55:18 -0500 (EST) Message-ID: <3837CD01.1910F28A@algroup.co.uk> Date: Sun, 21 Nov 1999 10:44:17 +0000 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: "John C. Kennedy" CC: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, djohnson@certicom.com, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: FIPS 186 and X9.42: One of these things is not like the other References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "John C. Kennedy" wrote: > (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: > DomainParameters ::= SEQUENCE { > p INTEGER, -- odd prime, p=jq +1 > g INTEGER, -- generator, g > q INTEGER, -- factor of p-1 > j INTEGER OPTIONAL, -- subgroup factor > validationParms ValidationParms OPTIONAL } I was perusing the OpenSSL DH code recently, and I noticed that DH was using a Germain prime for p (miscommented as a strong prime, btw), which, of course, makes j=2. But q and j are not kept - what are they actually used for? (Answers in the form "read XXX" are welcome) BTW, why the redundancy? If you have any two of p, j and q, you don't need the other, and surely the work involved to recover the third one is minimal in comparison to anything else you'd need to do, sumswise? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi From owner-ipsec@lists.tislabs.com Mon Nov 22 07:49:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18489; Mon, 22 Nov 1999 07:49:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18384 Mon, 22 Nov 1999 08:53:17 -0500 (EST) From: "John C. Kennedy" To: , , , Cc: , , , , , , Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Date: Sun, 21 Nov 1999 01:17:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <94314589412790@cs26.cs.auckland.ac.nz> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (A long but hopefully illuminating follow-up regarding ANSI X9.42) (**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the still unratified ANSI X9.42 draft should be used as a basis or even a reference for ongoing IETF Diffie-Hellman protocol standardization work.) Peter, I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April of 1997 when I changed employers and passed the X9.42 editing torch. Since my current work has given me a reason to wade back into the IETF process, I wanted to share a few comments and provide some additional data on the apparent state of Diffie-Hellman in IETF work. As I revisit things 2.5 years later it seems to still be a bit of a mess in need of some tidying up. (1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42. I believe this may be a draft that I "strategically distributed" to a few select people working in IPSEC, PKIX, and other IETF working groups around that time. ANSI X9F has never had a lot of interest in seeing X9.42 reviewed or adopted by IETF. [In fact, it is ridiculous that after almost five years of work and innumerable rewrites, neither ANSI or NIST have published an authoritative interoperability standard for one the most fundamental and powerful public key techniques for key agreement we have. (Hint: It is not because of patents or because it is too difficult to communicate.)] (2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft of X9.42. This X9.42 draft is probably the one made available by ANSI to IEEE P1363 members at http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will need an IEEE P1363 password to get at this.) This draft is better than the 1997 draft, but still has problems. Since I have not been involved with ANSI for about 3 years, I can't comment on where the X9.42 draft currently stands. Since the X9.42 draft document is (still!) not public, it is not clear whether it is relevant to the IETF's work anyway. RFC 2631 is currently a proposed standard in IETF. Since RFC 2631 propagates errors that existed in the 1998 X9.42 draft, a second look at it is probably called for. (These errors are noted below) (3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman standards. While the techniques given in this document are mathematically accurate and certainly filled a gap in the IPSEC work at the time, the OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX and some other security standards. (4) The following drafts contain relevant references to Diffie-Hellman or related protocols. The first two reference RFC 2631 and the second specifies a new DH variant altogether: draft-ietf-smime-small-subgroup-02.txt draft-ietf-pkix-dhpop-02.txt draft-ietf-secsh-transport-06.txt (5) Both of the ANSI documents currently referenced were drafts and probably weren't the best basis for IETF standards. Given the lack of anything else to point to, I can't say I blame the authors, however. They certainly meant well. What is also unfortunate is that IETF community has not been provided with access to more current X9.42 drafts. This is, IMHO, probably related to the situation I pointed out in (1). Now, in reponse to your observations: (6) RFC 2631 states "X9.42 requires that the private key x be in the interval [2, (q - 2)]" In other words, (1 < x < q-1). **It is quite clear that the referenced X9.42 draft is not only wrong but inconsistent**. And in a number of places. The Diffie-Hellman private key x should be chosen in the closed interval [2^(m-1), q-1], where m is the minimum length in bits acceptable for the private key. (Typically m>=160, but your mileage may vary...) This is consistent with security recommendations in the current IEEE P1363 documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt, draft-ietf-pkix-dhpop-02.txt. (If there is a mathematical subtlety I have forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to correct me.) Note that choosing x in [1, q-1] will work just fine mathematically, but does not reflect or enforce the minimum key size requirement. Note that if the size of q is at least a few bit greater than m and you are using a good RNG to pick x, the point is probably moot anyway. If you are using a long-term (aka "static") DH keys, however, it probably not a bad idea to put the minimum keysize check in your keygen routine as a "belt and suspenders" type measure. (7) The domain parameter generation routines in X9.42 were in fact derived from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and g) with X9.42 if desired. I can't say I am a big fan of this because it forces q to 160 bits which is probably not appropriate if you intend to enforce a minimum DH private key size greater than 160. (8) The parameter order switch was not a deliberate booby trap, although these types of things do help to keep crypto engineers on their toes. :) As I recall, the parameters q and j were added when concerns about small subgroup attacks on Diffie-Hellman surfaced. It is more of a coincidence that the DSA algorithm exploits the use of a subgroup also defined by a prime called q. In other words, DSA included q from the beginning while X9.42 added q as a security enhancement. The ASN.1 encoding choices are an artifact of the development process, not a deliberate reversal. If you feel like lobbying ANSI X9F to change the ordering to make everyone's life easier, have at it. I wouldn't hold my breath however. :) (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } whereas the 1998 X9.42 draft shows them as: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER, -- prime factor of p-1 j INTEGER, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (**Note q is no longer optional.** JK) if you can find a copy of the 1997 draft (which I happen to have) we see the original version: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER OPTIONAL, -- prime factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (This early draft reflects my admitted ignorance of proper ASN.1 at the time. You cannot have multiple optional INTEGERS without tags on them.) My guess is that the middle version (i.e., with only ValidationParms optional) is the preferred version, which means RFC 2459 should probably be changed. I do not know what the current X9.42 draft gives. ****Conclusion**** (10) Because of the aforementioned errors and inconsistencies, I have serious reservations about the continued use or referencing of ANSI X9.42 in IETF drafts or standards. The use or referencing of the ANSI X9.42 draft in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the apparently still unratified and possibly unstable ANSI X9.42 draft should be used as a basis or reference for ongoing IETF Diffie-Hellman protocol standardization efforts. Because of this, I respectfully submit that the IETF should consider whether RFC 2631 should be deprecated and rewritten in a manner which removes unnecessary references to the mysterious and forever-unpublished ANSI X9.42 draft. -John Kennedy jkennedy@trustpoint.com -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Sunday, November 21, 1999 1:58 PM To: ietf-pkix@imc.org; ietf-smime@imc.org Subject: FIPS 186 and X9.42: One of these things is not like the other FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key generation algorithm, and have domain parameters which look identical, however there are two subtle differences between them, one of which is really annoying. The annoying difference is that when writing the domain parameters, the order of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain parameters are written (p, q, g), exactly the same domain parameters when viewed as X9.42 values are written (p, g, q). This isn't helped by the fact that in many fonts lowercase q and g look very similar. Apart from the fact that it's a booby-trap for implementors, it also means that if the domain parameters are identified in the traditional way (SHA-1 hash), identical parameters will appear to be different depending on whether you're interpreting them as DSA/KEA or DH parameters. The second difference is in the allowed range for x: FIPS 186: 0 < x < q (ie x = 1...q-1) X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2) This looks like a transcription error from FIPS 186, given that using any x < ~2^160 is unsound I can't see why there'd be any difference between 1 and 2 as a lower bound. Perhaps new RFC's which cover this (eg son-of-RFC2459) could include warnings to the effect that although the parameters are the same internally, their external representations differ. Does anyone know why X9.42 decided to reverse the parameter order? (The motivation for this post is that ages ago I solved the problem of the reversed parameters by swapping the pointers for the X9.42 g and q values so they were read and written in the correct order, recently I was looking through the code and wondered why it was working fine for both interpretations of parameter ordering. There's now a big comment block by the code explaining the Bug which Isn't) Peter. From owner-ipsec@lists.tislabs.com Mon Nov 22 07:50:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18505; Mon, 22 Nov 1999 07:50:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18444 Mon, 22 Nov 1999 08:56:16 -0500 (EST) From: Gabriel.Montenegro@Eng.Sun.Com (Gabriel Montenegro) Message-Id: <199911211822.KAA11901@ha1mpk-mail.eng.sun.com> Date: Sun, 21 Nov 1999 10:31:09 -0800 To: "Dan Harkins" Cc: , , Reply-To: Subject: Re: suggested clarification regarding port handling in ike X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for your response Dan: >> IKE implementations MUST support UDP port 500 for both source >> and destination, but other port numbers are also allowed. >> If an implementation allows other-than-port-500 for IKE, >> it sets the value of the port numbers as reported in the >> ID payload to 0 (meaning "any port"), instead of 500. UDP port numbers >> (500 or not) are handled by the common "swap src/dst port and reply" >> method. > >IKE uses ISAKMP as a transport and it seems to me that any verbage >needed to clarify the use of that transport should go in a son-of-ISAKMP >draft. i hate to admit it, but i tend to agree with you here. the only reason i suggested putting in ike is that it is currently under revision, whereas isakmp is not. unless, of course, ted and the isakmp folks know something we don't. i don't think this clarification justifies opening up isakmp or doi again, so if it doesn't go in the new ike, it probably won't make it anywhere. ted? perhaps an addition to section 2.5.1 (transport protocol) in isakmp (rfc2408)? btw, there's also related text in the DOI. >In addition, the ID payloads are typically exchanged so late in >the exchange that this information would not be useful. A Main Mode >exchange will have 4 packets be exchanged before the Responder would >obtain the Initiator's ID payload informing him that the Initiator >allows for an other-than-port-500 port. there's some confusion here. this stuff actually works. this is how people test with the ssh test facility in finland (see tero's recent posting), for example, and the "other-than-port-500" combined with the "swap src/dst port and reply" actually works today (heck, it even works across network address and port translation--i know of someone who tests his ike implementation across such a box). perhaps you got confused because you expect the above blurb to cover the very important but orthogonal problem of *advertising* the value of the other-than-port-500. it doesn't. somehow, you've got to do that part. the above blurb just says that after you've set up an ike responder on some other-than-500 port, and made that known by whatever means, this is how things work. again, it's not meant to specify new behavior, but simply to document what appears to be the common practice. -gabriel From owner-ipsec@lists.tislabs.com Mon Nov 22 07:51:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18518; Mon, 22 Nov 1999 07:51:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18457 Mon, 22 Nov 1999 08:57:18 -0500 (EST) Date: Fri, 19 Nov 1999 17:18:13 -0600 From: Matthew Saroff Subject: Re: [Raven] FBI secret police FAQ#1 In-reply-to: William Allen Simpson <"[Raven] FBI secret police FAQ#1"@[138.209.240.12]> To: William Allen Simpson , raven@ietf.org Cc: cryptography@c2.net, cypherpunks@cyberpass.net, CYBERIA-L@LISTSERV.AOL.COM, ietf-ppp@merit.edu, ipsec@lists.tislabs.com Reply-to: msaroff@pobox.com Message-id: <9911191718.ZM17883@apollo.vs.lmco.com> MIME-version: 1.0 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <38359C77.87434F6@greendragon.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It looks to me like you might have been targeted because you were s supporter of strong crypto. If so, it might be a violation of your civil rights. Touch base with the ACLU, and find if there are similar cases out there. -- Matthew Saroff Do not reply directly to this message. Reply to msaroff@pobox.com From owner-ipsec@lists.tislabs.com Mon Nov 22 09:58:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21280; Mon, 22 Nov 1999 09:58:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18961 Mon, 22 Nov 1999 10:00:16 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Don Johnson" To: "John C. Kennedy" cc: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , "Simon Blake-Wilson" , "Phil Griffin" Message-ID: <85256831.0050D9FB.00@domino2.certicom.com> Date: Mon, 22 Nov 1999 09:36:04 -0500 Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John, A few comments on X9.42. 1. Elaine Barkey and Sharon Keller of NIST are the editors of ANSI X9.42. I am copying them on your note. It should be ready for final ballot. 2. The order of the parameters in the domain parameters should be made consistent with X9.30 DSA, I think. If this is not the way it is, it should be changed in X9.42. 3. The private key d should be a value from 1 to q-1 in X9.42. It is allowed to chop off the ends and make it 2 to q-2. Any further reduction risks reducing the keysize and therefore aiding the adversary. The reason that "low" values are allowed sometimes is that it is not known how to detect such a situation. In fact, if it were, then DH would unravel anyway. Don Johnson "John C. Kennedy" on 11/21/99 04:17:21 AM To: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com cc: ekr@rtfm.com, robert.zuccherato@entrust.com, Don Johnson/Certicom@Certicom, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com Subject: RE: FIPS 186 and X9.42: One of these things is not like the other (A long but hopefully illuminating follow-up regarding ANSI X9.42) (**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the still unratified ANSI X9.42 draft should be used as a basis or even a reference for ongoing IETF Diffie-Hellman protocol standardization work.) Peter, I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April of 1997 when I changed employers and passed the X9.42 editing torch. Since my current work has given me a reason to wade back into the IETF process, I wanted to share a few comments and provide some additional data on the apparent state of Diffie-Hellman in IETF work. As I revisit things 2.5 years later it seems to still be a bit of a mess in need of some tidying up. (1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42. I believe this may be a draft that I "strategically distributed" to a few select people working in IPSEC, PKIX, and other IETF working groups around that time. ANSI X9F has never had a lot of interest in seeing X9.42 reviewed or adopted by IETF. [In fact, it is ridiculous that after almost five years of work and innumerable rewrites, neither ANSI or NIST have published an authoritative interoperability standard for one the most fundamental and powerful public key techniques for key agreement we have. (Hint: It is not because of patents or because it is too difficult to communicate.)] (2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft of X9.42. This X9.42 draft is probably the one made available by ANSI to IEEE P1363 members at http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will need an IEEE P1363 password to get at this.) This draft is better than the 1997 draft, but still has problems. Since I have not been involved with ANSI for about 3 years, I can't comment on where the X9.42 draft currently stands. Since the X9.42 draft document is (still!) not public, it is not clear whether it is relevant to the IETF's work anyway. RFC 2631 is currently a proposed standard in IETF. Since RFC 2631 propagates errors that existed in the 1998 X9.42 draft, a second look at it is probably called for. (These errors are noted below) (3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman standards. While the techniques given in this document are mathematically accurate and certainly filled a gap in the IPSEC work at the time, the OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX and some other security standards. (4) The following drafts contain relevant references to Diffie-Hellman or related protocols. The first two reference RFC 2631 and the second specifies a new DH variant altogether: draft-ietf-smime-small-subgroup-02.txt draft-ietf-pkix-dhpop-02.txt draft-ietf-secsh-transport-06.txt (5) Both of the ANSI documents currently referenced were drafts and probably weren't the best basis for IETF standards. Given the lack of anything else to point to, I can't say I blame the authors, however. They certainly meant well. What is also unfortunate is that IETF community has not been provided with access to more current X9.42 drafts. This is, IMHO, probably related to the situation I pointed out in (1). Now, in reponse to your observations: (6) RFC 2631 states "X9.42 requires that the private key x be in the interval [2, (q - 2)]" In other words, (1 < x < q-1). **It is quite clear that the referenced X9.42 draft is not only wrong but inconsistent**. And in a number of places. The Diffie-Hellman private key x should be chosen in the closed interval [2^(m-1), q-1], where m is the minimum length in bits acceptable for the private key. (Typically m>=160, but your mileage may vary...) This is consistent with security recommendations in the current IEEE P1363 documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt, draft-ietf-pkix-dhpop-02.txt. (If there is a mathematical subtlety I have forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to correct me.) Note that choosing x in [1, q-1] will work just fine mathematically, but does not reflect or enforce the minimum key size requirement. Note that if the size of q is at least a few bit greater than m and you are using a good RNG to pick x, the point is probably moot anyway. If you are using a long-term (aka "static") DH keys, however, it probably not a bad idea to put the minimum keysize check in your keygen routine as a "belt and suspenders" type measure. (7) The domain parameter generation routines in X9.42 were in fact derived from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and g) with X9.42 if desired. I can't say I am a big fan of this because it forces q to 160 bits which is probably not appropriate if you intend to enforce a minimum DH private key size greater than 160. (8) The parameter order switch was not a deliberate booby trap, although these types of things do help to keep crypto engineers on their toes. :) As I recall, the parameters q and j were added when concerns about small subgroup attacks on Diffie-Hellman surfaced. It is more of a coincidence that the DSA algorithm exploits the use of a subgroup also defined by a prime called q. In other words, DSA included q from the beginning while X9.42 added q as a security enhancement. The ASN.1 encoding choices are an artifact of the development process, not a deliberate reversal. If you feel like lobbying ANSI X9F to change the ordering to make everyone's life easier, have at it. I wouldn't hold my breath however. :) (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } whereas the 1998 X9.42 draft shows them as: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER, -- prime factor of p-1 j INTEGER, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (**Note q is no longer optional.** JK) if you can find a copy of the 1997 draft (which I happen to have) we see the original version: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER OPTIONAL, -- prime factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (This early draft reflects my admitted ignorance of proper ASN.1 at the time. You cannot have multiple optional INTEGERS without tags on them.) My guess is that the middle version (i.e., with only ValidationParms optional) is the preferred version, which means RFC 2459 should probably be changed. I do not know what the current X9.42 draft gives. ****Conclusion**** (10) Because of the aforementioned errors and inconsistencies, I have serious reservations about the continued use or referencing of ANSI X9.42 in IETF drafts or standards. The use or referencing of the ANSI X9.42 draft in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the apparently still unratified and possibly unstable ANSI X9.42 draft should be used as a basis or reference for ongoing IETF Diffie-Hellman protocol standardization efforts. Because of this, I respectfully submit that the IETF should consider whether RFC 2631 should be deprecated and rewritten in a manner which removes unnecessary references to the mysterious and forever-unpublished ANSI X9.42 draft. -John Kennedy jkennedy@trustpoint.com -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Sunday, November 21, 1999 1:58 PM To: ietf-pkix@imc.org; ietf-smime@imc.org Subject: FIPS 186 and X9.42: One of these things is not like the other FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key generation algorithm, and have domain parameters which look identical, however there are two subtle differences between them, one of which is really annoying. The annoying difference is that when writing the domain parameters, the order of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain parameters are written (p, q, g), exactly the same domain parameters when viewed as X9.42 values are written (p, g, q). This isn't helped by the fact that in many fonts lowercase q and g look very similar. Apart from the fact that it's a booby-trap for implementors, it also means that if the domain parameters are identified in the traditional way (SHA-1 hash), identical parameters will appear to be different depending on whether you're interpreting them as DSA/KEA or DH parameters. The second difference is in the allowed range for x: FIPS 186: 0 < x < q (ie x = 1...q-1) X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2) This looks like a transcription error from FIPS 186, given that using any x < ~2^160 is unsound I can't see why there'd be any difference between 1 and 2 as a lower bound. Perhaps new RFC's which cover this (eg son-of-RFC2459) could include warnings to the effect that although the parameters are the same internally, their external representations differ. Does anyone know why X9.42 decided to reverse the parameter order? (The motivation for this post is that ages ago I solved the problem of the reversed parameters by swapping the pointers for the X9.42 g and q values so they were read and written in the correct order, recently I was looking through the code and wondered why it was working fine for both interpretations of parameter ordering. There's now a big comment block by the code explaining the Bug which Isn't) Peter. From owner-ipsec@lists.tislabs.com Mon Nov 22 11:20:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23418; Mon, 22 Nov 1999 11:20:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19852 Mon, 22 Nov 1999 11:32:16 -0500 (EST) Message-Id: <4.2.0.58.19991122105512.009c6e00@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 22 Nov 1999 11:00:16 -0500 To: "John C. Kennedy" From: Russ Housley Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Cc: , , , , , , , , , In-Reply-To: References: <94314589412790@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John: You have been out of the loop for over two years, and your observation are simply incorrect! The people that have been working on the PKIX and S/MIME standards that refer to X9.42 have been given every version of the document as it became available to the X9F1 working group participants. And, X9F1 has worked to ensure that they did not change the parts of X9.42 that were adopted by the IETF. Peter may not like the minor differences between X9.42 and DSA. But the IETF documents are aligned with the X9.42 (just as they claim). By the way, FIPS 186 contains no ASN.1; it only contains the algorithm specification. Russ At 01:17 AM 11/21/99 -0800, John C. Kennedy wrote: >(A long but hopefully illuminating follow-up regarding ANSI X9.42) > >(**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts >in IETF standards has resulted in the propagation of a number of errors and >inconsistencies within IETF drafts and RFCs. IMHO, it is questionable >whether the still unratified ANSI X9.42 draft should be used as a basis or >even a reference for ongoing IETF Diffie-Hellman protocol standardization >work.) > >Peter, > >I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April >of 1997 when I changed employers and passed the X9.42 editing torch. Since >my current work has given me a reason to wade back into the IETF process, I >wanted to share a few comments and provide some additional data on the >apparent state of Diffie-Hellman in IETF work. As I revisit things 2.5 >years later it seems to still be a bit of a mess in need of some tidying up. > >(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42. I >believe this may be a draft that I "strategically distributed" to a few >select people working in IPSEC, PKIX, and other IETF working groups around >that time. ANSI X9F has never had a lot of interest in seeing X9.42 >reviewed or adopted by IETF. [In fact, it is ridiculous that after almost >five years of work and innumerable rewrites, neither ANSI or NIST have >published an authoritative interoperability standard for one the most >fundamental and powerful public key techniques for key agreement we have. >(Hint: It is not because of patents or because it is too difficult to >communicate.)] > >(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft >of X9.42. This X9.42 draft is probably the one made available by ANSI to >IEEE P1363 members at >http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will >need an IEEE P1363 password to get at this.) This draft is better than the >1997 draft, but still has problems. Since I have not been involved with >ANSI for about 3 years, I can't comment on where the X9.42 draft currently >stands. Since the X9.42 draft document is (still!) not public, it is not >clear whether it is relevant to the IETF's work anyway. RFC 2631 is >currently a proposed standard in IETF. Since RFC 2631 propagates errors >that existed in the 1998 X9.42 draft, a second look at it is probably called >for. (These errors are noted below) > >(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman >standards. While the techniques given in this document are mathematically >accurate and certainly filled a gap in the IPSEC work at the time, the >OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX >and some other security standards. > >(4) The following drafts contain relevant references to Diffie-Hellman or >related protocols. The first two reference RFC 2631 and the second >specifies a new DH variant altogether: >draft-ietf-smime-small-subgroup-02.txt >draft-ietf-pkix-dhpop-02.txt >draft-ietf-secsh-transport-06.txt > >(5) Both of the ANSI documents currently referenced were drafts and probably >weren't the best basis for IETF standards. Given the lack of anything else >to point to, I can't say I blame the authors, however. They certainly meant >well. What is also unfortunate is that IETF community has not been provided >with access to more current X9.42 drafts. This is, IMHO, probably related >to the situation I pointed out in (1). > >Now, in reponse to your observations: > >(6) RFC 2631 states "X9.42 requires that the private key x be in the >interval [2, (q - 2)]" >In other words, (1 < x < q-1). **It is quite clear that the referenced >X9.42 draft is not only wrong but inconsistent**. And in a number of >places. The Diffie-Hellman private key x should be chosen in the closed >interval [2^(m-1), q-1], where m is the minimum length in bits acceptable >for the private key. (Typically m>=160, but your mileage may vary...) This >is consistent with security recommendations in the current IEEE P1363 >documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt, >draft-ietf-pkix-dhpop-02.txt. (If there is a mathematical subtlety I have >forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to >correct me.) > >Note that choosing x in [1, q-1] will work just fine mathematically, but >does not reflect or enforce the minimum key size requirement. Note that if >the size of q is at least a few bit greater than m and you are using a good >RNG to pick x, the point is probably moot anyway. If you are using a >long-term (aka "static") DH keys, however, it probably not a bad idea to put >the minimum keysize check in your keygen routine as a "belt and suspenders" >type measure. > >(7) The domain parameter generation routines in X9.42 were in fact derived >from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and >g) with X9.42 if desired. I can't say I am a big fan of this because it >forces q to 160 bits which is probably not appropriate if you intend to >enforce a minimum DH private key size greater than 160. > >(8) The parameter order switch was not a deliberate booby trap, although >these types of things do help to keep crypto engineers on their toes. :) As >I recall, the parameters q and j were added when concerns about small >subgroup attacks on Diffie-Hellman surfaced. It is more of a coincidence >that the DSA algorithm exploits the use of a subgroup also defined by a >prime called q. In other words, DSA included q from the beginning while >X9.42 added q as a security enhancement. The ASN.1 encoding choices are an >artifact of the development process, not a deliberate reversal. If you feel >like lobbying ANSI X9F to change the ordering to make everyone's life >easier, have at it. I wouldn't hold my breath however. :) > >(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: > DomainParameters ::= SEQUENCE { > p INTEGER, -- odd prime, p=jq +1 > g INTEGER, -- generator, g > q INTEGER, -- factor of p-1 > j INTEGER OPTIONAL, -- subgroup factor > validationParms ValidationParms OPTIONAL } > > ValidationParms ::= SEQUENCE { > seed BIT STRING, > pgenCounter INTEGER } > >whereas the 1998 X9.42 draft shows them as: > >DomainParameters ::= SEQUENCE { -- Galois field group parameters > p INTEGER, -- odd prime, p = jq + 1 > g INTEGER, -- generator, g > q INTEGER, -- prime factor of p-1 > j INTEGER, -- subgroup factor, j >= 2 > validationParms ValidationParms OPTIONAL >(**Note q is no longer optional.** JK) > >if you can find a copy of the 1997 draft (which I happen to have) we see the >original version: > >DomainParameters ::= SEQUENCE { -- Galois field group parameters > p INTEGER, -- odd prime, p = jq + 1 > g INTEGER, -- generator, g > q INTEGER OPTIONAL, -- prime factor of p-1 > j INTEGER OPTIONAL, -- subgroup factor, j >= 2 > validationParms ValidationParms OPTIONAL > >(This early draft reflects my admitted ignorance of proper ASN.1 at the >time. You cannot have multiple optional INTEGERS without tags on them.) > >My guess is that the middle version (i.e., with only ValidationParms >optional) is the preferred version, which means RFC 2459 should probably be >changed. I do not know what the current X9.42 draft gives. > >****Conclusion**** >(10) Because of the aforementioned errors and inconsistencies, I have >serious reservations about the continued use or referencing of ANSI X9.42 in >IETF drafts or standards. The use or referencing of the ANSI X9.42 draft in >IETF standards has resulted in the propagation of a number of errors and >inconsistencies within IETF drafts and RFCs. IMHO, it is questionable >whether the apparently still unratified and possibly unstable ANSI X9.42 >draft should be used as a basis or reference for ongoing IETF Diffie-Hellman >protocol standardization efforts. Because of this, I respectfully submit >that the IETF should consider whether RFC 2631 should be deprecated and >rewritten in a manner which removes unnecessary references to the mysterious >and forever-unpublished ANSI X9.42 draft. > > >-John Kennedy >jkennedy@trustpoint.com > > > >-----Original Message----- >From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] >Sent: Sunday, November 21, 1999 1:58 PM >To: ietf-pkix@imc.org; ietf-smime@imc.org >Subject: FIPS 186 and X9.42: One of these things is not like the other > > >FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key >generation algorithm, and have domain parameters which look identical, >however >there are two subtle differences between them, one of which is really >annoying. > >The annoying difference is that when writing the domain parameters, the >order >of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain >parameters are written (p, q, g), exactly the same domain parameters when >viewed as X9.42 values are written (p, g, q). This isn't helped by the fact >that in many fonts lowercase q and g look very similar. Apart from the fact >that it's a booby-trap for implementors, it also means that if the domain >parameters are identified in the traditional way (SHA-1 hash), identical >parameters will appear to be different depending on whether you're >interpreting >them as DSA/KEA or DH parameters. > >The second difference is in the allowed range for x: > > FIPS 186: 0 < x < q (ie x = 1...q-1) > X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2) > >This looks like a transcription error from FIPS 186, given that using any >x < ~2^160 is unsound I can't see why there'd be any difference between 1 >and 2 >as a lower bound. > >Perhaps new RFC's which cover this (eg son-of-RFC2459) could include >warnings >to the effect that although the parameters are the same internally, their >external representations differ. > >Does anyone know why X9.42 decided to reverse the parameter order? > >(The motivation for this post is that ages ago I solved the problem of the > reversed parameters by swapping the pointers for the X9.42 g and q values >so > they were read and written in the correct order, recently I was looking > through the code and wondered why it was working fine for both >interpretations > of parameter ordering. There's now a big comment block by the code >explaining > the Bug which Isn't) > >Peter. ------------- End Forwarded Message ------------- From owner-ipsec@lists.tislabs.com Mon Nov 22 13:02:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26258; Mon, 22 Nov 1999 13:02:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20198 Mon, 22 Nov 1999 13:00:45 -0500 (EST) Message-ID: <383985D3.FFDE9765@DataFellows.com> Date: Mon, 22 Nov 1999 20:05:07 +0200 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: Anonymous IKE phase 1 -mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Somehow I have a feeling this idea will be shot dead, but I think there's some good to be had by it, so I'll give it a try... Basically the problem is that traditional Internet communications have been based on "authentication by IP addresses". This has one good quality (only) that I can think of: it is available to absolutely everyone in the Internet. IKE requires more, which means that it's not available to absolutely everyone. This in turn means that you can't encrypt your communications with that sort of a peer either. This in turn helps things like ECHELON. If there existed an IKE phase 1 mode that would not do any more authentication than what is provided by IP addresses, all Internet communications could become encrypted at once. This would make large scale Internet surveillance like ECHELON harder, because passive surveillance would no longer work, and active methods would be necessary. Now, I've created an IKE authentication method that was inspired by CRACK and SSH, and which works as follows: Initiator Responder ----------- ----------- HDR, SAi, Ni ---> <--- HDR, SAr, Nr HDR, KEi, PKi, SIGi ---> <--- HDR, KEr, PKr, SIGr (The signatures sign every field sent by that entity previously in the protocol as well as the source and destination IP addresses. PKx = Public Key of entity x.) This protocol has these properties: - After these messages I and R know they have a secure channel to someone holding the private key corresponding to the received public key. This someone is capable of sending and receiving packets with the correct IP address. - Resistance to DoS attacks: The initiator has to perform a signature calculation before the responder responds with KEr or SIGr. - Identity protection is provided. Even more protection is possible by changing the IP address and the public key in every session. - There's no protection against man-in-the-middle. ps. If this idea is rejected by US persons, we can always raise conspiracy theories... ;-) -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Nov 22 13:34:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26659; Mon, 22 Nov 1999 13:34:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20353 Mon, 22 Nov 1999 13:39:40 -0500 (EST) X-Sender: rshirey@rosslyn.bbn.com Message-Id: In-Reply-To: <38359C77.87434F6@greendragon.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Nov 1999 13:36:27 -0500 To: William Allen Simpson From: "Robert W. Shirey" Subject: Re: FBI secret police FAQ#1 Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, There may be an IETF mailing list (or an ACM social issues list) that is appropriate for your messages on this subject, but IMHO it is not the IPsec mailing list. Regards, -Rob- Robert W. Shirey GTE Internetworking Security Practice Center Suite 1200, 1300 Seventeenth St. North, Arlington, VA 22209-3801 USA rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766 From owner-ipsec@lists.tislabs.com Mon Nov 22 15:43:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29636; Mon, 22 Nov 1999 15:43:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21243 Mon, 22 Nov 1999 17:07:27 -0500 (EST) Message-ID: <3839C006.30568FB1@ibm.net> Date: Mon, 22 Nov 1999 17:13:26 -0500 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec , ippcp Subject: IPComp rfc2393bis-00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a couple of questions with regards to negotiating IPCOMP with ISAKMP. IPComp draft rfc2393bis-00.txt explains that the CPI should be sent in the SPI field of the proposal payload when using ISAKMP to negotiated IPComp. This draft goes on to explain that 16 bit CPIs should be used, however 32 bit CPIs (SPIs) should be tolerated. Using the CPI, rather than a unique SPI for each associations leads to a couple of problems. First, it is not possible to send a single proposal which contains multiple IPComp transforms with different transform IDs. For example, the only way to negotiate IPComp with DEFLATE or LZS would be with 2 proposals since the SPI is part of the proposal payload. Additionally, and more importantly is that there is no way to uniquely identify an IPComp Association. It is entirely possible that 2 systems may have more than 1 IPComp Association (maybe part of an SA bundle with IPSec) using the same compression algo. In this case, there is no way to send a ISAKMP DELETE (which uses the SPI) to stop using one, but not the other. My questions are: 1) Why does this draft specify that the CPI MUST be sent as the SPI? I am assuming that there is some history here that I am not aware of? It seems redundant since the negotiated transform contains the compression algo which is also the CPI. 2) How are ISAKMP DELETEs handled for IPComp Associations? Are there implementations that are sending them? Any information that can be provided would be greatly appreciated. Thanks, Mike Williams From owner-ipsec@lists.tislabs.com Mon Nov 22 17:04:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00807; Mon, 22 Nov 1999 17:04:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21618 Mon, 22 Nov 1999 18:31:20 -0500 (EST) Date: Mon, 22 Nov 1999 18:32:20 -0500 Message-Id: <199911222332.SAA00861@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: pkoning@xedia.com CC: akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com In-reply-to: <199911191544.KAA00707@tonga.xedia.com> (message from Paul Koning on Fri, 19 Nov 1999 10:44:12 -0500) Subject: Re: Phase 1 Re-keying Implementation Identification From: tytso@mit.edu Phone: (781) 391-3464 References: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> <199911191544.KAA00707@tonga.xedia.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Fri, 19 Nov 1999 10:44:12 -0500 From: Paul Koning Vendor ID is for enabling private extensions. It is NOT for enabling optional features in the standard. I don't think Tero is saying otherwise, though if the wording is being misinterpreted that way it should be clarified so it's obvious that it must not be interpreted that way. What a number of folks have complained about is that the IKE framework doesn't have a particularly good way of turning on optional features, since as we add new orthoganol features, it causes a combinatoric explosion in number of IKE proposals that need to offered. Some people have pointed out that the Vendor ID can be (ab)used to allow for a more streamlined way of negotiating optional parts of the specification, especially as we move forward and want to add new (optional) extensions to IKE. Granted it it violates the original intention of the Vendor ID payload. Granted it is an ugly kludge. But the folks who are advocating it are saying that it might be cleaner and more pragmatic than some of the alternatives. I think it's fair to consider this point, and not reject it out of hand --- although I do have a lot of sympathy for the purist point of view that this is an ugly hack. - Ted From owner-ipsec@lists.tislabs.com Mon Nov 22 17:10:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00874; Mon, 22 Nov 1999 17:10:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21663 Mon, 22 Nov 1999 18:48:11 -0500 (EST) Date: Mon, 22 Nov 1999 18:49:24 -0500 Message-Id: <199911222349.SAA00872@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: gab@sun.com CC: dharkins@network-alchemy.com, carrel@rback.net, ipsec@lists.tislabs.com In-reply-to: <199911211822.KAA11901@ha1mpk-mail.eng.sun.com> (Gabriel.Montenegro@eng.sun.com) Subject: Re: suggested clarification regarding port handling in ike From: tytso@mit.edu Phone: (781) 391-3464 References: <199911211822.KAA11901@ha1mpk-mail.eng.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Gabriel.Montenegro@eng.sun.com (Gabriel Montenegro) Date: Sun, 21 Nov 1999 10:31:09 -0800 >IKE uses ISAKMP as a transport and it seems to me that any verbage >needed to clarify the use of that transport should go in a son-of-ISAKMP >draft. i hate to admit it, but i tend to agree with you here. the only reason i suggested putting in ike is that it is currently under revision, whereas isakmp is not. unless, of course, ted and the isakmp folks know something we don't. i don't think this clarification justifies opening up isakmp or doi again, so if it doesn't go in the new ike, it probably won't make it anywhere. ted? perhaps an addition to section 2.5.1 (transport protocol) in isakmp (rfc2408)? btw, there's also related text in the DOI. Umm... I don't think this Isakmp issue at all. The definition of the ID Payload is in the DOI documentation. At the ISAKMP level, the fact that you put IP addresses and Port numbers in an ID payload doesn't come up at all. All ISAKMP has to say about the matter is as follows: > ISAKMP can be implemented over any transport protocol or over IP > itself. Implementations MUST include send and receive capability for > ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port > 500 has been assigned to ISAKMP by the Internet Assigned Numbers > Authority (IANA). Implementations MAY additionally support ISAKMP > over other transport protocols or over IP itself. What goes into the ID Payload if you use UDP port 500 versus some other UDP port, versus TCP/IP, etc. isn't something for the ISAKMP document to define; I'm not sure how you would even add that to the ISAKMP document without dragging in all sorts of IKE specific issues into it. Perhaps some folks are seeing something I'm not seeing, but I don't see why it shouldn't be an IKE/DOI issue. That being said, if there are enough reasons why we think we want to reopen IKE (such as a clarification about how to do IKE extensions, etc.), we can do so. - Ted From owner-ipsec@lists.tislabs.com Mon Nov 22 17:20:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00959; Mon, 22 Nov 1999 17:20:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21727 Mon, 22 Nov 1999 18:57:55 -0500 (EST) Date: Tue, 23 Nov 1999 02:01:03 +0200 (EET) Message-Id: <199911230001.CAA31183@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@lists.tislabs.com CC: dharkins@network-alchemy.com, carrel@rback.net Subject: Some questions about the draft-ieft-ipsec-ike-00.txt X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 6.4.2 Acknowledged Informational > ... > The acknowledged Informational exchange is defined as: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), Ni, N/D --> > <-- HDR*, HASH(2), Nr, N/D I assume this is defined so that even if the responder does not understand the contents of the payloads, it MUST send the reply back? I.e If I send the other end notification payload having unknown notification number, the other end MUST send the second packet back, and it MUST NOT send any kind of error (no error notifications for notifications). Is this interpretation correct? If so, I would like to see something like this describing that in the document: ---------------------------------------------------------------------- The responder MUST always send back the reply packet defined above, even if there is an error while processing the packet sent by the initiator. This means that the initiator will always get the reply back from the responder, and that reply simply means that the responder received the packet. The reply does not mean that the responder understood and/or acted based on the packet it received. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Nov 22 17:44:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01438; Mon, 22 Nov 1999 17:44:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21819 Mon, 22 Nov 1999 19:21:25 -0500 (EST) Date: Tue, 23 Nov 1999 02:24:31 +0200 (EET) Message-Id: <199911230024.CAA25198@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: tytso@mit.edu Cc: pkoning@xedia.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-Reply-To: <199911222332.SAA00861@trampoline.thunk.org> References: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> <199911191544.KAA00707@tonga.xedia.com> <199911222332.SAA00861@trampoline.thunk.org> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk tytso@mit.edu writes: > What a number of folks have complained about is that the IKE framework > doesn't have a particularly good way of turning on optional features, > since as we add new orthoganol features, it causes a combinatoric > explosion in number of IKE proposals that need to offered. Some people > have pointed out that the Vendor ID can be (ab)used to allow for a more > streamlined way of negotiating optional parts of the specification, > especially as we move forward and want to add new (optional) extensions > to IKE. Note, that the vendor ID payloads are not authenticated, so even if somebody adds keepalive vendor IDs to their packets that doesn't mean that those vendor IDs reach the other end... > Granted it it violates the original intention of the Vendor ID payload. > Granted it is an ugly kludge. But the folks who are advocating it are > saying that it might be cleaner and more pragmatic than some of the > alternatives. I think it's fair to consider this point, and not reject > it out of hand --- although I do have a lot of sympathy for the purist > point of view that this is an ugly hack. I think we should start thinking better way to do the same thing. There isn't any currently defined vendor-id payloads used now, so everybody who wants to support something new, must modify their code anyways. So we might define new way to agree on used features, which doesn't break old implementations, but which is authenticated, and which doesn't violate the ISAKMP RFC. One such way could be to define another Protocol ID to be used in the feature negotiation. So the IKE SA proposal could be something like this: Proposal 1: Protocol: PROTO_ISAKMP Transform 1 KEY_IKE Encryption: Blowfish HASH: SHA Authentication method: RSA signatures Group: 5 Proposal 2: Protocol: PROTO_ISAKMP Transform 1 KEY_IKE Encryption: Blowfish HASH: SHA Authentication method: RSA signatures Group: 5 Protocol: PROTO_ISAKMP_FEATURE_NEGOTIATION Transform 1 FEATURE_NEGOTIATION Keepalives: enabled Nethack over IKE: disabled Transform 2 FEATURE_NEGOTIATION Keepalives: disabled Nethack over IKE: enabled Transform 3 FEATURE_NEGOTIATION Which would allow old implementations to select the proposal 1 having only one protocol (for this to work they must be able to process ike SAs having multiple proposals, which is currently forbidden in the IKE rfc) New implemenations could select IKE parameters from the PROTO_ISAKMP transform list, and then they can select one feature list transform from the PROTO_ISAKMP_FEATURE_NEGOTIATION list. The good thing about the SA payloads are that they are authenticated, so attacker cannot remove the features, as they can when you are using the vendor id payloads. This is just one example how this can be done, am not (yet) really proposing this. This just for you to start thinking about this issue also... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Nov 22 18:33:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04000; Mon, 22 Nov 1999 18:33:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21970 Mon, 22 Nov 1999 19:59:53 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA82EC@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Phase 1 Re-keying Implementation Identification Date: Mon, 22 Nov 1999 20:05:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, > Note, that the vendor ID payloads are not authenticated, so even if > somebody adds keepalive vendor IDs to their packets that doesn't mean > that those vendor IDs reach the other end... We've had this discussion before (offline). I think there are really only 3 realistic solutions: 1) Don't add unsigned payloads to phase 1. Send them later (e.g. using Isakmp-Config). 2) Add them to phase 1 unauthenticated. Later, send a hash of the extra payloads (e.g. using acknowledged notify). 3) Modify the phase 1 modes to retroactively sign earlier packets (like crack does). and, of course: 4) Don't do anything. This stuff's just for show, right? :-P > I think we should start thinking better way to do the same thing. > There isn't any currently defined vendor-id payloads used now, so > everybody who wants to support something new, must modify their code > anyways. Granted, vendor ids weren't necessarily intended to be used as feature ids, but they seem to act in an appropriate manner. As Paul described it to me (offline), we need to provide "feature advertisement capability", instead of "negotiation capability". Sort of like: Initiator: "I do feature X". Responder: "So do I. Let's do it". > One such way could be to define another Protocol ID to be used in the > feature negotiation. So the IKE SA proposal could be something like > this: > > Proposal 1: > Protocol: PROTO_ISAKMP > Transform 1 KEY_IKE > Encryption: Blowfish > HASH: SHA > Authentication method: RSA signatures > Group: 5 > Proposal 2: > Protocol: PROTO_ISAKMP > Transform 1 KEY_IKE > Encryption: Blowfish > HASH: SHA > Authentication method: RSA signatures > Group: 5 > Protocol: PROTO_ISAKMP_FEATURE_NEGOTIATION > Transform 1 FEATURE_NEGOTIATION > Keepalives: enabled > Nethack over IKE: disabled > Transform 2 FEATURE_NEGOTIATION > Keepalives: disabled > Nethack over IKE: enabled > Transform 3 FEATURE_NEGOTIATION > You're right that that's a secure way to do it. I wouldn't say that it's less kludgy than any other method, though. You kind of break the proposal model (flat list vs. pick & choose), which is important if we want to avoid gigantic packets but still kind of confusing. Also, the feature sets can be grouped, which isn't possible (easily) using vendor ids, although it isn't necessarily desirable either. I would rather see something like: Protocol: PROTO_ISAKMP Transform 1 ISAKMP_CONFIG and then use config mode later to negotiate the features using a REQUEST/REPLY exchange. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Nov 23 02:01:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25049; Tue, 23 Nov 1999 02:01:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA23354 Tue, 23 Nov 1999 02:50:45 -0500 (EST) Message-ID: <383A486F.DF9F0336@checkpoint.com> Date: Tue, 23 Nov 1999 09:55:27 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen CC: ipsec-list Subject: Re: Anonymous IKE phase 1 -mode References: <383985D3.FFDE9765@DataFellows.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ari, See my comments below: Ari Huttunen wrote: > Somehow I have a feeling this idea will be shot dead, but > I think there's some good to be had by it, so I'll give > it a try... > > Basically the problem is that traditional Internet communications > have been based on "authentication by IP addresses". This has > one good quality (only) that I can think of: it is available to > absolutely everyone in the Internet. IKE requires more, which > means that it's not available to absolutely everyone. This in turn > means that you can't encrypt your communications with that sort > of a peer either. This in turn helps things like ECHELON. > > If there existed an IKE phase 1 mode that would not do any more > authentication than what is provided by IP addresses, all Internet > communications could become encrypted at once. This would make > large scale Internet surveillance like ECHELON harder, because > passive surveillance would no longer work, and active methods > would be necessary. > > Now, I've created an IKE authentication method that was inspired > by CRACK and SSH, and which works as follows: > > Initiator Responder > ----------- ----------- > HDR, SAi, Ni > ---> > <--- HDR, SAr, Nr > HDR, KEi, PKi, SIGi > ---> > <--- HDR, KEr, PKr, SIGr > > (The signatures sign every field sent by that entity > previously in the protocol as well as the source and > destination IP addresses. PKx = Public Key of entity x.) > Signing IP addresses is NAT unfriendly. If SIGi does not include Nr then Responder is opened to the following DoS attack: A and B perform this exchange. C records the packets from A. C then later replays these packets. > > This protocol has these properties: > - After these messages I and R know they have a secure > channel to someone holding the private key corresponding > to the received public key. This someone is capable of sending > and receiving packets with the correct IP address. > - Resistance to DoS attacks: The initiator has to perform a signature > calculation before the responder responds with KEr or SIGr. Of course, the responder still needs to do signature verification. Assuming you are using RSA, since the exponent is usually 3 or 65537 this is not a problem. However, a DoS attacker can simply select a different (larger) exponent. So in order to protect herself from a DoS the responder needs to limit the size of the initiator public key exponent. > > - Identity protection is provided. Even more protection > is possible by changing the IP address and the public key > in every session. > - There's no protection against man-in-the-middle. > Yep. > > ps. If this idea is rejected by US persons, we can always raise > conspiracy theories... ;-) > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > Data Fellows Corporation http://www.DataFellows.com > > F-Secure products: Integrated Solutions for Enterprise Security Tamir. From owner-ipsec@lists.tislabs.com Tue Nov 23 02:21:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25785; Tue, 23 Nov 1999 02:21:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23671 Tue, 23 Nov 1999 03:36:38 -0500 (EST) Message-Id: <199911230839.LAA15708@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: tytso@mit.edu, Tero Kivinen Date: Tue, 23 Nov 1999 11:39:23 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Phase 1 Re-keying Implementation Identification CC: pkoning@xedia.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com In-reply-to: <199911230024.CAA25198@torni.ssh.fi> References: <199911222332.SAA00861@trampoline.thunk.org> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 23 Nov 99, at 2:24, Tero Kivinen wrote: Hi Tero, [...] > One such way could be to define another Protocol ID to be used in the > feature negotiation. So the IKE SA proposal could be something like > this: > > Proposal 1: > Protocol: PROTO_ISAKMP > Transform 1 KEY_IKE > Encryption: Blowfish > HASH: SHA > Authentication method: RSA signatures > Group: 5 > Proposal 2: > Protocol: PROTO_ISAKMP > Transform 1 KEY_IKE > Encryption: Blowfish > HASH: SHA > Authentication method: RSA signatures > Group: 5 > Protocol: PROTO_ISAKMP_FEATURE_NEGOTIATION > Transform 1 FEATURE_NEGOTIATION > Keepalives: enabled > Nethack over IKE: disabled > Transform 2 FEATURE_NEGOTIATION > Keepalives: disabled > Nethack over IKE: enabled > Transform 3 FEATURE_NEGOTIATION > > > Which would allow old implementations to select the proposal 1 having > only one protocol (for this to work they must be able to process > ike SAs having multiple proposals, which is currently forbidden in the > IKE rfc) > > New implemenations could select IKE parameters from the PROTO_ISAKMP > transform list, and then they can select one feature list transform > from the PROTO_ISAKMP_FEATURE_NEGOTIATION list. > > The good thing about the SA payloads are that they are authenticated, > so attacker cannot remove the features, as they can when you are using > the vendor id payloads. But attacker can always change responder's selection, because SAr is not explicitly authenticated in IKE. > This is just one example how this can be done, am not (yet) really > proposing this. This just for you to start thinking about this issue > also... > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > Best regards, Valera. From owner-ipsec@lists.tislabs.com Tue Nov 23 03:26:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29304; Tue, 23 Nov 1999 03:26:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA23880 Tue, 23 Nov 1999 04:29:56 -0500 (EST) Message-ID: <3C3175FCC945D211B65100805F1580890A487448@RED-MSG-07> From: William Dixon To: "'Tamir Zegman'" , Ari Huttunen Cc: ipsec-list Subject: RE: Anonymous IKE phase 1 -mode Date: Tue, 23 Nov 1999 01:32:10 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It would be very useful to authenticate the server only, keeping the client user or machine ID anonymous, ala normal HTTPS usage of SSL (without client auth). Does anyone remember why this wasn't provided in IKE ? I read through the Jan 99 SSL vs. IPSec and Vital's portable client credential comments way back, but haven't seen the reasons why IKE didn't provide a mode for this. -Wm -----Original Message----- From: Tamir Zegman [mailto:zegman@checkpoint.com] Sent: Monday, November 22, 1999 11:55 PM To: Ari Huttunen Cc: ipsec-list Subject: Re: Anonymous IKE phase 1 -mode Hi Ari, See my comments below: Ari Huttunen wrote: > Somehow I have a feeling this idea will be shot dead, but > I think there's some good to be had by it, so I'll give > it a try... > > Basically the problem is that traditional Internet communications > have been based on "authentication by IP addresses". This has > one good quality (only) that I can think of: it is available to > absolutely everyone in the Internet. IKE requires more, which > means that it's not available to absolutely everyone. This in turn > means that you can't encrypt your communications with that sort > of a peer either. This in turn helps things like ECHELON. > > If there existed an IKE phase 1 mode that would not do any more > authentication than what is provided by IP addresses, all Internet > communications could become encrypted at once. This would make > large scale Internet surveillance like ECHELON harder, because > passive surveillance would no longer work, and active methods > would be necessary. > > Now, I've created an IKE authentication method that was inspired > by CRACK and SSH, and which works as follows: > > Initiator Responder > ----------- ----------- > HDR, SAi, Ni > ---> > <--- HDR, SAr, Nr > HDR, KEi, PKi, SIGi > ---> > <--- HDR, KEr, PKr, SIGr > > (The signatures sign every field sent by that entity > previously in the protocol as well as the source and > destination IP addresses. PKx = Public Key of entity x.) > Signing IP addresses is NAT unfriendly. If SIGi does not include Nr then Responder is opened to the following DoS attack: A and B perform this exchange. C records the packets from A. C then later replays these packets. > > This protocol has these properties: > - After these messages I and R know they have a secure > channel to someone holding the private key corresponding > to the received public key. This someone is capable of sending > and receiving packets with the correct IP address. > - Resistance to DoS attacks: The initiator has to perform a signature > calculation before the responder responds with KEr or SIGr. Of course, the responder still needs to do signature verification. Assuming you are using RSA, since the exponent is usually 3 or 65537 this is not a problem. However, a DoS attacker can simply select a different (larger) exponent. So in order to protect herself from a DoS the responder needs to limit the size of the initiator public key exponent. > > - Identity protection is provided. Even more protection > is possible by changing the IP address and the public key > in every session. > - There's no protection against man-in-the-middle. > Yep. > > ps. If this idea is rejected by US persons, we can always raise > conspiracy theories... ;-) > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > Data Fellows Corporation http://www.DataFellows.com > > F-Secure products: Integrated Solutions for Enterprise Security Tamir. From owner-ipsec@lists.tislabs.com Tue Nov 23 03:36:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29463; Tue, 23 Nov 1999 03:36:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA23934 Tue, 23 Nov 1999 04:55:55 -0500 (EST) Message-ID: <383A65AF.545C849B@checkpoint.com> Date: Tue, 23 Nov 1999 12:00:15 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: William Dixon CC: ipsec-list Subject: Re: Anonymous IKE phase 1 -mode References: <3C3175FCC945D211B65100805F1580890A487448@RED-MSG-07> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hybrid does exactly that (with the exception that it mandates that XAuth would immediately follow). William Dixon wrote: > It would be very useful to authenticate the server only, keeping the client > user or machine ID anonymous, ala normal HTTPS usage of SSL (without client > auth). Does anyone remember why this wasn't provided in IKE ? I read > through the Jan 99 SSL vs. IPSec and Vital's portable client credential > comments way back, but haven't seen the reasons why IKE didn't provide a > mode for this. -Wm > From owner-ipsec@lists.tislabs.com Tue Nov 23 07:24:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03829; Tue, 23 Nov 1999 07:24:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24862 Tue, 23 Nov 1999 08:36:22 -0500 (EST) Message-ID: <87FB8F5CE210D311B60500A0C9F4871C0188D158@xcup01.cup.hp.com> From: "POLULYAKH,YEVGENIY (HP-Cupertino,ex1)" To: "'hans-joachim@knobloch.de'" Cc: ipsec@lists.tislabs.com Subject: RE: Error recovery? Date: Mon, 22 Nov 1999 21:03:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hansi, One may consider the following solution: 1. Gateway SG2 maintains a file containing remote IP addresses for all inbound Phase 2 SA's. 2. After the reboot, SG2 reads the file, and: 2.1 Establishes new Phase 1 SA's with the IP addresses saved in the file. 2.2 Sends Acknowledged Informational Exchange Notify messages (protected by the established Phase 1 SA's) with Message Type set to INITIAL-CONTACT (RFC 2407, Page 22) to the same addresses. 3. Upon receipt of the notify message, the recipient SHOULD clear all the local Phase 2 SA's it has with the sender. The old Phase 1 SA's SHOULD also be cleared. Best regards, Yevgeniy Yevgeniy Polulyakh Hewlett-Packard Company Cupertino, CA +1(408)447-1224 -----Original Message----- From: Hans-Joachim Knobloch [mailto:hajo@knobloch.de] Sent: Friday, November 19, 1999 10:02 AM To: ipsec@lists.tislabs.com Subject: Error recovery? Please excuse, if this is a FAQ or if I was simply too blind to find the answer in the RFCs and drafts on IPSec. Consider the case that two hosts communicate via two IPSec security gateways A <---> SG1 <-----> SG2 <---> B and that appropriate ISAKMP and IPSec SAs are established. Let us call these SAs SA1, SA2AB and SA2BA respectively. Now what happens, when SG2 is reset? When B sends a packet to A everything should be fine, since SG2 will initiate new phase 1 and phase 2 exchanges. But what if A sends a packet to B? SG1 will process the packet with the old IPsec SA2AB and SG2 will receive a packet with a most probably unknown SPI. Is this supposed to happen until SA2AB does "naturally expire"? Do we have to set SA lifetime short enough and/or hope that B will also send a packet more sooner than later? Alternatively one could imagine that SG2 sends SG1 some kind of (ICMP?) message to tell it to invalidate SA2AB. But then, this might be abused by an attacker to cause unnecessary ISAKMP traffic and a service disruption until new SAs are installed. In the above example, when SA2AB expires, SG1 will probably initiate a phase 2 exchange with the old SA1. What is the correct way for SG2 to respond to this? Initiate a nes phase 1 exchange? Send an error notification to SG2 (then necessarily unencrypted due to nonexistant ISAKMP SA)? The latter might open up a denial-of-service attack by sending spoofed error notifications to make SG1 invalidate its existing SAs and thus cause lots of unnecessary ISAKMP traffic and service disruption. Hansi From owner-ipsec@lists.tislabs.com Tue Nov 23 07:25:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03870; Tue, 23 Nov 1999 07:25:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24847 Tue, 23 Nov 1999 08:35:22 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Don Johnson" To: Russ Housley cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , "Simon Blake-Wilson" , "Phil Griffin" Message-ID: <85256831.0069D316.00@domino2.certicom.com> Date: Mon, 22 Nov 1999 14:07:00 -0500 Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, Also, I am not suggesting it MUST be changed, just that it would be preferred to be consistent, if at all possible, Don Johnson Russ Housley on 11/22/99 01:50:56 PM To: Don Johnson/Certicom@Certicom cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , Simon Blake-Wilson/Certicom@Certicom, "Phil Griffin" Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Don: At 09:36 AM 11/22/99 -0500, Don Johnson wrote: >2. The order of the parameters in the domain parameters should be made >consistent with X9.30 DSA, I think. If this is not the way it is, it >should be >changed in X9.42. I find no ASN.1 in X9.30 part 1. Russ From owner-ipsec@lists.tislabs.com Tue Nov 23 07:29:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04089; Tue, 23 Nov 1999 07:29:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24929 Tue, 23 Nov 1999 08:38:21 -0500 (EST) Message-Id: <4.2.0.58.19991122144732.00a45f00@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 22 Nov 1999 14:56:30 -0500 To: "Don Johnson" From: Russ Housley Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , "Simon Blake-Wilson" , "Phil Griffin" In-Reply-To: <85256831.0069D316.00@domino2.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Don: The ASN.1 associated with DSA in X9.57 is completely aligned with PKIX (RFC 2459). The DSA parameters contain p, q, and g. The ASN.1 associated with Diffie-Hellman in the draft X9.42 is completely aligned with PKIX (RFC 2459) and S/MIME (RFC 2631). The D-H parameters contain p, g, q, j (optional), and validationParms (also optional). Both of these parameter structures are included in RFC 2459. Concerns about alignment of the two structures should have been raised many months ago. While it might have been nice to have the two parameter definitions use the same order for p, q, and g, this is not a show stopper. People have implemented with against the current specifications, and I am strongly opposed to changes at this late date. Russ At 02:06 PM 11/22/99 -0500, Don Johnson wrote: >Russ, > >Yes, the ASN.1 for X9.30 is/was in X9.57 Certificate Management, DSA was the >only public key ANSI X9 had at that time. >Don Johnson > > > > > >Russ Housley on 11/22/99 01:50:56 PM > >To: Don Johnson/Certicom@Certicom >cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, > ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, > ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, > jis@mit.edu, > mleech@nortelnetworks.com, Elaine Barker , > Sharon > Keller , Simon Blake-Wilson/Certicom@Certicom, "Phil > Griffin" > >Subject: RE: FIPS 186 and X9.42: One of these things is not like the other > > > > >Don: > >At 09:36 AM 11/22/99 -0500, Don Johnson wrote: > >2. The order of the parameters in the domain parameters should be made > >consistent with X9.30 DSA, I think. If this is not the way it is, it > >should be > >changed in X9.42. > >I find no ASN.1 in X9.30 part 1. > >Russ > > From owner-ipsec@lists.tislabs.com Tue Nov 23 07:29:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04117; Tue, 23 Nov 1999 07:29:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24896 Tue, 23 Nov 1999 08:37:25 -0500 (EST) Message-Id: <4.2.0.58.19991122135026.00956aa0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 22 Nov 1999 13:50:56 -0500 To: "Don Johnson" From: Russ Housley Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , "Simon Blake-Wilson" , "Phil Griffin" In-Reply-To: <85256831.0050D9FB.00@domino2.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Don: At 09:36 AM 11/22/99 -0500, Don Johnson wrote: >2. The order of the parameters in the domain parameters should be made >consistent with X9.30 DSA, I think. If this is not the way it is, it >should be >changed in X9.42. I find no ASN.1 in X9.30 part 1. Russ From owner-ipsec@lists.tislabs.com Tue Nov 23 07:30:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04166; Tue, 23 Nov 1999 07:30:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24932 Tue, 23 Nov 1999 08:38:23 -0500 (EST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: elaine.barker@nist.gov, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, skeller@nist.gov Subject: Re: FIPS 186 and X9.42: One of these things is not like the other Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Tue, 23 Nov 1999 11:39:10 (NZDT) Message-ID: <94331035024854@cs26.cs.auckland.ac.nz> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Recipient list trimmed somewhat, I hope this is going to appropriate people] Russ Housley writes: >Both of these parameter structures are included in RFC 2459. Concerns about >alignment of the two structures should have been raised many months ago. > >While it might have been nice to have the two parameter definitions use the >same order for p, q, and g, this is not a show stopper. People have >implemented with against the current specifications, and I am strongly >opposed to changes at this late date. I had the impression that for an outsider to influence ANSI standards was close to impossible (if it wasn't for P1363 I'd never even have seen X9.42), which is why I never commented on it. Besides, I can't go around nitpicking *every* standard around, there are only so many hours in the day :-). That's why, in my original message, I merely suggested that any new work which uses X9.42 and FIPS 186/X9.30/whatever other standard it appears in point out that although the keys look the same and quack the same, they have two of the parameters (with names which look almost identical) reversed in the ASN.1 form. This is a trap just waiting to catch the unwary. [Having said that, I'd certainly like to see the ASN.1 fixed so the two match up, but I guess that's unlikely to happen at this stage]. Peter. From owner-ipsec@lists.tislabs.com Tue Nov 23 07:34:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04559; Tue, 23 Nov 1999 07:34:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24807 Tue, 23 Nov 1999 08:33:21 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Don Johnson" To: Russ Housley cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , "Simon Blake-Wilson" , "Phil Griffin" Message-ID: <85256831.0069D316.00@domino2.certicom.com> Date: Mon, 22 Nov 1999 14:06:17 -0500 Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, Yes, the ASN.1 for X9.30 is/was in X9.57 Certificate Management, DSA was the only public key ANSI X9 had at that time. Don Johnson Russ Housley on 11/22/99 01:50:56 PM To: Don Johnson/Certicom@Certicom cc: "John C. Kennedy" , pgut001@cs.aucKland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, jis@mit.edu, mleech@nortelnetworks.com, Elaine Barker , Sharon Keller , Simon Blake-Wilson/Certicom@Certicom, "Phil Griffin" Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Don: At 09:36 AM 11/22/99 -0500, Don Johnson wrote: >2. The order of the parameters in the domain parameters should be made >consistent with X9.30 DSA, I think. If this is not the way it is, it >should be >changed in X9.42. I find no ASN.1 in X9.30 part 1. Russ From owner-ipsec@lists.tislabs.com Tue Nov 23 07:36:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04701; Tue, 23 Nov 1999 07:36:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24865 Tue, 23 Nov 1999 08:36:24 -0500 (EST) From: "John C. Kennedy" To: "Russ Housley" Cc: , , , , , , , , , , "Elaine Barker" , "Sharon Keller" , "Simon Blake-Wilson" , "Phil Griffin" Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Date: Mon, 22 Nov 1999 12:57:13 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0056_01BF34E9.03F25260" Importance: Normal In-Reply-To: <4.2.0.58.19991122105512.009c6e00@mail.spyrus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0056_01BF34E9.03F25260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Russ, 1. With all due respect, saying that I have been "out of the loop" is not quite correct. I have continued to track the output of both X9F1 and IETF with regards to X9.42 and DH for the last couple of years. I have copies of X9.42 drafts up through February 1999. One does not have to be "in the loop" to see the inconsistencies I have pointed out. 2. The PKIX "son-of-2459" work, of which mostly only the ASN.1 portion of X9.42 is relevant, is probably correct. What is a bigger problem is that RFC 2631 (Diffie-Hellman Key Agreement Method) by Eric Rescorla references a 1998 draft. The related drafts, and , reference RFC 2631. Is there proper alignment in these works with the current state of X9.42? I don't think so. How would the larger IETF community know if they were? Is ANSI keeping all these authors "in the loop"? 3. FIPS 186-1 on DSA and rDSA is a good example. If the X9.42 specification had been kept as simple as FIPS 186 we wouldn't be where we are now. It is unfortunate that crypto-politics and other machinations did not allow NIST to handle this work independent of ANSI from the beginning. -John jkennedy@trustpoint.com > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > John: > > You have been out of the loop for over two years, and your > observation are > simply incorrect! > > The people that have been working on the PKIX and S/MIME standards that > refer to X9.42 have been given every version of the document as it became > available to the X9F1 working group participants. And, X9F1 has > worked to > ensure that they did not change the parts of X9.42 that were > adopted by the > IETF. > > Peter may not like the minor differences between X9.42 and DSA. But the > IETF documents are aligned with the X9.42 (just as they claim). By the > way, FIPS 186 contains no ASN.1; it only contains the algorithm > specification. > > Russ > > > At 01:17 AM 11/21/99 -0800, John C. Kennedy wrote: > >(A long but hopefully illuminating follow-up regarding ANSI X9.42) > > > >(**Summary: The use or referencing of the ANSI X9.42 > (Diffie-Hellman) drafts > >in IETF standards has resulted in the propagation of a number of > errors and > >inconsistencies within IETF drafts and RFCs. IMHO, it is questionable > >whether the still unratified ANSI X9.42 draft should be used as > a basis or > >even a reference for ongoing IETF Diffie-Hellman protocol standardization > >work.) > > > >Peter, > > > >I was the editor of the ANSI X9.42 Diffie-Hellman draft up until > about April > >of 1997 when I changed employers and passed the X9.42 editing > torch. Since > >my current work has given me a reason to wade back into the IETF > process, I > >wanted to share a few comments and provide some additional data on the > >apparent state of Diffie-Hellman in IETF work. As I revisit things 2.5 > >years later it seems to still be a bit of a mess in need of some > tidying up. > > > >(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42. I > >believe this may be a draft that I "strategically distributed" to a few > >select people working in IPSEC, PKIX, and other IETF working > groups around > >that time. ANSI X9F has never had a lot of interest in seeing X9.42 > >reviewed or adopted by IETF. [In fact, it is ridiculous that > after almost > >five years of work and innumerable rewrites, neither ANSI or NIST have > >published an authoritative interoperability standard for one the most > >fundamental and powerful public key techniques for key agreement we have. > >(Hint: It is not because of patents or because it is too difficult to > >communicate.)] > > > >(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a > 1998 draft > >of X9.42. This X9.42 draft is probably the one made available by ANSI to > >IEEE P1363 members at > >http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will > >need an IEEE P1363 password to get at this.) This draft is > better than the > >1997 draft, but still has problems. Since I have not been involved with > >ANSI for about 3 years, I can't comment on where the X9.42 draft > currently > >stands. Since the X9.42 draft document is (still!) not public, it is not > >clear whether it is relevant to the IETF's work anyway. RFC 2631 is > >currently a proposed standard in IETF. Since RFC 2631 propagates errors > >that existed in the 1998 X9.42 draft, a second look at it is > probably called > >for. (These errors are noted below) > > > >(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman > >standards. While the techniques given in this document are > mathematically > >accurate and certainly filled a gap in the IPSEC work at the time, the > >OAKLEY RFC doesn't quite provide all the pieces needed to link > up with PKIX > >and some other security standards. > > > >(4) The following drafts contain relevant references to Diffie-Hellman or > >related protocols. The first two reference RFC 2631 and the second > >specifies a new DH variant altogether: > >draft-ietf-smime-small-subgroup-02.txt > >draft-ietf-pkix-dhpop-02.txt > >draft-ietf-secsh-transport-06.txt > > > >(5) Both of the ANSI documents currently referenced were drafts > and probably > >weren't the best basis for IETF standards. Given the lack of > anything else > >to point to, I can't say I blame the authors, however. They > certainly meant > >well. What is also unfortunate is that IETF community has not > been provided > >with access to more current X9.42 drafts. This is, IMHO, > probably related > >to the situation I pointed out in (1). > > > >Now, in reponse to your observations: > > > >(6) RFC 2631 states "X9.42 requires that the private key x be in the > >interval [2, (q - 2)]" > >In other words, (1 < x < q-1). **It is quite clear that the referenced > >X9.42 draft is not only wrong but inconsistent**. And in a number of > >places. The Diffie-Hellman private key x should be chosen in the closed > >interval [2^(m-1), q-1], where m is the minimum length in bits acceptable > >for the private key. (Typically m>=160, but your mileage may > vary...) This > >is consistent with security recommendations in the current IEEE P1363 > >documents as well as definitions in > draft-ietf-smime-small-subgroup-02.txt, > >draft-ietf-pkix-dhpop-02.txt. (If there is a mathematical > subtlety I have > >forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to > >correct me.) > > > >Note that choosing x in [1, q-1] will work just fine mathematically, but > >does not reflect or enforce the minimum key size requirement. > Note that if > >the size of q is at least a few bit greater than m and you are > using a good > >RNG to pick x, the point is probably moot anyway. If you are using a > >long-term (aka "static") DH keys, however, it probably not a bad > idea to put > >the minimum keysize check in your keygen routine as a "belt and > suspenders" > >type measure. > > > >(7) The domain parameter generation routines in X9.42 were in > fact derived > >from those in the FIP 186 spec to allow re-use of DSA parameters > (p, q, and > >g) with X9.42 if desired. I can't say I am a big fan of this because it > >forces q to 160 bits which is probably not appropriate if you intend to > >enforce a minimum DH private key size greater than 160. > > > >(8) The parameter order switch was not a deliberate booby trap, although > >these types of things do help to keep crypto engineers on their > toes. :) As > >I recall, the parameters q and j were added when concerns about small > >subgroup attacks on Diffie-Hellman surfaced. It is more of a coincidence > >that the DSA algorithm exploits the use of a subgroup also defined by a > >prime called q. In other words, DSA included q from the beginning while > >X9.42 added q as a security enhancement. The ASN.1 encoding > choices are an > >artifact of the development process, not a deliberate reversal. > If you feel > >like lobbying ANSI X9F to change the ordering to make everyone's life > >easier, have at it. I wouldn't hold my breath however. :) > > > >(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: > > DomainParameters ::= SEQUENCE { > > p INTEGER, -- odd prime, p=jq +1 > > g INTEGER, -- generator, g > > q INTEGER, -- factor of p-1 > > j INTEGER OPTIONAL, -- subgroup factor > > validationParms ValidationParms OPTIONAL } > > > > ValidationParms ::= SEQUENCE { > > seed BIT STRING, > > pgenCounter INTEGER } > > > >whereas the 1998 X9.42 draft shows them as: > > > >DomainParameters ::= SEQUENCE { -- Galois field group parameters > > p INTEGER, -- odd prime, p = jq + 1 > > g INTEGER, -- generator, g > > q INTEGER, -- prime factor of p-1 > > j INTEGER, -- subgroup factor, j >= 2 > > validationParms ValidationParms OPTIONAL > >(**Note q is no longer optional.** JK) > > > >if you can find a copy of the 1997 draft (which I happen to > have) we see the > >original version: > > > >DomainParameters ::= SEQUENCE { -- Galois field group parameters > > p INTEGER, -- odd prime, p = jq + 1 > > g INTEGER, -- generator, g > > q INTEGER OPTIONAL, -- prime factor of p-1 > > j INTEGER OPTIONAL, -- subgroup factor, j >= 2 > > validationParms ValidationParms OPTIONAL > > > >(This early draft reflects my admitted ignorance of proper ASN.1 at the > >time. You cannot have multiple optional INTEGERS without tags on them.) > > > >My guess is that the middle version (i.e., with only ValidationParms > >optional) is the preferred version, which means RFC 2459 should > probably be > >changed. I do not know what the current X9.42 draft gives. > > > >****Conclusion**** > >(10) Because of the aforementioned errors and inconsistencies, I have > >serious reservations about the continued use or referencing of > ANSI X9.42 in > >IETF drafts or standards. The use or referencing of the ANSI > X9.42 draft in > >IETF standards has resulted in the propagation of a number of errors and > >inconsistencies within IETF drafts and RFCs. IMHO, it is questionable > >whether the apparently still unratified and possibly unstable ANSI X9.42 > >draft should be used as a basis or reference for ongoing IETF > Diffie-Hellman > >protocol standardization efforts. Because of this, I respectfully submit > >that the IETF should consider whether RFC 2631 should be deprecated and > >rewritten in a manner which removes unnecessary references to > the mysterious > >and forever-unpublished ANSI X9.42 draft. > > > > > >-John Kennedy > >jkennedy@trustpoint.com > > > > > > > >-----Original Message----- > >From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] > >Sent: Sunday, November 21, 1999 1:58 PM > >To: ietf-pkix@imc.org; ietf-smime@imc.org > >Subject: FIPS 186 and X9.42: One of these things is not like the other > > > > > >FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key > >generation algorithm, and have domain parameters which look identical, > >however > >there are two subtle differences between them, one of which is really > >annoying. > > > >The annoying difference is that when writing the domain parameters, the > >order > >of q and g is reversed for FIPS 186 and X9.42 keys, so that > while DSA domain > >parameters are written (p, q, g), exactly the same domain parameters when > >viewed as X9.42 values are written (p, g, q). This isn't helped > by the fact > >that in many fonts lowercase q and g look very similar. Apart > from the fact > >that it's a booby-trap for implementors, it also means that if the domain > >parameters are identified in the traditional way (SHA-1 hash), identical > >parameters will appear to be different depending on whether you're > >interpreting > >them as DSA/KEA or DH parameters. > > > >The second difference is in the allowed range for x: > > > > FIPS 186: 0 < x < q (ie x = 1...q-1) > > X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2) > > > >This looks like a transcription error from FIPS 186, given that using any > >x < ~2^160 is unsound I can't see why there'd be any difference between 1 > >and 2 > >as a lower bound. > > > >Perhaps new RFC's which cover this (eg son-of-RFC2459) could include > >warnings > >to the effect that although the parameters are the same internally, their > >external representations differ. > > > >Does anyone know why X9.42 decided to reverse the parameter order? > > > >(The motivation for this post is that ages ago I solved the > problem of the > > reversed parameters by swapping the pointers for the X9.42 g > and q values > >so > > they were read and written in the correct order, recently I was looking > > through the code and wondered why it was working fine for both > >interpretations > > of parameter ordering. There's now a big comment block by the code > >explaining > > the Bug which Isn't) > > > >Peter. ------=_NextPart_000_0056_01BF34E9.03F25260 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMTIyMjA1 NjM4WjAjBgkqhkiG9w0BCQQxFgQUG7z6EA/nfah6ILD1P+sSefziq/AwWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgHwXLP1sgy74hdtWvoz4y9Z2lt4LTBnorA5tLYxSD3XMKSmaPvNr8/b4 rS5foo+1N5YyVBy+G/MDwM21PeyUZeneUwJ+XJaZOLRLavB2z7diCcuDd3A1nY/xPRoTQfsK587o Yoad3QzhM3tgTFSZg+OLV72KiwfSgKX+3YH/hb0yAAAAAAAA ------=_NextPart_000_0056_01BF34E9.03F25260-- From owner-ipsec@lists.tislabs.com Tue Nov 23 07:42:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05041; Tue, 23 Nov 1999 07:42:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24853 Tue, 23 Nov 1999 08:35:24 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Don Johnson" To: "John C. Kennedy" cc: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com, "Elaine Barker" , "Sharon Keller" , "Simon Blake-Wilson" , asn1@mindspring.com Message-ID: <85256831.006FFE00.00@domino2.certicom.com> Date: Mon, 22 Nov 1999 15:17:00 -0500 Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM" Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM Content-type: text/plain; charset=us-ascii Content-Disposition: inline John, 1. ANSI X9.42 is supposed to go shortly to final ballot. 2. Yes, it looks like the different orders of parms are now cast in concrete. 3. A duplicate private key can be detected by checking for a duplicate public key, if this is a concern. For example, if an ephemeral public key repeats, then the forward secrecy property may fail. But this is often handled as being a event so rare it does not need to be checked. If it is a concern, it can be checked. Don Johnson "John C. Kennedy" on 11/22/99 03:08:47 PM To: Don Johnson/Certicom@Certicom cc: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com, ekr@rtfm.com, robert.zuccherato@entrust.com, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com, "Elaine Barker" , "Sharon Keller" , Simon Blake-Wilson/Certicom@Certicom, "Phil Griffin" Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Don, 1. I truly hope it is ready for final ballot. Many people have been patiently waiting for it and respectfully referencing and including placeholders in code and other standards in anticipation of it. It is not ANSI X9F1's responsibility to supply IETF with algorithm standards in a timely fashion. By the same token, IETF security working groups must be vigilant to not delay important work by continuing to hitch its wagon to a Diffie-Hellman draft that the ANSI committee continues to revise and which is *still* not ratified. My first post gave valid evidence of the results of this decision thus far. 2. IMHO, the order of the parameters is irrelevant as long as they are labeled and encoded correctly. 3. Is the private key now called 'd' instead of 'x'? As for the range of the private key, the checks to be performed during generation should be unambiguous. Whether or not the receiver of the corresponding public number can verify that these checks were done is somewhat meaningless. For example, can the receiver tell whether or not the sender's private number was generated with a robust PRNG that won't repeat itself every tenth time it is accessed? -John -----Original Message----- From: Don Johnson [mailto:djohnson@certicom.com] Sent: Monday, November 22, 1999 6:36 AM To: John C. Kennedy Cc: pgut001@cs.auckland.ac.nz; ietf-pkix@imc.org; ietf-smime@imc.org; ipsec@lists.tislabs.com; ekr@rtfm.com; robert.zuccherato@entrust.com; wpolk@nist.gov; housley@spyrus.com; jis@mit.edu; mleech@nortelnetworks.com; Elaine Barker; Sharon Keller; Simon Blake-Wilson; Phil Griffin Subject: RE: FIPS 186 and X9.42: One of these things is not like the other John, A few comments on X9.42. 1. Elaine Barkey and Sharon Keller of NIST are the editors of ANSI X9.42. I am copying them on your note. It should be ready for final ballot. 2. The order of the parameters in the domain parameters should be made consistent with X9.30 DSA, I think. If this is not the way it is, it should be changed in X9.42. 3. The private key d should be a value from 1 to q-1 in X9.42. It is allowed to chop off the ends and make it 2 to q-2. Any further reduction risks reducing the keysize and therefore aiding the adversary. The reason that "low" values are allowed sometimes is that it is not known how to detect such a situation. In fact, if it were, then DH would unravel anyway. Don Johnson "John C. Kennedy" on 11/21/99 04:17:21 AM To: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com cc: ekr@rtfm.com, robert.zuccherato@entrust.com, Don Johnson/Certicom@Certicom, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com Subject: RE: FIPS 186 and X9.42: One of these things is not like the other (A long but hopefully illuminating follow-up regarding ANSI X9.42) (**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the still unratified ANSI X9.42 draft should be used as a basis or even a reference for ongoing IETF Diffie-Hellman protocol standardization work.) Peter, I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April of 1997 when I changed employers and passed the X9.42 editing torch. Since my current work has given me a reason to wade back into the IETF process, I wanted to share a few comments and provide some additional data on the apparent state of Diffie-Hellman in IETF work. As I revisit things 2.5 years later it seems to still be a bit of a mess in need of some tidying up. (1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42. I believe this may be a draft that I "strategically distributed" to a few select people working in IPSEC, PKIX, and other IETF working groups around that time. ANSI X9F has never had a lot of interest in seeing X9.42 reviewed or adopted by IETF. [In fact, it is ridiculous that after almost five years of work and innumerable rewrites, neither ANSI or NIST have published an authoritative interoperability standard for one the most fundamental and powerful public key techniques for key agreement we have. (Hint: It is not because of patents or because it is too difficult to communicate.)] (2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft of X9.42. This X9.42 draft is probably the one made available by ANSI to IEEE P1363 members at http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will need an IEEE P1363 password to get at this.) This draft is better than the 1997 draft, but still has problems. Since I have not been involved with ANSI for about 3 years, I can't comment on where the X9.42 draft currently stands. Since the X9.42 draft document is (still!) not public, it is not clear whether it is relevant to the IETF's work anyway. RFC 2631 is currently a proposed standard in IETF. Since RFC 2631 propagates errors that existed in the 1998 X9.42 draft, a second look at it is probably called for. (These errors are noted below) (3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman standards. While the techniques given in this document are mathematically accurate and certainly filled a gap in the IPSEC work at the time, the OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX and some other security standards. (4) The following drafts contain relevant references to Diffie-Hellman or related protocols. The first two reference RFC 2631 and the second specifies a new DH variant altogether: draft-ietf-smime-small-subgroup-02.txt draft-ietf-pkix-dhpop-02.txt draft-ietf-secsh-transport-06.txt (5) Both of the ANSI documents currently referenced were drafts and probably weren't the best basis for IETF standards. Given the lack of anything else to point to, I can't say I blame the authors, however. They certainly meant well. What is also unfortunate is that IETF community has not been provided with access to more current X9.42 drafts. This is, IMHO, probably related to the situation I pointed out in (1). Now, in reponse to your observations: (6) RFC 2631 states "X9.42 requires that the private key x be in the interval [2, (q - 2)]" In other words, (1 < x < q-1). **It is quite clear that the referenced X9.42 draft is not only wrong but inconsistent**. And in a number of places. The Diffie-Hellman private key x should be chosen in the closed interval [2^(m-1), q-1], where m is the minimum length in bits acceptable for the private key. (Typically m>=160, but your mileage may vary...) This is consistent with security recommendations in the current IEEE P1363 documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt, draft-ietf-pkix-dhpop-02.txt. (If there is a mathematical subtlety I have forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to correct me.) Note that choosing x in [1, q-1] will work just fine mathematically, but does not reflect or enforce the minimum key size requirement. Note that if the size of q is at least a few bit greater than m and you are using a good RNG to pick x, the point is probably moot anyway. If you are using a long-term (aka "static") DH keys, however, it probably not a bad idea to put the minimum keysize check in your keygen routine as a "belt and suspenders" type measure. (7) The domain parameter generation routines in X9.42 were in fact derived from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and g) with X9.42 if desired. I can't say I am a big fan of this because it forces q to 160 bits which is probably not appropriate if you intend to enforce a minimum DH private key size greater than 160. (8) The parameter order switch was not a deliberate booby trap, although these types of things do help to keep crypto engineers on their toes. :) As I recall, the parameters q and j were added when concerns about small subgroup attacks on Diffie-Hellman surfaced. It is more of a coincidence that the DSA algorithm exploits the use of a subgroup also defined by a prime called q. In other words, DSA included q from the beginning while X9.42 added q as a security enhancement. The ASN.1 encoding choices are an artifact of the development process, not a deliberate reversal. If you feel like lobbying ANSI X9F to change the ordering to make everyone's life easier, have at it. I wouldn't hold my breath however. :) (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } whereas the 1998 X9.42 draft shows them as: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER, -- prime factor of p-1 j INTEGER, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (**Note q is no longer optional.** JK) if you can find a copy of the 1997 draft (which I happen to have) we see the original version: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER OPTIONAL, -- prime factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (This early draft reflects my admitted ignorance of proper ASN.1 at the time. You cannot have multiple optional INTEGERS without tags on them.) My guess is that the middle version (i.e., with only ValidationParms optional) is the preferred version, which means RFC 2459 should probably be changed. I do not know what the current X9.42 draft gives. ****Conclusion**** (10) Because of the aforementioned errors and inconsistencies, I have serious reservations about the continued use or referencing of ANSI X9.42 in IETF drafts or standards. The use or referencing of the ANSI X9.42 draft in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the apparently still unratified and possibly unstable ANSI X9.42 draft should be used as a basis or reference for ongoing IETF Diffie-Hellman protocol standardization efforts. Because of this, I respectfully submit that the IETF should consider whether RFC 2631 should be deprecated and rewritten in a manner which removes unnecessary references to the mysterious and forever-unpublished ANSI X9.42 draft. -John Kennedy jkennedy@trustpoint.com -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Sunday, November 21, 1999 1:58 PM To: ietf-pkix@imc.org; ietf-smime@imc.org Subject: FIPS 186 and X9.42: One of these things is not like the other FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key generation algorithm, and have domain parameters which look identical, however there are two subtle differences between them, one of which is really annoying. The annoying difference is that when writing the domain parameters, the order of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain parameters are written (p, q, g), exactly the same domain parameters when viewed as X9.42 values are written (p, g, q). This isn't helped by the fact that in many fonts lowercase q and g look very similar. Apart from the fact that it's a booby-trap for implementors, it also means that if the domain parameters are identified in the traditional way (SHA-1 hash), identical parameters will appear to be different depending on whether you're interpreting them as DSA/KEA or DH parameters. The second difference is in the allowed range for x: FIPS 186: 0 < x < q (ie x = 1...q-1) X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2) This looks like a transcription error from FIPS 186, given that using any x < ~2^160 is unsound I can't see why there'd be any difference between 1 and 2 as a lower bound. Perhaps new RFC's which cover this (eg son-of-RFC2459) could include warnings to the effect that although the parameters are the same internally, their external representations differ. Does anyone know why X9.42 decided to reverse the parameter order? (The motivation for this post is that ages ago I solved the problem of the reversed parameters by swapping the pointers for the X9.42 g and q values so they were read and written in the correct order, recently I was looking through the code and wondered why it was working fine for both interpretations of parameter ordering. There's now a big comment block by the code explaining the Bug which Isn't) Peter. --0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-transfer-encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMTIyMjAw ODAwWjAjBgkqhkiG9w0BCQQxFgQUBdgjSDcpnR2EJcDFK2skB/DlnoEwWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgDZrQXq3paFT0/wSmjF07F1aFaSLQDaVMzPFcaDkEiXIAMneugvSdduZ o/W6+y9R89kXdg9DJyGTym1wDe0fR3l9zbraPCh/U4jmU15SpoVyftjdWpZDwWdb43x4im44uXxj xuc9jnthCBqtWlsqtfo9ue0jBaYy0wB7QjmfOanKAAAAAAAA --0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM-- From owner-ipsec@lists.tislabs.com Tue Nov 23 07:53:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05759; Tue, 23 Nov 1999 07:53:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24852 Tue, 23 Nov 1999 08:35:23 -0500 (EST) From: "John C. Kennedy" To: "Don Johnson" Cc: , , , , , , , , , , "Elaine Barker" , "Sharon Keller" , "Simon Blake-Wilson" , "Phil Griffin" Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Date: Mon, 22 Nov 1999 12:08:47 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003E_01BF34E2.38788920" Importance: Normal In-Reply-To: <85256831.0050D9FB.00@domino2.certicom.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003E_01BF34E2.38788920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Don, 1. I truly hope it is ready for final ballot. Many people have been patiently waiting for it and respectfully referencing and including placeholders in code and other standards in anticipation of it. It is not ANSI X9F1's responsibility to supply IETF with algorithm standards in a timely fashion. By the same token, IETF security working groups must be vigilant to not delay important work by continuing to hitch its wagon to a Diffie-Hellman draft that the ANSI committee continues to revise and which is *still* not ratified. My first post gave valid evidence of the results of this decision thus far. 2. IMHO, the order of the parameters is irrelevant as long as they are labeled and encoded correctly. 3. Is the private key now called 'd' instead of 'x'? As for the range of the private key, the checks to be performed during generation should be unambiguous. Whether or not the receiver of the corresponding public number can verify that these checks were done is somewhat meaningless. For example, can the receiver tell whether or not the sender's private number was generated with a robust PRNG that won't repeat itself every tenth time it is accessed? -John -----Original Message----- From: Don Johnson [mailto:djohnson@certicom.com] Sent: Monday, November 22, 1999 6:36 AM To: John C. Kennedy Cc: pgut001@cs.auckland.ac.nz; ietf-pkix@imc.org; ietf-smime@imc.org; ipsec@lists.tislabs.com; ekr@rtfm.com; robert.zuccherato@entrust.com; wpolk@nist.gov; housley@spyrus.com; jis@mit.edu; mleech@nortelnetworks.com; Elaine Barker; Sharon Keller; Simon Blake-Wilson; Phil Griffin Subject: RE: FIPS 186 and X9.42: One of these things is not like the other John, A few comments on X9.42. 1. Elaine Barkey and Sharon Keller of NIST are the editors of ANSI X9.42. I am copying them on your note. It should be ready for final ballot. 2. The order of the parameters in the domain parameters should be made consistent with X9.30 DSA, I think. If this is not the way it is, it should be changed in X9.42. 3. The private key d should be a value from 1 to q-1 in X9.42. It is allowed to chop off the ends and make it 2 to q-2. Any further reduction risks reducing the keysize and therefore aiding the adversary. The reason that "low" values are allowed sometimes is that it is not known how to detect such a situation. In fact, if it were, then DH would unravel anyway. Don Johnson "John C. Kennedy" on 11/21/99 04:17:21 AM To: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org, ietf-smime@imc.org, ipsec@lists.tislabs.com cc: ekr@rtfm.com, robert.zuccherato@entrust.com, Don Johnson/Certicom@Certicom, wpolk@nist.gov, housley@spyrus.com, jis@mit.edu, mleech@nortelnetworks.com Subject: RE: FIPS 186 and X9.42: One of these things is not like the other (A long but hopefully illuminating follow-up regarding ANSI X9.42) (**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the still unratified ANSI X9.42 draft should be used as a basis or even a reference for ongoing IETF Diffie-Hellman protocol standardization work.) Peter, I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April of 1997 when I changed employers and passed the X9.42 editing torch. Since my current work has given me a reason to wade back into the IETF process, I wanted to share a few comments and provide some additional data on the apparent state of Diffie-Hellman in IETF work. As I revisit things 2.5 years later it seems to still be a bit of a mess in need of some tidying up. (1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42. I believe this may be a draft that I "strategically distributed" to a few select people working in IPSEC, PKIX, and other IETF working groups around that time. ANSI X9F has never had a lot of interest in seeing X9.42 reviewed or adopted by IETF. [In fact, it is ridiculous that after almost five years of work and innumerable rewrites, neither ANSI or NIST have published an authoritative interoperability standard for one the most fundamental and powerful public key techniques for key agreement we have. (Hint: It is not because of patents or because it is too difficult to communicate.)] (2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft of X9.42. This X9.42 draft is probably the one made available by ANSI to IEEE P1363 members at http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will need an IEEE P1363 password to get at this.) This draft is better than the 1997 draft, but still has problems. Since I have not been involved with ANSI for about 3 years, I can't comment on where the X9.42 draft currently stands. Since the X9.42 draft document is (still!) not public, it is not clear whether it is relevant to the IETF's work anyway. RFC 2631 is currently a proposed standard in IETF. Since RFC 2631 propagates errors that existed in the 1998 X9.42 draft, a second look at it is probably called for. (These errors are noted below) (3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman standards. While the techniques given in this document are mathematically accurate and certainly filled a gap in the IPSEC work at the time, the OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX and some other security standards. (4) The following drafts contain relevant references to Diffie-Hellman or related protocols. The first two reference RFC 2631 and the second specifies a new DH variant altogether: draft-ietf-smime-small-subgroup-02.txt draft-ietf-pkix-dhpop-02.txt draft-ietf-secsh-transport-06.txt (5) Both of the ANSI documents currently referenced were drafts and probably weren't the best basis for IETF standards. Given the lack of anything else to point to, I can't say I blame the authors, however. They certainly meant well. What is also unfortunate is that IETF community has not been provided with access to more current X9.42 drafts. This is, IMHO, probably related to the situation I pointed out in (1). Now, in reponse to your observations: (6) RFC 2631 states "X9.42 requires that the private key x be in the interval [2, (q - 2)]" In other words, (1 < x < q-1). **It is quite clear that the referenced X9.42 draft is not only wrong but inconsistent**. And in a number of places. The Diffie-Hellman private key x should be chosen in the closed interval [2^(m-1), q-1], where m is the minimum length in bits acceptable for the private key. (Typically m>=160, but your mileage may vary...) This is consistent with security recommendations in the current IEEE P1363 documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt, draft-ietf-pkix-dhpop-02.txt. (If there is a mathematical subtlety I have forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to correct me.) Note that choosing x in [1, q-1] will work just fine mathematically, but does not reflect or enforce the minimum key size requirement. Note that if the size of q is at least a few bit greater than m and you are using a good RNG to pick x, the point is probably moot anyway. If you are using a long-term (aka "static") DH keys, however, it probably not a bad idea to put the minimum keysize check in your keygen routine as a "belt and suspenders" type measure. (7) The domain parameter generation routines in X9.42 were in fact derived from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and g) with X9.42 if desired. I can't say I am a big fan of this because it forces q to 160 bits which is probably not appropriate if you intend to enforce a minimum DH private key size greater than 160. (8) The parameter order switch was not a deliberate booby trap, although these types of things do help to keep crypto engineers on their toes. :) As I recall, the parameters q and j were added when concerns about small subgroup attacks on Diffie-Hellman surfaced. It is more of a coincidence that the DSA algorithm exploits the use of a subgroup also defined by a prime called q. In other words, DSA included q from the beginning while X9.42 added q as a security enhancement. The ASN.1 encoding choices are an artifact of the development process, not a deliberate reversal. If you feel like lobbying ANSI X9F to change the ordering to make everyone's life easier, have at it. I wouldn't hold my breath however. :) (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as: DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } whereas the 1998 X9.42 draft shows them as: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER, -- prime factor of p-1 j INTEGER, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (**Note q is no longer optional.** JK) if you can find a copy of the 1997 draft (which I happen to have) we see the original version: DomainParameters ::= SEQUENCE { -- Galois field group parameters p INTEGER, -- odd prime, p = jq + 1 g INTEGER, -- generator, g q INTEGER OPTIONAL, -- prime factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j >= 2 validationParms ValidationParms OPTIONAL (This early draft reflects my admitted ignorance of proper ASN.1 at the time. You cannot have multiple optional INTEGERS without tags on them.) My guess is that the middle version (i.e., with only ValidationParms optional) is the preferred version, which means RFC 2459 should probably be changed. I do not know what the current X9.42 draft gives. ****Conclusion**** (10) Because of the aforementioned errors and inconsistencies, I have serious reservations about the continued use or referencing of ANSI X9.42 in IETF drafts or standards. The use or referencing of the ANSI X9.42 draft in IETF standards has resulted in the propagation of a number of errors and inconsistencies within IETF drafts and RFCs. IMHO, it is questionable whether the apparently still unratified and possibly unstable ANSI X9.42 draft should be used as a basis or reference for ongoing IETF Diffie-Hellman protocol standardization efforts. Because of this, I respectfully submit that the IETF should consider whether RFC 2631 should be deprecated and rewritten in a manner which removes unnecessary references to the mysterious and forever-unpublished ANSI X9.42 draft. -John Kennedy jkennedy@trustpoint.com -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Sunday, November 21, 1999 1:58 PM To: ietf-pkix@imc.org; ietf-smime@imc.org Subject: FIPS 186 and X9.42: One of these things is not like the other FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key generation algorithm, and have domain parameters which look identical, however there are two subtle differences between them, one of which is really annoying. The annoying difference is that when writing the domain parameters, the order of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain parameters are written (p, q, g), exactly the same domain parameters when viewed as X9.42 values are written (p, g, q). This isn't helped by the fact that in many fonts lowercase q and g look very similar. Apart from the fact that it's a booby-trap for implementors, it also means that if the domain parameters are identified in the traditional way (SHA-1 hash), identical parameters will appear to be different depending on whether you're interpreting them as DSA/KEA or DH parameters. The second difference is in the allowed range for x: FIPS 186: 0 < x < q (ie x = 1...q-1) X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2) This looks like a transcription error from FIPS 186, given that using any x < ~2^160 is unsound I can't see why there'd be any difference between 1 and 2 as a lower bound. Perhaps new RFC's which cover this (eg son-of-RFC2459) could include warnings to the effect that although the parameters are the same internally, their external representations differ. Does anyone know why X9.42 decided to reverse the parameter order? (The motivation for this post is that ages ago I solved the problem of the reversed parameters by swapping the pointers for the X9.42 g and q values so they were read and written in the correct order, recently I was looking through the code and wondered why it was working fine for both interpretations of parameter ordering. There's now a big comment block by the code explaining the Bug which Isn't) Peter. ------=_NextPart_000_003E_01BF34E2.38788920 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMTIyMjAw ODAwWjAjBgkqhkiG9w0BCQQxFgQUBdgjSDcpnR2EJcDFK2skB/DlnoEwWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgDZrQXq3paFT0/wSmjF07F1aFaSLQDaVMzPFcaDkEiXIAMneugvSdduZ o/W6+y9R89kXdg9DJyGTym1wDe0fR3l9zbraPCh/U4jmU15SpoVyftjdWpZDwWdb43x4im44uXxj xuc9jnthCBqtWlsqtfo9ue0jBaYy0wB7QjmfOanKAAAAAAAA ------=_NextPart_000_003E_01BF34E2.38788920-- From owner-ipsec@lists.tislabs.com Tue Nov 23 09:34:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09155; Tue, 23 Nov 1999 09:34:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25165 Tue, 23 Nov 1999 09:35:51 -0500 (EST) Message-Id: <4.2.0.58.19991123091224.009e5ee0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 23 Nov 1999 09:18:21 -0500 To: "John C. Kennedy" From: Russ Housley Subject: RE: FIPS 186 and X9.42: One of these things is not like the other Cc: , , , , , , , , , , "Elaine Barker" , "Sharon Keller" , "Simon Blake-Wilson" , "Phil Griffin" In-Reply-To: References: <4.2.0.58.19991122105512.009c6e00@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John: At 12:57 PM 11/22/99 -0800, John C. Kennedy wrote: >1. With all due respect, saying that I have been "out of the loop" is not >quite correct. I have continued to track the output of both X9F1 and IETF >with regards to X9.42 and DH for the last couple of years. I have copies >of X9.42 drafts up through February 1999. One does not have to be "in the >loop" to see the inconsistencies I have pointed out. > >2. The PKIX "son-of-2459" work, of which mostly only the ASN.1 portion of >X9.42 is relevant, is probably correct. What is a bigger problem is that >RFC 2631 (Diffie-Hellman Key Agreement Method) by Eric Rescorla references >a 1998 draft. The related drafts, >and , reference RFC 2631. Is there proper >alignment in these works with the current state of X9.42? I don't think >so. How would the larger IETF community know if they were? Is ANSI >keeping all these authors "in the loop"? > >3. FIPS 186-1 on DSA and rDSA is a good example. If the X9.42 >specification had been kept as simple as FIPS 186 we wouldn't be where we >are now. It is unfortunate that crypto-politics and other machinations >did not allow NIST to handle this work independent of ANSI from the >beginning. 1. I apologize. You certainly have not taken an active role in the IETF or X9F1 for the last few years. I am glad to hear that you have kept current. I would encourage you to become actively involved again. 2. Once the IETF adopted X9.42, I worked diligently with X9F1 to ensure that none of the aspects of X9.42 that were adopted by the IETF were changed. We made a final comparison of the X9.42 draft and RFC 2631 just prior to publication of the RFC. I have commitment that the parts of X9.42 that are included in RFC 2631 will not be changed unless a security problem is discovered. If a security problem is discovered, then the IETF will want to update RFC 2631 anyway, so this is not a concern. 3. Agree. Russ From owner-ipsec@lists.tislabs.com Tue Nov 23 10:51:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10689; Tue, 23 Nov 1999 10:51:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25492 Tue, 23 Nov 1999 10:55:28 -0500 (EST) Message-ID: <383ABA5A.BBFBF5FA@ibm.net> Date: Tue, 23 Nov 1999 11:01:30 -0500 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Error recovery? References: <319A1C5F94C8D11192DE00805FBBADDFFA7F99@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, I agree that the best alternative is a keep-alive mechanism similar to what is done with L2TP. What I don't understand is why people are not sending DELETEs when they go down. I realize that DELETEs are not acknowledged and can be lost, however in most situations this helps solve the problem. It seems like the most appropriate way to inform the other side that you are going to stop using an SA before it naturally expires. In our implementation, we always send DELETEs for any existing phase 1 or phase 2 SAs that we current know about when we go down. We will try this regardless of the reason we are going down - maybe a normal shutdown, however maybe an exception that is bringing us down. This has help tremendously, but unfortunately this does not appear to be common practice. Mike Williams Andrew Krywaniuk wrote: > Hansi, > > I've done a fairly exhaustive analysis of this situation, and it seems > apparent that the only way to really fix the problem is with some kind of > keep-alive protocol. > > It doesn't really matter if it's a stateless asynchronous query protocol: > > E.g. "Are you still there?" "Yes." > > or a stateful synchronous uni-directional protocol: > > E.g. "I'm still here (seq no=1234)." > > The problem is that if the SA really has gone down then the peer can't > communicate with you without performing some kind of time-consuming > operation (e.g. negotiating a new SA, signing a packet with RSA, etc). This > makes it very easy for an attacker to spoof a packet which will elicit a > response from one of the peers, thus effecting a DoS attack. The only way to > detect a lost SA without the DoS vulnerability is to rely on a timeout. > > As for the keep-alive alternatives, the query protocol will yield a faster > recovery time, but the synchronous protocol is easier to write. > Unfortunately, there is currently no standardized keep-alive protocol in > IKE/IPSec. > > BTW, the other solution is to keep all state information in non-volatile > storage so it sticks around after a reboot. That's not very practical for > most of us, though. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > > > -----Original Message----- > > From: Hans-Joachim Knobloch [mailto:hajo@knobloch.de] > > Sent: Friday, November 19, 1999 1:02 PM > > To: ipsec@lists.tislabs.com > > Subject: Error recovery? > > > > > > Please excuse, if this is a FAQ or if I was simply too blind > > to find the > > answer in the RFCs and drafts on IPSec. > > > > Consider the case that two hosts communicate via two IPSec security > > gateways > > A <---> SG1 <-----> SG2 <---> B > > > > and that appropriate ISAKMP and IPSec SAs are established. Let us call > > these SAs SA1, SA2AB and SA2BA respectively. > > Now what happens, when SG2 is reset? > > > > When B sends a packet to A everything should be fine, since SG2 will > > initiate new phase 1 and phase 2 exchanges. > > But what if A sends a packet to B? SG1 will process the > > packet with the > > old IPsec SA2AB and SG2 will receive a packet with a most > > probably unknown > > SPI. Is this supposed to happen until SA2AB does "naturally expire"? > > Do we have to set SA lifetime short enough and/or hope that B > > will also > > send a packet more sooner than later? > > > > Alternatively one could imagine that SG2 sends SG1 some kind of > > (ICMP?) message to tell it to invalidate SA2AB. But then, > > this might be > > abused by an attacker to cause unnecessary ISAKMP traffic and > > a service > > disruption until new SAs are installed. > > > > In the above example, when SA2AB expires, SG1 will probably initiate a > > phase 2 exchange with the old SA1. What is the correct way for SG2 to > > respond to this? Initiate a nes phase 1 exchange? Send an error > > notification to SG2 (then necessarily unencrypted due to nonexistant > > ISAKMP SA)? The latter might open up a denial-of-service > > attack by sending > > spoofed error notifications to make SG1 invalidate its > > existing SAs and > > thus cause lots of unnecessary ISAKMP traffic and service disruption. > > > > Hansi > > > > From owner-ipsec@lists.tislabs.com Tue Nov 23 11:20:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11518; Tue, 23 Nov 1999 11:20:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25816 Tue, 23 Nov 1999 11:45:56 -0500 (EST) Date: Tue, 23 Nov 1999 11:49:02 -0500 Message-Id: <199911231649.LAA21614@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tytso@mit.edu Cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> <199911191544.KAA00707@tonga.xedia.com> <199911222332.SAA00861@trampoline.thunk.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me you're suggesting I'm objecting to the use of vendor ID as a feature indicator for reasons of purism. That's not correct. The bigger issue is that it's not going to work. Optional features are a set, and you can't use a boolean or enumeration to describe them. You need an encoding that can represent the subset each side implements (or wants to use). A bitmap will do that, but a vendor ID cannot. Let's step away from the temptation to throw together a quick and dirty hack that won't solve the problem. The argument of "cleaner and more pragmatic" doesn't fly. This sort of requirement has been handled in dozens of protocols for several decades now, it can't be hard or time consuming to nail down the right way to do it this time. With a bit of care and a bit of luck, it can be done in a way that doesn't cause nasty disruption to existing implementations. paul From owner-ipsec@lists.tislabs.com Tue Nov 23 12:39:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13059; Tue, 23 Nov 1999 12:39:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26303 Tue, 23 Nov 1999 13:35:58 -0500 (EST) Message-ID: <383ADFF3.48833B14@ibm.net> Date: Tue, 23 Nov 1999 13:41:55 -0500 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec Subject: IPComp rfc2393bis-00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk have a couple of questions with regards to negotiating IPCOMP with ISAKMP. IPComp draft rfc2393bis-00.txt explains that the CPI should be sent in the SPI field of the proposal payload when using ISAKMP to negotiated IPComp. This draft goes on to explain that 16 bit CPIs should be used, however 32 bit CPIs (SPIs) should be tolerated. Using the CPI, rather than a unique SPI for each associations leads to a couple of problems. First, it is not possible to send a single proposal which contains multiple IPComp transforms with different transform IDs. For example, the only way to negotiate IPComp with DEFLATE or LZS would be with 2 proposals since the SPI is part of the proposal payload. Additionally, and more importantly is that there is no way to uniquely identify an IPComp Association. It is entirely possible that 2 systems may have more than 1 IPComp Association (maybe part of an SA bundle with IPSec) using the same compression algo. In this case, there is no way to send a ISAKMP DELETE (which uses the SPI) to stop using one, but not the other. My questions are: 1) Why does this draft specify that the CPI MUST be sent as the SPI? I am assuming that there is some history here that I am not aware of? It seems redundant since the negotiated transform contains the compression algo which is also the CPI. 2) How are ISAKMP DELETEs handled for IPComp Associations? Are there implementations that are sending them? Any information that can be provided would be greatly appreciated. Thanks, Mike Williams From owner-ipsec@lists.tislabs.com Tue Nov 23 14:59:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15130; Tue, 23 Nov 1999 14:59:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26655 Tue, 23 Nov 1999 15:16:55 -0500 (EST) Date: Tue, 23 Nov 1999 15:13:56 -0500 Message-Id: <199911232013.PAA01872@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: pkoning@xedia.com CC: ipsec@lists.tislabs.com In-reply-to: <199911231649.LAA21614@tonga.xedia.com> (message from Paul Koning on Tue, 23 Nov 1999 11:49:02 -0500) Subject: Re: Phase 1 Re-keying Implementation Identification From: tytso@mit.edu Phone: (781) 391-3464 References: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> <199911191544.KAA00707@tonga.xedia.com> <199911222332.SAA00861@trampoline.thunk.org> <199911231649.LAA21614@tonga.xedia.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Tue, 23 Nov 1999 11:49:02 -0500 From: Paul Koning It seems to me you're suggesting I'm objecting to the use of vendor ID as a feature indicator for reasons of purism. That's not correct. The bigger issue is that it's not going to work. Optional features are a set, and you can't use a boolean or enumeration to describe them. You need an encoding that can represent the subset each side implements (or wants to use). A bitmap will do that, but a vendor ID cannot. My understanding (please correct me if I am wrong!) is that existing implementations which are doing this hack are sending multiple vendor ID's, one for each feature that they advertise that they support. The negotiated set of features is determined by having each side taking the intersection of the advertised features via the vendor ID. Hence, I believe it *does* work, although it is limited kind of negotiation, and as one person has pointed out, the vendor ID's aren't secured, so it is not a secure negotiation, thus further limiting its usefulness. If we believe that we need a stronger, better negotiation mechanism, then certainly we should design one instead of relying on the vendor ID field, which the spec explicitly disclaims as a possible way of negotiating protocol extensions. - Ted From owner-ipsec@lists.tislabs.com Tue Nov 23 16:15:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16158; Tue, 23 Nov 1999 16:15:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27194 Tue, 23 Nov 1999 17:42:56 -0500 (EST) Message-ID: <383B1888.D490D435@indusriver.com> Date: Tue, 23 Nov 1999 17:43:20 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: tytso@mit.edu CC: pkoning@xedia.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification References: <319A1C5F94C8D11192DE00805FBBADDFF7B5FC@exchange> <199911191544.KAA00707@tonga.xedia.com> <199911222332.SAA00861@trampoline.thunk.org> <199911231649.LAA21614@tonga.xedia.com> <199911232013.PAA01872@trampoline.thunk.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Do we have requirements on _when_ feature negotiation is needed? For example, must we negotiate optional features during Phase 1 for later use during the creation of the Phase 1 SA? Or, can we negotiate _after_ Phase 1 via something like Mode Config (aka IKECFG)? I prefer something like Mode Config's additional Transaction Exchange because it is secured by the Phase 1 SA and because it offers a moderately rich set of operations and attributes. However, it won't let you affect the creation of the Phase 1 SA. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Tue Nov 23 16:33:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16403; Tue, 23 Nov 1999 16:33:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27350 Tue, 23 Nov 1999 18:11:28 -0500 (EST) Message-Id: <199911232314.PAA04475@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Nov 1999 15:14:26 -0800 To: Mike Williams From: Avram Shacham Subject: Re: IPComp rfc2393bis-00 Cc: ippcp , ipsec@lists.tislabs.com In-Reply-To: <3839C006.30568FB1@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, At 05:13 PM 11/22/99 -0500, Mike Williams wrote: >I have a couple of questions with regards to negotiating IPCOMP with >ISAKMP. > >IPComp draft rfc2393bis-00.txt explains that the CPI should be sent in >the SPI field of the proposal payload when using ISAKMP to negotiated >IPComp. This draft goes on to explain that 16 bit CPIs should be used, >however 32 bit CPIs (SPIs) should be tolerated. Using the CPI, rather >than a unique SPI for each associations leads to a couple of problems. Why can't CPI be unique (as in the range 256-61439)? >First, it is not possible to send a single proposal which contains >multiple IPComp transforms with different transform IDs. For example, >the only way to negotiate IPComp with DEFLATE or LZS would be with 2 >proposals since the SPI is part of the proposal payload. specifies in section 4.1 (in identical words as rfc2393) - An IPComp Association is negotiated by the initiator using a Proposal Payload, which includes one or more Transform Payloads. The Proposal Payload specifies the IP Payload Compression Protocol in the protocol ID field and each Transform Payload contains the specific compression algorithm(s) being offered to the responder. Indeed, when the CPI is in the well-known range, i.e., the CPI is identical to the algorithm-ID, a proposal can include only a single algorithm -- as was discussed several times on these lists. In order to offer two or more algorithms in the same proposal, the CPI in the range 256-61439 is adequate. >Additionally, and more importantly is that there is no way to uniquely >identify an IPComp Association. It is entirely possible that 2 systems >may have more than 1 IPComp Association (maybe part of an SA bundle with >IPSec) using the same compression algo. Again, when the CPI is negotiated in the range 256-61439, what blocks implementations from identifying IPComp Associations? avram >In this case, there is no way >to send a ISAKMP DELETE (which uses the SPI) to stop using one, but not >the other. > >My questions are: > >1) Why does this draft specify that the CPI MUST be sent as the SPI? I >am assuming that there is some history here that I am not aware of? It >seems redundant since the negotiated transform contains the compression >algo which is also the CPI. > >2) How are ISAKMP DELETEs handled for IPComp Associations? Are there >implementations that are sending them? > >Any information that can be provided would be greatly appreciated. > >Thanks, >Mike Williams > From owner-ipsec@lists.tislabs.com Tue Nov 23 16:53:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16586; Tue, 23 Nov 1999 16:53:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27090 Tue, 23 Nov 1999 17:15:19 -0500 (EST) Date: Tue, 23 Nov 1999 17:16:30 -0500 Message-Id: <199911232216.RAA01932@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: gab@sun.com CC: gab@Eng.Sun.Com, ipsec@lists.tislabs.com In-reply-to: <199911230824.AAA19610@ha1mpk-mail.eng.sun.com> (Gabriel.Montenegro@eng.sun.com) Subject: Re: suggested clarification regarding port handling in ike From: tytso@mit.edu Phone: (781) 391-3464 References: <199911230824.AAA19610@ha1mpk-mail.eng.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Gabriel.Montenegro@eng.sun.com (Gabriel Montenegro) Date: Tue, 23 Nov 1999 00:33:02 -0800 1. content of id payload with respect to port numbers: port 500 or 0 are ok. 0 means 'other-than-500' 2. protocol handling (a transport issue): use the common "swap src/dst port and reply" #1 should go in the doi (id payload content). #2 should go in isakmp (i think), given that it talks about transport issues and not at all about payload contents. Yes, now I see what you mean. Indeed, it does makes sense to put "use the common 'swap src/dst port and reply" in the ISAKMP document (#2), and the contents of the id payload should go in the DOI document, along with the rest of the definition of the id payload (#1) having these in separate places would hardly be considered a clarification, so perhaps the blurb that mentions both should go in ike. after all, ike is where it all comes together (ike defers to doi for payload content items such as #1, and to isakmp for transport issues such as #2). so why not add a clarifying blurb into the current ike document? A clarification in the IKE document would be a good thing; but if the ISAKMP document doesn't spell out the "swap src/dst port and reply" normatively, it probably should. Whether we make this change now or wait until we advance the ISAKMP document up the standards track and make it as an editorial change is something we can discuss. ps - if you agree with the above analysis, would it be ok with you if i shared this with the alias? No need; I've cc'ed the ipsec mailing list on my reply. - Ted From owner-ipsec@lists.tislabs.com Tue Nov 23 17:35:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17070; Tue, 23 Nov 1999 17:35:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27489 Tue, 23 Nov 1999 19:10:23 -0500 (EST) Message-Id: <199911240012.QAA06259@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Nov 1999 16:12:53 -0800 To: itojun@iijlab.net From: Avram Shacham Subject: Re: IPComp rfc2393bis-00 Cc: ippcp , ipsec@lists.tislabs.com In-Reply-To: <26138.943401624@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:00 AM 11/24/99 +0900, itojun@iijlab.net wrote: > Thanks for clarification, I did not notice the following. I would > add a word ONLY, like "and are used ONLY for manual setup". > >>> 0-63 define well-known compression algorithms, which require no >>> additional information, and are used for manual setup. The There is a second use - to save the CPU cycles of the CPI-to-algorithm conversion, even when the algorithm is negotiated dynamically. That is the rationale for the note in the CPI definition: Compression Parameter Index (CPI) 16-bit index. The CPI is stored in network order. The values 0-63 define well-known compression algorithms, which require no additional information, and are used for manual setup. [...] Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. avram From owner-ipsec@lists.tislabs.com Tue Nov 23 17:39:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17141; Tue, 23 Nov 1999 17:39:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27426 Tue, 23 Nov 1999 18:53:14 -0500 (EST) Message-Id: <199911232355.PAA05726@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Nov 1999 15:55:43 -0800 To: itojun@iijlab.net From: Avram Shacham Subject: Re: IPComp rfc2393bis-00 Cc: ippcp , ipsec@lists.tislabs.com In-Reply-To: <25892.943400328@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:38 AM 11/24/99 +0900, itojun@iijlab.net wrote: > If you would like to negotiate the existence/support for IPComp > at each end, you will need to perform IKE negotiation for well-known > CPI. Is there any other way available for us to check such a > situation? > > Problem: node A has IPComp support, node B has no IPComp support. > Under your assumption node A will be using well-known CPI IPComp > without negotiating with node B. Packets will be dropped at node B. Node A has to offer CPI + Protocol ID + Transform(s) where The CPI is sent in the SPI field of the proposal, with the SPI size field set to match. [...] In the Internet IP Security Domain of Interpretation (DOI), IPComp is negotiated as the Protocol ID PROTO_IPCOMP. The compression algorithm is negotiated as one of the defined IPCOMP Transform Identifiers. What is missing? avram From owner-ipsec@lists.tislabs.com Tue Nov 23 17:59:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17518; Tue, 23 Nov 1999 17:59:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27587 Tue, 23 Nov 1999 19:37:51 -0500 (EST) Message-Id: <199911240040.QAA07045@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Nov 1999 16:40:21 -0800 To: itojun@iijlab.net From: Avram Shacham Subject: Re: IPComp rfc2393bis-00 Cc: ippcp , ipsec@lists.tislabs.com In-Reply-To: <26431.943403028@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:23 AM 11/24/99 +0900, itojun@iijlab.net wrote: > So, the negotiated CPI and a CPI on the packet will be different > in this case. Am I right? > negotiated CPI: 16-bit value in "negotiated" range (256-61439) > algorithm to be used: well-known algorithm X > CPI on packet: X No, the negotiated CPI is the CPI used on the packet header: Compression Parameter Index (CPI) [...] The outbound IPComp header MUST use the CPI value chosen by the decompressing node. That CPI MAY negotiated to be in the well-known range if, for example, the host supports just a single algorithm. Another scenario -- the host sends two IPComp proposals, each with a single transport and the CPI equals that transform-ID. > I may need a more explicit wording here. I'll try and add some clarifications to version -02 of the draft. avram From owner-ipsec@lists.tislabs.com Tue Nov 23 18:19:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19784; Tue, 23 Nov 1999 18:19:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27622 Tue, 23 Nov 1999 19:52:35 -0500 (EST) Message-Id: <199911240054.QAA07430@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Nov 1999 16:55:06 -0800 To: itojun@iijlab.net From: Avram Shacham Subject: Re: IPComp rfc2393bis-00 Cc: ippcp , ipsec@lists.tislabs.com In-Reply-To: <26542.943403433@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:30 AM 11/24/99 +0900, itojun@iijlab.net wrote: >>There is a second use - to save the CPU cycles of the >>CPI-to-algorithm conversion, even when the algorithm is negotiated >>dynamically. That is the rationale for the note in the CPI definition: > BTW If you use this optimization, the negotiated IPComp association > will never get expired if it uses bytecount as expiration signal. IPComp Association expiration -- by byte-count or time -- is not defined in rfc2393bis. If an implementation elects to negotiate byte-count via IKE, it needs to visit the IPCA for each packet, and therefore a CPI in the upper range may be more adequate. otoh, the CPI definition also includes: The CPI in combination with the destination IP address uniquely identifies the compression algorithm characteristics for the datagram. So, implementations may locate the IPCA by IP-addr+CPI, and do more bookkeeping, such as expiration by byte-count. avram From owner-ipsec@lists.tislabs.com Tue Nov 23 18:20:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19872; Tue, 23 Nov 1999 18:20:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27600 Tue, 23 Nov 1999 19:40:36 -0500 (EST) Date: Wed, 24 Nov 1999 02:42:24 +0200 (EET) Message-Id: <199911240042.CAA06661@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: tytso@mit.edu, pkoning@xedia.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-Reply-To: <199911230839.LAA15708@relay1.trustworks.com> References: <199911222332.SAA00861@trampoline.thunk.org> <199911230024.CAA25198@torni.ssh.fi> <199911230839.LAA15708@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > > The good thing about the SA payloads are that they are authenticated, > > so attacker cannot remove the features, as they can when you are using > > the vendor id payloads. > But attacker can always change responder's selection, because SAr is > not explicitly authenticated in IKE. True. I forgot that one. I just submitted a draft that will also that problem (it will also fix the original problem that vendor id payloads are not authenticated). Here is a copy of that draft: ---------------------------------------------------------------------- IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT SSH Communications Security draft-ietf-ipsec-ike-hash-revised-00.txt 23 November 1999 Expires: 23 May 2000 Fixing IKE Phase 1 Authentication HASH Status of This memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the generic ISAKMP [RFC-2408] header, nor does it authenticate any extra payloads inside phase 1 packets. This causes a security prob- lem when using extra payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). This document defines three methods how to negotiate the new HASH method. All methods tries to be backward compatible as much as possible. Only one of those methods must be selected by the working group and all the other should be removed from this document. T. Kivinen [page 1] INTERNET-DRAFT 23 November 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 3. Revised HASH Calculation . . . . . . . . . . . . . . . . . . . . 3 4. Negotiating Revised HASH . . . . . . . . . . . . . . . . . . . . 4 5. Selecting Revised HASH Using New Authentication Methods . . . . 4 6. Selecting Revised HASH Using New HASH Algorithms . . . . . . . . 5 7. Selecting Revised HASH Using New PRF Algorithm . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the IKE [RFC-2409] protocol there is a clear security problem, because of the way the authentication HASH is calculated. The HASH is defined in the [RFC-2409] like this: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) The HASH does not include all payloads, nor it does not include generic ISAKMP [RFC-2408] header, which contains version numbers, exchange type etc. This problem is quite easy to fix, but the bigger problem is how to fix it in the backward compatible way, so we do not break all existing implementations out there. Most of the implementations out there will break immediately if we update the ISAKMP major/minor number or the phase 1 transform identifier. Most of the implementators say that their implementation should be able to ignore unknown SA data attributes inside the SA payload. They will not select that transform, so there should also be transform that is supported by them to really be backward compatible. This means that the most backword compatible way to negotiate the new HASH method is to negotiate it inside the SA payload. One advantage of negotiating new HASH inside the SA payload is that it is authenticated, so if attacker removes new revised HASH proposals from the SA payload the initiator will detect this when checking the HASH. There are three different alternatives that can be used. One is to define new, revised, authentication method for each existing authentication method. I.e define "Pre Shared Keys Revised HASH Authentication Method", "RSA Signatures Revised HASH Authentication Method" etc. Another alternative is to duplicate all HASH types ("MD5 Revised Authentication HASH"), and the third way is to define PRF method to describe new authentication HASH usage ("Revised Authentication T. Kivinen [page 2] INTERNET-DRAFT 23 November 1999 PRF"). All of the cases are identical in sense that the reserved number range is large enough (16 bits), so we can "consume" some extra numbers. The PRF method is might have more problems, because currently it is not used at all (there is no defined PRFs), so some implementations might break when they see such attribute class. 2. Specification of Requirements This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC-2119] document. 3. Revised HASH Calculation The new HASH is defined so that all the packet received and sent before are included in the HASH calculation. This also includes the packet currently being generated. The HASH includes the ISAKMP generic headers, ISAKMP payload headers etc, i.e the exact bits sent to the wire from the beginning of the ISAKMP generic header to the end of the packet. The HASH includes the padding added because of the encryption. When the length of the packet (inside the ISAKMP header) is calculated in to the HASH, it MUST be set to the real length of packet including the padding. Packet is added to the HASH as plaintext. Retransmission packets are not added to the HASH. The authentication payloads (HASH or SIG) MUST be the last payload in the packet, and when it is calculated to the authentication HASH its contents MUST be all zeros, with proper length (either determined by the HASH algorithm or the public key used in the authentication). So in the main mode the initiator HASH is calculated as follows: HASH_I = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 | packet_5) Where the packet_1 is the first packet initiator sends to the network (starting from the beginning of the generic header and continuing to the length specified in the ISAKMP header). Same goes for packets 2 to 4. The packet 5 is special, because it is this packet we are currently sending out. It is calculated to the HASH before encryption, but including the padding. The HASH/SIG payload MUST be in its place and must contain all zeros. After the HASH has been calculated, the value is filled in to the place holder inside the packet and then the packet is encrypted before sent out. When the responder is checking the HASH it first decrypts the packet_5 and then it copies the HASH/SIG away and clears it from the packet. Then it calculates the exactly same HASH_I the initiator did, which can then be used authenticate the exchange (either direct comparison of the T. Kivinen [page 3] INTERNET-DRAFT 23 November 1999 HASH, or signature verification). In the main mode the responder HASH is calculated as follows: HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 | packet_5 | packet_6) The packets 1 to 5 are identical to initiator case, i.e the SIG/HASH payload inside the payload 5 contains zeros. The packet 6 is similar than packet 5 in the initiator case, i.e the HASH/SIG payload is in its place and must contain all zeros. In the aggressive mode the HASH is calculated as follows: HASH_I = prf(SKEYID, packet_1 | packet_2) HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3) With same kind of processing of packet 2 and 3 than was for packets 5 and 6 in the main mode. Note, that the encryption of the final packet in the aggressive mode does affect the HASH, because there might be padding added to the packet 3 which must be then be included to the HASH. 4. Negotiating Revised HASH The revised HASH is negotiated using defined attribute values inside the SA payload. This means that current implementations are able to ignore those proposal and select the old HASH method. New implementations SHOULD add revised HASH method before normal method, so that the new revised HASH method is preferred. XXX Next paragraph will disappear from the final document: Next three sections describe three different ways to negotiate the new revised HASH method. The working group must select one of those and after that two of the other methods are removed from this document. Each of sections are currently written as they would be there alone, thus there is some duplication of text inside of them. 5. Selecting Revised HASH Using New Authentication Methods The revised HASH method is negotiated by adding 5 new authentication methods, i.e: XXX+1 Pre-Shared Keys with Revised Authentication HASH XXX+2 DSS Signatures with Revised Authentication HASH XXX+3 RSA Signatures with Revised Authentication HASH XXX+4 T. Kivinen [page 4] INTERNET-DRAFT 23 November 1999 Encryption with RSA with Revised Authentication HASH XXX+5 Revised Encryption with RSA with Revised Authentication HASH Note, The XXX should be replaced as the last defined authentication method number from the RFC2409. Each authentication method is exactly identical to the old ones, except the HASH_I and HASH_R are calculated as described in the section ``Revised HASH Calculation''. In the signature modes the final SIG_I or SIG_R is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In the RSA Encryption mode the authentication of the other party takes place in the generation of the SKEYID, because to generate it correctly the other end must be able to decrypt the encrypted NONCE payload. Note that the ID and NONCE payloads are already encrypted using public key when they are calculated to the authentication HASH. 6. Selecting Revised HASH Using New HASH Algorithms The revised HASH method is negotiated by adding 3 new HASH algorithms, i.e: XXX+1 MD5 with Revised Authentication HASH XXX+2 SHA with Revised Authentication HASH XXX+3 Tiger with Revised Authentication HASH Note, The XXX should be replaced as the last defined hash algorithm number from the RFC2409. Each HASH is defined so that it doesn't affect the HASH algorithm itself, but the new revised HASH methods changes the way how the HASH_I and HASH_R are calculated. This is described in the section ``Revised HASH Calculation''. In the signature modes the final SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In the RSA Encryption mode the authentication of the other party happens in the generation of the SKEYID, because to generate it correctly the other end must be able to decrypt the encrypted NONCE payload. Note that the ID and NONCE payloads are already encrypted, when they are calculated to the authentication HASH. T. Kivinen [page 5] INTERNET-DRAFT 23 November 1999 7. Selecting Revised HASH Using New PRF Algorithm The revised HASH method is negotiated by adding a PRF algorithm, i.e: XXX+1 HMAC-HASH PRF with Revised Authentication HASH Note, The XXX should be replaced as the last defined PRF algorithm number from the RFC2409. Each HASH is defined so that it doesn't affect the prf algorithm itself, but the new revised HASH method change the way how the HASH_I and HASH_R are calculated. This is described in the section ``Revised HASH Calculation''. In the signature modes the final SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. In the RSA Encryption mode the authentication of the other party happens in the generation of the SKEYID, because to generate it correctly the other end must be able to decrypt the encrypted NONCE payload. Note that the ID and NONCE payloads are already encrypted, when they are calculated to the authentication HASH. 8. Security Considerations This document describes a way to fix the security problem inside the IKE. In the IKE defined in RFC2409 only some payloads are authenticated. This means that generic ISAKMP header (version numbers, exchange type, flags etc) and extra payloads (Notifications, Vendor ID, CERT, and CR payloads) are not authenticated. This document fixes that security problem. This document does NOT fix the other exchanges methods, like the quick mode or the new group mode exchanges. In those exchanges the ISAKMP generic header is still unauthenticated, all other payloads inside the those exchanges are already authenticated. 9. References [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998. [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", November 1998 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", March 1997 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 T. Kivinen [page 6] INTERNET-DRAFT 23 November 1999 10. Authors' Addresses Tero Kivinen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: kivinen@ssh.fi T. Kivinen [page 7] -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Nov 23 19:12:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23433; Tue, 23 Nov 1999 19:12:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27873 Tue, 23 Nov 1999 20:47:54 -0500 (EST) Message-Id: <199911240148.RAA22752@potassium.network-alchemy.com> To: Tero Kivinen cc: "Valery Smyslov" , tytso@mit.edu, pkoning@xedia.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-reply-to: Your message of "Wed, 24 Nov 1999 02:42:24 +0200." <199911240042.CAA06661@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22749.943408084.1@network-alchemy.com> Date: Tue, 23 Nov 1999 17:48:04 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that this is the technique used in CRACK. So CRACK will also authenticate all optional payloads as well as the outer ISAKMP header. If the attacker changes the responder's selection the exchange will fall apart due to the different sides having different attributes of the negotiated SA. Either the hash will be different, or the encryption algorithm, or the D-H public value, etc. but the exchange should fall apart in this case. Dan. On Wed, 24 Nov 1999 02:42:24 +0200 you wrote > Valery Smyslov writes: > > > The good thing about the SA payloads are that they are authenticated, > > > so attacker cannot remove the features, as they can when you are using > > > the vendor id payloads. > > But attacker can always change responder's selection, because SAr is > > not explicitly authenticated in IKE. > > True. I forgot that one. I just submitted a draft that will also that > problem (it will also fix the original problem that vendor id payloads > are not authenticated). > > Here is a copy of that draft: > ---------------------------------------------------------------------- > IP Security Protocol Working Group (IPSEC) T. Kivinen > INTERNET-DRAFT SSH Communications Security > draft-ietf-ipsec-ike-hash-revised-00.txt 23 November 1999 > Expires: 23 May 2000 [snip] From owner-ipsec@lists.tislabs.com Tue Nov 23 20:05:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26232; Tue, 23 Nov 1999 20:05:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28047 Tue, 23 Nov 1999 21:29:42 -0500 (EST) Message-Id: <9911240245.AA02675@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Wed, 24 Nov 1999 11:45:39 +0900 To: Ari Huttunen Cc: ipsec-list Subject: Re: Anonymous IKE phase 1 -mode In-Reply-To: <383985D3.FFDE9765@DataFellows.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen wrote: >>Somehow I have a feeling this idea will be shot dead, but >>I think there's some good to be had by it, so I'll give >>it a try... >> >>Basically the problem is that traditional Internet communications >>have been based on "authentication by IP addresses". This has >>one good quality (only) that I can think of: it is available to >>absolutely everyone in the Internet. IKE requires more, which >>means that it's not available to absolutely everyone. This in turn >>means that you can't encrypt your communications with that sort >>of a peer either. This in turn helps things like ECHELON. >> >>If there existed an IKE phase 1 mode that would not do any more >>authentication than what is provided by IP addresses, all Internet >>communications could become encrypted at once. This would make >>large scale Internet surveillance like ECHELON harder, because >>passive surveillance would no longer work, and active methods >>would be necessary. >> >>Now, I've created an IKE authentication method that was inspired >>by CRACK and SSH, and which works as follows: >> >> Initiator Responder >> ----------- ----------- >> HDR, SAi, Ni >> ---> >> <--- HDR, SAr, Nr >> HDR, KEi, PKi, SIGi >> ---> >> <--- HDR, KEr, PKr, SIGr >> >>(The signatures sign every field sent by that entity >>previously in the protocol as well as the source and >>destination IP addresses. PKx = Public Key of entity x.) >> >>This protocol has these properties: >>- After these messages I and R know they have a secure >> channel to someone holding the private key corresponding >> to the received public key. This someone is capable of sending >> and receiving packets with the correct IP address. >>- Resistance to DoS attacks: The initiator has to perform a signature >> calculation before the responder responds with KEr or SIGr. Here's a comment on DoS resistance. In your protocol, the responder must verify SIGi before knowing whether the initiator really generated the signature SIGi or not. This is not good in terms of CPU exhaustion. As an alternative, please have a look at http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt. Thanks, --^^-- Kanta From owner-ipsec@lists.tislabs.com Tue Nov 23 20:45:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27127; Tue, 23 Nov 1999 20:45:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA28175 Tue, 23 Nov 1999 22:11:23 -0500 (EST) Date: Wed, 24 Nov 1999 05:14:13 +0200 (EET) Message-Id: <199911240314.FAA06212@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Dan Harkins Cc: "Valery Smyslov" , tytso@mit.edu, pkoning@xedia.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 Re-keying Implementation Identification In-Reply-To: <199911240148.RAA22752@potassium.network-alchemy.com> References: <199911240042.CAA06661@torni.ssh.fi> <199911240148.RAA22752@potassium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > > Note that this is the technique used in CRACK. So CRACK will also > authenticate all optional payloads as well as the outer ISAKMP header. > Crack does calculate the HASH almost in the same way, but not quite. The crack does not include the final packet into the HASH. In crack it does not matter, because the final packet only includes the SIG payload so there is no need to authenticate that. In main mode and aggressive mode the last packet includes all kind of important payloads, thus it must be added to the HASH. This makes the HASH calculations here little harder... > If the attacker changes the responder's selection the exchange will > fall apart due to the different sides having different attributes of > the negotiated SA. Either the hash will be different, or the encryption > algorithm, or the D-H public value, etc. but the exchange should fall > apart in this case. Here we ware talking about (one possible way) adding feature negotiation system inside the SA payload instead of using vendor ID payloads for that. Because in most cases those features cannot directly be detected this is problem for that, so this kind of feature negotiation system is not possible, because of the security reasons. So we have to invent something else. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Nov 24 09:27:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11014; Wed, 24 Nov 1999 09:27:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00058 Wed, 24 Nov 1999 09:38:39 -0500 (EST) To: Avram Shacham cc: ippcp , ipsec@lists.tislabs.com In-reply-to: shacham's message of Tue, 23 Nov 1999 16:12:53 PST. <199911240012.QAA06259@honeybee.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp rfc2393bis-00 From: itojun@iijlab.net Date: Wed, 24 Nov 1999 09:30:33 +0900 Message-ID: <26542.943403433@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>> 0-63 define well-known compression algorithms, which require no >>>> additional information, and are used for manual setup. The >There is a second use - to save the CPU cycles of the >CPI-to-algorithm conversion, even when the algorithm is negotiated >dynamically. That is the rationale for the note in the CPI definition: > Compression Parameter Index (CPI) > > 16-bit index. The CPI is stored in network order. The values > 0-63 define well-known compression algorithms, which require no > additional information, and are used for manual setup. [...] Note: When > negotiating one of the well-known algorithms, the nodes MAY > select a CPI in the pre-defined range 0-63. BTW If you use this optimization, the negotiated IPComp association will never get expired if it uses bytecount as expiration signal. itojun From owner-ipsec@lists.tislabs.com Wed Nov 24 09:27:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11013; Wed, 24 Nov 1999 09:27:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29918 Wed, 24 Nov 1999 09:21:02 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA86D3@exchange> From: Stephane Beaulieu To: Mike Williams , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Error recovery? Date: Wed, 24 Nov 1999 09:22:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, > > What I don't understand is why people are not sending DELETEs > when they go > down. Sometimes it's not in the implementors control. For example if a remote user unplugs his modem before logging off or shutting down (happens more often than not), then we have no chance to send DELETEs. Stephane. From owner-ipsec@lists.tislabs.com Wed Nov 24 09:29:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11056; Wed, 24 Nov 1999 09:29:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00053 Wed, 24 Nov 1999 09:38:36 -0500 (EST) To: Avram Shacham cc: ippcp , ipsec@lists.tislabs.com In-reply-to: shacham's message of Tue, 23 Nov 1999 15:55:43 PST. <199911232355.PAA05726@honeybee.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp rfc2393bis-00 From: itojun@iijlab.net Date: Wed, 24 Nov 1999 09:00:24 +0900 Message-ID: <26138.943401624@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> If you would like to negotiate the existence/support for IPComp >> at each end, you will need to perform IKE negotiation for well-known >> CPI. Is there any other way available for us to check such a >> situation? >> >> Problem: node A has IPComp support, node B has no IPComp support. >> Under your assumption node A will be using well-known CPI IPComp >> without negotiating with node B. Packets will be dropped at node B. >Node A has to offer CPI + Protocol ID + Transform(s) >where > The CPI is sent in the SPI field of the proposal, with the SPI size > field set to match. >[...] > In the Internet IP Security Domain of Interpretation (DOI), IPComp is > negotiated as the Protocol ID PROTO_IPCOMP. The compression > algorithm is negotiated as one of the defined IPCOMP Transform > Identifiers. >What is missing? Thanks for clarification, I did not notice the following. I would add a word ONLY, like "and are used ONLY for manual setup". >> 0-63 define well-known compression algorithms, which require no >> additional information, and are used for manual setup. The ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ itojun From owner-ipsec@lists.tislabs.com Wed Nov 24 10:12:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11691; Wed, 24 Nov 1999 10:12:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00059 Wed, 24 Nov 1999 09:38:40 -0500 (EST) To: Avram Shacham cc: ippcp , ipsec@lists.tislabs.com In-reply-to: shacham's message of Tue, 23 Nov 1999 16:12:53 PST. <199911240012.QAA06259@honeybee.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp rfc2393bis-00 From: itojun@iijlab.net Date: Wed, 24 Nov 1999 09:23:48 +0900 Message-ID: <26431.943403028@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Thanks for clarification, I did not notice the following. I would >> add a word ONLY, like "and are used ONLY for manual setup". >>>> 0-63 define well-known compression algorithms, which require no >>>> additional information, and are used for manual setup. The >There is a second use - to save the CPU cycles of the >CPI-to-algorithm conversion, even when the algorithm is negotiated >dynamically. That is the rationale for the note in the CPI definition: So, the negotiated CPI and a CPI on the packet will be different in this case. Am I right? negotiated CPI: 16-bit value in "negotiated" range (256-61439) algorithm to be used: well-known algorithm X CPI on packet: X I may need a more explicit wording here. itojun From owner-ipsec@lists.tislabs.com Wed Nov 24 10:28:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12035; Wed, 24 Nov 1999 10:28:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00999 Wed, 24 Nov 1999 11:44:44 -0500 (EST) Message-ID: <383C1608.40FAADA6@indusriver.com> Date: Wed, 24 Nov 1999 11:44:56 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kierstead CC: Mike Williams , Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Error recovery? References: <319A1C5F94C8D11192DE00805FBBADDFFA870F@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our remote access client provides a single GUI that manages both physical dial-up and IPSEC tunnel initiatiation. Since our app gets the 'disconnect' command from the user, we can, and do, send the DELETE's, wait for them to get on the wire, and then disconnect the phone call. The user doesn't disconnect the call via some other UI although he can certainly unplug the modem :-(. We will probably keep our Phase 1 SA alive for the duration of the user's session so we can send the necessary phase 2 DELETE's and so we can add keep-alives in the future. -Ben McCann Paul Kierstead wrote: > > People who connect using dial-up generally just hang-up. You can intercept > this and try sending a DELETE, but your results may vary... > > As well, numerous vendors do not keep phase-1's up, and I suspect they feel > that renegotiating for the sake of a DELETE is not worth it. > > OTOH, it would still be damn helpful where you could have it. > -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Nov 24 10:30:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12076; Wed, 24 Nov 1999 10:30:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00014 Wed, 24 Nov 1999 09:36:36 -0500 (EST) To: Avram Shacham cc: ippcp , ipsec@lists.tislabs.com In-reply-to: shacham's message of Tue, 23 Nov 1999 15:14:26 PST. <199911232314.PAA04475@honeybee.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp rfc2393bis-00 From: itojun@iijlab.net Date: Wed, 24 Nov 1999 08:38:48 +0900 Message-ID: <25892.943400328@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>Additionally, and more importantly is that there is no way to uniquely >>identify an IPComp Association. It is entirely possible that 2 systems >>may have more than 1 IPComp Association (maybe part of an SA bundle with >>IPSec) using the same compression algo. >Again, when the CPI is negotiated in the range 256-61439, what blocks >implementations from identifying IPComp Associations? If you would like to negotiate the existence/support for IPComp at each end, you will need to perform IKE negotiation for well-known CPI. Is there any other way available for us to check such a situation? Problem: node A has IPComp support, node B has no IPComp support. Under your assumption node A will be using well-known CPI IPComp without negotiating with node B. Packets will be dropped at node B. itojun From owner-ipsec@lists.tislabs.com Wed Nov 24 10:42:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12276; Wed, 24 Nov 1999 10:42:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00304 Wed, 24 Nov 1999 10:02:01 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA870F@exchange> From: Paul Kierstead To: Mike Williams , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Error recovery? Date: Wed, 24 Nov 1999 09:58:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk People who connect using dial-up generally just hang-up. You can intercept this and try sending a DELETE, but your results may vary... As well, numerous vendors do not keep phase-1's up, and I suspect they feel that renegotiating for the sake of a DELETE is not worth it. OTOH, it would still be damn helpful where you could have it. Paul Kierstead TimeStep Corporation mailto:pmkierst@timestep.com http:\\www.timestep.com > -----Original Message----- > From: Mike Williams [mailto:mikewill@ibm.net] > Sent: Tuesday, November 23, 1999 11:02 AM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: Re: Error recovery? > > > Andrew, > > I agree that the best alternative is a keep-alive mechanism > similar to what is > done with L2TP. > > What I don't understand is why people are not sending DELETEs > when they go > down. I realize that DELETEs are not acknowledged and can be > lost, however in > most situations this helps solve the problem. It seems like > the most appropriate > way to inform the other side that you are going to stop using > an SA before it > naturally expires. > > In our implementation, we always send DELETEs for any > existing phase 1 or phase > 2 SAs that we current know about when we go down. We will > try this regardless > of the reason we are going down - maybe a normal shutdown, > however maybe an > exception that is bringing us down. This has help tremendously, but > unfortunately this does not appear to be common practice. > > Mike Williams > > Andrew Krywaniuk wrote: > > > Hansi, > > > > I've done a fairly exhaustive analysis of this situation, > and it seems > > apparent that the only way to really fix the problem is > with some kind of > > keep-alive protocol. > > > > It doesn't really matter if it's a stateless asynchronous > query protocol: > > > > E.g. "Are you still there?" "Yes." > > > > or a stateful synchronous uni-directional protocol: > > > > E.g. "I'm still here (seq no=1234)." > > > > The problem is that if the SA really has gone down then the > peer can't > > communicate with you without performing some kind of time-consuming > > operation (e.g. negotiating a new SA, signing a packet with > RSA, etc). This > > makes it very easy for an attacker to spoof a packet which > will elicit a > > response from one of the peers, thus effecting a DoS > attack. The only way to > > detect a lost SA without the DoS vulnerability is to rely > on a timeout. > > > > As for the keep-alive alternatives, the query protocol will > yield a faster > > recovery time, but the synchronous protocol is easier to write. > > Unfortunately, there is currently no standardized > keep-alive protocol in > > IKE/IPSec. > > > > BTW, the other solution is to keep all state information in > non-volatile > > storage so it sticks around after a reboot. That's not very > practical for > > most of us, though. > > > > Andrew > > _______________________________________________ > > Beauty without truth is insubstantial. > > Truth without beauty is unbearable. > > > > > -----Original Message----- > > > From: Hans-Joachim Knobloch [mailto:hajo@knobloch.de] > > > Sent: Friday, November 19, 1999 1:02 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Error recovery? > > > > > > > > > Please excuse, if this is a FAQ or if I was simply too blind > > > to find the > > > answer in the RFCs and drafts on IPSec. > > > > > > Consider the case that two hosts communicate via two > IPSec security > > > gateways > > > A <---> SG1 <-----> SG2 <---> B > > > > > > and that appropriate ISAKMP and IPSec SAs are > established. Let us call > > > these SAs SA1, SA2AB and SA2BA respectively. > > > Now what happens, when SG2 is reset? > > > > > > When B sends a packet to A everything should be fine, > since SG2 will > > > initiate new phase 1 and phase 2 exchanges. > > > But what if A sends a packet to B? SG1 will process the > > > packet with the > > > old IPsec SA2AB and SG2 will receive a packet with a most > > > probably unknown > > > SPI. Is this supposed to happen until SA2AB does > "naturally expire"? > > > Do we have to set SA lifetime short enough and/or hope that B > > > will also > > > send a packet more sooner than later? > > > > > > Alternatively one could imagine that SG2 sends SG1 some kind of > > > (ICMP?) message to tell it to invalidate SA2AB. But then, > > > this might be > > > abused by an attacker to cause unnecessary ISAKMP traffic and > > > a service > > > disruption until new SAs are installed. > > > > > > In the above example, when SA2AB expires, SG1 will > probably initiate a > > > phase 2 exchange with the old SA1. What is the correct > way for SG2 to > > > respond to this? Initiate a nes phase 1 exchange? Send an error > > > notification to SG2 (then necessarily unencrypted due to > nonexistant > > > ISAKMP SA)? The latter might open up a denial-of-service > > > attack by sending > > > spoofed error notifications to make SG1 invalidate its > > > existing SAs and > > > thus cause lots of unnecessary ISAKMP traffic and service > disruption. > > > > > > Hansi > > > > > > > From owner-ipsec@lists.tislabs.com Wed Nov 24 11:47:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13037; Wed, 24 Nov 1999 11:47:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01387 Wed, 24 Nov 1999 13:11:58 -0500 (EST) Message-ID: <000d01bf36a3$15117ce0$6a323ac3@elvis.ru> From: "Valery Smyslov" To: "Tero Kivinen" Cc: References: <199911222332.SAA00861@trampoline.thunk.org><199911230024.CAA25198@torni.ssh.fi><199911230839.LAA15708@relay1.trustworks.com> <199911240042.CAA06661@torni.ssh.fi> Subject: Fixing IKE Phase 1 Authentication HASH Date: Wed, 24 Nov 1999 20:41:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, some comments on your draft below. > The authentication payloads (HASH or SIG) MUST be the last payload in > the packet, and when it is calculated to the authentication HASH its > contents MUST be all zeros, with proper length (either determined by the > HASH algorithm or the public key used in the authentication). > > So in the main mode the initiator HASH is calculated as follows: > > HASH_I = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 | > packet_5) There is one problem with this approach. To calculate HASH you need now to retain all the packets untill the end of exchange. This makes IKE state unnecessary large. More important, it opens protocol to attacks, when initiator sends big packets (i.e. SA with a lot of proposals) without completeng exchange (this problem also exists with current HASH definition). The possible solution would be to change HASH definition as follows: HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) | hash(packet_4) | hash(packet_5)) where "hash" is negotiated hash function. This way we would save IKE state size by the cost of additional CPU usage. But taking into consideration that hash function must be fast enough, I think this could make sense. > In the main mode the responder HASH is calculated as follows: > > HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 | > packet_5 | packet_6) Again, I would suugest: HASH_R = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) | hash(packet_4) | hash(packet_5) | packet_6) Of course, there is no need to include hash(packet_6). > In the aggressive mode the HASH is calculated as follows: > > HASH_I = prf(SKEYID, packet_1 | packet_2) > HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3) Again, I would suggest: HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2)) HASH_R = prf(SKEYID, hash(packet_1) | hash(packet_2) | packet_3) > With same kind of processing of packet 2 and 3 than was for packets 5 > and 6 in the main mode. Note, that the encryption of the final packet in > the aggressive mode does affect the HASH, because there might be padding > added to the packet 3 which must be then be included to the HASH. > > 4. Negotiating Revised HASH It seems that the most natural way of negotiating this feature would be the first proposed - via new authenticated methods. The two others looks like a kludge. Regards, Valera. From owner-ipsec@lists.tislabs.com Wed Nov 24 13:30:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14428; Wed, 24 Nov 1999 13:30:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01518 Wed, 24 Nov 1999 13:31:15 -0500 (EST) Message-ID: <383C2FC8.C128233C@redcreek.com> Date: Wed, 24 Nov 1999 10:34:48 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kierstead CC: Mike Williams , Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Error recovery? References: <319A1C5F94C8D11192DE00805FBBADDFFA870F@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Kierstead wrote: > > People who connect using dial-up generally just hang-up. You can intercept > this and try sending a DELETE, but your results may vary... > > As well, numerous vendors do not keep phase-1's up, and I suspect they feel > that renegotiating for the sake of a DELETE is not worth it. > Just out of curiosity, are there any vendors here who don't keep phase 1 SAs up under most circumstances? I can't think of any reason why we would delete the IKE SA at the remote (client) end, and we would only take down the IKE SA at the sgw end if there were resource issues, like the scenario Tero described a few days ago. In these cases, we will attempt to reinstantiate the IKE SA at either end if there is any need to send anything via IKE (e.g. a DELETE), and the only reasons why this would not occur would relate either to resource issues (most likely on the sgw), or reachability issues. I think the other problem that Paul cites (users hanging up without first deleting the SA) is the more substantial issue here. Scott From owner-ipsec@lists.tislabs.com Wed Nov 24 15:04:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15585; Wed, 24 Nov 1999 15:04:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02227 Wed, 24 Nov 1999 16:06:08 -0500 (EST) Date: Wed, 24 Nov 1999 15:52:15 -0500 Message-Id: <199911242052.PAA01874@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: itojun@iijlab.net Cc: shacham@cisco.com, ippcp@external.cisco.com, ipsec@lists.tislabs.com Subject: Re: IPComp rfc2393bis-00 References: <199911240012.QAA06259@honeybee.cisco.com> <26431.943403028@coconut.itojun.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "itojun" == itojun writes: >>> Thanks for clarification, I did not notice the following. I >>> would add a word ONLY, like "and are used ONLY for manual setup". >>>>> 0-63 define well-known compression algorithms, which require no >>>>> additional information, and are used for manual setup. The >> There is a second use - to save the CPU cycles of the >> CPI-to-algorithm conversion, even when the algorithm is negotiated >> dynamically. That is the rationale for the note in the CPI >> definition: itojun> So, the negotiated CPI and a CPI on the packet will be itojun> different in this case. Am I right? negotiated CPI: 16-bit itojun> value in "negotiated" range (256-61439) algorithm to be used: itojun> well-known algorithm X CPI on packet: X I may need a more itojun> explicit wording here. That can't be right. Whatever is negotiated should be used. The notion of using well known CPI values can be used when picking the value to propose, but it can't make you use a value different from what's proposed... paul From owner-ipsec@lists.tislabs.com Wed Nov 24 16:34:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16703; Wed, 24 Nov 1999 16:34:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02518 Wed, 24 Nov 1999 18:24:10 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA89ED@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Tero's draft Date: Wed, 24 Nov 1999 18:29:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > True. I forgot that one. I just submitted a draft that will also that > problem (it will also fix the original problem that vendor id payloads > are not authenticated). Tero, Forgive me if I keep this short. I'm wearing a cast on my arm and typing is difficult... I've been thinking about this problem as well. There seemed to be two alternatives: add the extra payloads to the phase 1 signature or send the payloads (or a hash of the payloads) sometime after phase 1 is complete. The reason I prefer the latter solution is because I'm worried that signing anything and everything in phase 1 will open up the possibility of birthday attacks. Imagine that the attacker has access to a table of [hash, Sig(hash)] pairs... I believe the attacker could actually generate these himself (Am I wrong? This would be possible using pure RSA sigs, but I think it could be thwarted using deterministic padding -- I'm not really familiar with the details of the RSA variant we use). But in any case, the user could watch traffic and record the sigs, or if they are encrypted he could maybe obtain them by means of an active attack. ... If the attacker can generate a new exchange that has the same hash as previous exchange then he can replay the signature from a previous exchange. The ability to add new pseudorandom data that contributes to HASH allows the attacker to test hash inputs until he gets a familiar output. Of course, this is a general weakness in IKE. It exists whenever the host that is generating the signature was the last to add pseudorandom input to the hash (i.e. the host adds new authenticated data to the packet that contains the sig, or the previous message from the peer did not contain any unpredictable data). Right now, this attack is fairly limited. The vulnerabilities depend on exactly which exchange mode is used, but the components of the signature are safe: SA and ID are low entropy so they are not much of a threat; COOKIE is pseudorandom, but it is sent early in the exchange. KE actually hinders the attack because it is deterministic yet unpredictable -- it can be forged, but then the attacker won't know SKEYID (although I suppose the attacker could also have a large table of precomputed [x, g^x] pairs). So right now this attack is difficult (except against AM) because the only truly random field, COOKIE, is sent before KE. However, if we allow the signer to add extra fields haphazardly then we expose ourselves to this attack. I haven't actually done any feasibilty calculations on this scenario based on cpu speeds, etc. Maybe the prf output is large enough to take this attack into consideration. Foiling the attack is conceptually simple: Don't allow the host to add new authenticated data to the packet that contains the signature, and require that the peer send some unpredictable data which needs to be signed (e.g a nonce) in the preceding packet. I guess I didn't really keep this short, did I? Now my arm hurts... :-( Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Nov 24 19:24:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23926; Wed, 24 Nov 1999 19:24:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02879 Wed, 24 Nov 1999 20:58:17 -0500 (EST) Date: Thu, 25 Nov 1999 04:01:31 +0200 (EET) Message-Id: <199911250201.EAA19333@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: Subject: Fixing IKE Phase 1 Authentication HASH In-Reply-To: <000d01bf36a3$15117ce0$6a323ac3@elvis.ru> References: <199911222332.SAA00861@trampoline.thunk.org> <199911230024.CAA25198@torni.ssh.fi> <199911230839.LAA15708@relay1.trustworks.com> <199911240042.CAA06661@torni.ssh.fi> <000d01bf36a3$15117ce0$6a323ac3@elvis.ru> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 10 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > There is one problem with this approach. To calculate HASH you need now > to retain all the packets untill the end of exchange. This makes IKE state > unnecessary large. More important, it opens protocol to attacks, when > initiator sends big packets (i.e. SA with a lot of proposals) without completeng > exchange (this problem also exists with current HASH definition). The possible > solution would be to change HASH definition as follows: I tought that little bit earlier, but decided that it is better to have the protocol simple than to save few hunderd bytes of memory. > HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) | > hash(packet_4) | hash(packet_5)) If the memory consumption is really an issue, then I would define it to be like this (this is the another version I thought about): HASH_I = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 | packet_5)) HASH_R = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 | packet_5 | packet_6)) I.e when you send first packet you add it to hash, when you receive second packet you append it the hash (keeping the hash context around all the time), and so on. I.e you have one or two hash contextes around from the first packet until the calculation of hash. You can manage with one, if you are able to duplicate the hash context after adding packet 5, but before calling the hash finalization function. If you cannot do that then you can make two hash contextes around and add each packet to both of them. If we want to get around the need for second has in all cases we could define the HASH_R to be: HASH_R = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 | packet_5) | packet_6)) I.e the concatination of the HASH_I input hash and the packet_6. Normal hash context is something like 100 bytes, so this would use only 100 or 200 bytes per each IKE SA being negotiated. Having 5 hashes of packets consumes 80 or 100 bytes, so the cost at the end is almost the same. > > 4. Negotiating Revised HASH > It seems that the most natural way of negotiating this feature > would be the first proposed - via new authenticated methods. > The two others looks like a kludge. That would be also my choice. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Nov 24 19:31:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24366; Wed, 24 Nov 1999 19:31:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02968 Wed, 24 Nov 1999 21:17:02 -0500 (EST) Date: Thu, 25 Nov 1999 04:20:20 +0200 (EET) Message-Id: <199911250220.EAA18890@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Tero's draft In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFA89ED@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFFA89ED@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > ... If the attacker can generate a new exchange that has the same hash as > previous exchange then he can replay the signature from a previous exchange. > The ability to add new pseudorandom data that contributes to HASH allows the > attacker to test hash inputs until he gets a familiar output. If the attacker is able to generate an input that will result to a given hash output, then the hash algorithm is broken. Pre-shared keys and rsa-encryption mode authentications are not vulnerable at all with this attack, because they SKEYID used as a key depends on the information that only the related parties can know, and those SKEYID values are different for each exchange. For the signature mode the SKEYID is not tied to the related parties, but it is is tied to the Diffie-Hellman output. So only way the attacker can get that information is doing active attack, and if he is going to launch huge number of active attacks against one user, I think it will be detected. > I haven't actually done any feasibilty calculations on this scenario based > on cpu speeds, etc. Maybe the prf output is large enough to take this attack > into consideration. I don't think this kind of attack is feasible, but I can ask our cryptographers to check it out. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Nov 25 01:50:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07684; Thu, 25 Nov 1999 01:50:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03804 Thu, 25 Nov 1999 03:00:35 -0500 (EST) Message-Id: <199911250803.LAA14779@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Tero Kivinen Date: Thu, 25 Nov 1999 11:03:07 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fixing IKE Phase 1 Authentication HASH CC: In-reply-to: <199911250201.EAA19333@torni.ssh.fi> References: <000d01bf36a3$15117ce0$6a323ac3@elvis.ru> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 25 Nov 99, at 4:01, Tero Kivinen wrote: > Valery Smyslov writes: > > There is one problem with this approach. To calculate HASH you need now > > to retain all the packets untill the end of exchange. This makes IKE state > > unnecessary large. More important, it opens protocol to attacks, when > > initiator sends big packets (i.e. SA with a lot of proposals) without completeng > > exchange (this problem also exists with current HASH definition). The possible > > solution would be to change HASH definition as follows: > > I tought that little bit earlier, but decided that it is better to > have the protocol simple than to save few hunderd bytes of memory. I don't think that this changes make protocol much more complicated. And note, that this would save not only few hundred of bytes under normal circumstances, but, possibly, tens of kilobytes in case of attack. This saving would have sense. > > HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) | > > hash(packet_4) | hash(packet_5)) > > If the memory consumption is really an issue, then I would define it > to be like this (this is the another version I thought about): > > HASH_I = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 | > packet_5)) > HASH_R = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 | > packet_5 | packet_6)) > > I.e when you send first packet you add it to hash, when you receive > second packet you append it the hash (keeping the hash context around > all the time), and so on. I.e you have one or two hash contextes > around from the first packet until the calculation of hash. > > You can manage with one, if you are able to duplicate the hash context > after adding packet 5, but before calling the hash finalization > function. If you cannot do that then you can make two hash contextes > around and add each packet to both of them. > > If we want to get around the need for second has in all cases we could > define the HASH_R to be: > > HASH_R = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 | > packet_5) | packet_6)) This definition is OK too. However, there is one minor implementation advantage in definition HASH as prf over concatenating of individual packet hashes. Anyway, you need to detect retransmitted packets. To do so you need either to keep last received packet or to keep its hash. The latter case has obvious advantages of memory saving, moreover, if you define HASH as prf over concatenating of individual packet hashes you will need only one hash operation over packet for both detecting retransmissions and authenticating. So, you will save not only memory, but CPU resources too. > I.e the concatination of the HASH_I input hash and the packet_6. > > Normal hash context is something like 100 bytes, so this would use > only 100 or 200 bytes per each IKE SA being negotiated. > > Having 5 hashes of packets consumes 80 or 100 bytes, so the cost at > the end is almost the same. > > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ Best regards, Valera. From owner-ipsec@lists.tislabs.com Thu Nov 25 13:28:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17267; Thu, 25 Nov 1999 13:28:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05741 Thu, 25 Nov 1999 14:57:40 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA8BBE@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt Date: Thu, 25 Nov 1999 15:03:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a number of concerns about this document, right from the process level down to the detailed. First, there was concern that the WG should even be doing an application specific MIB for IPsec. I believe there was a vote, but unfortunately, I can't remember the exact question that Ted asked, but I believe there was no clear consensus on whatever it was. Therefore, before I make further comments on this document, I'd like to re-open the question (Ted, stop me if I shouldn't be doing this). Should the WG be developing a VPN/Remote Access application-specific MIB for IPsec? (I choose VPN/remote access since they seem to be the primary applications for IPsec and they're the primary focus of this document, and also of the one I presented over a year ago.) If so, then we need to decide on the features and requirements. I believe this document at a high level is a good start, but I also believe it is missing some things that will make it useful for both VPN and remote access. Then, if the WG is to proceed, I'd like to ask the authors of this document to consider adapting this document to use the textual conventions, IPsec, ISAKMP and IKE monitoring MIBs already in development, in addition to modifying it to add any features the WG thinks are missing. Comments? Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: November 19, 1999 6:58 AM > To: IETF-Announce > Cc: ipsec@lists.tislabs.com > Subject: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Security Protocol Working > Group of the IETF. > > Title : IPsec Flow Monitoring MIB > Author(s) : C. Madson, L. Temoshenko, C. Pellacuru, > N. Timms, R. Somasundaram > Filename : draft-ietf-ipsec-flow-monitoring-mib-00.txt > Pages : 107 > Date : 18-Nov-99 > > This document describes a high-level MIB for monitoring, > accounting and error detection for IPsec. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-flow-moni > toring-mib-00.txt > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipsec-flow-monitoring-mib-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ipsec@lists.tislabs.com Thu Nov 25 19:27:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25848; Thu, 25 Nov 1999 19:27:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06393 Thu, 25 Nov 1999 21:01:00 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFA8C55@exchange> From: Andrew Krywaniuk To: Tero Kivinen , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Tero's draft Date: Thu, 25 Nov 1999 21:06:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tero. > Pre-shared keys and rsa-encryption mode authentications are not > vulnerable at all with this attack, because they SKEYID used as a key > depends on the information that only the related parties can know, and > those SKEYID values are different for each exchange. Yes, this is only a vulnerability of signature-based authentication, but since it's the auth method many of us are advocating... > For the signature mode the SKEYID is not tied to the related parties, > but it is is tied to the Diffie-Hellman output. So only way the > attacker can get that information is doing active attack, and if he is > going to launch huge number of active attacks against one user, I > think it will be detected. What if they are doing aggresive mode? The responder sends KE and SIG in the same packet. The attacker has no need for active attacks. He listens passively until he finds an input that works and then he forges KE and SIG at the same time. (And this works against both parties in base mode.) During this time, an intermediate router could drop packets in order to increase the time it has to search for a suitable hash input. Occasional dropped packets are unlikely to be logged as an attack. > If the attacker is able to generate an input that will result to a > given hash output, then the hash algorithm is broken. I guess you're right that the hash algorithm would have to be somewhat weak. Probably you should require implementors to use a hash algorithm that is sufficiently resistant against birthday attacks (e.g. not MD5). But your statement about having to "generate an input that will result to a given hash output" is incorrect. You have to generate an input that will hash to one of many hash outputs for which the signature is known. You also have to worry about differential plaintext attacks. Does the hash function maintain its full N bits of entropy against small changes in input? Valery's suggestion of hashing each message individually would actually strengthen your proposal against a differential chosen plaintext attack. In most parts of IKE, we only hash messages that are also encrypted (we also use HMAC, which is more resistant to birthday attacks). The phase 1 signature is the only place where we can see the direct output of the hash (by decrypting the SIG and removing the deterministic padding). I'm not saying that forging the signature would be easy, but it's much easier to perform a birthday attack on a variable message than it is to forge the signature for a completely deterministic message, so this change will clearly weaken IKE. Before: - attack is most likely active - chosen input plaintext is limited After: - attack is passive - input plaintext can be chosen I'm just wondering how many bits of effective security do we lose, and what recommendations do we need to make about the choice of hash function. > I don't think this kind of attack is feasible, but I can ask our > cryptographers to check it out. Let me try. Say that: N is the entropy of the hash. X is the dictionary of known hashes. Y is the number of trial hashes the attacker can generate during the session hijacking window. Z is the number of phase 1 negotiations which he can attempt to hijack. I think all the variables are orthogonal. If all variables are expressed in bits and N is the entropy of the hash and we disregard insignificant terms then the security loss against a long-term passive attack is X + Y + Z bits. If the hash has a weakness against chosen differential plaintext attacks then... it's too complicated for me to figure out. Say that: N* is the effective entropy of the hash against differential input. A reflects the time spent searching for differential attack candidates. B reflects the time spent specifically on the differential attack. A + B > 100%, since the searches are not orthagonal. My estimate would be X + [log2(1+A) + log2(1+B)(N - N*)] Y + Z bits. (Note that if A=1 and B=0 this reduces to X + Y + Z) Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Mon Nov 29 07:43:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28209; Mon, 29 Nov 1999 07:43:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16442 Mon, 29 Nov 1999 08:59:17 -0500 (EST) Message-ID: <011701bf372a$15705260$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPSec 2000 Date: Thu, 25 Nov 1999 10:47:18 +0100 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01BF3732.7200A2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0112_01BF3732.7200A2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPSec 2000 Global Summit: the international rendez-vous. A CFP is online = at: http://www.upperside.fr/baipsecy2k.htm ------=_NextPart_000_0112_01BF3732.7200A2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IPSec 2000 Global Summit: the = international=20 rendez-vous. A CFP is online at:
http://www.upperside.fr/b= aipsecy2k.htm
 
------=_NextPart_000_0112_01BF3732.7200A2C0-- From owner-ipsec@lists.tislabs.com Mon Nov 29 07:44:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28221; Mon, 29 Nov 1999 07:44:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16354 Mon, 29 Nov 1999 08:33:38 -0500 (EST) Message-Id: <199911291337.IAA19653@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-hash-revised-00.txt Date: Mon, 29 Nov 1999 08:37:00 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Fixing IKE Phase 1 Authentication HASH Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-hash-revised-00.txt Pages : 7 Date : 24-Nov-99 This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the generic ISAKMP [RFC-2408] header, nor does it authenticate any extra payloads inside phase 1 packets. This causes a security prob- lem when using extra payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). This document defines three methods how to negotiate the new HASH method. All methods tries to be backward compatible as much as possible. Only one of those methods must be selected by the working group and all the other should be removed from this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-hash-revised-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-hash-revised-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991124120422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-hash-revised-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991124120422.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 29 07:45:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28254; Mon, 29 Nov 1999 07:45:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16474 Mon, 29 Nov 1999 09:01:17 -0500 (EST) Message-ID: From: P A Centre Visitor Date: Sat, 27 Nov 1999 10:55:31 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, The 8th IEEE International Conference On Networks will be held from September 5- 8, 2000 in Singapore. The aim of the conference is to provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of computer and communication networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can be obtained at this web site : http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Best Regards Icon 2000 organizing Committee From owner-ipsec@lists.tislabs.com Mon Nov 29 09:35:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29762; Mon, 29 Nov 1999 09:35:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16454 Mon, 29 Nov 1999 09:00:18 -0500 (EST) Message-Id: <4.1.19991128223657.00a45e70@sj-email> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 28 Nov 1999 22:48:04 -0800 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: Alternate application for Jan 2000 Interoperability Workshop Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_2517222==_" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_2517222==_ Content-Type: text/plain; charset="us-ascii" The application for the January 2000 VPN Interoperability Workshop is available at http://www.calbug.org:8080/vpnworkshop/ For those of you who cannot access the site, the application is attached here as a Word document and also follows in this email. Please return the completed application to anfreema@cisco.com and the payment to bob@larribeau.com. Thanks, Anita ---------------------------------------------------------------------------- -------------------------------- Return your application via email and reserve your hotel rooms before December 15, 1999! To Networking Product Developers: Cisco invites you to participate in the VPN Interoperability Workshop, January 9-14, 2000, testing IPSec/IKE, L2TP, and PPP features at Paradise Point Resort in San Diego, California. The VPN Workshop combines the tenth CalBUG (formerly CIUG) PPP Interoperability Workshop and the eighth IPSec Interoperability Workshop. The Workshop will be open to companies with products that implement any of the following protocols: IP Security (IPSec) Internet Key Exchange (IKE) IKE-CFG IKE-XAUTH IP Payload Compression (IPComp) L2TP over Transport-Mode IPSec Compression Control Protocol (CCP) with MPPC and MPPE MS Challenge Handshake Authentication Protocol (MS CHAP) Version 2 Extensible Authentication Protocol (EAP) Point to Point Tunneling Protocol (PPTP) PPP over Ethernet (PPPoE) PPP over ATM L2TP over ATM L2TP The Workshop will provide an opportunity to test the interoperability of your products with products from all of the other companies attending. The participating companies are asked to bring products that are released, at beta or near beta level for the protocols being tested. Participants are engineering staff intimately familiar with the software and hardware that implement the capabilities being tested and are expected to have a thorough understanding of the protocols. This Workshop will be open to only the participants. This is not a spectator event; it is not open to observers. Some participants will be working with unreleased products and the other attendees are expected to respect their privacy. SPONSORSHIP: Cisco is the host for the VPN Interoperability Workshop. UUNET, an MCI Worldcom Company will provide the backbone Ethernet network and access to the Internet. Madge will provide ISDN lines and CalBUG (formerly CIUG) will provide infrastructure equipment for the workshop network. Cisco will provide an ATM switch for PPPoATM and L2TPoATM testing. SCHEDULE: Sunday, January 9, 2000 12:00 Noon to 8:00 PM Registration and equipment set up by Participants Monday, January 10, 2000 7:00 AM to 8:00 AM Continental Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon to 1:30 PM Lunch Tuesday, January 11, 2000 7:00 AM to 8:00 AM Continental Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon to 1:30 PM Lunch Wednesday, January 12, 2000 7:00 AM to 8:00 AM Continental Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon to 1:30 PM Lunch 4:00 PM to 5:00 PM Pizza 5:00 PM to 7:00 PM Group Meeting Thursday, January 13, 2000 7:00 AM to 8:00 AM Continental Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon to 1:30 PM Lunch Friday, January 14, 2000 7:00 AM to 8:00 AM Continental Breakfast 8:00 AM to 5:00 PM Testing 12:00 Noon to 1:30 PM Box Lunch 3:00 PM Break Down Facility FEES: The charge for the Workshop is $300 per person. The fee is for the entire week and covers the cost of the meals and hotel facility. Each person attending must pay the full amount. There will be no provision for a daily rate for those not attending the entire week. Checks, wire transfers, or credit cards will be accepted. Cash payments are not available. Payment must be received in advance. Refunds will not be made for cancellations after December 15, 1999. Please fill out and return the payment form with your payment. Companies not registered will not be allowed to walk-in. FACILITIES: Tables and Power: Each participating company will be provided one table, 5 Amps of power, and one power strip. Bring additional power strips if you need them. If you know your test setup will require more than 5 Amps please provide that information in advance on the application form and it will be available. Backbone Ethernet Network: Each participating company will be provided a single RJ-45 cable attached to the backbone Ethernet network. The backbone Ethernet network will be a set of public class C networks connected to the Internet via a router with all routes configured statically (no dynamic routing). In the application you will be asked to specify which of the following configurations you will need and the quantity. You may request multiple configurations but you must bring your own switches/hubs and a crossover cable with an RJ-45 to RJ-45 connector to attach more than a single device to the backbone Ethernet network. Configuration 1: A single IP address with a routed private network address. A single IP address assigned from the backbone Ethernet network (a public class C network) and a private class C network (to be assigned) with a static route configured in the backbone router to the single IP address. Configuration 2: A single IP address with a routed private and public network address. A single IP address assigned from the backbone Ethernet network (a public class C network) with a private class C network (to be assigned) and a public subnetwork (/29 subnet address to be assigned) with a static route for both networks configured in the backbone router to the single IP address. Note: You can not reach the Internet with private network addresses. If these configurations do not satisfy your requirements, please contact James Matheke at 614-723-1525 or jmatheke@wcom.net. File Transfer Servers: Servers will be available for file transfers as defined in the test procedures. CA Certificates: To arrange certificates with CA providers prior to the workshop, please go to the following for details. Baltimore: lisa@baltimore.ie Entrust: http://freecerts.entrust.com/ SSH (available in late December): http://isakmp-test.ssh.fi/ VeriSign(contact alex@verisign.com): https://onsite-test-fe.bbtest.net/bakeoff/ VPNC: paul.hoffman@vpnc.org ISDN Lines: BRI and PRI lines will be provided for testing from a Madge switch. The BRI lines will be provisioned as NI-1 with CSV/D on each B channel. The BRI lines may be either a U or S/T interface. If you request a PRI line, please bring a CSU and the crossover cable to terminate the T1 interface. The PRI lines will be NI-2. Telephone Service: There will be a telephone on each table in the workshop for voice service provided by a networked PBX. ATM Circuits: There will be an ATM switch with coax interfaces provided for testing PPP over ATM or L2TP over ATM. SHIPPING EQUIPMENT TO SAN DIEGO PARADISE POINT RESORT IN SAN DIEGO, CALIFORNIA Participants will be responsible for bringing workstations and network equipment. You may ship your equipment to: San Diego Paradise Point Resort 1404 W. Vacation Road San Diego, CA 92109 Telephone: 858-274-4630 Attention: Steve Hanger Please mark "Hold for Cisco VPN Workshop" Schedule your equipment to arrive at Paradise Point Resort between January 3-7, 2000. Please provide shipping information, such as date shipped, tracking number, and number of boxes to Paradise Point Resort so receipt of your shipment may be confirmed and accepted. IMPORTANT: Please bring the shipping documents for the return of your equipment back to your company. These documents include the carrier form. International shipments must include all appropriate documents, including carrier forms and invoices. Additionally, please make arrangements with your carrier in advance for pickup of your equipment at the Paradise Point Resort for no later than 5:00 PM on Friday, January 14, 2000. You will be responsible to see that your carrier picks up your equipment. These two points are very important. Neither Cisco nor the Paradise Point Resort will be able to provide shipping forms or customs forms to you. You have to bring your own. Also neither Cisco nor the Paradise Point Resort will be able to store your equipment past January 14, 2000. ACCOMMODATIONS: Be sure to reserve by December 15, 1999, to insure that rooms will be available for you and your group. The block of rooms is available at: San Diego Paradise Point Resort 1404 W. Vacation Road San Diego, CA 92109 Telephone: 858-274-4630 or 800-344-2626 Register under "Cisco VPN Workshop" to get the discounted Workshop rate of $140.00 plus tax per night. Rooms are available for check in January 9, 2000 through check out January 14, 2000. Check in time is 4:00 PM and check out time is 12:00 Noon. Should the attendee cancel the reservation within 48 hours of arrival, they are subject to billing of one night's room and tax. Should an attendee depart early from the original check out date, the attendee will be responsible for one night's room and tax. Available room upgrade options: Lanai single/double $140 Lanai Bayview $195 Studio Suite Garden $235 Studio Suite Bayside $265 One Bedroom Suite Garden $275 One Bedroom Suite Bayview $310 About San Diego Paradise Point Resort: http://www.paradisepoint.com/ Airport Access: Airline service is available to Lindbergh International Airport, San Diego, California, USA (SAN). Alternately, you may fly to Los Angeles (LAX), California and drive approximately two hours to San Diego. Directions from Lindbergh International Airport: Take Harbor Drive North and turn right on Nimitz, follow signs to Mission Bay Park. Right on Ingraham, left at West Vacation Road. You can take Cloud 9 Shuttle 1-800-9-SHUTTLE from the airport to the hotel for transportation to the hotel for $8.00. From Terminal 1 or Terminal 2 follow the signs to the Ground Transportation Skybridge, proceed to the "Shuttle for Hire" curb and ask the "Transportation Coordinator" for Cloud 9 Shuttle. From the Commuter terminal exit the doors, cross over to the shuttle loading island, and ask the "Transportation Coordinator" for Cloud 9 Shuttle. SECURITY: An outside security company has been retained from 8:00 PM until 8:00 AM from January 8-14, 2000. There will be a sign-up procedure for participants wishing to work after 8:00 PM Those wishing to work after 8:00 PM must be present at 8:00 PM for introductions to the security staff of the evening. PRESS RELEASE: Cisco plans to make a press release following the workshop. There will be no mention of any specific results of the testing in this release. Please indicate in the application if you want your company's name included in this release as a participant. If you include your public relations person in the application, that contact will be given the opportunity to review the release in advance. REGISTRATION: This will be a "self organizing" event. It will be your responsibility to develop your own test schedule and to arrange your own testing partners. This method has worked well in the past and we believe that it provides the most productive environment for testing. In the application you will be asked to list the days you will be available for testing. Please be accurate so everyone has an opportunity to test with you. Please fill out the Product Section of the application carefully defining the supported capability list for the protocol options you will test at the workshop. We will use the information to put together a binder of data to assist when you are testing with partners. To register for the VPN Interoperability Workshop fill out the payment form and return it by email to . Then fill out the application on this Web site immediately to reserve your place at the workshop. If you have any questions, send email or call Bob Larribeau, bob@larribeau.com, 415-241-9920 Based on past workshops, expected attendance is 60 companies. Get the payment form and application in early to assure yourself a place. ------------------------------ PAYMENT FORM---------------------------- PLEASE RETURN THIS PAYMENT FORM VIA EMAIL. Name: __________________________________ Company: _______________________________ Address: _________________________________ __________________________________________ City, State, Zip ________________________________ Country: _____________________________________ Phone: _________________________________ Fax: ___________________________________ Email: _________________________________ Number of Attendees: _________ x $300.00 = Total Payment $_____________ Refunds will not be made for cancellations after December 15, 1999. Pay by credit card: Fill out the form below and fax it to the CalBUG at (415) 753-6942. Credit Card Type (Circle One): American Express, Visa, Master Charge, JCB Credit Card Number: ______________________________ Expiration Date: _________________________________ Name: ____________________________________________ Signature: _______________________________________ Pay by check: Send a check made out to the CalBUG for $300 for each participant to: California Broadband User's Group, PO Box 27901-391, San Francisco, CA 94127 Wire funds to: California Broadband Users' Group Account Number 02882 07752 Bank of America #0288 288 West Portal Avenue, San Francisco, CA 94127 USA ----------------------------------------------------------------------- APPLICATION PLEASE FILL OUT THIS APPLICATION ON THE WEB SITE Please enter the name of the Workshop Coordinator who will coordinate your registration. We will send emails to this person to give the latest information on the workshop and to verify your registration. Company Name: __________________________ Name: __________________________________ Address: _________________________________ __________________________________________ City, State, Zip ________________________________ Country: _____________________________________ Phone: _________________________________ Fax: ___________________________________ Email: _________________________________ Do you want your company's name included in the Cisco press release as a participant? Yes or No Provide the name, address, phone, fax, and email of your public relations contact. We will give this person an opportunity to review the release in advance. Names of ALL Participants (including the Workshop Coordinator listed above if they will attend): Name_____________________ Name_____________________ Name_____________________ Days available for testing: M Tu W Th F Number of tables: ---------------------------------------------------------------------- IP Addresses- Number of Configuration 1: (a single IP address with a routed private network address) Number of Configuration 2: (A single IP address with a routed private and public network address) Additional Power Requirements: Number of BRI lines: 1 2 More than 2 (please specify) S/T or U interface: PRI (Yes or No): Additional Madge Switch Requirements: ATM PVC (PPP): 1 2 More than 2 (please specify) ATM PVC (L2TP): 1 2 More than 2 (please specifiy) ---------------------------------------------------------------------- Features you will be TESTING: IPSec (Y/N) IKE (Y/N) IKE-CFG IKE-XAUTH IP Payload Compression (Y/N) L2TP over Transport-Mode IPSec (Y/N) CCP with MPPC (Y/N) CCP with MPPE (Y/N) MS CHAP Version 2 (Y/N) EAP (Y/N) PPTP (Y/N) PPP over Ethernet (PPPoE) (Y/N) PPP over ATM (Y/N) L2TP over ATM (Y/N) L2TP (Y/N) ---------------------------------------------------------------------- Will you be providing: CA services (Y/N) ----------------------------------------------------------------------- Product Functionality Section: The purpose of this survey is to identify supported features so that vendors will know who is implementing what, can know who to discuss the detailed functionality with, and to identify products for more serious compatibility testing later. Fill out a Product Section to describe supported features for each device or software package you will have at the workshop. If the version is unreleased, indicate 'alpha', 'beta', RC (release candidate) or build number. Options marked with * are advanced features. --- 1--- Product Name: Software Version and OS compatibility: Product Type, check all that apply: Router_____ Firewall_____ IPSec Gateway_____ IPSec Client_____ L2TP/IPsec Client Software_____ End to End (Tunnel/Transport) Client_____ Other________________________ --- 2--- Product Name: Software Version and OS compatibility: Product Type, check all that apply: Router_____ Firewall_____ IPSec Gateway_____ IPSec Client_____ L2TP/IPsec Client Software_____ End to End (Tunnel/Transport) Client_____ Other________________________ --- 3--- Product Name: Software Version and OS compatibility: Product Type, check all that apply: Router_____ Firewall_____ IPSec Gateway_____ IPSec Client_____ L2TP/IPsec Client Software_____ End to End (Tunnel/Transport) Client_____ Other________________________ =====IPSEC=====IPSEC=====IPSEC=====IPSEC===== IPSec manual keys SA configuration (keys, SPI, algorithms) (Y/N) Minimum key length (Y/N) If yes, key length________________ AH tunnel (Y/N) AH transport (Y/N) ESP tunnel (Y/N) ESP transport (Y/N) Transport adjacency: applying more than one security protocol to the same IP datagram, without invoking tunneling, eg. [IP][AH][ESP][packet payload] (Y/N) Nested tunneling from the same box: "Tunneling IPSec in an IPSec tunnel", eg. [IP][IPSec][IP][IPSec][packet payload] where "[IPSec]" could be "[ESP]" or "[AH]" or "[AH][ESP]" and where "[packet payload]" could be a ULP or another entire IP datagram. (Y/N) Iterated tunneling on same box: "Terminate a tunnel on one interface and forward the packets out on a different tunnel on a different interface" (Y/N) ESP cipher algorithms- DES-CBC (Y/N) 3DES (Y/N) NULL encryption (Y/N) *RC5 (Y/N) *CAST (Y/N) *Blowfish (Y/N) *IDEA (Y/N) *DES-X (Y/N) ESP authenticators- HMAC-MD-5 (Y/N) HMAC-SHA-1 (Y/N) *HMAC RIPEMD-160 (Y/N) AH algorithms- HMAC-MD-5 (Y/N) HMAC-SHA-1 (Y/N) *HMAC RIPEMD-160 (Y/N) *IPP Compression Protocol- LZS (Y/N) DEFLATE (Y/N) =====IKE=====IKE=====IKE=====IKE===== IKE===== IKE Exchanges- Main/Quick mode (identity protect) (Y/N) *Aggressive mode (Y/N) *IKE Config (Y/N) *XAUTH (Y/N) *DHCP Inform for internal tunnel config (Y/N) *New Group Mode (Y/N) IKE Authentication methods- Preshared keys (Y/N) Minimum length (Y/N) If yes, length_____________ *RSA signature (Y/N) *DSS signature (Y/N) *RSA Encryption (Y/N) *Revised RSA encryption (Y/N) *GSSAPI-Kerberos v5 (Y/N) *Base Mode (Y/N) IKE Key Material- Groups supported (1,2,3,4,5,others)__________ *Elliptic Curve Groups_____________ *DH-less IKE_________ Main mode PFS (1 MM per quick mode) (Y/N) Quick mode PFS (Y/N) Minimum quickmode lifetime (bytes/secs)_________ IKE Encryption algorithms- DES (Y/N) 3DES (Y/N) CAST (Y/N) RC5 (Y/N) Blowfish (Y/N) IDEA (Y/N) Other__________________ IKE Hash algorithms- MD-5 (Y/N) SHA-1 (Y/N) *HMAC RIPEMD-160 optional (Y/N) IKE Certificates- *IKE Certificate Validation (Y/N) Validate subject name against IPSec policy data (Y/N) Normal operation requires on-line access to CA for enrollment (Y/N) Certificate Request Payload (Reqd/Optional/Not Used and Ignored)______________ *Certificate chains in band, means exchanged in IKE (Y/N) CRL support (Reqd/Optional/ None)___________ CRL retrieval mechanism (http, file, LDAP)______________ Normal operation (Reqd/Optional/ Don’t Care and Not Used) on-line access to CRL distribution point __________________ IKE Optional payloads---------------- *IKE Cert types - CERT (Y/N) CRL (Y/N) ARL (Y/N) PKCS7 (Y/N) Certificate signature algorithms supported (MD5, SHA1, etc)__________ IPSec only certificate key usage (Reqd/Optional/Don't Care)___________ Other certificate restrictions______________ *IKE Cert request types - CERT (Y/N) CRL (Y/N) ARL (Y/N) PKCS7 (Y/N) IKE Other Options- *Vendor-ID (Y/N) *Commit bit (Y/N) *Use quick mode lifetime notifies (Y/N) *Use Initial Contact (Y/N) *Send delete payload for quickmode SAs (Y/N) *Send delete payload for main mode SAs (Y/N) *CA Interoperability Issues- *RFC2510 (Y/N) *PKCS 10/7 (Y/N) *PKCS #12 (Y/N) Manual certificate enrollment (Y/N) *Level of CA hierarchies supported (number levels/No)___________ *Support certs issued by a subordinate CA, which is a child of a different vendor CA (cross certification) (Y/N) CMC (Y/N) PKIX-CMP (Y/N) CEP (Y/N) CRS (Y/N) For IPComp (RFC 2393)--------------------------------------------------------- Compression algorithms- DEFLATE - RFC 2394 (Y/N) LZS-RFC 2395 (Y/N) Negotiation mechanism- IKE (Y/N) Manually-configured (Y/N) Negotiated with- ESP/AH (Y/N) Standalone (Y/N) =====PPP=====PPP=====PPP=====PPP===== PPP===== LCP Options: Default MRU__________________________ Default MRRU_________________________ Authentication: CHAP authenticator (Y/N) CHAP authenticatee (Y/N) CHAP Re-challenge (Y/N) MS CHAP (Y/N) MS CHAP V2 (Y/N) Compression: STAC (Y/N) STAC DCP (Y/N) STAC Options _________ MPPC (Y/N) MPPE (Y/N) WCP (Y/N) Predictor (Y/N) Other__________________ IPCP: Numbered links (Y/N) Un-numbered links (Y/N) Tx if Un-numbered____________ Options supported____________ IP assignment (Y/N) IP Pool (Y/N) DHCP (Y/N) IPXCP: Numbered links (Y/N) Un-numbered links (Y/N) Tx if Un-numbered____________ Options supported____________ =====L2TP=====L2TP=====L2TP=====L2TP=====L2TP= Provide LAC (Y/N) Provide LNS (Y/N) Provide L2TP Client (Y/N) L2TP Access Concentrator (LAC) Options: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Sequencing (Y/N) L2TP secured by IPSec (Reqd/Optional/No)___________ If yes, IKE authentication using identity protect or aggressive mode__________ If yes, IKE authentication using (machine/user/other) credential___________ If yes, IKE authentication (pre-shared key only/certs only/both/other)__________ L2TP Network Server (LNS) Options: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Sequencing (Y/N) MP (bundle tunneled links) (Y/N) ECP (Y/N) CCP (Y/N) Algorithms______________________________ CBCP (Y/N) L2TP secured by IPSec (Reqd/Optional/No)___________ If yes, IKE authentication using identity protect or aggressive mode__________ If yes, IKE authentication using (machine/user/other) credential___________ If yes, IKE authentication (pre-shared key only/certs only/both/other)__________ Tunnel Types- Voluntary (Y/N) Compulsory (Y/N) Client L2TP Options: Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Sequencing (Y/N) L2TP secured by IPSec (Reqd/Optional/No)___________ If yes, IKE authentication using identity protect or aggressive mode__________ If yes, IKE authentication using (machine/user/other) credential___________ If yes, IKE authentication (pre-shared key only/certs only/both/other)__________ =====PPTP=====PPTP=====PPTP=====PPTP=====PPTP= PAC (Y/N) PNS (Y/N) PPTP Client (Y/N) PPTP Options - PAC: Outgoing calls (Y/N) Incoming calls (Y/N) PPTP secured by IPSec (Reqd/Optional/No)___________ Ring-time tunnel (Y/N) Username-based tunnel (Y/N) PPTP Options - PNS: Outgoing calls (Y/N) Incoming calls (Y/N) MP (bundle tunneled links) (Y/N) MPPE (Y/N) CCP (Y/N) Algorithms______________ PPTP secured by IPSec (Reqd/Optional/No)___________ Tunnel types - Voluntary (Y/N) Compulsory (Y/N) PPTP Options - Client: MPPE (Y/N) CCP (Y/N) Algorithms______________ PPTP secured by IPSec (Reqd/Optional/No)___________ =====EAP=====EAP=====EAP =====EAP ===== EAP== Identity (Y/N) Number of retries__________ Notification (Y/N) Nak (response only) (Y/N) MD5-Challenge (Y/N) S/Key (RFC 1760) (Y/N) Generic Token Card (Y/N) RADIUS EAP-Proxy (Y/N) Other________________________ =====PPPoE===== PPPoE ===== PPPoE ===== PPPoE == Client: Can select from multiple services (Y/N) AC-Cookie Tag (Y/N) Host-Uniq Tag (Y/N) Relay-Session-Id (Y/N) PPPoE Active Discovery Terminate (PADT) packet (Y/N) Server: Can offer multiple services (Y/N) AC-Cookie Tag (Y/N) Host-Uniq Tag (Y/N) Relay-Session-Id (Y/N) PPPoE Active Discovery Terminate (PADT) packet (Y/N) --=====================_2517222==_ Content-Type: application/msword; name="Jan2000IPSEC_PPP_application.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Jan2000IPSEC_PPP_application.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAgAAAAAAAAAAA EAAAggAAAAEAAAD+////AAAAAH4AAAB/AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAACBK/AAAAAAAAEAAAAAAABAAAG2QAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAJbgAABZBAQAWQQEAG2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAADIBAAAAAAAAMgEAADIB AAAAAAAAMgEAAAAAAAAyAQAAAAAAADIBAAAAAAAAMgEAABQAAAAAAAAAAAAAAEYBAAAAAAAARgEA AAAAAABGAQAAAAAAAEYBAAAAAAAARgEAAAwAAABSAQAA/AAAAEYBAAAAAAAAxAwAALYAAACaAgAA OgAAANQCAAAAAAAA1AIAAAAAAADUAgAAAAAAANQCAAAAAAAA1AIAAFoAAAAuAwAAHAAAAEoDAAAQ AAAAiQwAAAIAAACLDAAAAAAAAIsMAAAAAAAAiwwAAAAAAACLDAAAAAAAAIsMAAAAAAAAiwwAACQA AAB6DQAA9AEAAG4PAAA4AQAArwwAABUAAAAAAAAAAAAAAAAAAAAAAAAAMgEAAAAAAABaAwAAAAAA AAAAAAAAAAAAAAAAAAAAAADUAgAAAAAAANQCAAAAAAAAWgMAAAAAAABaAwAAAAAAAK8MAAAAAAAA QgUAAAAAAAAyAQAAAAAAADIBAAAAAAAA1AIAAAAAAAAAAAAAAAAAANQCAAAAAAAAmgIAAAAAAABC BQAAAAAAAEIFAAAAAAAAQgUAAAAAAABaAwAAmgAAADIBAAAAAAAA1AIAAAAAAAAyAQAAAAAAANQC AAAAAAAAiQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAARgEAAAAAAABGAQAAAAAAADIBAAAAAAAAMgEA AAAAAAAyAQAAAAAAADIBAAAAAAAAWgMAAAAAAACJDAAAAAAAAEIFAADOBgAAQgUAAAAAAAAQDAAA HgAAAGkMAAAYAAAAMgEAAAAAAAAyAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiQwAAAAAAADUAgAAAAAAAE4CAABMAAAAQOnn9jM6 vwFGAQAAAAAAAEYBAAAAAAAA9AMAAE4BAACBDAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA1SZXR1cm4g eW91ciBhcHBsaWNhdGlvbiB2aWEgZW1haWwgYW5kIHJlc2VydmUgeW91ciBob3RlbCByb29tcyBi ZWZvcmUgRGVjZW1iZXIgMTUsIDE5OTkhIA0NVG8gTmV0d29ya2luZyBQcm9kdWN0IERldmVsb3Bl cnM6IA0NQ2lzY28gaW52aXRlcyB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIFZQTiBJbnRlcm9w ZXJhYmlsaXR5IFdvcmtzaG9wLCBKYW51YXJ5IDktMTQsIDIwMDAsIHRlc3RpbmcgSVBTZWMvSUtF LCBMMlRQLCBhbmQgUFBQIGZlYXR1cmVzIGF0IFBhcmFkaXNlIFBvaW50IFJlc29ydCBpbiBTYW4g RGllZ28sIENhbGlmb3JuaWEuICBUaGUgVlBOIFdvcmtzaG9wIGNvbWJpbmVzIHRoZSB0ZW50aCBD YWxCVUcgKGZvcm1lcmx5IENJVUcpIFBQUCBJbnRlcm9wZXJhYmlsaXR5IFdvcmtzaG9wIGFuZCB0 aGUgZWlnaHRoIElQU2VjIEludGVyb3BlcmFiaWxpdHkgV29ya3Nob3AuIA0NVGhlIFdvcmtzaG9w IHdpbGwgYmUgb3BlbiB0byBjb21wYW5pZXMgd2l0aCBwcm9kdWN0cyB0aGF0IGltcGxlbWVudCBh bnkgb2YgdGhlIGZvbGxvd2luZyBwcm90b2NvbHM6IA0NSVAgU2VjdXJpdHkgKElQU2VjKQ1JbnRl cm5ldCBLZXkgRXhjaGFuZ2UgKElLRSkNSUtFLUNGRw1JS0UtWEFVVEgNSVAgUGF5bG9hZCBDb21w cmVzc2lvbiAoSVBDb21wKQ1MMlRQIG92ZXIgVHJhbnNwb3J0LU1vZGUgSVBTZWMNQ29tcHJlc3Np b24gQ29udHJvbCBQcm90b2NvbCAoQ0NQKSB3aXRoIE1QUEMgYW5kIE1QUEUNTVMgQ2hhbGxlbmdl IEhhbmRzaGFrZSBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoTVMgQ0hBUCkgVmVyc2lvbiAyDUV4 dGVuc2libGUgQXV0aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkNUG9pbnQgdG8gUG9pbnQgVHVu bmVsaW5nIFByb3RvY29sIChQUFRQKQ1QUFAgb3ZlciBFdGhlcm5ldCAoUFBQb0UpDVBQUCBvdmVy IEFUTQ1MMlRQIG92ZXIgQVRNDUwyVFANDVRoZSBXb3Jrc2hvcCB3aWxsIHByb3ZpZGUgYW4gb3Bw b3J0dW5pdHkgdG8gdGVzdCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiB5b3VyIHByb2R1Y3RzIHdp dGggcHJvZHVjdHMgZnJvbSBhbGwgb2YgdGhlIG90aGVyIGNvbXBhbmllcyBhdHRlbmRpbmcuIA0N VGhlIHBhcnRpY2lwYXRpbmcgY29tcGFuaWVzIGFyZSBhc2tlZCB0byBicmluZyBwcm9kdWN0cyB0 aGF0IGFyZSByZWxlYXNlZCwgYXQgYmV0YSBvciBuZWFyIGJldGEgbGV2ZWwgZm9yIHRoZSBwcm90 b2NvbHMgYmVpbmcgdGVzdGVkLiANDVBhcnRpY2lwYW50cyBhcmUgZW5naW5lZXJpbmcgc3RhZmYg aW50aW1hdGVseSBmYW1pbGlhciB3aXRoIHRoZSBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgdGhhdCBp bXBsZW1lbnQgdGhlIGNhcGFiaWxpdGllcyBiZWluZyB0ZXN0ZWQgYW5kIGFyZSBleHBlY3RlZCB0 byBoYXZlIGEgdGhvcm91Z2ggdW5kZXJzdGFuZGluZyBvZiB0aGUgcHJvdG9jb2xzLiANDVRoaXMg V29ya3Nob3Agd2lsbCBiZSBvcGVuIHRvIG9ubHkgdGhlIHBhcnRpY2lwYW50cy4gVGhpcyBpcyBu b3QgYSBzcGVjdGF0b3IgZXZlbnQ7IGl0IGlzIG5vdCBvcGVuIHRvIG9ic2VydmVycy4gU29tZSBw YXJ0aWNpcGFudHMgd2lsbCBiZSB3b3JraW5nIHdpdGggdW5yZWxlYXNlZCBwcm9kdWN0cyBhbmQg dGhlIG90aGVyIGF0dGVuZGVlcyBhcmUgZXhwZWN0ZWQgdG8gcmVzcGVjdCB0aGVpciBwcml2YWN5 LiANDVNQT05TT1JTSElQOiANDUNpc2NvIGlzIHRoZSBob3N0IGZvciB0aGUgVlBOIEludGVyb3Bl cmFiaWxpdHkgV29ya3Nob3AuICBVVU5FVCwgYW4gTUNJIFdvcmxkY29tIENvbXBhbnkgd2lsbCBw cm92aWRlIHRoZSBiYWNrYm9uZSBFdGhlcm5ldCBuZXR3b3JrIGFuZCBhY2Nlc3MgdG8gdGhlIElu dGVybmV0LiAgTWFkZ2Ugd2lsbCBwcm92aWRlIElTRE4gbGluZXMgYW5kIENhbEJVRyAoZm9ybWVy bHkgQ0lVRykgd2lsbCBwcm92aWRlIGluZnJhc3RydWN0dXJlIGVxdWlwbWVudCBmb3IgdGhlIHdv cmtzaG9wIG5ldHdvcmsuICBDaXNjbyB3aWxsIHByb3ZpZGUgYW4gQVRNIHN3aXRjaCBmb3IgUFBQ b0FUTSBhbmQgTDJUUG9BVE0gdGVzdGluZy4gDQ0NU0NIRURVTEU6IA0NU3VuZGF5LCBKYW51YXJ5 IDksIDIwMDANDTEyOjAwIE5vb24gdG8gODowMCBQTSAJUmVnaXN0cmF0aW9uIGFuZCBlcXVpcG1l bnQgc2V0IHVwIGJ5IFBhcnRpY2lwYW50cw0NTW9uZGF5LCBKYW51YXJ5IDEwLCAyMDAwDQ03OjAw IEFNIHRvIDg6MDAgQU0gCQlDb250aW5lbnRhbCBCcmVha2Zhc3QNODowMCBBTSB0byA4OjAwIFBN CQlUZXN0aW5nIA0xMjowMCBOb29uIHRvIDE6MzAgUE0JTHVuY2gNDVR1ZXNkYXksIEphbnVhcnkg MTEsIDIwMDANDTc6MDAgQU0gdG8gODowMCBBTSAJCUNvbnRpbmVudGFsIEJyZWFrZmFzdA04OjAw IEFNIHRvIDg6MDAgUE0gCQlUZXN0aW5nDTEyOjAwIE5vb24gdG8gMTozMCBQTQlMdW5jaA0NV2Vk bmVzZGF5LCBKYW51YXJ5IDEyLCAyMDAwDQ03OjAwIEFNIHRvIDg6MDAgQU0gCQlDb250aW5lbnRh bCBCcmVha2Zhc3QNODowMCBBTSB0byA4OjAwIFBNIAkJVGVzdGluZw0xMjowMCBOb29uIHRvIDE6 MzAgUE0JTHVuY2gNNDowMCBQTSB0byA1OjAwIFBNIAkJUGl6emEgIA01OjAwIFBNIHRvIDc6MDAg UE0JCUdyb3VwIE1lZXRpbmcgDQ1UaHVyc2RheSwgSmFudWFyeSAxMywgMjAwMA0NNzowMCBBTSB0 byA4OjAwIEFNIAkJQ29udGluZW50YWwgQnJlYWtmYXN0DTg6MDAgQU0gdG8gODowMCBQTSAJCVRl c3RpbmcNMTI6MDAgTm9vbiB0byAxOjMwIFBNCUx1bmNoDQ1GcmlkYXksIEphbnVhcnkgMTQsIDIw MDANDTc6MDAgQU0gdG8gODowMCBBTSAJCUNvbnRpbmVudGFsIEJyZWFrZmFzdA04OjAwIEFNIHRv IDU6MDAgUE0gCQlUZXN0aW5nDTEyOjAwIE5vb24gdG8gMTozMCBQTQlCb3ggTHVuY2gNMzowMCBQ TSAJCQlCcmVhayBEb3duIEZhY2lsaXR5IA0NDUZFRVM6IA0NVGhlIGNoYXJnZSBmb3IgdGhlIFdv cmtzaG9wIGlzICQzMDAgcGVyIHBlcnNvbi4gIFRoZSBmZWUgaXMgZm9yIHRoZSBlbnRpcmUgd2Vl ayBhbmQgY292ZXJzIHRoZSBjb3N0IG9mIHRoZSBtZWFscyBhbmQgaG90ZWwgZmFjaWxpdHkuIEVh Y2ggcGVyc29uIGF0dGVuZGluZyBtdXN0IHBheSB0aGUgZnVsbCBhbW91bnQuIFRoZXJlIHdpbGwg YmUgbm8gcHJvdmlzaW9uIGZvciBhIGRhaWx5IHJhdGUgZm9yIHRob3NlIG5vdCBhdHRlbmRpbmcg dGhlIGVudGlyZSB3ZWVrLiBDaGVja3MsIHdpcmUgdHJhbnNmZXJzLCBvciBjcmVkaXQgY2FyZHMg d2lsbCBiZSBhY2NlcHRlZC4gQ2FzaCBwYXltZW50cyBhcmUgbm90IGF2YWlsYWJsZS4gUGF5bWVu dCBtdXN0IGJlIHJlY2VpdmVkIGluIGFkdmFuY2UuICAgUmVmdW5kcyB3aWxsIG5vdCBiZSBtYWRl IGZvciBjYW5jZWxsYXRpb25zIGFmdGVyIERlY2VtYmVyIDE1LCAxOTk5LiAgUGxlYXNlIGZpbGwg b3V0IGFuZCByZXR1cm4gdGhlIHBheW1lbnQgZm9ybSB3aXRoIHlvdXIgcGF5bWVudC4gIENvbXBh bmllcyBub3QgcmVnaXN0ZXJlZCB3aWxsIG5vdCBiZSBhbGxvd2VkIHRvIHdhbGstaW4uDQ1GQUNJ TElUSUVTOiANDVRhYmxlcyBhbmQgUG93ZXI6DQ1FYWNoIHBhcnRpY2lwYXRpbmcgY29tcGFueSB3 aWxsIGJlIHByb3ZpZGVkIG9uZSB0YWJsZSwgNSBBbXBzIG9mIHBvd2VyLCBhbmQgb25lIHBvd2Vy IHN0cmlwLiBCcmluZyBhZGRpdGlvbmFsIHBvd2VyIHN0cmlwcyBpZiB5b3UgbmVlZCB0aGVtLiBJ ZiB5b3Uga25vdyB5b3VyIHRlc3Qgc2V0dXAgd2lsbCByZXF1aXJlIG1vcmUgdGhhbiA1IEFtcHMg cGxlYXNlIHByb3ZpZGUgdGhhdCBpbmZvcm1hdGlvbiBpbiBhZHZhbmNlIG9uIHRoZSBhcHBsaWNh dGlvbiBmb3JtIGFuZCBpdCB3aWxsIGJlIGF2YWlsYWJsZS4NDUJhY2tib25lIEV0aGVybmV0IE5l dHdvcms6IA0NRWFjaCBwYXJ0aWNpcGF0aW5nIGNvbXBhbnkgd2lsbCBiZSBwcm92aWRlZCBhIHNp bmdsZSBSSi00NSBjYWJsZSBhdHRhY2hlZCB0byB0aGUgYmFja2JvbmUgRXRoZXJuZXQgbmV0d29y ay4gVGhlIGJhY2tib25lIEV0aGVybmV0IG5ldHdvcmsgd2lsbCBiZSBhIHNldCBvZiBwdWJsaWMg Y2xhc3MgQyBuZXR3b3JrcyBjb25uZWN0ZWQgdG8gdGhlIEludGVybmV0IHZpYSBhIHJvdXRlciB3 aXRoIGFsbCByb3V0ZXMgY29uZmlndXJlZCBzdGF0aWNhbGx5IChubyBkeW5hbWljIHJvdXRpbmcp Lg0NSW4gdGhlIGFwcGxpY2F0aW9uIHlvdSB3aWxsIGJlIGFza2VkIHRvIHNwZWNpZnkgd2hpY2gg b2YgdGhlIGZvbGxvd2luZyBjb25maWd1cmF0aW9ucyB5b3Ugd2lsbCBuZWVkIGFuZCB0aGUgcXVh bnRpdHkuIFlvdSBtYXkgcmVxdWVzdCBtdWx0aXBsZSBjb25maWd1cmF0aW9ucyBidXQgeW91IG11 c3QgYnJpbmcgeW91ciBvd24gc3dpdGNoZXMvaHVicyBhbmQgYSBjcm9zc292ZXIgY2FibGUgd2l0 aCBhbiBSSi00NSB0byBSSi00NSBjb25uZWN0b3IgdG8gYXR0YWNoIG1vcmUgdGhhbiBhIHNpbmds ZSBkZXZpY2UgdG8gdGhlIGJhY2tib25lIEV0aGVybmV0IG5ldHdvcmsuIA0NQ29uZmlndXJhdGlv biAxOiBBIHNpbmdsZSBJUCBhZGRyZXNzIHdpdGggYSByb3V0ZWQgcHJpdmF0ZSBuZXR3b3JrIGFk ZHJlc3MuDQ1BIHNpbmdsZSBJUCBhZGRyZXNzIGFzc2lnbmVkIGZyb20gdGhlIGJhY2tib25lIEV0 aGVybmV0IG5ldHdvcmsgKGEgcHVibGljIGNsYXNzIEMgbmV0d29yaykgYW5kIGEgcHJpdmF0ZSBj bGFzcyBDIG5ldHdvcmsgKHRvIGJlIGFzc2lnbmVkKSB3aXRoIGEgc3RhdGljIHJvdXRlIGNvbmZp Z3VyZWQgaW4gdGhlIGJhY2tib25lIHJvdXRlciB0byB0aGUgc2luZ2xlIElQIGFkZHJlc3MuDQ1D b25maWd1cmF0aW9uIDI6IEEgc2luZ2xlIElQIGFkZHJlc3Mgd2l0aCBhIHJvdXRlZCBwcml2YXRl IGFuZCBwdWJsaWMgbmV0d29yayBhZGRyZXNzLg0NQSBzaW5nbGUgSVAgYWRkcmVzcyBhc3NpZ25l ZCBmcm9tIHRoZSBiYWNrYm9uZSBFdGhlcm5ldCBuZXR3b3JrIChhIHB1YmxpYyBjbGFzcyBDIG5l dHdvcmspIHdpdGggYSBwcml2YXRlIGNsYXNzIEMgbmV0d29yayAodG8gYmUgYXNzaWduZWQpIGFu ZCBhIHB1YmxpYyBzdWJuZXR3b3JrICgvMjkgc3VibmV0IGFkZHJlc3MgdG8gYmUgYXNzaWduZWQp IHdpdGggYSBzdGF0aWMgcm91dGUgZm9yIGJvdGggbmV0d29ya3MgY29uZmlndXJlZCBpbiB0aGUg YmFja2JvbmUgcm91dGVyIHRvIHRoZSBzaW5nbGUgSVAgYWRkcmVzcy4NDU5vdGU6IFlvdSBjYW4g bm90IHJlYWNoIHRoZSBJbnRlcm5ldCB3aXRoIHByaXZhdGUgbmV0d29yayBhZGRyZXNzZXMuIElm IHRoZXNlIGNvbmZpZ3VyYXRpb25zIGRvIG5vdCBzYXRpc2Z5IHlvdXIgcmVxdWlyZW1lbnRzLCBw bGVhc2UgY29udGFjdCBKYW1lcyBNYXRoZWtlIGF0IDYxNC03MjMtMTUyNSBvciBqbWF0aGVrZUB3 Y29tLm5ldC4NDUZpbGUgVHJhbnNmZXIgU2VydmVyczogU2VydmVycyB3aWxsIGJlIGF2YWlsYWJs ZSBmb3IgZmlsZSB0cmFuc2ZlcnMgYXMgZGVmaW5lZCBpbiB0aGUgdGVzdCBwcm9jZWR1cmVzLg0N Q0EgQ2VydGlmaWNhdGVzOiBUbyBhcnJhbmdlIGNlcnRpZmljYXRlcyB3aXRoIENBIHByb3ZpZGVy cyBwcmlvciB0byB0aGUgd29ya3Nob3AsIHBsZWFzZSBnbyB0byB0aGUgZm9sbG93aW5nIGZvciBk ZXRhaWxzLg0NCUJhbHRpbW9yZTogbGlzYUBiYWx0aW1vcmUuaWUNCUVudHJ1c3Q6IGh0dHA6Ly9m cmVlY2VydHMuZW50cnVzdC5jb20vDQlTU0ggKGF2YWlsYWJsZSBpbiBsYXRlIERlY2VtYmVyKTog aHR0cDovL2lzYWttcC10ZXN0LnNzaC5maS8NCVZlcmlTaWduKGNvbnRhY3QgYWxleEB2ZXJpc2ln bi5jb20pOiATIEhZUEVSTElOSyBodHRwczovL29uc2l0ZS10ZXN0LWZlLmJidGVzdC5uZXQvYmFr ZW9mZi8gARRodHRwczovL29uc2l0ZS10ZXN0LWZlLmJidGVzdC5uZXQvYmFrZW9mZi8VDSAJVlBO QzogEyBIWVBFUkxJTksgbWFpbHRvOnBhdWwuaG9mZm1hbkB2cG5jLm9yZyABFHBhdWwuaG9mZm1h bkB2cG5jLm9yZxUNDUlTRE4gTGluZXM6IEJSSSBhbmQgUFJJIGxpbmVzIHdpbGwgYmUgcHJvdmlk ZWQgZm9yIHRlc3RpbmcgZnJvbSBhIE1hZGdlIHN3aXRjaC4gIFRoZSBCUkkgbGluZXMgd2lsbCBi ZSBwcm92aXNpb25lZCBhcyBOSS0xIHdpdGggQ1NWL0Qgb24gZWFjaCBCIGNoYW5uZWwuICBUaGUg QlJJIGxpbmVzIG1heSBiZSBlaXRoZXIgYSBVIG9yIFMvVCBpbnRlcmZhY2UuIElmIHlvdSByZXF1 ZXN0IGEgUFJJIGxpbmUsIHBsZWFzZSBicmluZyBhIENTVSBhbmQgdGhlIGNyb3Nzb3ZlciBjYWJs ZSB0byB0ZXJtaW5hdGUgdGhlIFQxIGludGVyZmFjZS4gVGhlIFBSSSBsaW5lcyB3aWxsIGJlIE5J LTIuIA0NVGVsZXBob25lIFNlcnZpY2U6IFRoZXJlIHdpbGwgYmUgYSB0ZWxlcGhvbmUgb24gZWFj aCB0YWJsZSBpbiB0aGUgd29ya3Nob3AgZm9yIHZvaWNlIHNlcnZpY2UgcHJvdmlkZWQgYnkgYSBu ZXR3b3JrZWQgUEJYLg0NQVRNIENpcmN1aXRzOiBUaGVyZSB3aWxsIGJlIGFuIEFUTSBzd2l0Y2gg d2l0aCBjb2F4IGludGVyZmFjZXMgcHJvdmlkZWQgZm9yIHRlc3RpbmcgUFBQIG92ZXIgQVRNIG9y IEwyVFAgb3ZlciBBVE0uDQ1TSElQUElORyBFUVVJUE1FTlQgVE8gU0FOIERJRUdPIFBBUkFESVNF IFBPSU5UIFJFU09SVCBJTiBTQU4gRElFR08sIENBTElGT1JOSUENDVBhcnRpY2lwYW50cyB3aWxs IGJlIHJlc3BvbnNpYmxlIGZvciBicmluZ2luZyB3b3Jrc3RhdGlvbnMgYW5kIG5ldHdvcmsgZXF1 aXBtZW50LiBZb3UgbWF5IHNoaXAgeW91ciBlcXVpcG1lbnQgdG86IA0NU2FuIERpZWdvIFBhcmFk aXNlIFBvaW50IFJlc29ydA0xNDA0IFcuIFZhY2F0aW9uIFJvYWQNU2FuIERpZWdvLCBDQSA5MjEw OQ1UZWxlcGhvbmU6IDg1OC0yNzQtNDYzMA1BdHRlbnRpb246IFN0ZXZlIEhhbmdlciAgICAgICAg ICAgICAgICBQbGVhc2UgbWFyayAiSG9sZCBmb3IgQ2lzY28gVlBOIFdvcmtzaG9wIg0NU2NoZWR1 bGUgeW91ciBlcXVpcG1lbnQgdG8gYXJyaXZlIGF0IFBhcmFkaXNlIFBvaW50IFJlc29ydCBiZXR3 ZWVuIEphbnVhcnkgMy03LCAyMDAwLiBQbGVhc2UgcHJvdmlkZSBzaGlwcGluZyBpbmZvcm1hdGlv biwgc3VjaCBhcyBkYXRlIHNoaXBwZWQsIHRyYWNraW5nIG51bWJlciwgYW5kIG51bWJlciBvZiBi b3hlcyB0byBQYXJhZGlzZSBQb2ludCBSZXNvcnQgc28gcmVjZWlwdCBvZiB5b3VyIHNoaXBtZW50 IG1heSBiZSBjb25maXJtZWQgYW5kIGFjY2VwdGVkLiANDUlNUE9SVEFOVDogUGxlYXNlIGJyaW5n IHRoZSBzaGlwcGluZyBkb2N1bWVudHMgZm9yIHRoZSByZXR1cm4gb2YgeW91ciBlcXVpcG1lbnQg YmFjayB0byB5b3VyIGNvbXBhbnkuIFRoZXNlIGRvY3VtZW50cyBpbmNsdWRlIHRoZSBjYXJyaWVy IGZvcm0uIEludGVybmF0aW9uYWwgc2hpcG1lbnRzIG11c3QgaW5jbHVkZSBhbGwgYXBwcm9wcmlh dGUgZG9jdW1lbnRzLCBpbmNsdWRpbmcgY2FycmllciBmb3JtcyBhbmQgaW52b2ljZXMuIA0NQWRk aXRpb25hbGx5LCBwbGVhc2UgbWFrZSBhcnJhbmdlbWVudHMgd2l0aCB5b3VyIGNhcnJpZXIgaW4g YWR2YW5jZSBmb3IgcGlja3VwIG9mIHlvdXIgZXF1aXBtZW50IGF0IHRoZSBQYXJhZGlzZSBQb2lu dCBSZXNvcnQgZm9yIG5vIGxhdGVyIHRoYW4gNTowMCBQTSBvbiBGcmlkYXksIEphbnVhcnkgMTQs IDIwMDAuIFlvdSB3aWxsIGJlIHJlc3BvbnNpYmxlIHRvIHNlZSB0aGF0IHlvdXIgY2FycmllciBw aWNrcyB1cCB5b3VyIGVxdWlwbWVudC4gDQ1UaGVzZSB0d28gcG9pbnRzIGFyZSB2ZXJ5IGltcG9y dGFudC4gTmVpdGhlciBDaXNjbyBub3IgdGhlIFBhcmFkaXNlIFBvaW50IFJlc29ydCB3aWxsIGJl IGFibGUgdG8gcHJvdmlkZSBzaGlwcGluZyBmb3JtcyBvciBjdXN0b21zIGZvcm1zIHRvIHlvdS4g WW91IGhhdmUgdG8gYnJpbmcgeW91ciBvd24uIEFsc28gbmVpdGhlciBDaXNjbyBub3IgdGhlIFBh cmFkaXNlIFBvaW50IFJlc29ydCB3aWxsIGJlIGFibGUgdG8gc3RvcmUgeW91ciBlcXVpcG1lbnQg cGFzdCBKYW51YXJ5IDE0LCAyMDAwLiANDUFDQ09NTU9EQVRJT05TOiANDUJlIHN1cmUgdG8gcmVz ZXJ2ZSBieSBEZWNlbWJlciAxNSwgMTk5OSwgdG8gaW5zdXJlIHRoYXQgcm9vbXMgd2lsbCBiZSBh dmFpbGFibGUgZm9yIHlvdSBhbmQgeW91ciBncm91cC4gIFRoZSBibG9jayBvZiByb29tcyBpcyBh dmFpbGFibGUgYXQ6IA0NU2FuIERpZWdvIFBhcmFkaXNlIFBvaW50IFJlc29ydA0xNDA0IFcuIFZh Y2F0aW9uIFJvYWQNU2FuIERpZWdvLCBDQSA5MjEwOQ1UZWxlcGhvbmU6IDg1OC0yNzQtNDYzMCBv ciA4MDAtMzQ0LTI2MjYgIA0NUmVnaXN0ZXIgdW5kZXIgIkNpc2NvIFZQTiBXb3Jrc2hvcCIgdG8g Z2V0IHRoZSBkaXNjb3VudGVkIFdvcmtzaG9wIHJhdGUgb2YgJDE0MC4wMCBwbHVzIHRheCBwZXIg bmlnaHQuDQ1Sb29tcyBhcmUgYXZhaWxhYmxlIGZvciBjaGVjayBpbiBKYW51YXJ5IDksIDIwMDAg dGhyb3VnaCBjaGVjayBvdXQgSmFudWFyeSAxNCwgMjAwMC4gIENoZWNrIGluIHRpbWUgaXMgNDow MCBQTSBhbmQgY2hlY2sgb3V0IHRpbWUgaXMgMTI6MDAgTm9vbi4gU2hvdWxkIHRoZSBhdHRlbmRl ZSBjYW5jZWwgdGhlIHJlc2VydmF0aW9uIHdpdGhpbiA0OCBob3VycyBvZiBhcnJpdmFsLCB0aGV5 IGFyZSBzdWJqZWN0IHRvIGJpbGxpbmcgb2Ygb25lIG5pZ2h0J3Mgcm9vbSBhbmQgdGF4LiBTaG91 bGQgYW4gYXR0ZW5kZWUgZGVwYXJ0IGVhcmx5IGZyb20gdGhlIG9yaWdpbmFsIGNoZWNrIG91dCBk YXRlLCB0aGUgYXR0ZW5kZWUgd2lsbCBiZSByZXNwb25zaWJsZSBmb3Igb25lIG5pZ2h0J3Mgcm9v bSBhbmQgdGF4Lg1BdmFpbGFibGUgcm9vbSB1cGdyYWRlIG9wdGlvbnM6IA0JTGFuYWkgc2luZ2xl L2RvdWJsZQkJJDE0MA0JTGFuYWkgQmF5dmlldwkJJDE5NQ0JU3R1ZGlvIFN1aXRlIEdhcmRlbgkJ JDIzNQ0JU3R1ZGlvIFN1aXRlIEJheXNpZGUJCSQyNjUNCU9uZSBCZWRyb29tIFN1aXRlIEdhcmRl bgkkMjc1CQkNT25lIEJlZHJvb20gU3VpdGUgQmF5dmlldwkkMzEwDQ1BYm91dCBTYW4gRGllZ28g UGFyYWRpc2UgUG9pbnQgUmVzb3J0OiATIEhZUEVSTElOSyBodHRwOi8vd3d3LmZlc3NwYXJrZXJz ZG91YmxldHJlZS5jb20gARQgaHR0cDovL3d3dy5wYXJhZGlzZXBvaW50LmNvbS8VDQ1BaXJwb3J0 IEFjY2VzczoNDUFpcmxpbmUgc2VydmljZSBpcyBhdmFpbGFibGUgdG8gTGluZGJlcmdoIEludGVy bmF0aW9uYWwgQWlycG9ydCwgU2FuIERpZWdvLCBDYWxpZm9ybmlhLCBVU0EgKFNBTikuICBBbHRl cm5hdGVseSwgeW91IG1heSBmbHkgdG8gTG9zIEFuZ2VsZXMgKExBWCksIENhbGlmb3JuaWEgYW5k IGRyaXZlIGFwcHJveGltYXRlbHkgdHdvIGhvdXJzIHRvIFNhbiBEaWVnby4NDURpcmVjdGlvbnMg ZnJvbSBMaW5kYmVyZ2ggSW50ZXJuYXRpb25hbCBBaXJwb3J0OiBUYWtlIEhhcmJvciBEcml2ZSBO b3J0aCBhbmQgdHVybiByaWdodCBvbiBOaW1pdHosIGZvbGxvdyBzaWducyB0byBNaXNzaW9uIEJh eSBQYXJrLiAgUmlnaHQgb24gSW5ncmFoYW0sIGxlZnQgYXQgV2VzdCBWYWNhdGlvbiBSb2FkLg0N WW91IGNhbiB0YWtlIENsb3VkIDkgU2h1dHRsZSAxLTgwMC05LVNIVVRUTEUgZnJvbSB0aGUgYWly cG9ydCB0byB0aGUgaG90ZWwgZm9yIHRyYW5zcG9ydGF0aW9uIHRvIHRoZSBob3RlbCBmb3IgJDgu MDAuIEZyb20gVGVybWluYWwgMSBvciBUZXJtaW5hbCAyIGZvbGxvdyB0aGUgc2lnbnMgdG8gdGhl IEdyb3VuZCBUcmFuc3BvcnRhdGlvbiBTa3licmlkZ2UsIHByb2NlZWQgdG8gdGhlICJTaHV0dGxl IGZvciBIaXJlIiBjdXJiIGFuZCBhc2sgdGhlICJUcmFuc3BvcnRhdGlvbiBDb29yZGluYXRvciIg Zm9yIENsb3VkIDkgU2h1dHRsZS4gRnJvbSB0aGUgQ29tbXV0ZXIgdGVybWluYWwgZXhpdCB0aGUg ZG9vcnMsIGNyb3NzIG92ZXIgdG8gdGhlIHNodXR0bGUgbG9hZGluZyBpc2xhbmQsIGFuZCBhc2sg dGhlICJUcmFuc3BvcnRhdGlvbiBDb29yZGluYXRvciIgZm9yIENsb3VkIDkgU2h1dHRsZS4NDVNF Q1VSSVRZOg0NQW4gb3V0c2lkZSBzZWN1cml0eSBjb21wYW55IGhhcyBiZWVuIHJldGFpbmVkIGZy b20gODowMCBQTSB1bnRpbCA4OjAwIEFNIGZyb20gSmFudWFyeSA4LTE0LCAyMDAwLiAgVGhlcmUg d2lsbCBiZSBhIHNpZ24tdXAgcHJvY2VkdXJlIGZvciBwYXJ0aWNpcGFudHMgd2lzaGluZyB0byB3 b3JrIGFmdGVyIDg6MDAgUE0gVGhvc2Ugd2lzaGluZyB0byB3b3JrIGFmdGVyIDg6MDAgUE0gbXVz dCBiZSBwcmVzZW50IGF0IDg6MDAgUE0gZm9yIGludHJvZHVjdGlvbnMgdG8gdGhlIHNlY3VyaXR5 IHN0YWZmIG9mIHRoZSBldmVuaW5nLg0NUFJFU1MgUkVMRUFTRTogDQ1DaXNjbyBwbGFucyB0byBt YWtlIGEgcHJlc3MgcmVsZWFzZSBmb2xsb3dpbmcgdGhlIHdvcmtzaG9wLiAgVGhlcmUgd2lsbCBi ZSBubyBtZW50aW9uIG9mIGFueSBzcGVjaWZpYyByZXN1bHRzIG9mIHRoZSB0ZXN0aW5nIGluIHRo aXMgcmVsZWFzZS4gUGxlYXNlIGluZGljYXRlIGluIHRoZSBhcHBsaWNhdGlvbiBpZiB5b3Ugd2Fu dCB5b3VyIGNvbXBhbnkncyBuYW1lIGluY2x1ZGVkIGluIHRoaXMgcmVsZWFzZSBhcyBhIHBhcnRp Y2lwYW50LiBJZiB5b3UgaW5jbHVkZSB5b3VyIHB1YmxpYyByZWxhdGlvbnMgcGVyc29uIGluIHRo ZSBhcHBsaWNhdGlvbiwgdGhhdCBjb250YWN0IHdpbGwgYmUgZ2l2ZW4gdGhlIG9wcG9ydHVuaXR5 IHRvIHJldmlldyB0aGUgcmVsZWFzZSBpbiBhZHZhbmNlLiANDVJFR0lTVFJBVElPTjogDQ1UaGlz IHdpbGwgYmUgYSAic2VsZiBvcmdhbml6aW5nIiBldmVudC4gSXQgd2lsbCBiZSB5b3VyIHJlc3Bv bnNpYmlsaXR5IHRvIGRldmVsb3AgeW91ciBvd24gdGVzdCBzY2hlZHVsZSBhbmQgdG8gYXJyYW5n ZSB5b3VyIG93biB0ZXN0aW5nIHBhcnRuZXJzLiBUaGlzIG1ldGhvZCBoYXMgd29ya2VkIHdlbGwg aW4gdGhlIHBhc3QgYW5kIHdlIGJlbGlldmUgdGhhdCBpdCBwcm92aWRlcyB0aGUgbW9zdCBwcm9k dWN0aXZlIGVudmlyb25tZW50IGZvciB0ZXN0aW5nLiBJbiB0aGUgYXBwbGljYXRpb24geW91IHdp bGwgYmUgYXNrZWQgdG8gbGlzdCB0aGUgZGF5cyB5b3Ugd2lsbCBiZSBhdmFpbGFibGUgZm9yIHRl c3RpbmcuIFBsZWFzZSBiZSBhY2N1cmF0ZSBzbyBldmVyeW9uZSBoYXMgYW4gb3Bwb3J0dW5pdHkg dG8gdGVzdCB3aXRoIHlvdS4gDQ1QbGVhc2UgZmlsbCBvdXQgdGhlIFByb2R1Y3QgU2VjdGlvbiBv ZiB0aGUgYXBwbGljYXRpb24gY2FyZWZ1bGx5IGRlZmluaW5nIHRoZSBzdXBwb3J0ZWQgY2FwYWJp bGl0eSBsaXN0IGZvciB0aGUgcHJvdG9jb2wgb3B0aW9ucyB5b3Ugd2lsbCB0ZXN0IGF0IHRoZSB3 b3Jrc2hvcC4gV2Ugd2lsbCB1c2UgdGhlIGluZm9ybWF0aW9uIHRvIHB1dCB0b2dldGhlciBhIGJp bmRlciBvZiBkYXRhIHRvIGFzc2lzdCB3aGVuIHlvdSBhcmUgdGVzdGluZyB3aXRoIHBhcnRuZXJz LiANDVRvIHJlZ2lzdGVyIGZvciB0aGUgVlBOIEludGVyb3BlcmFiaWxpdHkgV29ya3Nob3AgZmls bCBvdXQgdGhlIHBheW1lbnQgZm9ybSBhbmQgcmV0dXJuIGl0IGJ5IGVtYWlsIHRvIDxib2JAbGFy cmliZWF1LmNvbT4uIA0NVGhlbiBmaWxsIG91dCB0aGUgYXBwbGljYXRpb24gb24gdGhpcyBXZWIg c2l0ZSBpbW1lZGlhdGVseSB0byByZXNlcnZlIHlvdXIgcGxhY2UgYXQgdGhlIHdvcmtzaG9wLg0N SWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucywgc2VuZCBlbWFpbCBvciBjYWxsIA0NQm9iIExhcnJp YmVhdSwgYm9iQGxhcnJpYmVhdS5jb20sIDQxNS0yNDEtOTkyMCANDUJhc2VkIG9uIHBhc3Qgd29y a3Nob3BzLCBleHBlY3RlZCBhdHRlbmRhbmNlIGlzIDYwIGNvbXBhbmllcy4gIEdldCB0aGUgcGF5 bWVudCBmb3JtIGFuZCBhcHBsaWNhdGlvbiBpbiBlYXJseSB0byBhc3N1cmUgeW91cnNlbGYgYSBw bGFjZS4NDQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gUEFZTUVOVCBGT1JNLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANUExFQVNFIFJFVFVSTiBUSElTIFBBWU1FTlQgRk9STSBW SUEgRU1BSUwuDQ1OYW1lOiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0NQ29t cGFueTogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANDUFkZHJlc3M6IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyANDV9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyANDUNpdHksIFN0YXRlLCBaaXAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gDQ1Db3VudHJ5OiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IA0NUGhvbmU6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANDUZheDogX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQ1FbWFpbDogX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIA0NTnVtYmVyIG9mIEF0dGVuZGVlczogX19fX19fX19fIHggJDMwMC4w MCA9IFRvdGFsIFBheW1lbnQgJF9fX19fX19fX19fX18NDVJlZnVuZHMgd2lsbCBub3QgYmUgbWFk ZSBmb3IgY2FuY2VsbGF0aW9ucyBhZnRlciBEZWNlbWJlciAxNSwgMTk5OS4NDVBheSBieSBjcmVk aXQgY2FyZDogDQ1GaWxsIG91dCB0aGUgZm9ybSBiZWxvdyBhbmQgZmF4IGl0IHRvIHRoZSBDYWxC VUcgYXQgKDQxNSkgNzUzLTY5NDIuIA0NQ3JlZGl0IENhcmQgVHlwZSAoQ2lyY2xlIE9uZSk6IEFt ZXJpY2FuIEV4cHJlc3MsIFZpc2EsIE1hc3RlciBDaGFyZ2UsIEpDQiANDUNyZWRpdCBDYXJkIE51 bWJlcjogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0NRXhwaXJhdGlvbiBEYXRlOiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQ1OYW1lOiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyANDVNpZ25hdHVyZTogX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIA0NUGF5IGJ5IGNoZWNrOiANDVNlbmQgYSBjaGVjayBt YWRlIG91dCB0byB0aGUgQ2FsQlVHIGZvciAkMzAwIGZvciBlYWNoIHBhcnRpY2lwYW50IHRvOiAN DUNhbGlmb3JuaWEgQnJvYWRiYW5kIFVzZXIncyBHcm91cCwgUE8gQm94IDI3OTAxLTM5MSwgU2Fu IEZyYW5jaXNjbywgQ0EgOTQxMjcgDQ1XaXJlIGZ1bmRzIHRvOiANDUNhbGlmb3JuaWEgQnJvYWRi YW5kIFVzZXJzJyBHcm91cA1BY2NvdW50IE51bWJlciAwMjg4MiAwNzc1MiANQmFuayBvZiBBbWVy aWNhICMwMjg4IA0yODggV2VzdCBQb3J0YWwgQXZlbnVlLCBTYW4gRnJhbmNpc2NvLCBDQSA5NDEy NyBVU0EgDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tIA1BUFBMSUNBVElPTiANDVBMRUFTRSBGSUxMIE9VVCBUSElT IEFQUExJQ0FUSU9OIE9OIFRIRSBXRUIgU0lURQ0NUGxlYXNlIGVudGVyIHRoZSBuYW1lIG9mIHRo ZSBXb3Jrc2hvcCBDb29yZGluYXRvciB3aG8gd2lsbCBjb29yZGluYXRlIHlvdXIgcmVnaXN0cmF0 aW9uLiBXZSB3aWxsIHNlbmQgZW1haWxzIHRvIHRoaXMgcGVyc29uIHRvIGdpdmUgdGhlIGxhdGVz dCBpbmZvcm1hdGlvbiBvbiB0aGUgd29ya3Nob3AgYW5kIHRvIHZlcmlmeSB5b3VyIHJlZ2lzdHJh dGlvbi4gDQ1Db21wYW55IE5hbWU6IF9fX19fX19fX19fX19fX19fX19fX19fX19fDQ1OYW1lOiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0NQWRkcmVzczogX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIA0NX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIA0NQ2l0eSwgU3RhdGUsIFppcCBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyANDUNvdW50cnk6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQ1Q aG9uZTogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0NRmF4OiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyANDUVtYWlsOiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gDQ1EbyB5b3Ugd2FudCB5b3VyIGNvbXBhbnkncyBuYW1lIGluY2x1ZGVkIGlu IHRoZSBDaXNjbyBwcmVzcyByZWxlYXNlIGFzIGEgcGFydGljaXBhbnQ/ICBZZXMgb3IgTm8gDQ1Q cm92aWRlIHRoZSBuYW1lLCBhZGRyZXNzLCBwaG9uZSwgZmF4LCBhbmQgZW1haWwgb2YgeW91ciBw dWJsaWMgcmVsYXRpb25zIGNvbnRhY3QuIFdlIHdpbGwgZ2l2ZSB0aGlzIHBlcnNvbiBhbiBvcHBv cnR1bml0eSB0byByZXZpZXcgdGhlIHJlbGVhc2UgaW4gYWR2YW5jZS4NIA0NTmFtZXMgb2YgQUxM IFBhcnRpY2lwYW50cyAoaW5jbHVkaW5nIHRoZSBXb3Jrc2hvcCBDb29yZGluYXRvciBsaXN0ZWQg YWJvdmUgaWYgdGhleSB3aWxsIGF0dGVuZCk6DSANTmFtZV9fX19fX19fX19fX19fX19fX19fXwkN DU5hbWVfX19fX19fX19fX19fX19fX19fX18JDQ1OYW1lX19fX19fX19fX19fX19fX19fX19fDSAN DURheXMgYXZhaWxhYmxlIGZvciB0ZXN0aW5nOiBNIFR1IFcgVGggRiANDU51bWJlciBvZiB0YWJs ZXM6IA0NLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0NSVAgQWRkcmVzc2VzLQ0NTnVtYmVyIG9mIENvbmZpZ3VyYXRp b24gMToNKGEgc2luZ2xlIElQIGFkZHJlc3Mgd2l0aCBhIHJvdXRlZCBwcml2YXRlIG5ldHdvcmsg YWRkcmVzcykNDU51bWJlciBvZiBDb25maWd1cmF0aW9uIDI6IA0oQSBzaW5nbGUgSVAgYWRkcmVz cyB3aXRoIGEgcm91dGVkIHByaXZhdGUgYW5kIHB1YmxpYyBuZXR3b3JrIGFkZHJlc3MpDQ1BZGRp dGlvbmFsIFBvd2VyIFJlcXVpcmVtZW50czogDQ1OdW1iZXIgb2YgQlJJIGxpbmVzOiAxICAyICBN b3JlIHRoYW4gMiAocGxlYXNlIHNwZWNpZnkpDQ1TL1Qgb3IgVSBpbnRlcmZhY2U6IA0NUFJJIChZ ZXMgb3IgTm8pOg0NQWRkaXRpb25hbCBNYWRnZSBTd2l0Y2ggUmVxdWlyZW1lbnRzOg0NQVRNIFBW QyAoUFBQKTogIDEgIDIgIE1vcmUgdGhhbiAyIChwbGVhc2Ugc3BlY2lmeSkNDUFUTSBQVkMgKEwy VFApOiAgMSAgMiAgTW9yZSB0aGFuIDIgKHBsZWFzZSBzcGVjaWZpeSkNDS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N DUZlYXR1cmVzIHlvdSB3aWxsIGJlIFRFU1RJTkc6IA0NSVBTZWMgKFkvTikgDQ1JS0UgKFkvTikN DUlLRS1DRkcNDUlLRS1YQVVUSA0NSVAgUGF5bG9hZCBDb21wcmVzc2lvbiAoWS9OKQ0NTDJUUCBv dmVyIFRyYW5zcG9ydC1Nb2RlIElQU2VjIChZL04pDQ1DQ1Agd2l0aCBNUFBDIChZL04pDQ1DQ1Ag d2l0aCBNUFBFIChZL04pDQ1NUyBDSEFQIFZlcnNpb24gMiAoWS9OKQ0NRUFQIChZL04pDQ1QUFRQ IChZL04pDQ1QUFAgb3ZlciBFdGhlcm5ldCAoUFBQb0UpIChZL04pDQ1QUFAgb3ZlciBBVE0gKFkv TikNDUwyVFAgb3ZlciBBVE0gKFkvTikNDUwyVFAgKFkvTikNDS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDVdpbGwg eW91IGJlIHByb3ZpZGluZzoNDUNBIHNlcnZpY2VzIChZL04pDQ0NLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQ1Q cm9kdWN0IEZ1bmN0aW9uYWxpdHkgU2VjdGlvbjoNDVRoZSBwdXJwb3NlIG9mIHRoaXMgc3VydmV5 IGlzIHRvIGlkZW50aWZ5IHN1cHBvcnRlZCBmZWF0dXJlcyBzbyB0aGF0IHZlbmRvcnMgd2lsbCBr bm93IHdobyBpcyBpbXBsZW1lbnRpbmcgd2hhdCwgY2FuIGtub3cgd2hvIHRvIGRpc2N1c3MgdGhl IGRldGFpbGVkIGZ1bmN0aW9uYWxpdHkgd2l0aCwgYW5kIHRvIGlkZW50aWZ5IHByb2R1Y3RzIGZv ciBtb3JlIHNlcmlvdXMgY29tcGF0aWJpbGl0eSB0ZXN0aW5nIGxhdGVyLg0NRmlsbCBvdXQgYSBQ cm9kdWN0IFNlY3Rpb24gdG8gZGVzY3JpYmUgc3VwcG9ydGVkIGZlYXR1cmVzIGZvciBlYWNoIGRl dmljZSBvciBzb2Z0d2FyZSBwYWNrYWdlIHlvdSB3aWxsIGhhdmUgYXQgdGhlIHdvcmtzaG9wLiAg SWYgdGhlIHZlcnNpb24gaXMgdW5yZWxlYXNlZCwgaW5kaWNhdGUgJ2FscGhhJywgJ2JldGEnLCBS QyAocmVsZWFzZSBjYW5kaWRhdGUpIG9yIGJ1aWxkIG51bWJlci4gIE9wdGlvbnMgbWFya2VkIHdp dGggICogYXJlIGFkdmFuY2VkIGZlYXR1cmVzLg0gDS0tLSAxLS0tDVByb2R1Y3QgTmFtZTogDQ1T b2Z0d2FyZSBWZXJzaW9uIGFuZCBPUyBjb21wYXRpYmlsaXR5OiANDVByb2R1Y3QgVHlwZSwgY2hl Y2sgYWxsIHRoYXQgYXBwbHk6IA0NUm91dGVyX19fX18gRmlyZXdhbGxfX19fXyBJUFNlYyBHYXRl d2F5X19fX18gSVBTZWMgQ2xpZW50X19fX18NDUwyVFAvSVBzZWMgQ2xpZW50IFNvZnR3YXJlX19f X18gRW5kIHRvIEVuZCAoVHVubmVsL1RyYW5zcG9ydCkgQ2xpZW50X19fX18NDU90aGVyX19fX19f X19fX19fX19fX19fX19fX19fIA0NLS0tIDItLS0NUHJvZHVjdCBOYW1lOiANDVNvZnR3YXJlIFZl cnNpb24gYW5kIE9TIGNvbXBhdGliaWxpdHk6IA0NUHJvZHVjdCBUeXBlLCBjaGVjayBhbGwgdGhh dCBhcHBseTogDQ1Sb3V0ZXJfX19fXyBGaXJld2FsbF9fX19fIElQU2VjIEdhdGV3YXlfX19fXyBJ UFNlYyBDbGllbnRfX19fXw0NTDJUUC9JUHNlYyBDbGllbnQgU29mdHdhcmVfX19fXyBFbmQgdG8g RW5kIChUdW5uZWwvVHJhbnNwb3J0KSBDbGllbnRfX19fXw0NT3RoZXJfX19fX19fX19fX19fX19f X19fX19fX18gDQ0tLS0gMy0tLQ1Qcm9kdWN0IE5hbWU6IA0NU29mdHdhcmUgVmVyc2lvbiBhbmQg T1MgY29tcGF0aWJpbGl0eTogDQ1Qcm9kdWN0IFR5cGUsIGNoZWNrIGFsbCB0aGF0IGFwcGx5OiAN DVJvdXRlcl9fX19fIEZpcmV3YWxsX19fX18gSVBTZWMgR2F0ZXdheV9fX19fIElQU2VjIENsaWVu dF9fX19fDQ1MMlRQL0lQc2VjIENsaWVudCBTb2Z0d2FyZV9fX19fIEVuZCB0byBFbmQgKFR1bm5l bC9UcmFuc3BvcnQpIENsaWVudF9fX19fDQ1PdGhlcl9fX19fX19fX19fX19fX19fX19fX19fXyAN DQ09PT09PUlQU0VDPT09PT1JUFNFQz09PT09SVBTRUM9PT09PUlQU0VDPT09PT0NDUlQU2VjIG1h bnVhbCBrZXlzIFNBIGNvbmZpZ3VyYXRpb24gKGtleXMsIFNQSSwgYWxnb3JpdGhtcykgKFkvTikN DU1pbmltdW0ga2V5IGxlbmd0aCAoWS9OKQ0NSWYgeWVzLCBrZXkgbGVuZ3RoX19fX19fX19fX19f X19fXw0NQUggdHVubmVsIChZL04pDQ1BSCB0cmFuc3BvcnQgKFkvTikNDUVTUCB0dW5uZWwgKFkv TikNDUVTUCB0cmFuc3BvcnQgKFkvTikNDVRyYW5zcG9ydCBhZGphY2VuY3k6IGFwcGx5aW5nIG1v cmUgdGhhbiBvbmUgc2VjdXJpdHkgcHJvdG9jb2wgdG8gdGhlIHNhbWUgSVAgZGF0YWdyYW0sIHdp dGhvdXQgaW52b2tpbmcgdHVubmVsaW5nLCBlZy4gW0lQXVtBSF1bRVNQXVtwYWNrZXQgcGF5bG9h ZF0gIChZL04pDQ1OZXN0ZWQgdHVubmVsaW5nIGZyb20gdGhlIHNhbWUgYm94OiAiVHVubmVsaW5n IElQU2VjIGluIGFuIElQU2VjIHR1bm5lbCIsIGVnLiBbSVBdW0lQU2VjXVtJUF1bSVBTZWNdW3Bh Y2tldCBwYXlsb2FkXSB3aGVyZSAiW0lQU2VjXSIgY291bGQgYmUgIltFU1BdIiBvciAiW0FIXSIg b3IgIltBSF1bRVNQXSIgYW5kIHdoZXJlICJbcGFja2V0IHBheWxvYWRdIiBjb3VsZCBiZSBhIFVM UCBvciBhbm90aGVyIGVudGlyZSBJUCBkYXRhZ3JhbS4gKFkvTikNDUl0ZXJhdGVkIHR1bm5lbGlu ZyBvbiBzYW1lIGJveDogIlRlcm1pbmF0ZSBhIHR1bm5lbCBvbiBvbmUgaW50ZXJmYWNlIGFuZCBm b3J3YXJkIHRoZSBwYWNrZXRzIG91dCBvbiBhIGRpZmZlcmVudCB0dW5uZWwgb24gYSBkaWZmZXJl bnQgaW50ZXJmYWNlIiAoWS9OKQ0NRVNQIGNpcGhlciBhbGdvcml0aG1zLQ0NREVTLUNCQyAoWS9O KQ0NM0RFUyAoWS9OKQ0NTlVMTCBlbmNyeXB0aW9uIChZL04pDQ0qUkM1IChZL04pDQ0qQ0FTVCAo WS9OKQ0NKkJsb3dmaXNoIChZL04pDQ0qSURFQSAoWS9OKQ0NKkRFUy1YIChZL04pDQ1FU1AgYXV0 aGVudGljYXRvcnMtDQ1ITUFDLU1ELTUgKFkvTikNDUhNQUMtU0hBLTEgKFkvTikNDSpITUFDIFJJ UEVNRC0xNjAgKFkvTikNDUFIIGFsZ29yaXRobXMtDQ1ITUFDLU1ELTUgKFkvTikNDUhNQUMtU0hB LTEgKFkvTikNDSpITUFDIFJJUEVNRC0xNjAgKFkvTikNDSpJUFAgQ29tcHJlc3Npb24gUHJvdG9j b2wtDQ1MWlMgKFkvTikNDURFRkxBVEUgKFkvTikNDT09PT09SUtFPT09PT1JS0U9PT09PUlLRT09 PT09SUtFPT09PT0gSUtFPT09PT0gDQ1JS0UgRXhjaGFuZ2VzLQ0NTWFpbi9RdWljayBtb2RlIChp ZGVudGl0eSBwcm90ZWN0KSAoWS9OKQ0NKkFnZ3Jlc3NpdmUgbW9kZSAoWS9OKQ0NKklLRSBDb25m aWcgKFkvTikNDSpYQVVUSCAoWS9OKQ0NKkRIQ1AgSW5mb3JtIGZvciBpbnRlcm5hbCB0dW5uZWwg Y29uZmlnIChZL04pDQ0qTmV3IEdyb3VwIE1vZGUgKFkvTikNDUlLRSBBdXRoZW50aWNhdGlvbiBt ZXRob2RzLQ0NUHJlc2hhcmVkIGtleXMgKFkvTikNDU1pbmltdW0gbGVuZ3RoIChZL04pDQ1JZiB5 ZXMsIGxlbmd0aF9fX19fX19fX19fX18NDSpSU0Egc2lnbmF0dXJlIChZL04pDQ0qRFNTIHNpZ25h dHVyZSAoWS9OKQ0NKlJTQSBFbmNyeXB0aW9uIChZL04pDQ0qUmV2aXNlZCBSU0EgZW5jcnlwdGlv biAoWS9OKQ0NKkdTU0FQSS1LZXJiZXJvcyB2NSAoWS9OKQ0NKkJhc2UgTW9kZSAoWS9OKQ0NSUtF IEtleSBNYXRlcmlhbC0NDUdyb3VwcyBzdXBwb3J0ZWQgKDEsMiwzLDQsNSxvdGhlcnMpX19fX19f X19fXw0NKkVsbGlwdGljIEN1cnZlIEdyb3Vwc19fX19fX19fX19fX18NDSpESC1sZXNzIElLRV9f X19fX19fXw0NTWFpbiBtb2RlIFBGUyAoMSBNTSBwZXIgcXVpY2sgbW9kZSkgKFkvTikNDVF1aWNr IG1vZGUgUEZTIChZL04pDQ1NaW5pbXVtIHF1aWNrbW9kZSBsaWZldGltZSAoYnl0ZXMvc2Vjcylf X19fX19fX18NDUlLRSBFbmNyeXB0aW9uIGFsZ29yaXRobXMtDQ1ERVMgKFkvTikNDTNERVMgKFkv TikNDUNBU1QgKFkvTikNDVJDNSAoWS9OKQ0NQmxvd2Zpc2ggKFkvTikNDUlERUEgKFkvTikNDU90 aGVyX19fX19fX19fX19fX19fX19fDQ1JS0UgSGFzaCBhbGdvcml0aG1zLQ0NTUQtNSAoWS9OKQ0N U0hBLTEgKFkvTikNDSpITUFDIFJJUEVNRC0xNjAgb3B0aW9uYWwgKFkvTikNDUlLRSBDZXJ0aWZp Y2F0ZXMtDQ0qSUtFIENlcnRpZmljYXRlIFZhbGlkYXRpb24gKFkvTikNDVZhbGlkYXRlIHN1Ympl Y3QgbmFtZSBhZ2FpbnN0IElQU2VjIHBvbGljeSBkYXRhIChZL04pDQ1Ob3JtYWwgb3BlcmF0aW9u IHJlcXVpcmVzIG9uLWxpbmUgYWNjZXNzIHRvIENBIGZvciBlbnJvbGxtZW50IChZL04pDQ1DZXJ0 aWZpY2F0ZSBSZXF1ZXN0IFBheWxvYWQgKFJlcWQvT3B0aW9uYWwvTm90IFVzZWQgYW5kIElnbm9y ZWQpX19fX19fX19fX19fX18NDSpDZXJ0aWZpY2F0ZSBjaGFpbnMgaW4gYmFuZCwgbWVhbnMgZXhj aGFuZ2VkIGluIElLRSAoWS9OKQ0NQ1JMIHN1cHBvcnQgKFJlcWQvT3B0aW9uYWwvIE5vbmUpX19f X19fX19fX18NDUNSTCByZXRyaWV2YWwgbWVjaGFuaXNtIChodHRwLCBmaWxlLCBMREFQKV9fX19f X19fX19fX19fDQ1Ob3JtYWwgb3BlcmF0aW9uIChSZXFkL09wdGlvbmFsLyBEb26SdCBDYXJlIGFu ZCBOb3QgVXNlZCkgb24tbGluZSBhY2Nlc3MgdG8gQ1JMIGRpc3RyaWJ1dGlvbiBwb2ludCBfX19f X19fX19fX19fX19fX18NDSBJS0UgT3B0aW9uYWwgcGF5bG9hZHMtLS0tLS0tLS0tLS0tLS0tDQ0q SUtFIENlcnQgdHlwZXMgLQ0NQ0VSVCAoWS9OKQ0NQ1JMIChZL04pDQ1BUkwgKFkvTikNDVBLQ1M3 IChZL04pDQ1DZXJ0aWZpY2F0ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBzdXBwb3J0ZWQgKE1ENSwg U0hBMSwgZXRjKV9fX19fX19fX18NDUlQU2VjIG9ubHkgY2VydGlmaWNhdGUga2V5IHVzYWdlIChS ZXFkL09wdGlvbmFsL0Rvbid0IENhcmUpX19fX19fX19fX18NDU90aGVyIGNlcnRpZmljYXRlIHJl c3RyaWN0aW9uc19fX19fX19fX19fX19fDQ0qSUtFIENlcnQgcmVxdWVzdCB0eXBlcyAtDQ1DRVJU IChZL04pDQ1DUkwgKFkvTikNDUFSTCAoWS9OKQ0NUEtDUzcgKFkvTikNIA1JS0UgT3RoZXIgT3B0 aW9ucy0NIA0qVmVuZG9yLUlEIChZL04pDQ0qQ29tbWl0IGJpdCAoWS9OKQ0NKlVzZSBxdWljayBt b2RlIGxpZmV0aW1lIG5vdGlmaWVzIChZL04pDQ0qVXNlIEluaXRpYWwgQ29udGFjdCAoWS9OKQ0N KlNlbmQgZGVsZXRlIHBheWxvYWQgZm9yIHF1aWNrbW9kZSBTQXMgKFkvTikNDSpTZW5kIGRlbGV0 ZSBwYXlsb2FkIGZvciBtYWluIG1vZGUgU0FzIChZL04pDQ0qQ0EgSW50ZXJvcGVyYWJpbGl0eSBJ c3N1ZXMtDQ0qUkZDMjUxMCAoWS9OKQ0NKlBLQ1MgMTAvNyAoWS9OKQ0NKlBLQ1MgIzEyIChZL04p DQ1NYW51YWwgY2VydGlmaWNhdGUgZW5yb2xsbWVudCAoWS9OKQ0NKkxldmVsIG9mIENBIGhpZXJh cmNoaWVzIHN1cHBvcnRlZCAobnVtYmVyIGxldmVscy9ObylfX19fX19fX19fXw0NKlN1cHBvcnQg Y2VydHMgaXNzdWVkIGJ5IGEgc3Vib3JkaW5hdGUgQ0EsIHdoaWNoIGlzIGEgY2hpbGQgb2YgYSBk aWZmZXJlbnQgdmVuZG9yIENBIChjcm9zcyBjZXJ0aWZpY2F0aW9uKSAoWS9OKQ0NQ01DIChZL04p DQ1QS0lYLUNNUCAoWS9OKQ0NQ0VQIChZL04pDQ1DUlMgKFkvTikNDUZvciBJUENvbXAgKFJGQyAy MzkzKS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0NQ29tcHJlc3Npb24gYWxnb3JpdGhtcy0NDURFRkxBVEUgLSBSRkMgMjM5NCAoWS9OKQ0N TFpTLVJGQyAyMzk1IChZL04pDQ1OZWdvdGlhdGlvbiBtZWNoYW5pc20tDQ1JS0UgKFkvTikNDU1h bnVhbGx5LWNvbmZpZ3VyZWQgKFkvTikNDU5lZ290aWF0ZWQgd2l0aC0NDUVTUC9BSCAoWS9OKQ0N U3RhbmRhbG9uZSAoWS9OKQ0NPT09PT1QUFA9PT09PVBQUD09PT09UFBQPT09PT1QUFA9PT09PSBQ UFA9PT09PQ0NTENQIE9wdGlvbnM6IA0NRGVmYXVsdCBNUlVfX19fX19fX19fX19fX19fX19fX19f X19fXyANDURlZmF1bHQgTVJSVV9fX19fX19fX19fX19fX19fX19fX19fX18gDQ1BdXRoZW50aWNh dGlvbjogDQ1DSEFQIGF1dGhlbnRpY2F0b3IgKFkvTikgDQ1DSEFQIGF1dGhlbnRpY2F0ZWUgKFkv TikgDQ1DSEFQIFJlLWNoYWxsZW5nZSAoWS9OKSANDU1TIENIQVAgKFkvTikNDU1TIENIQVAgVjIg KFkvTikNICANQ29tcHJlc3Npb246DQ1TVEFDIChZL04pDQ1TVEFDIERDUCAoWS9OKQ0NU1RBQyBP cHRpb25zIF9fX19fX19fXw0NTVBQQyAoWS9OKQ0NTVBQRSAoWS9OKQ0NV0NQIChZL04pDQ1QcmVk aWN0b3IgKFkvTikNDU90aGVyX19fX19fX19fX19fX19fX19fDQ1JUENQOg0NTnVtYmVyZWQgbGlu a3MgKFkvTikgDQ1Vbi1udW1iZXJlZCBsaW5rcyAoWS9OKSANDVR4IGlmIFVuLW51bWJlcmVkX19f X19fX19fX19fIA0NT3B0aW9ucyBzdXBwb3J0ZWRfX19fX19fX19fX18gDQ1JUCBhc3NpZ25tZW50 IChZL04pIA0NSVAgUG9vbCAoWS9OKSANDURIQ1AgKFkvTikNIA1JUFhDUDogDQ1OdW1iZXJlZCBs aW5rcyAoWS9OKSANDVVuLW51bWJlcmVkIGxpbmtzIChZL04pIA0NVHggaWYgVW4tbnVtYmVyZWRf X19fX19fX19fX18gDQ1PcHRpb25zIHN1cHBvcnRlZF9fX19fX19fX19fXw0NDT09PT09TDJUUD09 PT09TDJUUD09PT09TDJUUD09PT09TDJUUD09PT09TDJUUD0NDVByb3ZpZGUgTEFDIChZL04pIA0N UHJvdmlkZSBMTlMgKFkvTikgDQ1Qcm92aWRlIEwyVFAgQ2xpZW50IChZL04pIA0NTDJUUCBBY2Nl c3MgQ29uY2VudHJhdG9yIChMQUMpIE9wdGlvbnM6IA0NUHJveHkgTENQIChZL04pIA0NUHJveHkg QXV0aGVudGljYXRpb24gUEFQIChZL04pIA0NUHJveHkgQXV0aGVudGljYXRpb24gQ0hBUCAoWS9O KQ0NUHJveHkgQXV0aGVudGljYXRpb24gTVMtQ0hBUCAoWS9OKSANDVR1bm5lbCBBdXRoZW50aWNh dGlvbiAoWS9OKSANDUhpZGRlbiBBVlBzIChZL04pIA0NT3V0Z29pbmcgQ2FsbHMgKFkvTikgDQ1T ZXF1ZW5jaW5nIChZL04pDQ1MMlRQIHNlY3VyZWQgYnkgSVBTZWMgKFJlcWQvT3B0aW9uYWwvTm8p X19fX19fX19fX18NDUlmIHllcywgSUtFIGF1dGhlbnRpY2F0aW9uIHVzaW5nIGlkZW50aXR5IHBy b3RlY3Qgb3IgYWdncmVzc2l2ZSBtb2RlX19fX19fX19fXw0NSWYgeWVzLCBJS0UgYXV0aGVudGlj YXRpb24gdXNpbmcgKG1hY2hpbmUvdXNlci9vdGhlcikgY3JlZGVudGlhbF9fX19fX19fX19fDQ1J ZiB5ZXMsIElLRSBhdXRoZW50aWNhdGlvbiAocHJlLXNoYXJlZCBrZXkgb25seS9jZXJ0cyBvbmx5 L2JvdGgvb3RoZXIpX19fX19fX19fXw0NTDJUUCBOZXR3b3JrIFNlcnZlciAoTE5TKSBPcHRpb25z OiANDVByb3h5IExDUCAoWS9OKSANDVByb3h5IEF1dGhlbnRpY2F0aW9uIFBBUCAoWS9OKSANDVBy b3h5IEF1dGhlbnRpY2F0aW9uIENIQVAgKFkvTikNDVByb3h5IEF1dGhlbnRpY2F0aW9uIE1TLUNI QVAgKFkvTikNDVR1bm5lbCBBdXRoZW50aWNhdGlvbiAoWS9OKSANDUhpZGRlbiBBVlBzIChZL04p IA0NT3V0Z29pbmcgQ2FsbHMgKFkvTikgDQ1TZXF1ZW5jaW5nIChZL04pDQ1NUCAoYnVuZGxlIHR1 bm5lbGVkIGxpbmtzKSAoWS9OKQ0NRUNQIChZL04pDQ1DQ1AgKFkvTikNDUFsZ29yaXRobXNfX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NDUNCQ1AgKFkvTikNDUwyVFAgc2VjdXJlZCBieSBJ UFNlYyAoUmVxZC9PcHRpb25hbC9ObylfX19fX19fX19fXw0NSWYgeWVzLCBJS0UgYXV0aGVudGlj YXRpb24gdXNpbmcgaWRlbnRpdHkgcHJvdGVjdCBvciBhZ2dyZXNzaXZlIG1vZGVfX19fX19fX19f DQ1JZiB5ZXMsIElLRSBhdXRoZW50aWNhdGlvbiB1c2luZyAobWFjaGluZS91c2VyL290aGVyKSBj cmVkZW50aWFsX19fX19fX19fX18NDUlmIHllcywgSUtFIGF1dGhlbnRpY2F0aW9uIChwcmUtc2hh cmVkIGtleSBvbmx5L2NlcnRzIG9ubHkvYm90aC9vdGhlcilfX19fX19fX19fDQ1UdW5uZWwgVHlw ZXMtDQ1Wb2x1bnRhcnkgKFkvTikNDUNvbXB1bHNvcnkgKFkvTikNDUNsaWVudCBMMlRQIE9wdGlv bnM6IA0NVHVubmVsIEF1dGhlbnRpY2F0aW9uIChZL04pIA0NSGlkZGVuIEFWUHMgKFkvTikgDQ1P dXRnb2luZyBDYWxscyAoWS9OKQ0NU2VxdWVuY2luZyAoWS9OKQ0NTDJUUCBzZWN1cmVkIGJ5IElQ U2VjIChSZXFkL09wdGlvbmFsL05vKV9fX19fX19fX19fDQ1JZiB5ZXMsIElLRSBhdXRoZW50aWNh dGlvbiB1c2luZyBpZGVudGl0eSBwcm90ZWN0IG9yIGFnZ3Jlc3NpdmUgbW9kZV9fX19fX19fX18N DUlmIHllcywgSUtFIGF1dGhlbnRpY2F0aW9uIHVzaW5nIChtYWNoaW5lL3VzZXIvb3RoZXIpIGNy ZWRlbnRpYWxfX19fX19fX19fXw0NSWYgeWVzLCBJS0UgYXV0aGVudGljYXRpb24gKHByZS1zaGFy ZWQga2V5IG9ubHkvY2VydHMgb25seS9ib3RoL290aGVyKV9fX19fX19fX18NDT09PT09UFBUUD09 PT09UFBUUD09PT09UFBUUD09PT09UFBUUD09PT09UFBUUD0NDVBBQyAoWS9OKQ0NUE5TIChZL04p DQ1QUFRQIENsaWVudCAoWS9OKQ0NUFBUUCBPcHRpb25zIC0gUEFDOg0NT3V0Z29pbmcgY2FsbHMg KFkvTikNDUluY29taW5nIGNhbGxzIChZL04pDQ1QUFRQIHNlY3VyZWQgYnkgSVBTZWMgKFJlcWQv T3B0aW9uYWwvTm8pX19fX19fX19fX18NDVJpbmctdGltZSB0dW5uZWwgKFkvTikNDVVzZXJuYW1l LWJhc2VkIHR1bm5lbCAoWS9OKQ0NUFBUUCBPcHRpb25zIC0gUE5TOg0NT3V0Z29pbmcgY2FsbHMg KFkvTikNDUluY29taW5nIGNhbGxzIChZL04pDQ1NUCAoYnVuZGxlIHR1bm5lbGVkIGxpbmtzKSAo WS9OKQ0NTVBQRSAoWS9OKQ0NQ0NQIChZL04pDQ1BbGdvcml0aG1zX19fX19fX19fX19fX18NDVBQ VFAgc2VjdXJlZCBieSBJUFNlYyAoUmVxZC9PcHRpb25hbC9ObylfX19fX19fX19fXw0NVHVubmVs IHR5cGVzIC0gDQ1Wb2x1bnRhcnkgKFkvTikNDUNvbXB1bHNvcnkgKFkvTikNDVBQVFAgT3B0aW9u cyAtIENsaWVudDoNDU1QUEUgKFkvTikNDUNDUCAoWS9OKQ0NQWxnb3JpdGhtc19fX19fX19fX19f X19fDQ1QUFRQIHNlY3VyZWQgYnkgSVBTZWMgKFJlcWQvT3B0aW9uYWwvTm8pX19fX19fX19fX18N DT09PT09RUFQPT09PT1FQVA9PT09PUVBUCA9PT09PUVBUCA9PT09PSBFQVA9PQ0NSWRlbnRpdHkg KFkvTikgICAgICAgICAgTnVtYmVyIG9mIHJldHJpZXNfX19fX19fX19fDQ1Ob3RpZmljYXRpb24g KFkvTikNDU5hayAocmVzcG9uc2Ugb25seSkgKFkvTikNDU1ENS1DaGFsbGVuZ2UgKFkvTikNDVMv S2V5IChSRkMgMTc2MCkgKFkvTikNDUdlbmVyaWMgVG9rZW4gQ2FyZCAoWS9OKQ0NUkFESVVTIEVB UC1Qcm94eSAoWS9OKQ0NT3RoZXJfX19fX19fX19fX19fX19fX19fX19fX18NDT09PT09UFBQb0U9 PT09PSBQUFBvRSA9PT09PSBQUFBvRSA9PT09PSBQUFBvRSA9PQ0NQ2xpZW50Og0NQ2FuIHNlbGVj dCBmcm9tIG11bHRpcGxlIHNlcnZpY2VzIChZL04pDQ1BQy1Db29raWUgVGFnIChZL04pDQ1Ib3N0 LVVuaXEgVGFnIChZL04pDQ1SZWxheS1TZXNzaW9uLUlkIChZL04pDQ1QUFBvRSBBY3RpdmUgRGlz Y292ZXJ5IFRlcm1pbmF0ZSAoUEFEVCkgcGFja2V0IChZL04pDQ1TZXJ2ZXI6DQ1DYW4gb2ZmZXIg bXVsdGlwbGUgc2VydmljZXMgKFkvTikNDSBBQy1Db29raWUgVGFnIChZL04pDQ1Ib3N0LVVuaXEg VGFnIChZL04pDQ1SZWxheS1TZXNzaW9uLUlkIChZL04pDQ1QUFBvRSBBY3RpdmUgRGlzY292ZXJ5 IFRlcm1pbmF0ZSAoUEFEVCkgcGFja2V0IChZL04pDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABAAAfhUAAH8VAADBGgAAwhoAAPgaAAD5GgAA+hoAACQbAAAlGwAAJhsAAC4bAAAvGwAA VxsAAFgbAABZGwAAbhsAAG8bAABwGwAAkiEAAJMhAADGJAAAICcAAEgnAABJJwAAeScAAHonAAB7 JwAAmScAAJonAAAyKQAA9yoAAPdHAAD3SAAAPkwAAD9MAACXYgAAmGIAABtkAAD58fnm+djm1eYA +eb5x+bV5gD58fnA+eb5suau5vnA+cD5pvmm+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA41CIFD ShgAaAgAbkgJBAAGPioBQioCABoCCIEDavwBAAAGCAFDShgAVQgBaAgAbkgJBAAMQ0oYAE9KAABR SgAAABoCCIEDaiEBAAAGCAFDShgAVQgBaAgAbkgJBAAEMEoPAAAaAgiBA2oAAAAABggBQ0oYAFUI AWgIAG5ICQQAFANqAAAAAENKGABVCAFoCABuSAkEAA5CKgZDShgAaAgAbkgJBAALQ0oYAGgIAG5I CQQAJgAEAABuBAAAyAQAAMkEAADsBAAA7QQAADAGAAAxBgAAlgYAAJcGAACrBgAAxwYAAM8GAADZ BgAA+QYAABgHAABOBwAAkQcAALoHAADjBwAA/QcAAAoIAAAYCAAAHQgAAB4IAACvCAAAsAgAADcJ AAA4CQAAAAoAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEk AAAdAAQAAG4EAADIBAAAyQQAAOwEAADtBAAAMAYAADEGAACWBgAAlwYAAKsGAADHBgAAzwYAANkG AAD5BgAAGAcAAE4HAACRBwAAugcAAOMHAAD9BwAACggAABgIAAAdCAAAHggAAK8IAACwCAAANwkA ADgJAAAACgAAAQoAAO0KAADuCgAA/AoAAP0KAABcDAAAXQwAAF4MAABpDAAAagwAAIIMAACDDAAA zAwAAM0MAADmDAAA5wwAABINAAAvDQAASw0AAEwNAABmDQAAZw0AAJINAACvDQAAyw0AAMwNAADo DQAA6Q0AABQOAAAxDgAATQ4AAGoOAACNDgAAjg4AAKkOAACqDgAA1Q4AAPIOAAAODwAADw8AACgP AAApDwAAVA8AAHEPAACRDwAAsQ8AALIPAACzDwAAug8AALsPAAAFEgAABhIAABMSAAAUEgAAJhIA ACcSAABLEwAATBMAAGgTAABpEwAAfxQAAIAUAADGFQAAxxUAABMWAAAUFgAA7hYAAO8WAABGFwAA RxcAAHAYAAD+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+AAAAAAIB AWQACgAAAQoAAO0KAADuCgAA/AoAAP0KAABcDAAAXQwAAF4MAABpDAAAagwAAIIMAACDDAAAzAwA AM0MAADmDAAA5wwAABINAAAvDQAASw0AAEwNAABmDQAAZw0AAJINAACvDQAAyw0AAMwNAADoDQAA 6Q0AABQOAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAA HRQOAAAxDgAATQ4AAGoOAACNDgAAjg4AAKkOAACqDgAA1Q4AAPIOAAAODwAADw8AACgPAAApDwAA VA8AAHEPAACRDwAAsQ8AALIPAACzDwAAug8AALsPAAAFEgAABhIAABMSAAAUEgAAJhIAACcSAABL EwAATBMAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAEAAAMAADEkAAAd TBMAAGgTAABpEwAAfxQAAIAUAADGFQAAxxUAABMWAAAUFgAA7hYAAO8WAABGFwAARxcAAHAYAABx GAAAMxkAADQZAACbGQAAnBkAABYaAAAXGgAANRoAAF0aAACbGgAAJhsAAHAbAABxGwAAvxwAAMAc AAA6HQAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB1w GAAAcRgAADMZAAA0GQAAmxkAAJwZAAAWGgAAFxoAADUaAABdGgAAmxoAACYbAABwGwAAcRsAAL8c AADAHAAAOh0AADsdAACuHQAArx0AAP4dAAD/HQAAch4AAHMeAACTHgAAqR4AAL0eAADVHgAAJh8A ACcfAAAyIAAAMyAAACohAAArIQAAKyIAACwiAABHIwAASCMAAFkjAABaIwAA6CMAAOkjAAAJJAAA HyQAADMkAABdJAAAXiQAAMUkAADGJAAAWCYAAHkmAACUJgAAqSYAAMQmAADgJgAAAScAACAnAAAh JwAAmycAAJwnAACsJwAArScAAHsoAAB8KAAAMSkAADIpAAD3KgAA+CoAAAIrAAADKwAALiwAAC8s AAA/LAAAQCwAAMotAADLLQAA2i0AANstAACBLwAAgi8AAI4wAACPMAAACzEAAAwxAABuMQAAbzEA AJ4xAACfMQAAzzEAANAxAABZMgAAWjIAAFsyAACkMgAAzzIAANAyAAD6MgAA+zIAACUzAAAmMwAA UjMAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZDod AAA7HQAArh0AAK8dAAD+HQAA/x0AAHIeAABzHgAAkx4AAKkeAAC9HgAA1R4AACYfAAAnHwAAMiAA ADMgAAAqIQAAKyEAACsiAAAsIgAARyMAAEgjAABZIwAAWiMAAOgjAADpIwAACSQAAB8kAAAzJAAA XSQAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEkAAAdXSQA AF4kAADFJAAAxiQAAFgmAAB5JgAAlCYAAKkmAADEJgAA4CYAAAEnAAAgJwAAIScAAJsnAACcJwAA rCcAAK0nAAB7KAAAfCgAADEpAAAyKQAA9yoAAPgqAAACKwAAAysAAC4sAAAvLAAAPywAAEAsAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQABGE0AIAARAAAwAAMSQAABxALAAA yi0AAMstAADaLQAA2y0AAIEvAACCLwAAjjAAAI8wAAALMQAADDEAAG4xAABvMQAAnjEAAJ8xAADP MQAA0DEAAFkyAABaMgAAWzIAAKQyAADPMgAA0DIAAPoyAAD7MgAAJTMAACYzAABSMwAAUzMAAH8z AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHVIzAABT MwAAfzMAAIAzAACzMwAAtDMAAOQzAADlMwAADzQAABA0AAA6NAAAOzQAAGU0AABmNAAArjQAAK80 AADzNAAA9DQAAAk1AAAKNQAATzUAAFA1AACbNQAAnDUAANA1AADRNQAABTYAAAY2AAA6NgAAOzYA AG82AABwNgAAfzYAAIA2AADHNgAAyDYAABY3AAAXNwAAJzcAACg3AABKNwAAZjcAAH03AACyNwAA +zcAAAg4AAAJOAAAOjgAADs4AAAIOQAACTkAADI5AAAzOQAAXTkAAF45AACKOQAAizkAALc5AAC4 OQAA6zkAAOw5AAAcOgAAHToAAEc6AABIOgAAcjoAAHM6AACdOgAAnjoAAAA7AAABOwAAnjsAAKA7 AAChOwAAAjwAAAQ8AAAfPAAAIDwAADs8AAA8PAAAVjwAAFg8AABZPAAAgjwAAIM8AACWPAAAlzwA AN48AADfPAAA7TwAAO48AAAJPQAART0AAEY9AABiPQAAqT0AAKo9AADKPQAAyz0AAAM+AAAEPgAA /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAACAQFkfzMAAIAz AACzMwAAtDMAAOQzAADlMwAADzQAABA0AAA6NAAAOzQAAGU0AABmNAAArjQAAK80AADzNAAA9DQA AAk1AAAKNQAATzUAAFA1AACbNQAAnDUAANA1AADRNQAABTYAAAY2AAA6NgAAOzYAAG82AABwNgAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB1wNgAAfzYA AIA2AADHNgAAyDYAABY3AAAXNwAAJzcAACg3AABKNwAAZjcAAH03AACyNwAA+zcAAAg4AAAJOAAA OjgAADs4AAAIOQAACTkAADI5AAAzOQAAXTkAAF45AACKOQAAizkAALc5AAC4OQAA6zkAAOw5AAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHew5AAAcOgAA HToAAEc6AABIOgAAcjoAAHM6AACdOgAAnjoAAAA7AAABOwAAnjsAAKA7AAChOwAAAjwAAAQ8AAAf PAAAIDwAADs8AAA8PAAAVjwAAFg8AABZPAAAgjwAAIM8AACWPAAAlzwAAN48AADfPAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAMSQAD4TQAgMAADEkAAAc3zwAAO08AADu PAAACT0AAEU9AABGPQAAYj0AAKk9AACqPQAAyj0AAMs9AAADPgAABD4AABk+AAAaPgAAKz4AACw+ AABSPgAAUz4AAIY+AACHPgAAvD4AAL0+AAAEPwAABT8AACQ/AAAlPwAAMj8AADM/AAA9PwAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB0EPgAAGT4AABo+ AAArPgAALD4AAFI+AABTPgAAhj4AAIc+AAC8PgAAvT4AAAQ/AAAFPwAAJD8AACU/AAAyPwAAMz8A AD0/AAA+PwAARj8AAEc/AABRPwAAUj8AAG8/AABwPwAAlT8AAJY/AACqPwAAqz8AAL8/AADAPwAA 2D8AANk/AADjPwAA5D8AAO8/AADwPwAAEEAAABFAAAAkQAAAJUAAADlAAAA6QAAARUAAAEZAAACN QAAAjkAAAKVAAACmQAAAuEAAALlAAAC6QAAAA0EAAARBAAAjQQAAJEEAABVCAAAWQgAAI0MAACVD AAAuQwAAPUMAAD5DAABmQwAAZ0MAAIxDAACNQwAAzEMAAM1DAAAXRAAAGEQAADdEAAA4RAAAQUQA AFBEAABRRAAAeUQAAHpEAACfRAAAoEQAAN9EAADgRAAAKkUAACtFAABKRQAAS0UAAFRFAABjRQAA ZEUAAIxFAACNRQAAskUAALNFAADyRQAA80UAAD1GAAA+RgAAXUYAAF5GAABfRgAAjUYAAP7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZD0/AAA+PwAARj8A AEc/AABRPwAAUj8AAG8/AABwPwAAlT8AAJY/AACqPwAAqz8AAL8/AADAPwAA2D8AANk/AADjPwAA 5D8AAO8/AADwPwAAEEAAABFAAAAkQAAAJUAAADlAAAA6QAAARUAAAEZAAACNQAAAjkAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEkAAAdjkAAAKVAAACmQAAA uEAAALlAAAC6QAAAA0EAAARBAAAjQQAAJEEAABVCAAAWQgAAI0MAACVDAAAuQwAAPUMAAD5DAABm QwAAZ0MAAIxDAACNQwAAzEMAAM1DAAAXRAAAGEQAADdEAAA4RAAAQUQAAFBEAABRRAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB1RRAAAeUQAAHpEAACf RAAAoEQAAN9EAADgRAAAKkUAACtFAABKRQAAS0UAAFRFAABjRQAAZEUAAIxFAACNRQAAskUAALNF AADyRQAA80UAAD1GAAA+RgAAXUYAAF5GAABfRgAAjUYAAI5GAADPRgAA0EYAAOlGAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHY1GAACORgAAz0YAANBG AADpRgAA6kYAAA1HAAAORwAAHkcAAB9HAAAyRwAAM0cAAERHAABFRwAAWUcAAFpHAAD2RwAA90cA APdIAAD4SAAAj0kAAJBJAACnSQAAqEkAALZJAAC3SQAAwkkAAMNJAADZSQAA2kkAAOVJAADmSQAA 8kkAAPNJAAADSgAABEoAABBKAAARSgAAHkoAAB9KAAAzSgAANEoAAERKAABFSgAAVkoAAFdKAABu SgAAb0oAAH5KAAB/SgAAj0oAAJBKAAChSgAAokoAALlKAAC6SgAA1UoAANZKAADgSgAA4UoAAO9K AADwSgAAIEsAACFLAAAwSwAAMUsAAFpLAABbSwAAcksAAHNLAACFSwAAhksAAJNLAACUSwAAwksA AMNLAADZSwAA2ksAAPZLAAD3SwAADEwAAA1MAAAiTAAAI0wAAD9MAABATAAAVUwAAFZMAABrTAAA bEwAAIJMAACDTAAAoUwAAKJMAAC8TAAAvUwAAM5MAADPTAAA4UwAAOJMAAAQTQAA/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAACAQFk6UYAAOpGAAANRwAADkcA AB5HAAAfRwAAMkcAADNHAABERwAARUcAAFlHAABaRwAA9kcAAPdHAAD3SAAA+EgAAI9JAACQSQAA p0kAAKhJAAC2SQAAt0kAAMJJAADDSQAA2UkAANpJAADlSQAA5kkAAPJJAADzSQAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAARAAAwAAMSQAAB3zSQAAA0oAAARKAAAQSgAA EUoAAB5KAAAfSgAAM0oAADRKAABESgAARUoAAFZKAABXSgAAbkoAAG9KAAB+SgAAf0oAAI9KAACQ SgAAoUoAAKJKAAC5SgAAukoAANVKAADWSgAA4EoAAOFKAADvSgAA8EoAACBLAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHSBLAAAhSwAAMEsAADFLAABa SwAAW0sAAHJLAABzSwAAhUsAAIZLAACTSwAAlEsAAMJLAADDSwAA2UsAANpLAAD2SwAA90sAAAxM AAANTAAAIkwAACNMAAA/TAAAQEwAAFVMAABWTAAAa0wAAGxMAACCTAAAg0wAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEkAAAdg0wAAKFMAACiTAAAvEwAAL1M AADOTAAAz0wAAOFMAADiTAAAEE0AABFNAAA1TQAANk0AAExNAABNTQAAd00AAHhNAACNTQAAjk0A AL9NAADATQAA200AANxNAADmTQAA500AAPJNAADzTQAA/k0AAP9NAAAJTgAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB0QTQAAEU0AADVNAAA2TQAATE0A AE1NAAB3TQAAeE0AAI1NAACOTQAAv00AAMBNAADbTQAA3E0AAOZNAADnTQAA8k0AAPNNAAD+TQAA /00AAAlOAAAKTgAAGU4AABpOAAAlTgAAJk4AAD5OAAA/TgAAVE4AAFVOAABgTgAAYU4AAG1OAABu TgAAjk4AAI9OAAChTgAAok4AAMROAADFTgAA+04AAPxOAABATwAAQU8AAJBPAACRTwAAy08AAMxP AAD5TwAA+k8AADNQAAA0UAAAqlAAAKtQAADSUAAA01AAAOVQAADmUAAA8VAAAPJQAAD8UAAA/VAA AAdRAAAIUQAAFFEAABVRAABbUQAAXFEAAKNRAACkUQAA0VEAANJRAADsUQAA7VEAAPhRAAD5UQAA A1IAAARSAAAOUgAAD1IAABtSAAAdUgAAMFIAADJSAABDUgAARFIAAFZSAABXUgAAf1IAAIBSAACb UgAAnFIAAMlSAADKUgAA91IAAPhSAAAVUwAAFlMAACVTAAAmUwAAN1MAAP7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZAlOAAAKTgAAGU4AABpOAAAlTgAA Jk4AAD5OAAA/TgAAVE4AAFVOAABgTgAAYU4AAG1OAABuTgAAjk4AAI9OAAChTgAAok4AAMROAADF TgAA+04AAPxOAABATwAAQU8AAJBPAACRTwAAy08AAMxPAAD5TwAA+k8AAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEkAAAd+k8AADNQAAA0UAAAqlAAAKtQAADS UAAA01AAAOVQAADmUAAA8VAAAPJQAAD8UAAA/VAAAAdRAAAIUQAAFFEAABVRAABbUQAAXFEAAKNR AACkUQAA0VEAANJRAADsUQAA7VEAAPhRAAD5UQAAA1IAAARSAAAOUgAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB0OUgAAD1IAABtSAAAdUgAAMFIAADJS AABDUgAARFIAAFZSAABXUgAAf1IAAIBSAACbUgAAnFIAAMlSAADKUgAA91IAAPhSAAAVUwAAFlMA ACVTAAAmUwAAN1MAADhTAABIUwAASVMAAG1TAABuUwAAr1MAALBTAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHTdTAAA4UwAASFMAAElTAABtUwAAblMA AK9TAACwUwAAIVQAACJUAAAsVAAALVQAADxUAAA9VAAAR1QAAEhUAABSVAAAU1QAAKJUAACjVAAA u1QAALxUAADVVAAA1lQAAOlUAADqVAAAAVUAAAJVAAAMVQAADVUAACdVAAAoVQAAOVUAADpVAABH VQAASFUAAFlVAABaVQAAiVUAAIpVAACYVQAAmVUAAMBVAADBVQAA6FUAAOlVAAD6VQAA+1UAABVW AAAWVgAAMFYAADFWAABKVgAAS1YAAFlWAABaVgAAa1YAAG5WAAB7VgAAfFYAAIdWAACIVgAAl1YA AJhWAACvVgAAsFYAALtWAAC8VgAAx1YAAMhWAADSVgAA01YAAONWAADkVgAA/FYAAP1WAAADVwAA BFcAABpXAAAbVwAANFcAADVXAABUVwAAVVcAAHRXAAB1VwAAilcAAItXAACaVwAAm1cAAKZXAACo VwAAsFcAALFXAADHVwAAyFcAAOFXAADiVwAAAVgAAAJYAAAgWAAA/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAACAQFksFMAACFUAAAiVAAALFQAAC1UAAA8VAAA PVQAAEdUAABIVAAAUlQAAFNUAACiVAAAo1QAALtUAAC8VAAA1VQAANZUAADpVAAA6lQAAAFVAAAC VQAADFUAAA1VAAAnVQAAKFUAADlVAAA6VQAAR1UAAEhVAABZVQAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB1ZVQAAWlUAAIlVAACKVQAAmFUAAJlVAADA VQAAwVUAAOhVAADpVQAA+lUAAPtVAAAVVgAAFlYAADBWAAAxVgAASlYAAEtWAABZVgAAWlYAAGtW AABuVgAAe1YAAHxWAACHVgAAiFYAAJdWAACYVgAAr1YAALBWAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHbBWAAC7VgAAvFYAAMdWAADIVgAA0lYAANNW AADjVgAA5FYAAPxWAAD9VgAAA1cAAARXAAAaVwAAG1cAADRXAAA1VwAAVFcAAFVXAAB0VwAAdVcA AIpXAACLVwAAmlcAAJtXAACmVwAAqFcAALBXAACxVwAAx1cAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEkAAAdx1cAAMhXAADhVwAA4lcAAAFYAAACWAAAIFgA ACFYAAAiWAAAUVgAAFJYAABlWAAAZlgAAHlYAAB6WAAAlVgAAJZYAAC/WAAAwFgAANFYAADSWAAA 8lgAAPNYAAATWQAAFFkAADhZAAA5WQAAVlkAAFdZAABqWQAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB0gWAAAIVgAACJYAABRWAAAUlgAAGVYAABmWAAA eVgAAHpYAACVWAAAllgAAL9YAADAWAAA0VgAANJYAADyWAAA81gAABNZAAAUWQAAOFkAADlZAABW WQAAV1kAAGpZAABrWQAAgVkAAIJZAACTWQAAlFkAAMhZAADJWQAAGFoAABlaAABlWgAAZloAALda AAC4WgAA3FoAAN1aAADuWgAA71oAAA9bAAAQWwAAMFsAADFbAABUWwAAVVsAAHJbAABzWwAAhlsA AIdbAACdWwAAnlsAAK9bAACwWwAA0VsAANJbAADcWwAA3VsAAOdbAADoWwAAEVwAABJcAAAdXAAA HlwAAFJcAABTXAAAolwAAKNcAADvXAAA8FwAAEFdAABCXQAAUF0AAFFdAABhXQAAYl0AAHNdAAB0 XQAAil0AAItdAACoXQAAqV0AALxdAAC9XQAA0l0AANNdAADkXQAA5V0AABleAAAaXgAAaV4AAGpe AAC2XgAAt14AAAhfAAAJXwAAOF8AADlfAABDXwAARF8AAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAgEBZGpZAABrWQAAgVkAAIJZAACTWQAAlFkAAMhZAADJ WQAAGFoAABlaAABlWgAAZloAALdaAAC4WgAA3FoAAN1aAADuWgAA71oAAA9bAAAQWwAAMFsAADFb AABUWwAAVVsAAHJbAABzWwAAhlsAAIdbAACdWwAAnlsAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAAAAAAAAAAAAMAADEkAAAdnlsAAK9bAACwWwAA0VsAANJbAADcWwAA3VsAAOdb AADoWwAAEVwAABJcAAAdXAAAHlwAAFJcAABTXAAAolwAAKNcAADvXAAA8FwAAEFdAABCXQAAUF0A AFFdAABhXQAAYl0AAHNdAAB0XQAAil0AAItdAACoXQAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAAAAAAAAAAAAwAAMSQAAB2oXQAAqV0AALxdAAC9XQAA0l0AANNdAADkXQAA5V0A ABleAAAaXgAAaV4AAGpeAAC2XgAAt14AAAhfAAAJXwAAOF8AADlfAABDXwAARF8AAE5fAABPXwAA YV8AAGJfAAB2XwAAd18AAIxfAACNXwAAol8AAKNfAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAAAAAAAAAAADAAAxJAAAHURfAABOXwAAT18AAGFfAABiXwAAdl8AAHdfAACMXwAA jV8AAKJfAACjXwAA118AANhfAADvXwAA8F8AAAxgAAANYAAAIWAAACJgAAA3YAAAOGAAAE1gAABO YAAAb2AAAHBgAAB7YAAAfGAAAIZgAACHYAAAoGAAAKFgAADVYAAA1mAAAOZgAADnYAAA92AAAPhg AAAJYQAACmEAACFhAAAiYQAALWEAAC5hAAA4YQAAOWEAAFJhAABTYQAAh2EAAIhhAAC2YQAAt2EA AOthAADsYQAA/2EAAABiAAAaYgAAG2IAAC9iAAAwYgAAR2IAAEhiAABhYgAAYmIAAHliAAB6YgAA mGIAAJliAADKYgAAy2IAANNiAADUYgAA/GIAAP1iAAARYwAAEmMAACZjAAAnYwAAPmMAAD9jAAB0 YwAAdWMAAH1jAAB+YwAAoGMAAKFjAAC2YwAAt2MAAMtjAADMYwAA42MAAORjAAAZZAAAGmQAABtk AAD+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAACAQFdo18AANdfAADYXwAA718AAPBfAAAMYAAADWAAACFgAAAi YAAAN2AAADhgAABNYAAATmAAAG9gAABwYAAAe2AAAHxgAACGYAAAh2AAAKBgAAChYAAA1WAAANZg AADmYAAA52AAAPdgAAD4YAAACWEAAAphAAAhYQAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAAAAAAAAAAAAwAAMSQAAB0hYQAAImEAAC1hAAAuYQAAOGEAADlhAABSYQAAU2EAAIdh AACIYQAAtmEAALdhAADrYQAA7GEAAP9hAAAAYgAAGmIAABtiAAAvYgAAMGIAAEdiAABIYgAAYWIA AGJiAAB5YgAAemIAAJhiAACZYgAAymIAAMtiAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAAAAAAAAAAADAAAxJAAAHctiAADTYgAA1GIAAPxiAAD9YgAAEWMAABJjAAAmYwAAJ2MA AD5jAAA/YwAAdGMAAHVjAAB9YwAAfmMAAKBjAAChYwAAtmMAALdjAADLYwAAzGMAAONjAADkYwAA GWQAABpkAAAbZAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAMAADEkAAAZIwASMAAcUAEAH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAhAQAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAr AAAAaAB0AHQAcABzADoALwAvAG8AbgBzAGkAdABlAC0AdABlAHMAdAAtAGYAZQAuAGIAYgB0AGUA cwB0AC4AbgBlAHQALwBiAGEAawBlAG8AZgBmAC8AAADgyep5+brOEYyCAKoAS6kLVgAAAGgAdAB0 AHAAcwA6AC8ALwBvAG4AcwBpAHQAZQAtAHQAZQBzAHQALQBmAGUALgBiAGIAdABlAHMAdAAuAG4A ZQB0AC8AYgBhAGsAZQBvAGYAZgAvAAAA2wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAX AAAAFgAAAHAAYQB1AGwALgBoAG8AZgBmAG0AYQBuAEAAdgBwAG4AYwAuAG8AcgBnAAAA4Mnqefm6 zhGMggCqAEupCzoAAABtAGEAaQBsAHQAbwA6AHAAYQB1AGwALgBoAG8AZgBmAG0AYQBuAEAAdgBw AG4AYwAuAG8AcgBnAAAA/QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAHgAAAHcA dwB3AC4AZgBlAHMAcwBwAGEAcgBrAGUAcgBzAGQAbwB1AGIAbABlAHQAcgBlAGUALgBjAG8AbQAA AODJ6nn5us4RjIIAqgBLqQtMAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGYAZQBzAHMAcABhAHIA awBlAHIAcwBkAG8AdQBiAGwAZQB0AHIAZQBlAC4AYwBvAG0ALwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgASAAoAAQBbAA8AAgAAAAAAAAAkAABA8f8CACQAAAAGAE4AbwByAG0AYQBs AAAAAgAAAAQAbUgJBAAAAAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwA dAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAoAFVAogDxACgAAAAJ AEgAeQBwAGUAcgBsAGkAbgBrAAAABgA+KgFCKgI6AP5P8f8CAToAAAAJAEgAVABNAEwAIABCAG8A ZAB5AAAAAgAQABMAT0oCAFFKAgBoCABtSAkEbkgJBAA4AFZAogARATgAAAARAEYAbwBsAGwAbwB3 AGUAZABIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioMAAAAABtgAAAHAAC4AAAGAP////8ABAAA G2QAADMAAAAABAAAAAoAABQOAABMEwAAOh0AAF0kAABALAAAfzMAAHA2AADsOQAA3zwAAD0/AACO QAAAUUQAAOlGAADzSQAAIEsAAINMAAAJTgAA+k8AAA5SAACwUwAAWVUAALBWAADHVwAAalkAAJ5b AACoXQAAo18AACFhAADLYgAAG2QAADQAAAA2AAAANwAAADgAAAA6AAAAOwAAADwAAAA+AAAAPwAA AEAAAABBAAAAQwAAAEQAAABFAAAARwAAAEgAAABJAAAASgAAAEwAAABNAAAATgAAAFAAAABRAAAA UgAAAFMAAABVAAAAVgAAAFcAAABZAAAAWgAAAFsAAAAABAAAcBgAAFIzAAAEPgAAjUYAABBNAAA3 UwAAIFgAAERfAAAbZAAANQAAADkAAAA9AAAAQgAAAEYAAABLAAAATwAAAFQAAABYAAAAwRYAAPkW AAAkFwAALhcAAFgXAABuFwAASCMAAHojAACZIwAAG2AAABNYFP8VhBNYFP8VhBNYFP8VjP//AwAA AA0AXwBIAGwAdAA0ADYANQA3ADUAMgAxADAANwANAF8ASABsAHQANAA2ADUANwA1ADEAOQA3ADIA DQBfAEgAbAB0ADQANgA1ADcANQAyADAAMwA3AA8XAAASFwAAFxcAAB1gAAAAAAAAAQAAAAIAAAAQ FwAAExcAABgXAAAdYAAAAAAAAEUHAABNBwAAngcAAKMHAADABwAAxgcAAD0IAABECAAA3xMAAOkT AADvEwAA9RMAACMWAAA0FgAAnBYAAKQWAACbIgAAoiIAABMjAAAaIwAA9CUAAP0lAABXUAAAXVAA AB1gAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAA AABVBQAAnAUAAEcTAABvFAAAIxYAADQWAACcFgAApRYAAMUZAADOGQAA5hoAAAIbAABFHAAAShwA AGQdAADCHQAA1yQAAN4kAAALJQAAFCUAAMEsAADFLAAAwS0AAMQtAACWMQAAmTEAAAo5AAALOQAA 4DkAAOQ5AABgOgAAZDoAAJU6AACZOgAAozwAAKQ8AAB/PwAAiT8AAJJAAACcQAAApUEAAK9BAADf QwAA5UMAAFxEAABiRAAA3E0AAONNAACiTgAAqE4AANBOAADWTgAAxF0AANVdAAAdYAAABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwD//xQAAAANAEEA bgBpAHQAYQAgAEYAcgBlAGUAbQBhAG4AVgBDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAE0ATABQAFAAUABKAGEA bgAwADAASQBQAFMARQBDAF8AUABQAFAAXwBhAHAAcABsAGkAYwBhAHQAaQBvAG4AXwB3AG8AcgBr AGkAbgBnAF8AMQAwAC0AMgA1AC4AYQBzAGQADQBBAG4AaQB0AGEAIABGAHIAZQBlAG0AYQBuAEEA QwA6AFwARABhAHQAYQBcAE0ATABQAFAAUABKAGEAbgAwADAAXABNAEwAUABQAFAASgBhAG4AMAAw AEkAUABTAEUAQwBfAFAAUABQAF8AYQBwAHAAbABpAGMAYQB0AGkAbwBuAF8AZgBpAG4AYQBsAF8A MQAxAC0AMgAuAGQAbwBjAA0AQQBuAGkAdABhACAARgByAGUAZQBtAGEAbgBTAEMAOgBcAFcASQBO AEQATwBXAFMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAA bwBmACAATQBMAFAAUABQAEoAYQBuADAAMABJAFAAUwBFAEMAXwBQAFAAUABfAGEAcABwAGwAaQBj AGEAdABpAG8AbgBfAGYAaQBuAGEAbABfADEAMQAtADIALgBhAHMAZAANAEEAbgBpAHQAYQAgAEYA cgBlAGUAbQBhAG4AUwBDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEEAdQB0AG8AUgBl AGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAE0ATABQAFAAUABKAGEAbgAwADAASQBQAFMA RQBDAF8AUABQAFAAXwBhAHAAcABsAGkAYwBhAHQAaQBvAG4AXwBmAGkAbgBhAGwAXwAxADEALQAy AC4AYQBzAGQADQBBAG4AaQB0AGEAIABGAHIAZQBlAG0AYQBuAEEAQwA6AFwARABhAHQAYQBcAE0A TABQAFAAUABKAGEAbgAwADAAXABNAEwAUABQAFAASgBhAG4AMAAwAEkAUABTAEUAQwBfAFAAUABQ AF8AYQBwAHAAbABpAGMAYQB0AGkAbwBuAF8AZgBpAG4AYQBsAF8AMQAxAC0AMgAuAGQAbwBjAA0A QQBuAGkAdABhACAARgByAGUAZQBtAGEAbgBCAEMAOgBcAEQAYQB0AGEAXABNAEwAUABQAFAASgBh AG4AMAAwAFwATQBMAFAAUABQAEoAYQBuADAAMABJAFAAUwBFAEMAXwBQAFAAUABfAGEAcABwAGwA aQBjAGEAdABpAG8AbgBfAGYAaQBuAGEAbABfADEAMQAtADEAMAAuAGQAbwBjAA0AQQBuAGkAdABh ACAARgByAGUAZQBtAGEAbgBCAEMAOgBcAEQAYQB0AGEAXABNAEwAUABQAFAASgBhAG4AMAAwAFwA TQBMAFAAUABQAEoAYQBuADAAMABJAFAAUwBFAEMAXwBQAFAAUABfAGEAcABwAGwAaQBjAGEAdABp AG8AbgBfAGYAaQBuAGEAbABfADEAMQAtADEAMAAuAGQAbwBjAA0AQQBuAGkAdABhACAARgByAGUA ZQBtAGEAbgBUAEMAOgBcAFcASQBOAEQATwBXAFMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBv AHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAATQBMAFAAUABQAEoAYQBuADAAMABJAFAAUwBFAEMA XwBQAFAAUABfAGEAcABwAGwAaQBjAGEAdABpAG8AbgBfAGYAaQBuAGEAbABfADEAMQAtADEAMAAu AGEAcwBkAA0AQQBuAGkAdABhACAARgByAGUAZQBtAGEAbgBCAEMAOgBcAEQAYQB0AGEAXABNAEwA UABQAFAASgBhAG4AMAAwAFwATQBMAFAAUABQAEoAYQBuADAAMABJAFAAUwBFAEMAXwBQAFAAUABf AGEAcABwAGwAaQBjAGEAdABpAG8AbgBfAGYAaQBuAGEAbABfADEAMQAtADIAOAAuAGQAbwBjAA0A QQBuAGkAdABhACAARgByAGUAZQBtAGEAbgA2AEMAOgBcAFcASQBOAEQATwBXAFMAXABEAEUAUwBL AFQATwBQAFwATQBMAFAAUABQAEoAYQBuADAAMABJAFAAUwBFAEMAXwBQAFAAUABfAGEAcABwAGwA aQBjAGEAdABpAG8AbgAuAGQAbwBjAAEAakVFeAEACQT/D/8P/w//D/8P/w//D/8P/w8BANwFAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA AGpFRXgAAAAAAAAAAAAAAAD///////8BAAAAAAD/QAOAAQAaYAAAGmAAAPgy2AABAAAAGmAAAAAA AAAaYAAAAAAAAAIQAAAAAAAAABtgAABwAAAIAEAAAAMAAABHFpABAAACAgYDBQQFAgMEhwIAAAAA AAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAF BQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYE AgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAAIgAEAEAAiAAAANACAABo AQAAAACj5TsGo+U7Bo/lOwYCAAAAAADmDQAAPk8AAAEAKAAAAAQAAwCpAAAAAAAAAAAAAAABAAEA AAABAAAAAAAAACEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAAAA EAAZAGQAAAAZAAAAUGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAAbQAtAC0ALQAtAC0ALQAtAC0A LQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAt AC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0A LQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAt AC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAgAAAAAAAAAA0AQQBuAGkAdABhACAARgByAGUA ZQBtAGEAbgANAEEAbgBpAHQAYQAgAEYAcgBlAGUAbQBhAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA5AEAABEA AAABAAAAkAAAAAIAAACYAAAAAwAAABABAAAEAAAAHAEAAAUAAAA0AQAABwAAAEABAAAIAAAAVAEA AAkAAABsAQAAEgAAAHgBAAAKAAAAlAEAAAsAAACgAQAADAAAAKwBAAANAAAAuAEAAA4AAADEAQAA DwAAAMwBAAAQAAAA1AEAABMAAADcAQAAAgAAAOQEAAAeAAAAbgAAAC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAALQAeAAAAAQAAAAAtLS0eAAAADgAA AEFuaXRhIEZyZWVtYW4ALS0eAAAAAQAAAABuaXQeAAAACwAAAE5vcm1hbC5kb3QAYR4AAAAOAAAA QW5pdGEgRnJlZW1hbgAtLR4AAAACAAAAMgBpdB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAC1A AAAAAAAAAAAAAABAAAAAAArXEDE6vwFAAAAAAIIY3DM6vwFAAAAAAIIY3DM6vwEDAAAAAQAAAAMA AADmDQAAAwAAAD5PAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAE AAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss +a6oAQAAZAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAA AKQAAAALAAAArAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAEYBAAACAAAA 5AQAAB4AAAAUAAAAQ2lzY28gU3lzdGVtcywgSW5jLgADAAAAqQAAAAMAAAAoAAAAAwAAAFBhAAAD AAAAMRUIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAABuAAAALS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIAAMEAAAAgAAAB4A AAAGAAAAVGl0bGUAAwAAAAEAAAA8AgAABAAAAAAAAAAoAAAAAQAAAFIAAAACAAAAWgAAAAMAAACy AAAAAgAAAAIAAAAKAAAAX1BJRF9HVUlEAAMAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAA TgAAAHsARQA1ADQAMQA4AEUANwBEAC0AMQBBADYAQQAtADEAMQBEADIALQA4ADgAMwBDAC0AMwBD ADgAQgAwADAAQwAxADAAMAAwADAAfQAAAAAAQQAAAIABAAASAAAAAwAAABMAWwADAAAABgAAAAMA AAAAAAAAAwAAAAUAAAAfAAAAJgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBmAGUAcwBzAHAAYQBy AGsAZQByAHMAZABvAHUAYgBsAGUAdAByAGUAZQAuAGMAbwBtAC8AAAAfAAAAAQAAAAAAAAADAAAA DgB6AAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8AAAAdAAAAbQBhAGkAbAB0AG8AOgBwAGEAdQBs AC4AaABvAGYAZgBtAGEAbgBAAHYAcABuAGMALgBvAHIAZwAAAAAAHwAAAAEAAAAAAAAAAwAAADUA cAADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAKwAAAGgAdAB0AHAAcwA6AC8ALwBvAG4AcwBp AHQAZQAtAHQAZQBzAHQALQBmAGUALgBiAGIAdABlAHMAdAAuAG4AZQB0AC8AYgBhAGsAZQBvAGYA ZgAvAAAAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAE AAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIA AAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAA ACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9 AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAA AFoAAABbAAAAXAAAAP7///9eAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA/v///2YAAABnAAAA aAAAAGkAAABqAAAAawAAAGwAAABtAAAA/v///28AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAD+ ////dwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAP7////9/////f///4EAAAD+/////v////7/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0 AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///// /////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAOBdb/YzOr8BYIrv9jM6vwGDAAAAgAAAAAAAAABE AGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF0AAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAZQAAAKYQAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEGAAAABQAAAP////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbgAABjmRgAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4AAAAAEAAAYHZEAAUA RABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA//// /wAAAAA4AAIBBAAAAP//////////AgAAAAAAAAAAAAAADQAAAAIAAAAJBAAAAAAAAAAAAAAAAAAA dgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAACwBQAAAAAAAAAAAACIAABEAAAAACAEAAAA AAAA////ADUAAAAAAAAANQAAABIAAgECAAAABwAAAP////8DAAAAAAAAAAAAAACVAwCg1JdAAAAA AAAAAAAAAAAAAAAAAAAAAAAAagAAADhfRgBPAGIAagBlAGMAdABQAG8AbwBsAAAARgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgGDAIFgABAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAYIrv9jM6vwFgiu/2Mzq/AQAAAAAQAAAAAAAAAAEAAAD+//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AQD+/wMKAAD/////BgkCAAAA AADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABX b3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=====================_2517222==_-- From owner-ipsec@lists.tislabs.com Tue Nov 30 05:34:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07105; Tue, 30 Nov 1999 05:34:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20115 Tue, 30 Nov 1999 06:56:08 -0500 (EST) Message-Id: <199911301159.GAA06100@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ext-meth-03.txt Date: Tue, 30 Nov 1999 06:59:32 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : ISAKMP & IKE Extensions Methods Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-ext-meth-03.txt Pages : 13 Date : 29-Nov-99 This document describes multiple extension methods of the ISAKMP [RFC 2408] and IKE [RFC 2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best practice of extensions handling in ISAKMP [RFC 2408] and IKE [RFC 2409], so that a future version can be made without break- ing the old existing versions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ext-meth-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-ext-meth-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991129142206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ext-meth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991129142206.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Nov 30 05:50:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07381; Tue, 30 Nov 1999 05:50:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20109 Tue, 30 Nov 1999 06:55:01 -0500 (EST) Message-Id: <199911301158.GAA05401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-02.txt Date: Tue, 30 Nov 1999 06:58:25 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-02.txt Pages : 10 Date : 29-Nov-99 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shacham-ippcp-rfc2393bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991129130603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991129130603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Nov 30 09:59:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11417; Tue, 30 Nov 1999 09:59:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20408 Tue, 30 Nov 1999 08:36:37 -0500 (EST) Date: Mon, 29 Nov 1999 15:45:26 -0800 (PST) From: bradr@iname.com To: ipsec@lists.tislabs.com Subject: ISAKMP Configuration Method Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Warning: this may be a stupid newbie question--I apologize. After reading through this particular draft as well as searching through the DOI, ISAKMP, and other rfcs and drafts, I am unable to find any value mentioned for the `Next Payload' identifier for the ATTRIBUTE_PAYLOAD of a transaction exchange. Is this specified somewhere else, or did I just overlook it? Is anyone else using the ISAKMP configuration method? Thanks, -brad From owner-ipsec@lists.tislabs.com Tue Nov 30 09:59:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11418; Tue, 30 Nov 1999 09:59:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00744 Tue, 30 Nov 1999 10:59:38 -0500 (EST) Message-Id: <199911301602.IAA15074@gallium.network-alchemy.com> To: bradr@iname.com cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP Configuration Method In-reply-to: Your message of "Mon, 29 Nov 1999 15:45:26 PST." Date: Tue, 30 Nov 1999 08:02:32 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brad, > After reading through this particular draft as well as searching through > the DOI, ISAKMP, and other rfcs and drafts, I am unable to find any value > mentioned for the `Next Payload' identifier for the ATTRIBUTE_PAYLOAD of a > transaction exchange. Is this specified somewhere else, or did I just > overlook it? The ISAKMP Attribute information is not encoded as a separate payload. Instead, it's basically appended to any of the defined payloads. Its format is defined in Section 3.3 of RFC 2408. Derrell From owner-ipsec@lists.tislabs.com Tue Nov 30 10:10:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11644; Tue, 30 Nov 1999 10:10:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20409 Tue, 30 Nov 1999 08:36:37 -0500 (EST) Message-ID: <0e8401bf3abd$22caa8c0$b1c03ac1@jakab> From: "jakab frantisek" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , "sivy" , , , , , , , Subject: Re: Telemedicina and Teleeducation in Practice - ISTEP 2000 Date: Mon, 29 Nov 1999 23:56:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Colleagues: LAST CALL FOR WIP PAPERS ======================== Kindly excuse for interrupting you and asking for the abstract which you intended to send to the organising committee of the ISTEP'2000 Symposium. (International Symposium on Telemedicine and Teleeducation in Practice). The deadline is 31st of November 1999 (http://www.elfa.sk) We are looking forward to meet you in Kosice on the 22-24 of March 2000. Yours sincerely, Frantisek Jakab Chair of the Organizing Committee ISTEP From owner-ipsec@lists.tislabs.com Tue Nov 30 10:49:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12188; Tue, 30 Nov 1999 10:49:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00962 Tue, 30 Nov 1999 11:41:57 -0500 (EST) Message-ID: <3843FF2D.B77C6051@ire-ma.com> Date: Tue, 30 Nov 1999 11:45:33 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: IPSec SA DELETE in "dangling" implementation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is the dilemma: if "dangling" implementation wants to send IPSec SA DELETE message, while the "parent" IKE SA is no longer there (expired or deleted), the alternatives are (and I do not like either of them): a) do not send DELETE b) re-negotiate IKE SA before sending DELETE Any suggestions? From owner-ipsec@lists.tislabs.com Tue Nov 30 11:30:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12930; Tue, 30 Nov 1999 11:30:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01267 Tue, 30 Nov 1999 12:46:10 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5472@exchange> From: Tim Jenkins To: Slava Kavsan , ipsec Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Tue, 30 Nov 1999 12:46:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: November 30, 1999 11:46 AM > To: ipsec > Subject: IPSec SA DELETE in "dangling" implementation > > > Here is the dilemma: if "dangling" implementation wants to > send IPSec SA > DELETE message, while the "parent" IKE SA is no longer there > (expired or > deleted), the alternatives are (and I do not like either of them): > > a) do not send DELETE > b) re-negotiate IKE SA before sending DELETE > > Any suggestions? > > > I think you've pretty much captured it. However, b) is preferable to a). We might note that if you've re-keyed the phase 2 SA that you're about to delete, and if you move to the newest phase 2 SA as soon as possible, the probability that the phase 1 SA is not there should be low, since the time difference between a re-key and a delete of a phase 2 SA is small. This is probably the most normal of circumstances, so the situation you describe should not be as common as needing to re-negotiate phase 1 for the purposes of re-keying. Bottom line: attempt b), else a). From owner-ipsec@lists.tislabs.com Tue Nov 30 11:48:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13324; Tue, 30 Nov 1999 11:48:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01386 Tue, 30 Nov 1999 13:20:41 -0500 (EST) Date: Tue, 30 Nov 1999 09:38:15 -0600 (CST) From: madhavan@iscmed.med.ge.com (Deepa Madhavan x3-2898) Message-Id: <199911301538.JAA20040@olc230.med.ge.com> To: ipsec@lists.tislabs.com Subject: General discussion Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I would like to be a part of the general discussions on IP Sec. Thanks, deepa Sr. Design engineer GE Medical Systems Ltd. From owner-ipsec@lists.tislabs.com Tue Nov 30 11:57:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13489; Tue, 30 Nov 1999 11:57:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01403 Tue, 30 Nov 1999 13:21:41 -0500 (EST) Date: Tue, 30 Nov 1999 09:19:36 -0800 (PST) From: bradr@iname.com To: "Derrell D. Piper" cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP Configuration Method In-Reply-To: <199911301602.IAA15074@gallium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the information, but I'm still a little confused. In section 3.2 of the draft-ietf-ipsec-isakmp-mode-cfg-05.txt document, a description of a "new payload is defined to carry attributes as well as the type of transaction message". This payload would have to be referenced from the previous payload's `Next Payload' identifier field, right? -brad On Tue, 30 Nov 1999, Derrell D. Piper wrote: > > Brad, > > > After reading through this particular draft as well as searching through > > the DOI, ISAKMP, and other rfcs and drafts, I am unable to find any value > > mentioned for the `Next Payload' identifier for the ATTRIBUTE_PAYLOAD of a > > transaction exchange. Is this specified somewhere else, or did I just > > overlook it? > > The ISAKMP Attribute information is not encoded as a separate payload. > Instead, it's basically appended to any of the defined payloads. Its format > is defined in Section 3.3 of RFC 2408. > > Derrell > From owner-ipsec@lists.tislabs.com Tue Nov 30 12:12:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13763; Tue, 30 Nov 1999 12:12:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01453 Tue, 30 Nov 1999 13:32:18 -0500 (EST) Message-Id: <199911301835.KAA10252@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 30 Nov 1999 10:35:34 -0800 To: ippcp@external.cisco.com From: Avram Shacham Subject: Re: I-D ACTION:draft-shacham-ippcp-rfc2393bis-02.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <199911301158.GAA05401@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The content changes in rfc2393bis-02 are: * Added an Implementation Note on the usage and negotiation of CPI in the pre-defined range. (Following few threads on that issue.) * IKE is the negotiation protocol of IPSec -- pointed all references to IKE and RFC2409. avram At 06:58 AM 11/30/99 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Payload Compression Protocol (IPComp) > Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas > Filename : draft-shacham-ippcp-rfc2393bis-02.txt > Pages : 10 > Date : 29-Nov-99 > >This document describes a protocol intended to provide lossless >compression for Internet Protocol datagrams in an Internet >environment. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-02.txt From owner-ipsec@lists.tislabs.com Tue Nov 30 12:20:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13855; Tue, 30 Nov 1999 12:20:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01429 Tue, 30 Nov 1999 13:27:22 -0500 (EST) Message-ID: <384417CC.6504EC9@ire-ma.com> Date: Tue, 30 Nov 1999 13:30:36 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec Subject: Re: IPSec SA DELETE in "dangling" implementation References: <319A1C5F94C8D11192DE00805FBBADDFFD5472@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes - it makes sense, though there could be other reasons for deleting Phase 2 SA than just Phase 2 re-keying (where the probability of this scenario is low, as you noted). So, for example, in the case when I want to delete all my sessions, and if start deleting "orphan" Phase 2 SAs - I'll start re-negotiating Phase 1 SAs first.... This seems kinda silly when my goal is to kill all sessions. Tim Jenkins wrote: > > -----Original Message----- > > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > > Sent: November 30, 1999 11:46 AM > > To: ipsec > > Subject: IPSec SA DELETE in "dangling" implementation > > > > > > Here is the dilemma: if "dangling" implementation wants to > > send IPSec SA > > DELETE message, while the "parent" IKE SA is no longer there > > (expired or > > deleted), the alternatives are (and I do not like either of them): > > > > a) do not send DELETE > > b) re-negotiate IKE SA before sending DELETE > > > > Any suggestions? > > > > > > > > I think you've pretty much captured it. However, b) is > preferable to a). > > We might note that if you've re-keyed the phase 2 SA > that you're about to delete, and if you move to the > newest phase 2 SA as soon as possible, the probability > that the phase 1 SA is not there should be low, since > the time difference between a re-key and a delete of a > phase 2 SA is small. > > This is probably the most normal of circumstances, so > the situation you describe should not be as common as > needing to re-negotiate phase 1 for the purposes of > re-keying. > > Bottom line: attempt b), else a). -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Nov 30 12:35:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14024; Tue, 30 Nov 1999 12:35:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01559 Tue, 30 Nov 1999 13:57:57 -0500 (EST) Message-Id: <199911301900.LAA15474@gallium.network-alchemy.com> To: bradr@iname.com cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP Configuration Method In-reply-to: Your message of "Tue, 30 Nov 1999 09:19:36 PST." Date: Tue, 30 Nov 1999 11:00:51 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brad, Oh, sorry. I didn't understand you were asking an ISAKMP Config Mode specific question. That draft does define a new Attribute Payload which Section 3.2 in it says has the value of 14. 14 is simply the first unassigned value after the ISAKMP Vendor ID Payload value (13). It's really not cool for them to have done that since 14 has technically been reserved to IANA since the ISAKMP draft became a standard's track RFC, but this draft was first published before that happened. IANA now owns the ISAKMP Payload type registry and only if this draft advances will it necessarily get the value 14. However, given the number of fielded implementations using config mode (with XAUTH), it's probably safe to use 14... Derrell From owner-ipsec@lists.tislabs.com Tue Nov 30 12:46:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14146; Tue, 30 Nov 1999 12:46:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01575 Tue, 30 Nov 1999 14:02:02 -0500 (EST) Message-Id: <199911301904.LAA15483@gallium.network-alchemy.com> To: Slava Kavsan cc: ipsec Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Tue, 30 Nov 1999 11:45:33 EST." <3843FF2D.B77C6051@ire-ma.com> Date: Tue, 30 Nov 1999 11:04:57 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >b) re-negotiate IKE SA before sending DELETE ...which would beg the question of whether or not it's legal to send an IPSEC DELETE on an IKE SA that did not originally negotiate the IPSEC SA's. Our particular implementation would accept that, but I can also see an argument for while that's not right. I'm really unclear as to what problem is being solved by this rekeying draft. However, I owe Tim a reasoned response beyond just this snipe... :-) Derrell From owner-ipsec@lists.tislabs.com Tue Nov 30 12:51:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14226; Tue, 30 Nov 1999 12:51:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01510 Tue, 30 Nov 1999 13:44:08 -0500 (EST) Message-ID: <38441BEB.3945CC9D@redcreek.com> Date: Tue, 30 Nov 1999 10:48:11 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: ipsec Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Slava, Slava Kavsan wrote: > > Here is the dilemma: if "dangling" implementation wants to send IPSec SA > DELETE message, while the "parent" IKE SA is no longer there (expired or > deleted), the alternatives are (and I do not like either of them): > > a) do not send DELETE > b) re-negotiate IKE SA before sending DELETE > > Any suggestions? A related question: Is a static SA "dangling"? It seems to me that some folks are assuming that those who have argued against forcing a binding between phase 1 and phase 2 SAs are always deleting phase 1 SAs whenever the phase 2 SA is in place. Based on my experience at bakeoffs, this is incorrect. I don't recall ever seeing an implementation do this. Nonetheless, this erroneous assumption seems to continuously fuel this debate. If you don't like the alternatives you mention above, then don't delete your phase 1 SAs without replacing them. The current spec does not bind phase 1 SAs to phase 2 SAs, but this does not mean people should (or do) automatically delete phase 1 SAs once the phase 2 SAs are established. Nobody says you *must* delete the phase 1 SA - only that you should have the ability to do so if you deem it necessary. I think most of us would only delete phase 1 SAs if resource issues forced us to do so, and then we would re-establish it whenever we needed it. However, I think this is an implementation issue, one which should not be legislated. Common sense should be sufficient, I think. Scott From owner-ipsec@lists.tislabs.com Tue Nov 30 13:49:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14912; Tue, 30 Nov 1999 13:49:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01792 Tue, 30 Nov 1999 15:00:04 -0500 (EST) Date: Tue, 30 Nov 1999 22:03:30 +0200 (EET) Message-Id: <199911302003.WAA00371@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Summary of changes in the draft-ietf-ipsec-ike-ext-meth-03.txt X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk * Added text to ISAKMP Major and Minor version number section to explain that both ends use their own version numbers which might differ from each other. * Added paragrap in the Phase 1 Transform ID saying, that the responder cannot modify the SA payload, thus it must select one ID. * Added comment in the Payload Types section saying, that vendor ID payloads are not authenticated. * Added same comment about vendor ID payloads not being authenticated in the Vendor ID Payload section. * Lots of spelling corrections etc. So it doesn't really contain any big changes, only small fixes. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Nov 30 14:22:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15302; Tue, 30 Nov 1999 14:22:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01928 Tue, 30 Nov 1999 15:47:45 -0500 (EST) From: bradr@iname.com Date: Tue, 30 Nov 1999 11:20:57 -0800 (PST) To: "Derrell D. Piper" cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP Configuration Method In-Reply-To: <199911301900.LAA15474@gallium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excellent. David W. Faucher also pointed out to me that the value is indeed specified in the draft. I apologize for not reading the draft carefully enough and I thank you for your time. -brad On Tue, 30 Nov 1999, Derrell D. Piper wrote: > > Brad, > > Oh, sorry. I didn't understand you were asking an ISAKMP Config Mode specific > question. That draft does define a new Attribute Payload which Section 3.2 in > it says has the value of 14. 14 is simply the first unassigned value after > the ISAKMP Vendor ID Payload value (13). > > It's really not cool for them to have done that since 14 has technically been > reserved to IANA since the ISAKMP draft became a standard's track RFC, but > this draft was first published before that happened. IANA now owns the ISAKMP > Payload type registry and only if this draft advances will it necessarily get > the value 14. However, given the number of fielded implementations using > config mode (with XAUTH), it's probably safe to use 14... > > Derrell > From owner-ipsec@lists.tislabs.com Tue Nov 30 15:55:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16606; Tue, 30 Nov 1999 15:55:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02326 Tue, 30 Nov 1999 17:41:29 -0500 (EST) Date: Tue, 30 Nov 1999 17:44:49 -0500 Message-Id: <199911302244.RAA16462@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ddp@network-alchemy.com Cc: bkavsan@ire-ma.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derrell" == Derrell D Piper writes: >> b) re-negotiate IKE SA before sending DELETE Derrell> ...which would beg the question of whether or not it's legal Derrell> to send an IPSEC DELETE on an IKE SA that did not originally Derrell> negotiate the IPSEC SA's. Our particular implementation Derrell> would accept that, but I can also see an argument for while Derrell> that's not right. I think it has to be accepted. Reasoning: either phase 2 SAs are bound to phase 1 SAs or they are not. If they are, then the phase 2 SAs go away when the phase 2 SA does, and it is reasonable to require messages relating to the phase 2 SAs to come over the phase 1 SA to which they are bound. If they are not, then the phase 1 SA may disappear without affecting the phase 2 SAs. But also, if they aren't bound, then it is illogical to require messages about the phase 2 SA to arrive via the phase 1 SA that created it, because by definition there wasn't any such binding. And never mind that abstract argument... if you make that restriction then it follows that you can no longer send ANY messages about the phase 2 SA once the original phase 1 SA disappears. That defeats the purpose of the non-binding approach! Since IKE is defined the latter way (no binding) messages such as deletes of a phase 2 SA must be accepted on any phase 1 SA (from the right source, obviously). paul From owner-ipsec@lists.tislabs.com Tue Nov 30 15:56:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16624; Tue, 30 Nov 1999 15:56:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02300 Tue, 30 Nov 1999 17:36:25 -0500 (EST) Date: Tue, 30 Nov 1999 17:39:26 -0500 Message-Id: <199911302239.RAA04813@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: tjenkins@TimeStep.com CC: ipsec@lists.tislabs.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDFFA8BBE@exchange> (message from Tim Jenkins on Thu, 25 Nov 1999 15:03:01 -0500) Subject: Re: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt From: tytso@mit.edu Phone: (781) 391-3464 References: <319A1C5F94C8D11192DE00805FBBADDFFA8BBE@exchange> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Tim Jenkins Date: Thu, 25 Nov 1999 15:03:01 -0500 First, there was concern that the WG should even be doing an application specific MIB for IPsec. I believe there was a vote, but unfortunately, I can't remember the exact question that Ted asked, but I believe there was no clear consensus on whatever it was. Therefore, before I make further comments on this document, I'd like to re-open the question (Ted, stop me if I shouldn't be doing this). At the IPSEC working group meeting, I performed a straw poll which asked if there was interest to pursue this specific draft; but it's fair game to re-ask the question on the mailing list, especially given the general nature of the question you asked: Should the WG be developing a VPN/Remote Access application-specific MIB for IPsec? (I choose VPN/remote access since they seem to be the primary applications for IPsec and they're the primary focus of this document, and also of the one I presented over a year ago.) My personal (without my wg chair hat on) take on it is that as natural extension of the MIB work that we are doing, that it would be a good and useful thing for us to pursue. I do share your concern that if we do pursue this, they should as much as possible be in harmony with the rest of the MIBs being produced by this working group. At the same time, though, we should try to let this work move forward as quickly as possible; this means that folks who have an interest in these MIB's (which should include developers from just about every single company that's making a IPSEC product), should be encouraged to look at and comment on the documents as soon as possible. - Ted From owner-ipsec@lists.tislabs.com Tue Nov 30 16:04:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16756; Tue, 30 Nov 1999 16:04:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02427 Tue, 30 Nov 1999 17:53:23 -0500 (EST) Message-ID: <38445631.8073F94F@ire-ma.com> Date: Tue, 30 Nov 1999 17:56:49 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The issue still remains, though: "When deleting all SAs - in order to delete "orphan" IPSec SAs - starting re-negotiation of IKE SA seems kinda silly when the goal is to kill all SAs." (I also assume that there is no "step-parent" IKE SA exists with the same peer to "adapt" these "orphans") Paul Koning wrote: > >>>>> "Derrell" == Derrell D Piper writes: > > >> b) re-negotiate IKE SA before sending DELETE > Derrell> ...which would beg the question of whether or not it's legal > Derrell> to send an IPSEC DELETE on an IKE SA that did not originally > Derrell> negotiate the IPSEC SA's. Our particular implementation > Derrell> would accept that, but I can also see an argument for while > Derrell> that's not right. > > I think it has to be accepted. > > Reasoning: either phase 2 SAs are bound to phase 1 SAs or they are > not. > > If they are, then the phase 2 SAs go away when the phase 2 SA does, > and it is reasonable to require messages relating to the phase 2 SAs > to come over the phase 1 SA to which they are bound. > > If they are not, then the phase 1 SA may disappear without affecting > the phase 2 SAs. But also, if they aren't bound, then it is illogical > to require messages about the phase 2 SA to arrive via the phase 1 SA > that created it, because by definition there wasn't any such binding. > And never mind that abstract argument... if you make that restriction > then it follows that you can no longer send ANY messages about the > phase 2 SA once the original phase 1 SA disappears. That defeats the > purpose of the non-binding approach! > > Since IKE is defined the latter way (no binding) messages such as > deletes of a phase 2 SA must be accepted on any phase 1 SA (from the > right source, obviously). > > paul -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Tue Nov 30 17:22:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18074; Tue, 30 Nov 1999 17:22:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02604 Tue, 30 Nov 1999 18:50:54 -0500 (EST) Message-ID: <384463D7.8DCCB044@redcreek.com> Date: Tue, 30 Nov 1999 15:55:03 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Slava, Slava Kavsan wrote: > > The issue still remains, though: > > "When deleting all SAs - in order to delete "orphan" IPSec SAs - starting > re-negotiation of IKE SA seems kinda silly when the goal is to kill all > SAs." > > (I also assume that there is no "step-parent" IKE SA exists with the same > peer to "adapt" these "orphans") I think this misses the point: this is a pathological case which should occur only rarely. I don't think that the implications of requiring the binding are justified by this rare case. I will again point out that nobody has 'fessed up to summary deletion of phase 1 SAs once phase 2 SAs are established, despite the fact that we've been beating this into the ground for over a year now. I take that to mean that nobody does it, and I fail to understand why we don't move on. Scott From owner-ipsec@lists.tislabs.com Tue Nov 30 17:38:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18409; Tue, 30 Nov 1999 17:38:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02644 Tue, 30 Nov 1999 19:13:36 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 30 Nov 1999 16:16:20 -0800 (PST) From: Jan Vilhuber To: Slava Kavsan cc: Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <38445631.8073F94F@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Nov 1999, Slava Kavsan wrote: > The issue still remains, though: > > "When deleting all SAs - in order to delete "orphan" IPSec SAs - starting > re-negotiation of IKE SA seems kinda silly when the goal is to kill all > SAs." > If you want to be a nice net-citizen, and interoprate cleanly and robustly, then you should renegotiate the phase 1 to securely let the other end know that it should delete it's phase2's also. You can then proceed to also delete your phase1 (after sending a delete for the same ;). Thus, you now have a clean ending of all connections. I don't really see a problem with this. jan > (I also assume that there is no "step-parent" IKE SA exists with the same > peer to "adapt" these "orphans") > > > > > Paul Koning wrote: > > > >>>>> "Derrell" == Derrell D Piper writes: > > > > >> b) re-negotiate IKE SA before sending DELETE > > Derrell> ...which would beg the question of whether or not it's legal > > Derrell> to send an IPSEC DELETE on an IKE SA that did not originally > > Derrell> negotiate the IPSEC SA's. Our particular implementation > > Derrell> would accept that, but I can also see an argument for while > > Derrell> that's not right. > > > > I think it has to be accepted. > > > > Reasoning: either phase 2 SAs are bound to phase 1 SAs or they are > > not. > > > > If they are, then the phase 2 SAs go away when the phase 2 SA does, > > and it is reasonable to require messages relating to the phase 2 SAs > > to come over the phase 1 SA to which they are bound. > > > > If they are not, then the phase 1 SA may disappear without affecting > > the phase 2 SAs. But also, if they aren't bound, then it is illogical > > to require messages about the phase 2 SA to arrive via the phase 1 SA > > that created it, because by definition there wasn't any such binding. > > And never mind that abstract argument... if you make that restriction > > then it follows that you can no longer send ANY messages about the > > phase 2 SA once the original phase 1 SA disappears. That defeats the > > purpose of the non-binding approach! > > > > Since IKE is defined the latter way (no binding) messages such as > > deletes of a phase 2 SA must be accepted on any phase 1 SA (from the > > right source, obviously). > > > > paul > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-539-4816 > http://www.ire.com > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 30 17:57:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18668; Tue, 30 Nov 1999 17:57:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02702 Tue, 30 Nov 1999 19:34:48 -0500 (EST) Message-ID: <38446DE8.6074AEF8@redcreek.com> Date: Tue, 30 Nov 1999 16:38:00 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Re: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt References: <199911191158.GAA16457@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () I would like to develop feed back on your draft. I believe it is an important problem. But just so I don't get lost chasing rabbits, first I would ask the authors to provide their definitions for: * IPsec traffic flows * IPsec tunnels * IKE tunnel -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Tue Nov 30 18:40:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21132; Tue, 30 Nov 1999 18:40:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02807 Tue, 30 Nov 1999 20:20:50 -0500 (EST) Message-Id: <199912010121.RAA03398@potassium.network-alchemy.com> To: Jan Vilhuber cc: Slava Kavsan , Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Tue, 30 Nov 1999 16:16:20 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3395.944011298.1@network-alchemy.com> Date: Tue, 30 Nov 1999 17:21:39 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well the problem is that this is sort of like waking up someone to tell them to go to sleep. There's wasted work (trying to get back to sleep/public key operations) for what probably wouldn't pass the "duh!" test (already sleeping/was gonna delete that anyway). In normal operation I don't see this happening. Assuming that lifetimes are respected then the phase 1's will expire pretty much at the same time. Either or both can send deletes and no problem. Then when the phase 2s get around to being deleted they will either need to be rekeyed (if either is "in use") in which a phase 1 will have to be re-established anyway or they will just be deleted (if neither are "in use") in which case the other guy will just be deleteing them anyway and there's no need to send a delete. Doing a gratuitous negotiation here would be something a naughty net-citizen would do. This can happen though if you did (your syntax may vary): prompt# crypto clear ike prompt# crypto clear ipsec And the traffic was strictly unidirectional and these commands were entered on the sink (as opposed to the source). But this requires 1) operator intervention; and some unique traffic (maybe multicast?). Given that certain must-audit events would start happening if this problem occured the operator who caused them would most likely immediately see the error in his ways. Of all the loaded weapons we're putting in the hands of the net admin guy this one seems to be of a particularly small caliber and would not cause pain if used to shoot oneself in the foot. In other words, I still don't see the problem with non-continuous phase 1 SAs. Dan. On Tue, 30 Nov 1999 16:16:20 PST you wrote > On Tue, 30 Nov 1999, Slava Kavsan wrote: > > The issue still remains, though: > > > > "When deleting all SAs - in order to delete "orphan" IPSec SAs - starting > > re-negotiation of IKE SA seems kinda silly when the goal is to kill all > > SAs." > > > If you want to be a nice net-citizen, and interoprate cleanly and robustly, > then you should renegotiate the phase 1 to securely let the other end know > that it should delete it's phase2's also. You can then proceed to also delete > your phase1 (after sending a delete for the same ;). Thus, you now have a > clean ending of all connections. > > I don't really see a problem with this. > > jan From owner-ipsec@lists.tislabs.com Tue Nov 30 18:58:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22064; Tue, 30 Nov 1999 18:58:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02857 Tue, 30 Nov 1999 20:42:49 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 30 Nov 1999 17:45:45 -0800 (PST) From: Jan Vilhuber To: Dan Harkins cc: Slava Kavsan , Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912010121.RAA03398@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Nov 1999, Dan Harkins wrote: > Well the problem is that this is sort of like waking up someone to > tell them to go to sleep. There's wasted work (trying to get back to > sleep/public key operations) for what probably wouldn't pass the "duh!" > test (already sleeping/was gonna delete that anyway). > > In normal operation I don't see this happening. Assuming that lifetimes > are respected then the phase 1's will expire pretty much at the same time. > Either or both can send deletes and no problem. Then when the phase 2s > get around to being deleted they will either need to be rekeyed (if either > is "in use") in which a phase 1 will have to be re-established anyway or > they will just be deleted (if neither are "in use") in which case the > other guy will just be deleteing them anyway and there's no need to send > a delete. That's assuming that both sides have the same definition of 'in use'. I can imagine two different definitions, which would result in deleting an SA earlier than the other. Granted, in that case the one with the more lax definition of 'in use' will try to rekey with us (and we'll presumably let him), so it's still not a problem. Experience so far, however, leads me to believe that anything that will make this a more 'known' protocol as opposed to 'inferred' the better the stability and therefore customer acceptance. Therefore, I'm all in favor of some gratuitous re-establishements, if they aid in making both sides communicate better. No, I don't have any concrete examples, unfortunately.. jan > Doing a gratuitous negotiation here would be something a naughty > net-citizen would do. > > This can happen though if you did (your syntax may vary): > > prompt# crypto clear ike > prompt# crypto clear ipsec > > And the traffic was strictly unidirectional and these commands were entered > on the sink (as opposed to the source). > > But this requires 1) operator intervention; and some unique traffic (maybe > multicast?). Given that certain must-audit events would start happening if > this problem occured the operator who caused them would most likely > immediately see the error in his ways. Of all the loaded weapons we're > putting in the hands of the net admin guy this one seems to be of a > particularly small caliber and would not cause pain if used to shoot oneself > in the foot. In other words, I still don't see the problem with non-continuous > phase 1 SAs. > > Dan. > > On Tue, 30 Nov 1999 16:16:20 PST you wrote > > On Tue, 30 Nov 1999, Slava Kavsan wrote: > > > The issue still remains, though: > > > > > > "When deleting all SAs - in order to delete "orphan" IPSec SAs - starting > > > re-negotiation of IKE SA seems kinda silly when the goal is to kill all > > > SAs." > > > > > If you want to be a nice net-citizen, and interoprate cleanly and robustly, > > then you should renegotiate the phase 1 to securely let the other end know > > that it should delete it's phase2's also. You can then proceed to also delete > > your phase1 (after sending a delete for the same ;). Thus, you now have a > > clean ending of all connections. > > > > I don't really see a problem with this. > > > > jan > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 30 19:41:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24477; Tue, 30 Nov 1999 19:41:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02934 Tue, 30 Nov 1999 21:17:00 -0500 (EST) Message-Id: <199912010215.SAA03629@potassium.network-alchemy.com> To: Jan Vilhuber cc: Slava Kavsan , Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Tue, 30 Nov 1999 17:45:45 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3626.944014558.1@network-alchemy.com> Date: Tue, 30 Nov 1999 18:15:59 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, no. Different definitions of "in use" would just cause one side to renegotiate when the other would not have but it will not cause the problem being inferred here: a "blackhole" can happen if I don't send a delete message when I delete phase 2 SAs. The notion was whether to decide to rekey the SAs or not. If they aren't "in use" (open to interpretation and implementations may vary but common sense should rule) then don't rekey them; if they are then do. It doesn't refer to the notion of unilaterally deleting SAs that you feel are not being used. Making it a "known" protocol instead of an "inferred" protocol is a problem for the editors of the relevant documents. The documents should make problematic issues clear and if a firm definition of "in use" or when to rekey an SA or what to do in some situation is needed to nip some problem in the bud then suggested text goes a long way. But I'm still having trouble seeing what the problem is. If it requires manual intervention on a particular end of the session and a certain form of traffic and is easily identified when it occurs then I don't think that's a problem. If a "blackhole" could happen without manual intervention, on either end of the session, and with any traffic then that would be a problem. Everyone wants stability and customer acceptance but establishing a phase 1 SA for the sole purpose of sending a delete message, and then deleteing the phase 1 SA would not make this any more stable or acceptable to the customer. Dan. On Tue, 30 Nov 1999 17:45:45 PST you wrote > On Tue, 30 Nov 1999, Dan Harkins wrote: > > Well the problem is that this is sort of like waking up someone to > > tell them to go to sleep. There's wasted work (trying to get back to > > sleep/public key operations) for what probably wouldn't pass the "duh!" > > test (already sleeping/was gonna delete that anyway). > > > > In normal operation I don't see this happening. Assuming that lifetimes > > are respected then the phase 1's will expire pretty much at the same time. > > Either or both can send deletes and no problem. Then when the phase 2s > > get around to being deleted they will either need to be rekeyed (if either > > is "in use") in which a phase 1 will have to be re-established anyway or > > they will just be deleted (if neither are "in use") in which case the > > other guy will just be deleteing them anyway and there's no need to send > > a delete. > > That's assuming that both sides have the same definition of 'in use'. I can > imagine two different definitions, which would result in deleting an SA > earlier than the other. > > Granted, in that case the one with the more lax definition of 'in use' will > try to rekey with us (and we'll presumably let him), so it's still not a > problem. > > Experience so far, however, leads me to believe that anything that will make > this a more 'known' protocol as opposed to 'inferred' the better the stabilit >y > and therefore customer acceptance. Therefore, I'm all in favor of some > gratuitous re-establishements, if they aid in making both sides communicate > better. > > No, I don't have any concrete examples, unfortunately.. > > jan From owner-ipsec@lists.tislabs.com Tue Nov 30 19:46:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24806; Tue, 30 Nov 1999 19:46:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02954 Tue, 30 Nov 1999 21:25:01 -0500 (EST) Message-Id: <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 30 Nov 1999 18:29:52 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <384463D7.8DCCB044@redcreek.com> References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:55 PM 11/30/99 -0800, Scott G. Kelly wrote: >I think this misses the point: this is a pathological case which should >occur only rarely. I don't think that the implications of requiring the >binding are justified by this rare case. I will again point out that >nobody has 'fessed up to summary deletion of phase 1 SAs once phase 2 >SAs are established, despite the fact that we've been beating this into >the ground for over a year now. I take that to mean that nobody does it, >and I fail to understand why we don't move on. Well, I'm not a fan of beating a dead horse, but I don't think this discussion has come to resolution on a not-necessarily-rare prospect. If an implementation lets an IKE SA die without tearing down all IPsec SAs that were started under its protection, there's going to be the problems that have been long discussed. An implementation can (and IMO SHOULD) choose not create IPsec SAs that have lifetimes longer than the IKE SA under which they are protected. So far, so good. However, there are some cases where an IKE SA can get taken down unexpectedly. A good example is when the IKE SA discovers that the cert it used to authenticate the other party has been compromised. In this case, all the IPsec SAs are suspect and should be deleted. I may have missed it, but is there a good reason why an IKE implementation that is deleting an IKE SA for security reasons ever want *not* to tear down the IPsec SAs that it created? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Nov 30 20:30:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28543; Tue, 30 Nov 1999 20:30:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03031 Tue, 30 Nov 1999 22:04:02 -0500 (EST) Message-ID: <38449000.C8AF3B90@ire-ma.com> Date: Tue, 30 Nov 1999 22:03:29 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Jan Vilhuber , Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912010215.SAA03629@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In other words: - Dan recommends do not send DELETEs in these situations - it sounds reasonable, but IMHO could lead to some "in-limbo" scenarios - I would call it "medium-rare" solution :), while - Jan recommends to re-negotiate IKE SA and then send DELETEs - which also sounds reasonable - I would call it "well overdone" :) solution and probably could cause some catch 22 complications Therefore, both of you assume that there is no IMMEDIATE IKE SA re-establishment after the old IKE SA has expired or deleted - it is not quite the same as so-called "continuous" (ala Tim Jenkins proposal), but continuous in the sense that there is always IKE SA between peers that have at least one IPSec SA between them. In other word - it is true "dangler" implementation. (I hate these worms from the re-opened cans, but the issue is still not solved once and for all) Dan Harkins wrote: > Actually, no. Different definitions of "in use" would just cause one > side to renegotiate when the other would not have but it will not cause > the problem being inferred here: a "blackhole" can happen if I don't send > a delete message when I delete phase 2 SAs. > > The notion was whether to decide to rekey the SAs or not. If they aren't > "in use" (open to interpretation and implementations may vary but common > sense should rule) then don't rekey them; if they are then do. It doesn't > refer to the notion of unilaterally deleting SAs that you feel are not > being used. > > Making it a "known" protocol instead of an "inferred" protocol is a > problem for the editors of the relevant documents. The documents should > make problematic issues clear and if a firm definition of "in use" or > when to rekey an SA or what to do in some situation is needed to nip > some problem in the bud then suggested text goes a long way. But I'm > still having trouble seeing what the problem is. If it requires manual > intervention on a particular end of the session and a certain form of > traffic and is easily identified when it occurs then I don't think that's > a problem. If a "blackhole" could happen without manual intervention, on > either end of the session, and with any traffic then that would be a > problem. Everyone wants stability and customer acceptance but establishing > a phase 1 SA for the sole purpose of sending a delete message, and then > deleteing the phase 1 SA would not make this any more stable or acceptable > to the customer. > > Dan. > > On Tue, 30 Nov 1999 17:45:45 PST you wrote > > On Tue, 30 Nov 1999, Dan Harkins wrote: > > > Well the problem is that this is sort of like waking up someone to > > > tell them to go to sleep. There's wasted work (trying to get back to > > > sleep/public key operations) for what probably wouldn't pass the "duh!" > > > test (already sleeping/was gonna delete that anyway). > > > > > > In normal operation I don't see this happening. Assuming that lifetimes > > > are respected then the phase 1's will expire pretty much at the same time. > > > Either or both can send deletes and no problem. Then when the phase 2s > > > get around to being deleted they will either need to be rekeyed (if either > > > is "in use") in which a phase 1 will have to be re-established anyway or > > > they will just be deleted (if neither are "in use") in which case the > > > other guy will just be deleteing them anyway and there's no need to send > > > a delete. > > > > That's assuming that both sides have the same definition of 'in use'. I can > > imagine two different definitions, which would result in deleting an SA > > earlier than the other. > > > > Granted, in that case the one with the more lax definition of 'in use' will > > try to rekey with us (and we'll presumably let him), so it's still not a > > problem. > > > > Experience so far, however, leads me to believe that anything that will make > > this a more 'known' protocol as opposed to 'inferred' the better the stabilit > >y > > and therefore customer acceptance. Therefore, I'm all in favor of some > > gratuitous re-establishements, if they aid in making both sides communicate > > better. > > > > No, I don't have any concrete examples, unfortunately.. > > > > jan From owner-ipsec@lists.tislabs.com Tue Nov 30 20:51:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00333; Tue, 30 Nov 1999 20:51:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03081 Tue, 30 Nov 1999 22:36:43 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 30 Nov 1999 19:39:40 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Dan Harkins , Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <38449000.C8AF3B90@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Nov 1999, Bronislav Kavsan wrote: > In other words: > > - Dan recommends do not send DELETEs in these situations - it sounds reasonable, > but IMHO could lead to some "in-limbo" scenarios - I would call it "medium-rare" > solution :), while > - Jan recommends to re-negotiate IKE SA and then send DELETEs - which also sounds > reasonable - I would call it "well overdone" :) solution and probably could cause > some catch 22 complications > Actually, I don't recommend anything at all. I merely said I don't really see a problem with it. I'm not sure what I recommend at this point. jan > Therefore, both of you assume that there is no IMMEDIATE IKE SA re-establishment > after the old IKE SA has expired or deleted - it is not quite the same as so-called > "continuous" (ala Tim Jenkins proposal), but continuous in the sense that there is > always IKE SA between peers that have at least one IPSec SA between them. In other > word - it is true "dangler" implementation. > > (I hate these worms from the re-opened cans, but the issue is still not solved once > and for all) > > Dan Harkins wrote: > > > Actually, no. Different definitions of "in use" would just cause one > > side to renegotiate when the other would not have but it will not cause > > the problem being inferred here: a "blackhole" can happen if I don't send > > a delete message when I delete phase 2 SAs. > > > > The notion was whether to decide to rekey the SAs or not. If they aren't > > "in use" (open to interpretation and implementations may vary but common > > sense should rule) then don't rekey them; if they are then do. It doesn't > > refer to the notion of unilaterally deleting SAs that you feel are not > > being used. > > > > Making it a "known" protocol instead of an "inferred" protocol is a > > problem for the editors of the relevant documents. The documents should > > make problematic issues clear and if a firm definition of "in use" or > > when to rekey an SA or what to do in some situation is needed to nip > > some problem in the bud then suggested text goes a long way. But I'm > > still having trouble seeing what the problem is. If it requires manual > > intervention on a particular end of the session and a certain form of > > traffic and is easily identified when it occurs then I don't think that's > > a problem. If a "blackhole" could happen without manual intervention, on > > either end of the session, and with any traffic then that would be a > > problem. Everyone wants stability and customer acceptance but establishing > > a phase 1 SA for the sole purpose of sending a delete message, and then > > deleteing the phase 1 SA would not make this any more stable or acceptable > > to the customer. > > > > Dan. > > > > On Tue, 30 Nov 1999 17:45:45 PST you wrote > > > On Tue, 30 Nov 1999, Dan Harkins wrote: > > > > Well the problem is that this is sort of like waking up someone to > > > > tell them to go to sleep. There's wasted work (trying to get back to > > > > sleep/public key operations) for what probably wouldn't pass the "duh!" > > > > test (already sleeping/was gonna delete that anyway). > > > > > > > > In normal operation I don't see this happening. Assuming that lifetimes > > > > are respected then the phase 1's will expire pretty much at the same time. > > > > Either or both can send deletes and no problem. Then when the phase 2s > > > > get around to being deleted they will either need to be rekeyed (if either > > > > is "in use") in which a phase 1 will have to be re-established anyway or > > > > they will just be deleted (if neither are "in use") in which case the > > > > other guy will just be deleteing them anyway and there's no need to send > > > > a delete. > > > > > > That's assuming that both sides have the same definition of 'in use'. I can > > > imagine two different definitions, which would result in deleting an SA > > > earlier than the other. > > > > > > Granted, in that case the one with the more lax definition of 'in use' will > > > try to rekey with us (and we'll presumably let him), so it's still not a > > > problem. > > > > > > Experience so far, however, leads me to believe that anything that will make > > > this a more 'known' protocol as opposed to 'inferred' the better the stabilit > > >y > > > and therefore customer acceptance. Therefore, I'm all in favor of some > > > gratuitous re-establishements, if they aid in making both sides communicate > > > better. > > > > > > No, I don't have any concrete examples, unfortunately.. > > > > > > jan > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 30 21:03:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA01430; Tue, 30 Nov 1999 21:03:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03066 Tue, 30 Nov 1999 22:32:35 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 30 Nov 1999 19:35:31 -0800 (PST) From: Jan Vilhuber To: Dan Harkins cc: Slava Kavsan , Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912010215.SAA03629@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Nov 1999, Dan Harkins wrote: > Making it a "known" protocol instead of an "inferred" protocol is a > problem for the editors of the relevant documents. The documents should > make problematic issues clear and if a firm definition of "in use" or > when to rekey an SA or what to do in some situation is needed to nip > some problem in the bud then suggested text goes a long way. But I'm > still having trouble seeing what the problem is. If it requires manual > intervention on a particular end of the session and a certain form of > traffic and is easily identified when it occurs then I don't think that's > a problem. If a "blackhole" could happen without manual intervention, on > either end of the session, and with any traffic then that would be a > problem. Well, we've certainly had reports of exactly that, although I'm not currently sure why or how. But it does happen (whether as a bug in our implementation or a bug in the protocol remains to be proven, of course). jan > Everyone wants stability and customer acceptance but establishing > a phase 1 SA for the sole purpose of sending a delete message, and then > deleteing the phase 1 SA would not make this any more stable or acceptable > to the customer. > > Dan. > > On Tue, 30 Nov 1999 17:45:45 PST you wrote > > On Tue, 30 Nov 1999, Dan Harkins wrote: > > > Well the problem is that this is sort of like waking up someone to > > > tell them to go to sleep. There's wasted work (trying to get back to > > > sleep/public key operations) for what probably wouldn't pass the "duh!" > > > test (already sleeping/was gonna delete that anyway). > > > > > > In normal operation I don't see this happening. Assuming that lifetimes > > > are respected then the phase 1's will expire pretty much at the same time. > > > Either or both can send deletes and no problem. Then when the phase 2s > > > get around to being deleted they will either need to be rekeyed (if either > > > is "in use") in which a phase 1 will have to be re-established anyway or > > > they will just be deleted (if neither are "in use") in which case the > > > other guy will just be deleteing them anyway and there's no need to send > > > a delete. > > > > That's assuming that both sides have the same definition of 'in use'. I can > > imagine two different definitions, which would result in deleting an SA > > earlier than the other. > > > > Granted, in that case the one with the more lax definition of 'in use' will > > try to rekey with us (and we'll presumably let him), so it's still not a > > problem. > > > > Experience so far, however, leads me to believe that anything that will make > > this a more 'known' protocol as opposed to 'inferred' the better the stabilit > >y > > and therefore customer acceptance. Therefore, I'm all in favor of some > > gratuitous re-establishements, if they aid in making both sides communicate > > better. > > > > No, I don't have any concrete examples, unfortunately.. > > > > jan > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847