PARÁMETROS QUE INFLUYEN EN LA UCS

AKMithen sends it via acreate₋grantedmessage toM encrypted under AiM−Key:

AKMi →M :IDAik{Grp−T okenktext}AiM−Key.

Otherwise, AKMi sends a create₋denied message to M.

Step 5: On receipt, M checks the message by decrypting it with AiM−Key.

Assuming that the request to create a multicast group is granted,M

obtains the keys along with other information via the Grp₋T oken.

In summary, assuming that the join request is successful, at this point a new multicast group is created, with DKM as the domain key manager, AKMi as the area key manager, and M as the group initiator. The keys that are distributed through the protocol are the traffic key T₋Key and the area key

A₋Key.

9.3

Protocol II(a): New Member Joining without

Backward Secrecy

This protocol describes a new join of a host to a multicast group with no consideration to secure access to the previous data traffic, in other words no provision of backward secrecy. The protocol also includes the delivery of a traffic key T₋Key and an area key A₋Key to the newly joined group member

M.

Throughout this protocol, we make the following assumption:

• Any request to join the group only occurs after the successful creation of the multicast group usingProtocol I (Section 9.2).

The message flow of this protocol is depicted in Figure 9.2, and the steps involved are described as follows:

9.3 Protocol II(a): New Member Joining without Backward Secrecy

Figure 9.2: Member Joining without Backward Secrecy protocol message flow. Step 1: A host M that wishes to join a multicast group sends ajoin₋request

message to the area key manager AKMi encrypted under AiM−Key

(see Section 8.3.6.1):

M _→AKMi :IDMk{IDGkIDAikIDMktext}AiM−Key.

Step 2: On receipt, AKMi performs the following:

(a) AKMi checks the message by decrypting it with the secret key

AiM−Key shared with M. AKMi then passes the join−request

message to DKM encrypted under Domain-Area key DAi−Key

(see Section 8.3.6.1), along with the ID of the requesting entity, as well as the ID of the multicast group for joining:

AKMi →DKM :IDAik{IDGkIDAikIDMktext}DAi−Key.

(b) Assuming that hostM is permitted to join the group, AKMisends ajoin₋granted message to M encrypted under AiM−Key, along

with the current keys (the traffic key T₋Key and the area key

A₋Key) in the form of Join₋T oken:

AKMi →M :IDAik{Join−T okenktext}AiM−Key,

whereJoin₋T oken=_{IDGkIDAikIDMkT−KeykA−Keyktext}.

9.4 Protocol II(b): New Member Joining with Backward Secrecy

Note that the keys that are currently in use by group members are delivered to the newly joined member.

Step 3: Upon receiving the join₋request message, DKM checks the message by decrypting it with the secret key DAi−Key which it shares with

AKMi, and assuming that host M is granted permission to join the multicast group, DKM sends ajoin₋granted message to AKMi. Note that it is not necessary for other AKMs to be notified of the new join as it does not affect the overall group operation in the domain. New joins with no provision of backward secrecy simply require DKM to add a new member to a particular multicast group.

Step 4: Upon receiving the message from AKMi, M checks the message by decrypting it with his secret keyAiM−Keyto obtain theJoin−T oken

which, in particular, contains the cryptographic keys needed for the group communication.

In summary, assuming that host M is granted permission, using this protocol

M joins a multicast group within an area where AKMi is the area key manager and DKM is the domain key manager. Group member M is also given the current set of cryptographic keys; the traffic key T₋Key and the area key

A₋Key.

9.4

Protocol II(b): New Member Joining with

Backward Secrecy

This protocol describes a new join of a host to a multicast group with con- sideration to preventing access to the previous data traffic from the newly joined member, in other words provision of backward secrecy. This protocol also includes the delivery of a new traffic key T₋Keynew and a new area key

A₋Keynew to the newly joined member M and other group members (if any) in the area where the join occurs, as well as across the domain.

9.4 Protocol II(b): New Member Joining with Backward Secrecy

Figure 9.3: Member Joining with Backward Secrecy protocol message flow. The message flow of this protocol is depicted in Figure 9.3. Due to similarity withProtocol II(a) (seeSection 9.3), we only describe the differences as follows:

(a) In addition toStep2 inProtocol II(a) (seeSection 9.3), and assuming that the join is granted, AKMii must re-key its area key. To do so, it initiates

Protocol VI: Re-keying the area key (see Section 9.11). This results in all existing members in that particular area obtaining the new area key

A₋Keynew.

Note that only the area where the new host joins the group is re-keyed with a new area key. (Since the change in current group membership occurs only within a particular area, other areas should not be affected.)

(b) AKMi then delivers the new area key A₋Keynew in the join−granted

message to M in the form of Join₋T oken, as in Step 2(b) Protocol II(a)

(see Section 9.3).

(c) In addition toStep3, upon receiving thejoin₋requestmessage from AKMi, and assuming host M is allowed to join the multicast group, DKM initi- ates Protocol V: Re-keying the traffic key (see Section 9.10) and sends the join₋granted message along with ready₋to₋re₋key traffic key to all AKMs in the domain (including AKMi). This results in all AKMs and all group members in the domain obtaining a new traffic key T₋Keynew. DKM can send this message via two ways:

9.5 Protocol III(a): Existing Member Leaving without Forward