[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03                                                   
Internet Engineering Task Force                         Thomas Hardjono
INTERNET-DRAFT                                                Brad Cain
                                                       Indermohan Monga
                                                        Nortel Networks
                                                          November 1998
                                                      Expires July 1999


           Intra-Domain Group Key Management Protocol

              <draft-ietf-ipsec-intragkm-00.txt>


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet-Drafts

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

   Copyright The Internet Society (1998). All Rights Reserved.


Abstract

   This document describes a protocol for intra-domain group key
   management for IP multicast security, based on the framework of
   [HCD98]. In order to support multicast groups, the domain is divided
   into a number of administratively-scoped "areas".  A host-member of
   a multicast group is defined to reside within one (and only one) of
   these areas.  The purpose of placing host-members in areas is to
   achieve flexible and efficient key management, particularly in the
   face of the problem of changes (joining, leaving, ejections) in the
   membership of a multicast group. A separate administratively-scoped
   area control-group is defined for each (data) multicast group, for
   the express purpose of key management and other control-message
   delivery.



Hardjono, Cain, Monga                                         [Page 1]


Internet Draft       Intra-Domain GKM Protocol        November 1998


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
      3.1 Domains, Areas and Key Distributors  . . . . . . . . . . . 4
      3.2 Trust Relationships. . . . . . . . . . . . . . . . . . . . 5
      3.3 Multicast Groups for Data and Control. . . . . . . . . . . 6
      3.4 Keys: Multicast Groups and Control-Multicast Groups. . . . 7
      3.5 Control-Multicast Groups: Address Allocation . . . . . . . 8
      3.6 Group Security Associations . . . . . . . . . . . . . . . 10
      3.7 Secure Channels. . . . . . . . . . . . . . . . . . . . . .11
      3.8 Periodic Re-Keying . . . . . . . . . . . . . . . . . . . .11
      3.9 Arrangement of Keys in the Domain. . . . . . . . . . . . .12
   4. Creation of New Multicast Groups. . . . . . . . . . . . . . . 16
      4.1 Initiation of New Internal-Origin Groups . . . . . . . . .16
      4.2  Membership to External-Origin Groups. . . . . . . . . . .19
   5. Re-Keying Approach . . . . . . . . . . . . . . . . . . . . . .20
      5.1 Re-Keying of Multicast Keys  . . . . . . . . . . . . . . .20
      5.2 Re-Keying of Area Keys . . . . . . . . . . . . . . . . . .21
      5.3 Re-Keying of the All-KD-Key. . . . . . . . . . . . . . . .22
   6. Hosts Joining a Multicast Group. . . . . . . . . . . . . . . .23
      6.1 Joining with Backward Confidentiality . . . . . . .. . . .24
      6.2 Joining Without Backward Confidentiality . . . . . . . . .25
   7. Host Leaving a Multicast Group . . . . . . . . . . . . . . . .27
   8. Reliability in Key Management. . . . . . . . . . . . . . . . .28
   9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .30
   10. References. . . . . . . . . . . . . . . . . . . . . . . . . .30


1. Introduction

   This document describes a protocol for intra-domain group key
   management for IP multicast security, based on the framework of
   [HCD98]. In order to support multicast groups, the domain is divided
   into a number of administratively-scoped "areas".  A host-member of
   a multicast group is defined to reside within one (and only one) of
   these areas.  The purpose of placing host-members in areas is to
   achieve flexible and efficient key management, particularly in the
   face of the problem of changes (joining, leaving, ejections) in the
   membership of a multicast group.

   A separate administratively-scoped area control-group is defined for
   each (data) multicast group, for the express purpose of key
   management and other control-message delivery. A unique
   cryptographic key is associated with every (multicast group,
   control-group) pair in a given area.  The control-groups are used
   for key management, following the re-keying behavior described in
   [WGL98] and extending it over several key distributor entities.


Hardjono, Cain, Monga                                         [Page 2]


Internet Draft        Intra-Domain GKM Protocol         November 1998


2. Background

   The current document follows from the group key management
   framework proposal of [HCD98].  The framework of [HCD98] introduces
   two planes corresponding to the network entities and functions
   pertaining to multicasting ("network infrastructure plane") and to
   security ("key management plane").  Within the key management plane
   two hierarchies (levels) of regions are introduced, namely one
   "trunk region" (inter-region) and one or more "leaf regions" (intra-
   region).  These regions are defined to have unique group keys and
   are open to differing (inter-region or intra-region) group key
   management protocols.

   The current work introduces an "intra-region" (leaf-region) group
   key management protocol, where the term "domain" in the current
   work is taken to mean a single leaf region of [HCD98].  Although in
   practice one leaf region of [HCD98] can consist on one or more of
   our current "domains", for simplicity we assume that one leaf region
   corresponds to one current domain.

   The definition of a "domain" (leaf) here is viewed more from an
   administrative perspective, in which the "domain" is administered
   and controlled by one body.  This single-administration perspective
   is assumed both for multicasting and for key management.

   The group key management behavior in the current document is
   inspired by the work of [WGL98] which is based on a centralized
   server.  The current work extends it to cover multiple entities in a
   distributed fashion.

   The current document addresses group key management for multicast
   security.  The issue of how a cryptographic key is applied to data
   in a multicast group is not addressed, although the current document
   points to IPsec (ESP and AH) [KA98a, KA98b, KA98c] as a foremost
   candidate, depending on the multicast application type.  Although in
   the document a key is used to "encipher" the multicast data to
   control access by group members, the intent is clear that
   authentication-only multicast applications may also employ the
   current design.

   The current document seeks to cover both the one-to-many and many-
   to-many multicast application types.  Hence, the protocol has
   been described is the broadest way possible, without affecting the
   security of key management in general.






Hardjono, Cain, Monga                                         [Page 3]


Internet Draft      Intra-Domain GKM Protocol       November 1998


3. Architecture

   The current work aims to manage multicast group keys based
   on well-defined domains.  It also distinguishes between multicast
   groups for the purpose of payload delivery and for the purpose of
   key management.

   The current document is concerned with the correct and secure
   delivery of keys to members of a multicast group.  It does not
   prescribe how a key is to be used on the data being transmitted in
   the multicast group.  The reader is directed to methods such as
   IPsec ESP [KA98b] for concrete possibilities.


                   |--------------R/TE-------------|
                   |                               |
                   |              DKD      DMAAE   |
                   |                               |
                   | ----R---- ----R---- ----R---- |
                   | |       | |       | |       | |
                   | |  AKD  | |  AKD  | |  AKD  | |
                   | |       | |       | |       | |
                   | |        R         R        | |
                   | | m m m | | m m m | | m m m | |
                   | --------- --------- --------- |
                   |_______________________________|

           Figure 1: Intra-Domain Group Key Management Elements



3.1 Domains, Areas and Key Distributors

   At the domain-level, a Domain Key Distributor (DKD) entity is
   defined for the domain for the purpose of key management.

   In order to support multicast groups, the domain is divided into a
   number of administratively-scoped "areas" [Mey98].  A host-member of
   a multicast group is defined to reside within one (and only one) of
   these areas.  The purpose of placing host-members in areas is to
   achieve flexible and efficient key management, particularly in the
   face of the problem of changes (joins and leaves) in the membership
   of a multicast group.

   At the area level, an Area Key Distributor (AKD) entity is defined
   for each area for the purpose of key management.




Hardjono, Cain, Monga                                         [Page 4]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Depending on the address allocation approach (see Section 3.4), each
   area may be associated with one Area Multicast Address Allocation
   Entity (AMAAE), such the MAAS of [HTE98], from which the Area Key
   Distributor (AKD) of that area obtains area-wide multicast
   addresses.  In addition, at the domain-level, a Domain Multicast
   Address Allocation Entity (DMAAE) must exist to cater for the
   domain.

   Within the domain, all Key Distributors (the DKD and AKDs) are
   members of the domain-wide administratively-scoped multicast group,
   called the "All-KD-group", which does not extend beyond the domain
   and whose membership consists only of Key Distributors.

   The Domain Key Distributor (DKD) communicates to Area Key
   Distributors (AKD) either through secure one-to-one (unicast)
   communications or through the All-KD-group.  The All-KD-group is
   independent of other multicast groups and it exists even when there
   are no host-members of any multicast group in the domain.

   The Area Key Distributor (AKD) communicates to host-members residing
   in its area either through secure one-to-one (unicast)
   communications or through a special (ie. control) multicast group
   whose scope is limited to that area.

   Should a multicast group originate from outside the domain and
   should its traffic be enciphered under a foreign key, then
   Translating Entity(s) (TE), such as a border-router(s), must be
   specified in the domain.  In such a case, the Domain Key Distributor
   (DKD) is assumed to have a copy of the foreign key through other
   methods (unspecified).  The DKD will then supply the Translating
   Entity(s) with a copy of the foreign key and a copy of a new
   multicast key to be used on the traffic in the domain.


3.2 Trust Relationships

   The trust relationship in the current work revolves around the Key
   Distributors and does not extend beyond the domain.  All Key
   Distributors (DKD and AKDs) are configured and maintained by the
   human administration in the domain.  They must be implemented using
   the most secure technology available, since they represent the best
   point-of-attack.

   All entities trust the Domain Key Distributor (DKD) as the primary
   source of authentic parameters.  The DKD can in fact also take-on
   the role of a certification authority when the need arises.  The
   public-key of the DKD is well-known to (and/or is configured within)
   each host and within the Area Key Distributors (AKDs).


Hardjono, Cain, Monga                                         [Page 5]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   A host residing within an area trusts the Area Key Distributor (AKD)
   in that area.


3.3 Multicast Groups for Data and Control

   The current work employs administratively-scoped multicast
   groups for the purpose of key management.

   To distinguish these administratively-scoped multicast groups for
   control (ie. key management) from the multicast group for data, the
   latter will be referred to as "data multicast groups", "data-groups"
   or simply "multicast groups". A control-related group will be
   referred to as "control-multicast group" or simply "control-group".

   A "control-group" is an administratively-scoped multicast group
   which is area-wide. It is initiated/owned by the Area Key
   Distributor (AKD) of an area. The purpose of an area control-group
   is for key management relating to an associated data-multicast
   group.

   An area control-group associated with a data-multicast group exists
   so long as there are members of the corresponding data-multicast
   group in the area.  Once a data-multicast group ceases to have any
   members in an area, the Area Key Distributor (AKD) of that area may
   terminate that corresponding area control-group.

   A special control-group is the All-KD-group. This is an
   administratively-scoped multicast group which is domain-wide and
   consists only of the Domain Key Distributor (DKD) and Area Key
   Distributors (AKD). It has a fixed address and is initiated/owned by
   the Domain Key Distributor (DKD).  There is only one All-KD-group in
   a domain, and it is a permanent group, independent of whether any
   data multicast group members exists in the domain.  Unless
   specifically mentioned, in the remainder of this document all
   control-groups are area control-groups.

   Note that once a host (in an area within the domain) becomes a
   member of a multicast group, it also must become a member of one of
   the area control-groups of the area within which that host resides.
   This allows the Area Key Distributor (AKD) to communicate with the
   host-member through the area control-group.

   From the perspective of an Area Key Distributor (AKD) of an area,
   for a multicast group having a host-member in its area, the Key
   Distributor (AKD) must assign that host-member to one of the area
   control-groups in that area.



Hardjono, Cain, Monga                                         [Page 6]


Internet Draft        Intra-Domain GKM Protocol         November 1998


3.4 Keys: Multicast Groups and Control-Multicast Groups

   A multicast group is associated with a domain-wide Multicast-Key
   (MKey). The current work assumes that cryptographic keys are
   used for the encipherment of the multicast traffic as a method to
   provide receiver access-control, where only valid members of the
   multicast group is provided with a copy of the cryptographic key.
   This is true for data multicast groups and area control-groups.

   For each multicast group having a member in the domain, a unique
   Multicast-Key (MKey) is assigned by the Domain Key Distributor (DKD)
   for that multicast group.

   A multicast group having a member in an area in the domain is
   associated with one control-group in the area by the Area Key
   Distributor (AKD) of that area.  All traffic within an area control-
   group is enciphered in such a way that only the AKD of that area and
   the intended receivers of the traffic will be able to decipher the
   traffic.  The cryptographic key associated with an area control-
   group is referred to generally as the Area-Group-Key (AreaGroupKey).
   An Area-Group-Key is selected by the Area Key Distributor (AKD).
   The Area-Group-Key (AreaGroupKey) is unique for each (multicast
   group, control-group) pair.

   For the special All-KD-group, an All-KD-Key (AllKDKey) is assigned
   by the Domain Key Distributor (DKD) for the All-KD-group.

   Here, it is assumed (initially) that all payload
   related to a multicast group travelling within a domain is encrypted
   using the Multicast-Key (MKey).  Should the sender of the multicast
   group be located outside the domain, then a "Translating-Entity"
   (TE), such as the border-router of the domain, must be employed to
   decrypt the entering traffic (using some inter-domain cryptographic
   key) and to re-encrypt it using the Multicast-Key (MKey) assigned in
   the domain to that multicast group.  Similarly, the Translating-
   Entity must "translate" multicast group traffic (sent from a group
   member in the current domain) when the traffic leaves the domain.

   The "boot-strapping" process of each multicast group and control-
   group relies on the establishment of a Security Association (SA) and
   a shared private-key between a (candidate) member of the group with
   the Key Distributor (DKD or AKDs) that controls the group.  It is
   through this one-to-one secure channel that the parameters for the
   groups are then given to host-members by the Area Key Distributor in
   the case of the multicast group and area control groups, or to the
   Area Key Distributors (AKDs) by the Domain Key Distributor (DKD) in
   the case of the All-KD-group.



Hardjono, Cain, Monga                                         [Page 7]


Internet Draft        Intra-Domain GKM Protocol         November 1998


3.5 Control-Multicast Groups: Address Allocation

   Three possible approaches are available with regards to the use of
   area control-groups (corresponding to a given multicast group) for
   key management by the Area Key Distributor (AKD):

   (a) One control-group per area per multicast group:

       For each multicast group, having members in an area, a separate
       control-group is created within the area.

       Each separate area control-group is associated with a different
       Area-Group-Key.

       One disadvantage of this approach is the potential lack of
       multicast addresses within the area.  Another disadvantage is the
       waste of resource related to area-wide multicasting if the area
       only has very few members of the corresponding multicast group.
       This approach requires the presence of an Area Multicast Address
       Allocation Entity (AMAAE) in each area.

   (b) One control-group per area for all multicast groups:

       In this approach, for each multicast group, having members in an
       area, only one control-group is created within the area.  Hence,
       the area control-group is shared among members of different
       multicast groups.

       Although there is only one (shared) area control-group, a
       separate Area-Group-Key is used for each data multicast group.
       When the AKD wishes to communicate with members of a particular
       multicast group residing in its area, the AKD will encipher the
       communications using the appropriate Area-Group-Key.  Other non-
       intended recipients will also receive the enciphered packets, but
       will drop them since they will not be able to decipher them.

       The advantage of this approach is that there is only one control-
       group which can be long-lived and have a fixed address.  Having
       the fixed address obviates the Area Multicast Address Allocation
       Entity (AMAAE), thereby simplifying the entire design.

       The main disadvantage of this approach is that bandwidth within
       the area is wasted when the AKD is performing key management
       communications with only a small subset of group members residing
       in the area, since all other unconcerned members are receiving
       the (enciphered) packets and dropping them.  Another related
       disadvantage is increased opportunity for cryptanalysis of
       enciphered packets of control-groups, since unconcerned members
       are receiving these packets and may cryptanalyze them.

Hardjono, Cain, Monga                                         [Page 8]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   (c) One control-group per area for several multicast groups:

       This approach attempts to bring together the advantages of the
       previous two.  For a fixed number of multicast groups, having
       members in an area, a single control-group is created within the
       area.

       Thus, within a given area a set of N multicast addresses for N
       control-groups can be selected and fixed.  Each multicast group
       having (one or more members in an area) is then mapped to one of
       the N control-groups in that area (eg. by hashing the multicast
       group address).

       In terms of key management, each (multicast group, control-group)
       pair will be associated with a unique Area-Group-Key
       (AreaGroupKey).

       Thus, for example, a host who is a member of two multicast groups
       MG1 and MG2 may find that in its area both MG1 and MG2 are mapped
       into one control-group CG1, with two Area-Group-Keys AGK1 and
       AGK2 corresponding to the two multicast groups.  Hence, for the
       control-group CG1 the host must maintain the unique triplets
       (MG1, CG1, AGK1) and (MG2, CG1, AGK2).  The host must be able to
       distinguish control-group packets in CG1 corresponding to the two
       multicast groups, in order for it to apply the matching keys.
       Tagging methods within control-packets may be employed to achieve
       this effect, saving the host the effort of trying the keys.

       In this manner, the design is simplified by obviating the
       Area Multicast Address Allocation Entity (AMAAE) for each area,
       and the problem of unintended members receiving and dropping
       (enciphered) messages is also somewhat reduced.

   The current work will employ the third approach due to its
   simplicity.  We specify that an Area Key Distributor
   (AKD) maintains a mapping between a multicast group and its
   corresponding control-group in the area.  How this mapping is
   established is implementation-specific, and thus outside the scope
   of the document.  Furthermore, we assume that each
   control-group packet carries sufficient identification information
   relating to the multicast group to which it corresponds, thereby
   allowing non-intended receivers of the packets in the shared
   control-group to drop the packets without attempting to decrypt it.







Hardjono, Cain, Monga                                        [Page 9]


Internet Draft        Intra-Domain GKM Protocol         November 1998


3.6 Group Security Associations

   The IPsec security architecture [KA98a] defines the concept of a
   Security Association (SA) between two communicating parties. An SA
   is a simplex connection that affords security services to the
   traffic carried by it. An SA is uniquely identified by the triple
   consisting of the Security Parameter Index (SPI), an IP Destination
   Address and a security protocol identifier. Thus, for a two way
   communications, two Security Associations must be negotiated and
   established.

   The current work recognizes that for the many-to-many
   multicast applications the basic IPsec Security Association as a
   simplex connection does not suffice.  Hence, it uses the notion of a
   Multicast Group Security Association (GSA) derived from the simplex
   Security Association.  Note that the concept of a GSA for multicast
   has previously been describe, albeit briefly, in the IPsec security
   architecture document [KA98a] and other related documents.

   In the current document we assume that a Group Security
   Association (GSA) attributes is not negotiated between the
   communicating parties, but rather selected by one party. The entity
   that selects the GSA depends on the whether it is a multicast group
   or a control-group. All members of the group would then use the one
   same Group Security Parameter Index (GSPI) related to the GSA.
   Similarly, when a re-keying occurs, a new Group Security Parameter
   Index (GSPI) must selected for the GSA and a new key must be
   generated by one entity and delivered to the group members.

   The notion of a Group Security Association (GSA) selected by one
   entity departs from the existing IPsec definition and has
   implications on the ability of hosts to join multicast groups.
   Recall that in the two-party communication scenario, each party
   negotiates the Security Association (SA) depending on their
   cryptographic capability (eg. cryptographic algorithms available).
   In the case of a Group Security Association (GSA) selected by one
   entity, the required capability (eg. minimal algorithms) demanded of
   a potential member must be announced through other methods, such as
   through the multicast session description protocol or other
   protocols.  In this way, a multicast group initiator or owner can
   specify what cryptographic algorithm(s) can be used in the multicast
   group.  This approach is in-line with the one-to-many multicast
   applications (eg. pay per view service owners) and is deemed
   reasonable within the many-to-many multicast applications.






Hardjono, Cain, Monga                                        [Page 10]


Internet Draft        Intra-Domain GKM Protocol         November 1998


3.7 Secure Channels

   The general term "secure channel" is used in the remainder of the
   current document to mean communications between one sender and one
   receiver (unicast), with authenticity and confidentiality.  Secure
   channels here will be based on IPsec (AH and/or ESP) [KA98a].  The
   term implies the existence of a Secure Association (SA) and a
   private-key shared between the sender and receiver before the two
   begin communicating securely.  The IKE protocol [HC98] can be used
   to establish the Security Association and the shared private-key.

   Independent of the Group Security Association (GSA) for the
   multicast group, each host-member is assumed to have establish a
   Security Association (SA) and a shared private-key with the Area Key
   Distributor (AKD) of the area within which that host resides before
   the host joins any groups. Similarly, each Area Key Distributor
   (AKD) is assumed to have establish a Security Association (SA) and a
   shared private-key with the Domain Key Distributor (DKD) before the
   AKD serves any multicast groups.

   A "secure channel" between one sender and one receiver implies that
   the identity of the one is known to the other.  Hence, in
   communicating via a secure channel with a Key Distributor (AKD or
   DKD) a host-member is by definition identified and authenticated by
   the Key Distributor, and vice versa.

3.8 Periodic Re-Keying

   It is commonly accepted that the longer a cryptographic key is being
   employed, the higher the chances of that key being successfully
   cryptanalyzed by an attacker (who is assumed to have collected
   ciphertext of messages encrypted using the key).  This is
   particularly true for keys of symmetric cryptosystems.

   The current document recognizes the importance of periodic re-
   keying and attempts to provide a workable solution in the face of
   the issue of re-keying due to a new host-member joining (backward
   confidentiality) and the issue of an existing member leaving or
   being ejected (forward confidentiality).

   The approach of re-keying only when the group membership changes
   suffers from the possibility that the membership does not in fact
   change over long periods, and thus opening the possibility of
   cryptanalysis of the multicast key.

   Hence, the current design adopts the underlying philosophy
   that periodic re-keying is necessary (even if the membership of the
   multicast group does not change), independent of whether or not


Hardjono, Cain, Monga                                        [Page 11]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   immediate re-keying is performed when a host joins/leaves the
   multicast group.  In this way, the design provides flexibility
   for the implementor to be "strict" (immediate re-key at each
   membership change) or to be "loose" (wait until next periodic re-
   key) with regards to multicast key re-keying.

   In the following discussions on the group key management protocols,
   the current work will observe the strict re-keying policy (ie.
   immediate re-key at each membership change) since it represents a
   more complex case.  The loose re-keying can be established by
   removing some steps from the protocols and executing other steps
   only when the designated periodic re-keying occurs. Periodic re-
   keying in the multicast group will be determined by the Domain Key
   Distributor (DKD) and implemented with the aid of the Area Key
   Distributors (AKDs).  Periodic re-keying in a control-group (in an
   area) associated with a multicast group will be determined by the
   Area Key Distributor (AKD) of that area.

   From the perspective of multicast reliability, the approach of using
   periodic re-keying allows each Key Distributor (AKD and DKD) to
   prepare for the re-keying, hence providing them with a window of
   opportunity to obtain the next key.  Having this window of
   opportunity provides a context within which reliability mechanisms
   for key delivery can be established, either through existing
   reliable multicast protocols or through mechanisms specific to key
   management.  In either case, the current document recognizes that
   reliability is paramount to group key management if multicast
   security is to be achieved.


3.9 Arrangement of Keys in the Domain

   The current protocol aims at delivering a multicast key, in the
   form of a private-key (symmetric cryptography), to members of a
   multicast group or a control-group.  The fact that a host holds a
   copy of the multicast key is taken to mean that the host has
   previously been correctly identified by its Area Key Distributor
   (AKD) and that it has established a Security Association with its
   AKD.  The private-key used in a multicast group or a control-group
   affords confidentiality and "group authentication" in the sense that
   the source of any information enciphered under the key is a valid
   member of the group.  Note, that this level of authentication (group
   authentication) is implicit and does not provide irrefutable proof
   of the singular identity of the sender.

   The current document recognizes the benefits of a public key
   certification infrastructure and is open to such an infrastructure
   being deployed, with each entity being assigned a public key.


Hardjono, Cain, Monga                                        [Page 12]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   However, in order to render the protocol immediately deployable
   in the near future, we assume that public keys are
   assigned only to the Key Distributors (DKD and AKDs) and the Domain
   Multicast Address Allocation Entity (DMAAE) to allow them to
   digitally-sign information that is to be sent through the multicast
   group or the control-groups.  These public keys are valid only
   within the domain, and may not be recognized outside the domain
   (unless a certification infrastructure is employed).

3.9.1 Public Keys

   The current protocol assumes that all Key Distributors (DKD and
   AKDs) are assigned public-keys (asymmetric cryptography) in order
   for these Key Distributors to digitally-sign certain information in
   such a way that it is verifiable by all hosts in the domain.

   A host-member residing in area is assumed to have a copy of the
   public-key of its Area Key Distributor (AKD) and the public-key of
   the Domain Key Distributor (DKD).

   An Area Key Distributor (AKD) is assumed to have a copy of the
   public-key of the Domain Key Distributor (DKD).  An Area Key
   Distributor (AKD) may obtain the public-keys of other Area Key
   Distributors from the Domain Key Distributor (DKD), with the DKD
   acting as a domain-wide certification authority.

   Al the very least, the public key of the Domain Key Distributor
   (DKD) must be advertised in a tamper-proof manner (eg. printed or
   manually configured) to allow it to be used to vouch for the public
   keys of the Area Key Distributors (AKDs).


3.9.2 Shared Private-Keys

   Three types of group-oriented (ie. shared by a group) private-keys
   (symmetric cryptography) are used:

   -  Multicast-Key (MKey): this is the private-key associated with a
      multicast group that is used by all the group members in the
      domain to encrypt/decrypt the multicast traffic in the multicast
      group. This key is generated by the Domain Key Distributor (DKD)
      of the domain.

      This key is delivered securely to each Area Key Distributor
      (AKD), who will in turn deliver the key securely to each group
      member in their area.




Hardjono, Cain, Monga                                        [Page 13]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   -  Area-Group-Key (AreaGroupKey): this is the private-key associated
      with the (multicast group, control-group) pair, and used to
      encipher the communications in the control-group.  An Area-Group-
      Key is generated by the Area Key Distributor (AKD) of that area
      and delivered to each member through a secure-channel. An Area-
      Group-Key is known only to the AKD of an area and the members (of
      the corresponding multicast group) residing in that area.

   -  All-KD-Key (AllKDKey): this is the private-key associated with
      the special All-KD-group.  All the Area Key Distributors (AKDs)
      and the Domain Key Distributor (DKD) hold a copy of the All-KD-
      Key. This key is generated by the Domain Key Distributor (DKD)
      and delivered to each AKD through a secure-channel. This key is
      used to encipher the communications within the All-KD-group.


   Two types of pair-oriented private-key are used in the current
   work:

   -  Member-Private-Key (MbrPKey): Each host-member in an area pair-
      wise shares a Security Association (SA) and a Member-Private-Key
      (MbrPKey) with the Area Key Distributor (AKD) of that area.  The
      Security Association (SA) and the Member-Private-Key (MbrPKey)
      are long-term and must be established before the host-member
      joins (or initiates) any multicast groups and is given a copy of
      that group's Multicast-Key (MKey). There is only one SA and one
      MbrPKey shared between the host-member and the Area Key
      Distributor (AKD), independent of the number of multicast groups
      to which that host-member belongs.

   -  AKD-Private-Key (AKDPKey):  Each Area Key Distributor (AKD) of an
      area pair-wise shares a Security Association (SA) and a AKD-
      Private-Key with the Domain Key Distributor (DKD). The Security
      Association and the AKD-Private-Key (AKDPKey) are long-term and
      must be established before any multicast group exists in the
      domain.


   In summary, the private-key arrangement from the point of view of
   entities is as follows.

   Hosts:
      A host-member of a multicast group residing in an area holds a
      copy of the Multicast-Key (MKey) and a copy of the Area-Group-Key
      (AreaGroupKey) corresponding to the (multicast group, control-
      group) pair. In addition, the host-member also holds its own
      Member Private-Key (MbrPKey) independent of any multicast groups.



Hardjono, Cain, Monga                                        [Page 14]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Area Key Distributors (AKD):
      For each multicast group having a member in an area, the Area Key
      Distributor (AKD) of the area holds a copy of the Multicast-Key
      (MKey) of the multicast group and holds a unique Area-Group-Key
      (AreaGroupKey) corresponding to each (multicast group, control-
      group) pair.

      In addition, an AKD also holds a copy of the current All-KD-Key
      (AllKDKey), its own AKD-Private-Key (AKDPKey) and a copy of the
      Member Private-Key (MbrPKey) of each member residing in its area.
      These (the AllKDKey, AKDPKey and MbrPKeys) are independent of any
      multicast groups to which a resident host-member belongs.

   Domain Key Distributor (DKD):
      The Domain Key Distributor (DKD) of a given domain holds the
      Multicast-Key (MKey) for each multicast group, a copy of the
      current All-KD-Key (AllKDKey), and a copy of the AKD-Private-Key
      (AKDPKey) of each Area Key Distributor (AKD) in the domain.

   --------------------------------------------------------
        Multicast access purposes: Multicast Key (MKey)
   ========================================================
                      Control purposes:
   --------------------------------------------------------
             Pair-wise Shared          Group-wise shared
         -----------------------     -----------------------
   DKD    Key: AKD-Private-Key        Key: All-KD-Key
   with   - Long-term                 - Medium-term
   AKD    - Independent of groups     - Independent of groups


   AKD    Key: Member-Private-Key     Key: Area-Group-Key
   with   - Long-term                 - Medium-term
   Hosts  - Independent of groups     - N per area
   --------------------------------------------------------
   Table 1:  Key arrangement




   Note that the Domain Key Distributor (DKD) does not hold copies of
   the Member-Private-Keys (MbrPKey).  This is in contrast to the
   approach in [WGL98] in which a central server holds the private-keys
   of all members in the multicast group.  If a host is in need of
   communicating directly through a secure channel to the Domain Key
   Distributor (DKD) or any other entity, then the host must establish
   a Security Association and a shared private-key with the DKD or
   entity.


Hardjono, Cain, Monga                                        [Page 15]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Although currently not prescribed, depending on the reliability
   mechanism to be employed, the Domain Key Distributor (DKD) may hold
   copies of the Area-Group-Key (AreaGroupKey) within each area in the
   domain.  However, the intent is clear that the Domain Key
   Distributor (DKD) is not to replace any Area Key Distributor (AKD).

   Each key is assumed to be associated with a Key Identifier which
   uniquely identifies the cryptographic key is question.


4. Creation of New Multicast Groups

   Two possible scenarios with respect to new multicast groups exist.
   In the first case, the new multicast group is initiated from the
   current domain.  In the second case, the multicast group was
   initiated from outside the domain and has existed before a host in
   the current domain joins it.


4.1 Initiation of New Internal-Origin Groups

   When a host ("Initiator") in the current domain wishes to commence a
   new multicast group, it must first initiate the creation of the
   multicast group via the underlying multicast routing protocol and
   some membership protocol (eg. IGMP).

   If it has not already done so, the initiator host must establish a
   Security Association (SA) and a shared Member Private-Key (MbrPKey)
   with its Area Key Distributor (AKD).

   The commencement of a new multicast group from the perspective of
   group key management is described as follows, consisting two
   inseparable parts. The first part is the generation and distribution
   of the multicast-key, while the second part is the generation and
   distribution of the Area-Group-Key.

   Protocol-I: Generation and distribution of the multicast key

   Step N1:  The initiator in an area within the current domain creates
             a new domain-wide multicast group (method unspecified) with
             the aid of the Domain Multicast Address Allocation Entity
             (DMAAE) at the domain level.  The DMAAE returns to the
             initiator the following parameters, digitally signed by the
             DMAAE:
                - a multicast group address
                - a multicast group identity
                - the identity of the initiator (as group owner)



Hardjono, Cain, Monga                                        [Page 16]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Step N2:  The initiator selects the Multicast Group Security
             Association (MGSA) attributes (without the GSPI).  The
             initiator then authentically notifies its Area Key
             Distributor (AKD) about the new multicast group and requests
             a new multicast key for the new multicast group.  The message
             is sent through a secure channel and contains the signed
             parameters from the DMAAE, the MGSA and an Access Control
             List (ACL):
                - the multicast group address
                - the multicast group identity
                - the identity of the initiator
                - the Multicast Group Security Association (MGSA)
                - the time-period for re-keying cycle
                - an Access Control List (ACL) generated by the initiator

   Step N3:  The Area Key Distributor (AKD) of the initiator receives
             the request from the initiator, notifies the Domain Key
             Distributor (DKD) about the new multicast group and passes
             the request message to the DKD through a secure channel.

   Step N4:  The Domain Key Distributor (DKD) receives the request and
             performs the following steps:

      Step N4.1: The Domain Key Distributor (DKD) verifies the digital
             signature of the Domain Multicast Address Allocation Entity
             (DMAAE).

      Step N4.2: The Domain Key Distributor (DKD) generates:
                - a Group Security Parameter Index (GSPI) for the MGSA
                - a Multicast-Key (MKey)
                - a multicast key identifier MKeyID
             based on the MGSA selected by the initiator.

      Step N4.3: The Domain Key Distributor (DKD) digitally-signs the
             multicast group parameters:
                - the multicast group address
                - the multicast group identity
                - the identity of the initiator
                - the time-period for re-keying cycle
                - the Access Control List (ACL)
                - the Multicast Group Security Association (MGSA)
                - the Multicast-Key (MKey)
                - the multicast key identifier MKeyID
                - a timestamp






Hardjono, Cain, Monga                                        [Page 17]


Internet Draft        Intra-Domain GKM Protocol         November 1998


      Step N4.4: The Domain Key Distributor (DKD) securely delivers the
             signed multicast group parameters to each Area Key
             Distributor (AKD), either through the All-KD-group (encrypted
             under the All-KD-Key) or through a one-to-one secure channel
             to each Area Key Distributor (AKD).  This message also serves
             as an acknowledgment to the Area Key Distributor (AKD) of the
             initiator.

   The process of the creation of the All-KD-group is similar to
   Protocol-I, with the exception that the multicast address is fixed
   and the DKD selects the Group Security Association (GSA) for the
   All-KD-group.  The DKD also generates the All-KD-Key (AllKDKey) and
   the All-KD-Key identifier AllKDKeyID for the multicast group, based
   on the MGSA selected by the DKD.


   Protocol-II Generation and distribution of the area key

   Step N5:  Upon receiving the signed multicast group parameters from
             the DKD, the Area Key Distributor (AKD) of the initiator
             performs the following steps:

      Step N5.1: The Area Key Distributor (AKD) maps the multicast group
             address to one of the area control-group addresses.  The AKD
             maintains the following information for the given multicast
             group:
                - an area control-group address
                - an area control-group identity
                - the identity of the AKD (as group owner)

      Step N5.2: The Area Key Distributor (AKD) selects the Area Group
             Security Association (AGSA) attributes and generates:
                - a Group Security Parameter Index (GSPI) for the AGSA
                - an Area-Group-Key (AreaGroupKey)
                - an area key identifier AkeyID
             based on the AGSA selected by the AKD.

      Step N5.3: The Area Key Distributor (AKD) digitally-signs the area
             control-group parameters:
                - the multicast group address
                - the multicast group identity
                - the area control-group address
                - the area control-group identity
                - the identity of the AKD
                - the time-period for re-keying cycle
                - the Area Group Security Association (AGSA)
                - the Area-Group-Key (AreaGroupKey)
                - the area key identifier AKeyID
                - a timestamp

Hardjono, Cain, Monga                                        [Page 18]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Step N6:  The Area Key Distributor (AKD) of the initiator returns to
             the initiator, through a secure channel:
                - the multicast group parameters (from Step N4) without the
                  ACL, signed by the AKD
                - the area control-group parameters (from Step N5) signed by
                  the AKD

   Step N7:  The initiator joins the area control-group (method
             unspecified).

   Note that Step N4 above effectively provides each and every Area Key
   Distributor (AKD) in the domain with the necessary parameters
   related to the multicast group, regardless of whether or not the
   area of an AKD actually contains any members of the multicast group.
   This approach is chosen to allow for quick response by an AKD should
   other hosts in other areas wish to join the multicast group. In
   addition, the approach leaves open the possibility of the AKDs to
   participate in the reliability mechanisms to be employed
   (ie. as backups), since each of the AKDs holds the
   parameters related to every multicast group in the domain.

   The multicast group parameters are digitally signed by Domain Key
   Distributor (DKD) in order to aid reliability protocols.  That is,
   in the case that the DKD goes down, the parameters can be obtained
   by one AKD from another AKD through a one-to-one secure channel,
   with the recipient being able to verify the authenticity of the
   parameters as signed by the DKD.


4.2  Membership to External-Origin Groups

   Although the current design focuses on intra-domain group key
   management, it does not preclude the possibility of a multicast
   group originated by a host external to the domain.  However, unlike
   multicast groups which originate from a host within the domain and
   which is therefore known to the Domain Key Distributor (DKD),
   multicast groups which originate from outside a domain must be
   explicitly made known to the DKD.

   Since the current protocol views the multicast distribution tree
   used by a multicast routing protocol as a construct outside its
   control, the Domain Key Distributor (DKD) can be notified (when a
   host in domain joins the external-origin multicast group) through a
   number of ways, among others:
       - The joining host can explicitly notify its Area Key Distributor
         (AKD) or the Domain Key Distributor (DKD).




Hardjono, Cain, Monga                                        [Page 19]


Internet Draft        Intra-Domain GKM Protocol         November 1998


       - A domain border-router can notify the Domain Key Distributor
         (DKD) when it senses a request from a host to join the
         distribution tree
       - The Domain Key Distributor (DKD) can by default be a member of
         all external-origin multicast groups whose distribution tree
         extend into the domain.

   However, from the perspective of group key management, the Domain
   Key Distributor (DKD) only plays a role when the external-origin
   multicast traffic is enciphered for access control and the owner of
   the group requires the aid of the DKD to enforce access control.
   Hence, in this situation the DKD must obtain a copy of the key used
   to encipher the multicast traffic as it enters the domain and assign
   a new multicast key for that same traffic within its domain (method
   unspecified).

   The current document leaves the precise description and
   specification of the group key management for external-origin
   multicast groups to a later date.


5. Re-Keying Approach

   The basic approach to re-keying is discussed first
   in order to simplify later discussions on re-keying
   due to membership changes and due to periodic re-keying.  For
   simplicity, the process is view from the perspective of the Domain
   Key Distributor (DKD) and one Area Key Distributor (AKD).

   It is the DKD who initiates and controls all re-keying events in the
   domain related to multicast groups.  Re-keying of Area-Group-Keys of
   area control-groups are initiated and controlled by the respective
   Area Key Distributors (AKD).

   Note that it is important to have "cycle-over" period in which all
   host-members are in possession of the new re-key parameters, but is
   still employing the existing/old parameters.


5.1 Re-Keying of Multicast Keys

   In the following, all re-key steps are related to a given multicast
   group.  The protocol is initiated and controlled by the Domain Key
   Distributor (DKD).






Hardjono, Cain, Monga                                        [Page 20]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Protocol-III: Re-keying the multicast key

   Step RM1: The Domain Key Distributor (DKD) issues an authentic
             prepare-to-rekey message to all Area Key Distributors (AKD)
             through the All-KD-group.  The message contains:
                - an existing multicast group address
                - a existing multicast group identity
             of the multicast group being re-keyed

   Step RM2: The Domain Key Distributor (DKD) generates:
                - a new Group Security Parameter Index (GSPI) for the MGSA
                - a new Multicast-Key (MKey)
                - a new multicast key identifier MKeyID
             based on the MGSA selected by the initiator.

   Step RM3: The Domain Key Distributor (DKD) digitally-signs the
             multicast group parameters:
                - the existing multicast group address
                - the existing multicast group identity
                - the Multicast Group Security Association (MGSA)
                - the new Multicast-Key (MKey)
                - the new multicast key identifier MKeyID
                - a timestamp

   Step RM4: The Domain Key Distributor (DKD) securely delivers the
             signed parameters to each Area Key Distributor (AKD), either
             through the All-KD-group (encrypted under the All-KD-Key) or
             through a one-to-one secure channel to each Area Key
             Distributor (AKD).

   Step RM5: The Area Key Distributor (AKD) securely delivers the
             signed multicast group parameters to each host-member (of the
             multicast group) in its area using one of the following
             methods (depending on the cause of the re-keying event):
             (a) through the area control-group related to the multicast
                 group (encrypted under the AreaGroupKey)
             (b) through a one-to-one secure channel to each concerned
                 host-member.


5.2 Re-Keying of Area Keys

   In the following, all re-key steps by the Area Key Distributor (AKD)
   are related to a given multicast group.  The protocol is initiated
   and controlled by the Area Key Distributor (AKD).





Hardjono, Cain, Monga                                        [Page 21]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Protocol-IV: Re-keying the area key

   Step RA1: The Area Key Distributor (AKD) issues an authentic
             prepare-to-rekey message to all members of the multicast
             group within the area through the relevant area control-
             group.  The message contains:
                - an existing area control-group address
                - an existing area control-group identity
             of the area control-group being re-keyed

   Step RA2: The Area Key Distributor (AKD) generates:
                - a new Group Security Parameter Index (GSPI) for the AGSA
                - a new Area-Group-Key (AreaGroupKey)
                - a new area key identifier AkeyID
             based on the AGSA selected by the AKD.

   Step RA3: The Area Key Distributor (AKD) digitally-signs the area
             control-group parameters:
                - the existing area control-group address
                - the existing area control-group identity
                - the Area Group Security Association (AGSA)
                - the new Area-Group-Key (AreaGroupKey)
                - the new area key identifier AKeyID
                - a timestamp

   Step RA4: The Area Key Distributor (AKD) securely delivers the
             signed control-group parameters to each host-member (of the
             multicast group) in its area, using one of the following
             methods (depending on the cause of the re-keying event):
             (a) through the area control-group related to the multicast
                 group (encrypted under the old/current AreaGroupKey)
             (b) through a one-to-one secure channel to each concerned
                 host-member.


5.3 Re-Keying of the All-KD-Key

   The following describes the protocol to be employed when the All-KD-
   Key (AllKDKey) is to be re-keyed.  All the Area Key Distributors
   (AKDs) and the Domain Key Distributor (DKD) share an All-KD-Key.
   This key is used to encrypt traffic within the All-KD-group.  Note,
   that unlike host-members, Key Distributors never leave the All-KD-
   group, and hence its membership is static.







Hardjono, Cain, Monga                                        [Page 22]


Internet Draft        Intra-Domain GKM Protocol       November 1998


   Protocol-V: Re-keying the All-KD-Key

   Step RK1: The Domain Key Distributor (DKD) issues an authentic
             prepare-to-rekey message to all Area Key Distributors (AKD)
             through the All-KD-group.  The message contains:
                - the existing All-KD-group address
                - the existing All-KD-group identity

   Step RK2: The Domain Key Distributor (DKD) generates:
                - a new Group Security Parameter Index (GSPI) for the MGSA
                - a new All-KD-Key (AllKDKey)
                - a new All-KD-Key identifier AllKDKeyID
             based on the MGSA selected by the DKD

   Step RK3: The Domain Key Distributor (DKD) digitally-signs the All-
             KD-group parameters:
                - the existing multicast group address
                - the existing multicast group identity
                - the Multicast Group Security Association (MGSA)
                - the new All-KD-Key (AllKDKey)
                - the new All-KD-Key identifier (AllKDKeyID)
                - a timestamp

   Step RK4: The Domain Key Distributor (DKD) securely delivers the
             signed All-KD-group parameters to each Area Key Distributor
             (AKD) using one of the following methods, depending on the
             status of the AKD and the network condition:
             (a) through the All-KD-group (encrypted under the
                 existing/old All-KD-Key)
             (b) through a one-to-one secure channel to each Area Key
                 Distributor (AKD).


6. Hosts Joining a Multicast Group

   When a host within a domain wishes to join a multicast group having
   already (at least) a member in the domain, the two possible
   approaches can be adopted in admitting the host to become a group
   member.  In the first case, the host is disallowed from accessing
   (reading) traffic previous to its joining the group.  In the second
   case, no such access restriction apply.  The choice between the two
   approaches is dictated by policy, and hence beyond the scope of
   the current document.

   In the following, the strict re-keying policy is adopted, in which a
   re-keying of the Multicast-Key and the re-keying of the AreaGroupKey
   (of the area within which the new host joins) is conducted


Hardjono, Cain, Monga                                        [Page 23]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   immediately. In the loose re-keying policy, the task is postponed
   until the next periodic re-keying, at which point the new member is
   able access (decipher) the data of the multicast group.

   In the following, it is assumed that when a host in an area (first
   member or otherwise) joins a multicast group the Area Key
   Distributor (AKD) has already created the necessary area control-
   groups in its area. To conserve resources, an AKD may postpone the
   control-group creation (corresponding to a given multicast group)
   until such time that a first member of the multicast group appears
   in its area.

6.1 Joining with Backward Confidentiality

   When a new host joining a multicast group is to be prevented from
   accessing (reading) previous traffic (which it may have intercepted
   and stored), then Multicast-Key (MKey) of the multicast group in the
   domain must be re-keyed each time a host joins the multicast group.

   Note that even when a host is the first member of a multicast group
   in its area, all the other areas having a member must be re-keyed to
   reduce the possibility of that new host having access to previous
   traffic which it obtained (intercepted) in other areas.

Protocol-VI: Host joining with backward confidentiality

   Step JB1: The host sends an authentic join-request message for the
             multicast group to its Area Key Distributor (AKD).

   Step JB2: The Area Key Distributor (AKD) checks the host against the
             Access Control List (ACL) of the multicast group.  If the
             host is permitted to join, then the Area Key Distributor
             (AKD) authentically notifies the Domain Key Distributor (DKD)
             and the other Area Key Distributors (AKD) of the membership
             change (new host-member).  Otherwise, the AKD returns a join-
             reject message to the host

   Step JB3: The Domain Key Distributor (DKD) initiates an immediate
             re-keying (Protocol-III: Re-keying the multicast key).  This
             results in all Area Key Distributor (AKD) and all existing
             members of the multicast group obtaining the following
             multicast group parameters:
                - the existing multicast group address
                - the existing multicast group identity
                - the Multicast Group Security Association (MGSA)
                - the new Multicast-Key (MKey)
                - the new multicast key identifier MKeyID
                - a timestamp


Hardjono, Cain, Monga                                        [Page 24]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Step JB4: The Area Key Distributor (AKD) of the area (within which
             the host resides) must re-key its Area-Group-Key, and thus
             generates:
                - a new Group Security Parameter Index (GSPI) for the AGSA
                - a new Area-Group-Key (AreaGroupKey)
                - a new area key identifier AkeyID
             based on the AGSA selected by the AKD.

   Step JB5: The Area Key Distributor (AKD) digitally signs the area
             control-group parameters:
                - the existing area control-group address
                - the existing area control-group identity
                - the Multicast Group Security Association (MGSA)
                - the new Area-Group-Key (AreaGroupKey)
                - the new area key identifier AKeyID
                - a timestamp

   Step JB6: If there are existing host-members in the area, the Area
             Key Distributor (AKD) securely delivers the signed control-
             group parameters to each existing host-member (of the
             multicast group) in its area, using one of the following
             methods:
             (a) through the area control-group related to the multicast
                 group (encrypted under the old/current AreaGroupKey)
             (b) through a one-to-one secure channel to each existing
                 host-member.

   Step JB7: The Area Key Distributor (AKD) of the new host-member
             securely delivers the signed multicast group parameters (from
             Step JB3) and the signed control-group parameters (from Step
             JB5) to the new host-member through a one-to-one secure
             channel to the new host-member.

   Step JB8: The new host joins the multicast group (method
             unspecified).

   Step JB9: The new host joins the area control-group (method
             unspecified).


6.2 Joining Without Backward Confidentiality

   Here, when a host joins a multicast group, the Multicast-Key need
   not be re-keyed since backward confidentiality is not required.  The
   Area Key Distributor (AKD) of the host is already in possession of
   all the parameters related to the multicast group.




Hardjono, Cain, Monga                                        [Page 25]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Protocol-VII: Host joining without backward confidentiality

   Step JW1: The host sends an authentic join-request message for the
             multicast group to its Area Key Distributor (AKD).

   Step JW2: The Area Key Distributor (AKD) checks the host against the
             Access Control List (ACL) of the multicast group.  If the
             host is permitted to join, then the Area Key Distributor
             (AKD) proceeds with the next step, otherwise it returns a
             join-reject message to the host.

   Step JW3: The Area Key Distributor (AKD) looks-up the following
             multicast group parameters which it previously digitally-
             signed:
                - the existing multicast group address
                - the existing multicast group identity
                - the Multicast Group Security Association (MGSA)
                - the new Multicast-Key (MKey)
                - the new multicast key identifier MKeyID
                - a timestamp

   Step JW4: The Area Key Distributor (AKD) looks-up the following
             control-group parameters which it previously digitally-
             signed:
                - the existing area control-group address
                - the existing area control-group identity
                - the Multicast Group Security Association (MGSA)
                - the existing Area-Group-Key (AreaGroupKey)
                - the existing area key identifier AKeyID
                - a timestamp

   Step JW5: The Area Key Distributor (AKD) of the new host-member
             securely delivers the signed multicast group parameters (from
             Step JW3) and the signed control-group parameters (from Step
             JW4) to the new host-member through a one-to-one secure
             channel to the new host-member.

   Step JW6: The new host joins the multicast group (method
             unspecified).

   Step JW7: The new host joins the area control-group (method
             unspecified).








Hardjono, Cain, Monga                                        [Page 26]


Internet Draft        Intra-Domain GKM Protocol         November 1998


7. Host Leaving a Multicast Group

   The case of a host leaving a multicast group can be caused by a
   number of reasons depending on the policy dictating group membership
   and on the multicast application in question.

   From the perspective of the current design, re-keying must be
   conducted to preserve forward confidentiality.  That is, re-keying
   must be conducted to prevent the ex-member from further accessing
   (deciphering) the data in the multicast group, even if the ex-member
   persists in being a part of the multicast distribution tree.

   In the following, the strict re-keying policy is adopted, in which a
   re-keying of the Multicast-Key and the re-keying of the Area-Group-
   Key (AreaGroupKey) of the area within which the new host joins are
   conducted immediately. In the loose re-keying policy, the task is
   postponed until the next periodic re-keying, at which point the ex-
   member ceases to be able to decipher traffic in the multicast group
   and its corresponding control-group in the area.

   Note that in the current design, when a host leaves a
   multicast group it must also (by default) depart from the associated
   control-group.  In general, it makes no sense for a host to join a
   control-group without joining the corresponding multicast group.

   Protocol VIII: Host leaving a multicast group and control-group

   Step LB1: The leaving-host sends an authentic leave-request message
             for the multicast group to its Area Key Distributor (AKD).
             Alternatively, the Domain Key Distributor (DKD) notifies the
             AKD through an authentic eject-host-request message to the
             AKD.

   Step LB2: The Domain Key Distributor (DKD) of the affected area
             authentically notifies the other Area Key Distributors (AKD)
             of the membership change (host-member leaving).

   Step LB3: The Domain Key Distributor (DKD) initiates an immediate
             re-keying (Protocol-III: Re-keying the multicast key).  This
             results in all Area Key Distributors (AKDs) and all host-
             members of the multicast group, except host-members in the
             affected area, obtaining the following multicast group
             parameters:
                - the existing multicast group address
                - the existing multicast group identity
                - the Multicast Group Security Association (MGSA)
                - the new Multicast-Key (MKey)
                - the new multicast key identifier MKeyID
                - a timestamp

Hardjono, Cain, Monga                                        [Page 27]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   Step LB4: The Area Key Distributor (AKD) of the affected area
             (within which the leaving-host resides) must re-key its Area-
             Group-Key, and thus generates:
                - a new Group Security Parameter Index (GSPI) for the AGSA
                - a new Area-Group-Key (AreaGroupKey)
                - a new area key identifier AkeyID
             based on the AGSA selected by the AKD.

   Step LB5: The Area Key Distributor (AKD) digitally signs the area
             control-group parameters:
                - the existing area control-group address
                - the existing area control-group identity
                - the Multicast Group Security Association (MGSA)
                - the new Area-Group-Key (AreaGroupKey)
                - the new area key identifier AKeyID
                - a timestamp
             and digitally-signs the multicast group parameters that the
             AKD received from the DKD in Step LB3:
                - the existing multicast group address
                - the existing multicast group identity
                - the Multicast Group Security Association (MGSA)
                - the new Multicast-Key (MKey)
                - the new multicast key identifier MKeyID
                - a timestamp

   Step LB6: The Area Key Distributor (AKD) securely delivers the
             signed multicast group parameters and control-group
             parameters to each remaining host-member (of the multicast
             group) in its area, through a one-to-one secure channel to
             each existing host-member.

   Step LB7: The leaving-host leaves the multicast group (method
             unspecified).

   Step LB8: The leaving-host leaves the area control-group (method
             unspecified).


8. Reliability in Key Management

   The current document recognizes that key management be conducted
   in a reliable manner, due to the sensitivity of cryptographic keys
   and the basic necessity that a host-member obtain the multicast key
   before it can access (decipher) the multicast data. Reliability is
   also important in the re-keying of the keys used in the multicast
   group and in the area control-groups.  This is true particularly if
   in the re-keying process, the control-group itself is used to



Hardjono, Cain, Monga                                        [Page 28]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   transmit the new parameters (for either the multicast group or the
   same control-group) to the members of the group.

   However, the current document views reliability of transmission,
   particularly in the control-groups, as more of a multicast-
   reliability issue.  That is, reliability should not be expected from
   and should not be part of key management.  This is also true for the
   one-to-one "secure channels", in which confidential and authentic
   communications is created between a sender and a receiver through
   the previously-established Security Association (SA) and the shared
   private-key.

   Note that in the re-keying of a Multicast-Key (MKey), it is
   important that each Area Key Distributor (AKD) first reliably
   obtains the new parameters (including the new key) of the multicast
   group.  This is because without the new parameters, the AKD will not
   be able to even begin to re-key its area.  Once each AKD obtains the
   new parameters of the multicast group, the re-key of the Multicast-
   Key in each area is independent of one another.

   The current work currently does not specify how or what
   manner reliability in key management is to be achieved.  However,
   when a control-group (either the All-KD-group or an area control-
   group) is used for key management from a sender to a number of
   recipients (eg. delivery of new key and new parameters) several
   basic approaches can be used:

   (a) ACKs from members

   When a control-group is used to transmit re-keying parameters, the
   recipients simply return an acknowledgment (ACK) to the Key
   Distributor through the secure channel previously established with
   the Key Distributor.  Should the Key Distributor fail to receive
   such an ACK from a recipient within specified time, it will then
   query the recipient through the secure channel previously
   established.  Depending on the frequency of key management and the
   number of host-members, this approach may cause an ACK-implosion on
   the AKDs.

   (b) Timeouts

   When some period after a prepare-to-rekey message is received, some
   recipients fail to receive the actual new key and parameters through
   the control-group, those recipients query the sender (AKD or DKD).

   When nothing is heard after both the due time for the prepare-to-
   rekey message and due time for the actual key/parameters to be
   received, the recipients query the sender (AKD or DKD).


Hardjono, Cain, Monga                                        [Page 29]


Internet Draft        Intra-Domain GKM Protocol         November 1998


   (c) Explicit Reliable Multicast (RM) protocol

   Employ a specific RM protocol to establish reliability within the
   All-KD-group and/or the area control-groups.  Each control-group can
   in fact employ different RM protocols.



9. Packet Formats

   To be decided.


10. References

   [HCD98] T. Hardjono, B. Cain and N. Doraswamy, "A Framework for
   Group Key Management for Multicast Security", Internet Draft, July
   1998.

   [HC98] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)",
   Internet Draft, June 1998.

   [WGL98] C. K. Wong, M. Gouda and S. Lam, "Secure Group
   Communications Using Key Graphs", in Proceedings of SIGCOMM'98.

   [KA98a] S. Kent and R. Atkinson, "Security Architecture for the
   Internet Protocol", IETF, RFC 1825, 1998.

   [KA98b] S. Kent and R. Atkinson, "IP Encapsulating Security Payload
   (ESP)", Internet Draft, July 1998.

   [KA98c] S. Kent and R. Atkinson, "IP Authentication Header",
   Internet Draft, July 1998.

   [Mey98] D. Meyer, "Administratively Scoped IP Multicast", IETF, RFC
   2365, July 1998.

   [HTE98] M. Handley, D. Thaler, and D. Estrin, "The Internet
   Multicast Address Allocation Architecture", Internet Draft, June
   1998.










Hardjono, Cain, Monga                                        [Page 30]


Internet Draft        Intra-Domain GKM Protocol         November 1998


11. Author Addresses

   Thomas Hardjono
   Email: thardjono@baynetworks.com

   Brad Cain
   Email: bcain@baynetworks.com

   Inder Monga
   Email: imonga@baynetworks.com

   Nortel Networks
   3 Federal Street, Bl3-03
   Billerica, MA 01821, USA
   Tel: +1-978-916-4538


12. Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






Hardjono, Cain, Monga                                        [Page 31]