INTERNET DRAFT G. Gross Multicast Security working group IdentAware Security Expires: January 4 2004 July 4 2004 The Group Security Association Key Management Protocol Application to the IP Security Architecture Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright (C) The Internet Society (2004), All Rights Reserved Abstract The Group Security Association Key Management Protocol (GSAKMP)is a distributed secure multicast framework and key management protocol. This specification defines the GSAKMP profile for the IP security architecture version 2 and extends the base GSAKMP protocol with the Security Association Management (SAM) message. The GSAKMP IPsec policy token explicitly authorizes which group members may exercise the speaker privilege. When an authorized group speaker endpoint multicasts a SAM message to a GSAKMP group, the SAM message configures that group's Security Policy Databases and Security Association Databases in compliance to a template within the GSAKMP IPsec policy token. In addition, this specification profiles the three supporting components: RFC2401-bis compliant IP security subsystem, Negative-acknowledgement Oriented Reliable Multicast (NORM) protocol handler, and the X.509 Public Key Infrastructure. Gross Expires January, 2005 page 1 GSAKMP Application to the IP Security Architecture July, 2004 1 GSAKMP IP Security Architecture Overview...............4 1.1.......................................GSAKMP Profile 5 1.2........................IP Security Subsystem Profile 7 1.3............GSAKMP IP Security Policy Token Extension 7 1.4....NACK Oriented Reliable Multicast Protocol Profile 7 1.5...................Interactions with NAT and Mobility 8 1.6........Group Speaker Security Association Management 8 1.7....................Public Key Infrastructure Profile 8 2 Terminology and Definitions of Terms...................9 3 GSAKMP IPsec Identifier and Addressing Architecture...11 3.1...........................GSAKMP Group Node Identity 11 3.1.1 Node Identity as a Unicast IP-v6 Address 12 3.1.2 Node Identity Public Key Certificate 13 3.1.3 Secure Identity to Address Mapping Database 13 3.2........................GSAKMP IPsec Group Identifier 14 3.3.....GSAKMP IPsec Transport Layer Endpoint Identifier 15 3.3.1 Transport Layer Endpoint Identifier Definition 15 3.3.2 Application Endpoint Signature Certificate 16 3.3.3 Transport Endpoint Binding Attribute Certificate 17 3.4.....Receiver Multicast Packet Distributor Identifier 18 3.5......GSAKMP Group Any Source Multicast IP-v6 Address 19 3.6.GSAKMP Group Source-Specific Multicast IP-v6 Address 20 3.7.................GSAKMP Group Multicast IP-v4 Address 20 4 GSAKMP IP Security Implementation Profile.............20 4.1..............................GSAKMP Security Suite 2 21 4.2...............Group Re-Keying Algorithm and Protocol 21 4.3..............GC/KS Re-Key Group Security Association 22 4.4.........................................Verbose Mode 22 4.5......Identification and Signature's Identifier Types 23 4.6................Lack Of Acknowledgement (LOA) Message 23 4.7.....Registration Exchange Transport Layer Parameters 23 4.8......GSAKMP Registration Protocol Exchange Extension 23 4.9De-Registration Security Association Protocol Exchange 27 4.10..................GSAKMP Autonomous Distributed Mode 27 4.11....................Group Owner Management Interface 28 4.12..............GSAKMP Node Local Management Interface 28 4.13.Coordinating Security Policies Between Group Owners 29 5 GSAKMP IP Security Subsystem Profile..................29 5.1.....GSAKMP Requirements on the IP Security Subsystem 30 5.2....Authentication Header Group Security Associations 31 5.3..........Secure Multicast Application Service Models 32 5.3.1 Unidirectional Multicast Applications 32 5.3.2 Bi-directional Reliable Multicast Applications 32 5.3.3 Any-To-Any Multicast Applications 33 5.4....Co-Existence of Multiple Key Management Protocols 33 Gross Expires January, 2004 page 2 GSAKMP Application to the IP Security Architecture July, 2004 5.5...................................ESP GSA Properties 34 5.6...............Concurrent GSA Life Spans and Rollover 35 5.7....Multiple Group Speakers and Source Authentication 37 5.8...............GSAKMP IPsec Interactions with the PAD 38 5.9.....Security Policy Database Symbolic Name Selectors 38 5.10.............Tunnel Mode Group Security Associations 40 5.11..........Multicast Packet Distributor Policy Action 40 5.11.1 Basic and Composite GSAKMP Groups 41 5.11.2 Transmitter Multicast Packet Distributor 42 5.11.3 Receiver Multicast Packet Distributor 43 5.12............................UDP Encapsulated ESP GSA 43 6 GSAKMP Interactions with NAT and Mobility.............43 6.1SPD Losses Synchronization with Internet Layer's State 44 6.1.1Mobile Multicast Care-Of Address Route Optimization 44 6.1.2 NAT Translation Mappings Are Not Predictable 44 6.2..........Secondary Problems Created by NAT Traversal 45 6.2.1 SSM Routing Dependency on Source IP Address 45 6.2.2 ESP Cloaks Its Payloads from NAT Gateway 45 6.2.3 UDP Checksum Dependency on Source IP Address 46 6.2.4 Can Not Use AH with NAT Gateway 46 6.3...Avoidance of NAT Using an IP-v6 Over IP-v4 Network 46 6.4............GSAKMP Multi-Realm IP-v4 NAT Architecture 48 6.4.1 GSAKMP IP-v4 NAT Architectural Assumptions 48 6.4.2 Representative GSAKMP Multi-Realm Configuration 50 6.4.3 Registration Security Association NAT Traversal 51 6.4.4 GSAKMP Re-key GSA NAT Traversal 52 6.4.5 Application GSA NAT Traversal 52 7 Security Association Management Message...............54 7.1GSAKMP Security Association Management Message Syntax 55 7.2.............................SAM Message Verification 57 7.3.SAM Message Processing After Successful Verification 58 7.4........Identity to Transient Address Mapping Payload 59 7.5...........Security Association Configuration Payload 63 7.6........................Security Association Template 67 7.7..........GC/KS Co-located at the Transit NAT Gateway 68 7.8....................SAM Notification Payload Handling 68 8 NACK-Oriented Reliable Multicast Protocol Profile.....68 8.1.............GSAKMP/NORM Subsystem Mandatory Features 69 8.2..................Forward Error Correction Algorithms 70 8.3...................Group-wide Default Path MTU Length 70 9 GSAKMP IP Security Public Key Infrastructure Profile..71 9.1.Identification and Signature Payload Signer ID Types 71 9.2...........Application Endpoint Signature Certificate 72 9.2.1 Subject Field Distinguished Name 72 9.2.2 SubjectAltName Extension 72 Gross Expires January, 2004 page 3 GSAKMP Application to the IP Security Architecture July, 2004 9.2.3 Issuer Field 72 9.2.4 Key Usage and Extended Key Usage Fields 72 9.3.....................GSAKMP Certificate Payload Types 73 9.4......Node Identity End-Entity Public Key Certificate 73 9.4.1 Subject and SubjectAltName Extension 73 9.4.2 Unique Identifiers 74 9.4.3 Key Usage and Extended Key Usage Extensions 74 9.4.4 Certificate Policies Extension 74 9.4.5 Subject Key Identifier Extension 74 9.4.6 Authority Key Identifier Extension 74 9.4.7 Basic Constraints Extension 74 9.5...Group Trust Anchor Public Key Certificate Key-ring 74 9.6.....Transport Endpoint Binding Attribute Certificate 75 9.6.1 IssuerName Field 75 9.6.2 Holder Field 75 9.6.3 TEBAC Issuer Signature Algorithm 75 9.6.4 Validity Period and TEBAC Revocation Strategy 75 9.6.5 Attribute Certificate Targeting Extension 76 9.6.6 Group Attribute Type 76 9.6.7 Access Identity Attribute Type 76 9.6.8 Optional Attribute Types 78 10.................................Security Considerations 78 11.....................................IANA Considerations 78 11.1...................GSAKMP IPsec Specific Allocations 78 11.2.............................SAM Message Nonce Types 79 11.3GSAKMP IP Security Specific Notify Payload Error Codes 79 12........................................Acknowledgements 80 13....................................Normative References 80 14..................................Informative References 80 15..............................Author Contact Information 82 16.........................Intellectual Property Statement 82 17.....................................Copyright Statement 82 18....................................Disclaimer Statement 83 19..............................................APPENDIX A 83 1 GSAKMP IP Security Architecture Overview The Group Security Association Key Management Protocol (GSAKMP) base specification [GSAKMP] provides a distributed, application independent secure multicast framework and key management protocol. Figure 1 illustrates the GSAKMP mapping to the IP security architecture. The primary goal of the GSAKMP IP Security application is to assure inter-operable implementations across all facets of the IP security Gross Expires January, 2004 page 4 GSAKMP Application to the IP Security Architecture July, 2004 architecture shown in figure 1. The GSAKMP IP Security application builds on the revised IP multicast security [RFC2401-bis] capabilities that were not available in the predecessor IP security architecture [RFC2401]. Implementations that claim compliance to this GSAKMP IPsec application standard MUST support all of this document's mandatory to implement GSAKMP IPsec application-specific features, GSAKMP protocol extensions, and profiled parameters for the supporting architectural components. The GSAKMP IPsec application specifications divide into seven categories, as described in the ensuing sections. Although figure 1 only shows a monolithic GSAKMP component, all GSAKMP IPsec implementations MUST be capable of operating in Group Member (GM) role, or Subordinate Group Control/Key Server (S-GC/KS) role. Local policy sets the role authorization for a Node on a per group basis. A Node MAY also be capable of acting in the Primary Group Control/Key Server (P-GC/KS) role. Unless qualified to the contrary, the term "GC/KS" refers interchangeably to either a Subordinate GC/KS or a Primary GC/KS. The Group Owner component interacts with the Primary GC/KS through a private interface or protocol that is outside the scope of this standard. 1.1 GSAKMP Profile The GSAKMP base specification offers numerous options, and it defers the definition of application specific semantics to other documents. Section 4 prescribes the mandatory set of must implement options when applying GSAKMP to the IP security architecture. Wherever there are application-specific omissions or ambiguities in the GSAKMP base specification, this specification interprets what must be done to assure protocol interoperability between independently produced GSAKMP IPsec implementations. This includes the GSAKMP IPsec management interface configuration capabilities, such that any two implementations can be administered to inter-operate. Gross Expires January, 2004 page 5 GSAKMP Application to the IP Security Architecture July, 2004 +-----------+ +----+---------------------------------+--------+ | multicast <====>SIAM| Group Security Association Key | Group | |application|(C2)| | Mgmnt. Protocol (GSAKMP) IPsec | Owner | +-/\-----/\-+ +----+-/\------------/\------A----A----+-A------+ || || || || | | | || || || || | +------| (D0) (D1) (D2) (D3) (C0) (C1) || || || || | | || || || || | +-------V------+ || || || || | | Public Key | || || || || | |Infrastructure| || || || || | | subsystem | || || || || | +--------------+ || || || || | || +--\/-------------\/---+ || | || |Negative-ack Oriented | || | || | Reliable Multicast | || | || |(NORM) protocol subset| || | || +---------/\-----------+ || | || || || | || || || | +-\/------------\/--------------------\/-+ | | U s e r D a t a g r a m | | | P r o t o c o l ( U D P ) | | +---------------/\-----------------------+ | || | || | +---------------\/----------------------------V---+ | I P S e c u r i t y S u b s y s t e m | | +--------------------------------+ | | | Security Policy Database (SPD) | | | +--------------------------------+ | | | Security Assoc. Database (SAD) | | | +--------------------------------+ | | | Peer Authoriztn. Database (PAD)| | | +--------------------------------+ | +----------------------/\-------------------------+ || || +----------------------\/-------------------------+ | I n t e r n e t P r o t o c o l ( I P ) | | | | V 4 o r V 6 L a y e r | +-------------------------------------------------+ Figure 1 GSAKMP IP security architectural model Gross Expires January, 2004 page 6 GSAKMP Application to the IP Security Architecture July, 2004 1.2 IP Security Subsystem Profile Section 5 profiles the GSAKMP requirements on its underlying IPsec subsystem that assure inter-operability between all GSAKMP IPsec endpoints and co-existence with IKE-v2 [IKE-V2]. 1.3 GSAKMP IP Security Policy Token Extension The GSAKMP IP Security policy token extension manages the group's one or more Group Security Association (GSA) and other security policy configuration for an RFC2401-bis compliant Security Policy Database (SPD), Security Association Database (SAD), and the Peer Authorization Database (PAD). The GSAKMP IPsec policy token extension is an application specific branch under the GSAKMP core policy token schema [COREPT]. The GSAKMP IPsec policy token design is a subset of the IP security policy information model [RFC3585] with accommodations for secure multicast and the architectural features present in RFC2401-bis. The SNMP SPD configuration MIB [SPDMIB] is another major design influence on the GSAKMP IPsec policy information model. This document only introduces the IPsec policy token concepts; reference [IPSECPT] formally specifies the GSAKMP IPsec policy token extension. 1.4 NACK Oriented Reliable Multicast Protocol Profile GSAKMP depends on a reliable multicast transport layer to deliver its group-wide multicast messages. In particular, the GSAKMP GC/KS multicasts the Re-Key Event (RKE) message containing the GSAKMP IPsec policy token and group re-keying material to all of the group's members. The RKE message is often large enough that when it is fragmented to match the multicast path maximum transmission unit size, the RKE becomes susceptible to unacceptably high error rates. The GSAKMP base specification only defines a simple time-out based retransmissions scheme and it does not specify the reliable multicast transport layer. This document specifies a profile on the Negative-acknowledgement Oriented Reliable Multicast (NORM) protocol [NORM] that is more robust against GSAKMP multicast message fragment losses than simple multicast retransmission over UDP. Section 8 specifies the NORM protocol profile. Gross Expires January, 2004 page 7 GSAKMP Application to the IP Security Architecture July, 2004 1.5 Interactions with NAT and Mobility The GSAKMP IP Security mapping must accommodate the negative impact of IP-v4 Network Address Translation (NAT) [RFC2663] [RFC3022] and mobility induced changes in a multicast speaker's source IP address. Both of these issues require a GSAKMP mechanism to synchronize a group's SPD/SAD traffic selectors with unannounced changes in the Internet layer's state. The absence of a SPD/SAD synchronization mechanism can cause the group's data traffic to be discarded rather than processed correctly. NAT and mobility are also at the root of a litany of secondary GSAKMP architectural problems that would also benefit from a solution. This specification defines a new GSAKMP protocol extension, the "Security Association Management" (SAM) message, which mitigates these problems by announcing to the GSAKMP group membership any changes in a multicast speaker's IP interface address set. A GSAKMP IPsec implementation may offer access to its Secure Identity Address Mapping (SIAM) database (see (C2) in figure 1) to those peer components that need to know these authenticated mappings. Section 6 examines these NAT and mobility problems and section 7 goes on to specify the SAM message solution. 1.6 Group Speaker Security Association Management The GSAKMP IPsec application treats the Group Speaker role as a security policy managed privilege. The motivation is the observation that in the absence of per packet source authentication, multicast can be a powerful tool in a denial of service attack. The GSAKMP IPsec application introduces the Security Association Management (SAM) message as part of a new Group Speaker authorization process. An important SAM message benefit is that it allows a Group Speaker to independently manage its set of GSA within the constraints dictated by the IPsec policy token. The Group Speaker does not incur the overhead of a policy token revision signed by the Group Owner every time that the Group Speaker creates, modifies, or destroys one of its GSA. 1.7 Public Key Infrastructure Profile The GSAKMP IPsec mapping is inter-dependent with a Public Key Infrastructure (PKI)characterized by diversity in its standards and its deployments. This specification profiles those aspects of GSAKMP Identification payloads, X.509v3 public key certificate fields, and GSAKMP Certificate payloads needed to assure that conformant GSAKMP Gross Expires January, 2004 page 8 GSAKMP Application to the IP Security Architecture July, 2004 IPsec implementations can be configured to inter-operate with each other and with a standards-based PKI deployment. A major influence on this profile is [PKI4IPSEC]. However, this specification and its successors takes precedence for the GSAKMP IPsec profile. Section 9 specifies the PKI related profile parameters, including those aspects that must be configurable at the PKI management interface. 2 Terminology and Definitions of Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. This document makes reference to the following terms, acronyms, and definitions: . AH - Authentication Header . Composite group . DSCP - Differentiated Services Control Point . ESP - Encapsulating Security Payload . GC/KS - Group Controller/Key Server . GM - Group Member . GO - Group Owner . Group Receiver . Group Speaker . GSA - Group Security Association . GTAK - Group Traffic Authentication Key . GTEK - Group Traffic Encryption Key . ITAM - Identity to Transient Address Mapping GSAKMP payload . KDL - Key Down-Load message . Leading edge GSA Gross Expires January, 2004 page 9 GSAKMP Application to the IP Security Architecture July, 2004 . NAT - Network Address Translation . NAPT - Network Address/Port Translation . Node . Node Identity . NORM - Negative-acknowledgement Reliable Multicast protocol . PAD - Peer Authorization Database . PKI - Public Key Infrastructure . Primary-GC/KS . RKE - Re-Key Event message . RTD - Request-To-Depart message . RTJ - Request To Join message . SAC - Security Association Configuration GSAKMP payload . SAD - Security Association Database . SAM - Security Association Management message . SIAM - Secure Identity to Address Mapping database . SPD - Security Policy Database . SPI - Security Parameter Index . Subordinate GC/KS . TEBAC - Transport Endpoint Binding Attribute Certificate . Trailing edge GSA . Transport endpoint identifier . UDP - User Datagram Protocol Gross Expires January, 2004 page 10 GSAKMP Application to the IP Security Architecture July, 2004 3 GSAKMP IPsec Identifier and Addressing Architecture The GSAKMP IPsec application defines a set of identifier name space conventions that assure inter-operable usage and allocation of the objects and architectural entities referenced by the GSAKMP IPsec policy token. The GSAKMP IPsec policy token in combination with a SAM message configures the group's SPD traffic selectors at both the Internet and transport protocol layers. To assure interoperable GSAKMP implementations, this section explains the information model relationships between the identifiers found at the Internet layer's multicast service, the multicast transport layer, and the multicast application layer. 3.1 GSAKMP Group Node Identity GSAKMP IPsec groups require a multicast application endpoint addressing scheme wherein the endpoint's Node identifier remains constant despite a GSAKMP group's membership straddling two sources of change in its IP addresses: - A mobile Node will change one or more of its IP interface addresses after each move between IP networks. These changes in IP address make it difficult to depend on an IP source address for the source-specific multicast security policies configured in the group's SPD traffic selectors. - Secure multicast GSA interactions with IP-v4 Network Address Translation (NAT) gateways also negatively impact those SPD entries that refer to source IP-v4 addresses. Refer to section 6 for an explanation. The "Node Identity" is the permanent GSAKMP IPsec handle that refers to the IP protocol stack (and its companion IPsec subsystem) residing within a physical Node. Unlike the Node's one or more transient IP interface addresses, the Node Identity does not change when the Node changes its location. Since the Node Identity is constant, the Group Owner can consistently enforce its security policies with respect to a Node Identity. See [NSRG] for additional architectural motivation. A Node Identity is structured as an IP-v6 address, but it is not intended to be unicast routable in the global Internet. Instead, it Gross Expires January, 2004 page 11 GSAKMP Application to the IP Security Architecture July, 2004 is better understood as an Internet layer Node identifier bound to a transient set of one or more locator IP addresses. 3.1.1 Node Identity as a Unicast IP-v6 Address Regardless of whether a GSAKMP group will be using IP-v6 or IP-v4 as its multicast datagram delivery service, the Group Owner MUST assign each Node participating in a GSAKMP group a "Node Identity" IP-v6 address. A Node Identity is a globally unique local unicast IP-v6 address as defined by [LCLUNIQ]. The Group Owner permanently allocates the Node Identity from a network prefix reserved for the exclusive use of the GSAKMP groups that the Group Owner administratively owns and manages. Note that the Node Identity's lifetime transcends a particular group membership cycle. In other words, a Node joins a group using the same Node Identity across all instances of its membership in any group managed by the Node's Group Owner. The Node Identity comprises the following fields: - Globally unique local unicast address prefix: FC00::/7. - GSAKMP Group Owner's global identifier prefix, 40 random bits - as described in [LCLUNIQ] section 3.2. One additional bit selects central versus local prefix assignment. The global identifier prefix MUST NOT have the value of zero. The GSAKMP group network prefix MUST NOT be an IP-v6 prefix delegation from a RIR or ISP. Instead, the Group Owner MUST allocate its GSAKMP network prefix from the IP-v6 globally unique local unicast address space. This provider independent network prefix MAY be generated pseudo- randomly by a local procedure, or it MAY be allocated by the central allocation authority that assures its global uniqueness within the IP-v6 address pool. The Group Owner management interface MUST support both allocation procedures. - GSAKMP group sub-net identifier, 16 bits - This field corresponds to the "sub-net identifier" field defined in [LCLUNIQ]. When not explicitly set by policy, the GSAKMP group sub-net identifier SHOULD be set to a default value of zero. The Group Owner MAY assign non-zero GSAKMP group sub-net identifiers to represent policy defined Node Identity ranges or aggregates. GSAKMP group sub-net identifiers make it convenient for SPD traffic selectors to enforce security policies on logical subsets of a group's membership. For example, a group sub-net identifier MAY refer to the Node population that belongs to a sub-group within a composite Gross Expires January, 2004 page 12 GSAKMP Application to the IP Security Architecture July, 2004 group (see section 5.11.1). The GSAKMP group sub-net identifier SHOULD NOT represent a sub-group's topological point of attachment to the global Internet. A Node MAY have multiple Node Identities that are aliases for the same physical Node, each alias having a distinct GSAKMP group sub-net identifier but a common Interface Identifier. Each such alias has an associated Node Identity public key certificate, although all of the certificates refer to the same key pair.. - Interface Identifier, 64 bits - The Group Owner MUST assign this value to be unique relative to all other Nodes for which it controls the GSAKMP group memberships. The Modified EUI-64 "u" bit MUST be set to zero (i.e. local scope). The Group Owner SHOULD assign the Interface Identifier's value to be the low-order 64 bits of the Node Identity's public key. If a Node is registered with multiple Group Owner's, then its Node Identity's Interface Identifier SHOULD be the same value across all of those Group Owners. 3.1.2 Node Identity Public Key Certificate A Node MUST have an associated X.509 end-entity signature certificate with its IP-v6 address "SubjectAltName" field set to the Node Identity IP-v6 address. Section 9.4 profiles this certificate. The Node Identity MUST have a valid certificate path rooted at one of the GSAKMP group's trust anchor Certificate Authorities. The Group Owner MAY be the Node Identity's Certificate Authority. The Node Identity's signature substantiates its assertions about its interface IP addresses, and proxies the signatures of the application endpoints that reside on that Node. 3.1.3 Secure Identity to Address Mapping Database Each Node in a GSAKMP group maintains a Secure Identity Address Mapping (SIAM) database. The SIAM database contains the Node Identity to transient IP address set mappings for all of the relevant peer Nodes in the group. See section 7 for the discussion of how a Node populates its SIAM. One of the GSAKMP IPsec implementation's responsibilities is maintaining an accurate 1:1 mapping in the SIAM database between the dynamic 4-tuple: - Source transient IP address (either IP-v4 or IP-v6), Gross Expires January, 2004 page 13 GSAKMP Application to the IP Security Architecture July, 2004 - Source transient IP-v4 address after NAT gateway translation, - Destination multicast IP address (either IP-v4 or IP-v6). - Security Association's Security Parameter Index And the corresponding static 3-tuple representing a multicast application Group Speaker endpoint: - Group Speaker Node Identity, - Next layer protocol identifier, - Multicast application's source port number, RFC2401-bis compliant SPD traffic selectors refer to the transient IP addresses rather than quantities that remain stable during a group membership life span. Consequently, GSAKMP IPsec defines an efficient yet secure GSAKMP protocol extension, the Security Association Management message, to synchronize the group's SPD traffic selectors whenever there is an update to the above mapping. See section 7 for more information about this mechanism. 3.2 GSAKMP IPsec Group Identifier The "GSAKMP IPsec Group Identifier" MUST be an "IP-v6" Group Identification type as defined by [GSAKMP] section 7.1 table 11. The GSAKMP IPsec Group Owner assigns the GSAKMP IPsec Group Identifier by combining three components: . GSAKMP group serial number _ A permanent pseudo-random unsigned 64 bit serial number that is unique relative to all of the GSAKMP IPsec groups created and managed by the Group Owner. In [GSAKMP] section 7, this component is referred to as a "Random Value", although it remains constant for the duration of the group's lifetime. . Group Owner's global identifier prefix, which is the high-order 48 bits of a Node Identity as defined in section 3.1. . IP-v6 group identifier, an unsigned 32-bit integer that is unique relative to the Group Owner global identifier prefix. The IP-v6 group identifier MUST be a dynamic group allocation from the range specified in [RFC3307] section 4.3.1 for a server address allocation. Gross Expires January, 2004 page 14 GSAKMP Application to the IP Security Architecture July, 2004 The GSAKMP IPsec Group Identifier when further qualified by a four octet sequence number refers to a particular GSAKMP IPsec policy token that the Group Owner has issued for that GSAKMP group. The sequence number SHOULD advance monotonically by one for each policy token signed by the Group Owner. When encoded as the Group ID Value within a GSAKMP header, the GSAKMP IPsec Group Identifier complies with [GSAKMP] section 7.1.1.1.4, with the IP-v6 value field set to the group's IP-v6 multicast address as defined by this document's section 3.5 (or section 3.6 if the group uses Source-Specific Multicast). 3.3 GSAKMP IPsec Transport Layer Endpoint Identifier A GSAKMP IPsec transport layer endpoint identifier refers to an active group membership held by an application endpoint within a Node. Typically, a transport layer endpoint is instantiated as a individual process or file descriptor (e.g. socket) within a Node. Other equivalent implementation mechanisms are possible, but for the sake of clarity of exposition this specification refers to the well- known socket model. 3.3.1 Transport Layer Endpoint Identifier Definition A GSAKMP IPsec transport layer endpoint identifier is a 3-tuple formed from the following components: - Node Identity of the Node hosting the application endpoint, as defined in section 3.1. - Next layer protocol identifier _ Identifies the multicast application's transport layer protocol(e.g. UDP or a reliable multicast transport protocol). - Multicast application source port number _ The transport layer identifier dynamically assigned by a Node to represent a multicast application's endpoint context state. For example, an application's endpoint context state could be a socket file descriptor. The Node MUST assign a transport layer endpoint instance its source port number before the GC/KS authorizes that application's endpoint to become a GSAKMP group member. The source port number when qualified by its next layer protocol identifier MUST be unique relative to all other source port numbers assigned by that Node. The Gross Expires January, 2004 page 15 GSAKMP Application to the IP Security Architecture July, 2004 source port number is GSAKMP group-wide unique when qualified by its Node Identity and next layer protocol identifier. Associated with each transport layer endpoint instance are the following properties: - GSAKMP IPsec Group Identifier without its policy token sequence number qualifier, as defined in section 3.2. - Group Speaker endpoint mode or Group Receiver endpoint mode - Multicast application destination port number _ The multicast application's statically assigned transport layer identifier. The destination port number has the same value across all endpoints participating in the multicast application. Generally, the multicast application destination port number is configured to imply a particular GSAKMP IPsec Group Identifier. However, an implementation defined mechanism MAY dynamically choose the binding between an application and a GSAKMP group. Within a Node, multiple Group Receiver transport layer endpoints could open and bind to the same multicast application destination port number using an implementation defined mechanism. Each authorized endpoint receives a decrypted copy of the group's multicast transmissions addressed to that destination port number. For the multicast application's Group Speaker transport layer endpoints, one or more endpoints on a common Node could register with a GSAKMP group using an implementation defined mechanism. Once the GC/KS authorizes a transport layer endpoint to become a Group Speaker, then that endpoint can transmit encrypted datagrams to the GSAKMP group. The multicast datagrams originating from a Group Speaker endpoint will have a unique source port number relative to the datagrams originating from the other multicast speakers on the same Node. 3.3.2 Application Endpoint Signature Certificate At the GSAKMP IPsec application layer, an X.509 signature identity represents the application endpoint. The application endpoint signs an attribute certificate that binds its X.509 signature identity to a transport layer endpoint identifier and a Node Identity. Every application endpoint participating in a GSAKMP group MUST have a X.509v3 signature public key certificate with a valid certificate path rooted at one of the GSAKMP group's trust anchor Certificate Gross Expires January, 2004 page 16 GSAKMP Application to the IP Security Architecture July, 2004 Authorities. It MUST possess the corresponding signature secret key for that public key. Section 9.2 defines this certificate's profile. The application endpoint's signature certificate should not be confused with the Node Identity certificate described in section 3.1.2. The former certificate is an application layer endpoint identity, whereas the Node Identity certificate represents an Internet layer identity (e.g. the Node's operating system). There may be one or more multicast application endpoint identities co- resident on a common Node, each with its own signature public key certificate and associated secret key. 3.3.3 Transport Endpoint Binding Attribute Certificate An application endpoint's signature identity does not necessarily represent an application process itself, rather it may be representing an end user's identity. In such cases, an end user visiting a Node would have only a temporary relationship with that Node. The GSAKMP IPsec application uses a "Transport Endpoint Binding Attribute Certificate" (TEBAC) to cryptographically bind the application endpoint identity and the Node Identity. Whenever an application endpoint requires GSAKMP group management services, it first issues a TEBAC that delegates to its Node's GSAKMP subsystem the authority to: . Sign the GSAKMP registration or de-registration protocol messages that the Node exchanges with the GC/KS. The GSAKMP subsystem proxies the application endpoint's signature by signing with its Node Identity secret key. . Bind the transport endpoint identifier to the application endpoint's X.509 identity as expressed by its signature certificate. . If in Group Speaker mode, create and modify entries in the Group Receiver endpoints SPD/SAD whenever there is a change in the Node's set of IP addresses. As needed, the Group Speaker's GSAKMP subsystem multicasts a Security Association Management message that installs these SPD/SAD modifications. . If using a multicast source authentication service, sign the ESP or AH protected payloads sent by the multicast application's protocol. Gross Expires January, 2004 page 17 GSAKMP Application to the IP Security Architecture July, 2004 The TEBAC is the output of a local mutual authentication and authorization process between an application endpoint identity and a Node Identity. Although that process is an implementation matter between the Node and the application endpoint, this standard does mandate that process MUST generate a TEBAC conforming to the profile in section 9.6. The TEBAC creation MUST occur before the multicast application endpoint attempts its request to join a GSAKMP group. The TEBAC MUST be among the GSAKMP RTJ message's Certificate payloads. This requirement also applies to the GSAKMP Request-To- Depart message Certificate payloads. The TEBAC "Issuer" field MUST refer to the application endpoint's end-entity signature certificate. Consequently, the certificate's Issuer signature is that of the application endpoint's secret key. The TEBAC attribute fields declare: . GSAKMP IPsec group identifier, . Group Speaker mode or Group Receiver mode, . Destination port number, . Transport endpoint identifier (see section 3.3.1). The certificate's "Holder" field MUST refer to the Node Identity's signature certificate. That certificate's identity is the same as the signer identity that will be used in the forthcoming GSAKMP message's Signature payload. The TEBAC validity period is a matter of local policy, but it MUST at least exceed the expected duration of the GSAKMP protocol exchanges that depend on that TEBAC. 3.4 Receiver Multicast Packet Distributor Identifier Section 5.11 defines the Multicast Packet Distributor policy action component. The Receiver Multicast Packet Distributor is uniquely identified by the 3-tuple: - Group Identifier without its policy token sequence number qualifier, as defined in section 3.2. The Group Identifier implies the next layer protocol identifier and the multicast application's destination port number. - Multicast receiver's Node Identity, Gross Expires January, 2004 page 18 GSAKMP Application to the IP Security Architecture July, 2004 - GSAKMP group's time epoch, expressed as the GSAKMP group identifier's policy token sequence number 3.5 GSAKMP Group Any Source Multicast IP-v6 Address For a GSAKMP IPsec group using an IP-v6 any-source multicast routing service, its IP-v6 multicast address SHOULD be a unicast-prefix- based IPv6 multicast address [RFC3306] [RFC3513] defined as follows: - High-order 8 bits, all ones, - Flags field: The transient group "T" bit must be one except as noted below, the prefix "P" bit must also be one. - Scope field: set as described below, - Reserved field, 8 bits of all zeros (see note below regarding an embedded Rendezvous Point address), - Prefix length field, set to 48 - Unused portion of the network prefix field: 16 bits set to zeros, - Globally unique local unicast prefix: FC00::/7 - Local/central authority prefix allocation bit, - Group Owner global identifier prefix, 40 bits - IP-v6 group identifier as per section 3.2, 32 bits The address's "transient group" bit flag MUST be set unless the GSAKMP group is permanently allocated by IANA. It is RECOMMENDED that the scope be set to either admin-local, site-local, or organization-local. The Group Owner management interface MUST provide the ability to configure the multicast address scope to any legal value. The Group Owner management interface SHOULD provide the ability to configure the Embedded Rendezvous Point address capability [EMBEDRP]. This capability assigns a 4 bit-wide field within the above reserved field for the embedded Rendezvous Point's interface identifier. Gross Expires January, 2004 page 19 GSAKMP Application to the IP Security Architecture July, 2004 3.6 GSAKMP Group Source-Specific Multicast IP-v6 Address For usage with an IP-v6 source-specific multicast routing service, the GSAKMP group's unicast prefix-based IPv6 source-specific multicast address SHOULD use the format defined by RFC3306 section 6. The address's low-order 32 bits are the IP-v6 group identifier as defined in section 3.2. The Group Owner management interface SHOULD provide the ability to configure the Embedded Rendezvous Point address capability [EMBEDRP]. When the GSAKMP group uses IP-v6 Source-Specific Multicast, then a multicast speaker Node SHOULD NOT use its Group Owner assigned Node Identity as its IP-v6 source address for the multicast datagrams that it sends to that GSAKMP group. Instead, the multicast speaker Node MUST use one of the IP-v6 interface addresses declared in its most recent verified Identity to Transient Address Mapping payload. 3.7 GSAKMP Group Multicast IP-v4 Address For a GSAKMP group using IP-v4 multicast service, the IP-v4 multicast address SHOULD be algorithmically derived from the GSAKMP group's IP-v6 multicast address. RFC2529 section 6 [6over4] defines this multicast address derivation procedure. The Group Owner management interface MAY provide the ability to configure an administratively defined alternative GSAKMP group IP-v4 multicast address. 4 GSAKMP IP Security Implementation Profile This section of the GSAKMP IP Security application encompasses three facets of a GSAKMP implementation: - Those attributes and behaviors relevant to when two GSAKMP IPsec implementations are interacting with one another through the unicast GSAKMP protocol exchanges. In figure 1, these protocol exchanges flow over the data path labeled (D3). - The GSAKMP Re-Key Event multicast message and its Re-Key Group Security Association. In figure 1, these protocol exchanges flow over the data path labeled (D2). - GSAKMP management interface configuration capabilities that assure that two independent GSAKMP IPsec implementations can be arranged to inter-operate. Gross Expires January, 2004 page 20 GSAKMP Application to the IP Security Architecture July, 2004 4.1 GSAKMP Security Suite 2 The GSAKMP IPsec mapping Security Suite 2 is a superset of the Security Suite 1 as defined in GSAKMP section 6. Compliant GSAKMP IPsec implementations MUST support the algorithms specified by Security Suite 1 and in addition they MUST support: - Group Owner's policy token digital signature algorithm of RSA with a hash algorithm of MD5 [RFC3447]. - GSAKMP message signature algorithm of RSA with a hash algorithm of MD5. 4.2 Group Re-Keying Algorithm and Protocol The GSAKMP IPsec implementation MUST support Logical Key Hierarchy (LKH) as defined by GSAKMP appendix A. A GSAKMP IPsec implementation MAY support the group re-key protocol and algorithm specified in this document's Appendix A. The GSAKMP IPsec re-keying philosophy is to batch group join and group leave events into a periodic Re-Key Event (RKE) multicast. The benefit is to minimize re-keying overhead even when there is a high membership turnover. In figure 1, the RKE multicast is the data flow labeled (D2). Group policy sets the RKE multicast transmissions frequency. The RKE reliable delivery by default MUST use the NORM protocol (see section 8 for details) and it MAY be configurable on a per group basis to use UDP or another reliable multicast transport protocol besides NORM. The GSAKMP Group Owner management interface MUST provide the ability to adjust the RKE frequency and the associated group keying material lifetime on a per GSAKMP group basis. The RECOMMENDED minimum re-key interval should be tuned to be longer in duration than the NORM protocol's predicted maximum error recovery time. When the RKE multicast is a NORM protocol payload, the NORM|GSAKMP message is encapsulated within a UDP header having the UDP destination port number GSAKMP-NORM-UDP (see section 11.1). The UDP|NORM|GSAKMP payload in turn is ESP protected by the Re-Key GSA. The GSAKMP Group Owner management interface SHOULD have the ability to configure the parameters used by the underlying NORM protocol subsystem on a per group basis. GSAKMP IPsec implementations MUST be able to receive a RKE message up to 65,535 bytes long. Gross Expires January, 2004 page 21 GSAKMP Application to the IP Security Architecture July, 2004 4.3 GC/KS Re-Key Group Security Association A bi-directional Re-Key Group Security Association protects each GC/KS NORM session. See section 5.3.2 for the definition of a bi- directional GSA. Figure 1 shows the Re-key GSA data flow at label (D2). The Re-Key GSA exists for the same lifetime as the multicast application's one or more GSA shown at figure 1 labels (D0) and (D1). When a GSAKMP group operates in the autonomous distributed GC/KS mode (see [GSAKMP] section 4.4.7), then there is a Re-Key GSA for the Primary-GC/KS and a separate Re-Key GSA for each Subordinate- GC/KS. The P-GC/KS GSA membership comprises the P-GC/KS and its one or more S-GC/KS. The S-GC/KS GSA membership is the sub-group of the multicast application's group membership that the S-GC/KS admitted into the group and thereafter manages. The GC/KS is the only authorized multicast speaker in the Re-Key GSA. The Re-Key GSA MUST use the IPsec anti-replay protection service for the GC/KS multicast RKE transmission. The Re-Key GSA multicast transmission MUST have a distribution scope that assures all group members under the management control of their GC/KS will receive the Re-Key Event message. In the group member to GC/KS direction, the Re-key GSA MUST NOT have IPsec anti-replay service enabled. The SPD MUST be setup to allow any currently authorized group member to send a unicast NORM-NACK repair request (or other NORM message) to the GC/KS. If the facility is available, then all NORM messages SHOULD be source authenticated and verified by the GC/KS as belonging to the currently authorized group membership. The GC/KS SHOULD discard messages received from expelled or departed group members before NORM is allowed to process the message. Section 8 defines the NORM profile on which the Re-Key GSA depends. 4.4 Verbose Mode GSAKMP IPsec implementations MUST support Verbose mode. The GSAKMP Group Owner management interface MAY provide the ability to configure Verbose or Terse mode behavior on a per GSAKMP group basis. Gross Expires January, 2004 page 22 GSAKMP Application to the IP Security Architecture July, 2004 4.5 Identification and Signature's Identifier Types Section 9.1 defines the Identification payload ID types defined by [GSAKMP] table 17 that MUST be supported by the registration and de- registration protocol exchanges. Section 9.1 also defines the Signature payload signer ID types declared by [GSAKMP] table 20 that MUST be supported by the registration and de-registration protocol exchanges. 4.6 Lack Of Acknowledgement (LOA) Message The GSAKMP IPsec implementation MUST send and receive the LOA message as defined in GSAKMP section 5.2.1.5. The RECOMMENDED GC/KS timeout interval for sending a LOA is 6 seconds. The Group Owner management interface MAY configure the GC/KS to not send LOA on a per GSAKMP group basis. 4.7 Registration Exchange Transport Layer Parameters The GSAKMP IPsec registration protocol exchange MUST use UDP as its transport layer protocol and it SHOULD NOT use the UDP checksum feature for its signed GSAKMP messages. The RECOMMENDED number of retransmission attempts is 3, with a timeout interval of 3 seconds between retries. It is RECOMMENDED that a candidate group member that receives a RTJ-ERROR response to its RTJ transmission will wait 9 seconds for a delayed Key-Down-Load (KDL) message before giving up and releasing its registration security association state. The GSAKMP IPsec implementation SHOULD provide a local management interface that can tune each of the registration protocol exchange's recommended transport layer parameter values. 4.8 GSAKMP Registration Protocol Exchange Extension The GSAKMP IPsec application explicitly authorizes each of a group's multicast speakers by extending the base GSAKMP registration protocol exchange. Whenever mobility or NAT changes a Group Speaker's transient source IP address, the group's security policy decides how to announce that change to the Group Receiver endpoints. In a strict policy, the Group Speaker must prove the return route-ability of its asserted new source IP address. The Group Speaker executes a GSAKMP re- registration protocol exchange extension to revise the group's view of that address. In a relaxed security policy, the Group Speaker Gross Expires January, 2004 page 23 GSAKMP Application to the IP Security Architecture July, 2004 simply multicasts a Security Association Management message containing an ITAM payload that asserts its new set of IP addresses without substantiation. If a Group Receiver endpoint wants to become a Group Speaker then it MUST re-register with group using a newly created TEBAC that declares a new source port number and requests Group Speaker role authorization. The GSAKMP IPsec application makes the following registration protocol exchange extensions to the procedures specified in [GSAKMP] section 5.2. Both candidate Group Receiver and candidate Group Speaker endpoints MUST execute these registration extensions: 1. Prior to starting the registration protocol exchange, the application endpoint MUST generate an Transport Endpoint Binding Attribute Certificate as described in section 3.3.3. 2. All GSAKMP IPsec candidate Group Member endpoints, both speakers and receivers, MUST be capable of participating in a cookies exchange as defined in [GSAKMP] section 5.2.2.. A candidate Group Speaker and the GC/KS MUST exchange cookies. The cookies exchange proves return route-ability for the candidate Group Member's transient IP address location asserted in the ITAM payload. The Group Owner management interface MUST be able to configure the cookie exchange policy on a per group basis; by default it SHOULD be enabled. 3. The candidate Group Member's Request-To-Join (RTJ) message sent to the GC/KS MUST include the following two payload extensions beyond those defined by the GSAKMP base protocol: . Identity to Transient Address Mapping (ITAM) GSAKMP payload - The ITAM payload describes the Group Member's Node Identity mapping to one or more transient locator IP addresses. Section 7.4 describes the ITAM payload. . Transport Endpoint Binding Attribute Certificate payload _ The TEBAC substantiates a Node Identity's assertion that it is the delegated GSAKMP message signer on behalf of the application endpoint identifier that issued the TEBAC. 4. The GC/KS checks for the following possible GSAKMP IPsec registration error conditions when processing the RTJ: Gross Expires January, 2004 page 24 GSAKMP Application to the IP Security Architecture July, 2004 . The TEBAC certificate's GSAKMP IP-v6 group identifier found in the Group attribute field MUST match the GSAKMP IP-v6 group identifier found in the RTJ message's GSAKMP header. . The TEBAC certificate's "Issuer" field MUST refer to the application endpoint's end-entity signature certificate. The certificate's Issuer signature MUST be valid, including a valid certificate path to one of the group's trusted anchor CA. . The TEBAC certificate's "Holder" field MUST refer to the Node Identity's end-entity signature certificate, and that certificate's identity MUST be the same signer identity as is found in the RTJ message's Signature payload. . The Signature payload's signature MUST be valid, it MUST be the Node Identity's signature, and it MUST have a valid certificate path to one of the group's trusted anchor CA. . The TEBAC validity period MUST NOT be expired. . The TEBAC declared Node Identity MUST match the Node Identity contained in the ITAM payload. . A proposed Group Speaker endpoint MUST be authorized as a Group Speaker: If the TEBAC transport endpoint identifier attribute field "S" flag is set, then the candidate Group Member requests the authority to become a Group Speaker. The GSAKMP IPsec policy token contains Group Speaker authorization pattern matching rules, analogous to those used for the group membership and GC/KS role authorizations. The GC/KS MUST apply those Group Speaker authorization rules as part of its request to join admittance decision. . One of the ITAM payload's interface IP addresses MUST contain the transient source IP address that had been verified by the cookies exchange. . The TEBAC attribute fields MUST conform to the group's policy token: the TEBAC attribute fields assert a valid destination port number and transport endpoint identifier. If the GC/KS discovers any one of the above error conditions while processing the RTJ then the GC/KS responds to the candidate group member with a RTJ-ERROR message. The RTJ-ERROR message contains a Gross Expires January, 2004 page 25 GSAKMP Application to the IP Security Architecture July, 2004 Notification payload having the error status "Not authorized to speak to the group" if the TEBAC "S" flag is set. 5. If the GC/KS admits the candidate Group Member into the group, then it prepares a Key-Download (KDL) message to send to the Group Member. The GC/KS signs the KDL with its Node Identity. The KDL message's Identification payload refers to the TEBAC Issuer application endpoint identity. The GC/KS keeps a local copy of the Group Member's TEBAC so that it can verify the Signature payload of the forthcoming KDL-ACK/NACK response. The GC/KS MUST include two or more SAC payloads in the KDL message sent to the new Group Member. See section 7.5. The new Group Member MUST be sent a SAC payload that describes its Re-key GSA SPD/SAD entry. For a new Group Speaker, a second SAC payload creates the SPD/SAD entry for the speaker's leading edge GSA. For a new Group Receiver, the KDL contains a separate SAC payload for each peer Group Speaker GSA that is speaking to the group. The new Group Receiver creates its SPD/SAD entries from these SAC payloads. 6. For a GC/KS straddling an IP-v4 public/private network boundary, the KDL message SHOULD include an ITAM payload containing a single interface IP address structure. The structure encodes the GC/KS public IP-v4 address as the high-order 32 bits of the Interface Identifier field. The Interface Identifier field's low-order 32 bits are the Group Member's private IP-v4 address that has been verified by the GC/KS using the cookies exchange. The IAT field is set to b'01'. Section 7.4 describes the ITAM payload. 7. If the Group Member accepts the KDL, then the Group Member responds to the GC/KS with a Key-Download-Acknowledgement (KDL- ACK) message signed by the Group Member's Node Identity. The Group Member MAY include the TEBAC in a Certificate payload. 8. If the Group Member does not accept the KDL, then the Group Member responds with a KDL-NACK message signed by the Group Member's Node Identity secret key. The Group Member MAY include the TEBAC in a Certificate payload. 9. If the Group Member fails to respond with KDL-ACK or KDL-NACK, within the allotted time, then the GC/KS sends a LOA signed by its Node Identity secret key. 10. If the new Group Member is a Group Speaker, then it multicasts a Security Association Management (SAM) message to the GSAKMP group. The SAM message revises the Group Receiver endpoint SPD/SAD Gross Expires January, 2004 page 26 GSAKMP Application to the IP Security Architecture July, 2004 entries, installing a new leading edge GSA that will decrypt the Group Speaker's future transmissions. The new SAM specified SPD/SAD policy displaces the group's default policy that would have discarded the multicast transmissions from an unknown source. 4.9 De-Registration Security Association Protocol Exchange GSAKMP IPsec implementations MUST support the de-registration protocol exchange, although a given group's policy MAY choose not to require the use of that protocol exchange. When a group is in autonomous distributed mode (section 4.10), the Group Member's de- registration protocol exchange MUST be with the same GC/KS as the group member had used for its registration protocol exchange. The Request-To-Depart message received at the GC/KS from a departing Group Member MUST have a valid TEBAC Certificate payload and an authorized Node Identity signature in its Signature payload. The TEBAC MAY be the same TEBAC as was used during registration. Its verification process is identical to that specified for the GSAKMP registration protocol exchange. The GC/KS signs its Departure- Response message with its Node Identity secret key. The Departure- Response message's Identification payload refers to the TEBAC "Issuer" application endpoint identity. The GSAKMP IPsec de-registration protocol exchange MUST use UDP as its transport layer protocol and it SHOULD NOT use the UDP checksum feature for the signed GSAKMP messages. The RECOMMENDED number of retransmission attempts is 3, with a timeout interval of 3 seconds between retries. The GSAKMP IPsec implementation SHOULD provide a local management interface that can tune each of the de-registration protocol exchange's recommended parameter values. A Group Speaker that wants to revise the group's view of its source transient IP address does not have to do a de-registration protocol exchange before it begins its re-registration protocol exchange. 4.10 GSAKMP Autonomous Distributed Mode The GSAKMP autonomous distributed mode enables large-scale groups, wherein the Primary-GC/KS delegates group membership management responsibilities to one or more Subordinate-GC/KS. Each S-GC/KS handles a sub-group within the overall group membership. Section 5.11.1 discusses the composite group facility, which can be applied to this scenario. Gross Expires January, 2004 page 27 GSAKMP Application to the IP Security Architecture July, 2004 GSAKMP IPsec IP-v6 endpoints SHOULD support GSAKMP autonomous distributed mode. GSAKMP IPsec IP-v4 endpoints that participate in a multi-realm GSAKMP group that spans multiple IP-v4 private networks (i.e. a GSAKMP group that has NAT gateways present) MUST support GSAKMP autonomous distributed mode. Refer to section 6.4 for details. The GSAKMP IPsec local management interface MUST provide the capability to configure a Node to operate in a S-GC/KS or GM role on a per GSAKMP group basis. If the Group Owner supports group in autonomous distributed mode, then the Group Owner management interface MUST provide the ability to configure autonomous distributed mode on a per group basis 4.11 Group Owner Management Interface This sub-section describes those GSAKMP Group Owner management interface requirements that are not specified elsewhere in the GSAKMP IPsec mapping specification: 1. Generate "public announcements" that discloses the subset of a GSAKMP group's security policies sufficient to allow interested candidate members to know which GC/KS to contact join the group and what protocol modes/options must be supported to participate as a group member. The public announcement mechanism is implementation specific and not subject of this standard. Other capabilities to be defined. 4.12 GSAKMP Node Local Management Interface This sub-section describes those GSAKMP Node local management interface requirements that are not specified elsewhere in the GSAKMP IPsec mapping specification: 1. Configure a multicast application's ability to bind to a given GSAKMP group. 2. Configure the Group Owner's public key certificate on a per GSAKMP group basis. 3. Generate the Node Identity asymmetric cipher key pair, and create the Node Identity public key certificate in cooperation with the Group Owner management interface. Gross Expires January, 2004 page 28 GSAKMP Application to the IP Security Architecture July, 2004 4. Provide the security policy controls for the subsystem that generates Transport Endpoint Binding Attribute Certificates. Other capabilities to be described. 4.13 Coordinating Security Policies Between Group Owners A GSAKMP Node may simultaneously belong to multiple GSAKMP IPsec groups that have independent Group Owner management systems. There is a risk that uncoordinated SPI allocations by these Group Owners could lead to two groups instructing a Node to use the same SPI. More importantly, the GSAKMP IPsec policy token directed SPD updates from two groups could conflict in their intent. Resolving such conflicts requires manual intervention by the respective security policy domains. However, the GSAKMP IPsec mapping does provide the following tools to diagnose or avoid such security policy conflicts: - A single GSAKMP Group Owner management system SHOULD be granted the exclusive administrative control of all GSAKMP groups that share a common multicast destination IP address (or SSM channel). - The GSAKMP IPsec policy token information model embodies the concept of security policy rule priorities. The GSAKMP IPsec Group Owner management interface SHOULD provide the ability to assign a GSAKMP group's SPD rule priorities from a re-locatable numeric range. When two group's policies conflict due to an overlap in their rule priorities, one of the groups can be adjusted to have the numeric range assigned to its security policies set to a lower or higher precedence than the other group. - The GSAKMP IPsec policy token advertises the SPI range for each multicast channel. The receiver Nodes can compare that range against the SPI ranges announced for all other GSAKMP groups that it is a participant for that same multicast channel. If the Node detects an overlap to a SPI range, it MUST log a local error, and it MAY notify its GSAKMP Group Owners of the fault. The notification mechanism is outside the scope of this standard. 5 GSAKMP IP Security Subsystem Profile This section prescribes mandatory requirements on both the GSAKMP IPsec implementation and its companion IP security subsystem. Wherever feasible, these requirements align with the existing Gross Expires January, 2004 page 29 GSAKMP Application to the IP Security Architecture July, 2004 requirements imposed by RFC2401-bis and IKE-v2. No attempt is made by the GSAKMP IPsec application to achieve backward compatibility with legacy RFC2401 IPsec subsystems. The GSAKMP IPsec application generally avoids sub-setting RFC2401-bis, and it is an explicit goal that the GSAKMP IPsec application does not preclude its implementation in any of the major IP security architectures: native host-based system, Bump-In-The-Stack (BITS), Bump-In-The-Wire (BITW), or as a security gateway. 5.1 GSAKMP Requirements on the IP Security Subsystem The primary GSAKMP IPsec requirement is a RFC2401-bis compliant IP security system that supports the secure multicast option as defined in section 4.1 [RFC2401-bis] and also section 2.1 of [RFC2406-bis]. A GSAKMP IPsec mapping implementation MUST support Encapsulating Security Payload (ESP) [RFC2406-bis] and it MAY support Authentication Header (AH) [RFC2402-bis]. RFC2401-bis permits an IP security subsystem to have only one SPD per Node rather than one SPD per network interface (this is an architectural revision from RFC2401). The GSAKMP IPsec policy token requires that the IPsec subsystem MUST have only one SPD, as the GSAKMP IPsec policy token multicast sets the SPD configuration identically at all of the group's endpoints. Practical limits on the policy token's message length prohibits encoding the configuration for all of a group's individual network interfaces and their respective SPD configurations. The single SPD per GSAKMP Node encompasses the SPD-I, SPD-S, and the SPD-O. All of those components, and also the Node's SAD, MUST be accessible for configuration updates by the GSAKMP IPsec implementation interpreting the GSAKMP IPsec policy token. Figure 1 shows the control interface (C0) between GSAKMP and the IP security subsystem. The mechanism that provides that SPD/SAD access is a local implementation matter outside the scope of this standard. Both the GSAKMP IPsec implementation and its underlying IPsec subsystem MUST support logical expressions that combine the following types of SPD traffic selectors as defined by RFC2401-bis section 4.4 and the ASN.1 syntax declared in its Appendix A: - Destination IP-v4 address range, both unicast and multicast - Source IP-v4 address range Gross Expires January, 2004 page 30 GSAKMP Application to the IP Security Architecture July, 2004 - Destination and source IP-v6 address range traffic selectors - This requirement includes the GSAKMP Group Owner management interface capability to configure skipping IP-v6 extension headers for the Next Layer Protocol selector, as per RFC2401-bis section 4.4.2. - Next Layer Protocol range, - Transport protocol-dependent source port range and destination port range selectors for UDP, TCP, SCTP, ICMP, and NORM. - The "opaque" and "any" attributes for each of the above five selectors. - The SPD-outbound traffic selectors, using a symbolic "Name" selector, can trigger a candidate group member's GSAKMP registration with a GC/KS. See section 5.9 for additional details. - The GSAKMP IPsec implementation and the SPD-outbound MUST support the Populate From Packet (PFP) feature as required by RFC2401-bis section 4.4.1. This version of the GSAKMP IPsec mapping does not support compression, although a future version may introduce support for that feature. The GSAKMP IPsec implementation MAY support quality of service using parallel group security associations, each group security association having a separate datagram flow marked with a DSCP. The algorithm that selects the GSA for a given DSCP marked datagram is outside the scope of this specification. Subsequent sections provide additional requirements and clarifications with respect to GSAKMP interactions with the IP security subsystem. 5.2 Authentication Header Group Security Associations If the GSAKMP IPsec implementation does support AH, then the Group Owner MUST assign AH group security association SPI that are unique from those SPI that its assigns to its ESP group security associations (i.e. ESP and AH share the same SPI pool). In addition, a GSAKMP IPsec subsystem that supports AH MUST also support SA bundles (i.e. the combination of AH and ESP in one datagram). Gross Expires January, 2004 page 31 GSAKMP Application to the IP Security Architecture July, 2004 5.3 Secure Multicast Application Service Models The vast majority of secure multicast applications can be catalogued by their service model and accompanying intra-group communication patterns. Both the GSAKMP IPsec implementation and the IPsec subsystem MUST be able to configure the SPD/SAD security policies to match these dominant usage scenarios. The SPD/SAD policies MUST include the ability to configure both Any-Source-Multicast groups and Source-Specific-Multicast groups for each of these service models. The GSAKMP management interface MAY include mechanisms to configure the security policies for service models not identified by this standard 5.3.1 Unidirectional Multicast Applications Multi-media content delivery multicast applications without congestion notification or retransmission error recovery are inherently unidirectional. RFC2401-bis only defines bi-directional unicast security associations (as per sections 4.4.1 and 5.1 with respect to SA directionality). The GSAKMP IPsec mapping requires that the IPsec subsystem MUST support unidirectional group security associations. Applications that have only one group member authorized to transmit can use this type of group security association to enforce that group policy. In the inverse direction, the GSA does not have a SAD entry, and the SPD configuration is setup to discard unauthorized attempts to transmit to the group. Although supported as a GSAKMP IPsec configuration, this multicast application service model is NOT RECOMMENDED because it does not have congestion control feedback capabilities. The GSAKMP Group Owner management interface MUST have the ability to setup a GSAKMP group having a unidirectional GSA security policy. 5.3.2 Bi-directional Reliable Multicast Applications Some secure multicast applications are characterized as one speaker to many listeners, but with inverse data flows required by a reliable multicast transport protocol (e.g. NORM). In such applications, the data flow from the speaker is multicast, and the inverse flow from the group's listeners is unicast to the speaker. Typically, the inverse data flows carry error repair requests and congestion control status. Gross Expires January, 2004 page 32 GSAKMP Application to the IP Security Architecture July, 2004 For such applications, the GSA SHOULD use IPsec anti-replay protection service for the speaker's multicast data flow to the group's listeners. In the inverse direction, the GSA anti-replay protection MUST be disabled. The group listener's SPD entry for this GSA MAY be configured to only allow a unicast transmission to the speaker Node rather than a multicast transmission to the whole group. If available, a source authentication mechanism (e.g. ESP digital signature) SHOULD be used to authenticate the listener Node's transmission to the speaker. The GSAKMP Group Owner management interface MUST have the ability to setup a GSAKMP group having a bi-directional GSA security policy. 5.3.3 Any-To-Any Multicast Applications Another family of secure multicast applications exhibit a "many to many" communications pattern. A representative example of such an application is a videoconference combined with an electronic whiteboard. For such applications, all (or a subset) of the group's endpoints are authorized multicast speakers. The group SHOULD share one GSA for all of its speakers. The GSA SHOULD NOT use IPsec anti-replay protection service for the speaker's multicast data flow to the group's listeners. The GSAKMP Group Owner management interface MUST have the ability to setup a GSAKMP group having an Any-To-Any Multicast GSA security policy. 5.4 Co-Existence of Multiple Key Management Protocols Often, GSAKMP will be introduced to an existent IPsec subsystem as a companion key management protocol to IKE-v2 [IKE-v2]. A fundamental GSAKMP IP Security subsystem requirement is that both GSAKMP and IKE-v2 can simultaneously share access to a common Security Policy Database and Security Association Database. The mechanisms that provide mutually exclusive access to the common SPD/SAD data structures are a local matter. This includes the SPD-outbound cache and the SPD-inbound cache. However, implementers should note that IKE-v2 SPI allocation is entirely independent from GSAKMP SPI allocation because group security associations are qualified by a destination multicast IP address and may optionally have a source IP address qualifier. See [RFC2406-bis] section 2.1 for further explanation. Gross Expires January, 2004 page 33 GSAKMP Application to the IP Security Architecture July, 2004 The Peer Authorization Database does require explicit coordination between GSAKMP and IKE-v2. Section 5.8 describes these interactions. This document discusses the coordination of multiple GSAKMP group owner and endpoint local management systems in section 4.11. 5.5 ESP GSA Properties At the time of this writing, IPsec RFCs specify the support of the following transforms and algorithms for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation Requirements For ESP And AH" [CRYPTREQ] contains the current set of mandatory to implement algorithms for ESP and AH. It also specifies algorithms that should be implemented because they are likely to be promoted to mandatory at some future time. GSAKMP IPsec Nodes SHOULD conform to the requirements in [CRYPTREQ]. All GSAKMP IPsec subsystem implementations MUST support both sending and receiving for the following ESP GSA properties: - Triple-DES encryption in CBC mode with an 168-bit key length [RFC2451] [RFC2406-bis]. The 3DES-CBC encryption algorithm does not suffer from the same security issues as DES-CBC, and the 3DES- CBC algorithm within ESP MUST be supported to ensure interoperability. - The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published soon. DES provides 56 bits of protection, which is no longer considered sufficient. - Group source authentication is mandatory, wherein the ESP authenticator uses HMAC-SHA1-MAC96 [RFC2404]. An implementation MAY also support the use of the HMAC-MD5-96 algorithm [RFC-2403] within AH and ESP. - Both transport and tunnel mode, as required by RFC2401-bis section 4.4.3. See section 5.10 for additional GSA tunnel mode specifications. - Anti-replay protection, configurable to use either sixty-four bit or thirty two bit ESP sequence numbers Gross Expires January, 2004 page 34 GSAKMP Application to the IP Security Architecture July, 2004 - Security association lifetime hard limits for both kilo-bytes processed by the cryptographic transform and its lifetime duration measured in units of seconds. - Security association lifetime soft limits of both kilo-bytes processed by the cryptographic transform and its lifetime duration measured in units of seconds. The interpretation of SA soft lifetime expiration is implementation dependent. However, it is usually used to signal the GSAKMP subsystem that it should proactively initiate re-registration with the group because one or more Re-Key Event message(s) have failed to arrive in time. - Sequence counter overflow - A configurable flag indicating whether to log an audit message if the SA sequence number overflows (as per [RFC2401-bis] section 4.4.3). - Path MTU - The associated IPsec SA fragmentation policy MUST be compliant to RFC2401-bis. The GSAKMP IPsec management interface MUST provide a configuration capability to set the path MTU on a per GSAKMP multicast speaker basis. - UDP encapsulation of ESP [UDPESP]. In addition, GSAKMP IP Security implementations SHOULD support the following additional ESP algorithms and modes: - AES encryption in CBC mode with a 128-bit key length [RFC3602]. - AES combined encryption and authentication using Counter with CBC- MAC96 (CCM) mode [AESCCM] with a 128-bit key length. The GSAKMP Group Owner management interface MUST have the ability to set a group's GSA policy to use null ESP encryption or null authentication. All GSAKMP IPsec endpoints MUST support the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-2406]. However, while authentication and encryption can each be NULL, they MUST NOT both be NULL. The NULL encryption algorithm is also useful for debugging. 5.6 Concurrent GSA Life Spans and Rollover During a GSAKMP group's lifetime, multiple group security associations can exist concurrently. This occurs principally due to two reasons: Gross Expires January, 2004 page 35 GSAKMP Application to the IP Security Architecture July, 2004 - There are multiple Group Speakers authorized in the group, each with its own GSA that maintains anti-replay state. A group that does not rely on IP Security anti-replay services can share one GSA for all of its Group Speakers. - The life span of a Group Speaker's two (or more) GSA are allowed to overlap in time, so that there is continuity in the multicast data stream across group re-key events. This capability is referred to as "re-key rollover continuity". This specification requires that a GSAKMP IPsec implementation MUST support at least two concurrent GSA per Group Speaker to facilitate multicast data stream re-key rollover continuity. Each SAM multicast sent by a Group Speaker signals the start of a new Group Speaker time epoch, with each such epoch having an associated GSA. The group membership interacts with these GSA as follows: - As a precursor to the Group Speaker beginning its re-key rollover continuity processing, the GC/KS periodically multicasts a Re-Key Event (RKE) message to the group. The RKE multicast contains a revised GSAKMP IPsec policy token, group membership management directives (e.g. LKH), and a new Group Traffic Protection Key (GTEK). - After successfully processing the RKE multicast, the Group Speaker creates its new "leading edge" Group Security Association by multicasting a SAM message to the group. The SAM multicast configures the group's SPD/SAD with the leading edge GSA state information. The leading edge GSA allocates a new Security Parameter Index and it is keyed by the GTEK distributed by the most recent RKE multicast. For a short period after multicasting the SAM, a Group Speaker does not transmit data using the leading edge GSA. However, all of the Group Receiver endpoints prepare to use this GSA by installing the SAM directed changes to their respective SPD/SAD. - After waiting a sufficiently long enough period such that all of the Group Receiver endpoints have processed the SAM multicast, the Group Speaker begins to transmit using the leading edge GSA with its data encrypted by the new GTEK. Only authorized Group Members can decrypt these GSA multicast transmissions. The time delay that a Group Speaker waits before starting its first leading edge GSA transmission is a GSAKMP IPsec policy token parameter. This value SHOULD be configurable at the Group Owner management interface on a per GSAKMP group basis. Gross Expires January, 2004 page 36 GSAKMP Application to the IP Security Architecture July, 2004 - The Group Speaker's "trailing edge" GSA is the oldest group security association in use by the group for that speaker. All authorized Group Receiver endpoints can receive and decrypt data for this GSA, but the Group Speaker does not transmit new data using the "trailing edge" GSA after it has transitioned to the "leading edge GSA". This rollover strategy allows the group to drain its in transit datagrams from the network while transitioning to the leading edge GSA. Staggering the roles of each respective GSA as described above improves the group's synchronization even when there are high network propagation delays. Note that due to group membership joins and leaves, each Group Speaker time epoch may have a different group membership set. It is a group policy decision whether the re-key events provide forward and backward secrecy at these re-key event transitions between epochs. This group policy is declared in the policy token, and that policy is enforced by its re-key protocol's keying material and algorithm (e.g. Logical Key Hierarchy). Implementations MAY offer a Group Owner management interface option to enable/disable re-key rollover continuity for a particular group, but by default it MUST be enabled. 5.7 Multiple Group Speakers and Source Authentication A GSAKMP IPsec implementation MUST support at least one Group Speaker per GSAKMP group and it MAY support more than one Group Speaker per group. This requirement is in addition to the requirement to support a GC/KS as a Group Speaker along with its attendant Re-Key GSA. The GSAKMP IPsec policy token specifies the Group Speaker authorization pattern matching rules, authorizing one or more group endpoints to become Group Speakers. In the Any-Source Multicast (ASM) usage model, all of the group members are authorized to speak to the group. When the group's GSAKMP IPsec policy token requires IP Security anti-replay protection service, then there MUST be only one Group Speaker authorized per GSA per time epoch. In other words, when anti-replay service is enabled for a group, then there MUST be as many GSA allocated and operating per group time epoch as there are Group Speakers. Each such GSA will have its own set of SPD policies, anti-replay state, and MAY have its own multicast destination IP address. All of these GSA share a common group membership set. GSAKMP IPsec implementations MUST support IPsec anti-replay services Gross Expires January, 2004 page 37 GSAKMP Application to the IP Security Architecture July, 2004 for at least one Group Speaker. Although this requirement may not scale to larger groups, the GSAKMP IPsec management interface SHOULD support a configurable number of Group Speakers per group using the anti-replay service. The RECOMMENDED minimum number of such Group Speakers is 8. By default, both the SPD-inbound and SPD-outbound traffic selectors MUST be configured with security policy actions that discard unauthorized multicast transmission attempts. This inhibits the spoofing of a peer group member's transmissions by a rogue group member. However, group transmissions that have stronger source authentication policy requirements (e.g. messages having group control, economic, or legal implications) SHOULD use per packet multicast source authentication techniques. 5.8 GSAKMP IPsec Interactions with the PAD The Peer Authorization Database (PAD) MUST provide a management interface capability that allows an administrator to enforce that the scope of a GSAKMP group's policy token specified SPD/SAD modifications are restricted to only those traffic data flows that belong to that group. This authorization MUST be configurable at GSAKMP group granularity. In the inverse direction, the PAD management interface MUST provide a mechanism(s) to enforce that IKE-v2 security associations do not negotiate traffic selectors that conflict or override GSAKMP group policies. An implementation SHOULD offer PAD configuration capabilities that authorize GSAKMP policy token to set security policy for all aspects of an endpoint's SPD/SAD configuration, not just its GSAKMP group security associations. This capability allows the group's policy to inhibit the creation of back channels that might otherwise leak confidential group application data. The PAD also defines the trust anchor public key certificates for each GSAKMP group. See section 9.5. 5.9 Security Policy Database Symbolic Name Selectors The RFC2401-bis section 4.4.2 describes SPD symbolic name selectors and several examples of their usage. GSAKMP IPsec implementations MUST support SPD symbolic name selectors for the two cases that depend on this feature: the GC/KS response to a Request-To-Join (RTJ), and triggering a GSAKMP registration attempt in response to starting a multicast application (e.g. a socket bind() system call). Gross Expires January, 2004 page 38 GSAKMP Application to the IP Security Architecture July, 2004 When a GC/KS receives a GSAKMP RTJ message from a candidate group member, the GC/KS looks up the TEBAC Certificate payload's Issuer identification field's value in the SPD. If one of the SPD symbolic name selector entries matches that value, then the system is locally authorized to act as a GC/KS for that candidate group member. However, the GSAKMP IPsec policy token currently in the possession of the GC/KS ultimately decides whether the GC/KS allows that candidate group member to join the group, or denies the join request. The GSAKMP IPsec local management interface MUST provide the GC/KS configuration tools that create each GSAKMP group's SPD symbolic name selector(s). All GSAKMP IPsec implementations MUST have the latent capability to be configured as a S-GC/KS, although local policy may not enable it. In a multi-user native host-based GSAKMP IPsec system, a SPD symbolic name selector matching an application endpoint's authenticated identity, (optionally in combination with other traffic selectors), MUST initiate a request to join a GSAKMP group. In this context, the operating system is trusted to have previously authenticated the user's identity and created his/her TEBAC credentials in compliance with the group's application endpoint authentication policy. For example, the matching SPD name selector may trigger an AAA application that generates the TEBAC credentials. The GSAKMP IPsec subsystem transparently proxies that candidate Group Member's signature for the GSAKMP messages that it sends in the registration SA exchange. Alternatively, a GSAKMP IPsec native host-based implementation MAY define a mechanism, such as an application program interface, that facilitates the application endpoint's direct signature of its GSAKMP messages without TEBAC signature delegation. This specification does not standardize this mechanism. For those GSAKMP IPsec implementations within a BITS, BITW, or security gateway, there MUST be a mechanism to trigger the GSAKMP registration protocol exchange. For example, the GSAKMP IPsec subsystem may interact with an application layer protocol gateway service that initiates the group membership registrations. This includes the GSAKMP IPsec subsystem acquiring the appropriate TEBAC. However, that mechanism is a local implementation issue. The mechanism may not necessarily use a SPD symbolic name selector, and the mechanism is not standardized by this specification. Gross Expires January, 2004 page 39 GSAKMP Application to the IP Security Architecture July, 2004 5.10 Tunnel Mode Group Security Associations GSAKMP IPsec implementations MUST support IPsec tunnel mode group security associations as prescribed by [RFC2401-bis] section 5.1.2. One anticipated application for this capability is a set of multicast-capable IPsec gateways at the border between an untrustworthy public Internet and a group of one or more trusted private networks. The IPsec GSA tunnel's outer IP header delivers the encrypted multicast datagram across the public Internet to each of the group's IPsec gateways. Once that payload is de-capsulated at the GSA destination tunnel endpoint and it is decrypted, then the multicast IPsec gateway multicasts the inner IP header and its plain-text payload to the group's endpoints within the gateway's respective private network. This specification requires that a GSAKMP IPsec implementation also MUST support a Group Owner management interface that facilitates the configuration of all of a RFC2401-bis tunnel mode SA attributes: - All of the relevant tunnel source endpoint's outer IP header attributes. - For IP-v4 tunnels, the Do Not Fragment flag copy policy - DSCP _ copy from inner IP header to outer IP header or else GSAKMP IPsec assigns the outer IP header's DSCP to a value fixed by the group's policy. - For IP-v6 tunnels, the flow label copy or set policy 5.11 Multicast Packet Distributor Policy Action This section introduces the "Multicast Packet Distributor", a security policy building block that takes a packet as its input, replicates the packet, and distributes the copies to two or more downstream policy action components. The formal definition is deferred to [IPSECPT]. The Group Owner management interface MAY provide the configuration tools needed to encode policy tokens containing Multicast Packet Distributor policy actions. All GSAKMP IPsec implementations MUST be able to interpret any correctly encoded policy token containing a Multicast Packet Distributor, and correctly enforce its policies. Gross Expires January, 2004 page 40 GSAKMP Application to the IP Security Architecture July, 2004 5.11.1 Basic and Composite GSAKMP Groups In the trivial case, there is a 1:1 relationship between a GSAKMP group identifier, a multicast application, and a multicast IP address. In other words, a basic GSAKMP group has only one multicast application destination port number, and it has only one multicast IP address. A GSAKMP Group Owner management system MUST be able to set up a GSAKMP group having this basic configuration. However, the GSAKMP IPsec architectural model does not preclude the creation of a GSAKMP "composite group" and SPD policy that aggregates multiple basic GSAKMP sub-groups. In this service model, the multicast application multicasts one message payload to all of the group's endpoints, and the GSAKMP IPsec subsystem transparently replicates that message and distributes a copy to each of the sub- groups. The goal is to accommodate GSAKMP group endpoint populations that have heterogeneous capabilities or attributes. Some examples where a composite group could be applied include: - A GSAKMP group straddling both IP-v4 and IP-v6 endpoints. For a group spanning IP-v4 and IP-v6, the Group Speaker endpoint's Node must be dual stack capable. - A single GSAKMP group using a Reliable Multicast Transport protocol (RTMP) that has a heterogeneous deployment of error recovery algorithms (e.g. Forward Error Correction codes) at its endpoint population. Each RMTP version is configured as a sub- group at a distinct multicast destination IP address. In this case, the application's payload is replicated within the speaker Node before being distributed to each RMTP version-specific subsystem. The Group Speaker endpoint's Node must implement all of the RMTP sub-group versions. - There are multiple multicast routing domains supporting the GSAKMP group, each routing domain imposing its own policy defined multicast IP address. The GSAKMP IPsec must alter the multicast destination IP address for each copy of the multicast packet before it is sent to its respective routing domain. - A multicast application wherein the GSAKMP group is the union of multiple source-specific IP multicast groups. For example, a multi-homed Group Speaker might require this configuration. In principal, each of the above examples could be decomposed into multiple independent basic GSAKMP groups. However, that incurs a Gross Expires January, 2004 page 41 GSAKMP Application to the IP Security Architecture July, 2004 commensurate increase in the multicast application's overhead to discover, join, and manage each of those groups. A preferable solution is for the multicast application to join one GSAKMP group, and have the GC/KS bundle the multiple basic group SPD traffic selector rules into a single policy token configuration operation. This type of SPD configuration encodes the GSAKMP "composite group" security policy. A composite group has the following properties: - The composite group membership is the union of two or more non- overlapping basic sub-group memberships formed by the sub-group's Group Receiver endpoints. All of the sub-groups share the composite group's GTEK and algorithm. - When a Group Receiver endpoint joins a composite group, it also selects its membership in one of the basic sub-groups. The sub- group selection can be implicit (i.e. pre-configured at the GC/KS) or explicitly signaled in the group member's RTJ sent to the GC/KS. The signaling mechanism MAY be the TEBAC payload, or it MAY be an implementation defined mechanism not standardized by this version of the GSAKMP IPsec mapping. - The multicast application Group Speaker endpoint sends a single message to the composite group and it is received once at each endpoint within a sub-group. The Group Speaker's Node is responsible for transparently replicating that message and sending a copy to each sub-group within the composite group. When the Group Speaker endpoint joins a composite group, it implicitly joins all of the basic sub-groups as a speaker. - If the Multicast Packet Distributor policy action occurs before encryption, then there is a GSA per sub-group (assuming anti- replay service is enabled). - If the Multicast Packet Distributor policy action occurs after encryption, then there is one GSA for the composite group. - There SHOULD be a Subordinate-GC/KS per GSAKMP sub-group. 5.11.2 Transmitter Multicast Packet Distributor The GSAKMP IPsec policy token grammar (see [IPSECPT]) has the expressive power to describe and manage composite group security policies. The GSAKMP IPsec policy action Multicast Packet Distributor can be inserted as one action in the sequenced list that constitutes a compound policy action. The Multicast Packet Gross Expires January, 2004 page 42 GSAKMP Application to the IP Security Architecture July, 2004 Distributor building block distributes each application message transmission to the composite group's sub-groups. The group's policy decides whether the distribution occurs before or after the message's GSA encryption policy action. 5.11.3 Receiver Multicast Packet Distributor At a receiving Node, the Receiver Multicast Packet Distributor is the decryption and distribution control point for the one or more authorized Group Receiver endpoints co-residing on that Node. This has the benefit that the Node receives one encrypted multicast datagram regardless of the number of such endpoints, decrypts its ESP payload once, and securely distributes that plain-text payload to each of the authorized application endpoints within that Node. The mechanism through which the Node achieves that secure distribution is a local implementation matter. Note that after the decryption step but before the plain-text distribution, the IP security subsystem compares the datagram's attributes against the SPD-inbound traffic selectors, and verifies that the datagram conforms to the GSA's security policy. If the verification succeeds, then the GSA forwards the datagram to the Receiver Multicast Packet Distributor. If a multicast application destination port has multiple Group Speaker GSA in a given time epoch, all of those GSA forward their datagrams to the same Receiver Multicast Packet Distributor. Internal to the Node, the Receiver Multicast Packet Distributor is the single control state shared between one or more authorized Group Receiver endpoints for a group time epoch. There is a Receiver Multicast Packet Distributor instance per GSAKMP group per time epoch that has authorized Group Receiver endpoints as members within a Node. 5.12 UDP Encapsulated ESP GSA To be defined. 6 GSAKMP Interactions with NAT and Mobility With the advent of NAT and mobile Nodes, GSAKMP IPsec multicast applications must overcome several architectural barriers to their successful deployment. This section surveys those problems, and section 7 specifies a GSAKMP protocol extension as their solution. Gross Expires January, 2004 page 43 GSAKMP Application to the IP Security Architecture July, 2004 6.1 SPD Losses Synchronization with Internet Layer's State The most prominent problem facing GSAKMP IPsec is that the GSAKMP IPsec policy token can inadvertently configure the group's SPD traffic selectors with unreliable transient IP addresses. The IP addresses are transient because of either Node mobility or Network Address Translation (NAT), both of which can unilaterally change a multicast speaker's source IP address without signaling GSAKMP. The absence of a SPD synchronization mechanism can cause the group's data traffic to be discarded rather than processed correctly. 6.1.1 Mobile Multicast Care-Of Address Route Optimization Both Mobile IP-v4 [RFC3344] and Mobile IP-v6 [MIPV6] provide transparent unicast communications to a mobile Node. However, comparable support for secure multicast mobility management is not specified by these standards. The goal is the ability to maintain an end-to-end transport mode group SA between a Group Speaker mobile node that has a volatile care-of-address and a Group Receiver membership that also may have mobile endpoints. In particular, there is no secure mechanism for route optimization of the triangular multicast path between the correspondent Group Receiver Nodes, the home agent, and the mobile Node. Any proposed solution must be secure against hostile re-direct and flooding attacks. 6.1.2 NAT Translation Mappings Are Not Predictable The following spontaneous NAT behaviors adversely impact source- specific secure multicast groups. When a NAT gateway is on the path between a Group Speaker endpoint residing behind a NAT and a public IP-v4 multicast Group Receiver, the NAT gateway alters the private source address to a public IP-v4 address. This translation must be coordinated with every Group Receiver's inbound Security Policy Database (SPD) multicast entries that uses that source address as a traffic selector. One might mistakenly assume that the GC/KS can set up the GSAKMP endpoints with a SPD entry that anticipates the value(s) that the NAT translates the packet's source address. However, there are known cases where this address translation can spontaneously change without warning: - NAT gateways may re-boot and lose their address translation state information. Gross Expires January, 2004 page 44 GSAKMP Application to the IP Security Architecture July, 2004 - The NAT gateway may de-allocate its address translation state after an inactivity timer expires. The address translation used by the NAT gateway after the resumption of data flow may differ than that known to the SPD selectors at the GSAKMP endpoints. - The GC/KS may not have global consistent knowledge of a GSAKMP endpoint's current public and private address mappings due to network errors or race conditions. For example, an endpoint's address may change due to a DHCP assigned address lease expiration. - Alternate paths may exist between a given pair of GSAKMP endpoints. If there are parallel NAT gateways along those paths, then the address translation state information at each NAT gateway may produce different translations on a per packet basis. The consequence of this problem is that the GC/KS can not be pre- configured with NAT mappings, as the SPD at the group's endpoints will lose synchronization as soon as a NAT mapping changes due to any of the above events. In the worst case, group endpoints in different sections of the Internet will see different NAT mappings, because the multicast packet traversed multiple NAT gateways. 6.2 Secondary Problems Created by NAT Traversal 6.2.1 SSM Routing Dependency on Source IP Address Source-Specific Multicast (SSM) routing depends on a multicast packet's source IP address and multicast destination IP address to make a correct forwarding decision. However, a NAT gateway alters that packet's source IP address as its passes from a private network into the public Internet. Mobility changes a Node's point of attachment to the Internet, and this also will change the packet's source IP address. Regardless of why it happened, this alteration in the source IP address makes it infeasible for transit multicast routers in the public Internet to know which SSM speaker originated the multicast packet, which in turn selects the correct multicast forwarding policy. 6.2.2 ESP Cloaks Its Payloads from NAT Gateway When traversing NAT, application layer protocols that contain IP-v4 addresses in their payload need the intervention of an Application Layer Gateway (ALG) that understands that application layer protocol [RFC3027] [RFC3235]. The ALG massages the payload's private IP-v4 Gross Expires January, 2004 page 45 GSAKMP Application to the IP Security Architecture July, 2004 addresses into equivalent public IP-v4 addresses. However, when encrypted by end-to-end ESP, such payloads are opaque to application layer gateways. When multiple Group Speaker endpoints reside behind a NAT with a single public IP-v4 address, the NAT gateway can not do UDP or TCP protocol translation (i.e. NAPT) because the ESP encryption conceals the transport layer protocol headers. The use of UDP encapsulated ESP [UDPESP] avoids this problem. However, this capability must be configured at the GC/KS as a group policy, and it must be supported in unison by all of the GSAKMP endpoints within the group, even those that reside in the public Internet. 6.2.3 UDP Checksum Dependency on Source IP Address A GSAKMP IPsec multicast application that uses UDP within an ESP payload will encounter NAT induced problems. The original IP-v4 source address is an input parameter into a receiver's UDP pseudo- header checksum verification, yet that value is lost after the IP header's address translation by a transit NAT gateway. The UDP header checksum is opaque within the encrypted ESP payload. Consequently, the checksum can not be manipulated by the transit NAT gateways. UDP checksum verification needs a mechanism that recovers the original source IP-4 address at the Group Receiver endpoints. In a transport mode multicast application GSA, the UDP checksum operation requires the origin endpoint's IP address to complete successfully. In IKE-v2 [IKE-v2], this information is exchanged between the endpoints by a NAT-OA payload (NAT original address). See also reference [IPSECNAT]. A comparable facility must be exist in a GSAKMP payload that defines the multicast application GSA attributes for each Group Speaker endpoint. 6.2.4 Can Not Use AH with NAT Gateway The presence of a NAT gateway makes it impossible to use an Authentication Header, keyed by a group-wide key, to protect the integrity of the IP header for transmissions between members of the cryptographic group. 6.3 Avoidance of NAT Using an IP-v6 Over IP-v4 Network A straight forward and standards-based architecture that effectively avoids the GSAKMP interaction with NAT gateways is the IP-v6 over IP-v4 transition mechanism [RFC2529]. In IP-v6 over IP-v4 (a.k.a. Gross Expires January, 2004 page 46 GSAKMP Application to the IP Security Architecture July, 2004 "6over4"), the underlying IP-v4 network is treated as a virtual multicast-capable Local Area Network. The IP-v6 traffic tunnels over that IP-v4 virtual link layer. Applying GSAKMP in a 6over4 architecture leverages the fact that an administrative domain deploying GSAKMP would already be planning to deploy IP-v4 multicast router(s). The GSAKMP group's IP-v6 multicast routing can execute in parallel to IP-v4 multicast routing on that same physical router infrastructure. In particular, the NAT gateways at administrative domain public/private boundaries are replaced by IP-v6 multicast routers operating with 6over4 mode enabled on their network interfaces. Within the GSAKMP protocol, all references to IP addresses are IP-v6 addresses for all security association endpoints and these addresses do not change over the group's lifetime. This yields a substantial reduction in complexity and error cases over the NAT-based approaches. This reduction in complexity can translate into better security. Reliable scalable GSAKMP 6over4 deployment is far more practical than GSAKMP/NAT with IP-v4. In particular, new GSAKMP multicast applications SHOULD prefer GSAKMP IP-v6 native mode. However, GSAKMP supports either choice. The following factors may weigh against the decision to deploy GSAKMP 6over4: - A drawback of the GSAKMP 6over4 approach is that the secure multicast application must be (re-)written to an IP-v6 multicast socket API or equivalent, and it must interact with the Multicast Listener Discovery (MLD) API [RFC3590] [RFC3678] rather than IGMP. In addition, the application layer protocol itself must embed references to IP-v6 addresses rather than IP-v4 addresses within its payloads. For new applications, this may not be of consequence; it usually only becomes an issue if the application and its protocol has an embedded base. - An embedded base of GSAKMP IP-v4 multicast applications that are only available in binary form will not be able to migrate to these transitional IP-v6 mechanisms. - The secondary drawbacks of GSAKMP 6over4 are that the IP hosts must be upgraded to dual-stack, the attendant overlay IP-v6 multicast network operational costs, and the difficulty of deploying commercial wide-area IP-v6 multicast services. Gross Expires January, 2004 page 47 GSAKMP Application to the IP Security Architecture July, 2004 6.4 GSAKMP Multi-Realm IP-v4 NAT Architecture In a multi-realm group, GSAKMP security association endpoints may straddle any combination of IP-v4 public addresses and private addresses [RFC1918]. In such cases, transport layer endpoint identifiers when resolved to their underlying private or public IP- v4 addresses entangle the GSAKMP protocol with NAT gateway behaviors. The NAT translation of IP-v4 header addresses impacts the GSAKMP registration SA, the GSAKMP re-key GSA, and the multicast application GSA. This section overviews the GSAKMP mechanisms that partially mitigate the inherent complexity spawned by IP-v4 NAT and Network Address Protocol Translation (NAPT) traversal. However, the attendant Group Owner configuration procedures are labor-intensive, prone to configuration mismatch errors between the GC/KS and NAT gateways, and they do not scale well to large groups. Given the large number of documented NAT problems and its erosion of end-to-end security, new GSAKMP applications and deployments SHOULD strongly prefer the use of IP-v6. Section 6.3 offers IP-v4 to IP-v6 transitional guidance in support of that objective. 6.4.1 GSAKMP IP-v4 NAT Architectural Assumptions To make the multi-realm GSAKMP IP-v4 NAT interaction problem tractable to a solution, this specification makes the following simplifying assumptions: - The secure multicast group destination address is a statically allocated public IP-v4 multicast address known to all GSAKMP endpoints. - Wherever they are present in the GSAKMP protocol, GSAKMP endpoint addresses are expressed as permanent IP-v6 "6to4" addresses [RFC3056] to assure that the GSAKMP endpoints that refer to hosts assigned private IP-v4 addresses are globally unique. In this context, a "permanent" 6to4 address means that the address is constant for the group's lifetime. - Each private IP-v4 address space has one or more NAT gateways directly connected to the IP-v4 public Internet, and a packet does not have to traverse multiple private networks to reach the public Internet. This can be thought of as a "spoke and hub" configuration wherein the public Internet is the hub. Gross Expires January, 2004 page 48 GSAKMP Application to the IP Security Architecture July, 2004 - A GC/KS may reside within one of the private networks, but it also MUST have a permanent public IP-v4 address on at least one of its network interfaces. This requirement applies to both the Primary-GC/KS and all of the group's Subordinate-GC/KS. - GSAKMP group security associations are end-to-end transport mode. However, since the S-GC/KS are constrained to straddle a public/private network boundary, they effectively terminate the GSA at a combined NAT/security gateway [RFC2709]. - The GC/KS domain name RR record should point to that public IP-v4 address, and it should be protected by DNS-SEC. - Each of an administrative domain's NAT gateways are explicitly configured with static private/public address translation mappings for the GC/KS's GSAKMP re-key multicast ESP protected UDP packets inbound from the public Internet [RFC2588]. - The NAT gateways/firewalls are explicitly configured with stateless filter rules that simply pass through without any address translation the group's inbound multicast application packets arriving from the public Internet. The NAT gateway does not translate the multicast application packet's public multicast IP destination address into a private IP multicast address. - In the outbound direction, NAT gateways generally translate the multicast application packet's private source IP address into a dynamically selected public IP address. Exceptions to this policy for source specific multicast are noted in subsequent sections. - Within each administrative domain, a multicast routing protocol domain routes packets based on the group's destination multicast public IP-v4 address. The multicast routers will distribute the group's packets to all of the group's Group Receiver endpoints residing in that administrative domain. - The border routers of each of the administrative domains spanned by the group do cross-realm multicast routing and distribution on behalf of the group. The IP-v4 multicast routers that exchange reachability information regarding the group across trust boundaries authenticate that information. Gross Expires January, 2004 page 49 GSAKMP Application to the IP Security Architecture July, 2004 "A" Admin . ISP Admin . "B" Admin Domain . Domain . Domain . . +---------------.--------------.-------------------+ | . . | | P U B L I C . I P - v 4 . I N T E R N E T | | . . | +------/\-------.-----A-----A--.----/\--------/\---+ || public. | | . || public || || IP-v4 . | | . || IP-v4 || +------\/------+. | | .+---\/---+ +--\/---+ |Grp.Z |NAT "A"|. | | .|Group Z | |NAT "B"| |S-GCKS|gateway|. | | .|P-GC/KS | |gateway| +---A--+---A---+. | | .+---A----+ +--A----+ | | .registratn | . | | regist. SA| . SA | . regist. SA | | | . | | . | | +-V-+ | . +-V-+ | . +-V-+ | |GM1| | . |GM2| | . |GM3| | +-A-+ | . +-A-+ | . +-A-+ | | | . | | . | | Group data SA . Group data SA. Group data SA rekey SA . rekey SA . and rekey SA | | . | | . | | +-V------V--+ . +---V-----V-+.+---V---------V-+ | Group "Z" | . | Group "Z" |.| Group "Z" | | multicast | . | multicast |.| multicast | | routing | . | routing |.| routing | | domain | . | domain |.| domain | +-----------+ . +-----------+.+---------------+ . . Figure 2 Representative GSAKMP/NAT architecture 6.4.2 Representative GSAKMP Multi-Realm Configuration Figure 2 illustrates a representative group "Z" wherein a GSAKMP group security association spans two private IP-v4 networks and the public IP-v4 Internet. The Group "Z" GC/KS has two network interfaces, one attached to the public Internet and the other interface attached to the administrative domain "B" private network. The group member GM1 resides within the administrative domain "A" private network. It communicates with the group Z Group Speaker endpoint(s) through the administrative domain "A" NAT gateway. When Gross Expires January, 2004 page 50 GSAKMP Application to the IP Security Architecture July, 2004 GM1 multicasts application SA traffic to the group Z public multicast address, the Group Z peer members (i.e. GM2, and GM3) receive that multicast with the source address translated by NAT gateway "A" processing. In the inverse direction, the administrative domain "A" NAT gateway/firewall must be configured to allow Group Z multicast application GSA traffic to enter the private network "A" from the public Internet (e.g. a multicast originating from GM3). The group member GM3 resides within the administrative domain "B" private network. Its interactions with Group Z are very similar to those discussed for member GM1. It uses private addresses when communicating with the P-GC/KS, as it is in private network "B". The group member GM2 is in a public Internet administrative domain operated by an ISP. It communicates with the P-GC/KS using public IP-v4 addresses without passage through a NAT gateway. When GM2 multicasts application SA traffic to the group Z public multicast address, the Group Z peer members behind NAT gateways receive that multicast with the source address unchanged by NAT processing. Each administrative domain operates an IP-v4 multicast routing domain instance. The multicast routers distribute both GSAKMP RKE messages and multicast application GSA data traffic. The multicast routing for group "Z" peers between these three multicast routing domains. 6.4.3 Registration Security Association NAT Traversal The GSAKMP registration protocol's unicast messages are exchanged between a GC/KS in the public IP-v4 Internet and a candidate Group Member that may be in a private network. A group member sends a registration SA GSAKMP message to the GC/KS public IP-v4 address and the GSAKMP reserved port number. The group member assigns a unique GSAKMP UDP source port number for each GSAKMP registration SA that it participates in. The group member SHOULD send the GSAKMP UDP packet without a checksum to avoid NAT alterations to that field. The UDP packet's transmission error detection depends on the GSAKMP Signature payload. A NAT gateway on the path leading to the GC/KS translates the private source IP address and source UDP port number into a public address and a temporary UDP port number (assuming NAPT), then forwards the packet to the GC/KS. The NAT gateway creates state information for that public/private address mapping so it can do the inverse translation on the GSAKMP messages sent from the GC/KS to that group member. Gross Expires January, 2004 page 51 GSAKMP Application to the IP Security Architecture July, 2004 The GC/KS must process the GSAKMP messages that it receives from group members originating from any source IP address or source port number, even if those two values have changed since the last time that the GC/KS had interacted with a given group member. To identify the group member, the GC/KS MUST use the GSAKMP signature payload's identifying information and validate the message's digital signature. After processing a message from a group member that requires a GC/KS response, the GC/KS creates the GSAKMP UDP message destined for the same IP-v4 address and UDP port that the GC/KS found in the candidate Group Member message's source IP address and UDP source port. 6.4.4 GSAKMP Re-key GSA NAT Traversal The GSAKMP Re-Key GSA is considerably simplified by the constraint that every Subordinate-GC/KS and Primary-GC/KS MUST straddle a public Internet/private network boundary adjacent to wherever it has Group Members behind a NAT gateway. Consequently, a GC/KS may have Group Members on either side of that boundary, but there is no intervening NAT gateway tampering with the GC/KS transmissions. The GC/KS multicasts the GSAKMP Re-Key Event message to the Re-Key GSA in an ESP protected UDP|NORM|GSAKMP packet addressed to its (sub-)group's destination public IP-v4 multicast address. The UDP destination port is set to the GSAKMP-NORM-UDP reserved port number. The group keyed ESP authenticator protects the UDP payload, so a UDP checksum MUST NOT be used. A multi-realm IP-v4 GSAKMP group operates in autonomous distributed mode. Therefore, each of the group's Subordinate-GC/KS must relay to their respective sub-group membership the GTEK and policy token that it extracts from the Primary-GC/KS RKE multicast. The S-GC/KS sends its RKE message to its sub-group membership from its public Internet interface. 6.4.5 Application GSA NAT Traversal Unlike the RKE message multicast to the Re-Key GSA, a multicast application message sent to the group may originate from a Group Speaker endpoint located behind a NAT gateway. Since the application's message is encrypted within an ESP payload, the transport layer protocol header port fields are concealed from NAT gateways and they can not participate in NAPT. The multicast Gross Expires January, 2004 page 52 GSAKMP Application to the IP Security Architecture July, 2004 application GSA must be handled differently depending on whether the application requires source-specific multicast. If the application requires source-specific multicast routing, then there must be a separate public IP-v4 address statically reserved at the NAT gateway for each Group Speaker endpoint private/public address mapping. This constraint allows the GC/KS to specify at every Group Member the inbound SPD traffic selector with a pre- determined public source address for each Group Speaker endpoint in the group. The traffic selector's public source address in combination with the group's destination multicast address and SPI selects the inbound SA. Keeping the NAT gateway's source address mapping static rather than dynamic also allows the multicast routers along the packet's path to apply source-specific routing policies. Note that the use of a static source address mapping NAT avoids the need for the group's policy token to specify UDP encapsulated ESP. The drawback of this approach is that the GC/KS SPD/SAD configuration database must be kept synchronized with the group's NAT gateway address mapping configurations. These operational procedures can be labor-intensive and error-prone, making large- scale group deployments difficult. The SAM message side steps this problem (see section 7) by dynamically setting the Group Receiver endpoint's SPD/SAD entry traffic selector rather than relying on static GC/KS configuration. If the application requires the any-source multicast service model, then the NAT gateway's source address translation can use dynamically allocated public IP-v4 addresses rather than statically allocated IP-v4 addresses. However, unless the group uses UDP encapsulated ESP, then the NAT gateway must have a pool of public IP-v4 addresses reserved that is at least as large as the number of Group Speaker endpoints within its private network. The public IP address pool allows the NAT gateway to do a one-to-one mapping from every Group Speaker endpoint's private source address to a dynamically allocated public source address. In this case, the use of NAPT rather than NAT is not an option, since the transport layer protocol is within an opaque ESP payload. The GC/KS specifies the SPD/SAD traffic selector as the combination of the group's destination multicast address and the SPI. In some deployments, the number of public IP-v4 addresses assigned to a NAT gateway is very limited (e.g. only one public address). Also, it may be difficult to predict how many Group Speaker endpoints will reside within the private network before the group begins its operation. For these cases, the group MAY use UDP Gross Expires January, 2004 page 53 GSAKMP Application to the IP Security Architecture July, 2004 encapsulated ESP. The NAT gateway applies NAPT to the UDP header's source port field, sidestepping the constraint of its limited public address pool. The Group Owner modifies the group policy token to specify that the outbound SPD processing must pre-append a UDP header in front of the ESP header. When a Group Speaker endpoint originates a multicast application packet, it inserts a UDP header in front of the ESP header, as per reference [UDPESP]. 7 Security Association Management Message A Group Speaker multicasts the Security Association Management (SAM) message to create a Group Security Association's SPD/SAD configuration at the Group Receiver endpoints. In addition to the SAM message, the GSAKMP IPsec application extends the GSAKMP base protocol with three new GSAKMP payload types: . Security Association Configuration (SAC) . Identity to Transient Address Mapping (ITAM) . Transport Endpoint Binding Attribute Certificate (TEBAC) as a Certificate payload. See section 3.3.3. Table 1 shows for which GSAKMP messages the ITAM, SAC, and TEBAC payloads are required, optional, or prohibited. Exchange Type ITAM Payload SAC Payload TEBAC Payload RTJ MUST MUST NOT MUST KDL MAY MUST MUST NOT KDL-ACK/NACK MUST NOT MUST NOT MAY RTD MUST NOT MUST NOT MUST DR MUST NOT MUST NOT MUST NOT DR-ACK MUST NOT MUST NOT MAY SAM MUST MUST MUST RKE MUST MUST MUST Gross Expires January, 2004 page 54 GSAKMP Application to the IP Security Architecture July, 2004 Table 1 _ ITAM, SAC, and TEBAC payload presence requirements A Group Speaker endpoint multicasts a SAM message under the following conditions: - After the Group Speaker endpoint has sent a KDK-ACK response to its GC/KS and before it multicasts its first application protocol data unit, the Group Speaker MUST multicast a SAM message to create the leading edge GSA SPD/SAD state at its Group Receiver endpoints. - Periodically, the Group Speaker multicasts a SAM message at sufficiently frequent intervals that it replaces the current GSA with a new leading edge GSA before the current GSA expires due to elapsed lifetime or reaching its key's cumulative data encryption limit. - After each change in one of the Group Speaker's interface transient IP address assignments. Alternatively, a group security policy that requires proof of return route-ability will mandate that the Group Speaker re-register with a GC/KS before sending a SAM. Every authorized Group Receiver endpoint receives the SAM message at the multicast application's destination IP address. The SAM multicast is a "best effort" UDP payload, and it SHOULD NOT use a RMTP. Each Group Receiver endpoint validates the Group Speaker's SAM using the procedure defined by section 7.2. If any of these checks fail, then the SAM message is discarded. 7.1 GSAKMP Security Association Management Message Syntax The Security Association Management message comprises a GSAKMP header encapsulating the sequence of GSAKMP payloads shown in table 2. Table 2 Security Association Management Message Message Name : Security Association Management Dissection : {HDR-GrpID, Nonce-Speaker, Nonce-Membership, Identity to Transient Address Mapping, {SA- Config}*, [Key Creation], [Vendor-ID], [Notification]} SigN, [SpeakerCert], Gross Expires January, 2004 page 55 GSAKMP Application to the IP Security Architecture July, 2004 [NodeCert], AttribCert Payload types : GSAKMP header, Nonce, Identity to Transient Address Mapping, SA-Config, [Key Creation], [Notification], [Vendor-ID], Signature, Certificate SigN : Node Identity's signature SpeakerCert : The Group Speaker endpoint's signature end- entity X.509 certificate as profiled in section 9.2. NodeCert The Node Identity's signature end-entity X.509 certificate as profiled in section 9.4 AttribCert : The Node Identity's Transport Endpoint Binding Attribute Certificate Attribute Certificate, issued by the Group Speaker endpoint, as profiled by section 9.6. {data} SigN : Braces enclose the GSAKMP header and those payloads that are under the SigN signature [] : Indicates an optional GSAKMP payload {payload}* : Braces enclose payload encrypted by the GTEK Unless stated to the contrary, there can be only one GSAKMP payload of a given type per SAM message. The SAM GSAKMP payloads under the signature MAY be in any order, not just the order shown above in table 1. The Certificate payloads, if any, MUST follow the Signature payload. The Transport Endpoint Binding Attribute Certificate is the same one that was issued by the Group Speaker endpoint to its Node prior to its registration protocol exchange (see section 4.8). The TEBAC MUST be present in the SAM message, because it is the Group Speaker endpoint's authorization of the binding between the Node's signature identity and the multicast application endpoint attributes asserted in the SAC and ITAM payloads. Gross Expires January, 2004 page 56 GSAKMP Application to the IP Security Architecture July, 2004 7.2 SAM Message Verification A Group Receiver endpoint accepts the SAM message only after it has successfully executed the following verification steps in the given order. If any of these steps fail, then the Group Receiver endpoint MUST discard the SAM message. It MAY log an error but SHOULD NOT trigger an alarm message (e.g. SNMP TRAP) unless it is rate dampened and it uses a randomly dithered transmission time. 1. The SAM GSAKMP header and the GSAKMP payloads that the header envelopes all MUST have the correct length and correct payload types as defined in section 7.1. There can only be one instance of the following payload types: SAC, ITAM, Signature, Key Creation, and Vendor-ID. There can be zero or more instances of the Notification payload type. There MUST be at least one Certificate payload which contains the TEBAC. There MUST be two Nonce payloads, and they respectively contain a Nonce-Speaker nonce type and a Nonce-Membership nonce type. 2. The GSAKMP header's Group Identifier type MUST be of type "IP-v6", and it MUST match one of the groups for which the SAM receiving Node possesses an active membership. A SAM message that arrives at a Group Receiver endpoint during its registration or de- registration protocol exchange is not an error but it is silently discarded. 3. The SAM message depends on its GSAKMP header's sequence number for anti-replay protection. The Group Receiver endpoint MUST verify that the SAM GSAKMP header's sequence number is greater than the previously received SAM message from the same Group Speaker. Receipt of SAM re-transmission duplicates is possible and they MUST be silently discarded. The first SAM sequence number transmitted MUST have the value of one (1). The Group Speaker advances its GSAKMP header's sequence number after each distinct SAM message. Group Receiver endpoints MUST NOT update their view of the SAM sequence number to the value received in the SAM message's GSAKMP header until all the message's verification steps complete successfully. 4. The Nonce-Membership payload's value MUST be verified for freshness and the Group Receiver endpoints MUST confirm that the Group Speaker endpoint possesses the GTEK. The "Nonce-Speaker" payload contains a random value that MUST be at least 4 octets in length. The Nonce-Membership value is the 20 octet HMAC-SHA1 hash of the group's current policy token concatenated with the Nonce- Gross Expires January, 2004 page 57 GSAKMP Application to the IP Security Architecture July, 2004 Speaker payload's value. The current GTEK is the key input to that HMAC-SHA1 operation. The Group Receiver endpoint locally computes its own view of the Nonce-Membership payload's value. If the Nonce-Membership value that it computes is the same as the value found in the Nonce-Membership payload, then that proves the Group Speaker endpoint possesses the current GTEK. 5. The TEBAC "Issuer" field identifies the Group Speaker endpoint. This "Issuer" field MUST match one of the group membership authorization pattern match rules found in the group's current policy token. 6. The TEBAC "Issuer" field MUST match one of the Group Speaker authorization pattern match rules found in the group's current policy token. 7. The TEBAC "Holder" field MUST match the SAM Signature payload's signer identification value, which is the Node Identity associated with the Group Speaker endpoint. 8. The Group Receiver endpoint MUST confirm that the Group Speaker's TEBAC validity period is not expired. 9. The TEBAC "Transport Endpoint Identifier" attribute type MUST assert the "S" flag. 10. The Group Speaker endpoint's TEBAC "Issuer" signature MUST be verified, and its signature certificate confirmed to have a chain of valid certificates rooted at one of the GSAKMP group's trust anchor Certificate Authorities. 11. The Node Identity's signature in the Signature payload MUST verify as per [GSAKMP] section 7.8. 12. The Group Receiver endpoint decrypts the SAC payload using the current GTEK. The SAC payload plain-text's Source Node Identity field MUST match the Node Identity that signed the SAM message. 7.3 SAM Message Processing After Successful Verification After all of the section 7.2 SAM message verification checks have succeeded, then a Group Receiver endpoint can process its payloads. The SAM message payloads are processed as follows: Gross Expires January, 2004 page 58 GSAKMP Application to the IP Security Architecture July, 2004 - The ITAM payload binds the Group Speaker's Node Identity to its associated set of transient locator IP addresses. The Identity to Transient Address Mapping payload handling is defined in section 7.4. - The Security Association Configuration payload creates a new Group Security Association instance by inserting its parameters into a GSA template's formal arguments as specified by the policy token. Section 7.5 defines the Security Association Configuration payload format and its handling. - The Key Creation payload supports an optional method of creating peer-to-peer secret keying material and derived security associations between any two GSAKMP group members that have multicast a SAM message to the group. The mechanisms that create and manage those unicast security associations are outside the scope of this standard. Endpoints that receive a SAM message and do not participate in the peer-to-peer key management MUST silently ignore this payload and continue normal processing of the SAM message. - The Notification payload is an optional mechanism to supplement the ITAM and SAC payloads with additional information or status. See section 7.6. Endpoints that receive a SAM Notification payload and do not understand the notification code and its contents MUST silently ignore this payload and continue normal processing of the SAM message. - The Vendor-ID payload is an optional mechanism to announce the presence of vendor-specific information sent from the Group Speaker to the group's membership. Endpoints that receive a Vendor-ID payload and do not understand its contents MUST silently ignore this payload and continue normal processing of the SAM message. GSAKMP exchange types and payload header types that are not understood MUST be silently ignored. 7.4 Identity to Transient Address Mapping Payload The SAM message's ITAM payload keeps the Group Receiver endpoint's SPD/SAD entries synchronized with NAT and mobility induced changes in the Group Speaker's IP addresses. The ITAM payload declares the mapping between three quantities: 1. The Group Speaker's Node Identity, as defined in section 3.1. Gross Expires January, 2004 page 59 GSAKMP Application to the IP Security Architecture July, 2004 2. The Group Speaker's one or more locator IP interface addresses, which can change over time due to mobility or other causes (e.g. DHCP lease expiration). 3. The source IP-v4 address found in the SAM message's IP header, which may have been assigned by an intervening NAT gateway. Unlike the previous two quantities, this quantity is not authenticated. After a GSAKMP Group Receiver endpoint successfully verifies the SAM message, it populates its local Secure Identity to Address Mapping (SIAM) database with the ITAM payload's identity to address mapping. Other system components (e.g. PIM, UDP) may subscribe to the SIAM event notification service, and receive accurate and authoritative mappings between a peer system's Node Identity and its transient locator IP addresses. Figure 1 shows this interface at (C2). The details of the SIAM implementation and its interactions with other processes is a local implementation matter outside the scope of this specification. As a matter of local security policy, the Group Receiver endpoint MAY also adjust its SPD entries to match the SAM message's public source IP-v4 address that had been assigned by a transit NAT gateway. See section 7.7 for discussion of the tradeoffs. Figure 3 illustrates the Identity to Transient Address Mapping GSAKMP payload's bits-on-the-wire format. The "Next Payload", the "Reserved-1", and "ITAM Payload Length" fields together form the standard GSAKMP payload header as defined in GSAKMP section 7.1. Immediately following the GSAKMP payload header, without alignment padding, is the fixed length portion of the ITAM payload. It contains the following fields: - Node Identity _ The Node Identity of the Node originating this ITAM payload, as per section 3.1. - Number of interfaces _ The number of interface IP addresses declared by this ITAM payload, each expressed as a 2-tuple of the form {Interface local index, transient IP address}. This value MUST be at least one and it has a maximum value of 31. - ITAM lifetime _ The duration in seconds after receiving the ITAM that an endpoint can trust this set of address mappings. The lifetime is relative to the timestamp in the GSAKMP message's Signature payload. When the trusted interval expires, then the Gross Expires January, 2004 page 60 GSAKMP Application to the IP Security Architecture July, 2004 Group Receiver endpoint should no longer accept multicast transmissions from this Group Speaker endpoint. After the above fixed length fields, the ITAM payload contains a variable length array containing one or more interface IP address structures as its elements. There is a fixed length interface IP address structure for each of the Node's unicast IP interface addresses. Each interface IP address structure has the following fields: - Reserved-2 field - 14 bits set to zero by sender; it is ignored by Group Receiver endpoints. - Interface Address Type (IAT) field _ A two-bit field that indicates the interface's attached IP network type: o b'00' _ Global scope unicast IP-v6 address o b'01' _ IP-v4 address, encoded as a "6to4" IP-v6 unicast address [RFC3056] with a globally unique unicast IP-v4 address embedded in its V4ADDR field. The IP-v6 address's Interface Identifier field low-order 32 bits are the interface's IP-v4 address, which may be allocated from either the public or a private IP-v4 address spaces. The Interface Identifier field high-order 32 bits are the Node's controlling GC/KS globally unique unicast IP-v4 address. Every GC/KS supporting an IP-v4 based GSAKMP group MUST have at least one interface with a public IP-v4 address. If the Node resides in a private IP-v4 network, then its GC/KS MUST also have at least one IP-v4 interface attached to the same private IP-v4 network as that Node. o b'10' _ reserved for future use o b'11' _ Private IP-v4 address encoded as defined for IAT=b'01', but with the GC/KS public IP-v4 address unknown, and therefore this address's Interface Identifier field high-order 32 bits are set to zero. - Interface local index _ A unsigned 16-bit integer in network-byte- order assigned by the Node to represent one of its network interfaces. Typically the interface local index refers to a link layer network adapter. Note that multiple IP-v6 addresses MAY share the same interface local index. Gross Expires January, 2004 page 61 GSAKMP Application to the IP Security Architecture July, 2004 - Interface IP-v6 address _ The IP interface's unicast IP-v6 address, mapped as specified by the IAT field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Reserved-1 | ITAM Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Node Identity | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITAM Lifetime | number of interfaces | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-2 |IAT| Interface "A" Local Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface "A" IP-v6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-2 |IAT| Interface "B" Local Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface "B" IP-v6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | . . . Other Interface addresses . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Identity to Transient Address Mapping GSAKMP payload After a successful ITAM payload verification, the Group Receiver endpoint MUST update: . Those SPD/SAD traffic selectors that reference the Group Speaker endpoint's previous (i.e. no longer valid) set of transient IP addresses. The ITAM payload does not alter the Group Speaker Gross Expires January, 2004 page 62 GSAKMP Application to the IP Security Architecture July, 2004 endpoint's SPI, source port, next layer protocol identifier, or destination port number assignments. . Within the Secure Identity/Address Mapping database, the Group Receiver endpoint updates the Node Identity data structure selected by the ITAM payload's Node Identity field. The SIAM process MUST notify those applications that depend on knowing the revised Node Identity to IP address set mapping. In figure 1, this is the implementation specific control interface labeled C2. For both of these databases, the Group Receiver endpoint replaces the Group Speaker Node's old set of IP addresses with the new set of IP addresses as declared by the ITAM payload. 7.5 Security Association Configuration Payload The SAM message's SAC payload creates (or destroys) a Group Security Association instance at every Group Receiver endpoint. The SAC payload contains the leading edge GSA traffic selectors, expressed as a Security Parameter Index (SPI), destination multicast IP address, source Node Identity, and any GSA related information. The SAC payload selects one of the GSAKMP IPsec policy token's Security Association Templates, and every Group Receiver endpoint inserts the SAC payload's actual parameters into that template's formal parameters. The Security Association Template originates from the Group Owner, and it expresses the Group Owner's security policy for a class of one or more Group Speaker endpoints. See section 7.6. Each Security Association Template has a set of associated speaker role authorization rules. These rules pattern match against a Group Speaker's identity, authorizing which Group Speaker endpoints may use that template. For some of the actual parameters supplied by the SAC payload, the template will provide formal parameter constraints (e.g. numeric ranges) for the acceptable actual parameter values. Figure 4 illustrates the Security Association Configuration GSAKMP payload's bits-on-the-wire format. The "Next Payload", the "Reserved-1", and "SAC Payload Length" fields together form the standard GSAKMP payload header as defined in [GSAKMP] section 7.1. The remainder of the SAC payload contains the following fields: . GSAKMP IPsec policy token sequence number _ This value MUST be equal to the group's current GSAKMP IPsec policy token sequence number. If it is not equal, then the GSAKMP message containing this SAC payload is discarded. Gross Expires January, 2004 page 63 GSAKMP Application to the IP Security Architecture July, 2004 . Security Association Template identifier _ Refers to a Security Association Template structure within the current GSAKMP IPsec policy token. It is an unsigned 32-bit integer in network byte order. If this identifier does not reference a valid Security Association Template, then the GSAKMP message containing this SAC payload MUST be discarded. . Security Parameter Index (SPI) _ A random value allocated by the Group Speaker endpoint within the range that has been reserved for this Group Speaker. The SPI component MUST be unique amongst all GSA active in the group. It also MUST be unique amongst all of the SPI allocated by any other groups that share the same multicast destination IP address. If the GSAKMP group is a Source-Specific Multicast group then the SPI uniqueness requirement is qualified by the speaker's source IP address and the group's destination multicast IP addresses. If the SPI asserted by the SAC payload collides with an existent GSA, then the GSAKMP message containing this SAC payload is discarded and an error MUST be logged. See section 4.11 for additional discussion regarding SPI allocation coordination among multiple Group Owners. . Group Traffic Encryption Key identifier . Group Traffic Encryption Key version . Group Traffic Authentication Key identifier . Group Traffic Authentication Key version . ESP sequence number _ The security association's ESP header first sequence number, expressed as an unsigned 64-bit integer in network byte order. When the SAC payload is part of a KDL message, then a new Group Receiver endpoint can synchronize its receive GSA state with an existent GSA. A Group Speaker using the GSA re-key rollover continuity feature MAY multicast a SAM message with a SAC payload having consecutive ESP sequence numbers across the transition from the trailing edge to the leading edge GSA time epochs. - Source Node Identity _ This value MUST match the Node Identity asserted in the GSAKMP message's ITAM payload and the Signature payload's signer identity value. If these Node Identity values do not match then the GSAKMP message containing the SAC payload MUST be discarded. Gross Expires January, 2004 page 64 GSAKMP Application to the IP Security Architecture July, 2004 - Destination multicast IP-v6 address authorized to be used by the Group Speaker endpoint. If the group is using IP-v4 multicast distribution then this address is algorithmically translated from IP-v6 to IP-v4 as per the procedure in section 3.7. - Next Layer Protocol Identifier _ The GSAKMP group's multicast application's transport layer protocol identifier (e.g. UDP, NORM, etc.) as described in section 3.3. Refer to IANA for the current valid IP header protocol identifier assignments. - Destination Port _ The multicast application endpoint's destination port number as described in section 3.3. - Source Port _ The multicast application endpoint's source port as described in section 3.3. - Security Association lifetime _ The GTEK encryption transform hard time limit, the amount of time that this security association exists before it self-terminates. - "D" flag _ A Group Speaker can destroy one of its existent GSA before the GSA lifetime expires by setting the SAC payload "D" flag, and sending in a SAM message the same SAC payload parameters as it had sent in its previous SAM message that referred to the same GSA. Gross Expires January, 2004 page 65 GSAKMP Application to the IP Security Architecture July, 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Reserved-1 | SAC Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GSAKMP IPsec policy token sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Template identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Traffic Encryption Key identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Traffic Encryption Key version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Traffic Authentication Key identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Traffic Authentication Key version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP sequence number | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source Node Identity | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Multicast IP-v6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next Layer PID |D| Reserved-3 | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA Lifetime | Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 _ Security Association Configuration GSAKMP payload Gross Expires January, 2004 page 66 GSAKMP Application to the IP Security Architecture July, 2004 7.6 Security Association Template The GSAKMP IPsec policy token encodes one or more Security Association Templates. A Security Association Template declares a Group Owner's security policy for a class of Group Speaker and Group Receiver endpoints that share a Group Security Association. Each such template contains: . Group Speaker role authorization pattern matching rules, which represents the set of X.509 identities permitted to become a GSA Group Speaker using this template. . The GSA SAD information that is common across all GSA instantiations based on this template, as described previously in section 5.5. . A set of formal parameter constraints on the SAC payload's actual parameter values. These constraints are represented as the valid ranges for the following SAC payload parameters. If a SAC payload asserts a value outside of its associated template's range, then the SAC payload and its GSAKMP message MUST be discarded. o Source Node Identity's GSAKMP IPsec group sub-net identifier o Destination multicast IP-v6 address o Next layer protocol identifier o Destination port o Security association hard limit lifetime o Security Parameter Index . Tunnel mode GSA information, as per section 5.10 . If the GSAKMP group policy requires that the Group Speaker use digital signature multicast source authentication, then the Security Association Template specifies the Group Speaker's source authentication protocol, algorithm, and related parameters. Some source authentication algorithms (e.g. TESLA) will require that the GSAKMP IPsec policy token announce other algorithm-specific parameters. Gross Expires January, 2004 page 67 GSAKMP Application to the IP Security Architecture July, 2004 7.7 GC/KS Co-located at the Transit NAT Gateway For a GSAKMP multi-realm IP-v4 based group, special processing occurs for a Group Speaker's SAM message. If none of the Group Speaker's interface IP-v4 addresses within the ITAM payload match the SAM message's IP header source IP-v4 address, then a transit NAT gateway translated that address while the datagram was in transit. Since the NAT gateway's alteration is not authenticated, the GSAKMP group policy must pick one of two alternatives: 1. Assume that the translated source IP-v4 address is sufficiently trustworthy without proof of return route-ability, and the Group Receiver endpoints immediately modify their SPD/SAD to use that address for the Group Speaker's traffic selector entries. 2. The translated source IP-v4 address is not sufficiently trustworthy "as is", and it should not be installed in the Group Receiver endpoint's SPD/SAD traffic selectors until it is substantiated by a re-registration. All GSAKMP IPsec IP-v4 implementations MUST support this policy. The second group policy requires that the Group Speaker endpoint re- register with the GC/KS (section 4.8) co-located with the transit NAT gateway at the public/private network boundary. The cookies exchange proves the return route-ability of the translated source IP address. After its re-registration completes, the Group Speaker multicasts the SAM message to the Group Receiver endpoints. The Group Receiver endpoints confirm that one of the ITAM payload's interface IP address structures has an IAT field set to b'01' with an interface IP-v6 address containing the GC/KS public IP-v4 address in its Interface Identifier. The GC/KS public IP-v4 address MUST match the SAM message's translated source IP address. The drawback of the proof of return route-ability policy is its high latency penalty that interrupts continuous streaming media transmission from the Group Speaker endpoint. 7.8 SAM Notification Payload Handling To be defined. 8 NACK-Oriented Reliable Multicast Protocol Profile At the time of this writing, the Negative-acknowledgement Oriented Reliable Multicast (NORM) protocol is an IETF experimental track Gross Expires January, 2004 page 68 GSAKMP Application to the IP Security Architecture July, 2004 specification being developed in the Reliable Multicast Transport (RMT) working group. NORM is a general-purpose facility that accommodates many diverse multicast applications. For its purposes, the GSAKMP IPsec application only needs the simple subset of the NORM protocol that is optimal for the GSAKMP RKE message reliable multicast transport. This section prescribes an interoperable profile based on the NORM protocol as it exists at the time of this writing. The expectation is that in the long-term, this profile will be deprecated and altogether replaced by the NORM protocol when it makes its planned transition to IETF proposed standard status. Until then, compliant GSAKMP IPsec implementations MUST support the use of the NORM protocol subset defined herein for reliable RKE message delivery. 8.1 GSAKMP/NORM Subsystem Mandatory Features There is only one GC/KS NORM session per GSAKMP group, or else when in autonomous distributed mode then there is one S-GC/KS NORM session per GSAKMP sub-group. This GC/KS NORM session is independent from any NORM sessions that might be created in the same group by the multicast application. The GC/KS is the NORM session's only multicast sender. The NORM protocol messages are UDP encapsulated, and they are protected by a GSAKMP ESP Group Security Association. Referring to the figure 1 data flow (D2), the protocol stack is as follows: IP|ESP|UDP|NORM|GSAKMP RKE payload The GC/KS NORM session's UDP destination port number is GSAKMP-NORM- UDP (value TBD by IANA). A NORM message's NormNodeId is the SHA hash of the source Node's Node Identity truncated to use the low-order 32 bits. The NormTransportId monotonically increases for each RKE multicast. The GSAKMP/NORM subsystem assigns the NormInstanceId; this value SHOULD be unique across GC/KS re-boots. The NORM-FLAG-MSG-START marks the start of each RKE message boundary. The NORM-FLAG-INFO, NORM-FLAG-STREAM, NORM-FLAG-FILE, and NORM-FLAG-UNRELIABLE flags MUST NOT be set. The NORM-ROBUST-FACTOR is a tunable quantity that controls how many NORM retry attempts are allowed by the error recovery procedure. It SHOULD be configurable by the GSAKMP Group Owner management interface. The RECOMMENDED value is 3. Gross Expires January, 2004 page 69 GSAKMP Application to the IP Security Architecture July, 2004 The GSAKMP/NORM subset MUST NOT use the NORM "ack node" list capability. The GSAKMP/NORM subsystem MUST support the following protocol message types: - NORM-DATA messages only specify the NORM-OBJECT-DATA attribute. Section 8.Y gives constraints on the NORM-DATA Forward Error Correction (FEC) algorithms and payloads. - NORM-CMD(FLUSH)- This command is sent by the GC/KS sender after the last FEC payload segment of a RKE transmission. - NORM-CMD(SQUELCH) - NORM-CMD(CC) _ congestion control - NORM-CMD(REPAIR-ADV) _ sender's repair state advertisement - NORM-NACK - NORM-ACK Any of the NORM protocol optional message types MAY be supported by a GSAKMP/NORM implementation, however, these messages types MUST NOT be used with a GC/KS NORM session. They MAY be used with other multicast application NORM sessions, i.e. the figure 1 data flow labeled (D1). 8.2 Forward Error Correction Algorithms To be defined. 8.3 Group-wide Default Path MTU Length The NormSegmentSize is less than the path MTU, as it MUST be adjusted to subtract the overhead length of the IP header, IP-v6 extension headers (if any), AH (if any), ESP header, ESP trailer, UDP header, and NORM header. For IP-v6, the default path MTU is 1280. For IP-v4, the default path MTU is 580 bytes. Gross Expires January, 2004 page 70 GSAKMP Application to the IP Security Architecture July, 2004 9 GSAKMP IP Security Public Key Infrastructure Profile This section profiles the GSAKMP IPsec subsystem's requirements and certificate conventions for its supporting Public Key Infrastructure. Figure 1 shows the GSAKMP/PKI interface at (C1). As its guiding principle, the GSAKMP IPsec architecture creates a short-lived attribute certificate that binds each application endpoint in a GSAKMP group to a Node Identity before starting a Node's GSAKMP protocol exchanges on behalf of that application endpoint. Both the application endpoint identity and the Node Identity are long-lived in comparison to the attribute certificate. This approach allows an application endpoint identity representing a roaming GSAKMP end user to dynamically bind to a Node for the duration of a group membership, rather than assuming a permanent static relationship. A short lived attribute certificate also avoids the complexity of a revocation mechanism. 9.1 Identification and Signature Payload Signer ID Types The [GSAKMP] table 19 defines the GSAKMP identification types that match against certificate identities and SPD symbolic name selectors. These identification types are used by both Identification payloads and also for the Signature payload's signer identification type. The GSAKMP IPsec application requires that GSAKMP IPsec implementations MUST support both sending and receiving of the following identification types in the Identification and Signature payloads: . ID-IPV4-ADDR . ID-FQDN . ID-IPV6-ADDR . ID-RFC822-ADDR . ID-DER-ASN1-DN . ID-UNENCODED-UNAME The ID-IPV4-ADDR, ID-FDQN, ID-IPV6-ADDR, and ID-RFC822-ADDR MUST exactly match the corresponding certificate "SubjectAltName" field. The SPD symbolic name selector MUST support exact matching against Gross Expires January, 2004 page 71 GSAKMP Application to the IP Security Architecture July, 2004 these identification types and MAY support wildcard or regular expression string matching. The ID-DER-ASN1-DN MUST match the certificate's "Subject" field using bit-by-bit comparison. The SPD symbolic name selector MUST support any combination of the "C", "CN", "O", or "OU" attributes. The ID-KEY-ID identification type is not standardized by this profile and SHOULD NOT be used. 9.2 Application Endpoint Signature Certificate The application endpoint end-entity signature certificate profile strikes a balance between accommodating existing PKI certificate deployments, and constraining those certificates to avoid the inter- operability problems witnessed in RFC2401 compliant IPsec/IKE deployments. This profile subsets the [GSAKMP] requirement for compliance with the [RFC3280] profile and further requires that it MUST be a X.509-v3 certificate. Unless qualified to the contrary by this specification, a certificate inherits whatever RFC3280 has profiled. 9.2.1 Subject Field Distinguished Name The Subject field X.500 distinguished name MUST NOT be empty, as issuing the TEBAC has a dependency on its value (see section 9.6.1) The Subject field MUST declare the "C", "CN", "O", and "OU" attributes. 9.2.2 SubjectAltName Extension If the SubjectAltName extension is present, it SHOULD be a rfc822Name, ipAddress, or dNSName. It MUST NOT be an otherName, x400Address, directoryName, ediPartyName, or registeredID. 9.2.3 Issuer Field To be defined. 9.2.4 Key Usage and Extended Key Usage Fields To be defined. Gross Expires January, 2004 page 72 GSAKMP Application to the IP Security Architecture July, 2004 9.3 GSAKMP Certificate Payload Types Compliant GSAKMP IPsec implementations MUST be able to send, receive, verify, and process Certificate payloads containing X.509- v3 end-entity and intermediate CA signature certificates ([GSAKMP] table 20, certificate type 4). The Transport Endpoint Binding Attribute Certificate when sent in a Certificate payload uses [GSAKMP] table 20 certificate type 10. 9.4 Node Identity End-Entity Public Key Certificate Each Node MUST have an X.509-v3 end-entity signature public key certificate that meets the profile given in this section. There is usually only one Node Identity signature public key/secret key pair per Node, rather than one such key pair per GSAKMP group that the Node is a participant. For all of the GSAKMP groups managed by a given Group Owner, the Node uses its Node Identity certificate to prove its identity in all of those groups that it participates. As its starting point, the Node Identity certificate MUST conform to the [RFC3280] profile. This section further qualifies the required usage and values for many of that certificate's fields. The Group Owner management system MAY be the Certificate Authority for the Node Identity certificate issued to a Node. Alternatively, the GSAKMP Group Owner management system oversees the Node Identity certificate lifecycle through a Certificate Management System interface that is outside the scope of this standard. However, in either case the Group Owner MUST enforce the Node Identity uniqueness requirement across all of its registered Nodes. It is RECOMMENDED that the Node Identity key pair creation and certificate enrollment process occur as a part of a Node's GSAKMP IPsec subsystem installation process. The Node Identity certificate's "signatureAlgorithm" MUST be either be DSA-SHA1 or RSA-MD5 as per [PKIXALGS]. 9.4.1 Subject and SubjectAltName Extension The Node Identity certificate MUST have an IP-v6 address "subjectAltName" critical extension, with its value set to the Node Identity IP-v6 address as defined in section 3.1. The Node Identity certificate MUST have a Subject field distinguished name conformant to the profile in 9.2.1. In addition, the Node Identity public key certificate MAY also have a Fully Qualified Domain Name or IP-v4 Gross Expires January, 2004 page 73 GSAKMP Application to the IP Security Architecture July, 2004 address "subjectAltName" field. It SHOULD NOT have a RFC822 name as a "subjectAltName". 9.4.2 Unique Identifiers As specified by [RFC3280] section 4.1.2.8, the Node Identity certificate MUST NOT use the "issuerUniqueID", and "subjectUniqueID" fields. 9.4.3 Key Usage and Extended Key Usage Extensions The "keyUsage" extension MUST be present and marked as critical. It MUST indicate that the Node Identity's public key can be used to validate a digital signature. Other key usage flags MUST NOT be asserted. The Extended Key Usage extension MAY be present but it MUST NOT be marked critical. Interpreting its value is a local matter set by Group Owner policy. 9.4.4 Certificate Policies Extension To be defined. 9.4.5 Subject Key Identifier Extension The subject key identifier extension MUST be present in the Node Identity certificate and it MUST NOT be marked critical. The "keyIdentifier" SHOULD be the 160-bit SHA1 hash of the public key. 9.4.6 Authority Key Identifier Extension The Authority Key Identifier extension MUST be present in the Node Identity certificate. 9.4.7 Basic Constraints Extension If the "BasicConstraints" extension is present then it MUST have the "cA" boolean set to FALSE. 9.5 Group Trust Anchor Public Key Certificate Key-ring The PAD defines the trust anchor public key certificates for each GSAKMP group. These MAY be organized as a database containing one or more key-rings, each indexed by a key-ring identifier. A key-ring in that database contains one or more Certificate Authority certificates or else references to where those certificate can be Gross Expires January, 2004 page 74 GSAKMP Application to the IP Security Architecture July, 2004 retrieved and/or verified (e.g. an LDAP directory). The GSAKMP IPsec management interface MUST have the ability to associate each GSAKMP group with a single key-ring or an equivalent trusted database. The key-ring MUST support at least two CA certificates. Other key-ring and Public Key Infrastructure configuration management facilities (i.e. add/remove certificates to/from the key-ring) SHOULD be implemented. 9.6 Transport Endpoint Binding Attribute Certificate The Transport Endpoint Binding Attribute Certificate is an GSAKMP IPsec interpretation of "An Internet Attribute Certificate Profile for Authorization" [RFC3281]. The RFC3281 mandates the X.509-2000 version 2 definition of an attribute certificate. Any attribute certificate field not explicitly qualified herein simply inherits the RFC3281 definition. 9.6.1 IssuerName Field To comply with [RFC3281] section 4.2.3, the "issuerName" MUST contain a single "GeneralName" having a non-empty distinguished name in its "directoryName" field. This constraint prohibits the use of those application endpoint end-entity certificates that have an empty distinguished name as a TEBAC issuer entity. The distinguished name MUST conform with the rules given in this document's section 9.2. The "baseCertificateID" and "objectDigestInfo" forms of "issuerName" MUST NOT be used. 9.6.2 Holder Field The X.509 attribute certificate's "Holder" field is a SEQUENCE OF options, for which a TEBAC MUST have only one instance of the "baseCertificateID" option. The "entityName" and "objectDigestInfo" options MUST NOT be used in the TEBAC "Holder" field. The Node Identity signature public key certificate's "serialNumber" and "issuer" fields are identical to the TEBAC "Holder" field. 9.6.3 TEBAC Issuer Signature Algorithm The TEBAC signature algorithm MUST be DSA-SHA1 as per [PKIXALGS]. 9.6.4 Validity Period and TEBAC Revocation Strategy It is an explicit GSAKMP IPsec security assumption that the TEBAC validity period is short-lived and that certificate revocation Gross Expires January, 2004 page 75 GSAKMP Application to the IP Security Architecture July, 2004 status does not need to be maintained. The validity period is set by the application endpoint issuer's security policy. The TEBAC validity period SHOULD be tailored to minimally bracket the application endpoint's predicted GSAKMP group membership lifetime. Alternatively, the validity period MAY bracket each GSAKMP protocol exchange, although this incurs the overhead of issuing a TEBAC more frequently. Consequently, the "noRevAvail" extension MUST be present in the TEBAC. The authority information access and CRL distribution point extensions MUST NOT be present in the TEBAC. When validating a "attrCertValidityPeriod", the GC/KS MUST compare it against both the GSAKMP message's Signature payload Signature Timestamp field ([GSAKMP] figure 21, section 7.8) and also the local system's clock. 9.6.5 Attribute Certificate Targeting Extension The Attribute Certificate Targeting extension prescribes the set of GC/KS authorized to provide GSAKMP group management services for the issuer application endpoint. However, this version of the GSAKMP IPsec profile does not require GC/KS to inspect and act on the contents of this TEBAC field. A TEBAC MAY be issued without the "attrCertTargeting" extension and the GC/KS verifiers MAY ignore this extension. 9.6.6 Group Attribute Type The "Group" attribute type MUST be present within the TEBAC Attributes field. The "Group" attribute type is a set of one or more values, and each such value MUST specify a valid GSAKMP IPsec group identifier, as defined in section 3.2. The TEBAC "Group" attribute type SHOULD have only one GSAKMP group value. The application endpoint authorizes the Node Identity to sign its GSAKMP messages for each of the GSAKMP groups named by the "Group" attribute. The "Group" field's value encoding MUST compare equal on a bit by bit basis with the GSAKMP group header's group identifier value as per [GSAKMP] section 7.1.1.1.4. 9.6.7 Access Identity Attribute Type The TEBAC profile defines a "transportEndpointIdentifier" data structure mapping on the "accessIdentity" attribute type (refer to RFC3281 section 4.4.2). The transportEndpointIdentifier represents the transport layer endpoint identifier for which the TEBAC issuing application endpoint authorizes a Node Identity to sign GSAKMP Gross Expires January, 2004 page 76 GSAKMP Application to the IP Security Architecture July, 2004 messages and setup SPD/SAD entries on its behalf. The TEBAC "Access Identity" attribute type MUST be present in the TEBAC "Attributes" field, and that attribute type MUST have only one fixed length value. The Access Identity attribute's value is in "SvceAuthInfo" syntax, but MUST NOT have the "authInfo" component. The SvceAuthInfo "service" component encodes the GSAKMP message signer's delegated authority. The "service" is a GeneralName OCTET STRING. It is encoded in one octet as a set of bit flags authorizing which types of GSAKMP messages that the Holder Node Identity may sign on behalf of the Issuer application endpoint. Multiple flags may be OR'ed together: o Group Speaker mode membership registration, 0x01 o Group Receiver mode membership registration, 0x02 o De-registration,0x04 o Group management (RKE), 0x08 o All other bits reserved for IANA allocation, and set to zero The SvceAuthInfo "ident" component concatenates the following TransportEndpointIdentifier data structure fields in the following order: . TransportEndpointIdentifier version number, 1 octet, set to zero for this specification version. This value maps the TransportEndpointIdentifier data structure, allowing new fields to be defined in a future specification revisions. . Application endpoint's identification type, 1 octet, as defined by [GSAKMP] table 19. This document's section 9.1 defines which identification types from [GSAKMP] table 19 MUST be supported by a TEBAC. The identification type selects one among the multiple identifiers (e.g. one value from the SubjectAltName list) within the application endpoint's certificate. The GC/KS uses the selected identity in the application endpoint's group membership and group speaker role authorization pattern matching process. . Next layer protocol identifier, 1 octet. . Source port number, 2 octets in network-byte-order, Gross Expires January, 2004 page 77 GSAKMP Application to the IP Security Architecture July, 2004 . Destination port number, 2 octets in network-byte-order See section 3.3 for additional information about these components. The Node Identity is implicitly part of this TransportEndpointIdentifier data structure, and its value is found in the SubjectAltName of the certificate referenced by the Holder field. 9.6.8 Optional Attribute Types There are non-critical yet standard Attribute Types in [RFC3281]. This TEBAC profile does not specify how to apply the following Attribute Types to the GSAKMP IPsec context: . Service Authentication Information . Clearance . Charging Identity _ This attribute type MAY be used to assist AAA related charge back for GSAKMP group services. 10 Security Considerations To be defined in a future edition of this document. 11 IANA Considerations 11.1 GSAKMP IPsec Specific Allocations The GSAKMP IPsec application allocates the following new values beyond those defined by the [GSAKMP] core protocol specification: . GSAKMP exchange type for the Security Association Management message, IANA allocated from [GSAKMP] table 13. . GSAKMP payload next header type for the Identity to Transient Address Mapping payload, IANA allocated from [GSAKMP] table 12. . GSAKMP payload next header type for the Security Association Configuration payload, IANA allocated from [GSAKMP] table 12. . A UDP port number for GSAKMP payloads encapsulated by a UDP header followed by a NORM protocol header. Gross Expires January, 2004 page 78 GSAKMP Application to the IP Security Architecture July, 2004 11.2 SAM Message Nonce Types The GSAKMP Security Association Message contains two Nonce payloads, each having a new nonce type. GSAKMP IPsec requires that two code- points be allocated from the [GSAKMP] table 27 reserved to IANA range: Nonce Type Code Point Definition Nonce-Speaker TBD by IANA Section 7.2 Nonce-Membership TBD by IANA Section 7.2 11.3 GSAKMP IP Security Specific Notify Payload Error Codes The [GSAKMP] table 21 reserves the GSAKMP Notification Type range. This specification allocates the following Notification Types for GSAKMP IPsec related error conditions. An IP Security error condition can trigger sending a Notification payload as part of the registration protocol exchange, the de-registration exchange, or it can be used as a value recorded in a log file (e.g. an error logged during RKE policy token processing). GSAKMP IPsec implementations MUST be capable of generating the following error code points: Error GSAKMP/IPsec Error Description Section defining code the error trigger 34 SAC payload configuration error 7.5, 7.6 35 SPI range overlap detected 4.11, 7.2 35 Group Speaker Attribute Certificate 4.8, 7.2 not acceptable 36 Candidate group member not 4.8 authorized to be a speaker 37-66 Reserved for future allocation Gross Expires January, 2004 page 79 GSAKMP Application to the IP Security Architecture July, 2004 12 Acknowledgements The author wishes to acknowledge the contribution of Stephen Farrell, who reviewed and offered guidance for the attribute certificate related aspects of section 9. 13 Normative References GSAKMP Group Security Association Key Management Protocol (GSAKMP), H. Harney, U. Meth, A. Colegrove, G. Gross, draft-ietf-msec-gsakmp-sec-06.txt, June 2004, work in progress. RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, R. Housley, W. Polk, W. Ford, D. Solo, April 2002. RFC3281 An Internet Attribute Certificate Profile for Authorization, R. Housley, S. Farrell, April 2002. PKIXALGS IPSECPT The GSAKMP IP Security Policy Token Extension, G. Gross, work in progress, to be published. RFC2401bis Security Architecture for the Internet Protocol, S. Kent, K. Seo, April 2004, draft-ietf-ipsec- rfc2401bis-02.txt, work in progress. 14 Informative References RFC1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.(Status: BEST CURRENT PRACTICE) RFC2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Status: INFORMATIONAL) RFC3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. (Status: INFORMATIONAL) Gross Expires January, 2004 page 80 GSAKMP Application to the IP Security Architecture July, 2004 UDPESP UDP Encapsulation of IPsec Packets, A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg, February 16, 2004, draft-ietf-ipsec-udp-encaps- 08.txt, work in progress. IKE-V2 Internet Key Exchange (IKEv2) Protocol, C. Kaufman (Ed.), March 22, 2004, draft-ietf-ipsec-ikev2-13.txt, work in progress. IPSECNAT Negotiation of NAT-Traversal in the IKE, T. Kivinen, A. Huttunen, B. Swander, V. Volpe, 10 Feb 2004, draft-ietf-ipsec-nat-t-ike-08.txt, work in progress RFC2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. RFC3235 Network Address Translator (NAT)-Friendly Application Design Guidelines. D. Senie. January 2002. (Status: INFORMATIONAL) RFC3027 Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Status: INFORMATIONAL) RFC3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol. B. Haberman. September 2003. RFC3678 Socket Interface Extensions for Multicast Source Filters, D. Thaler, B. Fenner, B. Quinn, January 2004 (Status: INFORMATIONAL) RFC3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. RFC2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Status: INFORMATIONAL) RFC2709 Security Model with Tunnel-mode IPsec for NAT Domains,. P.Srisuresh. October 1999. (Status: INFORMATIONAL) Gross Expires January, 2004 page 81 GSAKMP Application to the IP Security Architecture July, 2004 15 Author Contact Information George M. Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833 908-268-1629 gmgross@identaware.com 16 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 17 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. Gross Expires January, 2004 page 82 GSAKMP Application to the IP Security Architecture July, 2004 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 18 Disclaimer Statement 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. 19 APPENDIX A To be supplied. Gross Expires January, 2004 page 83