Internet Engineering Task Force Mark Baugher(Cisco) INTERNET-DRAFT Thomas Hardjono (Verisign) Hugh Harney (Sparta) Brian Weis (Cisco) July 12, 2001 The Group Domain of Interpretation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The "GDOI" borrows definitions from GSAKMP, incorporates the Phase 1 SA of the Internet DOI, and proposes new payloads and exchanges according to the ISAKMP and IKE standards. The GDOI manages group security associations, which are used by security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. Comments on this document should be sent to msec@securemulticast.org. Baugher, Hardjono, Harney, Weis [PAGE 1] INTERNET DRAFT July 2001 Table of Contents 1.0 Introduction................................................4 2.0 Motivation for Using ISAKMP.................................5 2.1 Disadvantages of using ISAKMP.............................5 2.2 Advantages of using ISAMKP................................5 2.3 Overview of IKE...........................................6 2.4 Use of IKE Phase 1 as a Secure Channel....................7 2.4.1 IKE Phase 1 SA Payload................................7 3.0 GROUPKEY-PULL Exchange......................................7 3.1 ACL-based Versus Credential-based Authorization...........7 3.2 Messages..................................................8 3.2.1 ISAKMP Header Initialization.........................10 3.3 Use of Data Security Protocols for the Secure Channel....10 4.0 GROUPKEY-PUSH Message......................................10 4.1 Perfect Forward Secrecy (PFS)............................11 4.2 Forward and Backward Access Control......................11 4.3 Delegation of Key Management.............................11 4.4 ISAKMP Header Initialization.............................12 4.5 Deletion of SAs..........................................12 5.0 Payloads and Defined Values................................12 5.1 Identification Payload...................................13 5.1.1 ID_KEY_ID............................................13 5.2 Security Association Payload.............................13 5.2.1 Payloads following the SA payload....................14 5.3 SA KEK payload...........................................14 5.3.1 KEK Attributes.......................................15 5.3.2 KEK_MANAGEMENT_ALGORITHM.............................16 5.3.3 KEK_ALGORITHM........................................16 5.3.4 KEK_KEY_LENGTH.......................................16 5.3.5 KEK_KEY_LIFETIME.....................................17 5.3.6 SIG_HASH_ALGORITHM...................................17 5.3.7 SIG_ALGORITHM........................................17 5.3.8 SIG_KEY_LENGTH.......................................17 5.3.9 KE_OAKLEY_GROUP......................................17 5.4 SA TEK Payload...........................................17 5.4.1 PROTO_IPSEC_ESP......................................19 5.4.2 Other Security Protocols.............................20 5.5 Key Download Payload.....................................21 5.5.1 TEK Download Type....................................22 5.5.2 KEK Download Type....................................23 5.5.3 LKH..................................................24 5.5.4 OFT..................................................24 5.6 Sequence Number Payload..................................24 5.7 Proof of Possession......................................25 6.0 Application Scenarios......................................25 6.1 Data Broadcast...........................................26 6.2 Video-on-demand..........................................26 6.3 Summary..................................................27 7.0 Security Considerations....................................27 8.0 Acknowledgements...........................................27 9.0 References.................................................28 Baugher, Hardjono, Harney, Weis [PAGE 2] INTERNET DRAFT July 2001 Authors Address:...............................................30 Appendix A: Sample GDOI definitions for MESP and AMESP.........30 A.1 SA TEK bindings..........................................31 A.2 MESP/AMESP SA TEK Attributes.............................31 A.2.1 GS_ORDER.............................................31 A.2.2 GS_PROTOCOL..........................................32 A.2.3 GS_TRANSFORM.........................................32 A.2.4 GS_TRANSFORM_KEY_LENGTH..............................32 A.2.5 GS_TRANSFORM_KEY_LIFETYPE............................32 A.2.6 GA_ORDER.............................................32 A.2.7 GA_PROTOCOL..........................................32 A.2.8 GA_TRANSFORM.........................................32 A.2.9 SrA_ORDER............................................33 A.2.10 SrA_PROTOCOL........................................33 A.2.11 SrA_ALGORITHM.......................................33 A.3 TESLA SA TEK Attributes..................................33 A.3.1 SOURCE_ID............................................33 A.3.2 DIRECT_SYNCHRONIZATION...............................34 A.3.3 SENDERS_CERT_TYPE....................................34 A.3.4 SENDERS_CERT.........................................34 A.3.5 HMAC_TYPE............................................34 A.3.6 KEY_CHAIN_PRF........................................34 A.3.7 INTERVAL_TIME........................................34 A.3.9 INTERVAL_DURATION....................................35 A.3.10 KEY_DISCLOSURE_DELAY................................35 Appendix B: LKH Data Key Download Definitions..................35 B.1 LKH Key Data (KD) Payload definitions....................35 B.1.1 KEK_LKH..............................................36 Appendix C: Sample GDOI Definitions for SRTP...................37 C.1 SRTP Namespace: SA TEK Bindings..........................37 C.2 SRTP Namespace: SA TEK Attributes........................38 C.2.1 SSRC.................................................38 C.2.2 DESTINATION_ADDRESS..................................38 C.2.3 DESTINATION_RTP_PORT.................................38 C.2.4 DESTINATION_RTCP_PORT................................38 C.2.5 ROLLOVER_COUNTER.....................................38 C.2.6 CIPHER...............................................38 C.2.7 CIPHER_MODE..........................................39 C.2.8 CIPHER_KEY_LENGTH....................................39 C.2.9 SALT_KEY_LENGTH......................................39 C.2.10 AUTHENTICATION ALGORITHM............................39 C.2.11 WINDOW_SIZE.........................................39 C.2.12 SRTCP...............................................39 Baugher, Hardjono, Harney, Weis [PAGE 3] INTERNET DRAFT July 2001 1.0 Introduction This document presents an ISAMKP Domain of Interpretation (DOI) for group key management [GKMARCH]. The GDOI incorporates the Phase 1 SA of the Internet DOI [RFC2407, RFC2409], and proposes new payloads and exchanges according to the ISAKMP and IKE standards [p. 14 RFC2408, p. 7 RFC2409]. There are several new payloads: 1) GDOI SA 2) SA KEK (SAK) which follows the SA payload 3) SA TEK (SAT) which follows the SA payload 4) Key Download Array (KD, or Key Download in GSAKMP) 5) Sequence number (SEQ) 6) Proof of Possession (POP) There are two new exchanges. 1) A Phase 2 exchange creates Category-2 or Category-3 SAs. The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for group key management (an SA that includes a key encrypting key, or KEK, common to the group) or for security protocols [Section 2.1 RFC2407], which consist of an SA that includes a data encryption key, or TEK. The SA [Section 4.6.2 RFC2401] for the KEK or TEK includes authentication keys, encryption keys, cryptographic policy, and attributes specific to the data security protocol (see Appendices of this document). The GROUPKEY-PULL exchange uses "pull" behavior since the Member initiates the retrieval of these SAs from a group controller and key server ("GCKS"). The Member is aware of the Group through some out-of-band announcement scheme (such as Session Description Protocol) and initiates the pull. 2) A datagram creates or modifies Category-2 and Category-3 SAs. The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the Members. A KEK or KEK array protects the GROUPKEY-PUSH message, which creates new Category-2 or Category 3 SA. A Category-2 SA protects GROUPKEY- PUSH messages (i.e. it contains the group KEK). A Category-3 SA is a Data Security protocol SA û GDOI passes this information to the particular Data Security Protocol (IPsec, SRTP, AMESP). Multiple Category-3 SAs can be specified through the SAT. The GCKS or Delegate creates each Category-3 SA with a TEK (carried in KD) on behalf of a Security Protocol, which secures a new data session (e.g., IP multicast file transfer). A Security Protocol uses the TEK and owns the Category-3 SA in the same way that IPsec ESP uses the IKE Phase 2 keys and owns the Phase 2 SA. When the GROUPKEY-PUSH message carries a KEK array, it creates a new Category-2 SA. The GKCS or Delegate creates a new Category-2 SA with a KEK array in order to add or remove group members using a membership management protocol [RFC2627, GSAKMP, OFT]. Alternatively, membership may expire when the KEK expires Baugher, Hardjono, Harney, Weis [PAGE 4] INTERNET DRAFT July 2001 [MARKS] and the GROUPKEY-PUSH message is not used to create Category-2 SAs for the particular Group. Use of LKH-style membership management is an option in the GDOI. The GROUPKEY-PULL exchange resembles the GSAKMP Group Establishment procedure and gthe GROUPKEY-PUSH resembles GSAKMP Re-key [GSAKMP]. Unlike GSAKMP, GDOI uses IKE exchanges (the Phase 1 exchanges) and definitions. GDOI uses an IKE-compliant header in which "GDOI" is the declared domain of interpretation used in the IKE Phase 1 and subsequent GDOI Phase 2 (GROUPKEY-PULL) exchanges. Thus GDOI is a group security association management protocol: All GDOI messages are used to create, maintain, or delete security associations for a group. As described above, these security associations protect one or more key-encrypting keys, traffic- encrypting keys, or data shared by group members. 2.0 Motivation for Using ISAKMP The ISAKMP protocol is a key management framework for transferring key and authentication data independent of the key generation process [Section 1 RFC2408]. ISAKMP defines a set of protocol exchanges that set up a secure channel for key management, as well as the exchange of key and authentication data. Generalized payloads for exchanging key generation and authentication data are defined by ISAKMP. These payloads are combined with a Domain of Interpretation (DOI), which defines the specifics of key exchange protocol. ISAKMP is intended to support the negotiation of SAs for Security Protocols at all layers of the network stack, although in practice it is commonly used at the network layer. 2.1 Disadvantages of using ISAKMP A generalized protocol such as ISAMKP has a tendency towards complexity. This complicates security reviews of the protocol [FS00]. Protocol complexity may also lead to implementation errors. 2.2 Advantages of using ISAMKP The IKE protocol is a widely-deployed key exchange protocol that supports new DOIs [Section 4 RFC2409]. It is primarily used as a key exchange protocol for IPSEC, but can be used for other security protocols as well. IPSEC protocols are deployed in the majority of all internetworking devices as well as end-user host products. As IPSEC support has grown, support for the IKE protocol has proliferated as well. As a measure of IPsec deployment, 70 vendors participated in the IKE interoperability testing at the most recent VPN interoperability conference. Baugher, Hardjono, Harney, Weis [PAGE 5] INTERNET DRAFT July 2001 There are many advantages to making use of this existing support for ISAKMP as a key management framework and IKE for the secure channel that is our Category-1 SA of Figure 2: a. Re-using much of the existing key management protocol promotes a single key management framework. b. Systems that provide network-layer protection of unicast data will have the same market needs to provide network-layer protection for multicast data. c. Using the same underlying protocol will reduce both complexity and size of the key management code. d. Implementation can be achieved more expediently. 2.3 Overview of IKE IKE is logically divided into two exchanges, referred to as Phase 1 and Phase 2. A Phase 1 exchange must be completed before any Phase 2 exchanges are attempted. Once the Phase 1 exchange has completed, there is no limit to the number of Phase 2 exchanges that can take place, and there may be simultaneous Phase 2 exchanges occurring between IKE peers. In Phase 1, two peers establish a bi-directional secure authenticated channel using payloads and semantics defined in ISAKMP. Several different authentication methods are defined for use in IKE, i.e. manually shared keys, digital signatures, or public key encryption. The two peers negotiate a mutually-acceptable set of cryptographic policies, and derive keying material using the Diffie-Hellman or public key encryption algorithms. At the end of Phase 1, the two peers have fully authenticated each other and have exchanged adequate keying material used to create a secure authenticated channel for Phase 1 and Phase 2. In Phase 2, the two peers negotiate Security Associations on behalf of IPSEC (or other security protocols if another DOI has been defined). IKE Phase 1 provides the following protections for any defined Phase 2 protocol: a. Confidentiality. All messages are protected using an encryption protocol negotiated during Phase 1. b. Integrity. Each message contains a per-message authentication obtained with the use of an HMAC protocol which signs hashes taken over the Phase 2 payloads and other relevant data. c. Replay protection. If the Phase 2 protocol uses nonces, they can be included in the hashed data for Phase 2 messages. Baugher, Hardjono, Harney, Weis [PAGE 6] INTERNET DRAFT July 2001 d. Generation of key exchange protocol keying material. If the key exchange protocol requires keying material to be generated, it can be generated using the keying material exchanged during Phase 1. 2.4 Use of IKE Phase 1 as a Secure Channel The secure channel defined by an IKE Phase 1 protects GDOI keying material. It can directly provide confidentiality and integrity. IKE exchanges protect against man-in-the middle, connection hijacking, reflection and replay attacks. IKE offers some protection against denial-of-service attacks as well. GDOI uses the IKE Phase 1 to protect a new Phase 2 exchange called "GROUPKEY-PULL", which is defined below. 2.4.1 IKE Phase 1 SA Payload The IKE Phase 1 SA payload has a DOI value. That value should be the GDOI DOI value as defined later in this document. 3.0 GROUPKEY-PULL Exchange The goal of the GROUPKEY-PULL exchange is to establish a Category-2 and/or Category-3 SAs at the Member for a particular Group. An IKE Phase 1 SA protects the GROUPKEY-PULL; there may be multiple GROUPKEY- PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange downloads the Group key encrypting key (KEK) or KEK array under the protection of the Category 1 (IKE Phase 1) SA. 3.1 ACL-based Versus Credential-based Authorization The GROUPKEY-PULL exchange supports two authorization models. If the GCKS authorizes access to the Group KEK using a mechanism such as an access control List (ACL), then a single Member identity may suffice and the GROUPKEY-PULL exchange will not include additional credential (CERT) and authentication data. If the GCKS uses a more sophisticated credential-based authorization mechanism, then the Member may have a separate identity for each Group and the GROUPKEY-PULL exchange does this securely [STS]. In ACL-based authorization, the GCKS keeps a list of members for every Group, and the identity of the Member is contained in the Phase 1 IKE ID payload. The GCKS forwards the ID payloads from the Member to the authorization application program (see Figure 3) to check the ACL before downloading the KD payload (section 5.5) to the Member. There are no cryptographic data passed in the GROUPKEY-PULL exchange for ACL-based Authorization beyond SA and KD payloads, and nonces for replay protection (see section 5.2). Credential-based authorization uses public-key cryptography, which is probably the most scalable authentication technology for key Baugher, Hardjono, Harney, Weis [PAGE 7] INTERNET DRAFT July 2001 management [SKEME]. In the credential-based authorization model, a much smaller list of signing authorities will be kept by the GCKS authorization application. The Member can use up to one CERT payload for each KEK or KEK array it requests (through a Phase 2 ID payload). The GCKS authenticates this identity as part of the GROUPKEY-PULL exchange. 3.2 Messages The GROUPKEY-PULL is an IKE Phase 2 exchange. IKE Phase 1 computes SKEYID_a from the DH keying material exchanged in Phase 1. SKEYID_a is the "key" in the keyed hash used in the GROUPKEY-PULL HASH payloads. As with the IKE HASH payload generation [RFC 2409 section 5.5], each GROUPKEY-PULL message hashes a uniquely-defined set of values. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract. The GROUPKEY-PULL uses nonces to guarantee "liveliness", or that someone is not replaying a recent GROUPKEY-PULL message. The replay attack is only useful in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous IKE Phase 1, the HASH calculation will fail due to a wrong SKEYID_a. The message will fail processing before the nonce is ever evaluated. In order for either peer to get the benefit of the replay protection it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the Responder must not compute the shared Diffie-Hellman number (if KE payloads were included) or install the new SAs until it receives a message with Nr included properly in the HASH payload. Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness. The GROUPKEY-PULL Member-Initiator expects to find its nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL GKCS Responder expects to see its nonce, Nr, in the HASH of a returned message before providing Group-keying material as in the following exchange. Initiator (Member) Responder (GCKS) ------------------ ---------------- HDR*, HASH(1), Ni, ID --> <-- HDR*, HASH(2), Nr, SA HDR*, HASH(3) --> [,CERT] [,POP_I] <-- HDR*, HASH(4), SEQ, KD [,CERT] [,POP_R] Baugher, Hardjono, Harney, Weis [PAGE 8] INTERNET DRAFT July 2001 Hashes are computed as follows: HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | POP_I ]) HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b | SEQ | KD [ | POP_R]) POP payload is constructed from prf(Ni | Nr) * Protected by IKE Phase 1 SA, encryption occurs after HDR HDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are included in the first two exchanges, with the GCKS returning only the SA policy payload before liveliness is proven. The HASH payloads [RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message id, M-ID. Once liveliness is established, the last message completes the real processing of downloading the KD payload. In addition to the Nonce and HASH payloads, the Member Initiator identifies the Group it wishes to join through the ISAKMP ID payload. The GCKS Responder informs the Member of the current value of the sequence number in the SEQ payload; the sequence number orders the GROUPKEY-PUSH datagrams (section 4); the member MUST check to see that the sequence number is greater than in the previous SEQ payload the member holds for the group (if it holds any) before installing any KEK SA. The GCKS Responder informs the Member of the cryptographic policies of the Group in the SA payload, which describes the DOI, KEK and/or TEK keying material, and authentication transforms. The SPIs are also determined by the GCKS and downloaded in the SA payload chain (see section 5.2). The KEK SA contains the ISAKMP cookie pair for the Category-2 SA, which is not negotiated but downloaded. The TEK SA contains an SPI as defined in section 5.3 of this document. The second message downloads this SA payload. If a Category-2 SA is defined in the SA payload, then KD will contain the KEK; if one or more Category-3 SAs are defined in the SA payload, KD will contain the TEKs. This is useful if there is an initial set of TEKs for the particular Group and can obviate the need for future TEK GROUPKEY-PUSH messages (described in section 4). As described above, the Member may establish an identity in the GROUPKEY-PULL exchange in an optional CERT payload that is separate from the Phase 1 identity. When the Member Responder passes a new CERT, a proof of possession (POP) payload accompanies it. The POP payload demonstrates that the Member or GCKS principal has used the very secret that authenticates that principal (i.e., the principal's private key that corresponds to the public key used in the CERT payload). POP_I is an ISAKMP SIG payload containing a hash of the concatenated nonces Ni and Nr signed by the Member, when the Member passes a CERT, signed by the Group Owner to prove its authorization. POP_R contains the hash of the concatenated nonces Ni and Nr signed by the GCKS, when the GCKS passes a CERT, signed by the Group owner, to Baugher, Hardjono, Harney, Weis [PAGE 9] INTERNET DRAFT July 2001 prove its authority to provide keys for a particular Group. The use of the nonce pair for the POP payload, transformed through the IKE prf, is designed to withstand compromise of the Category 1 (IKE Phase 1) key. 3.2.1 ISAKMP Header Initialization Cookies are used in the ISAKMP header as a weak form of denial of service protection. The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP and IKE [RFC2527, RFC2408, RFC2409]. Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1]. The Exchange Type has value 240 for the GDOI GROUPKEY-PULL exchange. Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section 3.1] 3.3 Use of Data Security Protocols for the Secure Channel The IKE Phase 1 is used as a Secure Channel for the "registration" of a Member to a Group whereby the Member authenticates itself to the GCKS and receives keying material. In principle, a variety of means might be used to protect the registration and pulling of keys such as IPSEC ESP or SSL. There are advantages to that approach, moreover, in simplicity of implementation and robustness of operation. Web servers, for example, support SSL, which might serve as a convenient means of securely downloading keys from the GCKS to the Member. There is no requirement that GROUPKEY-PULL be the means by which the GDOI SAD is initialized. It is possible that GDOI GROUPKEY-PUSH datagrams (described below) use keying material obtained by means other than a GROUPKEY-PULL. The GDOI, however, does not define these other means since it is intended to be an extension to IKE for group key management. Although the GDOI could specify a mode of operation for GROUPKEY-PULL other than over an IKE Phase 1 SA, this is not done in the interests of simplicity of the specification. 4.0 GROUPKEY-PUSH Message Following the model described in [HBH00], GDOI sends control information securely using group communications, i.e. using IP multicast distribution of a GROUPKEY-PUSH message (which can also be "pushed" using unicast delivery). The GROUPKEY-PUSH message replaces a Category-2 SA KEK or KEK array, and/or creates a new Category-3 SA (see section 1.3). Baugher, Hardjono, Harney, Weis [PAGE 10] INTERNET DRAFT July 2001 Member GCKS or Delegate ------ ---------------- <---- HDR*, SEQ, SA, KD, [CERT,] SIG * Protected by the Category-2 SA KEK; encryption occurs after HDR HDR is defined below. The SEQ payload is defined in the Payloads section. The SA defines the policy (e.g. crypto suite) and attributes (e.g. SPI) for a Category-2 and/or Category-3 SAs. The GCKS or Delegate optionally provides a CERT payload for verification of the SIG, which is a signature of a hash of the entire message before encryption (including the header and excluding the SIG payload itself). KD is the key download payload as described in the Payloads section. If the SA defines an LKH-style KEK array or single KEK, KD contains a KEK or KEK array for a new Category-2 SA, which has a new cookie pair. When the KD payload carries a new KEK SA (section 5.3), a Category-2 SA is replaced with a new SA having the same Group identifier (ID specified in message 1 of section 3.1) and incrementing the same sequence counter, which is initialized in message 4 of section 3.1. If the SA defines an SA TEK payload, this informs the member that a new Category-3 SA has been created, with keying material carried in KD (Section 5.5). 4.1 Perfect Forward Secrecy (PFS) The GROUPKEY-PUSH message is protected by the Group KEK though in all cases, the GROUPKEY-PUSH message carries new key downloads, among other information. A freshly generated secret must protect the key download for the GROUPKEY-PUSH message to have PFS. This issue is for further study. 4.2 Forward and Backward Access Control Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH and OFT that have the property of denying access to a new group key by a member removed from the group (forward access control) and to an old group key by a member added to the group (backward access control). An unrelated notion to PFS, "forward access control" and "backward access control" have been called "perfect forward security" and "perfect backward security" in the literature [RFC2627, GSAKMP, CP00, OFT]. 4.3 Delegation of Key Management GDOI supports delegation of GROUPKEY-PUSH datagrams through the delegation capabilities of the PKI. However, GDOI does not explicitly specify how the GCKS identifies delegates, but leaves this to the PKI that is used by a particular GDOI implementation. Baugher, Hardjono, Harney, Weis [PAGE 11] INTERNET DRAFT July 2001 4.4 ISAKMP Header Initialization Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Category-2 SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI. Use of the cookie as an anti-clogging token [RFC2522, RFC2408] is for further study. Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1]. The Exchange Type has value 241 for the GDOI GROUPKEY-PUSH message. Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section 3.1] 4.5 Deletion of SAs There are times the GCKS may want to signal to receivers to delete SAs, for example at the end of a broadcast. Deletion of keys may be accomplished by sending an ISAKMP Delete payload as part of a GDOI GROUPKEY-PUSH message. 5.0 Payloads and Defined Values This document specifies use of several ISAKMP payloads, which are defined in accordance with RFC2408. The following payloads are extended. Next Payload Type Value ----------------- ----- Security Association (SA) 1 Identification (ID) 5 Several new payload formats are required in the group security exchanges. The Payload types for the new headers are defined in the ISAKMP "Private USE" range pending the receipt of an assigned number from the Internet Assigned Names Authority (IANA). Next Payload Type Value ----------------- ----- SA KEK Payload (SAK) 130 SA TEK Payload (SAT) 131 Key Download (KD) 132 Sequence Number (SEQ) 133 Proof of Possession (POP) 134 Baugher, Hardjono, Harney, Weis [PAGE 12] INTERNET DRAFT July 2001 5.1 Identification Payload The Identification Payload is used to identify a group identity that will later be associated with Security Associations for the group. A group identity may map to a specific IP multicast group, or may specify a more general identifier, such as one that represents a set of related multicast streams. The GDOI uses the Identification Payload defined in [RFC2407]. The following fields in the header MUST be zero (0): Protocol ID, and Port. 5.1.1 ID_KEY_ID In the context of the GDOI, ID_KEY_ID specifies a four (4)-octet group identifier. 5.2 Security Association Payload The Security Association payload is defined in RFC 2408. For GDOI, it is used by the GCKS to assert security attributes for both Category-2 and Category-3 SAs. In the GDOI, this payload may also be called a GSA Payload. 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 ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DOI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SA Attribute Next Payload ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The Security Association Payload fields are defined as follows: o Next Payload (1 octet) - Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The next payload MUST NOT be a SAK Payload or SAT Payload type, but the next non-Security Association type payload. o RESERVED (1 octet) - Must be zero. o Payload Length (2 octets) is the octet length of the current payload including the generic header and all TEK and KEK payloads. o DOI (4 octets) - Is the GDOI, which is value 196 pending assignment by the IANA. Baugher, Hardjono, Harney, Weis [PAGE 13] INTERNET DRAFT July 2001 o Situation (4 octets) - Must be zero. o SA Attribute Next Payload (1 octet) - Must be either a SAK Payload or a SAT Payload. See section 5.3.2 for a description of which circumstances are required for each payload type to be present. o RESERVED (2 octets) - Must be zero. 5.2.1 Payloads following the SA payload Payloads that define specific security association attributes for the KEK and/or TEKs used by the group MUST follow the SA payload. How many of each payload is dependant upon the group policy. There may be zero or one SAK Payloads, and zero or more SAT Payloads, where either one SAK or SAT payload MUST be present. This latitude allows for various group policies to be accommodated. For example if the group policy does not require the use of a Category-2 SA, the GCKS would not need to send a KEK SA payload to the group member since all SA updates would be performed using the Category-1 SA. Alternatively, group policy might use a Category-2 SA but choose to download a KEK to the group member only as part of the Category-1 SA. Therefore, the KEK policy (in the SA KEK payload) would not be necessary as part of the Category-2 SA message SA payload. Specifying multiple SATs allows multiple sessions to be part of the same group and multiple streams to be associated with a session (e.g., video, audio, and text) but each with individual security association policy. 5.3 SA KEK payload The SA KEK (SAK) payload contains security attributes for the KEK method for a Group and parameters specific to the GROUPKEY-PULL operation. 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 ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ~ SPI ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! POP Algorithm ! POP Key Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ KEK Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Baugher, Hardjono, Harney, Weis [PAGE 14] INTERNET DRAFT July 2001 The SAK Payload fields are defined as follows: o Next Payload (1 octet) - Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are a SAT Payload or zero to indicate there is no SA TEK payload. o RESERVED (1 octet) - Must be zero. o Payload Length (2 octets) - Length of this payload, including the KEK attributes. o SPI (16 octets) - Security Parameter Index for the KEK. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the "Responder Cookie" in the same HDR. As described above, these cookies are assigned by the GCKS. o POP Algorithm (2 octets) - The POP payload algorithm. Defined values are specified in the following table. If no POP algorithm is defined by the KEK policy this field must be zero. Algorithm Type Value -------------- ----- RESERVED 0 POP_ALG_RSA 1 POP_ALG_DSS 2 POP_ALG_ECDSS 3 RESERVED 4-127 Private Use 128-255 o POP Key Length (2 octets) - Length of the POP payload key. If no POP algorithm is defined in the KEK policy this field must be zero. o KEK Attributes - Contains KEK policy attributes associated with the group. The following sections describe the possible attributes. Any or all attributes may be optional, depending on the group policy. 5.3.1 KEK Attributes The following attributes may be present in a SAK Payload. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V). Baugher, Hardjono, Harney, Weis [PAGE 15] INTERNET DRAFT July 2001 ID Class Value Type -------- ----- ---- RESERVED 0 KEK_MANAGEMENT_ALGORITHM 1 B KEK_ALGORITHM 2 B KEK_KEY_LENGTH 3 B KEK_KEY_LIFETIME 4 V SIG_HASH_ALGORITHM 5 B SIG_ALGORITHM 6 B SIG_KEY_LENGTH 7 B KE_OAKLEY_GROUP 10 B The following attributes may only be included in a GROUPKEY-PULL message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP. 5.3.2 KEK_MANAGEMENT_ALGORITHM The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management algorithm used to provide forward or backward access control (i.e., used to exclude group members). Defined values are specified in the following table. KEK Management Type Value ------------------- ----- RESERVED 0 LKH 1 OFT 2 RESERVED 3-127 Private Use 128-255 5.3.3 KEK_ALGORITHM The KEK_ALGORITHM class specifies the encryption algorithm using with the KEK. Defined values are specified in the following table. Algorithm Type Value -------------- ----- RESERVED 0 KEK_ALG_DES 1 KEK_ALG_3DES 2 KEK_ALG_TWOFISH 3 KEK_ALG_AES 4 RESERVED 5-127 Private Use 128-255 5.3.4 KEK_KEY_LENGTH The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits). Baugher, Hardjono, Harney, Weis [PAGE 16] INTERNET DRAFT July 2001 5.3.5 KEK_KEY_LIFETIME The KEK_KEY_LIFETIME class specifies the maximum time for which the KEK is valid. The GCKS may refresh the KEK at any time before the end of the valid period. The value is a four (4) octet number defining a valid time period in seconds. 5.3.6 SIG_HASH_ALGORITHM SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The following tables define the algorithms for SIG_HASH_ALGORITHM. Algorithm Type Value -------------- ----- RESERVED 0 SIG_HASH_MD5 1 SIG_HASH_SHA1 2 RESERVED 3-127 PRIVATE USE 128-255 SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1. 5.3.7 SIG_ALGORITHM The SIG_ALGORITHM class specifies the SIG payload signature algorithm. Defined values are specified in the following table. Algorithm Type Value -------------- ----- RESERVED 0 SIG_ALG_RSA 1 SIG_ALG_DSS 2 SIG_ALG_ECDSS 3 RESERVED 4-127 Private Use 128-255 5.3.8 SIG_KEY_LENGTH The SIG_KEY_LENGTH class specifies the length of the SIG payload key. 5.3.9 KE_OAKLEY_GROUP The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL exchange. This attribute uses the Internet DOI definitions [RFC2407]. 5.4 SA TEK Payload The SA TEK (SAT) payload contains security attributes for a single TEK SA associated with a group. Baugher, Hardjono, Harney, Weis [PAGE 17] INTERNET DRAFT July 2001 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 ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol-ID ! TEK Protocol-Specific Payload ~ +-+-+-+-+-+-+-+-+ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The SAT Payload fields are defined as follows: o Next Payload (1 octet) - Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are another SAT Payload or zero to indicate there are no more security association attributes. o RESERVED (1 octet) - Must be zero. o Payload Length (2 octets) - Length of this payload, including the TEK Protocol-Specific Payload. o Protocol-ID (1 octet) - Value specifying the Security Protocol. The following table defines values for the Security Protocol Protocol ID Value ----------- ----- RESERVED 0 GDOI_PROTO_IPSEC_ESP 1 GDOI_PROTO_MESP 2 GOI_PROTO_AMESP 3 GDOI_PROTO_SRTP 4 RESERVED 5-127 PRIVATE USE 128-255 o TEK Protocol-Specific Payload (variable) - Payload which describes the attributes specific for the Protocol-ID. Baugher, Hardjono, Harney, Weis [PAGE 18] INTERNET DRAFT July 2001 5.4.1 PROTO_IPSEC_ESP The TEK Protocol-Specific payload for ESP is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SRC ID Type ! SRC ID Prot ! SRC ID Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !SRC ID Data Len! SRC Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST ID Type ! DST ID Prot ! DST ID Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !DST ID Data Len! DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Transform ID ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! RFC 2407 SA Attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The SAT Payload fields are defined as follows: o SRC ID Type (1 octet) - Value describing the identity information found in the SRC Identification Data field. Defined values are specified in RFC2407 Section 4.6.2.1. Set to zero for multiple- source multicast groups that use a common TEK for all senders. o SRC ID Prot (1 octet) - Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the SRC Id Prot field should be ignored. Set to zero for multiple-source multicast groups that use a common TEK for all senders. o SRC ID Port (2 octets) - Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field should be ignored. Set to zero for multiple-source multicast groups that use a common TEK for all senders. o SRC ID Data Len (1 octet) - Value specifying the length of the SRC Identification Data field. Set to zero for multiple-source multicast groups that use a common TEK for all senders. o SRC Identification Data (variable length) - Value, as indicated by the SRC ID Type. Set to three bytes of zero for multiple-source multicast groups that use a common TEK for all senders. o DST ID Type (1 octet) - Value describing the identity information found in the DST Identification Data field. Defined values are specified in RFC2407 Section 4.6.2.1 Baugher, Hardjono, Harney, Weis [PAGE 19] INTERNET DRAFT July 2001 o DST ID Prot (1 octet) - Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the DST Id Prot field should be ignored. o DST ID Port (2 octets) - Value specifying a port associated with the source Id. A value of zero means that the DST ID Port field should be ignored. o DST ID Data Len (1 octet) - Value specifying the length of the DST Identification Data field. o DST Identification Data (variable length) - Value, as indicated by the DST ID Type. o Transform ID (1 octet) - Value specifying which ESP transform is to be used. The list of valid values are defined in the IPSEC DOI [RFC2407,section 4.4.4]. o RESERVED (3 octets) - Must be zero. o SPI (4 octets) - Security Parameter Index for ESP. o RFC 2407 Attributes - ESP Attributes from RFC 2407 Section 4.5. The GDOI supports all IPSEC DOI SA Attributes for PROTO_IPSEC_ESP excluding the Group Description [RFC2407, section 4.5], which MUST NOT be sent by a GDOI implementation and is ignored by a GDOI implementation if received. All mandatory IPSEC DOI attributes are mandatory in GDOI PROTO_IPSEC_ESP. The Authentication Algorithm attribute of the IPSEC DOI is group authentication [AMESP] in GDOI. 5.4.2 Other Security Protocols Besides ESP, GDOI should serve to establish SAs for secure groups needed by other Security Protocols that operate at the transport, application, and internetwork layers. These other Security Protocols, however, are in the process of being developed or do not yet exist. MESP and AMESP are two related secure multicast protocols being developed under the auspices of the IRTF Secure Multicast Group [AMESP]. These Security Protocols must be defined in the context of the GDOI. The following information needs to be provided for a Security Protocol to the GDOI. o The Protocol-ID for the particular Security Protocol o The SPI Size o The method of SPI generation o The transforms, attributes and keys needed by the Security Protocol All Security Protocols must provide the information in the bulleted Baugher, Hardjono, Harney, Weis [PAGE 20] INTERNET DRAFT July 2001 list above to guide the GDOI implementation for that protocol. As the GDOI progresses on an IETF standards track, other Security Protocols operating within its framework will be specified in separate standards track documents. To exemplify the structure and content of GDOI security-protocol specifications, Appendix A contains a specification for the SMuG Security Protocols, MESP and AMESP (see Appendix A). 5.5 Key Download Payload The Key Download Payload contains group keys for the Group specified in the SA Payload. These key download payloads can have several security attributes applied to them based upon the security policy of the group as defined by the associated SA Payload. When included as part of the Category-2 SA with an optional KE payload, The Key Download Payload will be xor'ed with the new Diffie- Hellman shared secret. The xor operation will begin at the "Number of Key Packets" field. If the "Number of Key Packets" is zero, the group member is expected to delete all keys associated with the ID. This type of KD payload will only be sent by the GCKS when a group is deleted. 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 ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Number of Key Packets ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packets ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The Key Download Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Number of Key Packets (2 octets) -- Contains the total number of both TEK and Rekey arrays being passed in this data block. o Key Packets Several types of key packets are defined. Each Key Packet has Baugher, Hardjono, Harney, Weis [PAGE 21] INTERNET DRAFT July 2001 the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! KD Type ! RESERVED ! KD Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI Size ! SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packet Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! o Key Download (KD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet. Key Download Type Value ----------------- ----- RESERVED 0 TEK 1 KEK 2 LKH 3 OFT 4 RESERVED 5-127 Private Use 128-255 "KEK" is a single key whereas LKH and OFT are arrays of key- encrypting keys. The definition for LKH is given in the appendix. o RESERVED (1 octet) - Unused, set to zero. o Key Download Length (2 octets) -- Length in octets of the Key Packet data following this field. o SPI Size (1 octet) - Value specifying the length in octets of the SPI as defined by the Protocol-Id. o SPI (variable length) - Security Parameter Index which matches a SPI previously sent in an SAK or SAT Payload. o Key Packet Attributes (variable length) -- Contains Key information. The format of this field is specific to the value of the KD Type field. The following sections describe the format of each KD Type. 5.5.1 TEK Download Type The following attributes may be present in a SAT Payload. Exactly one attribute matching each type sent in the SAT payload MUST be present. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes which are defined as TV are marked as Basic (B); attributes which are defined as TLV are marked as Baugher, Hardjono, Harney, Weis [PAGE 22] INTERNET DRAFT July 2001 Variable (V). TEK Class Value Type --------- ----- ---- RESERVED 0 TEK_ALGORITHM_KEY 1 V TEK_INTEGRITY_KEY 2 V TEK_SOURCE_AUTH_KEY 3 V If no TEK key packets are included in a Category-1 KD payload, the group member can expect to receive the TEK as part of a Category-2 SA. At least one TEK must be included in each Category-2 KD payload. Multiple TEKs may be included if multiple streams associated with the SA are to be rekeyed. 5.5.1.1 TEK_ALGORITHM_KEY The TEK_ALGORITHM_KEY class declares that the encryption key for this SPI is contained as the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAT payload. DES keys will consist of 64 bits (the 56 key bits with parity bit). Triple DES keys will be be specified as 64 bits (including parity bits) in the order that they are to be used for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). 5.5.1.2 TEK_INTEGRITY_KEY The TEK_INTEGRITY_KEY class declares that the integrity key for this SPI is contained as the Key Packet Attribute. The integrity algorithm that will use this key was specified in the SAT payload. Thus GDOI assumes that both the symmetric encryption and integrity keys are pushed to the Member. SHA keys will consist of 160 bits, and MD5 keys will consist of 128 bits. 5.5.1.3 TEK_SOURCE_AUTH_KEY The TEK_SOURCE_AUTH_KEY class declares that the source authentication key for this SPI is contained in the Key Packet Attribute. The source authentication algorithm that will use this key was specified in the SAT payload. 5.5.2 KEK Download Type The following attributes may be present in a SAK Payload. Exactly one attribute matching each type sent in the SAK payload MUST be present. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes which are defined as TV are marked as Basic (B); attributes which are defined as TLV are marked as Variable (V). Baugher, Hardjono, Harney, Weis [PAGE 23] INTERNET DRAFT July 2001 KEK Class Value Type --------- ----- ---- RESERVED 0 KEK_ALGORITHM_KEY 1 V SIG_ALGORITHM_KEY 2 V If the KEK key packet is included, there must be only one present in the KD payload. 5.5.2.1 KEK_ALGORITHM_KEY The KEK_ALGORITHM_KEY class declares the encryption key for this SPI is contained in the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAK payload. 5.5.2.2 SIG_ALGORITHM_KEY The SIG_ALGORITHM_KEY class declares that the public key for this SPI is contained in the Key Packet Attribute, which may be useful when no public key infrastructure is available. The signature algorithm that will use this key was specified in the SAK payload. 5.5.3 LKH The LKH key packet is comprised of attributes representing different leaves in the LKH key tree. The format of those attributes are described in Appendix B. 5.5.4 OFT The OFT key packet is comprised of attributes representing different leaves in the OFT key tree. The format of those attributes are TBD. 5.6 Sequence Number Payload The Sequence Number Payload (SEQ) provides an anti-replay protection for GROUPKEY-PUSH messages. Its use is similar to the Sequence Number field defined in the IPsec ESP protocol [RFC2406]. 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 ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sequence Number Payload fields are defined as follows: Baugher, Hardjono, Harney, Weis [PAGE 24] INTERNET DRAFT July 2001 o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Sequence Number (4 octets) - This field contains a monotonically increasing counter value for the group. It is initialized to zero by the GCKS, and incremented in each subsequently-transmitted message. Thus the first packet sent for a given Cat-2 SA will have a Sequence Number of 1. The GDOI implementation keeps a sequence counter as an attribute for Cat-2 SA and increments the counter upon receipt of a GROUPKEY-PUSH message. The current value of the sequence number must be transmitted to group members as a part of the Cat-1 SA SA payload. A group member must keep a sliding receive window. The window must be treated as in the ESP protocol [RFC2406] Section 3.4.3. 5.7 Proof of Possession The Proof of Possession Payload is used as part of group membership authorization during a GDOI exchange. The Proof of Possession Payload is identical to an ISAKMP SIG payload. However, the usage is entirely different as the GCKS, GCKS delegate or Member signs a prf (i.e., RFC 2409 keyed MAC) of the concatenated nonces, Ni and Nr. 6.0 Application Scenarios This section considers two uses of GDOI for data broadcast and video- on-demand applications. In these applications, a "content provider" may be a studio, such as one of the seven major U.S. movie studios, or a regional, national or international broadcast station. There is also a "distributor," who provides delivery to homes and business. A "distributor" may be a cable, telco, terrestrial broadcast network or direct-to-home satellite operator. There are more than a dozen major network distributors in the U.S. that serve digital data to homes and businesses. These distributors increasingly provide data services such a multimedia stream and file delivery broadcasted to groups of subscribers (e.g., using single source IP multicast) or delivered on demand to a single subscriber. A typical data broadcast may be a multicast file transfer or a stream of a live sports event that is sent as part of a subscription or a pay-per-view session. A typical video-on-demand application may be a movie that is streamed or downloaded to an authenticated customer who belongs to a subscription group, for example. The customer authentication may use a smart card, pass phrases, network authentication, tamper-resistant software, and other means. These means are beyond the scope of this document though the ID and GID Baugher, Hardjono, Harney, Weis [PAGE 25] INTERNET DRAFT July 2001 payload fields convey the needed authorization information in the GDOI Phase 1 and GROUPKEY-PULL exchanges. Each application scenario is discussed in a separate section below. 6.1 Data Broadcast In this scenario, a wide-area broadcaster is sending a multicast data feed. This feed is from a live sporting event that is streamed from the event location. This broadcaster is also the content provider who sends the feed, which is received by authorized customers of metropolitan-area network distributors. The network distributor also has a GCKS that acts on its behalf and has distributed KEKs to the Group of customers who are authorized to receive the sporting-event feed. Our network distributor delivers the broadcast data encrypted by the TEK, which is sent via IP Multicast in a GROUPKEY-PUSH message. The customers who have the KEK or KEK array for the network- distributor's Group will be able to decrypt the GROUPKEY-PUSH messages that contain the TEK for the sporting event. In this way, the network distributor controls access to the TEK by its customers independently of the broadcaster, who encrypts each stream once for re-distribution through any number of network distributors. At the end of the data broadcast, each network distributor will have its GCKS instruct Group members to destroy the Category-3 SA and its TEK. This is done through a GROUPKEY-PUSH message. 6.2 Video-on-demand In this scenario, a movie studio has mastered a movie file, and sends it to network distributors who offer video-on-demand (VOD) service to their customers. The content provider may choose to encrypt the file or not. In this scenario, the network distributor has a GCKS that acts on its behalf and has distributed KEKs to the Group of customers who are authorized to download VOD movie files or view VOD streams. There are many applications where the encryption needs to be unique to the receiving device of the Group Member. So the network distributor encrypts the file (after first decrypting it if it were previously encrypted by the content provider). Thus the movie file is encrypted at the point of distribution in QuickTime format, for example, in a manner such that it can be decrypted and played by a QuickTime player. Such a player fulfills the role of "Security Protocol" in Figure 3. In contrast to the previous example, both the TEK and the KEK are under the control of the network distributor owing to the need of unique encryption of the VOD feed. The previous scenario, however, allowed the GCKS to control the TEK and the network distributor to control of the KEK. In some VOD applications, it may make sense for the content provider to control the KEK and the network distributor to control the TEK if the content provider owns the customer relationship and the TEK is always distributed encrypted in the KEK. The use of the KEK group secret eliminates the need for point-to-point Baugher, Hardjono, Harney, Weis [PAGE 26] INTERNET DRAFT July 2001 key establishment procedures for a 1:1 VOD session. 6.3 Summary GDOI securely establishes keys for unicast and multicast data. As further illustrated in the two scenaria, GDOI is suitable to manage keys for on-demand unicast and multicast streams as well as file download. Besides supporting 1:N and 1:1 groups, GDOI should be effective in securing M:N applications, such as teleconferencing, using LKH-style membership management [RFC2627]. Use of LKH-style membership management is specified in the appendix. 7.0 Security Considerations GDOI is a security association (SA) protocol for groups of senders and receivers. This protocol must use best-known practices for defense against man-in-middle, connection hijacking, replay, reflection, and denial-of-service (DOS) attacks. Further work is needed to establish whether this draft version of GDOI uses best-known practices for key management. GDOI may inherit the problems of its ancestors, ISAKMP [RFC2408] and Internet Key Exchange [RFC2409]. Some problems remain to be addressed in ISAKMP and IKE [FS00]. GDOI should benefit, however, from improvements to its ancestor protocols just as it benefits from years of experience and work embodied in those protocols. Further work is needed to establish whether GDOI uses ISKAMP and IKE in a good way. Of course, GDOI supports secure groups and differs from ISAKMP and IKE in authorization, policy, SA structure, and exchanges. The SA structure is more complex than ISAKMP and IKE. Complexity is bad for a Security Protocol because it makes correctness analysis more difficult than in a simpler protocol and may lead to implementation problems. The distribution of keying material using multicast techniques, moreover, is novel. Novelty is bad for a key management protocol because it can contain unexpected results and problems. Further work is needed to determine that this version of GDOI successfully employs novel techniques such as multicast key distribution without compromising Group security (as defined by Group policy). 8.0 Acknowledgements The authors thank Ran Canetti, Cathy Meadows and Andrea Colegrove. Ran has advised the authors on secure group cryptography, which has led to changes in the exchanges and payload definitions. Cathy identified several problems in a previous version of this draft, including a replay attack against the proof of possession exchange. Andrea has contributed to the group policy section of this draft. Baugher, Hardjono, Harney, Weis [PAGE 27] INTERNET DRAFT July 2001 9.0 References [CP00] R. Canetti, B. Pinkas, A taxonomy of multicast security issues, http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-01.txt, Work in Progress, August 2000. [FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of IPsec, CounterPane, http://www.counterpane.com/ipsec.html. [GKMARCH] M.Baugher, R.Canetti, L.Dondeti, Group Key Management Architecture, http://search.ietf.org/internet-drafts/draft-ietf-msec- gkmarch-00.txt, Work in Progress, June 2000. [GSAKMP] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer, Group Secure Association Key Management Protocol, http://search.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec- 00.txt, June 2000, Work in Progress. [HBH] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group Security Association (GSA) Definition, http://www.ietf.org/internet-drafts/draft-irtf-smug-gkmbb-gsadef- 00.txt, Work in Progress 2000. [HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, Secure IP Multicast: Problem areas, Framework, and Building Blocks, http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt, Work in Progress 1999. [MARKS] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99, rbriscoe@bt.co.uk. [AMESP] R. Canetti, P. Rohatgi, Pau-Chen Cheng, Multicast Data Security Transformations: Requirements, Considerations, and Prominent Choices, http://search.ietf.org/internet-drafts/draft-irtf-smug-data- transforms.txt, Work In Progress, 2000. [NAI] http://www.nai.com/media/pdf/products/tns/6_PGP_VPN_001.pdf [OFT] D. Balenson, D. McGrew, A. Sherman, Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization, http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- 00.txt, February 1999, Work in Progress. [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, January 1996. [RFC2093] Harney, H., and Muckenhirn, C., "Group Key Management Protocol (GKMP) Specification," RFC 2093, July 1997. Baugher, Hardjono, Harney, Weis [PAGE 28] INTERNET DRAFT July 2001 [RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management Protocol (GKMP) Architecture," RFC 2094, July 1997. [RFC2327] M. Handley, V. Jacobson, SDP: Session Description Protocol, April 1998. [RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API, Version 2, July 1998. [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, November 1998 [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP), November 1998. [RFC2407] D. Piper, The Internet IP Domain of Interpretation for ISAKMP, November 1998. [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet Security Association and Key Management Protocol, November 1998. [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), November, 1998. [RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November 1998. [RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management Protocol, March 1999. [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for Multicast: Issues and Architectures, September 1998. [SKEME] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism for Internet, ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996. [SRTP] R.Blom, E.Carrara, D.McGrew, M.Nasland, K.Norrman, D. Oran, The Secure Real Time Transport Protocol, http://www.ietf.org/internet- drafts/draft-ietf-avt-srtp-00.txt, February 2001, Work in Progress. [STS] Diffie, P. van Oorschot, M. J. Wiener, Authentication and Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107- 125 (1992), Kluwer Academic Publishers. Baugher, Hardjono, Harney, Weis [PAGE 29] INTERNET DRAFT July 2001 Authors Address: Mark Baugher Cisco Systems 5510 SW Orchid Street Portland, OR 97219, USA (503) 245-4543 mbaugher@cisco.com Thomas Hardjono VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880 Tel: 781-245-6996 Email: thardjono@verisign.com Hugh Harney Sparta 9861 Broken Land Parkway Columbia, MD 21046 (410) 381-9400 x203 hh@sparta.com Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA (408) 526-4796 bew@cisco.com Appendix A: Sample GDOI definitions for MESP and AMESP Among the Security Protocols that may use the GDOI are MESP and AMESP, which together are a protocol framework for group secrecy, group authentication, and group source authentication [AMESP]. This framework is to support a variety of algorithms for source authentication and operate at the internetwork, transport or applications layers. The MESP and AMESP protocols do not provide source authentication; they provide a framework for source authentication algorithms such as TESLA, which is a group source authentication algorithm that is suitable for transport/application layer service. Thus, if source authentication service is desired for MESP and AMESP, then one or more group source authentication algorithms must be defined along with MESP and AMESP. We choose to use TESLA for this example. As mentioned above (section 5.4.2), the GDOI definitions for group Security Protocols such as MESP and AMESP are to have separate documents from the GDOI document. This appendix, therefore, offers an example for Security Protocol GDOI documents. In the model of Figure 3, the MESP/AMESP Security Protocol Baugher, Hardjono, Harney, Weis [PAGE 30] INTERNET DRAFT July 2001 implementation invokes GDOI to establish necessary security associations for its services. The needed information is communicated in the SA TEK payload and MESP/AMESP SA TEK attributes. These are defined in A.1 and A.2. MESP/AMESP, moreover, specifies source-specific information for multicast group senders so there may be information contained in the SA TEK that is specific to a sender. The sender-specific information is sent in a set of Extended Attributes that are particular to the algorithm that is used. These are defined in A.3. In both the single-sender and multiple-sender cases, the GROUPKEY-PUSH message containing the SA TEK payload may originate from the GCKS or from another source such as the sender or senders to the multicast group (section 4.3). A.1 SA TEK bindings A GDOI implementation must initialize the SA TEK payload information for MESP/AMESP. The reader may refer to the SA TEK payload section 5.4 for the MESP/AMESP bindings, which follow. o SPI size is 4 octets o SPI is a pseudo-random number created by the GCKS A.2 MESP/AMESP SA TEK Attributes The following attributes may be present in an MESP/AMESP SAT Payload. These attributes are followed by attributes for the TESLA source authentication algorithm. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V). ID Class Value Type -------- ----- ---- RESERVED 0 GS_ORDER 1 B GS_PROTOCOL 2 B GS_XFORM_TYPE 3 B GS_XFORM_KEY_LENGTH 4 B GS_XFORM_KEY_LIFETIME 5 B GA_ORDER 6 B GA_PROTOCOL 7 B GA_TRANSFORM 8 B SrA_ORDER 9 B SrA_PROTOCOL 10 B SrA_ALGORITHM 11 B RESERVED 12-63 AUTHENTICATION ALGORITHM 64-128 PRIVATE USE 129-255 A.2.1 GS_ORDER Baugher, Hardjono, Harney, Weis [PAGE 31] INTERNET DRAFT July 2001 This is the order in which the transform is applied relative to the other transforms. The ordering is from outer (1) to inner. If GS_ORDER is zero then group secrecy is not employed. If it is one (1), then GS is the first transform applied by the receiver. If GS_ORDER is greater than GA_ORDER and SrA_ORDER, then GS is the first transform applied by the sender. GDOI does nothing with this ordering beyond communicating it to the MESP/AMESP implementation across the interface shown in Figure 3 between GDOI and the Security Protocol. A.2.2 GS_PROTOCOL This is set to one (1) if MESP is used or two (2) if AMESP is used. GDOI does nothing with this layering information beyond communicating it to the MESP/AMESP implementation across the interface shown in Figure 3 between GDOI and the Security Protocol. A.2.3 GS_TRANSFORM Transform Type Value -------------- ----- RESERVED 0 GS_XFORM_DES 1 GS_XFORM_3DES 2 GS_XFORM_TWOFISH 3 GS_XFORM_AES 4 RESERVED 5-127 Private Use 128-255 A.2.4 GS_TRANSFORM_KEY_LENGTH The length of the key in bits. A.2.5 GS_TRANSFORM_KEY_LIFETYPE The GS_TRANSFORM_KEY_LIFETIME specifies the maximum time for which the key is valid. The GCKS may refresh the key at any time before the end of the valid period. The value is a four (4) octet number defining a valid time period in seconds. A.2.6 GA_ORDER See A.2.1. A.2.7 GA_PROTOCOL See A.2.2. A.2.8 GA_TRANSFORM Baugher, Hardjono, Harney, Weis [PAGE 32] INTERNET DRAFT July 2001 Transform Type Value -------------- ----- RESERVED 0 GA_XFORM_DES_MAC 1 GA_XFORM_HMAC_MD5 2 GA_XFORM_HMAC_SHA1 3 RESERVED 4-127 Private Use 128-255 A.2.9 SrA_ORDER See A.2.1. A.2.10 SrA_PROTOCOL See A.2.2. A.2.11 SrA_ALGORITHM Algorithm Type Value -------------- ----- RESERVED 0 SrA_TESLA 1 RESERVED 2-127 Private Use 128-255 A.3 TESLA SA TEK Attributes The attributes for the source authentication algorithm follow the MESP/AMESP SA TEK attributes. These are for TESLA. ID Class Value Type -------- ----- ---- RESERVED 0 SOURCE_ID 64 B DIRECT_SYNCHRONIZATION 65 B SENDERS_CERT_TYPE 66 B SENDERS_CERT 67 V HMAC_TYPE 68 B KEY_CHAIN_PRF 69 B INTERVAL_TIME 70 V INTERVAL_NUMBER 71 V INTERVAL_DURATION 72 V KEY_DISCLOSURE_DELAY 73 V KEY_CHAIN_COMMITMENT_VALUE 74 V KEY_CHAIN_EXPIRATION_VALUE 75 V A.3.1 SOURCE_ID Baugher, Hardjono, Harney, Weis [PAGE 33] INTERNET DRAFT July 2001 This is 32-bit number that uniquely identifies the source. A.3.2 DIRECT_SYNCHRONIZATION This is set to one if Direct Synchronization is desired and zero otherwise. A.3.3 SENDERS_CERT_TYPE ID Class Value Type -------- ----- ---- RESERVED 0 X.509 1 B SPKI 2 B PGP 3 B RESERVED 4-127 Private Use 128-255 A.3.4 SENDERS_CERT This is the sender's certificate. A.3.5 HMAC_TYPE This is the hashed message authentication code used for TESLA messages. HMAC Type Value --------- ----- RESERVED 0 TESLA_HMAC_MD5 1 TESLA_HMAC_SHA1 2 TESLA_HMAC_RIPEMD160 3 RESERVED 4-127 Private Use 128-255 A.3.6 KEY_CHAIN_PRF The PRF used for computing the key chain. KEY_CHAIN_PRF Value --------- ----- RESERVED 0 TESLA_PRF_MD5 1 TESLA_PRF_SHA1 2 TESLA_PRF_RIPEMD160 3 RESERVED 4-127 Private Use 128-255 A.3.7 INTERVAL_TIME Baugher, Hardjono, Harney, Weis [PAGE 34] INTERNET DRAFT July 2001 The beginning time of the current interval. A.3.8 INTERVAL_NUMBER The identifier of the current interval. A.3.9 INTERVAL_DURATION The fixed interval of time (Tint) during which a message source sends zero or more packets may be set once for the session or may be dynamically changed during the session. If group policy dictates that the time interval is to be invariant, then INTERVAL_DURATION is the number of seconds of the time interval. If INTERVAL_DURATION is not present, then the time interval will be dynamically set by the source authentication protocol and may vary over the lifetime of the session. A.3.10 KEY_DISCLOSURE_DELAY KEY_DISCLOSURE_DELAY is the number of intervals (d) before an authentication key is disclosed. KEY_DISCLOSURE_DELAY is used if the number of intervals must be fixed for a given session or if the sender chooses not to vary this interval during the session. Otherwise, if the KEY_DISCLOSURE_DELAY attribute is not present, then the key disclosure delay may be set dynamically by the source authentication protocol. A.3.11 KEY_CHAIN_COMMITMENT_VALUE The PRF value for the start of a new key chain. A.3.12 KEY_CHAIN_EXPIRATION_VALUE The INTERVAL_NUMBER that will be the last interval of the current key chain. Appendix B: LKH Data Key Download Definitions This section contains attribute definitions used by a GCKS to transmit a LKH KEK array to group members. These definitions are compatible with the GSAKMP protocol [GSAKMP]. B.1 LKH Key Data (KD) Payload definitions The following attributes are used to pass an LKH KEK array in the KD payload. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes which are defined as TV are marked as Basic (B); attributes which are defined as TLV are marked as Variable (V). Baugher, Hardjono, Harney, Weis [PAGE 35] INTERNET DRAFT July 2001 KEK Class Value Type --------- ----- ---- RESERVED 0 KEK_LKH 1 V If an LKH key packet is included in the KD payload, there must be only one present. B.1.1 KEK_LKH This attribute consists of a header block, followed by one or more LKH keys. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! LKH Version ! Leaf ID ! Number of ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LKH Keys ! ! +-+-+-+-+-+-+-+-+ LKH Keys ! ~ ~ +---------------------------------------------------------------+ The KEK_LKH attribute fields are defined as follows: o LKH version (1 octet) - Contains the version of the LKH protocol which the data is formatted in. o Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH sequence contained in this Key Packet Data block. o Number of LKH Keys (2 octets) -- This value is the number of distinct LKH keys in this sequence. Each LKH Key is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! LKH ID ! Key Type ! ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Key Creation Date ! ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Key expiration Date ! ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Key Handle ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ! ! ! ~ Key Data ~ +---------------------------------------------------------------+ o LKH ID (2 octets) -- This is the position of this key in the binary tree structure used by LKH. Baugher, Hardjono, Harney, Weis [PAGE 36] INTERNET DRAFT July 2001 o Key Type (1 octet) -- This is the encryption algorithm for which this key data is to be used. This value is specified in the Policy Token. o Key Creation Date (4 octets) -- This is the time value of when this key data was originally generated. o Key Expiration Date (4 octets) -- This is the time value of when this key is no longer valid for use. o Key Handle (4 octets) -- This is the randomly generated value to uniquely identify a key. o Key Data (variable length) -- This is the actual encryption key data, which is dependent on the Key Type algorithm for its format. Appendix C: Sample GDOI Definitions for SRTP As described above, Security Protocols may use GDOI to establish their security associations (Section 5.4.2). Designers of the security protocol should develop a draft document that describes the information needs of their security protocol for security association (SA) attributes and cryptographic policy. This appendix outlines a specification for GDOI support of SRTP [SRTP]. SRTP, Secure Real Time Transport Protocol, provides authentication, integrity, and confidentiality services for Real Time Transport Protocol [RFC1889]. Thus SRTP is an application-layer security protocol that operates above the TCP/IP services (sockets) interface. SRTP communicates with GDOI using an API [we will investigate use of PF_KEY for IPC communication]. Through the API, SRTP requests SA establishment and GDOI updates SRTP's security association database (SAD) for maintenance of its cryptographic context [SRTP]. The KDC or the SRTP sender acting on behalf of the KDC provides the cryptographic policy and other attributes through the SA TEK payload and SRTP SA TEK attributes. C.1 SRTP Namespace: SA TEK Bindings A GDOI implementation must initialize the SA TEK payload information for SRTP. The reader may refer to the SA TEK payload section 5.4 for the description of SA TEK bindings, which follow. o SPI size is 2 octets o SPI the RTP 32-bit sequence number that is sent on the wire. The receiver(s) will immediately compute the "real" SPI as the "packet index" of SPI + rollover-counter * 2^32 and use this value with the SSRC and Transport address to identify the SRTP cryptographic context. Thus, a cryptographic context is identified by the RTP packet index, the SSRC and the Transport Address. This packet index is the first number in a sequence of RTP packets that will use the given cryptographic context. For a given SSRC and Transport Address, a new cryptographic context is identified by a packet index number in which all RTP packets that equal or exceed that packet index will use Baugher, Hardjono, Harney, Weis [PAGE 37] INTERNET DRAFT July 2001 the new cryptographic context. A compliant SRTP implementation, therefore, must compute and check the packet index to see if it matches a new cryptographic context for a given SSRC, Transport Address pair. At any given time, there should be at most two cryptographic contexts available for a given SSRC, Transport Address pair - this is how new cryptographic contexts are installed and the key is changed for an RTP session. C.2 SRTP Namespace: SA TEK Attributes The following attributes are encoded according to Section 3.3, RFC 2408 [RFC2408]. ID Class Type Length -------- ----- ------ RESERVED 0 SSRC 1 V DESTINATION_ADDRESS 2 V DESTINATION_RTP_PORT 3 V DESTINATION_RTCP_PORT 4 V ROLLOVER_COUNTER 5 V CIPHER 6 V CIPHER_MODE 7 V CIPHER_KEY_LENGTH 8 V SALT_KEY_LENGTH 9 V AUTHENTICATION_ALGORITHM 10 B REPLAY_WINDOW_SIZE 11 V SRTCP 12 B RESERVED 19-128 C.2.1 SSRC A 32-bit unsigned integer that identifies the SSRC of the sender. C.2.2 DESTINATION_ADDRESS The network address on which RTP and RTCP packets are received and sent. C.2.3 DESTINATION_RTP_PORT The port number on which RTP packets are received. C.2.4 DESTINATION_RTCP_PORT The port number on which RTCP packets are received and sent. C.2.5 ROLLOVER_COUNTER The 32-bit counter that is incremented each time the sequence number (SRTP SPI) rolls over. C.2.6 CIPHER The algorithm used to encipher and decipher SRTP payloads. AES is the default. Baugher, Hardjono, Harney, Weis [PAGE 38] INTERNET DRAFT July 2001 Algorithm Type Value -------------- ----- RESERVED 0 AES 1 RESERVED 2-127 Private Use 128-255 C.2.7 CIPHER_MODE The mode of the cipher used to encipher and decipher SRTP payloads. Counter_Mode_AES is the default. Cipher Mode Value -------------- ----- RESERVED 0 Counter_Mode_AES 1 f8_Mode_AES 2 RESERVED 3-127 Private Use 128-255 C.2.8 CIPHER_KEY_LENGTH The length of the encryption key. 128 is the default for AES. C.2.9 SALT_KEY_LENGTH The length of key used for salt. 128-bit is the default for AES Counter Mode. C.2.10 AUTHENTICATION_ALGORITHM The type of authentication used for SRTP. Authentication Value -------------- ----- RESERVED 0 UMAC 1 RESERVED 2-127 Private Use 128-255 C.2.11 WINDOW_SIZE Replay window size defaults to 64 when not specified. C.2.12 SRTCP Defaults to "0" when RTCP authentication/integrity and encryption is used and set to "1" when these services are not applied to the RTCP for the session. Baugher, Hardjono, Harney, Weis [PAGE 39]