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

Re: manual keying and IPSEC conformance



Hi,

I'm (potentially at least :-) a customer of Derrell's.  I do want to continue 
to mandate that manual key management continue to be must-implement for conformance 
to the specifications.  We use manual key distribution in some environments.  There
exist some real world Internet environments where manual key distribution is really
the best overall operational approach.  

I confess that I really liked that the comment from someone else about the architecture 
being designed to quite clearly decouple:

		Security Policy
		Key Management
		Algorithms
		
Fundamentally, manual key distribution (e.g. via a Marine or other armed courier :-) 
is probably the only _really_ secure KM game in town.  Its also the only thing that
works today for multicast traffic [1].  Its the only known way to provide for secure 
bootstrapping of IPv6 nodes [2].   

It isn't hard to implement manual key distribution even if not all the customers
want to actually use it.  Those customers who don't want to use it, don't have to.

That all said, I think it would be A Very Fine thing if ISAKMP/Oakley were also
MUST implement for IPv4 IPsec systems.   Having the option of using automated
key management cannot be anything but goodness.  Widespread availability of a
common key management protocol is also clearly a win.  The market is clearly
moving towards ISAKMP/Oakley (e.g. vendors at Interop in LV in May 1997) anyway.

Now ISAKMP/Oakley _does_ require that the end parties be authenticated using some
form of signed public key (perhaps from Secure DNS or X.509 certs).  The past
history of the IETF and the Internet is that certificate heirarchies are operationally
hard to setup, maintain, and use.  One of the reasons that PEM is not widely
deployed today for encrypted email is that PEM relied on the availability of
a (not yet existing) public key certificate heirarchy.   DNSSEC is not yet widely
available in running code (the stuff currently in BIND doesn't verify any of
the signatures, so it isn't secure in current form).  The DNSSEC WG is considering
changes to the DNSSEC packet format, which might delay DNSSEC further.
In the X.509 arena there are MANY folks in the CA business competing with 
each other, but cross-certification is not yet an element of the real world.
What if I want to talk with user FOO, but I use CA==X, FOO uses CA==Y 
where (Y!=X) and (X,Y don't cross certify each other) -- result, no secure packets.

I don't want IPsec to become dependent on something that in turn depends on the 
availabilty of any amount of PK infrastructure.  I think a PK infrastructure 
would be A Very Fine Thing; I just don't want IPsec deployment to depend upon it.

Ran
rja@inet.org

[1] Some form of scalable multicast key distribution might well be standardised
    eventually, but it isn't close to being ready today.
[2] An important reason that IPv6 junked ARP and went with Neighbor Discovery
    was that AH+manual keying provided a mechanism for fully authenticated bootstrap
    of an IPv6 network (with all its nodes).  No form of automated keying can provide
    this because automated key management doesn't work until the network is up
    ("automated" in the sense of travelling via some IP packet :-).


References: