[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modular approach to key management
Ashar:
I will be making a presentation at the Key Management IPSEC sesion at the
IETF. I will try to address each of your concerns in that presentation.
Thanks for the detailed list of me to focus on.
Russ
______________________________ Reply Separator _________________________________
Subject: Re: Modular approach to key management
Author: Ashar.Aziz@Eng.Sun.COM (Ashar Aziz)
Date: 11/29/94 5:43 PM
>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.