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 <anfreema@cisco.com>
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 <dfox@ennovatenetworks.com>
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" <lars-schultz@teliamail.dk>
To: <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>We are implementing a vpn with =
IPSec. Our=20
question is</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>if IPSec is a protocol or is it a =
range of=20
protocols.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks</FONT></DIV></BODY></HTML>
------=_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 <dfox@ennovatenetworks.com>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scott G. Kelly" <skelly@redcreek.com>
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" <Stephen.Waters@cabletron.com>
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 <dfox@ennovatenetworks.com>
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 <dharkins@network-alchemy.com>
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 <wprice@cyphers.net>
Reply-To: wprice@cyphers.net
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
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 <markus.friedl@informatik.uni-erlangen.de>
To: Ricky Charlet <rcharlet@redcreek.com>
Cc: ipsec@lists.tislabs.com, Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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: <Pine.SOL.3.93.980818120151.21486F-100000@ee.technion.ac.il>
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 <dfox@ennovatenetworks.com>
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 <dharkins@network-alchemy.com>
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: <D899E9E27BE9D211842200805FA67B433FC6A3@vpnet.com>
From: Sankar Ramamoorthi <Sankar@vpnet.com>
To: "'Dan Harkins'" <dharkins@network-alchemy.com>,
Daniel Fox
<dfox@ennovatenetworks.com>
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 <dfox@ennovatenetworks.com>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@network-alchemy.com>
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 <briank@CS.Stanford.EDU>
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
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 <Ari.Huttunen@datafellows.com>
Organization: Data Fellows Oyj
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@network-alchemy.com>
CC: Daniel Fox <dfox@ennovatenetworks.com>, 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" <Sami.Mousa@mail.house.gov>
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>, 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" <Sami.Mousa@mail.house.gov>
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: <B067F3F71A6CD3118395009027AA6160939D39@ca-exchange2.nai.com>
From: "Salzman, Noah" <Noah_Salzman@nai.com>
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>, 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 <dfox@ennovatenetworks.com>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sankar Ramamoorthi <Sankar@vpnet.com>
CC: ipsec@lists.tislabs.com
Subject: Re: Phase 2 ID's for different VPN's with different Address Space
References: <D899E9E27BE9D211842200805FA67B433FC6A3@vpnet.com>
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 <jtiller@lucent.com>
X-Mailer: The Bat! (v1.36) S/N 569FD297
Reply-To: Jim Tiller <jtiller@lucent.com>
Organization: Lucent
X-Priority: 3 (Normal)
Message-ID: <17408.991102@lucent.com>
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
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 <dfox@ennovatenetworks.com>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ari Huttunen <Ari.Huttunen@datafellows.com>
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 <sandy.harris@sympatico.ca>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
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 <CTrobridge@baltimore.com>
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" <balenson@tislabs.com>
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: <F30BAAC39A86D0119404006097148B4C5714E7@mail.netlock.com>
From: "Stoler, David J" <dstoler@netlock.com>
To: "'Waters, Stephen'" <Stephen.Waters@cabletron.com>,
"'ipsec@lists.tislabs.com'" <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: <F30BAAC39A86D0119404006097148B4C5714E6@mail.netlock.com>
From: "Stoler, David J" <dstoler@netlock.com>
To: "'Waters, Stephen'" <Stephen.Waters@cabletron.com>,
"'ipsec@lists.tislabs.com'" <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: <D899E9E27BE9D211842200805FA67B433FC6A4@vpnet.com>
From: Sankar Ramamoorthi <Sankar@vpnet.com>
To: "'Daniel Fox'" <dfox@ennovatenetworks.com>,
Sankar Ramamoorthi
<Sankar@vpnet.com>
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 <rodney@ssh.fi>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>,
Dan Harkins <dharkins@network-alchemy.com>
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 <bkavsan@ire-ma.com>
cc: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <dharkins@network-alchemy.com>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@network-alchemy.com>
CC: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <mikewill@ibm.net>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSec <ipsec@lists.tislabs.com>
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 <sbeaulieu@TimeStep.com>
To: Slava Kavsan <bkavsan@ire-ma.com>,
Dan Harkins <dharkins@network-alchemy.com>
Cc: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <bkavsan@ire-ma.com>
From: "Shawn Mamros" <smamros@nortelnetworks.com>
Subject: Re: CRACK questions
Cc: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Shawn Mamros <smamros@nortelnetworks.com>
CC: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <bkavsan@ire-ma.com>,
Shawn Mamros <smamros@nortelnetworks.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: CRACK questions
Cc: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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: <D899E9E27BE9D211842200805FA67B433FC6AB@vpnet.com>
From: Sankar Ramamoorthi <Sankar@vpnet.com>
To: "'Shawn Mamros'" <smamros@nortelnetworks.com>,
Slava Kavsan
<bkavsan@ire-ma.com>
Cc: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <paul.hoffman@vpnc.org>
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
<http://www.ietf.org/ietf/99nov/nat-agenda-99nov.txt>.
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 <kivinen@ssh.fi>
To: Slava Kavsan <bkavsan@ire-ma.com>
Cc: ipsec <ipsec@lists.tislabs.com>, ipsra <ietf-ipsra@vpnc.org>
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 <nxmishra@yahoo.com>
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 <jtiller@lucent.com>
X-Mailer: The Bat! (v1.36) S/N 569FD297
Reply-To: Jim Tiller <jtiller@lucent.com>
Organization: Lucent
X-Priority: 3 (Normal)
Message-ID: <15700.991106@lucent.com>
To: Jianying Zhou <jyzhou@krdl.org.sg>
CC: Qiang Zhang <qzhang@ecutel.com>,
ipsec mailling list <ipsec@lists.tislabs.com>
Subject: Re[2]: Main mode using pre-shared keys
In-reply-To: <Pine.GSO.4.02.9910280931030.10549-100000@arizona>
References: <Pine.GSO.4.02.9910280931030.10549-100000@arizona>
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: <scott.davidson@iprg.nokia.com>
From: "Scott Davidson" <scott.davidson@iprg.nokia.com>
To: "Nishant Mishra" <nxmishra@yahoo.com>, <ipsec@lists.tislabs.com>
Subject: RE: VPN<->Firewall
Date: Mon, 8 Nov 1999 08:56:48 -0600
MIME-Version: 1.0
Message-ID: <NCBBIIIDALGGCGKAECNGOEDGCDAA.scott.davidson@iprg.nokia.com>
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 <nxmishra@yahoo.com>
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 <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Nishant" == Nishant Mishra <nxmishra@yahoo.com> 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 <mcr@sandelman.ottawa.on.ca>
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 <joern.sierwald@datafellows.com>
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 <sbeaulieu@TimeStep.com>
To: "'Joern Sierwald'" <joern.sierwald@datafellows.com>,
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-----
<From: Joern Sierwald [mailto:joern.sierwald@datafellows.com]
<Sent: Tuesday, November 09, 1999 2:04 PM
<To: ipsec@lists.tislabs.com
<Subject: draft-ietf-ipsec-isakmp-mode-cfg-05.txt
<
<
<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 Wed Nov 10 15:13: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 PAA16067;
Wed, 10 Nov 1999 15:13:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00074
Wed, 10 Nov 1999 16:18:10 -0500 (EST)
From: jerome@psti.com
Message-ID: <19991110151358.A6224@jerome.psti.com>
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 <provos@citi.umich.edu>
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:
<E0z6zWL-0006Yo-00@wserver.physnet.uni-hamburg.de>
<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" <jharleman@certicom.com>
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 <provos@citi.umich.edu> 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:
<E0z6zWL-0006Yo-00@wserver.physnet.uni-hamburg.de>
<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 <niklas@appli.se>
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 <provos@citi.umich.edu>
In-Reply-To: "John Harleman", Wed, 10 Nov 1999 20:23:25 PST
To: "John Harleman" <jharleman@certicom.com>
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 <kivinen@ssh.fi>
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" <Mike_Borella@mw.3com.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
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 <paul.hoffman@vpnc.org> on 11/05/99 06:22:56 PM
Sent by: Paul Hoffman <paul.hoffman@vpnc.org>
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
<http://www.ietf.org/ietf/99nov/nat-agenda-99nov.txt>.
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" <pfahn@certicom.com>
To: Niels Provos <provos@citi.umich.edu>
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 <draft-ietf-ipsec-ike-ecc-groups-01.txt> on the IPSec site for
details.
Paul
Niels Provos <provos@citi.umich.edu> 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 <smb@research.att.com>
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 <dharkins@network-alchemy.com>
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 <srao@ibondinc.com>
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 <qzhang@ecutel.com>
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 <pkoning@xedia.com>
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 <shganguly@hss.hns.com> 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" <bill.strahm@intel.com>
To: "'shganguly@hss.hns.com'" <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: <s82c1db0.024@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Fri, 12 Nov 1999 13:58:28 -0700
From: "Hilarie Orman" <HORMAN@novell.com>
To: <provos@citi.umich.edu>, <jharleman@certicom.com>
Cc: <ipsec@lists.tislabs.com>, <jerome@psti.com>
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" <jharleman@certicom.com>
To: "Hilarie Orman" <HORMAN@novell.com>
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" <HORMAN@novell.com> 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 <srowles@cisco.com>
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 <sommerfeld@orchard.arlington.ma.us>
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 <akrywaniuk@TimeStep.com>
To: "Strahm, Bill" <bill.strahm@intel.com>,
"'shganguly@hss.hns.com'" <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" <ylian.saint-hilaire@intel.com>
To: ipsec@lists.tislabs.com, "'gab@sun.com'" <gab@sun.com>,
"'Mike Borella'"
<Mike_Borella@mw.3com.com>
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" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian <ylian.saint-hilaire@intel.com> 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: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. 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 <akrywaniuk@TimeStep.com>
cc: "Strahm, Bill" <bill.strahm@intel.com>, 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 <akrywaniuk@TimeStep.com> on 11/14/99 03:02:14 AM
To: "Strahm, Bill" <bill.strahm@intel.com>, 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 <devrimu@yunus.mam.gov.tr>
To: shganguly@hss.hns.com
cc: Andrew Krywaniuk <akrywaniuk@TimeStep.com>,
"Strahm, Bill" <bill.strahm@intel.com>, ipsec@lists.tislabs.com
Subject: RE: Some queries regarding IP security
In-Reply-To: <6525682A.0014B964.00@sandesh.hss.hns.com>
Message-ID: <Pine.HPP.3.96.991115090558.17725A-100000@yunus.mam.gov.tr>
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 <akrywaniuk@TimeStep.com> on 11/14/99 03:02:14 AM
>
> To: "Strahm, Bill" <bill.strahm@intel.com>, 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 <pkoning@xedia.com>
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 <akrywaniuk@TimeStep.com> 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" <Mike_Borella@mw.3com.com>
To: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
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" <mcr@sandelman.ottawa.on.ca> on 11/14/99 09:04:09 PM
Sent by: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
cc: (Mike Borella/MW/US/3Com)
Subject: Re: IKE negotiation/rekeying problem with RSIP
>>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian <ylian.saint-hilaire@intel.com>
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: <A HREF="
http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
">mcr@sandelman.ottawa.on.ca</A>. 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 <kivinen@ssh.fi>
To: "Mike Borella" <Mike_Borella@mw.3com.com>
Cc: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>,
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" <mleech@nortelnetworks.com>
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" <Mike_Borella@mw.3com.com>
To: "Saint-Hilaire, Ylian" <ylian.saint-hilaire@intel.com>
cc: ipsec@lists.tislabs.com, "'gab@sun.com'" <gab@sun.com>, nat@livingston.com,
"David Grabelsky" <David_Grabelsky@mw.3com.com>
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" <ylian.saint-hilaire@intel.com> on 11/14/99 06:39:34 PM
Sent by: "Saint-Hilaire, Ylian" <ylian.saint-hilaire@intel.com>
To: ipsec@lists.tislabs.com, "'gab @sun.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" <ylian.saint-hilaire@intel.com>
To: "'Mike Borella'" <Mike_Borella@mw.3com.com>,
"Saint-Hilaire, Ylian"
<ylian.saint-hilaire@intel.com>
Cc: ipsec@lists.tislabs.com, "'gab@sun.com'" <gab@sun.com>, nat@livingston.com,
David Grabelsky <David_Grabelsky@mw.3com.com>
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" <ylian.saint-hilaire@intel.com> on 11/14/99 06:39:34
PM
Sent by: "Saint-Hilaire, Ylian" <ylian.saint-hilaire@intel.com>
To: ipsec@lists.tislabs.com, "'gab @sun.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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Saint-Hilaire, Ylian" <ylian.saint-hilaire@intel.com>
CC: "'Mike Borella'" <Mike_Borella@mw.3com.com>, ipsec@lists.tislabs.com,
"'gab@sun.com'" <gab@sun.com>, nat@livingston.com,
David Grabelsky <David_Grabelsky@mw.3com.com>
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 <anfreema@cisco.com>
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" <mcr@sandelman.ottawa.on.ca>,
<ipsec@lists.tislabs.com>
Cc: "Ylian" <ylian.saint-hilaire@intel.com>
Reply-To: <gab@sun.com>
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 <ylian.saint-hilaire@intel.com>
>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 <tjenkins@TimeStep.com>
To: "'ipsec@lists.tislabs.com'" <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 <tjenkins@TimeStep.com>
To: Slava Kavsan <bkavsan@ire-ma.com>
Cc: "'ipsec@lists.tislabs.com'" <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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Jenkins <tjenkins@TimeStep.com>
CC: "'ipsec@lists.tislabs.com'" <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 <wprice@cyphers.net>
Reply-To: wprice@cyphers.net
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Jenkins <tjenkins@TimeStep.com>
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
<pgpfone://cast.cyphers.net>
-----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 <tjenkins@TimeStep.com>
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 <bmccann@indusriver.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Slava Kavsan <bkavsan@ire-ma.com>
CC: "'ipsec@lists.tislabs.com'" <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 <tjenkins@TimeStep.com>
To: Slava Kavsan <bkavsan@ire-ma.com>
Cc: "'ipsec@lists.tislabs.com'" <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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben McCann <bmccann@indusriver.com>
CC: "'ipsec@lists.tislabs.com'" <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" <smb@research.att.com>
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" <smb@research.att.com>
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 <kivinen@ssh.fi>
To: <gab@sun.com>
Cc: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>,
<ipsec@lists.tislabs.com>, "Ylian" <ylian.saint-hilaire@intel.com>
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 <gab@Eng.Sun.Com>
Reply-To: Gabriel Montenegro <gab@Eng.Sun.Com>
Subject: Re: IKE negotiation/rekeying problem with RSIP
To: Tero Kivinen <kivinen@ssh.fi>
Cc: ipsec@lists.tislabs.com, Ylian <ylian.saint-hilaire@intel.com>
In-Reply-To: "Your message with ID" <199911162223.AAA29181@torni.ssh.fi>
Message-ID: <Roam.SIMC.2.0.6.942792501.6433.gab@eng.sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Tero Kivinen" <kivinen@ssh.fi> 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 <kivinen@ssh.fi>
To: Tim Jenkins <tjenkins@TimeStep.com>
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."
<Roam.SIMC.2.0.6.942792501.6433.gab@eng.sun.com>
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" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Gabriel" == Gabriel Montenegro <gab@Eng.Sun.Com> writes:
Gabriel> "Tero Kivinen" <kivinen@ssh.fi> 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: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. 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 <kivinen@ssh.fi>
To: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@lists.tislabs.com
Subject: Re: IKE negotiation/rekeying problem with RSIP
In-Reply-To: <199911170044.TAA04775@istari.sandelman.ottawa.on.ca>
References: <Roam.SIMC.2.0.6.942792501.6433.gab@eng.sun.com>
<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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tero Kivinen <kivinen@ssh.fi>
CC: Tim Jenkins <tjenkins@TimeStep.com>, 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" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> 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: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. 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" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> 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 <dharkins@cisco.com>
* 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: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. 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: <ipsec@lists.tislabs.com>,
"Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Reply-To: <gab@sun.com>
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" <mcr@sandelman.ottawa.on.ca> 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 <tjenkins@TimeStep.com>
To: Tero Kivinen <kivinen@ssh.fi>, "Scott G. Kelly" <skelly@redcreek.com>
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" <skelly@redcreek.com>
cc: Tero Kivinen <kivinen@ssh.fi>, Tim Jenkins <tjenkins@TimeStep.com>,
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 <carney@securecomputing.com>
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:
<Fine ascii art deleted >
> 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" <ylian.saint-hilaire@intel.com>
To: "'Tim Jenkins'" <tjenkins@TimeStep.com>, 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 <pkoning@xedia.com>
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 <carney@securecomputing.com> 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 <pkoning@xedia.com>
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 <carney@securecomputing.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> >>>>> "Mike" == Mike Carney <carney@securecomputing.com> 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" <bill.strahm@intel.com>
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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Carney <carney@securecomputing.com>
CC: Paul Koning <pkoning@xedia.com>, 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: <D7D145EB4903D311985E00A0C9FC76FE31D611@sjcxch01.hifn.com>
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 <akrywaniuk@TimeStep.com>
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 <kivinen@ssh.fi>
To: Tim Jenkins <tjenkins@TimeStep.com>
Cc: "Scott G. Kelly" <skelly@redcreek.com>, 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 <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> 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 <akrywaniuk@TimeStep.com>
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 <dharkins@network-alchemy.com>
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 <tjenkins@TimeStep.com>
To: Tero Kivinen <kivinen@ssh.fi>
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 <tjenkins@TimeStep.com>
To: Dan Harkins <dharkins@network-alchemy.com>
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" <kimed@nortelnetworks.com>
Reply-To: "Kim Edwards" <kimed@nortelnetworks.com>
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: <Rosa.SunOS5.5.1.2.1.991118101410.10238I@bcarsc7d>
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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
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 <wsimpson@greendragon.com>
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:
<black>
"<black> 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 <black>).
<black>
"In summary, <black> 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 <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Public Key Encryption Authentication
In-Reply-To: <199911181511.KAA04134@lists.tislabs.com>
Message-ID: <Pine.BSI.3.91.991118133533.24070A-100000@spsystems.net>
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 <akrywaniuk@TimeStep.com>
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 <pkoning@xedia.com>
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 <akrywaniuk@TimeStep.com> 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 <tjenkins@TimeStep.com>
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 <dharkins@network-alchemy.com>
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 <kivinen@ssh.fi>
To: "Kim Edwards" <kimed@nortelnetworks.com>
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 <kivinen@ssh.fi>
To: Tim Jenkins <tjenkins@TimeStep.com>
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" <sfanning@cisco.com>
To: "Paul Koning" <pkoning@xedia.com>, <akrywaniuk@TimeStep.com>
Cc: <ipsec@lists.tislabs.com>
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 <akrywaniuk@TimeStep.com> 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 <akrywaniuk@TimeStep.com>
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 <akrywaniuk@TimeStep.com> 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 <paul.hoffman@vpnc.org>
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: <v04220802b45a7c21b036@[204.167.101.26]>
Date: Thu, 18 Nov 1999 23:02:11 -0500
To: William Allen Simpson <wsimpson@greendragon.com>, raven@ietf.org,
ietf-ppp@merit.edu, ipsec@lists.tislabs.com
From: Robert Hettinga <rah@shipwright.com>
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 <rah@shipwright.com>, CYBERIA-L@LISTSERV.AOL.COM,
cryptography@c2.net, cypherpunks@cyberpass.net
From: Matthew Lyle <matt@nova.org>
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 <wsimpson@greendragon.com>
>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 <mailto: rah@ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
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" <kimed@nortelnetworks.com>
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" <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 <kimed@nortelnetworks.com>
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 <wsimpson@greendragon.com>, raven@ietf.org
From: Christian Huitema <huitema@research.telcordia.com>
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 <bmccann@indusriver.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
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 <bmccann@indusriver.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@network-alchemy.com>
CC: Tim Jenkins <tjenkins@TimeStep.com>, 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 <tjenkins@TimeStep.com>
To: Tero Kivinen <kivinen@ssh.fi>
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 <tjenkins@TimeStep.com>
To: Dan Harkins <dharkins@network-alchemy.com>
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 <saroff@poseidon.vs.lmco.com>
Subject: Re: [Raven] FBI secret police
In-reply-to: Christian Huitema <huitema@research.telcordia.com> <"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 <pkoning@xedia.com>
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 <akrywaniuk@TimeStep.com> 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 <hajo@knobloch.de>
X-Sender: hajo@lagavulin.xlink.net.
Reply-To: hans-joachim@knobloch.de
To: ipsec@lists.tislabs.com
Subject: Error recovery?
Message-ID: <Pine.LNX.4.20.9911191840570.27932-100000@lagavulin.xlink.net.>
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" <Mike_Borella@mw.3com.com>
To: Tero Kivinen <kivinen@ssh.fi>
cc: gab@sun.com, "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>,
ipsec@lists.tislabs.com, "Ylian" <ylian.saint-hilaire@intel.com>
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 <kivinen@ssh.fi> on 11/16/99 04:23:45 PM
Sent by: Tero Kivinen <kivinen@ssh.fi>
To: gab@sun.com
cc: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>,
ipsec@lists.tislabs.com, "Ylian" <ylian.saint-hilaire@intel.com> (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 <wsimpson@greendragon.com>
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: <v0422080cb45a34fbf25b@[204.167.101.17]>
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 <akrywaniuk@TimeStep.com>
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 <akrywaniuk@TimeStep.com>
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" <mkumar@intotoinc.com>
To: <hans-joachim@knobloch.de>
Cc: <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2><FONT face=3D"Times New =
Roman">Hi,<BR></FONT></FONT><FONT=20
face=3D"Times New Roman"><FONT size=3D2></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman"></FONT></FONT><FONT=20
face=3D"Times New Roman"><FONT size=3D2></FONT></FONT> </DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman">>Hans-Joachim =
Knobloch=20
wrote:<BR><BR>> Consider the case that two hosts communicate via two =
IPSec=20
security<BR>>=20
gateways<BR>> &nb=
sp; =20
A <---> SG1 <-----> SG2 <---> B<BR>><BR>> and =
that=20
appropriate ISAKMP and IPSec SAs are established. Let us call<BR>> =
these SAs=20
SA1, SA2AB and SA2BA respectively.<BR>> Now what happens, when SG2 is =
reset?<BR>><BR>> When B sends a packet to A everything should be =
fine,=20
since SG2 will<BR>> initiate new phase 1 and phase 2 =
exchanges.<BR>> But=20
what if A sends a packet to B? SG1 will process the packet with =
the<BR>> old=20
IPsec SA2AB and SG2 will receive a packet with a most probably =
unknown<BR>>=20
SPI. Is this supposed to happen until SA2AB does "naturally=20
expire"?<BR>> Do we have to set SA lifetime short enough and/or =
hope=20
that B will also<BR>> send a packet more sooner than=20
later?</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New =
Roman"></FONT></FONT> </DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman"></FONT></FONT><FONT=20
face=3D"Times New Roman" size=3D2> Currently, there is no standard =
way to do=20
this and I guess it is left<BR> to the =
implementation.<BR><BR> For=20
phase1 SA:<BR> Assume SG1 has phase1 SA where as SG2 =
does not=20
have corresponding<BR> phase1 =
SA.<BR> If=20
phase2 is initiated by SG2, there is no problem,because it=20
negotiaties<BR> new phase1 SA with the=20
SG1.<BR><BR> If phase2 is initiated by SG1, then the =
SG1 never=20
receives second<BR> quick mode message, since SG2 does =
not=20
have phase1 SA.<BR> SG1 quick mode negotiation fails =
and then=20
SG1 can take action based<BR> on implementation. In =
our=20
implementation, we delete the phase1 SA<BR> if the=20
initiator(SG1) does not receive second message for all=20
retries.<BR> ( Note that we have configuration option =
to do=20
this or not ).<BR><BR>For phase2 SA:<BR> This is=20
tricky.<BR> Again here, assume SG1 has phase2 SA =
whereas SG2=20
does not have<BR> corresponding phase2=20
SA.<BR><BR> If the packet comes on SG2 destined to =
SG1, there=20
is no problem as<BR> SG2 negotiates new phase2=20
SA.<BR><BR> If the packet comes on SG1 destined to =
SG2, SG1=20
applies security<BR> and sends it to the SG2 and SG2 =
drops the=20
packet. There will be<BR> no packets transferred =
between=20
these two SG for that session.<BR><BR> Here, following =
can be=20
done:<BR> Using IKE, you always get two SAs. One for =
oubound=20
and other for<BR> inbound.<BR> Here, =
I feel=20
we can use some sort of timeouts.<BR> That is whenever =
packet=20
is sent, start software timer with some<BR> =
preconfigured=20
value ( say 5 minutes )<BR> Whenever packet is =
receieved on=20
the corresponding inbound SA,<BR> then disable the =
timer on=20
the outbound SA.<BR> If no packets are received within =
5=20
minutes on inbound SA, then<BR> delete both=20
SAs.<BR> Here, basic assumption is that the there will =
be=20
always some packets<BR> coming inbound within 5 =
minutes after=20
sending any outbound packet.<BR> This mechanism still =
works=20
otherwise, but at the expense of one<BR> quick mode=20
negotiation.<BR></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman">><BR>> =
Alternatively one=20
could imagine that SG2 sends SG1 some kind of<BR>> (ICMP?) message to =
tell it=20
to invalidate SA2AB. But then, this might be<BR>> abused by an =
attacker to=20
cause unnecessary ISAKMP traffic and a service<BR>> disruption until =
new SAs=20
are installed.</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman">><BR>> In the =
above=20
example, when SA2AB expires, SG1 will probably initiate a<BR>> phase =
2=20
exchange with the old SA1. What is the correct way for SG2 to<BR>> =
respond to=20
this? Initiate a nes phase 1 exchange? Send an error<BR>> =
notification to SG2=20
(then necessarily unencrypted due to nonexistant<BR>> ISAKMP SA)? The =
latter=20
might open up a denial-of-service attack by sending<BR>> spoofed =
error=20
notifications to make SG1 invalidate its existing SAs and<BR>> thus =
cause=20
lots of unnecessary ISAKMP traffic and service=20
disruption.<BR></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New =
Roman"></FONT></FONT> </DIV>
<DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman">See above. The above =
is a=20
possible means of addressing the problem, though</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman">not explicitly stated =
in any RFC.=20
There are, obviously other alternative </FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Times New Roman"></FONT></FONT><FONT=20
face=3D"Times New Roman" size=3D2>solutions possible.</FONT></DIV></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" =
size=3D2>Regards.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>- =
Kumar</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" =
size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>Product=20
Manager</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>Intoto =
Inc.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>3160, de La =
Cruz Blvd;=20
Ste #100</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2>Santa =
Clara, <BR>CA=20
95054</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Times New Roman" size=3D2><A=20
href=3D"http://www.intotoinc.com">www.intotoinc.com</A></FONT></DIV></BOD=
Y></HTML>
------=_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" <todd.glassey@www.gmtsw.com>
To: "Andrew Krywaniuk" <akrywaniuk@TimeStep.com>, <ipsec@lists.tislabs.com>
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" <akrywaniuk@TimeStep.com>
To: <ipsec@lists.tislabs.com>
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" <sgkelly@ix.netcom.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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 <dharkins@network-alchemy.com>
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: <ipsec@lists.tislabs.com>, <dharkins@network-alchemy.com>,
<carrel@rback.net>
Reply-To: <gab@sun.com>
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" <jkennedy@trustpoint.com>
To: "Ben Laurie" <ben@algroup.co.uk>
Cc: <pgut001@cs.auckland.ac.nz>, <ietf-pkix@imc.org>, <ietf-smime@imc.org>,
<ipsec@lists.tislabs.com>, <ekr@rtfm.com>, <djohnson@certicom.com>,
<housley@spyrus.com>, <amit@trustpoint.com>
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: <NDBBKGCMPJCKIDPKAHACMENICAAA.jkennedy@trustpoint.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 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" <jkennedy@trustpoint.com>
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 <ben@algroup.co.uk>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: "John C. Kennedy" <jkennedy@trustpoint.com>
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: <NDBBKGCMPJCKIDPKAHACIENDCAAA.jkennedy@trustpoint.com>
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" <jkennedy@trustpoint.com>
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>, <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
Date: Sun, 21 Nov 1999 01:17:21 -0800
Message-ID: <NDBBKGCMPJCKIDPKAHACIENDCAAA.jkennedy@trustpoint.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 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" <dharkins@network-alchemy.com>
Cc: <carrel@rback.net>, <ipsec@lists.tislabs.com>, <tytso@mit.edu>
Reply-To: <gab@sun.com>
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 <saroff@poseidon.vs.lmco.com>
Subject: Re: [Raven] FBI secret police FAQ#1
In-reply-to: William Allen Simpson <wsimpson@greendragon.com> <"[Raven] FBI secret police FAQ#1"@[138.209.240.12]>
To: William Allen Simpson <wsimpson@greendragon.com>, 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: <v0422080cb45a34fbf25b@[204.167.101.17]> <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" <djohnson@certicom.com>
To: "John C. Kennedy" <jkennedy@trustpoint.com>
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 <elaine.barker@nist.gov>,
Sharon Keller <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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" <jkennedy@trustpoint.com> 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" <jkennedy@trustpoint.com>
From: Russ Housley <housley@spyrus.com>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other
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>, <jis@mit.edu>, <mleech@nortelnetworks.com>
In-Reply-To: <NDBBKGCMPJCKIDPKAHACIENDCAAA.jkennedy@trustpoint.com>
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 <Ari.Huttunen@datafellows.com>
Organization: Data Fellows Oyj
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-list <ipsec@lists.tislabs.com>
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: <v03110709b45f3d4bd633@[192.233.50.131]>
In-Reply-To: <38359C77.87434F6@greendragon.com>
References: <v0422080cb45a34fbf25b@[204.167.101.17]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 22 Nov 1999 13:36:27 -0500
To: William Allen Simpson <wsimpson@greendragon.com>
From: "Robert W. Shirey" <rshirey@bbn.com>
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 <mikewill@ibm.net>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSec <ipsec@lists.tislabs.com>, ippcp <ippcp@external.cisco.com>
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 <pkoning@xedia.com>
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 <kivinen@ssh.fi>
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 <kivinen@ssh.fi>
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
<empty>
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 <akrywaniuk@TimeStep.com>
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
> <empty>
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 <zegman@checkpoint.com>
Organization: Check Point
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ari Huttunen <Ari.Huttunen@datafellows.com>
CC: ipsec-list <ipsec@lists.tislabs.com>
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" <svan@trustworks.com>
Organization: TWS
To: tytso@mit.edu, Tero Kivinen <kivinen@ssh.fi>
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
> <empty>
>
> 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 <wdixon@microsoft.com>
To: "'Tamir Zegman'" <zegman@checkpoint.com>,
Ari Huttunen
<Ari.Huttunen@datafellows.com>
Cc: ipsec-list <ipsec@lists.tislabs.com>
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 <zegman@checkpoint.com>
Organization: Check Point
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Dixon <wdixon@microsoft.com>
CC: ipsec-list <ipsec@lists.tislabs.com>
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)" <yevgeniy_polulyakh@hp.com>
To: "'hans-joachim@knobloch.de'" <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" <djohnson@certicom.com>
To: Russ Housley <housley@spyrus.com>
cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>,
Sharon Keller <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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 <housley@spyrus.com> on 11/22/99 01:50:56 PM
To: Don Johnson/Certicom@Certicom
cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>, Sharon
Keller <skeller@nist.gov>, Simon Blake-Wilson/Certicom@Certicom, "Phil
Griffin" <Phil_Griffin@certicom.com>
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" <djohnson@certicom.com>
From: Russ Housley <housley@spyrus.com>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other
Cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>,
Sharon Keller <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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 <housley@spyrus.com> on 11/22/99 01:50:56 PM
>
>To: Don Johnson/Certicom@Certicom
>cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>,
> Sharon
> Keller <skeller@nist.gov>, Simon Blake-Wilson/Certicom@Certicom, "Phil
> Griffin" <Phil_Griffin@certicom.com>
>
>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" <djohnson@certicom.com>
From: Russ Housley <housley@spyrus.com>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other
Cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>,
Sharon Keller <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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 <housley@spyrus.com> 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" <djohnson@certicom.com>
To: Russ Housley <housley@spyrus.com>
cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>,
Sharon Keller <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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 <housley@spyrus.com> on 11/22/99 01:50:56 PM
To: Don Johnson/Certicom@Certicom
cc: "John C. Kennedy" <jkennedy@trustpoint.com>, 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 <elaine.barker@nist.gov>, Sharon
Keller <skeller@nist.gov>, Simon Blake-Wilson/Certicom@Certicom, "Phil
Griffin" <Phil_Griffin@certicom.com>
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" <jkennedy@trustpoint.com>
To: "Russ Housley" <housley@spyrus.com>
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>, <jis@mit.edu>, <mleech@nortelnetworks.com>,
"Elaine Barker" <elaine.barker@nist.gov>,
"Sharon Keller" <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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: <NDBBKGCMPJCKIDPKAHACGEPBCAAA.jkennedy@trustpoint.com>
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, <draft-ietf-smime-small-subgroup-02.txt>
and <draft-ietf-pkix-dhpop-02.txt>, 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" <djohnson@certicom.com>
To: "John C. Kennedy" <jkennedy@trustpoint.com>
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" <elaine.barker@nist.gov>,
"Sharon Keller" <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>, 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" <jkennedy@trustpoint.com> 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" <elaine.barker@nist.gov>,
"Sharon Keller" <skeller@nist.gov>, Simon Blake-Wilson/Certicom@Certicom,
"Phil Griffin" <Phil_Griffin@certicom.com>
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'? <sigh>
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" <jkennedy@trustpoint.com> 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" <jkennedy@trustpoint.com>
To: "Don Johnson" <djohnson@certicom.com>
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" <elaine.barker@nist.gov>,
"Sharon Keller" <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
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: <NDBBKGCMPJCKIDPKAHACIEOOCAAA.jkennedy@trustpoint.com>
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'? <sigh>
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" <jkennedy@trustpoint.com> 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" <jkennedy@trustpoint.com>
From: Russ Housley <housley@spyrus.com>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other
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>, <jis@mit.edu>, <mleech@nortelnetworks.com>,
"Elaine Barker" <elaine.barker@nist.gov>,
"Sharon Keller" <skeller@nist.gov>,
"Simon Blake-Wilson" <sblakewi@certicom.com>,
"Phil Griffin" <Phil_Griffin@certicom.com>
In-Reply-To: <NDBBKGCMPJCKIDPKAHACGEPBCAAA.jkennedy@trustpoint.com>
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, <draft-ietf-smime-small-subgroup-02.txt>
>and <draft-ietf-pkix-dhpop-02.txt>, 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 <mikewill@ibm.net>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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 <pkoning@xedia.com>
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 <mikewill@ibm.net>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSec <ipsec@lists.tislabs.com>
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 <pkoning@xedia.com>
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 <bmccann@indusriver.com>
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 <mikewill@ibm.net>
From: Avram Shacham <shacham@cisco.com>
Subject: Re: IPComp rfc2393bis-00
Cc: ippcp <ippcp@external.cisco.com>, 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.
<draft-shacham-ippcp-rfc2393bis-01.txt> 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 <shacham@cisco.com>
Subject: Re: IPComp rfc2393bis-00
Cc: ippcp <ippcp@external.cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <26138.943401624@coconut.itojun.org>
References: <shacham's message of Tue, 23 Nov 1999 15:55:43 PST. <199911232355.PAA05726@honeybee.cisco.com>
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 <shacham@cisco.com>
Subject: Re: IPComp rfc2393bis-00
Cc: ippcp <ippcp@external.cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <25892.943400328@coconut.itojun.org>
References: <shacham's message of Tue, 23 Nov 1999 15:14:26 PST. <199911232314.PAA04475@honeybee.cisco.com>
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 <shacham@cisco.com>
Subject: Re: IPComp rfc2393bis-00
Cc: ippcp <ippcp@external.cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <26431.943403028@coconut.itojun.org>
References: <shacham's message of Tue, 23 Nov 1999 16:12:53 PST. <199911240012.QAA06259@honeybee.cisco.com>
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 <shacham@cisco.com>
Subject: Re: IPComp rfc2393bis-00
Cc: ippcp <ippcp@external.cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <26542.943403433@coconut.itojun.org>
References: <shacham's message of Tue, 23 Nov 1999 16:12:53 PST. <199911240012.QAA06259@honeybee.cisco.com>
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 <kivinen@ssh.fi>
To: "Valery Smyslov" <svan@trustworks.com>
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 <kivinen@ssh.fi>
cc: "Valery Smyslov" <svan@trustworks.com>, 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 <dharkins@network-alchemy.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
<commercial advertisement>
Note that this is the technique used in CRACK. So CRACK will also
authenticate all optional payloads as well as the outer ISAKMP header.
</commercial advertisement>
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 <kanta@hideki.iis.u-tokyo.ac.jp>
Date: Wed, 24 Nov 1999 11:45:39 +0900
To: Ari Huttunen <Ari.Huttunen@datafellows.com>
Cc: ipsec-list <ipsec@lists.tislabs.com>
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 <Ari.Huttunen@datafellows.com> 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 <kivinen@ssh.fi>
To: Dan Harkins <dharkins@network-alchemy.com>
Cc: "Valery Smyslov" <svan@trustworks.com>, 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:
> <commercial advertisement>
> Note that this is the technique used in CRACK. So CRACK will also
> authenticate all optional payloads as well as the outer ISAKMP header.
> </commercial advertisement>
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 <shacham@cisco.com>
cc: ippcp <ippcp@external.cisco.com>, 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 <sbeaulieu@TimeStep.com>
To: Mike Williams <mikewill@ibm.net>,
Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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 <shacham@cisco.com>
cc: ippcp <ippcp@external.cisco.com>, 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 <shacham@cisco.com>
cc: ippcp <ippcp@external.cisco.com>, 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 <bmccann@indusriver.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kierstead <pkierstead@TimeStep.com>
CC: Mike Williams <mikewill@ibm.net>,
Andrew Krywaniuk <akrywaniuk@TimeStep.com>, 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 <shacham@cisco.com>
cc: ippcp <ippcp@external.cisco.com>, 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 <pkierstead@TimeStep.com>
To: Mike Williams <mikewill@ibm.net>,
Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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" <svan@trustworks.com>
To: "Tero Kivinen" <kivinen@ssh.fi>
Cc: <ipsec@lists.tislabs.com>
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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kierstead <pkierstead@TimeStep.com>
CC: Mike Williams <mikewill@ibm.net>,
Andrew Krywaniuk <akrywaniuk@TimeStep.com>, 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 <pkoning@xedia.com>
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 <itojun@iijlab.net> 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 <akrywaniuk@TimeStep.com>
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 <kivinen@ssh.fi>
To: "Valery Smyslov" <svan@trustworks.com>
Cc: <ipsec@lists.tislabs.com>
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 <kivinen@ssh.fi>
To: Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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" <svan@trustworks.com>
Organization: TWS
To: Tero Kivinen <kivinen@ssh.fi>
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: <ipsec@lists.tislabs.com>
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 <tjenkins@TimeStep.com>
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 <akrywaniuk@TimeStep.com>
To: Tero Kivinen <kivinen@ssh.fi>, Andrew Krywaniuk <akrywaniuk@TimeStep.com>
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" <peter.lewis@upperside.fr>
To: <imesh-cip@mailbase.ac.uk>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT color=3D#000000 size=3D3>IPSec 2000 Global Summit: the =
international=20
rendez-vous. A CFP is online at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D3><A=20
href=3D"http://www.upperside.fr/baipsecy2k.htm">http://www.upperside.fr/b=
aipsecy2k.htm</A></FONT></DIV>
<DIV> </DIV></DIV></BODY></HTML>
------=_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: <FD3672F0C0A4D01196B30020AFFBEDC603986AB8@exs05.ex.nus.edu.sg>
From: P A Centre Visitor <engv13@nus.edu.sg>
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 <anfreema@cisco.com>
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 <bob@larribeau.com>.
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: <Pine.LNX.4.21.9911291538200.16636-100000@spickard.inside.sealabs.com>
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."
<Pine.LNX.4.21.9911291538200.16636-100000@spickard.inside.sealabs.com>
Date: Tue, 30 Nov 1999 08:02:32 -0800
From: "Derrell D. Piper" <ddp@network-alchemy.com>
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" <elfa@elfa.sk>
To: <diffserv@ietf.org>
Cc: <qosr@newbridge.com>, <int-serv@isi.edu>, <te-wg@uu.net>,
<xtp-relay@cs.concordia.ca>, <sigmedia@bellcore.com>, <tccc@ieee.org>,
<Conferencesa@comsoc.org>, <Undisclosed-Recipient:@s2.smtp.oleane.net>,
<end2end-interest@isi.edu>, <fokus-user@fokus.gmd.de>,
<hipparch@sophia.inria.fr>, <giga@tele.pitt.edu>, <WG-ALL@TERENA.NL>,
<rap@iphighway.com>, <ippm@advanced.org>,
<iptel@lists.research.bell-labs.com>, <nat@livingston.com>,
<pilc@grc.nasa.gov>, <tcpsat@grc.nasa.gov>, <ipsec@lists.tislabs.com>,
<www-security@ns2.Rutgers.EDU>, <mpls@uu.net>, <lsma@gmu.edu>,
<bucko@elfa.sk>, <Saadawi@aol.com>, "sivy" <sivy@elfa.sk>,
<webmaster@telecom.sk>, <ECA@uga.cc.uga.edu>, <ian.keene@gartner.com;>,
<palo@bgsdaustrab.sk>, <m.hackenberg@alcatel.de>,
<neversova.eva@slsp.sk>, <cis@cis.sk>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec <ipsec@lists.tislabs.com>
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 <tjenkins@TimeStep.com>
To: Slava Kavsan <bkavsan@ire-ma.com>, ipsec <ipsec@lists.tislabs.com>
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" <ddp@network-alchemy.com>
cc: ipsec@lists.tislabs.com
Subject: Re: ISAKMP Configuration Method
In-Reply-To: <199911301602.IAA15074@gallium.network-alchemy.com>
Message-ID: <Pine.LNX.4.21.9911300906400.17356-100000@spickard.inside.sealabs.com>
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 <shacham@cisco.com>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Jenkins <tjenkins@TimeStep.com>
CC: ipsec <ipsec@lists.tislabs.com>
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."
<Pine.LNX.4.21.9911300906400.17356-100000@spickard.inside.sealabs.com>
Date: Tue, 30 Nov 1999 11:00:51 -0800
From: "Derrell D. Piper" <ddp@network-alchemy.com>
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 <bkavsan@ire-ma.com>
cc: ipsec <ipsec@lists.tislabs.com>
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" <ddp@network-alchemy.com>
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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Slava Kavsan <bkavsan@ire-ma.com>
CC: ipsec <ipsec@lists.tislabs.com>
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 <kivinen@ssh.fi>
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" <ddp@network-alchemy.com>
cc: ipsec@lists.tislabs.com
Subject: Re: ISAKMP Configuration Method
In-Reply-To: <199911301900.LAA15474@gallium.network-alchemy.com>
Message-ID: <Pine.LNX.4.21.9911301118470.17423-100000@spickard.inside.sealabs.com>
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 <pkoning@xedia.com>
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 <ddp@network-alchemy.com> 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 <tjenkins@TimeStep.com>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Koning <pkoning@xedia.com>
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 <ddp@network-alchemy.com> 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" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Slava Kavsan <bkavsan@ire-ma.com>
CC: Paul Koning <pkoning@xedia.com>, 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 <vilhuber@cisco.com>
To: Slava Kavsan <bkavsan@ire-ma.com>
cc: Paul Koning <pkoning@xedia.com>, 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: <Pine.SOL.3.96.991130161439.5734O-100000@jvilhube-ss20.cisco.com>
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 <ddp@network-alchemy.com> 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 <rcharlet@redcreek.com>
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 <ipsec@lists.tislabs.com>
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 <vilhuber@cisco.com>
cc: Slava Kavsan <bkavsan@ire-ma.com>, Paul Koning <pkoning@xedia.com>,
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."
<Pine.SOL.3.96.991130161439.5734O-100000@jvilhube-ss20.cisco.com>
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 <dharkins@network-alchemy.com>
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 <vilhuber@cisco.com>
To: Dan Harkins <dharkins@network-alchemy.com>
cc: Slava Kavsan <bkavsan@ire-ma.com>, Paul Koning <pkoning@xedia.com>,
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: <Pine.SOL.3.96.991130174212.6670A-100000@jvilhube-ss20.cisco.com>
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 <vilhuber@cisco.com>
cc: Slava Kavsan <bkavsan@ire-ma.com>, Paul Koning <pkoning@xedia.com>,
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."
<Pine.SOL.3.96.991130174212.6670A-100000@jvilhube-ss20.cisco.com>
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 <dharkins@network-alchemy.com>
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 <paul.hoffman@vpnc.org>
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 <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@network-alchemy.com>
CC: Jan Vilhuber <vilhuber@cisco.com>, Paul Koning <pkoning@xedia.com>,
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 <vilhuber@cisco.com>
To: Bronislav Kavsan <bkavsan@ire-ma.com>
cc: Dan Harkins <dharkins@network-alchemy.com>,
Paul Koning <pkoning@xedia.com>, 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: <Pine.SOL.3.96.991130193836.6670G-100000@jvilhube-ss20.cisco.com>
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 <vilhuber@cisco.com>
To: Dan Harkins <dharkins@network-alchemy.com>
cc: Slava Kavsan <bkavsan@ire-ma.com>, Paul Koning <pkoning@xedia.com>,
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: <Pine.SOL.3.96.991130193435.6670D-100000@jvilhube-ss20.cisco.com>
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