Approaches to Multicast Key Management Protocols

Shared Secret

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.

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:

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

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.

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.

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

unless certificates are renewed they become useless.

by changing the policy file, we can prevent nodes from accepting connections from blacklisted nodes

Issues/Concerns

The major issues with the above plan were:

join latency

rekeying

subnet addressing guidelines

communication with multiple nodes

research users

route distribution

Key Management

Join Latency: This wouldn't be an issue, as it turns out, because there's not underlying fabric to join. When discussing groups of IPSec communicators, I immediately began reasoning along the lines of a 'fabric-oriented' approach, which starts sounding much more like multicast- IPsec than what's really necessary for our requirements. This is not to say we can't tie all nodes together in a multi-cast-like setting, but I would say that's for a future implementation. The complication of source authentication and key management make a potential solution difficult, although I have provided possible solutions below. We may want to start a project on multicast IPSec. This particular point is only important when considering a more seamless level of resource sharing.

In the above proposed scenario, keys can be distributed and updated using a simple automated method such as CVS. Certificates need to be kept for both independent researchers and nodes so as to allow the same. As the scale of the network increases, we can develop something more automated, which is described below.

IP Addressing

This should also be a non-issue. We should provide guidelines that administrators stick to 10.0.*/24 and even hand out address spaces, but largely IPSec communication between two or more IPSec nodes can go ungoverned. To keep life sane for everyone, we should make sure to specify what subnets.. the CA only authenticates nodes.

Communication with multiple nodes: Communication between from Node A and Node B to Node C may saturate node C's link. This is partially a disadvantage to the IPSec mesh, as over a hub-spoke arrangement, only one tunnel is necessary to carry multiple sessions between endpoints. It can be recommended that nodes employ the use of bandwidth shaping/rate limiting to prevent this from becoming a problem on popular nodes.

Research Users: The above may be further exasperated when considering that researchers are logically, their own nodes (albeit, single machine nodes). Multiple researches hitting one node may be undesirable for the same reason. This actually brings up additionaly issues about the quality of research which I'll bring up at some other time.

Route Distribution: This was also another issue that cropped up when thinking about the mesh in a 'fabric-oriented' way. This also becomes a non-issue as nodes are subject to their own routing impedence and there's no need to know private address routes.. as they don't exist in the proposed scenario. We can move towards route sharing in the future, but I see IPsec multicast as possibly being the best way to send non-contiguous, non-canonical route updates.

Multicast IPSec - Brief Treatment to be expanded at a later time

These are just notes.

Multicast Ipsec

in a normal scenario, the destination chooses the SPI.

in multicast, there is not single destination for a given address.

Source Authentication Solutions

Gennarro and Rohatgi describe a system where a single public-key (asymmetric) signature and a symetrically-keyed hash can be used to effectively authenticate the source of a packet based on the fact that a sender knows what the next packet it is going to send will be.

The digest of the first packet, which is a keyed hash of the second packet, can be checked when the secon packet is recieved.

The second packet then holds a digest for the keyed hash in the third packet.

When the keyed hash of the second packet holding the digest for the third packet can verify the signature sent in the first packet, the sender of the first packet can be absolutely identified and so on up to packet #n.

Alternate Technique:

G. Itkis describes a technique using the authentication employed in AH, but adapted to use additional digests such that:

for any particular sender of a group, there are 'n' keys.

Each member of the group/recipient of multicast traffic is granted k of the n keys, where k < n

Each packet is sent with n digests of a keyed hash appended for each of the n keys.

The recipients validate the digests based on how they correspond to the keys that s/he holds.

if the recepients digests are correct, the reciever must assume that the rest of the digests are correct as well.

one member could forge packets to members in the rest of the group, but if we have a suitably large 'n' and a relatively small 'k' the number of members that share the same keys will be small.

This idea has limitations, but has been incorporated into [2]

- can't finish this post at the moment, next post will correlate to CBT - RFC1949 using GKDCs and cores and MKMP using GKMs and GKDs ... enough acros y'think?

[1] "Digital Signatures for Flows and Multicasts" - Chung Kei Wong and Simon Lam

[2] "Multicast Security: A Taxonomy of Secure Multicast Protocols and Effecient Authentication Schemes" - Cannetti, Garay, Itkis, Micciancio, Naor and Pinkas