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

Re: Modular approach to key management




Dear IPSECers,

I believe that the very reasonable arguments below by Aziz, and the very
reasonable counter-arguments, make one thing clear: we should go with a
modular approach that provides a common protocol for key refreshment,
where the key could be obtained by a variety of mechanisms (and later
we'll standardize some specific choices). The main gains are interoperability,
efficiency, but over all: time to market.

I suggest that the group decides to do such a modular design. In particular
I suggest that to take the Modular Key Management proposal (now available
as Internet-draft) and work on it together to offer the Internet QUICKLY a
really useful tool for interoperable IP-layer security solutions.

Please voice your opinions on the list, and let's also discuss this in the
IETF.

Best, Amir Herzberg

>
> >From ipsec-request@ans.net Mon Nov 21 15:33:39 1994
> >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.
>
> I am afraid that I, for one, am not amenable to adopting IEEE 802.10c
> as something suitable for use with IPSP, for a number of reasons which I'll
> describe below.
>
> (This is based on the IEEE 802.10c draft that was available sometime
> before the last IETF meeting so if things have substantially changed
> since then, I am not aware of that.)
>
> o IEEE 802.10c is quite a complex document. In my view, unnecessarily so.
> If this groups decides to adopt it, it needs to be much clearer and
> easier to understand than it currently is.
>
> o IEEE 802.10c utilizes OSI upper layer services and concepts like
> Application Entity Titles etc. I dont think that the Internet community
> needs to buy into (and implement) the OSI upper layer services, with
> its associated complexities, just for the sake of IP layer key-management.
> Especially since much simpler alternatives already exist.
>
> o IEEE 802.10c multicast design uses a single key obtained from a
> Multicast KDC. Changing this key requires obtaining a new key from
> the Multicast KDC. This may work for small multicast groups as may
> arise on a single 802.x subnet (which is what 802.10 is intended for)
> but this will not scale to the number of nodes possible in an
> Internet wide multicast group.
>
> o Using the same key for all members of a multicast group eliminates
> using some of the highest performance stream ciphers commercially available
> for traffic encryption purposes. This is a major disadvantage for
> high-performance multicast applications like encrypted video.
>
> o The fact that IEEE 802.10 was designed for subnets (and not internets,
> for which scalability to a large number of nodes is criticial) shows in places
> like how to determine which application entity to use in order to
> negotiate session keys. In one of the appendices, it states that each
> node will have a local table of mappings between 802.x MAC addresses and
> AE-Titles. This might work for a single subnet. This will clearly not work
> for the Internet, where it is not feasible to have a local table of
> mappings between IP addresses and AE-Titles for the entire Internet.
>
> >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.
>
> I think that IEEE 802.10c is the wrong solution for the Internet.
> It will substantially increase time to market because of the complexities
> inherent a complete OSI upper layer implementation (truly unnecessary for
> the task at hand). It also does not adequately address the needs of the
> Internet, because of various subnet oriented design decisions.
>
> Regards,
> Ashar.
>