Advogato: Blog for nchriss

29 Nov 2001 nchriss » (Journeyer)

Complexities of Multicast IPSec Key Management

The following are notes applicable to the issue of multicast IPSec key management.

IKE authenticates two peers via authenticated DH exchange. It is possible to extend a basic Diffie-Hellman exchange to more than two members, but it is computationally costly.

addition or deletion of a single member requires a similiar n-way exchange (where n is the # of group participants)

join latency (time required to join the IPSec group and begin sharing secure traffic), rekeying (retiring old keys and distributing fresh keys), forced member removal (exclusion/revoking of IPSec group participation) are all affected by the same complexity issues.

Approaches to Multicast Key Management Protocols

Shared Secret

Shared Secret: a shared secret is established between each group member and the key holder.

secret is used as a key encrypting key (KEK), which is then used to distribute the shared group key to individual members.

each member retains knowledge of the shared secret with the key distributor, but the key distributor must retain knowledge of all keys it shares with the group members.

limitations: as the number of members in the group rises, the key distribution mechanics scale poorly

key acquisition latency is too high in large groups.

revoking/rekeying latency also remains high in the event that a member needs to be forcibly removed.

The addition of a Complimentary Variable to the shared key:

A list of variables is sent to each group member, encrypted with the KEK.

Each member is assigned a cv and is given the cv of every other member in the group.

for a group of n members, there will be n complimentary variables and each member j recieves all variables i where i=1,2..,n, but i != j.

IOW, each member knows the complimentary variable of every other member but does not know his own.

For forcibly removing a member b, the group owner issues a message to all group members specifying the generation of a new key using the existing key and the complimentary variable for member b (possibly by hashing the two together). Being that member b does not have his own complimentary variable, he is unable to recompute the new key and is effectively out of the group.

limitations of cv: each time a new member joins the group, the members new complimentary variable needs to be redistributed to established group members. Also, for large groups, storing complimentary variables for every other member becomes cumbersome.

Hierarchical Tree

In this technique, there is no single key, there are many.

Keys are maintained by the group owner by constructing and maintaining a hierarchical tree.

At the root of the tree is the main group key.

Each member is a leaf on the tree and is given the set of keys from the root, through all intermediate nodes, to the leaf that represents itself.

To construct this tree the keyserver (who is not necessarily the root of the tree but possibly an intermediary) establishes a shared secret (a KEK) with each leaf node, each user.

The root key and the keys of the leaf's parent nodes are transmitted to it encrypted with the KEK.

Addition of a new member requires only establishing of a KEK and then a single message containing all the keys of its parent nodes encrypted in that KEK.

Rekeying is less labor intensive and impacts a smaller group of members.

For a group of n members, the group owner must do 2 * log n key encryptions to rekey the group.
For a tree of depth d, each user must store d + 1 keys while the group owner must keep all keys.

..next post, Multicast Key Distribution with CBT and/or MKMP

Latest blog entries Older blog entries