GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3740

Network Working Group T. Hardjono Request for Comments: 3740 Verisign Category: Informational B. Weis

                                                                 Cisco
                                                            March 2004
             The Multicast Group Security Architecture

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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

Abstract

 This document provides an overview and rationale of the multicast
 security architecture used to secure data packets of large multicast
 groups.  The document begins by introducing a Multicast Security
 Reference Framework, and proceeds to identify the security services
 that may be part of a secure multicast solution.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.2.  Summary of Contents of Document. . . . . . . . . . . . .  3
     1.3.  Audience . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Architectural Design: The Multicast Security Reference
     Framework. . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  The Reference Framework. . . . . . . . . . . . . . . . .  4
     2.2.  Elements of the Centralized Reference Framework. . . . .  5
           2.2.1.  Group Controller and Key Server. . . . . . . . .  6
           2.2.2.  Sender and Receiver. . . . . . . . . . . . . . .  7
           2.2.3.  Policy Server. . . . . . . . . . . . . . . . . .  7
     2.3.  Elements of the Distributed Reference Framework. . . . .  8
 3.  Functional Areas . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Multicast Data Handling. . . . . . . . . . . . . . . . .  9
     3.2.  Group Key Management . . . . . . . . . . . . . . . . . . 10
     3.3.  Multicast Security Policies. . . . . . . . . . . . . . . 11
 4.  Group Security Associations (GSA). . . . . . . . . . . . . . . 12
     4.1.  The Security Association . . . . . . . . . . . . . . . . 12

Hardjono & Weis Informational [Page 1] RFC 3740 Multicast Group Security Architecture March 2004

     4.2.  Structure of a GSA: Introduction . . . . . . . . . . . . 13
     4.3.  Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14
     4.4.  Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
     4.5.  Typical Compositions of a GSA. . . . . . . . . . . . . . 17
 5.  Security Services. . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Multicast Data Confidentiality . . . . . . . . . . . . . 18
     5.2.  Multicast Source Authentication and Data Integrity . . . 18
     5.3.  Multicast Group Authentication . . . . . . . . . . . . . 19
     5.4.  Multicast Group Membership Management. . . . . . . . . . 19
     5.5.  Multicast Key Management . . . . . . . . . . . . . . . . 20
     5.6.  Multicast Policy Management. . . . . . . . . . . . . . . 21
 6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22
     6.1.  Multicast Data Handling. . . . . . . . . . . . . . . . . 22
     6.2.  Group Key Management . . . . . . . . . . . . . . . . . . 22
     6.3.  Multicast Security Policies. . . . . . . . . . . . . . . 22
 7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Normative References . . . . . . . . . . . . . . . . . . 23
     8.2.  Informative References . . . . . . . . . . . . . . . . . 23
 9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26

1. Introduction

 Securing IP multicast group 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 solution.  This document describes those functional
 areas and how they are related.

1.1. Scope

 This architecture is concerned with the securing of large multicast
 groups.  Whereas it can also be used for smaller groups, it is not
 necessarily the most efficient means.  Other architectures (e.g., the
 Cliques architecture [STW]) can be more efficient for small ad-hoc
 group communication.
 This architecture is "end to end", and does not require multicast
 routing protocols (e.g., PIM [RFC2362]) to participate in this
 architecture.  Inappropriate routing may cause denial of service to
 application layer groups conforming to this architecture.  However
 the routing cannot affect the authenticity or secrecy of group data
 or management packets.  The multicast routing protocols could
 themselves use this architecture to protect their own multicast and
 group packets.  However, this would be independent of any secure
 application layer group.

Hardjono & Weis Informational [Page 2] RFC 3740 Multicast Group Security Architecture March 2004

 This architecture does not require IP multicast admission control
 protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part of
 secure multicast groups.  As such, a "join" or "leave" operation for
 a secure group is independent of a "join" or "leave" of an IP
 multicast group.  For example, the process of joining a secure group
 requires being authenticated and authorized by a security device,
 while the process of joining an IP multicast group entails contacting
 a multicast-aware router.  Admission control protocols could
 themselves use this architecture to protect their own multicast
 packets.  However, this would be independent of any secure
 application layer group.
 This architecture does not explicitly describe how secure multicast
 groups deal with Network Address Translation (NAT) [RFC2663].
 Multicast routing protocols generally require the source and
 destination addresses and ports of an IP multicast packet to remain
 unchanged.  This allows consistent multicast distribution trees to be
 created throughout the network.  If NAT is used in a network, then
 the connectivity of senders and receivers may be adversely affected.
 This situation is neither improved or degraded as a result of
 deploying this architecture.
 This architecture does not require the use of reliable mechanisms,
 for either data or management protocols.  The use of reliable
 multicast routing techniques (e.g., FEC [RFC3453]) enhance the
 availability of secure multicast groups.  However the authenticity or
 secrecy of group data or management packets is not affected by the
 omission of that capability from a deployment.

1.2. Summary of Contents of Document

 This document provides an architectural overview that outlines the
 security services required to secure large multicast groups.  It
 provides a Reference Framework for organizing the various elements
 within the architecture, and explains the elements of the Reference
 Framework.
 The Reference Framework organizes the elements of the architecture
 along three Functional Areas pertaining to security.  These elements
 cover the treatment of data 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.

Hardjono & Weis Informational [Page 3] RFC 3740 Multicast Group Security Architecture March 2004

1.3. Audience

 This document is addressed to the technical community, implementers
 of IP multicast security technology, and 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., [RFC2401]), related
 networking technology, and general security terms and concepts.

1.4. Terminology

 The following key terms are used throughout this document.
 1-to-N
    A group which has one sender and many receivers.
 Group Security Association (GSA)
    A bundling of Security Associations (SAs) that together define how
    a group communicates securely.  The GSA may include a registration
    protocol SA, a rekey protocol SA, and one or more data security
    protocol SAs.
 M-to-N
    A group which has many senders and many receivers, where M and N
    are not necessarily the same value.
 Security Association (SA)
    A set of policy and cryptographic keys that provide security
    services to network traffic that matches that policy.

2. Architectural Design: The Multicast Security Reference Framework

 This section considers the complex issues of multicast security in
 the context of a Reference Framework.  This Reference Framework is
 used to classify functional areas, functional elements, and
 interfaces.  Two designs of the Reference Framework are shown: a
 centralized design, and a distributed design that extends the
 centralized design for very large groups.

2.1. The Reference Framework

 The Reference Framework is based on three broad functional areas (as
 shown in Figure 1).  The Reference Framework incorporates the main
 entities and functions relating to multicast security, and depicts

Hardjono & Weis Informational [Page 4] RFC 3740 Multicast Group Security Architecture March 2004

 the inter-relations among them.  It also expresses multicast security
 from the perspective of multicast group types (1-to-N and M-to-N),
 and classes of protocols (the exchanged messages) needed to secure
 multicast packets.
 The aim of the Reference Framework is to provide some general context
 around the functional areas, and the relationships between the
 functional areas.  Note that some issues span more than one
 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 diagrams, 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.  This could be true even across functional
 areas.  For example, an entity in a group could act as both a Group
 Controller and a Sender to a group.
 The protocols to be standardized are depicted in the Reference
 Framework diagrams by the arrows that connect the various boxes.  See
 more details in Section 4, below.

2.2. Elements of the Centralized 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.
 In some cases, a system implementing the multicast security
 architecture may not need to implement protocols to account for every
 interface.  Rather, those interfaces may be satisfied through the use
 of manual configuration, or even omitted if they are not necessary
 for the application.

Hardjono & Weis Informational [Page 5] RFC 3740 Multicast Group Security Architecture March 2004

 There are three sets of functional entities.  Each is discussed
 below.
               +--------------------------------------+
               |                                      |
               |                                      |
               |  FUNCTIONAL                          |
               |    AREAS                             |
               |                                      |
               |             +------+                 |
               |  Multicast  |Policy|                 |
               |  Security   |Server|                 |
               |  Policies   +------+                 |
               |                 ^                    |
               |                 |                    |
               |                 |                    |
               |                 v                    |
               |             +------+                 |
               |  Group      |Group |                 |
               |  Key        |Ctrl/ |<---------+      |
               |  Management |Key   |          |      |
               |             |Server|          V      |
               |             +------+     +--------+  |
               |                 ^        |        |  |
               |                 |        |Receiver|  |
               |                 |        |        |  |
               |                 v        +--------+  |
               |             +------+          ^      |
               |             |      |          |      |
               |  Multicast  |Sender|----------+      |
               |  Data       |      |                 |
               |  Handling   |      |                 |
               |             +------+                 |
               |                                      |
               +--------------------------------------+
     Figure 1: Centralized Multicast Security Reference Framework

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.  The GCKS also conducts
 user-authentication and authorization checks on the candidate members
 of the multicast group.

Hardjono & Weis Informational [Page 6] RFC 3740 Multicast Group Security Architecture March 2004

 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 authorized to transmit
 data to the group.  In an M-to-N multicast group, two or more group
 members are authorized to be senders.  In some groups all members are
 authorized as senders.
 Both Sender and Receiver must interact with the GCKS entity for the
 purpose of key management.  This includes user and/or device
 authentication, user and/or device authorization, 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.
 Senders and Receivers may receive much of their policy from the GCKS
 entities.  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.

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.
 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.

Hardjono & Weis Informational [Page 7] RFC 3740 Multicast Group Security Architecture March 2004

2.3. Elements of the Distributed Reference Framework

 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.  Figure 2 shows
 how distributed designs supporting large group scalability fit into
 the Reference Framework.
  +-----------------------------------------------------------------+
  |                                                                 |
  |                                                                 |
  | 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 2: Distributed Multicast Security Reference Framework
 In a distributed design the GCKS entity interacts with other GCKS
 entities to achieve scalability in the key management related
 services.  GCKS entities will require a means of authenticating their
 peer GCKS entities, a means of authorization, and a means of
 interacting securely to pass keys and policy.

Hardjono & Weis Informational [Page 8] RFC 3740 Multicast Group Security Architecture March 2004

 Similarly, Policy Servers must interact with each other securely to
 allow the communication and enforcement of policies across the
 Internet.
 Two Receiver boxes are displayed 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).  In the distributed design, all
 Receivers must obtain identical keys and policy.  Each member of a
 multicast group may interact with a primary GCKS entity (e.g., the
 "nearest" GCKS entity, measured in terms of a well-defined and
 consistent metric).  Similarly, a GCKS entity may interact with one
 or more Policy Servers, also arranged in a distributed architecture.

3. Functional Areas

 The Reference Framework identifies three functional areas.  They are:
  1. Multicast data handling. This area covers the security-related

treatments of multicast data by the sender and the receiver.

       This functional area is further discussed in Section 3.1.
  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.
  1. 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 Handling

 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:
       a. Source authentication and data integrity.  This
          functionality guarantees that the data originated with the
          claimed source and was not modified en route (either by a
          group member or an external attacker).

Hardjono & Weis Informational [Page 9] RFC 3740 Multicast Group Security Architecture March 2004

       b. 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 a point-to-
 point communication, source authentication for multicast is
 considerably more involved.  Consequently, off-the-shelf solutions
 (e.g., taken from IPsec [RFC2406]) may be sufficient for encryption
 and group authentication.  For source authentication, however,
 special-purpose transformations are necessary.  See [CCPRRS] for
 further elaboration on the concerns regarding the data transforms.
 Multicast data encrypted and/or authenticated by a sender should be
 handled the same way by both centralized and distributed receivers,
 (as shown in Figure 2).
 The "Multicast Encapsulating Security Payload" [BCCR] provides the
 definition for Multicast ESP for data traffic.  The "Multicast Source
 Authentication Transform Specification" [PCW] defines the use of the
 TESLA algorithm for source authentication in multicast.

3.2. Group Key Management

 The term "keying material" refers to the cryptographic keys 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 issues must be addressed.  These may include
 the following:
  1. Methods for member identification and authentication.
  2. Methods to verify the membership to groups.
  3. 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 requirements related to the management of keying material must be
 seen in the context of the policies that prevail within the given
 circumstance.

Hardjono & Weis Informational [Page 10] RFC 3740 Multicast Group Security Architecture March 2004

 Core to the area of key management is Security Association (SA)
 Management, which will be discussed further below.
 A "Group Key Management Architecture" document [BCDL] further defines
 the key management architecture for multicast security.  It builds on
 the Group Security Association (GSA) concept, and further defines the
 roles of the Key Server and Group Controller.
 "The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP],
 and "MIKEY" [ACLNM] are three instances of protocols implementing the
 group key management function.

3.3. Multicast Security Policies

 Multicast Security Policies must provide the rules for operation for
 the other elements of the Reference Framework.  Security Policies may
 be distributed in an ad-hoc fashion in some instances.  However,
 better coordination and higher levels of assurance are achieved if a
 Policy Controller distributes Security Policies policy to the group.
 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.  For example, policy would specify the authorization level
 necessary in order for an entity to join a group.  More advanced
 operations would include the conditions when a group member must be
 forcibly removed from the group, and what to do if the group members
 need to resynchronize because of lost key management messages.
 The application of policy at the Group Controller element and the
 member (sender and receiver) elements must be described.  While there
 is already a basis for security policy management in the IETF,
 multicast security policy management extends the concepts developed
 for unicast communication in the areas of:
  1. Policy creation,
  2. High-level policy translation, and
  3. 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,

Hardjono & Weis Informational [Page 11] RFC 3740 Multicast Group Security Architecture March 2004

 if not spanning a different domain for each user.  There are several
 methods that need to be considered in 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.
 The translation of policy rules from one data model to another is
 much more difficult in a multicast group environment.  This is
 especially true when group membership spans multiple administrative
 domains.  Policies specified at a high level with a Policy Management
 tool must be translated into more precise rules that the available
 security policy 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 specific policy objects must
 result in the same objects in order to achieve communication between
 all of the group members.  The requirement that policy translation
 results in the same objects 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.

4. Group Security Associations (GSA)

4.1. The Security Association

 A security association is a commonly used term in cryptographic
 systems (e.g., [RFC2401, RFC2406bis, RFC2409]).  This document uses
 the term to mean any set of policy and cryptographic keys that
 provide security services for the network traffic matching that
 policy.  A Security Association usually contains the following
 attributes:
  1. selectors, such as source and destination transport addresses.
  2. properties, such as an security parameter index (SPI) or cookie

pair, and identities.

  1. cryptographic policy, such as the algorithms, modes, key

lifetimes, and key lengths used for authentication or

       confidentiality.
    -  keys, such as authentication, encryption and signing keys.

Hardjono & Weis Informational [Page 12] RFC 3740 Multicast Group Security Architecture March 2004

 Group key management uses a different set of abstractions than
 point-to-point key management systems (such as IKE [RFC2409]).
 Notwithstanding, the abstractions used in the Group Key Management
 functional area may be built from the point-to-point key management
 abstractions.

4.2. Structure of a GSA: Introduction

 Security associations (SAs) for group key management are more
 complex, and are usually more numerous, than for point-to-point key
 management algorithms.  The latter establishes a key management SA to
 protect application SAs (usually one or two, depending on the
 protocol).  However, group key management may require up to three or
 more SAs.  These SAs are described in later sections.
 A GSA contains all of the SA attributes identified in the previous
 section, as well some additional attributes pertaining to the group.
 As shown in Figure 3, the GSA builds on the SA in two distinct ways.
  1. First, the GSA is a superset of an SA (Figure 3(a)). A GSA has

group policy attributes. For example, the kind of signed

    credentials needed for group membership, whether group members
    will be given new keys when a member is added (called "backward
    re-key" below), or whether group members will be given new keys
    when a member is removed from the group ("forward re-key").  A GSA
    also includes an SA as an attribute of itself.
  1. Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is

comprised of multiple SAs, and these SAs may be used for several

    independent purposes.
          +---------------+              +-------------------+
          |     GSA       |              |        GSA        |
          |               |              | +-----+   +-----+ |
          |               |              | | SA1 |   | SA2 | |
          |    +----+     |              | +-----+   +-----+ |
          |    | SA |     |              |      +-----+      |
          |    +----+     |              |      | SA3 |      |
          |               |              |      +-----+      |
          +---------------+              +-------------------+
             (a) superset                  (b) aggregation
                 Figure 3: Relationship of GSA to SA

Hardjono & Weis Informational [Page 13] RFC 3740 Multicast Group Security Architecture March 2004

4.3. Structure of a GSA: Reasoning

 Figure 4 shows three categories of SAs that can be aggregated into a
 GSA.
    +------------------------------------------------------------+
    |                                                            |
    |                    +------------------+                    |
    |                    |       GCKS       |                    |
    |                    |                  |                    |
    |                    |   REG      REG   |                    |
    |                    |    /  REKEY \    |                    |
    |                    +---/-----|----\---+                    |
    |                       /      |     \                       |
    |                      /       |      \                      |
    |                     /        |       \                     |
    |                    /         |        \                    |
    |                   /          |         \                   |
    |       +----------/------+    |   +------\----------+       |
    |       |        REG      |    |   |      REG        |       |
    |       |            REKEY-----+----REKEY            |       |
    |       |     Sender      |        |      Receiver   |       |
    |       |             DATA----------DATA             |       |
    |       +-----------------+        +-----------------+       |
    |                                                            |
    |                                                            |
    +------------------------------------------------------------+
           Figure 4: GSA Structure and 3 categories of SAs
 The three categories of SAs are:
  1. Registration SA (REG): A separate unicast SA between the GCKS and

each group member, regardless of whether the group member is a

    sender or a receiver or acting in both roles.
  1. Re-key SA (REKEY): A single multicast SA between the GCKS and all

of the group members.

  1. Data Security SA (DATA): A multicast SA between each multicast

source speaker and the group's receivers. There may be as many

    data SAs as there are multicast sources allowed by the group's
    policy.
 Each of these SAs are defined in more detail in the next section.

Hardjono & Weis Informational [Page 14] RFC 3740 Multicast Group Security Architecture March 2004

4.4. Definition of GSA

 The three categories of SAs correspond to three different kinds of
 communications commonly required for group communications.  This
 section describes the SAs depicted in Figure 4 in detail.
  1. Registration SA (REG):

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 common
    in a number of group key management environments [RFC3547, GSAKMP,
    CCPRRS, RFC2627, BMS].
    The 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).  The GSA
    information pulled down from the GCKS is related to the other two
    SAs defined as part of the GSA.
    Note that this (unicast) SA is used to protect the other elements
    of the GSA.  As such, the Registration SA is crucial and is
    inseparable from the other two SAs in the definition of a GSA.
    However, the requirement of a registration SA does not imply the
    need of a registration protocol to create that Registration SA.
    The registration SA could instead be setup through some manual
    means, such as distributed on a smart card.  Thus, what is
    important is that a Registration SA exists, and is used to protect
    the other SAs.
    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.  A registration SA may be established on-demand with
    a short lifetime, whereas re-key and data security SAs are
    established at least for the life of the sessions that they
    support.
    Conversely the registration SA could be left in place for the
    duration of the group lifetime, if scalability is not an issue.
    Such a long term registration SA would be useful for re-
    synchronization or deregistration purposes.

Hardjono & Weis Informational [Page 15] RFC 3740 Multicast Group Security Architecture March 2004

  1. Re-key SA (REKEY):

In some cases, a GCKS needs the ability to "push" new SAs as part

    of the GSA.  These new SAs must be sent to all group members.  In
    other cases, the GCKS needs the ability to quickly revoke access
    to one or more group members.  Both of these needs are satisfied
    with the Re-key SA.
    This Re-key SA is a unidirectional multicast transmission of key
    management messages 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.
    A rekey SA is not absolutely required to be part of a GSA.  For
    example, the lifetime of some groups may be short enough such that
    a rekey is not necessary.  Conversely, the policy for the group
    could specify multiple rekey SAs of different types.  For example,
    if the GC and KS are separate entities, the GC may deliver rekey
    messages that adjust the group membership, and the KS may deliver
    rekey messages with new DATA SAs.
  1. Data Security SA (DATA):

The Data Security SA protects data between member senders and

    member receivers.
    One or more SAs are required for the multicast transmission of
    data-messages from the Sender to other group members.  This SA is
    known by the GCKS and by all members of the group.
    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.  If
    the group has more than one data security SA, the data security
    protocol must have a means of differentiating the SAs (e.g., with
    a SPI).

Hardjono & Weis Informational [Page 16] RFC 3740 Multicast Group Security Architecture March 2004

    There are a number of possibilities with respect to the number of
    data security SAs:
    1. Each sender in the group could be assigned a unique data
       security SA, thereby resulting in each receiver having to
       maintain as many data security SAs as there are senders in the
       group.  In this case, each sender may be verified using source
       origin authentication techniques.
    2. The entire group deploys a single data security SA for all
       senders.  Receivers would then be able to maintain only one
       data security SA.
    3. A combination of 1. and 2.

4.5. Typical Compositions of a GSA

 Depending on the multicast group policy, many compositions of a GSA
 are possible.  For illustrative purposes, this section describes a
 few possible compositions.
  1. A group of memory-constrained members may require only a REG SA,

and a single DATA SA.

  1. A "pay-per-session" application, where all of the SA information

needed for the session may be distributed over a REG SA. Re-key

    and re-initialization of DATA SAs may not be necessary, so there
    is no REKEY SA.
 -  A subscription group, where keying material is changed as
    membership changes.  A REG SA is needed to distribute other SAs; a
    REKEY SA is needed to re-initialize a DATA SA at the time
    membership changes.

5. Security Services

 This section identifies security services for designated interfaces
 of Figure 2.  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 2.  Authentication
 and confidentiality services may also be needed between the Key
 Server and group members (i.e., the Senders and Receivers of Figure
 2), but the services that are needed for multicast key management may
 be unicast as well as multicast.  A security service in the Multicast
 Security Reference Framework therefore identifies a specific function
 along one or more Figure 2 interfaces.

Hardjono & Weis Informational [Page 17] RFC 3740 Multicast Group Security Architecture March 2004

 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, that work will occur
 as the security services are further defined and realized in
 algorithms and protocols.

5.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 Multicast Data Confidentiality security
 service 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.
 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.  Effects to both Senders and Receivers are considered.
 In Figure 2, 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 2 when multicast data confidentiality
 is needed.

5.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.  This is one of the harder areas of
 multicast security due to the connectionless and real-time

Hardjono & Weis Informational [Page 18] RFC 3740 Multicast Group Security Architecture March 2004

 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 complete solution to
 multicast security.
 In Figure 2, 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 security
 services in other functional area that use multicast services such as
 Group Key Management.

5.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.
 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.4. Multicast Group Membership Management

 This security service describes the functionality of registration of
 members with the Group Controller, and de-registration of members
 from the Group Controller.  These are security functions, which are
 independent from IP multicast group "join" and "leave" operations
 that the member may need to perform as a part of group admission
 control protocols (i.e., IGMP [RFC3376], MLD [RFC3019]).
 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

Hardjono & Weis Informational [Page 19] RFC 3740 Multicast Group Security Architecture March 2004

 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.5).
 This security service also describes the functionality of the
 communication related to group membership among different GCKS
 servers in a distributed group design.
 In Figure 2, the Multicast Group Membership security service is
 placed in the Group Key Management Area and has interfaces to Senders
 and Receivers.

5.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 security service may include:
  1. GCKS to group member (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.
    -  Termination of groups in a secure manner, including the secure
       group itself and the associated keying material.
 Among the responsibilities of this security service is the secure
 management of keys between Key Servers and group members, the
 addressing issues for the multicast distribution of keying material,
 and the scalability or other performance requirements for multicast
 key management [RFC2627, BMS].  Key Servers and group members may
 take advantage of a common Public Key Infrastructure (PKI) for
 increased scalability of authentication and authorization.
 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, this security
 service takes into account the key management requirements for IP

Hardjono & Weis Informational [Page 20] RFC 3740 Multicast Group Security Architecture March 2004

 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 GDOI [RFC3547] or application-layer multicast
 security).
 This security service also describes the functionality of the
 communication related to key management among different GCKS servers
 in a distributed group design.
 Multicast Key Management appears in both the centralized and
 distributed designs as shown in Figure 2 and is placed in the Group
 Key Management Area.

5.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
 [RFC2748].  Thus, it may not be necessary to re-invent a separate
 architecture for multicast security policy.  At minimum, however,
 this security service will be 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 GCKS to
 an instance of 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.  Group members are not expected to directly
 participate in this security service.  However, this option is not
 ruled out.

Hardjono & Weis Informational [Page 21] RFC 3740 Multicast Group Security Architecture March 2004

6. Security Considerations

 This document describes an architectural framework for protecting
 multicast and group traffic with cryptographic protocols.  Three
 functional areas are identified within the framework.  Each
 functional area has unique security considerations, and these are
 discussed below.
 This architectural framework is end-to-end, and does not rely upon
 the network that connects group controllers and group members.  It
 also does not attempt to resolve security issues in the unicast or
 multicast routing infrastructures, or in multicast admission control
 protocols.  As such, denial of service, message deletion, and other
 active attacks against the unicast or multicast routing
 infrastructures are not addressed by this framework.  Section 1.1
 describes the relationship of the network infrastructure to the
 multicast group security architecture.

6.1. Multicast Data Handling

 Cryptographic protocols protecting multicast data are responsible for
 providing confidentiality and group authentication.  They should also
 be able to provide source authentication to uniquely identify senders
 to the group.  Replay protection of multicast data is also desirable,
 but may not always be possible.  This is due to the complexity of
 maintaining replay protection state for multiple senders.  Section
 3.1 elaborates on the security requirements for this area.

6.2. Group Key Management

 Group key management protocols provide cryptographic keys and policy
 to group members.  They are responsible for authenticating and
 authorizing group members before revealing those keys, and for
 providing confidentiality and authentication of those keys during
 transit.  They are also responsible for providing a means for
 rekeying the group, in the case that the policy specifies a lifetime
 for the keys.  They also are responsible for revocation of group
 membership, once one or more group members have had their
 authorization to be a group member revoked.  Section 3.2 describes
 the security requirements of this area in more detail.

6.3. Multicast Security Policies

 Cryptographic protocols providing multicast security policies are
 responsible for distributing that policy such that the integrity of
 the policy is maintained.  If the policy itself is confidential, they
 also are responsible for authenticating group controllers and group
 members, and providing confidentiality of the policy during transit.

Hardjono & Weis Informational [Page 22] RFC 3740 Multicast Group Security Architecture March 2004

7. Acknowledgements

 Much of the text in this document was derived from two research
 papers.  The framework for this document came from a paper co-
 authored by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete
 Dinsmore.  Description of the GSA came from a document co-authored by
 Hugh Harney, Mark Baugher, and Thomas Hardjono.  George Gross
 suggested a number of improvements that were included in later
 versions of this document.

8. References

8.1. Normative References

 [RFC2401]    Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.
 [RFC2408]    Maughan, D., Shertler, M., Schneider, M. and J. Turner,
              "Internet Security Association and Key Management
              Protocol", RFC 2408, November 1998.

8.2. Informative References

 [ACLNM]      J. Arkko, et. al., "MIKEY: Multimedia Internet KEYing",
              Work in Progress, December 2003.
 [BCCR]       M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, "MESP: A
              Multicast Framework for the IPsec ESP", Work in
              Progress, October 2002.
 [BCDL]       M. Baugher, R. Canetti, L. Dondeti, F.  Lindholm, "Group
              Key Management Architecture", Work in Progress,
              September 2003.
 [BMS]        D. Balenson, D. McGrew, A. Sherman, Key Management for
              Large Dynamic Groups: One-Way Function Trees and
              Amortized Initialization,
              http://www.securemulticast.org/draft-balenson-
              groupkeymgmt-oft-00.txt, Work in Progress, February
              1999.
 [CCPRRS]     Canetti, R., Cheng P. C., Pendarakis D., Rao, J.,
              Rohatgi P., Saha D., "An IPSec-based Host Architecture
              for Secure Internet Multicast",
              http://www.isoc.org/isoc/conferences/ndss/2000/
              proceedings/028.pdf, NDSS 2000.

Hardjono & Weis Informational [Page 23] RFC 3740 Multicast Group Security Architecture March 2004

 [Din]        Dinsmore, P., Balenson, D., Heyman, M., Kruus, P.,
              Scace, C., and Sherman, A., "Policy-Based Security
              Management for Large Dynamic Groups:  An Overview of the
              DCCM Project," DARPA Information Survivability
              Conference and Exposition,
              http://download.nai.com/products/media/nai/doc/discex-
              110199.doc.
 [GSAKMP]     H. Harney, et. al., "GSAKMP", Work in Progress, October
              2003.
 [Har1]       Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Specification", RFC 2093, July 1997.
 [Har2]       Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Architecture", RFC 2094, July 1997.
 [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.
 [PCW]        Perrig, A., Canetti, R. and B. Whillock, TESLA:
              Multicast Source Authentication Transform
              Specification", Work in Progress, October 2002.
 [RFC2362]    Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,
              Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma,
              P. and L. Wei, "Protocol Independent Multicast-Sparse
              Mode (PIM-SM): Protocol Specification",  RFC 2362, June
              1998.
 [RFC2406]    Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.
 [RFC2406bis] Kent, S., "IP Encapsulating Security Payload (ESP)",
              Work in Progress, March 2003.
 [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.
 [RFC2627]    Wallner, D., Harder, E. and R. Agee, "Key Management for
              Multicast: Issues and Architectures", RFC 2627,
              September 1998.
 [RFC2663]    Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

Hardjono & Weis Informational [Page 24] RFC 3740 Multicast Group Security Architecture March 2004

 [RFC2748]    Durham, D., Ed., Boyle, J., Cohen, R., Herzong, S.,
              Rajan, R. and A. Sastry, "COPS (Common Open Policy
              Service) Protocol", RFC 2748, January 2000.
 [RFC3019]    Haberman,  B. and R. Worzella, "IP Version 6 Management
              Information Base for The Multicast Listener Discovery
              Protocol", RFC 3019, January 2001.
 [RFC3376]    Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
              Thyagarajan, "Internet Group Management Protocol,
              Version 3", RFC 3376, October 2002.
 [RFC3453]    Luby, M., Vicisano, L., Gemmell, J., Rizzo, M., Handley,
              M. and J. Crowcroft, "The Use of Forward Error
              Correction (FEC) in Reliable Multicast", RFC 3453,
              December 2002.
 [RFC3547]    Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
              Group Domain of Interpretation", RFC 3547, December
              2002.
 [STW]        M., Steiner, Tsudik, G., Waidner, M., CLIQUES: A New
              Approach to Group key Agreement, IEEE ICDCS'98 , May
              1998.

9. Authors' Addresses

 Thomas Hardjono
 VeriSign
 487 E. Middlefield Rd.
 Mountain View, CA 94043, USA
 Phone:(650) 426-3204
 EMail: thardjono@verisign.com
 Brian Weis
 Cisco Systems
 170 W. Tasman Drive,
 San Jose, CA 95134-1706, USA
 Phone: (408) 526-4796
 EMail: bew@cisco.com

Hardjono & Weis Informational [Page 25] RFC 3740 Multicast Group Security Architecture March 2004

10. Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78 and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Hardjono & Weis Informational [Page 26]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3740.txt · Last modified: 2004/03/29 16:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki