idnits 2.17.00 (12 Aug 2021) /tmp/idnits18789/draft-baugher-msec-gdoi-srtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2006) is 5697 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.wing-behave-multicast' is defined on line 567, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GDOI-REG' ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) == Outdated reference: A later version (-01) exists of draft-mcgrew-srtp-big-aes-00 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.mcgrew-srtp-ekt' ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP-REG') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2627 -- Duplicate reference: RFC2408, mentioned in 'RFC2408', was also mentioned in 'ISAKMP-REG'. -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Baugher 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 17, 2007 A. Rueegsegger 5 October 14, 2006 7 GDOI Key Establishment for the SRTP Data Security Protocol 8 draft-baugher-msec-gdoi-srtp-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 17, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The Secure Real-time Transport Protocol (SRTP) secures unicast and 42 multicast media streams. Multicast receivers of an SRTP stream 43 therefore share an SRTP master key for multicast message 44 authentication and decryption. This document describes how to 45 establish a shared, "group key" for an SRTP session using RFC 3547, 46 the Group Domain of Interpretation (GDOI) and RFC 2408, the Internet 47 Security Association and Key Management Protocol. This document 48 extends GDOI for SRTP group key establishment. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Overview of This Document . . . . . . . . . . . . . . . . 3 54 1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3 55 2. SRTP Definitions for GDOI Signaling . . . . . . . . . . . . . 4 56 2.1. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 6 58 2.3. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 10 59 3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 11 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 12 62 4.2. Enable Distributed Key Management . . . . . . . . . . . . 12 63 4.3. Support Strong Source Authentication . . . . . . . . . . . 13 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Introduction 74 The Group Domain of Interpretation (GDOI) is specified in RFC 3547 75 [RFC3547]. GDOI is based upon ISAKMP, the Internet Security 76 Association and Key Management Protocol [RFC2408]. GDOI extends 77 ISAKMP for group key management whereby a cryptographic key is shared 78 among multiple receivers. GDOI uses both unicast and multicast key 79 establishment, and can support messaging for member revocation 80 algorithms, such as the "key hierarchy" algorithm [RFC2627]. GDOI 81 preserves the ISAKMP design, which supports new data security 82 protocols through documented procedures. GDOI currently supports 83 only one data security protocol, IPsec. 85 This document presents GDOI payloads for another data security 86 protocol, the Secure Real-time Transport Protocol (SRTP). These 87 payload definitions apply GDOI key establishment procedures to groups 88 of SRTP receivers in accordance with Section 5.4.2 of the GDOI 89 protocol specification [RFC3547]. GDOI carries keys, parameters, and 90 other values needed for an SRTP session's "cryptographic context", 91 which is described in Section 8 of the SRTP specification [RFC3711]. 92 The GDOI-SRTP payloads MAY signal use of the EKT protocol as an 93 option for secure dissemination of internally-generated SRTP 94 parameters [I-D.mcgrew-srtp-ekt]. These options, parameters and keys 95 are contained in two GDOI payloads, the "Key Download" (KD) and the 96 "Security Association Traffic Encrypting Key" (SA-TEK) payloads. 98 1.1. Overview of This Document 100 Section 2 of this document presents the GDOI-SRTP payloads. The SRTP 101 SA-TEK payload MAY carry IP address and port information, which has 102 implications for network address translation (NAT). Section 3 gives 103 NAT considerations, Section 4 discusses Security Considerations, and 104 Section 5 lists IANA requirements. 106 1.2. Conformance Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. SRTP Definitions for GDOI Signaling 114 An application can use GDOI to establish security associations for a 115 data security protocol when GDOI is extended with one or more 116 payloads for that data security protocol. Payloads are carried in 117 GDOI message exchanges between a GDOI Group Controller/Key Server 118 (GCKS) and a GDOI member, as shown in Figure 2.0-1. 120 Figure 2.0-1: GDOI and SRTP Interfaces 122 +-------+ 123 | GDOI | 124 | GCKS | 125 +-------+ 126 ^ 127 | 128 V 129 +--------------------------+ 130 | GDOI with SRTP payloads | 131 V V 132 +--------+ +--------+ 133 | GDOI | | GDOI | 134 | Member | | Member | 135 +--------+ +--------+ 136 ^ ^ 137 | | 138 API API 139 | | 140 V V 141 +--------+ SRTP/SRTCP +--------+ 142 | SRTP |---------------->| SRTP | 143 | Source |<----------------|Receiver| 144 +--------+ SRTCP +--------+ 146 This section specifies the SRTP payloads for GDOI key management 147 exchanges. SRTP is an application-layer security protocol that 148 operates above the TCP/IP services (sockets) interface. GDOI also 149 operates above the transport service. SRTP communicates with GDOI 150 using the API shown in Figure 2.0-1. Using the API, SRTP or another 151 application requests that GDOI establish an SRTP cryptographic 152 context (a "security association" in GDOI parlance), which is 153 described in Section 3.2 of the SRTP specification [RFC3711]. The 154 API of Figure 2.0-1 is not considered further in this document, which 155 is concerned with extending the GDOI protocol with a new payload. 156 Using this protocol extension, the GDOI Group Controller/Key Server 157 (GCKS) provides the cryptographic keys, policies and other attributes 158 to SRTP (via the API to a GDOI Member). The GCKS might obtain some 159 of this information through a user console or event database, and it 160 generates some information automatically, such as keying materials. 161 How the GCKS obtains or generates information for the SRTP payload 162 fields is not considered further in this document. 164 Figure 2.0-2: GDOI GCKS Co-located with GDOI Member 166 +--------+ 167 | GDOI | GDOI with +--------+ 168 | GCKS & |<--------------->| GDOI | 169 | Member | SRTP payloads | Member | 170 +--------+ +--------+ 171 ^ ^ 172 | | 173 API API 174 | | 175 V V 176 +--------+ SRTP/SRTCP +--------+ 177 | SRTP |---------------->| SRTP | 178 | Source |<----------------|Receiver| 179 +--------+ SRTCP +--------+ 181 Figure 2.0-1 is a logical diagram. In a physical realization of the 182 system, the GDOI GKCS can either be separate from or co-located with 183 a GDOI Member. When physically co-located with a member, the GCKS 184 can be dedicated to maintaining the group keys for that member's 185 "SRTP Source", and the GCKS can more easily obtain the SRTP-specific 186 information for its payloads across the API. This configuration is 187 shown in Figure 2.0-2. It is often more efficient for the GCKS to be 188 physically co-located in the same computer as the SRTP source of the 189 multicast stream. 191 2.1. GDOI and EKT 193 It is not always possible for GCKS to obtain all the needed SRTP 194 information. In order to establish an SRTP session, an SRTP system 195 requires some internally-generated SRTP information along with keys. 196 This information is the SSRC, the rollover counter (ROC), and the 197 sequence number (SEQ). The ROC and SEQ are used by the SRTP ciphers, 198 and they are used in SRTP replay protection; the SSRC is used in 199 combination with the destination transport address to identify an RTP 200 session [RFC3550] and thus an SRTP session's crypto context. The SEQ 201 and ROC values are generated internally by the SRTP source. When the 202 GCKS is co-located with the GDOI Member and the SRTP source, however, 203 this information can be obtained via the API shown in the above 204 figures. But when the GCKS is physically separate from the SRTP 205 source, GDOI has no over-the-wire protocol for collecting such SSRC, 206 ROC and SEQ information from a multicast source. 208 The EKT protocol offers a solution to the problem of securely 209 providing the SSRC, ROC and the SEQ from the SRTP source to the SRTP 210 receiver, and EKT correctly initializes the SSRC, ROC and SEQ for 211 late joiners to the multicast or following RTP SSRC collision repair 212 [I-D.mcgrew-srtp-ekt]. EKT is RECOMMENDED in this document for 213 transport of an SRTP sender's SSRC, ROC and SEQ to SRTP receivers. 214 When it is possible for the GCKS to correctly initialize the SSRC, 215 ROC and SEQ, however, it is RECOMMENDED that the Key Download also 216 carry the SRTP master key and salt as this will allow the SRTP 217 receiver to begin validating and decrypting packets without waiting 218 for an EKT message to arrive in the SRTCP. EKT is particularly 219 useful when the GCKS cannot reliably initialize the SA-TEK with SSRC, 220 ROC and SEQ fields. When EKT is used, the SA-TEK at minimum signals 221 EKT in the SA-TEK Options field and provides the EKT Key in a Key 222 Download payload. 224 2.2. SRTP SA-TEK Definitions 226 Figure 2.2-1: SRTP SA-TEK 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 231 ! SRC ID Type ! SRC ID Port !SRC ID Date Len! 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 233 ! SRC Identification Data ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 235 ! DST ID Type ! DST ID Port !DST ID Data Len! 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 237 ! DST Identification Data ~ 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 239 ! Options ! SSRC ! Crypto Suite ! 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 241 ! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime! 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 243 ! ROC ~ 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 245 ! SEQ ! MKI Length ! MKI (Optional)~ 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 247 ! EKT Cipher ! EKT SPI Length! EKT SPI ! 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 GDOI provides SA-TEK and Key-Download payload information to an SRTP 251 implementation, which uses this information to initialize the 252 cryptographic context of an SRTP session. An SRTP crypto context is 253 identified by the SSRC and RTP destination transport address as 254 explained in Section 8 of the SRTP specification [RFC3711]. The SRTP 255 rollover counter (ROC) and current sequence number (SEQ) MAY be 256 carried in the SA TEK payload that is shown in Figure 2.2-1. When 257 the ROC and the SEQ are not carried in the SRTP SA-TEK payload, the 258 EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt], in which case the 259 SA-TEK carries EKT information as shown in Figure 2.2-1. In either 260 case, GDOI-SRTP uses the same encryption and authentication 261 transforms for SRTP and SRTCP. 263 The RFC 3547 SA TEK payload has a header and a protocol-specific 264 payload. The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value 265 in the Protocol-ID field of the SA TEK header, which is defined in 266 Section 5.4 of RFC 3547 [RFC3547]. The SA TEK protocol-specific 267 payload for SRTP is given in Figure 2.2-1. The SAT Payload fields 268 are defined as follows: 270 o SRC ID Type (1 octet) -- Value describing the identity information 271 found in the SRC Identification Data field. Defined values are 272 specified by the IPSEC Identification Type section in the IANA 273 isakmpd-registry [ISAKMP-REG]. 275 o SRC ID Port (2 octets) -- Value specifying a port associated with 276 the SRC Identification data. A value of zero means that the SRC 277 ID Port field should be ignored. 279 o SRC ID Data Len (1 octet) -- Value specifying the length of the 280 SRC Identification Data field. 282 o SRC Identification Data (variable length) -- Value as indicated by 283 the SRC ID Type. According to RFC 3547, SRC Identification Data 284 consists of three bytes of zero for multiple-source multicast 285 groups that use a common TEK for all senders. The TEK in an SRTP 286 Key Download payload is an SRTP master key, however, and it is NOT 287 RECOMMENDED that this key be shared for the counter mode and f8 288 ciphers of SRTP. Thus, it is NOT RECOMMENDED that this field 289 consist of three bytes of zero. It SHOULD be ID_FQDN (see the 290 "NAT Considerations" section). 292 o DST ID Type (1 octet) -- Value describing the identity information 293 found in the DST Identification Data field. Defined values are 294 specified by the IPSEC Identification Type section in the IANA 295 isakmpd-registry [ISAKMP-REG]. 297 o DST ID Port (2 octets) -- Value specifying a port associated with 298 the source Id. A value of zero means that the DST ID Port field 299 should be ignored. 301 o DST ID Data Len (1 octet) -- Value specifying the length of the 302 DST Identification Data field. 304 o DST Identification Data (variable length) -- Value, as indicated 305 by the DST ID Type. 307 o Options (1 octet) - Reading from left to right (big-endian), SRTP 308 is unencrypted when bit 0 is set to '1'. SRTP is unauthenticated 309 when bit 1 is set to '1'. SRTCP is unencrypted when bit 2 is set 310 to '1'. EKT is not used when bit 3 is set to '1'. The SSRC, ROC 311 and SEQ are not included and MUST be ignored when bit 4 is set to 312 '1'. 314 o SSRC (2 octets) - Value of the Sender's SSRC when there is a 315 single sender associated with the KEK and TEK and signaled in SA- 316 TEK and Key Download payload. 318 o Crypto Suite (1 octet) -- The set of parameters that defines the 319 SRTP and SRTCP encryption transform, authentication transform, key 320 length, and salt length. The values are defined in the Table 321 2.1-2. Each row in the table defines a suite of parameters. Any 322 parameter can be changed and new parameters added by creating a 323 new Crypto Suite, documenting it in an Internet RFC, and 324 requesting a Suite Value for it from IANA. 326 Table 2.1-2: SRTP Crypto Suites 328 Suite Master Master Max SRTP Max SRTCP 329 Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len 330 ----- ------ ------ ------- -------- -------- ------- 331 0 AES-CM 128 112 2^48 2^31 HMAC-SHA1/80 332 1 AES-CM 128 112 2^48 2^31 HMAC-SHA1/32 333 2 AES-F8 128 112 2^48 2^31 HMAC-SHA1/80 334 3 AES-CM 192 112 2^48 2^31 HMAC-SHA1/80 335 4 AES-CM 192 112 2^48 2^31 HMAC-SHA1/32 336 5 AES-CM 256 112 2^48 2^31 HMAC-SHA1/80 337 6 AES-CM 256 112 2^48 2^31 HMAC-SHA1/32 338 7-127 RESERVED 339 Note: All keylen values are in bits 341 The key values of 192 and 256 are specified in the "BIG AES" 342 Internet Draft document [I-D.mcgrew-srtp-big-aes]. In the vast 343 majority of SRTP applications, the BIG AES values SHOULD NOT be 344 used since they do not increase security as a practical matter but 345 could diminish interoperability, see Section 7 of the Big AES I-D. 347 o Replay Window Size (1 octet) - The size of SRTP Replay Window as 348 specified in Section 3.3.2 of the standard[RFC3711]. 350 o KD Rate (1 octet) - SRTP Key Derivation Rate as specified in 351 Section 4.3.1, second paragraph of the standard [RFC3711]. KD 352 Rate is an integer that is greater than or equal to zero. The 353 modulus of the SRTP "packet index" of an outgoing or incoming SRTP 354 packet is computed modulo the KD Rate in cases where the KD Rate 355 is greater than zero. The reader is referred to Sections 3.3.1 356 and 4.3.1 of the SRTP specification for the definitions of "packet 357 index" and "Key Derivation Rate". 359 o SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an 360 integer N to represent a lifetime of 2^N packets, where N cannot 361 exceed the maximum lifetime as specified by the Crypto Suite. A 362 value of zero signals the SRTP default. 364 o SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an 365 integer N to represent a lifetime of 2^N packets, where N cannot 366 exceed the maximum lifetime as specified by the Crypto Suite. A 367 value of zero signals the SRTP default. 369 o ROC (4 octets) - When bit 4 of Opions is cleared to '0', this 370 field contains the current value of the SRTP ROC. 372 o SEQ (2 octets) - When bit 4 of Options is cleared to '0', this 373 field contains the current SRTP SEQ. 375 o MKI Length (1 octet) - An SRTP Master Key Indicator (MKI) SHALL 376 appear in SRTP packets when this field is nonzero. The MKI field 377 is the length of the SRTP MKI as defined in Section 3 of RFC 3711 378 [RFC3711]. The maximum MKI length is 128 (bytes) though a smaller 379 length of one or two bytes IS RECOMMENDED. 381 o MKI (optional, variable length) - The SRTP MKI is present when the 382 SRTP MKI Length is nonzero. The value of the SRTP MKI Length 383 determines the number of bytes in the width of this field. 385 o EKT Cipher (1 octet) - When bit 3 of the SRTP Options field is 386 cleared to '0', EKT parameters appear in the SA TEK payload. "EKT 387 Cipher" is the cipher and mode used by EKT for the EKT key, which 388 is carried in a GDOI Key Download payload. The following table 389 correlates each EKT Cipher Suite [I-D.mcgrew-srtp-ekt] with a 390 Suite Value. New EKT Cipher Suites MAY be added when documented 391 by an Internet RFC and once IANA assigns a Suite Value to that 392 Cipher Suite. 394 Table 2.1-3: EKT Cipher Suites 396 EKT Cipher Suite 397 Suite Value 398 ------ ----- 399 RESERVED 0 400 AES_128 1 401 AESKW_128 2 402 AESKW_196 3 403 AESKW_256 4 404 RESERVED 5-127 406 o EKT SPI Len (1 octet) - The length of the EKT SPI. 408 o EKT SPI (variable length) - The EKT SPI. 410 2.3. SRTP Key Download 412 The Crypto Suites of Table 2.1-2 define two keys, the SRTP master key 413 and master salt key. These two keys are concatenated with the SRTP 414 master key followed by the SRTP master salt in a Key Download (KD) 415 payload's TEK_ALGORITHM_KEY attribute. 417 When EKT is used, EKT key is carried as a KEK_ALGORITHM_KEY 418 attribute. 420 3. NAT Considerations 422 Transport addresses are carried in the SA-TEK payload and this 423 contradicts recommendations for application-layer signaling through 424 network address translators (NATs) [RFC2663][RFC3235]. The 425 destination IP address and port, however, are multicast addresses and 426 these are not re-written by a NAT. The source address, however, 427 might be re-written on outgoing multicast packets [I-D.wing-behave- 428 multicast]. 430 If the SA TEK SRC ID type of Figure 2.1-1 is an IP address and if 431 there is an outgoing NAT that re-writes the source IP address field 432 of outgoing packets, then there will likely be a discrepancy between 433 the source address in the IP packet and the SRC Identification Data 434 field of Figure 2.1-1. It is therefore RECOMMENDED that SRC ID Type 435 be ID_FQDN [ISAKMP-REG] whenever there is network address translation 436 present on the network of the multicast source. 438 4. Security Considerations 440 The security of GDOI and its payloads is discussed in Section 6 of 441 the GDOI specification [RFC3547]. The security of SRTP and its 442 parameter settings is discussed in Section 9 of the SRTP 443 specification[RFC3711]. There are some additional risks in GDOI and 444 SRTP that are considered here. 446 4.1. No Sharing Counter-Mode Encryption Keys 448 One risk is to the proper establishment of the SRTP SSRC, which is 449 subject to SSRC collisions that might be exploited by an attacker. 450 SRTP specifies that the SSRC is used in the AES counter mode and f8 451 initialization vectors (IV) to prevent counter reuse. RFC 3711 452 states that key management "SHOULD" install a unique SSRC. GDOI 453 relaxes this requirement since SSRCs collide. It is also difficult 454 to support and unchanged RTP module in a "bump-in-the-stack" SRTP 455 configuration. Instead of depending on SSRC uniqueness, IT IS 456 RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master 457 key for each sender. 459 To ensure SRTP master key uniqueness among senders to an SRTP 460 session, SA-TEK SRC Identification Data (Figure 2.1.1) MUST NOT 461 signal a group of senders sharing a key. GDOI specifies a means for 462 sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK 463 is an SRTP master key and this specification RECOMMENDS that a TEK 464 not be shared among SRTP sources. 466 4.2. Enable Distributed Key Management 468 In many cases, SRTP sources are not co-located with a GCKS. This is 469 one possible configuration in a large scale "video pump", for 470 example, that is specialized to a purpose other than key management. 471 If there are geographically-dispersed video-pump sources, there is 472 the risk that the GCKS will be attacked and its ability to 473 disseminate source-unique values to such as the ROC to the multicast 474 group will be impaired. This is one possible attack out of many 475 where a central GCKS can disrupt the entire multicast group of SRTP 476 receivers. This document RECOMMENDS use of EKT to securely 477 distribute the SSRC, ROC and SEQ. GDOI-SRTP payloads signal the EKT 478 Key. 480 Two protocols have more vulnerabilities than one, however, and there 481 are added risks that come from using both GDOI and EKT. A 482 programming bug in GDOI (e.g. signaling zeros in SA-TEK SRC 483 Identification Data), for example, might cause an attack on EKT (e.g. 484 a distributed denial of service attack on a group of EKT receivers). 485 In some cases, a feature that is useful for M:N groups might be risky 486 when used in 1:N groups. For these reasons, the GDOI-SRTP SA-TEK 487 SHOULD explicitly signal each source and provides a source TEK (SRTP 488 Master Key) as well as a KEK (EKT Key). In extraordinary cases such 489 as SSRC collision, the SSRC and SRTP master key MAY come from EKT, 490 but in normal operation only the SEQ and ROC SHOULD be obtained from 491 EKT. 493 4.3. Support Strong Source Authentication 495 Despite the precautions described above, there is always the 496 possibility of "source spoofing" when any member of the group 497 authorized only to receive can impersonate an authorized sender. 498 This is a limitation in symmetric-key authentication in secure 499 groups. To address this problem, SRTP can use TESLA source 500 authentication messaging [RFC4383]. A future revision of this 501 document will consider TESLA signaling. 503 5. IANA Considerations 505 IANA is requested to register "GDOI_PROTO_SRTP with a new value and 506 that additional values be added to the Security Association Traffic 507 Encrypting Key payload definitions, "SA TEK Payload Values" [GDOI- 508 REG], as follows. 510 1. Table 2.1-2: SRTP Crypto Suites. 512 2. Table 2.1-3: EKT Cipher Suites 514 6. Acknowledgements 516 The authors thank David McGrew and Brian Weis for their helpful 517 comments. 519 7. References 521 7.1. Normative References 523 [GDOI-REG] 524 "Group Domain of Interpretation (GDOI) Payloads - per 525 [RFC3547], http://www.iana.org/assignments/gdoi-payloads", 526 2003. 528 [I-D.mcgrew-srtp-big-aes] 529 McGrew, D., "The use of AES-192 and AES-256 in Secure 530 RTP", draft-mcgrew-srtp-big-aes-00 (work in progress), 531 April 2006. 533 [I-D.mcgrew-srtp-ekt] 534 McGrew, D., "Encrypted Key Transport for Secure RTP", 535 draft-mcgrew-srtp-ekt-01 (work in progress), June 2006. 537 [ISAKMP-REG] 538 "FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP 539 Protocol, 540 http://www.iana.org/assignments/isakmp-registry", 541 September 2006. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 547 Multicast: Issues and Architectures", RFC 2627, June 1999. 549 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 550 Group Domain of Interpretation", RFC 3547, July 2003. 552 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 553 Jacobson, "RTP: A Transport Protocol for Real-Time 554 Applications", STD 64, RFC 3550, July 2003. 556 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 557 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 558 RFC 3711, March 2004. 560 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 561 Stream Loss-Tolerant Authentication (TESLA) in the Secure 562 Real-time Transport Protocol (SRTP)", RFC 4383, 563 February 2006. 565 7.2. Informative References 567 [I-D.wing-behave-multicast] 568 Wing, D., "IGMP Proxy Behavior", 569 draft-wing-behave-multicast-00 (work in progress), 570 October 2004. 572 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 573 Security Association and Key Management Protocol 574 (ISAKMP)", RFC 2408, November 1998. 576 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 577 Translator (NAT) Terminology and Considerations", 578 RFC 2663, August 1999. 580 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 581 Application Design Guidelines", RFC 3235, January 2002. 583 Authors' Addresses 585 Mark Baugher 586 Cisco Systems, Inc. 587 800 East Tasman Drive 588 San Jose, CA 95164 589 US 591 Phone: (503) 245-4543 592 Email: mbaugher@cisco.com 594 Adrian-Ken Rueegsegger 595 Bocksteinstrasse 2 596 4583 Muehledorf, 597 Switzerland 599 Phone: +41 32 661 10 88 600 Email: adrian.rueegsegger@students.fhnw.ch 602 Intellectual Property Statement 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Disclaimer of Validity 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 631 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 632 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 633 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 Copyright Statement 638 Copyright (C) The Internet Society (2006). This document is subject 639 to the rights, licenses and restrictions contained in BCP 78, and 640 except as set forth therein, the authors retain all their rights. 642 Acknowledgment 644 Funding for the RFC Editor function is currently provided by the 645 Internet Society.