securemult

Building Secured and Scalable Multicast Group
Communication
By Sunil Srivastava
11/18/98

1. Synopsis
The paper describes an unique way of building a group communication using a secured
and distributed Multicast KDC (MKDC and not Kerberos KDC). It uses a distributed
and near-statically replicated directory containing User Account or Security Principal
Information for Authenticating Users or Services and their associated mutual Shared
Secret between individual members in a Multicast Group and the Directory (or Private
and Public keys for that matter). Users authenticate themselves using Directory’s
Security, which in turn use Kerberos KDC. Some directories can also act as a Certificate
Authority or work with Certificate Authorities.
The distributed MKDCs themselves form a secured group communication to replicate
and exchange replicated dynamic Group Sesssion Keys used by Publishers and
Subscribers Applications. The secured channel is built based on using an efficient
algorithm, much like the standard Broadcast version of Diffie-Hellman, but that uses
fewer overheads of message exchanges. Later other mechanisms are also covered to
scale distributed MKDCs. The dynamic Group Session Keys can be derived by various
methods, including efficient and scalable algorithms like Binary-Tree-Algorithm and a
derivative of it that is Network or Node Id based.
For a Group with no Group Controller, we can use Broadcast version of Deffie-Hellman
and that has N(N-1) overhead of messages. The two algorithms proposed by me take 4N-
6 rounds of messages. Two algorithms, both having same operational steps and
overhead of exchanging messages is demonstrated, but having different mathematical
formulas. One matches with the mathematical formula of the Broadcast version of Diffie-
Hellman, and the other is different and more complex. We can also use Burmeister-
Desmedt algorithm and it takes 2N rounds of Broadcast messages. For joins and leaves,
the overhead remains the same in all of these algorithms.
For a Group with a Group Controller, we can use standard version of Deffie-Hellman
and it takes N-1 rounds of point-to-point messages to communicate a dynamic Group
Session Key.
There is a Binary-Tree-Algorithm, where a Group Controller can update keys and the
overhead is still N-1 messages. But for joins and leaves, one can do just a broadcast
message containing 2log2N + 1 Keys to take care of joins and leaves. Each member has
log2N keys to store, out of which one key is unique and private to a member, and log2N
decryption computations to do. Each member is a leaf node.
We can expand the Binary-Tree-Algorithm if keys corresponding to its nodes can be
replaced by keys corresponding to bit values of a network address or id of members,
where each bit mandates 2 keys. So for an address space of 2^W, we will need W keys for
each node, and the Group Controller has 2W +1 keys. When a new node joins, the
Group Controller sends W keys to the new node over a secured channel, and only W-1
keys would be overlapping with other nodes. The overlapping keys with affected nodes
get their keys changed for every addition or deletion to a group.

Another version of the same algorithm gets rid of the Group Controller and uses an
expanding ring protocol, similar to Beacon Protocol proposed in the paper.
The paper shows optimizations made in reducing the overhead of exchanging messages
for tracking group memberships. Group Membership Tracking Protocol is used to track
member MKDCs joining and leaving, each of which triggering a round of message
exchange and computations, which are expensive when coming to a shared secret key
among MKDCs. This is to support dynamic MKDC Group Membership. One can also
rely on a static Group Membership and use Directory replication to show a static group
made of distributed MKDCs.
It goes on further to demonstrate building an Expanding Ring Beacon Protocol,
exploiting the Multicast TTL, and by increasing from 1 to N, how local groups can first
join the group. Similar groups will be running the same algorithm and eventually such
groups will run a Group Merge Protocol to create a larger group.
By having an efficient algorithm and having many parallel groups consisting of MKDCs
running the algorithm, and later merging such individual groups, it is shown how the
proposed method always scales.
Later it shows that how MKDCs can scale up by joining another group of MKDCs using
hierarchical relationship with other MKDC groups using overlapping Multicast groups.
These MKDCs will be placed strategically on the trees in a forest to help scaling.
The proposed method employed by MKDC nodes to build a secured channel could also
be used by other Multicast based Applications, including Publish and Subscribe. Since
there is a computational and message overhead, and if members go up and down, this
will lead to a system that is always in flux. Hence the service of distributed MKDCs is
employed that are assumed to be relatively more stable and do not experience transitory
ups and downs as compared to some of the other Multicast Applications.
If the Multicast Application nodes are going to be relatively stable, then they can
themselves build the secured channel without needing a distributed MKDC. But they will
still need a service of a CA or distributed Directory to give point-to-point Secured
Communication and Authentication. Please note that we can not rid ourselves of
Directory being used as a Certificate Server or a Trusted Third Party Security Authority
that identifies individual nodes in a group to other nodes.
Practically speaking distributing MKDCs at global level does not make sense, since WAN
level multicasting is not there and problems arising from network partitions and
administrative scope of MKDC replication. We can replicate MKDCs at domain levels,
and have Subscribers go to a Publisher specificMKDC. We can also use a load
balancing technology like Local Director to have a single point of contact for MKDC for
a domain (the idea came from me when I was at Pointcast and was brought to CISCO by
my VP, Joe Pistritto and we had to solve the problem of load balancing 60% of Internet
traffic in 1995) . Or we can use the multiple service entries in n DNS, as used by Domain
Controllers in Directory Services to load balancing among MKDCs.

Every scheme has different pros and cons, and come with certain advantages and
disadvantages in terms of overheads. Building a secure channel for distributed Multicast
KDC, after individual Multicast KDCs (MKDC) are authenticated by Directory,
mandates less stringent requirements, then building a secured channel for a Multicast
Group in general.
We can use an algorithm that mandates a Group Controller approach to provide a
Security solution to Multicast Groups - but we distribute Group Controller by building a
secured distributed channel using algorithms that do not need a Group Controller
approach. The distributed Group Controllers are actually the distributed Multicast
KDCs, using a secured channel, to replicate and distribute dynamic session keys! So a
Group Controller keeps other Group Controllers informed about group membership joins
and leaves and also shares keys. The requirements to provide a secured channel among
distributed Multicast KDCs or Group Controllers are less stringent as they are more
static in membership joins and leaves as well as they can be mutually trust each other.
This leads to having less forward looking and backward looking secrecy requirements
and scaling requirements among distributed Multicast KDCs or Groups Controllers. We
can place the distribution of KDCs at sub-net level, domain level, tree level, and forest
levels, which are interconnected as peers at one level and as parent-child layers in a
hierarchical relationship between sub-net level, domain level, tree level and forest levels.
When a publisher registers with its local MKDC, it specifies its multicast range in terms
of TTLs that can be mapped to a range of levels of MKDCs involved in a hierarchical
relationship, and it will be used to replicate the dynamic session keys. This is an ultimate
push model. On pull model, we can have Subscribers come to Publisher specific KDCs.
This paper assumes that one has a fundamental knowledge of concepts related to
security, multicast and directory services.
1.0 Introduction
Everything in Universe is distributed,
All at certain level are part of some central entity.
- SKS
What is a Circular Problem to most,
Innovators see a Bootstrap Spiral.
- SKS
Building a Scalable and Secured Group Communication has been a challenge so far.
Coming to a shared secret among participants can be done in two ways. (1) By using
a central Key Distribution Center (KDC) and (2) by using a mathematical algorithm
like the broadcast version of Diffie-Hellman, or some other algorithm, to take
advantage of coming to a shared secret key for group members of a group.
The second option still needs a service of a central authority like a Trusted Security
Authority or Certificate Authority to authenticate individual group members to peer

group members. The central authority is a logical point of contact for Authentication
and Validation Services when individual nodes join a group and present their
credentials to other group members. This logical point can be distributed at LAN and
WAN level and itself have some kind of peering and hierarchical relationship.
Multicast Security has following attributes that need to be understood before we go
on:
Attribute Explanation
Group key to
achieve privacy and/or
authenticity
The Group Key needs to be dynamic and
Session oriented, where session begins with a
Group being formed anytime. The key needs
have temporal and spatial randomness in
Distances between key versions and revisions.
Perfect forward secrecy If a member node leaves, it should not be able
decrypt group communications in future
Perfect backward secrecy If a member node joins, it should not be able
decrypt group communications from past
Dynamic Membership There is an overhead of supporting dynamic
group membership
Trust in Third Parties
Required for Group
Authentication
Sometimes having a shared secret is sufficient
to implicitly authenticate that a node is a valid
Member of a group. Sometimes having a trust
in a third party is necessary when an algorithm i
is susceptible to the Man-in-the-Middle attack
Required for Individual
Authentication
Group Members can fake as other Group
Members, and use the shared secret to forge
Messages sent by one another.
Designed for one
central controlling entity
Most of algorithms assume the concept of a
controlling entity that members talk to come to
a shared group secret but this poses a Single
Point-of-failure and may not scale. By making
a Sender the controlling entity for a group will
distribute the failure points but this still may
not scale for a large group. Plus it assumes a
sender to be a powerful machine.
Controlling entity must
know all participants
Group Membership is well tracked when it is
Centralized and some algorithms need the
Controlling entity to know about all members.
This is also necessary when we need Forward
and Backward looking security
Multiple leaves When multiple nodes leave a group at once
Exclusion of colluding
participants
Some algorithms build security on distributed
but partially overlapping set of keys, and it
can be breached if these nodes collude
Joining and separation
of groups
When Groups merge and separate due to
Network partitions and healing
Setup implosion is an
issue
When members join a group and set-up a
Shared secret either using a central entity or

a peer-to-peer protocol, the message traffic
volume generated may cause implosion
Load Balancing Devices can be used in case of
central entities. For peer-to-peer approaches,
expanding ring protocols, by controlling
multicast TTL can be used. And later Groups
can be merged.
Return channel required
during operation
Some protocols need heartbeat or membership
protocol, along with some key sharing
messages either with central entity or peering
nodes.
Assigned IDs or
Network IDs
Network IDs can be used in protocols to track
Membership or IDs can be assigned. Assigned
IDs can be hashed Network IDs.
Single point of failure A single point of failure of can make
an algorithm or an operation fail.
Easily recoverable When network partitions or merges, member
Nodes come and go, an algorithm or an operatio
functional.
Small database Some algorithms need to hold large amount of
information and sometime pass large amount
of information.
Involvement of multiple
parties for leave/join
Sometimes, many nodes distribute the function
Of tracking group memberships.
2.0 Using KDC
The KDC using a point to point communication authenticates individual members
of group. They get dynamic session keys for further point to point
communications. An individual node that starts a group communication can
create a dynamic Group key based on symmetrical cryptographic algorithms and
give it to KDC, or it can request KDC to generate one for a group communication.
Other nodes that want to join the group, Request KDC to disburse a dynamic
Group Session Key using secured point to point communications. When a
Publisher wants to publish a message, it uses a dynamic Group Session Key to
encrypt a message and sign a message digest, appended with time-stamp and
serial numbers with its private key. Subscribers for the Group can identify a
Publisher of a message and request KDC for its public key and the associated and
dynamic Group Session Key. If they trusted a Publisher, then it can itself act as a
KDC.
We assume that a Publisher of a Group controls the Group Session Key. For a
Group where each node can be a Publisher as well as Subscriber, each member
can use a different Group Session Key when they have to send messages. The
individual Group Session Keys controlled by individual nodes acting as

Publishers can also act as an authentication signature/certificate of a particular
node. But since they already have established private keys with a Certificate
Authority or a Kerberos KDC that they can use for this purpose, there is no reason
we need this. We need the services of a CA or Kerberos KDC to establish the
identity of group members. So as an optimization, individual Publishing nodes
can also use the Publisher controller Group Session key. This is a special case. A
Publisher uses its local Multicast KDC to set a Group Session Key and that Group
Session key could also be used by other Publishing node members. Hence the
notion of a Group Controller or Initiator comes and this case the first publishing
node that creates or joins a group is going to decide which Publishing node’s
Multicast KDC will be used for being a Group Controller.
2.1 Problem Using Central KDC
The approach of using a central KDC does not scale so well. The KDC will
appear to be one System. Normally it is a trusted third party and communication
with it is secured and encrypted. It has access to user identity and their associated
passwords. It grants tickets encrypted in a key derived from passwords or session
keys issued in a Ticket for a Server. The KDC can only scale if the System can
scale but is not distributed and has a single point of failure. Scaling of KDC can
be done using Clusters or shared disk based systems using CISCO’s Local
Director.
2.1 The Solution: Distributed KDC
The other way to scale is to distribute KDCs over LAN and WAN and they using
a secured channel among themselves to communicate and exchange dynamic
Group Session Keys. But the challenge is how to build a secured channel among
KDC nodes, which in turn may be using a reliable multicast protocol to exchange
dynamic Group Keys. Hence it is a chicken and egg problem. To solve the
chicken and egg problem, we need to build a secured channel using an unsecured
channel! (Secured unicast methods can be used but they do not scale and will add
latency as messages get encrypted and decrypted at each hop along the way to its
destination.)
The other way to look at the chicken and egg problem is that it is a circular
problem from one perspective but a cylindrical spiral (spring-like figure) from
another perspective. Since different algorithms have different characteristics, and
the needs for secured and distributed KDC nodes is different from Multicast
Group members, we can use different algorithms to bootstrap a solution.
3.0 Algorithms

3.1 Standard Version of Diffie-Hellman
In the Diffie-Hellman protocol, Alice and Bob each arrive at the same shared
secret through different computations.
The computation use an one-way function using two prime numbers, p and q that
are public or implicitly agreed values.
Although these equations are easy to compute, the reverse computations (solving
for x and y) are very difficult. The security of the Diffie-Hellman protocol
depends upon the difficulty of the reverse computations.
Alice chooses a private value a, and a one-way function to compute a public
value A (the constants p and q):
A = p a
* mod (q)
Similarly Bob chooses a secret value b, and uses this equation to compute a
public value B:
B = p b
* mod (q)
Alice and Bob then share their public values with each other. Alice computes the
shared secret, k, using this equation:
k = B a
* mod (q) = p ab
* mod (q)
Bob computes the same shared secret, k, using this equation:
k = A b
* mod (q) = p ab
* mod (q)
Both values for k are identical, because of this equality:
The public values, A and B, are useless without the opposite private values, a
and b. Only Alice and Bob can compute the shared secret, k, because only they
have the required private information.
The shared secret, k, is unique to Alice and Bob as a pair. Alice and Carol cannot
derive the same k that Alice and Bob derive. Nor can Mallory derive the same k.
Once Alice and Bob both have the shared secret, k, they both use k to derive a
secret symmetric key for encrypting key channel messages. They both encrypt all
subsequent key channel messages with that key.

For a group of N nodes, with one node acting as a Group Controller, a shared
secret can be calculated in N-1 messages. The shared secret derived from
Deffie-Hellman will be different for communication between a Group controller
node and each remaining node. The dynamic group shared secret will be derived
from some other means. This is like a central KDC approach.
3.2 The Broadcast Version of Diffie-Hellman
Alice, Bob, and Carol together generate a secret key.
(1). Alice’s public value is
A = p a
* mod (q)
(2) Bob’s public value is
B = p b
* mod (q)
(3) Carol’s public value is
C = p c
* mod (q)
(4) Alice sends Bob
C’ = C a
* mod (q)
(5) Bob sends Carol
A’ = A b
* mod (q)
(6) Carol send Alice
B’ = B c
* mod (q)
(7) Alice computes
k = B’ a
* mod (q) = p abc
* mod (q)
(8) Bob computes
k = C’ b
* mod (p) = p abc
* mod (q)
(9) Carol computes
k = A’ c
* mod (p) = p abc
* mod (q)

This method needs N * (N –1) round of messages, where N is the number of
nodes in the group. For larger group this method does not scale up.
In this method one assumes, that all nodes are peers and there is no group
controller.
If we assume that the initiator of a group is a group controller and also a KDC,
we can use the standard point-to-point Deffie-Hellman and get a shared secret
using N-1 round of messages! The shared secret is orthogonal to the individual
shared session keys between an initiator of a group and individual group
members.
3.3 My Broadcast Version 1 of Diffie-Hellman
(1) Alice and Bob, both have come to their shared secret key:
k = pab
* mod (q)
(2) Once Alice and Bob have a secret key, they can exchange their private numbers.
Please note that the there may be a permanent private key that is used to sign a
message, and another private number that is randomly generated to come to a
common shared key.
The public number AB (not the product of A and B) is sent to Carol can be:
AB = p ab
* mod (q)
Only one of them sends this message. The last member in the group can take this
responsibility.
At the time of joining, the new member only know that it is talking to one entity,
which may be a group having many members or just one node.
(2) Carol broadcasts her public value:
C = p c
* mod (q)
(3) Alice and Bob, independently compute the shared secret as
k = C ab
* mod (q) = p abc
* mod (q)
Alice and Bob, both know each others private numbers, a and b that were randomly
generated (and not their individual private key that always remains the same and used
to sign their messages).
(4) Carol calculates the shared secret as

k = (AB) c
* mod (q) = p abc
* mod (q)
This methods needs 2(n) + 2(n-1) round of messages, where n is the round of iteration of
exchanging messages between two entities, where the entities may be groups having
members or member themselves. Since 2 node make the first round, and 3 nodes make a
second round, we can say 2(N-1) + 2(N-1-1) = 4N – 6 messages, where N is number of
nodes.
The side effect is that each new node takes 4 extra round of messages. Introduction to a
group can be controlled through an expanding ring algorithm. Members leaving can
trigger a fresh execution of the algorithm from ground zero, which is not very scalable.
All private and public values have to recomputed since a leaving node knows all about
the current members public and private values. If one of the remaining members act ac a
coordinator, then a new set of public and private values can be calculated and a new
group key can be calculated in N-1 messages.
The purpose of this approach was that though the algorithm is different in operational
steps, but is the same mathematically as the Broadcast version of the Diffie-Hellman
algorithm. The standard Broadcast version takes N(N-1) = N2
– N messages.
3.4 My Broadcast Version 2 of Diffie-Hellman
We will also assume that first Alice starts a group, then Bob joins, followed by Carol
joining the group and so on.
(1) Alice’s public value is
A = p a
* mod (q)
(2) Bob’s public value is
B = p b
* mod (q)
(3) A and B have shared secret kab
kab = p ab
* mod (q)
(4) Alice and Bob exchange their private values, which were randomly and
independently generated by Alice and Bob, encrypted by their shared secret and
signed by their respective private keys that remain the same and not randomly
generated.
(5) Carol joins Alice and Bob, and sends its public value C

C = p c
mod (q)
(6) Alice or Bob or both independently send their agreed public value AB to C.
AB = kab
ab
* mod (q) = p (ab)(ab)
* mod (q)
For sake of optimizing, we will assume the last member to join the group will be
responsible to the group’s public value.
The private value for the entity AB seems to be the product of the private values
multiplied and raised to the number of nodes, i.e., 2. The private value is (ab) 2
.
(7) Carol calculates the shared secret kabc with A and B
kabc = (AB)c
mod(p) = p (ab)(ab)c
* mod (q) = p (ab ** 2)c
* mod (q)
The shared secret seems be equivalent to p[(private value of entity AB) * (private value of entity C)]
*
mod (q).
(8) Alice and Bob independently, calculate the shared secret kabc with Carol,
kabc = C (ab)(ab)
mod (q) = p (ab)(ab)c
* mod (q) = p (ab ** 2)c
* mod (q)
The shared secret seems be equivalent to p[(private value of entity AB) * (private value of entity C)]
*
mod (q).
It is clear the each node has to track the number of times it has gone through group
membership reformations. So Alice and Bob have seen 2 group reformations, and
Carol has seen 1 .
(9) Alice and Bob send their individual private values to Carol.
As an optimization, only Bob sends Alice’s and Bob’s private values that they
exchanged during step 4.
(10) Carol does the vice versa. So, all parties have a, b and c private values that were
randomly generated. Carol can broadcast her private value c to Alice and Bob.
(11) Doug joins Alice, Bob, and Carol and sends its public value D to them
D = p d
mod (q)
(10) Alice, Bob and Carol independently send their agreed public value ABC to D
ABC = kabc
abc
mod(q) = p (((ab)(ab)c)) (abc))
* mod (q) = p
(ab ** 3)(c**2)
As an optimization, Carol only send the public value ABC since she was the last
member.

The private value for the entity ABC seems to be (ab 3
)(c2
), i.e., (product of private
value of the first two nodes, raised to the number of times they have been in group
reformations) * (private value of third member the number of times it has seen group
reformations).
(11) Doug calculates the shared secret kabcd with Alice, Bob, and Carol
kabcd = (ABC)d
mod(p) = p (((ab)(ab)c)) (abc)) d
* mod (q) = p (ab ** 3)(c**2) d
* mod (q)
The shared secret seems be equivalent to p[(private value of entity ABC) * (private value of entity D)]
*
mod (q).
(12) Alice, Bob and Carol independently calculate the shared secret kabcd with Doug
kabcd = D (ab)(ab)(ab)(c)(c)
mod (q) = p (ab)(ab)c
* mod (q) = p (ab ** 3)(c**2) d
* mod (q)
The shared secret seems be equivalent to p[(private value of entity ABC) * (private value of entity D)]
*
mod (q).
It is clear the each node has to track the number of times it has gone through group
membership reformations. So Alice and Bob have seen 3 group reformations, Carol
has seen 2 and Doug has seen 1,
(13) Doug broadcasts his private value d to Alice, Bob, and Carol, encrypted with the
new shared secret and signed by Carols’s private value.
(14) Alice, Bob and Carol send their private values to Doug. As an optimization,
Carol can send the private values for Alice and Bob, and herself, since she received
Bob’s and Carol’s private keys in Step 9.
(15) So when Ed will join, he will broadcast his public value E to Alice, Bob and
Carol:
E = p e
mod (q)
(16) Alice, Bob, Carol and Doug will send their private value for entity ABCD.
ABCD = kabcd
abcd
* mod (q) = p (ab**4)(c**3)(d**2)
mod (q)
As an optimization, Doug sends the public value ABCD, as it was the last
member to join the group.
The private value for the entity ABCD seems to be (ab 4
)(c3
)(d2
).
It is product of private value of the first two nodes, raised to the number of times
they have been in group reformations, the private value of third member the
number of times it has seen group reformations, the private value of fourth
member the number of times it has seen group reformations, and so on.

(17) Alice, Bob, Carol and Doug will independently calculate the new secret key kabcde
for the Group ABCDE as
kabcde = E
(ab**4)(c**3)(d**2)
mod (q) = p (ab**4)(c**3)(d**2) (e)
* mod (q)
The shared secret seems be equivalent to p[(private value of entity ABCD) * (private value of entity
E)]
* mod (q).
(18) E will calculate the same value based on public key ABCD
kabcde = ABCD e
* mod (q) = p (ab**4)(c**3)(d**2) (e)
* mod (q).
The shared secret seems be equivalent to p[(private value of entity ABCD) * (private value of entity
E)]
* mod (q).
This methods needs 2(n) + 2(n-1) round of messages, where n is the round of
iteration of exchanging messages between two entities, where the entities may be
groups having members or member themselves. Since 2 node make the first
round, and 3 nodes make a second round, we can say 2(N-1) + 2(N-1-1) = 4N –
6 messages, where N is number of nodes.
The side effect is that each new node takes 4 extra round of messages. Introduction to a
group can be controlled through an expanding ring algorithm. Members leaving can
trigger a fresh execution of the algorithm from ground zero, which is not very scalable.
All private and public values have to recomputed since a leaving node knows all about
the current members public and private values. If one of the remaining members act ac a
coordinator, then a new set of public and private values can be calculated and a new
group key can be calculated in N-1 messages.
3.5 Burmeister-Desmedt Conference Key Distribution Protocol
The algorithm was proposed by Burmester and Desmedt. It takes 2N rounds of N
broadcasts to come to a shared secret key. Since like Deffie-Hellman, the
algorithm is prone to the man-in-the-middle attack, we still need a private-public
key mechanism to have individual members sign messages.
The algorithm completes in 3 rounds of computations, with each round
accompanied by each node sending a broadcast message.
In the first round, each participant selects it
zi = p r
i * mod (q) and broadcasts it.
In the second round, each participant computes Xi = (z i+1 / z i-1 )r
i * mod (q) and
broadcasts.

In the last round each participant can compute the conference key
Ki = ((z i-1)
nr
i * X i+1
n-1 *
X i
n-2 *…..*
X i-2 )) mod (q)
For new membership, we will still need 2N round of messages. If any member
leaves, the cost will be the same.
Again this protocol also assumes a peering arrangement and there is no central
group controller.

3.6 Binary Tree Algorithm
Figure 1. 0 A B-Tree
Nodes Leaf Parent Grandparent Great-Grand Grand-Grand
Node 1Keys Private 1 Key Shared C Key Shared A Key Group Key 0
Node 2 Keys Private 2 Key Shared C Key Shared A Key Group Key 0
---------------
Node 7 Keys Private 7 Keys Shared F Key Shared B Key Group Key 0
Node 8 Keys Private 8 Keys Shared F Key Shared B Key Group Key 0
Figure 2.0 Key Chain Distribution Table
New Keys For Left Child For Right Child
Node C Key Encrypted with Private Key 2
Node D Key Encrypted with Private Key 3 Encrypted with Private Key 4
Node A Key Encrypted with Private Key C Encrypted with Private Key D
Node F Key Encrypted with Private Key 7 Encrypted with Private Key 8
Node E Key Encrypted with Private Key 5 Encrypted with Private Key 6
Node B Key Encrypted with Private Key E Encrypted with Private Key F
Group Key 0 Encrypted with Private Key A Encrypted with Private Key B
Figure 3.0 Encryption Sequence of Affected Keys when Node 1 is removed
We arrange N nodes in a multicast group as leaves, with each holding log2 N
Keys. Adjacent nodes have only one key unique among them and have remaining
log2 N-1 keys common.
1 2 3 4 7 8
C D F
A B
02^0
2^1
2^2
2^3 65
E
2^3+1
- 2

There is a parent key between any two adjacent leaves and is known to both of
them. The parent key is delivered encrypted individually with leave nodes’
private keys.
Adjacent parent nodes have a grand-parent node and that in turn has it own grand-
parent key. A grand-parent key is delivered encrypted individually with parent
nodes keys.
Adjacent grandparent nodes have a great-grand parent node and it has it own
great-grand parent key. A great-grand-parent key is delivered encrypted
individually with grand-parents node keys.
And this process will carry own, till all leave nodes and intermediate ancestor
nodes reach a common ancestor node called root node. The Group Controller
owns the root node and all other intermediate nodes are hypothetical nodes.
Leave nodes form a point-to-point secure channel communication with a Group
Controller, and obtain all log2N keys, along their tree path from their leave node
to the root node. The keys contain key-id, revision, version and key information.
When a new node joins, the Group Controller gives the set of keys belonging to
the new leaf node, with new revisions of overlapping keys and a fresh key for the
leaf node. The affected keys are one way hashed to by the Group Controller to
get to the new version of keys. It also sends a broadcast message to affected
nodes to update their affected keys. The broadcast a message says that so and so
key ids have their revisions changed or updated to such and such number. Hence
the cost of addition is only one message. The affected node members can derive a
new revision by applying a one-way hash to overlapped keys. This is an
optimization. The Group Controller could just send a message with 2log2N + 1
keys encrypted with one other, in a nested fashion.
When a leaf node leaves, all keys it had known have to be version controlled. The
Group Controller first creates a new key for the parent node, and then the great-
parent node and then the grand-great parent node and this goes on till it hits the
root node key, which is the new Group Key. It does it for the branches going
from the departed member’s node to the root as well as the sub-branches hanging
off from the sub-nodes that fall on the path from the departed node to the root.
It encrypts the new parent node key with the adjacent nodes private key, and the
grand-parent’s new key with the new parent node key from one branch and also
old parent node key from the other branch that was not affected. The great-grand-
parent node’s new key will be encrypted using the new grand-parent node’s key
from one branch and also with the great-grand-parent node’s key from the other
branch that did not get affected. This process will go till the new root node key is
encrypted with its two children keys. All these keys will be broadcast in one
message containing 2logN + 1 keys.

3.5.1 Costs
Number of
Group
Members
N
No of
Unique
Key Per
Group
Member
Number of
Keys Per
Each
Member
Log2N +1
No of Keys
To Be Updated
Per Leave and
Join
2*Log2N +1
No of Messages
For
Broadcasting
All Keys in one
Message
No of Messages
For
Broadcasting
Affected Keys
along Tree
Branches
4 1 2 + 1 4+1 1 2
8 1 3 + 1 6+1 1 2
16 1 4 + 1 4+1 1 2
32 1 5 + 1 10+1 1 2
64 1 6 + 1 12+1 1 2
128 1 7 + 1 14+1 1 2
256 1 8 + 1 16+1 1 2
512 1 9 + 1 18+1 1 2
1024 1 10 + 1 20+1 1 2
2048 1 11 + 1 22+1 1 2
4096 1 12 + 1 24+1 1 2
It can be easily shown that a tree with 3 branches, instead of 2 branches has the minimal
cost. Also the tree concept can be extended to any number of branches.
3.6.1 My Oprimizations
3.6.1.1 Elimination of Single Point of Failure
The above algorithm needs a central entity called Group Manager that acts as a
coordinator but can also be the single point of failure and a bottleneck. We can eliminate
this by running replicated nodes of Group Managers that to outside world acts as one
central entity and has one IP address. By using a device like Local Director, we can
direct traffic to one of the replicated nodes of a Group Manager. But then the Group
Manager need to coordinate among each other to let one of the replicated node be in
control to generate Group Session Keys and other nodes should learn about the new
Group Session Keys in a secured fashion. This needs a reliable and secures Group
Communication, the problem that we began to solve! We are still in luck as we can use
less efficient Multicast Security Algorithms like: (1) Standard Broadcast Version of
Diffie-Hellman, (2) Sunil’s/Cisco Broadcast Version 1 of Diffie-Hellman, or (3)
Sunil’s/Cisco Broadcast Version 2 of Diffie-Hellman, or (3) Burmeister-Desmedt
Conference Key Distribution Protocol.
3.6.1.2 Hierarchical Keying And Notion of Group Controller

In the Binary Tree Algorithm, we assumed that only leaf nodes are member nodes and
other intermediate nodes are not members. In this case the Group Controller Node has
the responsibility of encrypting 2log2N+1 keys and sending them either in one broadcast
or multicast message or 2log2N+1 messages.
Since the Multicast Routing Trees, Reliable Multicasting Transport Trees, Hierarchical
Cache Chaining and Directory Trees are also trees, we need to realize what if the
Multicast Keys B-Tree is superimposed with these Trees. Here the intermediate nodes in
the Multicast Key B-Tree also become node members. So instead of having N Nodes
having 2N+1
- 1 Keys in total, and each node having log2N keys, we will have 2N+1
- 1
Nodes having 2N+1
- 1 keys in total, and each node will have log2n key, where n = 0 to N.
The ’n’defines the level in a tree. This is vast leap in improving the efficiency and
scaling of the algorithm.
In this case , when an intermediate node receives a Join and Receive Message, it can do
the following:
(1) It can go ahead and change keys of the affected nodes under its node. In this case the
work done by the root Group Manager is being reduced. The intermediate node acts like
a sub Group Manager for its branch.
(2) It can either go ahead or send a request to the Group Manager to send a new Group
Session Key or ask permission from Group Manager to create a new session key.
(3) If the Group Manager creates a new Group Session key, it has to be encrypted in the
key(s) for the intercepting node. But is the Group Session Key is being changed because
a member has left, then the intercepting node has to change its key(s) which were also
known to the leaving group member. To solve this problem, the intercepting node has to
have a private channel with the root Group Manager and has to have it secured. Over this
channel it sends the root Group Manager its updated version of keys.
There are other ways to secure them as discussed layer. The other solution is that the
Group Manager has to decrypt the Group Session Key sent from the root Group Manager
and then encrypt then back with newly created keys that were affected and had to be
changed. But this will be a slower process.
The number of keys affected by the intercepting node will be 2log2N - 2log2n, where n is
the level where the intercepting node intercepts. Thus we can see that the number of keys
that are getting affected have reduced and the number of keys encrypted and decrypted
will be further reduced.
(4) If the intercepting node decides to generate the Group Session Key, it has to ask
permission from the root Group Manager. This is equivalent to the floating Token in the
previous optimization. Then it has to send its affected key(s) to the root Group Manager
over a secured channel.
3.7 Group Identity Based

This is a variation of the Binary Tree Protocol. Assume that there is a address
space of 2^N member node elements. Each member is identified by a word of N
bits long, where each bit corresponds to a binary 1 or 0. If we have a private key
corresponding to each bit in the address id and it possible values, we will have a
total number of keys equal to 2N. Then we have a Session Group Key.
Whenever a node joins a group, the Group Manager will hand out the N keys
corresponding to bit values of node joining by its Id, after version incrementing it.
Whenever a node leaves a group, the Group Manager will broadcast a new Group
Key encrypted in remaining N Keys that were unaffected by a node leaving. It
will also broadcast the new version of the affected N keys encrypted in the new
Group Key (which other nodes would have got as they still have N-1 keys
unchanged) and old set of N keys.
This approach takes less space compared to the binary tree approach but has the
same philosophy. The N private keys could be made arranged in the B-tree
further to increase security, and also solve the problem of multiple leaves, which
the algorithm does not take care of very well.
3.7.1 My Optimizations
3.7.1.1 Hierarchical Identities
The identities can be hierarchically allocatedm where the MSB bits are for node
members closer to a root Group Controller. This way the number of keys that will
be affected will be contained.
The idea is similar to the second optimization I discussed in the previous section
on the B-Tree.
3.7.1.2 Directory Replication
Since the identities are to be derived uniquely, we use the IP address and Time
coordinates to get to an unique id, but this will not be contiguous. We can further
hash it or make it go through a central registration authority to get an unique key
that is contiguous in the address space.
Since we have the Multicast KDC generate the Group Session Key and it is
specific to a Publisher, Subscribers and Publishers need to get a special id specific
to that Publisher or its Multicast KDC.
Later on when the information gets replicated, the local copies of Directory can be
used to get a common Group Session Key.

This assumes that the members will not come and go and perfect forward secrecy
and perfect backward secrecy is not required. This is a perfect solution for
Muiltcast KDC nodes to secure their channel among themselves!
3.7.1.3 Key Updates
It will be desirable to change the keys among the MKDC from time to time. We
can have the agent in the Multicast KDC specific to a Publisher generate enough
keys that also change with time dimensions and be replicated. This way we can
take advantage of the Directory Replication and occasionally change the keys
among MKDCs that build a secured channel specific to a Publisher’s MKDC.
4.0 The Expanding Ring Beacon Protocol
This section talks about how we can use the algorithms that I proposed in the
beginning and are like Deffie-Hellman to come to a shared secret. This was my
original thinking when I was not aware of the Binary Tree Alogorithms.
We have successfully demonstrated that we have reduced the overhead of
message exchanges required from N(N-1) in case of Deffie-Hellman to 4N – 6
messages in case of my proposed algorithms, and 2N in case of the Burmeister-
Desmedt, and 2Log 2 N+1 in case of Binary Tree (or one message with 2Log 2
N+1 keys. This is quite an achievement if we would like to scale up the number
of nodes doing a secured multicast based communication.
For argument sake, in an Enterprise domain, which can span the globe, with
partnered Enterprises, again spread over the globe, we can have domains in
thousands. If we have to model the whole DNS then this may come to millions of
domains! If each domain had a few domain controllers, then we would expect the
same number of KDCs for our solution for not having a single point of failure for
KDC nodes.
If this multicast group was within a domain, then there will be only a few KDC
nodes and we need not worry about scaling. But if the multicast group spans
hundreds or thousands of domains, then we may have a problem if would like to
replicated KDCs spanning many domains.
One solution to avoid is this is to have the Subscribers go to the KDC in the
Publisher’s domain, which will be replicated.
The other problem is that it will difficult to control the order of nodes joining a
group, and one could control the order by employing a random wait period with
an exponential back-off mechanism. In Multicast there is a mechanism called
Time-To-Live (TTL) and it is used to limit the radius of hops that a multicast
packet will travel.
We could leverage this when starting the Group Membership Protocol. By
expanding the TTL, from 0 to higher numbers, we can have a multicast node, first

discover its neighbors that are nearby and then build a secured communication
among them before letting far off members join a group.
When a new node joins in, it waits for a time-out period to hear a beacon from a
neighbor. If it hears a beacon from a neighbor, it will join the neighbour initiated
group. The beacon contains the ordinal list of members of a group. The group is
identified by a value that is a hashed value of all members IP addresses. If a
multicast node does not hear a beacon for a waiting period, it starts a group by
itself and identified by a hashed value of its IP address and starts expanding the
search ring by increasing its TTL.
When a node discovers a beacon by a neighboring group or a node, which can be
identified by the list of members carried in the beacon, it will merge with a new
group.
There is a possibility that many nodes may start groups independently and have
multicast nodes in their vicinity as part of their individually initiated group, and
then discover each other. In this case the protocol of establishing a secured
channel will be same as if two entities are joining each other. In fact this
approach will scale better and the group reformations would have proceeded in
parallel. The merging of groups will be speedier and it will be like building
binary sub-trees separately and then merging them with each other to build a
larger binary tree.
There is also a possibility that a multicast node would like to join a node, but it
sees the group being busy with the reformation group membership protocol with
another node. In this case, the random delay tactics and exponential back-off will
be employed and then the reformation group will be again tried by the waiting
multicast node. The other option for this node will be to decrease its TTL and
form a group hoping that a new multicast node will join its group.
There is another possibility that one group discovers second group. But the
second group discovers a third group, besides the second group, and the third
group discovers the fourth group, besides the second group, and so on. In this
case the second group can gossip about the first group to the third group and also
gossip about the third group to the first group. In the gossip protocol, the second
node also helps the first node and the second node discover the distance with each
other in terms of TTL. The second group will join the first group or the third
group. The new group will then join the group that was left out.
If anytime a multicast node or group drops out, the group can immediately encode
a new secret with the old key and broadcast.
Every node sends its keep alive to its neighbor node and when a new node is
sensed, a group reformation happens which includes going through an message
exchange protocol to come to a new secret. Once the secured channel is built, the
new membership list is sent after an update.

Since this protocol is very sensitive to nodes going up and down, it is expected
that the KDCs will be run on highly available nodes and will not go up and down
that frequently. For this reason, Publishers and Subscribers nodes will not
directly employ the algorithm to get to a shared secret but instead use KDCs to
get a new dynamic Session Key.
The gossip protocol is like any other flooding protocol and is susceptible to surges
of nodes going up and down. The same problem is faced by Routing Protocols.
Hence there will be an upper limit to the number of domains that can be crossed
with this approach. In this case, we have to manually configure peer exit and
entry point nodes, something like BGP equivalent or set up rendezvous nodes like
CBT protocols. This process will be manual or some other protocol has to be
implemented.
The other solution is to use hierarchical scaling approach used in the ATM
Routing Protocol PINNI.
5.0 Scaling using Hierarchical KDC Groups using overlapping Multicast Groups.
Some designated KDCS will be members of two KDC Multicast groups.
Basically they will be using a “back door” channel on the same machine to
replicate dynamic Group Session Keys for keys that need to passed to upper or
lower KDC Multicast Groups. These KDC Multicast Groups will be strategically
placed along well defined boundaries, which may be at the head of a tree or
domain and so on.
There needs to be some mechanism to know how far a Publisher and Subscribers
are spread. This value is defined by the Multicast TTL value. The same value
can be given as hint for replicating a dynamic Group Session Key among the
KDCs within a one KDC group and among KDC groups.
6.0 Conclusion
The proposed solution is scalable compared to any method proposed so far for
solving the problem of building secured channels. Like any solution it will reach
its breaking point, which is OK since even the Multicast Routing Protocols and
Reliable Multicast Routing Protocols have there upper limits. Practically it not
expected to have more 30,000 nodes participating in a group membership. The
numbers of KDCs serving such a population will not span more 3000 KDCs, if
we assume on average each KDC serves 10 nodes. If it serves 100 nodes, the
number of nodes will be 300 and so on.
We do not expect to have an Enterprise have more than 300 sub domains and not
more than 100 trees in a forest. Each tree represents a complete Enterprise or its
partners. So there will be at the most 30,000 domains. So theoretically there may
be up to 10,000 KDCs across domains.
To scale-up, one can then have a designated or rendezvous KDC node each per
tree that will talk to peering KDCs in the tree. Or we can have KDCs interspersed

along the tree ever hops. These KDC are special KDCs and they in turn can use
the same protocol to build secured channel across the Rendezvous KDCs but
using different Multicast Address. This way we can always scale up and at
present these requirements seems very high. Scaling up to 3000 KDCs seems to
be a reasonable goal and it should not take more than a few seconds for the
protocol to converge.
7.0 Other solutions that I came across
The concept of distributed KDC interspersed along CBT routers was one proposal
that I came across and they rely on secured point-to-point channel to build the
distributed KDCs that is overlaid along the CBT tree. Only CBT has the options
for security headers. PIM, OSPF, DVMRP do not have such options and have to
be modified to do the same.
The second proposal that I came across was using a modified version of IGMP to
do the Authentication at the time of a node issues IGMP.
8.0 The Solution
Requirements for Scalable Secured Multicast Security
• Security should provide: Authentication, Encryption, Attacks against Repudiation and
Replay Attack Proof through Signatures, Hash and Certificates
• Perfect Forward Secrecy and Perfect Backward Secrecy for Multicast Security
• Dynamic Multicast Groups
• Should Scale for Large Groups Spanning LAN and WAN
• Should Scale for Large Domains and Cross-Domains.
• Session Key has temporal and spatial randomness.
Assumptions
• Should leverage Directory (and its KDC) do Point-to-Point Authentication
• Take advantage of multiple DSAs in a domain to distribute load - which hold
identical replica of domain specific data
• Take advantage of DSAs across domains and trees to distribute load - which hold
meta data for cross domains and cross trees.
• Take advantage of GC to work cross-domains and trees and publish domain specific
data at global level.
• Take advantage of DSA replication wherever possible.
• Publishers, Subscribers, Multicast Service Agents (MSA) and Multicast KDCs
(MKDC) will be Security Principals.
• For cross-domains and cross trees, mutual trust will be administrative setup for Event,
Publisher and Subscriber Objects in the Directory.
• Directory Publish Data for Events that are published by what Publishers and what all
Subscribers can subscribe what all Events.

• Multicast Publisher and Subscriber will use Multicast KDC (MKDC) as a proxy
Multicast Service Agent (MSA) to do Authentication and Group Session Key
Management
• MKDC and MSA will authenticate multicast Publisher and Subscriber, which in turn
use a DSA and its KDC to authenticate Publishers and Subscribers.
• Multicast Publisher will use the Multicast MSA AND MKDC close to itself and
within its domain.
• MSA and MKDC close to a Publisher will be the primary Group Session Key
Manager.
• A Publisher controls group Session Key or Multicast KDC installed near a Publisher.
• MKDC will be distributed at LAN level, domain level, across domains and cross trees
to scale and balance.
• Events will have information, implicit through Directory based Event Discovery, or
explicitly based on Event Headers, the preferred MKDC and MSA IP Address.
• Subscribers will request Group Session Key at the time of joining a Group and the
request will be received by MKDC+MSA near them, which in turn will pass the
information to MKDC+MSA near a publisher.
• Subscribers will keep sending heartbeats to their MKDC+MSA for after every time
interval.
• Subscribers will send a Group Leave Message at the time of leaving a group.
• MKDC+MSA near Subscribers will forward the Join and Leave Requests and track
Subscribers timing out, upon which a Leave Request will be issued on behalf of
Subscribers.
• Like Multicast Traffic has to be limited in its flooding, the Group Session Key has to
be limited in being replicated for the sake of scalability and load balancing. So we
will assume that the Keys are only replicated within a domain and sometimes cross-
domains.
1st
Order of Scaling
1. Use Binary Tree Algorithm for Scaling to a Large Multicast Group. The algorithm
has the best characteristics for scaling for large groups as only log2N + keys are
maintained and log2N key decryption’s are required to get a Group Session Key.
2. The Binary Tree Algorithm needs a central Group Key Manager and by making the
MKDC near a publisher as a Group Key Manager for a Publisher and the Events it is
publishing, we have already distributed the load. The Group Key Manager can be a
single point of failure.
3. Use other mixture of algorithms to address the problems in the Binary Algorithms to
eliminate a single point of failure, distribute load and do load balancing.
2nd
Order of Scaling:
1. By filtering out unauthorized Subscribers go to their MSA+MKDC, which in turn
will use their local DSA to discover Events and get authenticated.

2. Multiple nodes of MKDC+MSA may advertise one virtual IP Address through
Directory Services for a given domain and use Local Director (which takes a virtual
address and translates to an available address) or a set of IP addresses.
3. MSA+MKDCs from outside domain or tree will contact either one virtual IP address
or one of the ’n’possible IP addressees
4. Each Publisher from different domains will "attract traffic" to its MSA+MKDC and
hence spread the overall load among multiple MSA+MKDC nodes.
3rd
Order of Scaling
1. The multiple MKDCs + MSAs at LAN level will create a secured group
communication among themselves using Broadcast Secured Algorithms which do not
support dynamic Group Memberships very well and scale to large groups but are OK
for small groups of few tens of nodes.
2. The MKDCs+MSAs at LAN level will be using a distributed token, which will be
floated to grant Group Session Keys in a sequential order.
3. MSA+MKDCs within a domain at LAN level will replicate Group Session Keys
using Secured Multicast Channel in real-time.
4. The Secured Channel will be built using least amount of data from the directory but
after having the MSA+MKDCs authenticated through DSA+KDC.
5. The Secured Channel will be built based an algorithm that prefers static membership
(since the MSA + MKDC does not come up and down all that often) and does not
care for forward or backward secrecy but will be useful if it does. Since the nodes
expected here are not to be exceeded by 30, they can use: (1) Standard Broadcast
Version of Diffie-Hellman, (2) Sunil’s/Cisco Broadcast Version 1 of Diffie-Hellman,
or (3) Sunil’s/Cisco Broadcast Version 2 of Diffie-Hellman, or (3) Burmeister-
Desmedt Conference Key Distribution Protocol.
6. Outside domain MSA+MKDC will be authenticated using their supplied info in their
request to the Publisher’s Domain specific MSA+MKDC.
7. The Dynamic Group Session Key will be based on the "Binary Tree Protocol".
4rth
Order of Scaling
1. A domain specific MKDC+MSA node will learn about all the outside domain
MKDC+MSA in two ways: (1) Through Directory and (2) When the outside MKDC
+ MSA node approaches it for a Group Session Key.
2. The outside MSA+MKDC node will approach the domain specific MSA+MKDC
node by either: (1) discovering the domain specific MSA+MKDC node IP Address in
the Event Header that a Subscriber presented to the outside MSA+MKDC node (and
possibly directed through Local Director), (2) discovering the list of MKDC+MSA
nodes from a Publisher for an Event listed in the Directory, and (3) through an
administrative setup of mutually trusted cross domain MSA+MKDC nodes
information in the Directory.

3. The nodes will build either a point to point secured channel using conventional
methods or a multi-point secured channel for an Event among inter-domain
MSA+MKDC nodes.
4. Each nodes will use their replicated universal IDs specific to an Event as a basis to
get a common secured key for communicating among inter domain MCS+MKDCs.
5. The publisher specific MCS+MKDCs can then publish the dynamic Group Session
Keys on pre-registration (through directory discovery), or on demand basis, or on pre-
setup of mutually trusted domain basis.
6. The Dynamic Group Session Key will be based on the "Group ID Based Protocol".

Appendix A. Comparision among Different Methods
Tree Central Distributed Mine
Allows establishment of
group-wise key to
authenticity
Yes
2N pt-to-pt
Messages
Yes
2W pt-to-pt
messages, where
2^W = N
Yes
Between 0 to
2W
Perfect forward secrecy Yes
1 Broadcast
Message of
Log N Keys
Yes
Broadcast W key
Yes
2W pt-to-pt
messages
Perfect backward secrecy Yes
1 Broadcast
Message of
Log N Keys
Or Hash Op
Yes
Broadcast W key
Yes
2W pt-to-pt
messages
Dynamic Membership Yes Difficult Difficult
Required for Group
Authentication
No No No
Authentication
Yes Yes Yes
Designed for one
Yes Yes No
Yes No No
Multiple leaves Yes Difficult Difficult
participants
Yes Difficult Difficult
of groups
Yes Yes Yes
issue
Yes Yes No
during operation
No No Yes
Assigned IDs or
Network IDs
Both Both Both
Single point of failure Yes Yes No
Easily recoverable Yes Yes Difficult
Small database logN W W
Yes Difficult Difficult

Deffie-Hellman Broadcast
Version
Deffie-Hellma
Burmeister-Desmed Mine
group-wise key to
authenticity
Yes
2(N-1) pt-to-pt
messages
Yes
N(N-1) pt-to-pt
messages
Yes
2N Broadcast
Messages
Yes
4N-6 Mainly
Boadcast
Messages
Perfect forward secrecy Yes
N-1 pt-to-pt
messages
Yes
N(N-1) pt-to-pt
messages
Yes
2N Broadcast
Messages
2(N-1) pt-to-pt
messages
Perfect backward secrecy Yes
N-1 pt-to-pt
messages
Yes
N(N-1) pt-to-pt
messages
Yes
2N Broadcast
Messages
4 Messages
Dynamic Membership Difficult Difficult Difficult Difficult
Required for Group
Authentication
Yes Yes Yes Yes
Authentication
Yes Yes Yes Yes
Designed for one
Yes No No No
Yes Yes Yes Yes
Multiple leaves Difficult
Heartbeat &
Group View
Protocol
Difficult
Heartbeat &
Group View
Protocol
Difficult
Heartbeat &
Group View
Protocol
Difficult
Heartbeat &
Group View
Protocol
Serialized
participants
Yes Yes Yes Yes
of groups
No Yes Yes Yes
issue
Yes Controlled
Through
Expanding Ring
Membership
Protocol
Controlled
Through
Expanding Ring
Membership
Protocol
Controlled
Through
Expanding Ring
Membership
Protocol
during operation
Yes Yes Yes Yes
Assigned IDs or
Network IDs
Both Both Both Both
Single point of failure Yes
Can be fixed
With Local
Director and
2 Nodes Sharin
No No No

Media or Info
Easily recoverable Yes Yes Yes Yes
Small database N-1 N(N-1) + 1 2N + 1 2N + 1
No Yes Yes Yes

Appendix - B
Distributed KDCs for Multicast
Group Needs
Members of Multicast Group
Needs
group-wise key to
authenticity
Yes Yes
Perfect forward secrecy No Most likely but depends
Perfect backward secrecy No Most likely but depends
Dynamic Membership No Yes
Required for Group
Authentication
No No
Authentication
Yes with Public Key
Infrastructure or Kerberos
KDC
Yes with Public Key
Infrastructure or Kerberos
KDC
Designed for one
Depends, May be Directory
Enabled for Central Admin
Depends, May be Directory
Enabled for Central Admin
Distributed KDCs for Multicast
Group can Act as Distributed
Central Controlling Entity
Depends how Distributed
KDCs are secured
Most likely but depends
Multiple leaves Support Not Needed Most likely but depends
participants
Support Not Needed Most likely but depends
of groups
KDCs are secured
For Dir Enabled Multicast
KDCs, this may not be
needed
Can not be tolerated
issue
KDCs are secured
For Dir Enabled Multicast
KDCs, this may not be
An issue
Load Balancing Devices can
Be used
Depends how Group
nodes are secured but Multicast
KDCs acting as a Group
Manger can help
during operation
No Depends how Group
nodes are secured
Assigned IDs or
Network IDs
Flexible Depends how Group
nodes are secured
Single point of failure Not Tolerated Not Tolerated
Easily recoverable Yes

Small database Can be Big Static can be big, dynamic need
To be small
Not Required Depends on how Group nodes
Are secured.

securemult

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to securemult

Similar to securemult (20)

securemult