Network Working Group M. Baugher Internet-Draft Cisco Systems, Inc. Intended status: Standards Track A. Rueegsegger Expires: August 24, 2007 secunet SwissIT AG S. Rowles Cisco Systems, Inc. February 20, 2007 GDOI Key Establishment for the SRTP Data Security Protocol draft-ietf-msec-gdoi-srtp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 24, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Baugher, et al. Expires August 24, 2007 [Page 1] Internet-Draft GDOI-SRTP February 2007 Abstract The Secure Real-time Transport Protocol (SRTP) protects unicast and multicast RTP packets. Multicast receivers of SRTP session data therefore share an SRTP master key for message authentication and decryption. This document describes how to establish a shared, "group key" for an SRTP session using RFC 3547, the Group Domain of Interpretation (GDOI) and RFC 2408, the Internet Security Association and Key Management Protocol. This document extends GDOI for SRTP group key establishment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of This Document . . . . . . . . . . . . . . . . 3 1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3 2. GDOI Signaling of an SRTP Crypto Context . . . . . . . . . . . 4 2.1. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. GDOI Exchanges for SRTP . . . . . . . . . . . . . . . . . 7 2.3. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 9 2.4. EKT SA-TEK Definitions . . . . . . . . . . . . . . . . . . 14 2.5. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 15 3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 17 4.2. Enable Distributed Key Management . . . . . . . . . . . . 17 4.3. Support Strong Source Authentication . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Baugher, et al. Expires August 24, 2007 [Page 2] Internet-Draft GDOI-SRTP February 2007 1. Introduction The Group Domain of Interpretation (GDOI) is an authenticated key establishment protocol for groups, which is specified by RFC 3547 [RFC3547]. GDOI is based upon ISAKMP, the Internet Security Association and Key Management Protocol [RFC2408]. GDOI extends ISAKMP for group key management whereby a cryptographic key is shared among multiple receivers and optionally multiple senders. GDOI uses unicast (ISAKMP) as well as multicast key establishment method and supports member revocation algorithms, such as the "key hierarchy" algorithm of RFC 2627 [RFC2627]. GDOI preserves the ISAKMP design, which supports new data security protocols through documented procedures, but it currently supports only one data security protocol, IPsec. This document extends GDOI to a new data security protocol, the Secure Real-time Transport Protocol (SRTP) as specified by RFC 3711 [RFC3711]. SRTP extensions to GDOI use two new GDOI payloads. The GDOI-SRTP payload definitions apply GDOI key establishment procedures to groups of SRTP receivers in accordance with Section 5.4.2 of the GDOI protocol specification [RFC3547]. The SRTP payloads carry keys, parameters, and other values needed for an SRTP session's "cryptographic context", which is described in Section 8 of the SRTP specification [RFC3711]. In addition to signaling SRTP, GDOI-SRTP payloads MAY signal use of the Encrypted Key Transport (EKT) protocol as an option [I-D.mcgrew-srtp-ekt]. These options, parameters and keys are defined in two GDOI payloads, the "Security Association Traffic Encrypting Key" (SA-TEK) payloads for SRTP (SRTP SA-TEK) and EKT (EKT SA-TEK). 1.1. Overview of This Document Section 2 of this document presents the GDOI-SRTP payloads. The SRTP SA-TEK payload MAY carry IP address and port information, which have implications for network address translation (NAT). Section 3 gives NAT considerations, Section 4 discusses Security Considerations, and Section 5 lists IANA requirements. 1.2. Conformance Language 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 [RFC2119]. Baugher, et al. Expires August 24, 2007 [Page 3] Internet-Draft GDOI-SRTP February 2007 2. GDOI Signaling of an SRTP Crypto Context A service can use GDOI to establish keys (security associations) for a data security protocol provided that GDOI is extended with one or more payload definitions for that data security protocol. For GDOI, a "data security protocol" is any protocol that uses the services of GDOI. By contrast, TLS key establishment is packaged with the TLS data-security protocol. GDOI follows the ISAKMP model in which key management and data security MAY use separate transport addresses and underlying transport protocols, typically UDP or TCP. By default, GDOI uses UDP to negotiate an IKE phase 1 security association between a GDOI Group Controller/Key Server (GCKS) and group member; the IKE phase 1 protects an exchange to establish a security association on behalf of an application security protocol. In SRTP, a "security association" is called a "cryptographic context", and this is the application-specific information carried in GDOI payloads between the GCKS and a GDOI member. This section defines these SRTP payloads for GDOI. Baugher, et al. Expires August 24, 2007 [Page 4] Internet-Draft GDOI-SRTP February 2007 Figure 2.0-1: Member and SRTP Interfaces in a Central GCKS Configuration +-------+ | GDOI | | GCKS | +-------+ ^ | V +--------------------------+ | GDOI with SRTP payloads | V V +----------+ +----------+ |+--------+| |+--------+| || GDOI || || GDOI || || Member || || Member || |+--------+| |+--------+| | ^ | | ^ | | | | | | | | API | | API | | | | | | | | V | | V | |+--------+| SRTP/SRTCP |+--------+| || SRTP |---------------->| SRTP || || Source |<----------------|Receiver|| |+--------+| SRTCP |+--------+| +----------+ +----------+ MEMBERi MEMBERj This section gives the SRTP payloads for GDOI key management exchanges. SRTP is an application-layer security protocol that operates above the TCP/IP services (sockets) interface. GDOI also operates above the transport service. SRTP communicates with GDOI using the API shown in Figure 2.0-1. SRTP or another application uses the API to request that GDOI establish an SRTP cryptographic context (i.e. a GDOI "security association"), which is described in Section 3.2 of the SRTP specification [RFC3711]. The API of Figure 2.0-1 is not considered further in this document, which is concerned solely with extending the GDOI protocol with new payloads for SRTP. Using this protocol extension, the GDOI Group Controller/Key Server (GCKS) can provide the cryptographic keys, cryptographic parameters and session parameters to SRTP (via the API to a GDOI Member) in accordance with pre-configured group policy regarding which parameters are acceptable and which are not. The GCKS might obtain policy and some SRTP crypto-context information through a user console or event database. The GCKS generates some information Baugher, et al. Expires August 24, 2007 [Page 5] Internet-Draft GDOI-SRTP February 2007 automatically, such as keying materials. How the GCKS obtains or generates policy information for the SRTP payload fields is specific to an implementation and not considered further in this document. Figure 2.0-2: A Distributed GCKS Configuration +----------+ +----------+ |+--------+| +|+--------+| GDOI with || GDOI || ||| GCKS & |<--------------->| GCKS & || ||| Member || SRTP payloads|| Member || ||+--------+| |+--------+| || ^ | | ^ | || | | | | | || API | | API | || | | | | | || V | | V | ||+--------+| SRTP/SRTCP |+--------+| ||| SRTP |---------------->| SRTP || ||| Source |<----------------|Receiver|| ||+--------+| SRTCP |+--------+| || MEMBERi | | MEMBERj | |+----------+ +----------+ | MEMBERk | +----------+ In a physical realization of GDOI system, the GDOI GKCS can either be separate from or co-located with a GDOI Member. When physically co- located with a member, the GCKS can be dedicated to maintaining the group keys for that member's "SRTP Source", and the GCKS can more easily obtain the SRTP-specific information for its payloads across the API. This configuration is shown in Figure 2.0-2. It is often more scalable for the GCKS to be physically co-located in the same computer as the SRTP source of the multicast stream. When this configuration is possible, there is no need for a centralized Group Controller/Key Server. 2.1. GDOI and EKT When the Group Controller/Key Server (GCKS) is centralized as a third-party device, it is not co-located with the SRTP source, and it is not always possible for the GCKS to get access to important SRTP keystream parameters, which are the SSRC, the Rollover Counter (ROC) and current SRTP sequence number (SEQ). This information is generated internally by the SRTP source and used in the SRTP ciphers and SRTP replay protection; the SSRC is used in combination with the destination transport address to identify an RTP session [RFC3550] and thus identify an SRTP session's crypto context. When the GCKS is Baugher, et al. Expires August 24, 2007 [Page 6] Internet-Draft GDOI-SRTP February 2007 co-located with the SRTP source, this information can be obtained via the API shown in the above figures. Such an API can be defined in an implementation. But when the GCKS is physically separate from the SRTP source, GDOI has no over-the-wire protocol for collecting the SSRC, ROC and SEQ information from the source. The Encrypted Key Transport (EKT) protocol solves this problem. EKT extends SRTCP to securely provide the SSRC, ROC and the SEQ from the SRTP source to the SRTP receiver, and EKT correctly initializes the SSRC, ROC and SEQ for late joiners to the multicast group or following RTP SSRC collision repair [I-D.mcgrew-srtp-ekt]. In a centralized GCKS configuration (Fig 2.0-1), EKT is RECOMMENDED in this document for transporting an SRTP sender's SSRC, ROC and SEQ to SRTP receivers. In a distributed GCKS configuration, it is possible for the GCKS to correctly initialize the SSRC, ROC and SEQ by obtaining these values through an API with the GDOI member; in this case, it is RECOMMENDED that GDOI peform this function. When the GCKS provides current SSRC, ROC and SEQ values, these are carried in GDOI-SRTP SA-TEK payload and the GDOI Key Download payload carries the SRTP master key and salt. When EKT is used instead, the GDOI Key Download payload carries the EKT key. Whether or not to use EKT or to provide SRTP SSRC, ROC and SEQ parameters via GDOI SHALL be a configurable option in GDOI-SRTP. When the EKT option is not used, the SRTP receiver can begin validating and decrypting packets without waiting for an EKT message to arrive in the SRTCP session. EKT is needed, however, when the GCKS cannot reliably initialize the SA-TEK with SSRC, ROC and SEQ fields. When EKT is used, there are two SA-TEK payloads. First, there is an SRTP SA-TEK payload that describes an SRTP master key and salt; the SRTP SA-TEK is always present. Second, there is an EKT SA-TEK payload that describes an EKT key. In either case, there is exactly one Key Download payload sent in a GDOI-SRTP exchange. If EKT is signaled by the presence of an EKT SA-TEK, then the Key Download payload SHALL carry an EKT key. If EKT is not signaled, then the KEY Download payload SHALL carry an SRTP master key and master salt. In either case, there MUST be exactly one Key Download payload when signaling SRTP in GDOI. 2.2. GDOI Exchanges for SRTP As mentioned above, GDOI exchanges for SRTP are protected by a "phase 1 security association", which is an IKE phase 1 connection in which the GCKS and the member identify and authenticate each other. For the IKE phase 1, RFC 3547 allows any defined IKE identity such as IP address, fully-qualified domain name or an opaque byte string that Baugher, et al. Expires August 24, 2007 [Page 7] Internet-Draft GDOI-SRTP February 2007 identifies a pre-shared key[ISAKMP-REG]. Also, any of the IKE authentication methods MAY be used including pre-shared key, public- key encryption, and digitial signatures. The IKE phase 1 connection is established using a six-message "Main Mode" exchange if identity protection is desired or a 3-message "Aggressive Mode" if identity protection is not needed [RFC2409]. With identity protection, a passive attack will not reveal the identities that the initiator or responder use to authenticate themselves. In GDOI, the initiator is usually the group member and the responder is usually the Group Controller/Key Server. This is true in both the phase 1 and phase 2 exchanges. The phase 2 exchange uses a 4-message exchange as defined in RFC 3547, Section 3 [RFC3547] and is reproduced below for the convenience of the reader. Figure 2.2-1: GDOI Phase 2 Exchange, from Section 3.2 [RFC3547] Initiator (Member) Responder (GCKS) ------------------ ---------------- HDR*, HASH(1), Ni, ID --> <-- HDR*, HASH(2), Nr, SA HDR*, HASH(3) [,KE_I] --> [,CERT] [,POP_I] <-- HDR*, HASH(4),[KE_R,][SEQ,] KD [,CERT] [,POP_R] * Protected by the Phase 1 SA, encryption occurs after HDR When sent to the GDOI port, the message header (HDR) of Fig. 2.2-1 identifies the phase 2 exchange, i.e. by the ISAKMP message id (M-ID) field of HDR. Everything else is encrypted using the phase 1 encryption key and authenticated in the HASH payloads that appear in each message. A nonce and an ID are sent in the first message from the member to the GCKS, which responds by downloading the cryptographic parameters, session parameters, authentication policy and other information that the member needs to identify and authenticate itself to the GCKS. The GCKS provides these parameters and policy information in the Security-Association (SA) payload of the second message along with its nonce, Nr. As described in the previous section of this document, how these policies and parameters are defined is out of scope for this document. The successful GDOI- SRTP exchange establishes an SRTP cryptographic context (i.e. a security association among SRTP endpoints). The third message of Fig 2.2-1 is from the member to the GCKS. If perfect forward secrecy is desired, Diffie-Hellman public value are exchanged in the Key-Exchange (KE) payloads (KE_I and KE_R), which Baugher, et al. Expires August 24, 2007 [Page 8] Internet-Draft GDOI-SRTP February 2007 are optional. If additional authorization and authentication are desired beyond the IKE Phase 1, then a digital certificate can be passed in a Cerficate (CERT) payload with an optional proof-of- possession exchange to prove possession of the corresponding private key (POP_I and POP_R). The fourth and final message concludes a successful GDOI phase 2 exchange by passing a Key-Download (KD) payload. Any KE, CERT or POP exchanges are completed in the final message. Another optional field is SEQ, which is the sequence number associated with messages that are sent (pushed) from the GCKS to the member. For pushed messages, the SA payload will include a GDOI key-encrypting key (KEK) definition in an SA-KEK payload. A GDOI group will not use pushed messages if it does not need to perform key update of the SRTP Master Key (SA-TEK) or member revocation. Thus, an SA-KEK is OPTIONAL whereas one or two SA-TEKs are REQUIRED by this document; these are the SRTP SA-TEK and the optional EKT SA-TEK. The SA-KEK and SA-TEK are part of the SA payload shown in Figure 2.2-1. 2.3. SRTP SA-TEK Definitions The RFC 3547 SA TEK payload has a header and a protocol-specific payload. The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value (assigned by IANA) in the Protocol-ID field of the SA TEK header, which is defined in Section 5.4 of RFC 3547 [RFC3547]. The SA TEK protocol-specific payload for SRTP is given in Figure 2.2-1. The SAT Payload fields are shown in Figure 2.3-1. Baugher, et al. Expires August 24, 2007 [Page 9] Internet-Draft GDOI-SRTP February 2007 Figure 2.3-1: SRTP SA-TEK 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SRC ID Type ! SRC ID Port !SRC ID Date Len! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SRC Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST ID Type ! DST ID Port !DST ID Data Len! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Options ! Crypto Suite ! SPI ! Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Attribute Class Value Type --------------- ----- ---- RESERVED 0 SSRC 1 B ROC 2 B SEQ 3 B MKI 4 V The Group Controller/Key Server (GCKS) provides SA-TEK and Key- Download payload information to an SRTP implementation through the GDOI member to SRTP, which uses this information to initialize the cryptographic context of an SRTP session. An SRTP crypto context is identified by the SSRC and RTP destination transport address as explained in Section 8 of the SRTP specification [RFC3711]. The RTP destination address is identified in the SA-TEK, which is shown in Figure 2.3-1. The "DST ID Type" defines the type of DST Identification data, which is an IP address or a fully-qualified domain name that resolves to one. The destination port is also carried in the DST ID Port, also shown in Figure 2.3-1 following the similar definitions for the source. Replay window, key-derivation (KD) rate, SRTP and SRTCP lifetimes are the crypto context parameters for the particular SRTP session. Also shown in Figure 2.3-1 is the options field, that declares values for boolean SRTP configuration parameters and also whether EKT is to be used or not. Crypto Suite identifies the SRTP encryption and authentication transforms. GDOI-SRTP uses the same encryption and authentication transforms for SRTP and SRTCP. Finally, the SPI is the "security parameter index", which identifies the particular Baugher, et al. Expires August 24, 2007 [Page 10] Internet-Draft GDOI-SRTP February 2007 security association (SRTP crypto context) by a 8-bit number, a positive integer. The Attributes payloads are optional. The attributes must follow the format defined in ISAKMP [RFC3547] 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). The SSRC, rollover counter (ROC) and current sequence number (SEQ) MAY be carried in the SA TEK payload that is shown in Figure 2.3-1. When the SSRC, ROC and the SEQ are not carried in the SRTP SA-TEK payload, the EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt]. EKT is signaled in the options field described above. If EKT is signaled in Options, then the SSRC, ROC and SEQ Attributes MUST be ignored. If EKT is not signaled in Options, the the SSRC, ROC and SEQ MUST be present. Each of the fields of Figure 2.3-1 is 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 by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. o SRC ID Port (2 octets) -- Value specifying a port associated with the SRC Identification data. A value of zero means that the SRC ID Port field should be ignored. o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field. o SRC Identification Data (variable length) -- Value as indicated by the SRC ID Type. According to RFC 3547, SRC Identification Data consists of three bytes of zero for multiple-source multicast groups that use a common TEK for all senders. The TEK in an SRTP Key Download payload is an SRTP master key, however, and it is NOT RECOMMENDED that this key be shared for the counter mode and f8 ciphers of SRTP. Thus, it is NOT RECOMMENDED that this field consist of three bytes of zero. It SHOULD be ID_FQDN (see the "NAT Considerations" section). o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. 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. Baugher, et al. Expires August 24, 2007 [Page 11] Internet-Draft GDOI-SRTP February 2007 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 Replay Window Size (1 octet) - The size of the SRTP Replay Window as specified in Section 3.3.2 of the SRTP standard [RFC3711]. o KD Rate (1 octet) - SRTP Key Derivation Rate as specified in Section 4.3.1, second paragraph of the standard [RFC3711]. KD Rate is an integer that is greater than or equal to zero. The SRTP "packet index" of an outgoing or incoming SRTP packet is computed modulo the KD Rate in cases where the KD Rate is greater than zero. The reader is referred to Sections 3.3.1 and 4.3.1 of the SRTP specification for the definitions of "packet index" and "Key Derivation Rate". o SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an integer N to represent a lifetime of 2^N packets, where N cannot exceed the maximum lifetime as specified by the Crypto Suite. A value of zero signals the SRTP default (N=48). o SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an integer N to represent a lifetime of 2^N packets, where N cannot exceed the maximum lifetime as specified by the Crypto Suite. A value of zero signals the SRTP default (N=31). o Options (1 octet) - Reading from left to right (big-endian), SRTP is unencrypted when bit 0 is set to '1'. SRTP is unauthenticated when bit 1 is set to '1'. SRTCP is unencrypted when bit 2 is set to '1'. EKT is not used when bit 3 is set to '1'. The SSRC, ROC and SEQ are not included and MUST be ignored when bit 4 is set to '1'. o SSRC (2 octets) - Value of the Sender's SSRC when there is a single sender associated with the KEK and TEK signaled in the SA- TEK and Key Download payload. o Crypto Suite (1 octet) -- The set of parameters that defines the SRTP and SRTCP encryption transform, authentication transform, key length, and salt length. The values are defined in the Table 2.1-2. Each row in the table defines a suite of parameters. Any parameter can be changed and new parameters added by creating a new Crypto Suite, documenting it in an Internet RFC, and requesting a Suite Value for it from IANA. Baugher, et al. Expires August 24, 2007 [Page 12] Internet-Draft GDOI-SRTP February 2007 Table 2.1-2: SRTP Crypto Suites Suite Master Master Max SRTP Max SRTCP Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len ----- ------ ------ ------- -------- -------- ------- 0 AES-CM 128 112 2^48 2^31 HMAC-SHA1/80 1 AES-CM 128 112 2^48 2^31 HMAC-SHA1/32 2 AES-F8 128 112 2^48 2^31 HMAC-SHA1/80 3 AES-CM 192 112 2^48 2^31 HMAC-SHA1/80 4 AES-CM 192 112 2^48 2^31 HMAC-SHA1/32 5 AES-CM 256 112 2^48 2^31 HMAC-SHA1/80 6 AES-CM 256 112 2^48 2^31 HMAC-SHA1/32 7-127 RESERVED Note: All keylen values are in bits The key values of 192 and 256 are specified in the "BIG AES" Internet Draft document [I-D.mcgrew-srtp-big-aes]. In the vast majority of SRTP applications, the BIG AES values SHOULD NOT be used since they do not increase security as a practical matter but could diminish interoperability, see Section 7 of the Big AES I-D. o SPI (2 octets) - The value of the security parameter index that identifies this security association between the GCKS and the group member. o SSRC (1 octet) - The value of the SRTP SSRC; this attribute MUST be present when bit 4 of Options is set to '1' but MUST be ignored otherwise. o ROC (4 octets) - The current value of the SRTP rollover counter (ROC); this attribute value MUST be present when bit 4 of Options is set to '1' but MUST be ignored otherwise. o SEQ (2 octets) - The current value of the SRTP sequence number; this attribute MUST be present when bit 4 of Options is set to '0' but MUST be ignored otherwise. o MKI (variable) - An SRTP Master Key Indicator (MKI) SHALL appear in SRTP packets when this attribute is present. As defined in Section 3 of RFC 3711 [RFC3711], the maximum MKI length is 128 (bytes) though a smaller length of one or two bytes IS RECOMMENDED. The MKI Length attribute MUST be present when an MKI attribute is given. Baugher, et al. Expires August 24, 2007 [Page 13] Internet-Draft GDOI-SRTP February 2007 2.4. EKT SA-TEK Definitions EKT is an abbreviation for "encrypted key transport", which carries an SRTP master key, SEQ and ROC in an SRTCP packet. As described above, these values are generated internally to SRTP, and a central GCKS typically cannot obtain these values and the SSRC when it has no interface to the SRTP sender. In this case, EKT is RECOMMENDED as a means to correctly initialize an SRTP receiver with the SSRC, SEQ, ROC and SRTP master key. In this case, GDOI-SRTP serves to initialize the EKT system in a GDOI member by providing EKT parameters and a key called the "EKT key", which is used to encrypt the SRTP master key in the SRTCP packet. Thus, the security association between the GCKS and GDOI member establishes and maintains an EKT key. The EKT identifying information and parameters are shown in Figure 2.4-1. Figure 2.4-1: EKT-TEK 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST ID Type ! DST ID Port !DST ID Data Len! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! EKT Cipher ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each of the fields of Figure 2.3-1 is defined as follows. o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. 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. Baugher, et al. Expires August 24, 2007 [Page 14] Internet-Draft GDOI-SRTP February 2007 o EKT Cipher (1 octet) - Value specifying the cipher and mode used by EKT for the EKT key, which is carried in a GDOI Key Download payload. The following table correlates each EKT Cipher Suite [I-D.mcgrew-srtp-ekt] with a Suite Value. New EKT Cipher Suites MAY be added when documented by an Internet RFC and once IANA assigns a Suite Value to that Cipher Suite. Table 2.1-3: EKT Cipher Suites EKT Cipher Suite Suite Value ------ ----- RESERVED 0 AES_128 1 AESKW_128 2 AESKW_196 3 AESKW_256 4 RESERVED 5-127 o EKT SPI (1 octet) - The EKT security parameter index, which identifies the EKT security association between the GCKS and the GDOI member. 2.5. SRTP Key Download The SRTP SA-TEK Crypto Suite of Table 2.3-1 defines two keys, the SRTP master key and master salt key. These two keys are concatenated with the SRTP master key followed by the SRTP master salt in a Key Download (KD) payload's TEK_ALGORITHM_KEY attribute. When EKT is used, there is no KD payload corresponding to the SRTP SA-TEK. Instead, the KD payload carries the EKT key as defined by the EKT SA-TEK EKT Cipher. Baugher, et al. Expires August 24, 2007 [Page 15] Internet-Draft GDOI-SRTP February 2007 3. NAT Considerations Transport addresses are carried in the SA-TEK payloads and this contradicts recommendations for application-layer signaling through network address translators (NATs) [RFC2663][RFC3235]. The SA-TEK destination IP address and port, however, are multicast addresses which are not re-written by a NAT. The source address, however, might be re-written on outgoing multicast packets [I-D.wing-behave-multicast]. If the SA TEK SRC ID type of Figure 2.3-1 is an IP address and if there is an outgoing NAT that re-writes the source IP address field of outgoing packets, then there will likely be a discrepancy between the source address in the IP packet and the SRC Identification Data field of Figure 2.3-1. It is therefore RECOMMENDED that SRC ID Type be ID_FQDN [ISAKMP-REG] whenever there is network address translation present on the network of the multicast source. Baugher, et al. Expires August 24, 2007 [Page 16] Internet-Draft GDOI-SRTP February 2007 4. Security Considerations The security of GDOI and its payloads is discussed in Section 6 of the GDOI specification [RFC3547]. The security of SRTP and its parameter settings is discussed in Section 9 of the SRTP specification[RFC3711]. There are some additional risks in GDOI and SRTP that are considered here. 4.1. No Sharing Counter-Mode Encryption Keys One risk is the proper establishment of the SRTP SSRC, which is subject to SSRC collisions that might be exploited by an attacker. SRTP specifies that the SSRC is used in the AES counter mode and f8 initialization vectors (IV) to prevent counter reuse. RFC 3711 states that key management "SHOULD" install a unique SSRC. GDOI relaxes this requirement since SSRCs collide. It is also difficult to support an unchanged RTP module in a "bump-in-the-stack" SRTP configuration. Instead of depending on SSRC uniqueness, IT IS RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master key for each sender. To ensure SRTP master key uniqueness among senders to an SRTP session, SA-TEK SRC Identification Data (Figure 2.1.1) MUST NOT signal a group of senders sharing a key. GDOI specifies a means for sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK is an SRTP master key and this specification RECOMMENDS that a TEK SHOULD NOT be shared among SRTP sources. 4.2. Enable Distributed Key Management In many cases, SRTP sources are not co-located with a GCKS. This is one possible configuration in a large scale "video pump", for example, that is specialized to a purpose other than key management. If there are geographically-dispersed video-pump sources, there is the risk that the GCKS will be attacked and its ability to disseminate source-unique values to such as the ROC to the multicast group will be impaired. This is one possible attack out of many where a central GCKS can disrupt the entire multicast group of SRTP receivers. This document RECOMMENDS the use of EKT to securely distribute the SSRC, ROC and SEQ. GDOI-SRTP payloads signal the EKT Key. Two protocols have more vulnerabilities than one, however, and there are added risks that come from using both GDOI and EKT. A programming bug in GDOI (e.g. signaling zeros in SA-TEK SRC Identification Data), for example, might cause an attack on EKT (e.g. a distributed denial of service attack on a group of EKT receivers). In some cases, a feature that is useful for M:N groups might be risky Baugher, et al. Expires August 24, 2007 [Page 17] Internet-Draft GDOI-SRTP February 2007 when used in 1:N groups. For these reasons, the GDOI-SRTP SA-TEK SHOULD explicitly signal each source and provides a source TEK (SRTP Master Key) as well as a KEK (EKT Key). In extraordinary cases such as SSRC collision, the SSRC and SRTP master key MAY come from EKT, but in normal operation only the SEQ and ROC SHOULD be obtained from EKT. 4.3. Support Strong Source Authentication Despite the precautions described above, there is always the possibility of "source spoofing" when any member of the group authorized only to receive can impersonate an authorized sender. This is a limitation in symmetric-key authentication in secure groups. To address this problem, SRTP can use TESLA source authentication messaging [RFC4383]. A future revision of this document will consider TESLA signaling. Baugher, et al. Expires August 24, 2007 [Page 18] Internet-Draft GDOI-SRTP February 2007 5. IANA Considerations IANA is requested to register "GDOI_PROTO_SRTP" with a new value and that additional values be added to the Security Association Traffic Encrypting Key payload definitions, "SA TEK Payload Values" [GDOI-REG], as follows. 1. Table 2.1-2: SRTP Crypto Suites. 2. Table 2.1-3: EKT Cipher Suites Baugher, et al. Expires August 24, 2007 [Page 19] Internet-Draft GDOI-SRTP February 2007 6. Acknowledgements The authors thank David McGrew, Brian Weis and Liu Ya for their helpful comments. Baugher, et al. Expires August 24, 2007 [Page 20] Internet-Draft GDOI-SRTP February 2007 7. References 7.1. Normative References [GDOI-REG] "Group Domain of Interpretation (GDOI) Payloads - per [RFC3547], http://www.iana.org/assignments/gdoi-payloads", 2003. [I-D.mcgrew-srtp-big-aes] McGrew, D., "The use of AES-192 and AES-256 in Secure RTP", draft-mcgrew-srtp-big-aes-00 (work in progress), April 2006. [I-D.mcgrew-srtp-ekt] McGrew, D., "Encrypted Key Transport for Secure RTP", draft-mcgrew-srtp-ekt-01 (work in progress), June 2006. [ISAKMP-REG] "FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP Protocol, http://www.iana.org/assignments/isakmp-registry", September 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006. Baugher, et al. Expires August 24, 2007 [Page 21] Internet-Draft GDOI-SRTP February 2007 7.2. Informative References [I-D.wing-behave-multicast] Wing, D., "IGMP Proxy Behavior", draft-wing-behave-multicast-00 (work in progress), October 2004. [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. Baugher, et al. Expires August 24, 2007 [Page 22] Internet-Draft GDOI-SRTP February 2007 Authors' Addresses Mark Baugher Cisco Systems, Inc. 800 East Tasman Drive San Jose, CA 95164 US Phone: (503) 245-4543 Email: mbaugher@cisco.com Adrian-Ken Rueegsegger secunet SwissIT AG Hauptbahnhofstrasse 12 4501 Solothurn, Switzerland Phone: +41 32 625 80 40 Email: rueegsegger@swiss-it.ch Sheela Rowles Cisco Systems, Inc. 1700 West Tasman Drive San Jose, CA 95134-1706 US Phone: (408) 527-7677 Email: srowles@cisco.com Baugher, et al. Expires August 24, 2007 [Page 23] Internet-Draft GDOI-SRTP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baugher, et al. Expires August 24, 2007 [Page 24]