[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of IPSEC Key Management


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