Re: Status of IPSEC Key Management
"C. Harald Koch" <chk@border.com> Mon, 09 September 1996 14:49 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa11753; 9 Sep 96 10:49 EDT
Received: by relay.hq.tis.com; id KAA05996; Mon, 9 Sep 1996 10:19:46 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma005991; Mon, 9 Sep 96 10:19:20 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA23109; Mon, 9 Sep 96 10:18:28 EDT
Received: by relay.hq.tis.com; id KAA05982; Mon, 9 Sep 1996 10:19:16 -0400
Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma005957; Mon, 9 Sep 96 10:18:50 -0400
Received: by janus.border.com id <18473-1>; Mon, 9 Sep 1996 10:19:03 -0400
Message-Id: <96Sep9.101903edt.18473-1@janus.border.com>
To: perry@piermont.com
Cc: Stephen Kent <kent@bbn.com>, ipsec@TIS.COM
Subject: Re: Status of IPSEC Key Management
References: <9609090724.aa08819@neptune.TIS.COM>
In-Reply-To: perry's message of "Sat, 07 Sep 1996 11:30:43 -0400". <9609090724.aa08819@neptune.TIS.COM>
From: "C. Harald Koch" <chk@border.com>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 368 7157
X-Uri: <URL:http://www.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2; hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm; z:NJ7pss)l__Cw+.>xUJ) did@Pr9
Date: Mon, 09 Sep 1996 10:20:26 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <9609090724.aa08819@neptune.TIS.COM>, "Perry E. Metzger" writes: > > In a large internet, key lookup will be required, the result of which > will be that SKIP will have no advantage whatsoever in terms of number > of message exchanges compared with other techniques. Piggy-back the keys in the Additional Records portion of the DNS response to the initial hostname lookup (I believe some SKIP implementations already do this). -- C. Harald Koch | Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change. From: Ran Atkinson <rja@cisco.com> Date: Mon, 9 Sep 1996 09:52:26 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: FYI: Multicast Key Management documents Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609091253.aa13265@neptune.TIS.COM> There are a number of documented approaches to multicast key management that this group should consider. Ones that have not been marketed very aggressively include: Group Key Management Protocol (GKMP), developed by SPARTA under ARPA sponsorship circa 1994 based on technology that dates back somewhat before 1994. This has some proof-of-concept code written under the ARPA sponsorship. This was presented at the December 1994 IETF in San Jose and has current Internet-Drafts online as: draft-harney-gkmp-arch-01.txt draft-harney-gkmp-spec-01.txt and will be moving to RFC in the near future. Scalable Multicast Key Distribution, developed by Tony Ballardie, and described in RFC-1949. The above have significantly different technology approaches. Both of these approaches will work well not only with multicasting but also with RSVP and are worth careful review and consideration. I'm told that work is underway at several places (e.g. ORNL) on a PF_KEY-based freely distributable implementation of GKMP technology inside the ISAKMP framework. Ran rja@cisco.com -- To: Stephen Kent <kent@bbn.com> Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management In-Reply-To: Your message of "Mon, 09 Sep 1996 10:42:28 EDT." <v02130502ae59db0ba8ff@[128.89.0.110]> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 09 Sep 1996 13:07:35 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609091310.aa13559@neptune.TIS.COM> Stephen Kent writes: > In the Mobile IP case, the communication being authenticated (as > per the current specs) is between a mobile node and it's home agent, so > there is plenty of time to pre-load and pre-compute the D-H value. Then again, there is no reason an Oakley like protocol can't work just fine there as well -- the associations are long lived. > In later instances one may wish to autnenticate communication > between the mobile node and foreign agents, and between home and > foreign agents. Even there, caching ought to enable one to avoid > fetches on many (most?) communications. And again, since the associations are fairly long lived, Oakley or Photuris or what have you works just fine there. BTW, I'm only arguing that SKIP doesn't actually have an advantage in speed here -- not that its worse. Frankly, at this point I'd like to see the working group agree to recess for six months and see what people implement -- move SKIP and Photuris and Oakley to experimental for a while and regroup after we have more field experience that would give us a better idea of what we really want. Perry
- Status of IPSEC Key Management Jeffrey I. Schiller
- Re: Status of IPSEC Key Management Stephen Kent
- Re: Status of IPSEC Key Management Robert Moskowitz
- Re: Status of IPSEC Key Management Rich Skrenta
- Re: Status of IPSEC Key Management Rich Skrenta
- Re: Status of IPSEC Key Management Rich Skrenta
- Re: Status of IPSEC Key Management Stephen Kent
- Re: Status of IPSEC Key Management C. Harald Koch
- Re: Status of IPSEC Key Management Stephen Kent
- Re: Status of IPSEC Key Management Stuart Jacobs
- Re: Status of IPSEC Key Management Germano Caronni
- Re: Status of IPSEC Key Management Germano Caronni
- Re: Status of IPSEC Key Management Stephen Kent
- Re: Status of IPSEC Key Management Stephen Kent
- Re: Status of IPSEC Key Management Dave Johnson