[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 3740

   Internet Engineering Task Force                   Thomas Hardjono (VeriSign)
   INTERNET-DRAFT                                            Brian Weis (Cisco)
   draft-ietf-msec-arch-00.txt                                 Expires May 2003
   November 2002


                The Multicast Security (MSEC) Architecture

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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 and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document provides a foundation for the protocols developed by
   the Multicast Security (MSEC) group.  The document begins by
   introducing a Reference Framework, and proceeds to identify
   functional areas which must be addressed as part of a secure
   multicast solution.










   Hardjono, Weis         Expires May, 2003                         1
   MSEC Architecture                                     October, 2002


Table of Contents

1. Introduction.......................................................2
  1.1 Summary of Contents of Document.................................2
  1.2 Audience........................................................3
  1.3 Related Documents...............................................3
2. Architectural Design: The MSEC Reference Framework.................4
  2.1 A Reference Framework...........................................4
  2.2 Elements of the Reference Framework.............................5
    2.2.1 Group Controller and Key Server.............................5
    2.2.2 Sender and Receiver.........................................6
    2.2.3 Policy Server...............................................6
    2.2.4 Centralized and Distributed Designs.........................7
3. Functional Areas...................................................7
  3.1 Multicast Data..................................................7
  3.2 Management of Keying Material...................................8
  3.3 Multicast Security Policies.....................................8
4. Group Security Associations (GSA).................................10
  4.1 SAs and Multicast..............................................10
  4.1 Structure of a GSA: Reasoning..................................11
5. Security Services.................................................14
    5.2.1 Multicast Data Confidentiality.............................14
    5.2.2 Multicast Source Authentication and Data Integrity.........15
    5.2.3. Multicast Group Authentication............................15
    5.2.4 Multicast Group Membership Management......................16
    5.2.5 Multicast Key Management...................................16
    5.2.6 Multicast Policy Management................................17
6. MSEC Documents Roadmap............................................18
7. Conclusion........................................................19
8. Acknowledgments...................................................19
9. References........................................................19
  9.1 Normative References...........................................19
  9.2 Informative References.........................................20
Authors Addresses....................................................21


1. Introduction

   Securing IP multicast communication is a complex task that involves
   many aspects. Consequently, a secure IP multicast protocol suite must
   have a number of functional areas that address different aspects of
   the problem. This document describes those functional areas, and
   protocols which have been developed which fit into those component
   areas.

1.1 Summary of Contents of Document


   Hardjono, Weis         Expires May, 2003                         2
   MSEC Architecture                                     October, 2002


   This document provides an architectural overview of the work being
   conducted in the MSEC Working Group.  It provides a Reference
   Framework for covering the scope of the problems in multicast
   security, and explains the elements of the Reference Framework.

   The Reference Framework, in turn, provides the division of labor
   along three Functional Areas pertaining to security.  These cover the
   treatment of data from a security perspective when it is to be sent
   to a group, the management of keying material used to protect the
   data and the policies governing a group.

   Another important item in this document is the definition and
   explanation of Group Security Associations (GSA), which is the
   multicast counterpart of the unicast Security Association (SA).  The
   GSA is specific to multicast security, and is the foundation of the
   work on group key management.


1.2 Audience

   This document is addressed to the technical community and
   implementers of IP multicast security technology others interested in
   gaining a general background understanding of multicast security.
   This document assumes that the reader is familiar with the Internet
   Protocol, the IPsec suite of protocols (e.g. IPsec, IKE, ISAKMP),
   related networking technology, and general security terms and
   concepts.

1.3 Related Documents

   Other documents provide detailed explanations of the Functional Areas
   within the MSEC Reference Framework.  These include the following set
   of documents:

   a. "Group Key Management Architecture" document [BCDL] -- a document
      that provides the key management architecture for multicast
      security, building on the Group Security Association (GSA)
      concept defined in the current document.

   b. "Group Domain of Interpretation" [BHHW] and "GSAKMP Light" [HSC],
      which are two instances of protocols implementing the group key
      management function.

   c. "Multicast Encapsulating Security Payload" [BCCR], which provides
      the definition for Multicast ESP, for data traffic.

   d. "Multicast Source Authentication Transform Specification" [PCW],
      which defines the use of the TESLA algorithm for source
      authentication in multicast.




   Hardjono, Weis         Expires May, 2003                         3
   MSEC Architecture                                     October, 2002


2. Architectural Design: The MSEC Reference Framework

   This section considers the complex problems of multicast security in
   the context of a heuristic device, the Reference Framework diagram,
   shown in Figure 1. The Reference Framework is used to classify
   functional areas, functional elements, and interfaces.

2.1 A Reference Framework

   Based on the three broad functional areas, a reference framework is
   proposed (Figure 1). The reference framework attempts to incorporate
   the main entities and functions relating to multicast security, and
   to depict the inter-relations among them. At the same time, it also
   tries to express the complex multicast security question from the
   perspective of problem classification (i.e., the three functional
   areas), from the perspective of architectures (centralized
   distributed), of multicast types (1-to-M or M-to-N), and protocols
   (the exchanged messages).

   The aim of the reference framework is to provide some general context
   within which functional areas can be identified and classified and
   the relationships among the functional areas can be recognized. Note
   that some issues span more than one so-called functional area. In
   fact, the framework encourages the precise identification and
   formulation of issues that involve more than one functional area or
   those which are difficult to express in terms of a single functional
   area. An example of such a case is the expression of policies
   concerning group keys, which involves both the functional areas of
   group key management and multicast policies.

   When considering the reference framework (Figure 1) it is important
   to realize that the singular "boxes" in the framework do not
   necessarily imply a corresponding singular entity implementing a
   given function. Rather, a box in the framework should be interpreted
   loosely as pertaining to a given function related to a functional
   area.  Whether that function is in reality implemented as one or more
   physical entities is dependent on the particular solution. As an
   example, the box labeled "Key Server" must be interpreted in broad
   terms as referring to the functions of key management.  Similarly,
   the Reference Framework acknowledges that some implementations may in
   fact merge a number of the "boxes" into a single physical entity.

   The reference framework can be viewed horizontally and vertically.
   Horizontally, it displays both the entities and functions as singular
   boxes, expressing each of the three broad functional areas.
   Vertically, it expresses the basic architecture designs for
   solutions, namely a centralized architecture and a distributed
   architecture.

   The protocols to be standardized are depicted in Figure 1 by the
   arrows that connect the various boxes. See more details in Section 4,
   below.


   Hardjono, Weis         Expires May, 2003                         4
   MSEC Architecture                                     October, 2002


     +-----------------------------------------------------------------+
     |          CENTRALIZED  \                            DISTRIBUTED  |
     |            DESIGNS     \                             DESIGNS    |
     | FUNCTIONAL              \                                       |
     |   AREAS                  \                                      |
     |            +------+       \                          +------+   |
     | Multicast  |Policy|<-------\------------------------>|Policy|   |
     | Security   |Server|         \                        |Server|   |
     | Policies   +------+          \                       +------+   |
     |                ^              \                          ^      |
     |                |               \                         |      |
     |                |                \                        |      |
     |                v                 \                       v      |
     |            +------+               \                  +------+   |
     | Group      |Group |<-------------- \---------------> |Group |   |
     | Key        |Ctrl/ |<---------+      \                |Ctlr/ |   |
     | Management |Key   |          |       \               |Key   |   |
     |            |Server|          V        \              |Server|   |
     |            +------+     +--------+     \             +------+   |
     |                ^        |        |      \                ^      |
     |                |        |Receiver|       \               |      |
     |                |        |        |        |              |      |
     |                v        +--------+        |              |      |
     |            +------+          ^            |              V      |
     |            |      |          |            |         +--------+  |
     | Multicast  |Sender|<---------+            |         |        |  |
     | Data       |      |<--------------------- |-------->|Receiver|  |
     | Handling   |      |                       |         |        |  |
     |            +------+                       |         +--------+  |
     +-----------------------------------------------------------------+
                 Figure 1: MSEC Reference Framework




2.2 Elements of the Reference Framework

   The Reference Framework diagram of Figure 1 contains boxes and
   arrows. The boxes are the functional entities and the arrows are the
   interfaces between them.  Standard protocols are needed for the
   interfaces, which support the multicast services between the
   functional entities.  There are three sets of functional entities in
   both centralized and distributed designs as discussed below.


2.2.1 Group Controller and Key Server

   The Group Controller and Key Server (GCKS) represent both the entity
   and functions relating to the issuance and management of
   cryptographic keys used by a multicast group, which is subject to the
   user-authentication and authorization checks conducted on the
   candidate member of the multicast group.


   Hardjono, Weis         Expires May, 2003                         5
   MSEC Architecture                                     October, 2002


   In a distributed architecture the GCKS entity also interacts with
   other GCKS entities to achieve scalability in the key management
   related services.  In such a case, each member of a multicast group
   may interact with one or more GCKS entity (say, the "nearest" GCKS
   entity, measured in terms of a well-defined and consistent metric).
   Similarly, in a distributed architecture a GCKS entity may interact
   with one or more Policy Servers, also arranged in a distributed
   architecture.

   We remark that the Key Server (KS) and the Group Controller (GC) have
   somewhat different functionality and may in principle be regarded as
   separate entities. Currently the framework regards the two entities
   as one "box" in order to simplify the design, and in order not to
   mandate standardization of the protocol between the KS and the GC. It
   is stressed that the KS and GC need NOT be co-located. Furthermore,
   future designs may choose to standardize the protocol between the GC
   and the KS, without altering other components.


2.2.2 Sender and Receiver

   The Sender is an entity that sends data to the multicast group.  In a
   1-to-N multicast group only a single sender is allowed to transmit
   data to the group.  In an M-to-N multicast group, many (or even all)
   group members can transmit data to the group.

   Both Sender and Receiver must interact with the GCKS entity for the
   purpose of key management.  This includes user-authentication, the
   obtaining of keying material in accordance with some key management
   policies for the group, obtaining new keys during key-updates, and
   obtaining other messages relating to the management of keying
   material and security parameters.

   The influence of policies on both Senders and Receivers is seen as
   coming indirectly through the GCKS entities, since the event of
   joining a multicast group is typically coupled with the
   Sender/Receiver obtaining keying material from a GCKS entity.  This
   does not preclude the direct interaction between the Sender/Receiver
   and the Policy Server.

   The reference framework displays two Receiver boxes corresponding to
   the situation where both the Sender and Receiver employ the same
   GCKS entity (centralized architecture) and where the Sender and
   Receiver employ different GCKS entities (distributed architecture).

2.2.3 Policy Server

   The Policy Server represents both the entity and functions used to
   create and manage security policies specific to a multicast group.
   The Policy Server interacts with the GCKS entity in order to install
   and manage the security policies related to the membership of a given
   multicast group and those related to keying material for a multicast
   group.

   Hardjono, Weis         Expires May, 2003                         6
   MSEC Architecture                                     October, 2002



   The interactions between the Policy Server and other entities in the
   reference framework is dependent to a large extent on the security
   circumstances being addressed by a given policy.


2.2.4 Centralized and Distributed Designs

   The need for solutions to be scalable to large groups across wide
   geographic regions of the Internet requires the elements of the
   framework to also function as a distributed system.  This implies
   that a GCKS entity must be able to interact securely with other
   GCKS entities in a different location.  Similarly, Policy Servers
   must interact with each other securely to allow the communication and
   enforcement of policies across the Internet.

3. Functional Areas

   In order to begin to address the problems in securing IP multicast,
   we identify three functional area emanating from the reference
   framework. The three functional area are:

     ¡ Multicast data handling. This area covers problems concerning
        the security-related treatments of multicast data by the sender
        and the receiver. This functional area is further discussed in
        Section 3.1.

     ¡ Group Key Management. This area is concerned with the secure
        distribution and refreshment of keying material. This functional
        area is further discussed in Section 3.2.

     ¡ Multicast security policies. This area covers aspects of policy
        in the context of multicast security, taking into consideration
        the fact that policies may be expressed in different ways, that
        they may exist at different levels in a given multicast security
        architecture and that they may be interpreted differently
        according to the context in which they are specified and
        implemented.  This functional area is further discussed in
        Section 3.3.

3.1 Multicast Data

   In a secure multicast group, the data typically needs to be:

       1. Encrypted using the group key, mainly for access control and
          possibly also for confidentiality.

       2. Authenticated, for verifying the source and integrity of the
          data. Authentication takes two flavors:
          2.1 Source authentication and data integrity. This
             functionality guarantees that the data originate with the
             claimed source and was not modified en route (either by a
             group member or an external attacker).

   Hardjono, Weis         Expires May, 2003                         7
   MSEC Architecture                                     October, 2002


          2.2 Group authentication. This type of authentication only
             guarantees that the data was generated (or last modified)
             by some group member. It does not guarantee data integrity
             unless all group members are trusted.

   While multicast encryption and group authentication are fairly
   standard and similar to encrypting and authenticating point-to-point
   communication, source authentication for multicast is considerably
   more involved. Consequently, off-the-shelf solutions (e.g., taken
   from IPSec [RFC2406], TLS [RFC2246]) may be sufficient for
   encryption. For source authentication, however, special-purpose
   transformations are necessary.   See [CP99] for further elaboration
   on the concerns regarding the data transforms, on present solutions
   and remaining challenges.

3.2 Management of Keying Material

   The term "keying material" refers to the cryptographic key belonging
   to a group, the state associated with the keys and the other security
   parameters related to the keys.  Hence, the management of the
   cryptographic keys belonging to a group necessarily requires the
   management of their associated state and parameters.  A number of
   solutions for specific problems must be addressed.  These may include
   the following:

     ¡ Methods for member identification and authentication.
     ¡ Methods to verify the membership to groups.
     ¡ Methods to establish a secure channel between a GCKS entity and
        the member, for the purpose of delivery of shorter-term keying
        material pertaining to a group.
     ¡ Methods to establish a long-term secure channel between one
        GCKS entity and another, for the purpose of distributing
        shorter-term keying material pertaining to a group.
     ¡ Methods to effect the changing of keys and keying material
     ¡ Methods to detect and signal failures and perceived compromises
        to keys and keying material

   The needs related to the management of keying material must be seen
   in the context of the policies that prevail within the given
   circumstance.

   Core to the problem of key management is Security Association (SA)
   Management, which will be discussed further below.

3.3 Multicast Security Policies

   Multicast Security Policies must provide the rules for operation for
   the other elements of the Reference Framework.  While much of the
   work for the Multicast Security Policy area is focused in the Policy
   Controller, there are potential areas for work in the application of
   policy at the Group Controller element and the member (sender and
   receiver) elements.  While there is already a basis for security
   policy management in the IETF between the Policy Working Group and

   Hardjono, Weis         Expires May, 2003                         8
   MSEC Architecture                                     October, 2002


   the IP Security Policy Working Group, multicast security policy
   management will extend the concepts developed for unicast
   communication in the areas of:

     ¡ Policy creation,
     ¡ High-level policy translation, and
     ¡ Policy representation.

   Examples of work in multicast security policies include the Dynamic
   Cryptographic Context Management project [Din], Group Key Management
   Protocol [Har1, Har2], and Antigone[McD].

   Policy creation for secure multicast has several more dimensions than
   the single administrator specified policy assumed in the existing
   unicast policy frameworks.  Secure multicast groups are usually large
   and by their very nature extend over several administrative domains,
   if not spanning a different domain for each user.  There are several
   methods that need to be explored for the creation of a single,
   coherent group security policy.  They include a top-down
   specification of the group policy from the group initiator and
   negotiation of the policy between the group members (or prospective
   members).  Negotiation can be as simple as a strict intersection of
   the policies of the members or extremely complicated using weighted
   voting systems.

   High-level policy translation is much more difficult in a multicast
   group environment, especially when group membership spans multiple
   administrative domains.  When policies are specified at a high level
   with a Policy Management tool, they must then be translated into more
   precise rules that the available security mechanisms can both
   understand and implement. When dealing with multicast communication
   and its multiple participants, it is essential that the individual
   translation performed for each participant result in the use of a
   mechanism that is interoperable with the results of all of the other
   translations.  Typically, the translation from high-level policy to
   implementation mechanisms must result in the same mechanism in order
   to achieve communication between all of the group members.  The
   requirement that policy translation results in the same mechanism
   places constraints on the use and representations in the high-level
   policies.  It is also important that policy negotiation and
   translation be performed as an integral part of joining a group.
   Adding a member to a group is meaningless if they will not be able to
   participate in the group communications.

   Multicast security policies must represent, or contain, more
   information than a traditional peer-to-peer policy.  In addition to
   representing the security mechanisms for the group communication, the
   policy must also represent the rules for the governance of the secure
   group.  Policy must be established for the basic group operations of
   add and remove, as well as more advanced operations such as leave,
   rejoin, or resynchronize.


   Hardjono, Weis         Expires May, 2003                         9
   MSEC Architecture                                     October, 2002


4. Group Security Associations (GSA)

4.1 SAs and Multicast

   It is clear that the security associations (SA) for group key
   management are more complex, or at least more numerous, than for
   Internet key management [RFC2409].  The latter establishes a key
   management SA to protect application SAs (where a minimum of two are
   needed to key an Internet application process). However, group key
   management requires at least three:  There is a registration SA
   between the group member and the GCKS, a rekey SA between the GCKS
   and all the group members, and an SA to protect application data from
   sender-members to receiver-members.  In fact, each sender to the
   group may use a unique key for their data and use a separate SA:
   there may be more SAs than there are group senders.

   Group key management, therefore, uses a different set of abstractions
   than ISAKMP and IKE.  Notwithstanding, the abstractions used in our
   Group Key Management functional area may be built from the ISAKMP
   abstractions. In our approach the Group Security Association (GSA)
   includes the attributes of the Internet Security Architecture SA,
   which is succinctly defined as the encapsulation of keys and policies
   [RFC2409] as follows.

     - An SA has selectors, such as source and destination transport
        addresses.
     - An SA has properties, such as an security parameter index (SPI)
        or cookie pair, and identities.
     - An SA has cryptographic policy, such as the algorithms, modes,
        key lifetimes, and key lengths used for authentication or
        confidentiality.
     - An SA has keys, such as authentication, encryption and signing
        keys.

   As is discussed in the next section of this memo, a GSA contains the
   SA attributes plus some additional ones.  As shown in Figure 2 (a),
   the GSA is a superset of the SA.

     ¡ A GSA has group policy attributes, such as the kind of signed
        credential needed for group membership and whether the group
        will be given new keys when a member is added (called "backward
        re-key" below) or whether group members will be given new key
        when a member is removed from the group ("forward re-key").
     - A GSA has SAs as attributes.


   Hardjono, Weis         Expires May, 2003                        10
   MSEC Architecture                                     October, 2002


       +------------------------------------------------------------+
       |                                                            |
       |    +---------------+              +-------------------+    |
       |    |     GSA       |              |        GSA        |    |
       |    |               |              | +-----+   +-----+ |    |
       |    |               |              | | SA1 |   | SA2 | |    |
       |    |    +----+     |              | +-----+   +-----+ |    |
       |    |    | SA |     |              |      +-----+      |    |
       |    |    +----+     |              |      | SA3 |      |    |
       |    |               |              |      +-----+      |    |
       |    +---------------+              +-------------------+    |
       |                                                            |
       |       (a) superset                  (b) aggregation        |
       |                                                            |
       +------------------------------------------------------------+
                   Figure 2: Relationship of GSA to SA


4.1 Structure of a GSA: Reasoning

   There are three categories of SAs aggregated into a GSA in Figure
   2(b). We choose this structure to better realize a GSA in our key
   management environment. There is a need to maintain SAs between a Key
   Server and a group member (either a sender, a receiver or both) and
   among members. The Key Server is called the "GCKS," which is charged
   with access control to the group keys, with policy distribution to
   client members or prospective members, and with group key
   dissemination to sender and receiver client members.  This structure
   is common in many group key management environments [HH, CP99,
   RFC2627, BMS]. There are two SAs established between the GCKS and the
   members, and there is an SA established among the sending and
   receiving members as shown in Figure 3.

   The first category of SA (namely REG in Figure 3, for "registration
   SA") is initiated by the member to pull GSA information from the
   GCKS. This is how the member requests to join the secure group or has
   its GSA keys re-initialized after being disconnected from the group
   (e.g., when its host computer has been turned off during re-key
   operations as described below). The GSA information pulled down from
   the GCKS include the SA, keys and policy used to secure the data
   transmission between sending and receiving members; this is DATA in
   Figure 3, "for data security SA".  Note that DATA is a category of
   SA, and this implies that there may be multiple SAs established
   between member senders and member receivers - at least as an option.
   There may exist, for example, a single DATA SA in which all senders
   share common keys and associated information. On the other hand,
   there may be one or more DATA SAs that are unique to the particular
   sender.  A DATA SA may be reestablished or have its keys modified
   through re-key operations, which occur over a REKEY SA (for "rekey
   SA). Keys are pushed through a REKEY SA to support subscription
   groups.


   Hardjono, Weis         Expires May, 2003                        11
   MSEC Architecture                                     October, 2002


   Thus, despite the fact that the data to be protected are multicast,
   registration exchanges through a REG SA should be unicast or point-
   to-point key determination exchanges.  Some group key management
   solutions rely solely point-to-point. Most others combine unicast
   exchanges for initialization with multicast distribution for re-key.
   In some cases, such as in a pure "pay-per-session" application, all
   of the SA information needed for the session may be distributed at
   the time of registration or selection of a session, i.e. over a REG
   SA; re-key and re-initialization may not be necessary, so there is no
   REKEY SA.  For subscription groups where keying material is changed
   as membership changes, a REKEY SA is needed to re-initialize a DATA
   SA.

      +------------------------------------------------------------+
      |                                                            |
      |                    +------------------+                    |
      |                    |       GCKS       |                    |
      |                    |                  |                    |
      |                    |   REG      REG   |                    |
      |                    |    /  REKEY \    |                    |
      |                    +---/-----|----\---+                    |
      |                       /      |     \                       |
      |                      /       |      \                      |
      |                     /        |       \                     |
      |                    /         |        \                    |
      |                   /          |         \                   |
      |    +-------------/------+    |   +------\-------------+    |
      |    |           REG      |    |   |     REG            |    |
      |    |               REKEY-----+----REKEY               |    |
      |    | MEMBER SENDER      |        |     MEMBER RECEIVER|    |
      |    |                DATA----------DATA                |    |
      |    +--------------------+        +--------------------+    |
      |                                                            |
      |                                                            |
      +------------------------------------------------------------+
             Figure 3: GSA Structure and 3 categories of SAs


   4.2 Definition of GSA

   The GSA includes an aggregate of the three aforementioned categories
   of SAs. The three categories of SAs correspond to the three kinds of
   communications as seen from the point of view of the Receiver
   (Member). Figure 3 depicts this concept:

    - Registration (REG) SA:
      An SA is required for (bi-directional) unicast communications
      between the GCKS and a group member (be it a Sender or Receiver).
      This SA is established only between the GCKS and a Member. The
      GCKS entity is charged with access control to the group keys,
      with policy distribution to members (or prospective members), and
      with group key dissemination to Sender and Receiver members. This
      use of a (unicast) SA as a starting point for key management is

   Hardjono, Weis         Expires May, 2003                        12
   MSEC Architecture                                     October, 2002


      common in a number of group key management environments [HH,
      CP99, RFC2627, BMS, Bris99].

      Note that this (unicast) SA is used to protect the other elements
      of the GSA (such as the other following two categories of SAs),
      either in a "push" or "pull" model.  As such, this SA is crucial
      and is inseparable from the other two SAs as the definition of a
      GSA.

      From the perspective of one given GCKS, there are as many unique
      registration SAs as there are members (Senders and/or Receivers)
      in the group.  This may constitute a scalability concern for some
      applications, so a registration SA may be used on-demand whereas
      re-key and data security SAs are established at least for the
      life of the sessions that they support.

    - Re-key (REKEY) SA:
      An SA is required for the multicast transmission of key
      management messages (unidirectional) from the GCKS to all group
      members. As such, this SA is known by the GCKS and by all members
      of the group.

      This SA is not negotiated, since all the group members must share
      it. Thus, the GCKS must be the authentic source and act as the
      sole point of contact for the group members to obtain this SA.

      From the perspective of each participant in a group (GCKS and all
      members), there is at least one registration SA for the group.
      Note that this allows for the possibility of the GCKS deploying
      multiple re-key SAs for group key management purposes.

    - Data Security (DATA) SA:
      One or more SAs are required for the multicast transmission of
      data-messages (unidirectional) from the Sender to other group
      members. This SA is known by the GCKS and by all members of the
      group.

      Similarly, regardless of the number of instances of this third
      category of SA, this SA is not negotiated.  Rather, all group
      members obtain it from the GCKS. The GCKS itself does not use
      this category of SA.

      From the perspective of the Receivers, there is at least one data
      security SA for the member sender (one or more) in the group.
      This allows for the possibility of including group IDs (GID) in
      transmission of data packets from the senders in the group.

      There are a number of possibilities with respect to the number of
      data security SAs and the use of Group IDs (GIDs):

        (i) Each sender in the group could be assigned a unique dta
           security SA, thereby resulting in each receiver having to

   Hardjono, Weis         Expires May, 2003                        13
   MSEC Architecture                                     October, 2002


           maintain as many data security SAs as there are senders in
           the group.

       (ii) The entire group deploys a single data security SA for all
           senders, together with the use of GIDs.  Receivers would
           then be able to filter based on the GIDs, whilst maintaining
           only one data security SA.

      (iii) A combination of (i) and (ii) above.

5. Security Services

   Referring to our Reference Diagram, this section identifies security
   services for designated interfaces of Figure 1.  In this section,
   distinct security services are assigned to specific interfaces.  For
   example, multicast source authentication, data authentication, and
   confidentiality occur on the multicast data interface between Senders
   and Receivers in Figure 1.  Authentication and confidentiality
   services may also be needed between the Key Server and key clients
   (i.e., the Senders and Receivers of Figure 1), but the services that
   are needed for multicast key management may be unicast as well as
   multicast.  A security service for multicast security, therefore,
   identifies a specific function along one or more Figure 1 interfaces.

   This paper does not attempt to analyze the trust relationships,
   detailed functional requirements, performance requirements, suitable
   algorithms, and protocol specifications for IP multicast and
   application-layer multicast security.  Instead, we propose these
   tasks as future work that will occur as the functional building
   blocks are further defined and realized in algorithms and protocols.

   We identify a set of security services in the following sections.
   This preliminary list of services is intended to serve as a basis for
   discussion in the MSEC working group.

5.2.1 Multicast Data Confidentiality

   This security service handles the encryption of multicast data at the
   Sender's end and the decryption at the Receiver's end.  This security
   service may also apply the keying material that is provided by
   Multicast Key Management in accordance with Multicast Policy
   Management, but it is independent of both.

   An important part of the future work on the Multicast Data
   Confidentiality building block is in the identification of and
   motivation for specific ciphers that should be used for multicast
   data. Obviously, not all ciphers will be suitable for IP multicast
   and application-layer multicast traffic.  Since this traffic will
   usually be connectionless UDP flows, stream ciphers may be unsuitable
   though hybrid stream/block ciphers may have advantages over some
   block ciphers. Those working on this security service will need to
   evaluate the real-time and other requirements of multicast senders
   and receivers, and recommend a small set of promising ciphers and

   Hardjono, Weis         Expires May, 2003                        14
   MSEC Architecture                                     October, 2002


   data protocols for IP multicast and application-layer multicast data
   confidentiality.

   Regarding application-layer multicast, some consideration is needed
   to consider the effects of sending encrypted data in a multicast
   environment lacking admission-control, where practically any
   application program can join a multicast event independently of its
   participation in a multicast security protocol.  Thus, this security
   service is also concerned with the effects of multicast
   confidentiality services, intended and otherwise, on application
   programs in all senders and receivers.

   In Figure 1, the Multicast Data Confidentiality security service is
   placed in Multicast Data Handling Area along the interface between
   Senders and Receivers.  The algorithms and protocols that are
   realized from work on this security service may be applied to other
   interfaces and areas of Figure 1 when multicast data confidentiality
   is needed.


5.2.2 Multicast Source Authentication and Data Integrity

   This security service handles source authentication and integrity
   verification of multicast data. It includes the transforms to be made
   both at the Sender's end and at the Receiver's end. It assumes that
   the appropriate signature and verification keys are provided via
   Multicast Key Management in accordance with Multicast Policy
   Management as described below.   Work done by MSEC Working Group
   members suggests that this is one of the harder areas of multicast
   security. This is due to the connectionless and real-time
   requirements of many IP multicast applications.  There are classes of
   application-layer multicast security, however, where offline source
   and data authentication will suffice.  As discussed previously, not
   all multicast applications require real-time authentication and data-
   packet integrity.  A robust solution to multicast source and data
   authentication, however, is necessary for a Whole Protocol solution
   to multicast security.

   In Figure 1, the Multicast Source and Data Authentication security
   service is placed in Multicast Data Handling Area along the interface
   between Senders and Receivers.  The algorithms and protocols that are
   produced for this functional area may have applicability to building
   blocks in other functional area that use multicast services such as
   Group Key Management.


5.2.3. Multicast Group Authentication

   This security service provides a limited amount of authenticity of
   the transmitted data: It only guarantees that the data originated
   with (or was last modified by) one of the group members. It does not
   guarantee authenticity of the data in case that other group members
   are not trusted.

   Hardjono, Weis         Expires May, 2003                        15
   MSEC Architecture                                     October, 2002



   The advantage of group authentication is that it is guaranteed via
   relatively simple and efficient cryptographic transforms. Therefore,
   when source authentication is not paramount group authentication
   becomes useful. In addition, performing group authentication is
   useful even when source authentication is later performed: it
   provides a simple-to-verify weak integrity check that is useful as a
   measure against denial-of -service attacks.

   The Multicast Group Authentication security service is placed in the
   Multicast Data Handling Area along the interface between Senders and
   Receivers.

5.2.4 Multicast Group Membership Management

   This security service describes the functionality of registration and
   de-registration of members. Registration includes member
   authentication, notification and negotiation of security parameters,
   and logging of information according to the policies of the group
   controller and the would-be member. (Typically, an out-of-band
   advertisement of group information would occur before the
   registration takes place. The registration process will typically be
   invoked by the would-be member.)

   De-registration may occur either at the initiative of the member or
   at the initiative of the group controller. It would result in logging
   of the de-registration event by the group controller and an
   invocation of the appropriate mechanism for terminating the
   membership of the de-registering member (see Section 5.2.5).

   This security service also describes the functionality of the
   communication related to group membership among different GC+KS
   servers in a distributed group design.

   In Figure 1, the Multicast Group Membership security service is
   placed in the Group Key Management Area and has interfaces to Senders
   and Receivers.

5.2.5 Multicast Key Management

   This security service describes the functionality of distributing and
   updating the cryptographic keying material throughout the life of the
   group. Components of this building may include:

     - GC+KS to Client (Sender or Receiver) notification regarding
        current keying material (e.g. group encryption and
        authentication keys, auxiliary keys used for group management,
        keys for source authentication, etc).

     - Updating of current keying material, depending on circumstances
        and policies.


   Hardjono, Weis         Expires May, 2003                        16
   MSEC Architecture                                     October, 2002


     - Termination of groups in a secure manner, including the
        multicast group itself and the associated keying material.

   Among the problems to be solved by this security service is the
   secure management of keys between Key Servers and Clients, the
   addressing issues for the multicast distribution of keying material,
   and the scalability or other performance requirements for multicast
   key management [RFC2627, BMS].

   To allow for an interoperable and secure IP multicast security
   protocol, this security service may need to specify host abstractions
   such as a group security association database (GSAD) and a group
   security policy database (GSPD) for IP multicast security.  The
   degree of overlap between IP multicast and application-layer
   multicast key management needs to be considered.  Thus, work on this
   security service must take into account the key management
   requirements for IP multicast, the key management requirements for
   application-layer multicast, and to what degree specific realizations
   of a Multicast Key Management security service can satisfy both.
   ISAKMP, moreover, has been designed to be extensible to multicast key
   management for both IP multicast and application-layer multicast
   security [RFC2408].  Thus, multicast key management protocols may use
   the existing ISAKMP standard's Phase 1 and Phase 2 protocols,
   possibly with needed extensions (such as an ISAKMP Domain of
   Interpretation for IP multicast or application-layer multicast
   security).

   This security service also describes the functionality of the
   communication related to key management among different GC+KS servers
   in a distributed group design.

   Multicast Key Management appears in both the centralized and
   distributed designs as shown in Figure 1 and is placed in the Group
   Key Management Area.


5.2.6 Multicast Policy Management

   This security service handles all matters related to multicast group
   policy including membership policy and multicast key management
   policy.  Indeed, one of the first tasks in further defining this
   security service is identifying the different areas of multicast
   policy.  Multicast Policy Management includes the design of the
   policy server for multicast security, the particular policy
   definitions that will be used for IP multicast and application-layer
   multicast security, and the communication protocols between the
   Policy Server and the Key Server.  This security service may be
   realized using a standard policy infrastructure such as a Policy
   Decision Point (PDP) and Policy Enforcement Point (PEP) architecture.
   Thus, it may not be necessary to re-invent a separate architecture
   for multicast security policy; we expect that this work will evaluate
   use of the products of IETF efforts in the areas of network and
   security policy.  At minimum, however, this security service will be

   Hardjono, Weis         Expires May, 2003                        17
   MSEC Architecture                                     October, 2002


   realized in a set of policy definitions, such as multicast security
   conditions and actions.

   The Multicast Policy Management security service describes the
   functionality of the communication between an instance of a GC+KS to
   an instance the Policy Server.  The information transmitted may
   include policies concerning groups, memberships, keying material
   definition and their permissible uses, and other information.  This
   security service also describes communication between and among
   Policy Servers.  Thus, the Multicast Policy Management security
   service is placed in Problem Area 3, along the interface between Key
   Servers and Policy Servers. Group members are not expected to
   directly participate in this security service.  However, this option
   is not ruled out.


6. MSEC Documents Roadmap

   The roadmap of MSEC WG documents is shown the in the following.


                              +--------------+
                              |     MSEC     |
                              | Requirements |
                              +--------------+
                                     :
                                     :
                              +--------------+
                              |     MSEC     |
                              | Architecture |
                              +--------------+
                                     :
                .....................:.......................
                :                    :                      :
         +--------------+     +--------------+      +--------------+
         |    Policy    |     |     GKM      |      | Data Security|
         | Architecture |     | Architecture |      | Architecture |
         +--------------+     +--------------+      +--------------+
                :                    :                     :
                :                    :                     :
                        .     +------------+ :      +------------+ :
                        .     |  GDOI      | :      |TESLA/MESP  | :
                              | Resolution |-:      |            |-:
                              |            | :      |            | :
                              +------------+ :      +------------+ :
                                             :                     :
                                             :                     :
                              +------------+ :      +------------+ :
                              | GSAKMP-    | :      |            | :
                              | Resolution |-:      |    TBD     |-:
                              |            | :      |            | :
                              +------------+ :      +------------+ :
                                             :                     :

   Hardjono, Weis         Expires May, 2003                        18
   MSEC Architecture                                     October, 2002


                                             :                     :
                              +------------+ :      +------------+ :
                              |            | :      |            | :
                              |   RE-KEY   |-:      |    TBD     |-:
                              |            | :      |            | :
                              +------------+ :      +------------+ :
                                             :                     :
                                             .                     .
                                             .                     .

                         Figure 4: MSEC Document Roadmap

7. Conclusion

   This document has provided an architectural overview of the work
   being conducted in the MSEC Working Group and introduced several
   important aspects of the standardization efforts in the MSEC WG.

   A Reference Framework for covering the scope of the problems in
   multicast security was introduced, and a division of labor along
   three Functional Areas pertaining to security was discussed.  These
   cover the treatment of data from a security perspective when it is to
   be sent to a group, the management of keying material used to protect
   the data and the policies governing a group.

   This document also defined the notion of Group Security Associations
   (GSA), which is the foundation of the work on group key management in
   the MSEC Working Group.


8. Acknowledgments

   This document was derived from an IRTF SMuG Working Group draft that
   was originally co-authored by Thomas Hardjono, Ran Canetti, Mark
   Baugher, and Pete Dinsmore.

9. References

9.1 Normative References

   [BCDL] M. Baugher, R. Canetti, L. Dondeti, F.  Lindholm, Group Key
   Management Architecture, draft-ietf-msec-gkmarch-03.txt. IETF,
   October 2002. Work in Progress.

   [HSC] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light. draft-ietf-
   msec-gsakmp-light-sec-01.txt. IETF, July 2002. Work in Progress.

   [BHHW] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain
   of Interpretation, draft-ietf-msec-gdoi-06.txt. IETF, February 2002.
   Work in Progress.


   Hardjono, Weis         Expires May, 2003                        19
   MSEC Architecture                                     October, 2002


   [BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: Multicast
   Encapsulating Security Payload, draft-ietf-msec-mesp-00.txt. IETF,
   October 2002. Work in Progress.

   [PCW] A. Perrig, R. Canetti, B. Whillock, TESLA: Multicast Source
   Authentication Transform Specification. draft-ietf-msec-tesla-spec-
   00.txt. IETF, October 2002. Work in Progress.


9.2 Informative References

   [BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large
   Dynamic Groups: One-Way Function Trees and Amortized Initialization,
   http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft-
   00.txt, February 1999, Work in Progress.

   [CP99] R. Canetti and B. Pinkas, A taxonomy of multicast security
   issues, http://search.ietf.org/internet-drafts/draft-irtf-smug-
   taxonomy-01.txt, April 1999, Work in Progress.

   [Din]  Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C.,
   and Sherman, A., "Policy-Based Security Management for Large Dynamic
   Groups:  An Oerview of the DCCM Project," DARPA Information
   Survivability Conference and Exposition, To Be Published.

   [Har1] Harney, H., and Muckenhirn, C., "Group Key Management
   Protocol (GKMP) Specification," RFC 2093, July 1997.

   [Har2] Harney, H., and Muckenhirn, C., "Group Key Management
   Protocol (GKMP) Architecture," RFC 2094, July 1997.

   [HH] H. Harney, E. Harder, Group Secure Association Key Management
   Protocol, http://search.ietf.org/internet-drafts/draft-harney-
   sparta-gsakmp-sec-00.txt, April 1999, Work in Progress.

   [McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone:
   A Flexible Framework for Secure Group Communication," Proceedings of
   the Eight USENIX Security Symposium, pp 99-113, August, 1999.

   [RFC2246] Dierks, T. and C. Allen, The TLS Protocol Version 1.0,
   RFC 2246, January 1999.

   [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
   (ESP),November 1998.

   [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
   Security Association and Key Management Protocol, November 1998.

   [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
   November, 1998.


   Hardjono, Weis         Expires May, 2003                        20
   MSEC Architecture                                     October, 2002


   [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
   Multicast: Issues and Architectures, September 1998.

Authors Addresses

   Thomas Hardjono
   VeriSign
   401 Edgewater Place, Suite 280
   Wakefield, MA 01880
   (781) 245-6996
   thardjono@verisign.com

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive,
   San Jose, CA 95134-1706, USA
   (408) 526-4796
   bew@cisco.com

   Hardjono, Weis         Expires May, 2003                        21


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/