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

Re: Status of IPSEC Key Management

Perry,

        You're right that if one chose to employ long duration SAs, then
similar functionality can be had via other key management protocols.
However, in general, I think that the booking associated with maintaing an
SA is not justified when the keying material is used just once for a brief
exchange.  This is not a criticism of any specific key management approach,
but just an opinion about when it makes sense to create a new SA vs.
maintaining and old one.  In some instances establishing a very long lived
SA is atractive, with key updates on some trigger basis, but other times
the flexibility of creating a new key for a transaction is preferable,
because there really is no association per se.  Niether is the "right'
model in all cases, but rather some times each is preferable.

        Note that mny message was not intended as an endorsement of SKIP.
Neither of the examples I gave of work we were doing used SKIP exactly.
Instead, we used the underlying concept of SKIP in a particular context,
without making use of the SKIP header.  So, my point in sending the message
was to raise an isse in terms of what functionality the WG believes it
needs in a key management porotocol for IPSEC.  One possible answer is that
the sort of examples I cited are viewed as not within scope for this WG and
thus they do not motivate inclusion of a SKIP-like capability in the key
management protocol for IPSEC.

Steve



To: perry@piermont.com
Cc: Stephen Kent <kent@bbn.com>, ipsec@TIS.COM
Subject: Re: Status of IPSEC Key Management 
Date: Mon, 09 Sep 1996 15:46:47 -0400
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID:  <9609091546.aa15541@neptune.TIS.COM>

	 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.

We can't do that.  There are too many implementations of IPSEC out
there that can't quite interoperate, because they don't share common
key management.  If we delay, something will fill the vacuum -- and it
may not be something we like.  For example, it may be proprietary, lack
PFS, and be insecure.

My own preference is for ISAKMP/Oakley.  But I agree that SKIP has
attributes that make it preferable for some applications.  As a rough
rule of thumb, SKIP works best in applications that are best-suited
to UDP:  many-to-one or many-to-many applications (i.e., network management
and multicast protocols), or casual query/response without prior setup
(such as DNS).

With the exception of DNS queries -- and it isn't clear if they even need
IPSEC, given that they'll have DNSSEC (and yes, I know about traffic
analysis) -- I suspect that other uses are among comparatively limited
communities of interest, and with some prearrangement.  I suggest, therefore,
that on the order of 16-32 SPIs be used for SKIP, half with standard
D-H exponents and moduli, and half with locally-configured values.  The
routing tables (or some other static, local table) would define when these
SPIs should be used (or accepted).

Another way to phrase it is that I like SKIP as a transform, but not as
a general key management protocol.  As a future work item, we might want
to consider a protocol to negotiate SKIP communities, possibly within the
ISAKMP framework.