[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modular approach to key management
Amir:
> I agree that it would be much better if we had automated negotiation
> of methods i.e. a standard high-level key management alg. The questions are:
> 1. Should we do a small common module already, without waiting to resolve
> the higher layer problem? We believe the answer is YES.
> 2. How do we solve the higher layer problem? I think there are too many
> possibilities rather than too few... You seem to suggest a specific one:
>
> > In the IEEE 802.10c Key Management Protocol, all three forms of key
> > management are supported: KDC, certificate-based, and manual. Each of
> > these techniques can be used to establish a traffic encryption key, then a
> > common attribute negotiation technique is used. I think that IPSEC can
> > adopt all of this work with minimal adaptation to the Internet. By starting
> > with IEEE 802.10c, the "upper module" is nearly complete.
>
> We (in particular Juan) tried to learn and re-use IEEE 802.10c as much as we
> could. (Juan, you may want to elaborate.) Maybe you (and others) can help the
> WG to use more of it - that would be great.
I think that we agree more than we disagree. IEEE 802.10c defines a protocol
that can be used with certificate-based key management, KDC-based key
management, and manual key management. Since the protocol is so flexible, the
IPSEC WG would be faced with choosing one (or more) technique that would be
standardized for the Internet community of users. For example, Kerberos might
be the basis for a KDC-based key management technique for the Internet.
Likewise, the PEM certificate infrastructure might be the basis for a
certificate-based key management technique for the Internet. Another
certificate-based alternative might be based on the draft X9.42 variant of
Diffie-Hellman.
My suggestion is that we adopt the IEEE work, then select particular algorithms
for use in the Internet. Of course, the IPSEC WG would also have to define the
attributes that are part of security association negotiation. These attributes
have to be defined regardless of the approach taken, so this is neither a plus
nor a minus to the IEEE 802.10c approach.
NASA has agreed to make some space available on a machine that supports
anonymous FTP. We hope to have the latest draft of IEEE 802.10c available
before the IETF meeting. I will gladly spend time with anyone at the IETF to
expalin the direction that we are going. Good ideas are welcome from any
source.
> ... Even if used with manual key management by some pairs of partners, it
> would still help to 'stop the bleeding' - and this is what we were told to
> do by the IESG.
In my opinion, IEEE 802.10c decreases the time to market. Protocol development
can take alot of time, especially in an open environment like the IEEE and
the IETF. Therefore, take advantage of the investement that has already
been made by the IEEE 802.10 participants, and take a working solution to
the Internet sooner.
Russ
Follow-Ups: