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

Re: Status of IPSEC Key Management



In article <199609102225.PAA15843@monster.incog.com> you write:
> > [ Dan Harkins writes ]
> >
> > That's not necessarily true. The general SKIP case requires: 1) Certificate
> > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two 
> > messages; and, if PFS is desired, 3) the PFS extension, two more messages. 
> > A total of 6 messages required-- 4 if PFS is not desired. 
> 
> Not true.  SKIP requires that communicating parties have each other's
> certificates (keys).  SKIP does not specify how this happens.  We 
> tried to solve this key distribution problem by creating another protocol
> which is not specific to SKIP.  People naively assume this is a SKIP
> exchange.  Base SKIP allows you to talk without any exchanges if you
> have a way to distribute keys and algorithm information.   This could
> be done via hardware tokens, CDP, floppies, Directory Servers, Secure
> DNS or whatever.  It is important to understand that once you have this
> certificate, you do not need to get it again.  Algorithm information can
> be handled in the same way. 

  You forgot SneakerNet :-). But seriously, floppies, hardware tokens,
pre-configuration, and SneakerNet don't scale too well. And, I don't think
Secure DNS is well suited for algorithm discovery.

  Granted, base SKIP does not require round-trips because it assumes you
have some shared information already. But the general case, where we've
never exchanged floppies or phone calls, does. My point was that to get
to the point where base SKIP works without round-trips requires some
round-trips.

> > The multicast extension also doesn't scale well to highly dynamic multicast
> > groups (unicast request/response for every member to group owner to obtain 
> > GIK).
> 
> Ashar described a scheme in Montreal in which GIKs are distributed by
> an expanding ring multicast scheme.  I believe this solves this problem.

That would be great! I hope to see this as an Internet-Draft soon since I 
don't remember the specifics of how this scheme works.

> > > One way to do this would be to include fields saying "respond to this
> > > on SPI <NNN> until <expiration>" in the in-band-keying header; once an
> > > explicit SPI had been set up between peers, the in-band header would
> > > not be used.
> 
> So would a message be sent back acknowleging this key change?  What would
> you do if the key change packet was dropped?  SKIP sends the key in each
> packet to avoid the problem with lost and out of order packets (one of
> the original goals of IP).  This would also preclude the one-way 
> Satellite environment I described above.

This is for negotiation-less SA establishment. You create an inbound SA with 
SPI NNN and send me the aforementioned packet. I create a similar outbound 
one upon receipt. No ack necessary since this just describes how I will be 
communicating with you in the future. If the packet was dropped you would,
presumably, send another until your inbound SA went active (meaning I actually
sent you something with SPI NNN) or the application requesting security 
timed out. This is to establish a single unidirectional SA. You could, I guess, 
continue to send me vanilla SKIP but I would reply with standard IPsec, 
Practically, though, I would imagine me setting up an inbound SA with SPI JJJ,
sending you that packet, etc.

  You're right, this wouldn't work in the Satellite environment you described
(since it implies that I don't respond to you and this whole idea is predicated
on just the opposite) but it is still an interesting idea. It requires just 
as many roundtrips as SKIP-- the general case-- but loses the in-band header 
after SA establishment.

  Dan.