idnits 2.17.1 draft-ietf-msec-gdoi-srtp-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 886. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (December 3, 2007) is 5986 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) -- 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-03 -- 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) ** Obsolete normative reference: RFC 2409 (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: 5 errors (**), 0 flaws (~~), 4 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 Intended status: Standards Track A. Rueegsegger 5 Expires: June 5, 2008 secunet SwissIT AG 6 S. Rowles 7 Cisco Systems, Inc. 8 December 3, 2007 10 GDOI Key Establishment for the SRTP Data Security Protocol 11 draft-ietf-msec-gdoi-srtp-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 5, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Secure Real-time Transport Protocol (SRTP) protects unicast and 45 multicast RTP packets. Multicast receivers of SRTP session data 46 therefore share an SRTP master key for message authentication and 47 decryption. This document describes how to establish a shared, 48 "group key" for an SRTP session using RFC 3547, the Group Domain of 49 Interpretation (GDOI) and RFC 2408, the Internet Security Association 50 and Key Management Protocol. This document extends GDOI for SRTP 51 group key establishment. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Overview of This Document . . . . . . . . . . . . . . . . 3 57 1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3 58 2. GDOI Signaling of an SRTP Crypto Context . . . . . . . . . . . 4 59 2.1. GDOI Signaling and SDP Signaling . . . . . . . . . . . . . 6 60 2.2. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3. GDOI Exchanges for SRTP . . . . . . . . . . . . . . . . . 8 62 2.4. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 10 63 2.5. EKT SA-TEK Definitions . . . . . . . . . . . . . . . . . . 14 64 2.6. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 15 65 3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 16 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 17 68 4.2. Enable Distributed Key Management . . . . . . . . . . . . 17 69 4.3. Support Strong Source Authentication . . . . . . . . . . . 18 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 76 Intellectual Property and Copyright Statements . . . . . . . . . . 24 78 1. Introduction 80 The Group Domain of Interpretation (GDOI) is an authenticated key 81 establishment protocol for groups, which is specified by RFC 3547 82 [RFC3547]. GDOI is based upon ISAKMP, the Internet Security 83 Association and Key Management Protocol [RFC2408]. GDOI extends 84 ISAKMP for group key management whereby a cryptographic key is shared 85 among multiple receivers and optionally multiple senders. GDOI uses 86 unicast (ISAKMP) as well as multicast key establishment method and 87 supports member revocation algorithms, such as the "key hierarchy" 88 algorithm of RFC 2627 [RFC2627]. GDOI preserves the ISAKMP design, 89 which supports new data security protocols through documented 90 procedures, but it currently supports only one data security 91 protocol, IPsec. 93 This document extends GDOI to a new data security protocol, the 94 Secure Real-time Transport Protocol (SRTP) as specified by RFC 3711 95 [RFC3711]. SRTP extensions to GDOI use two new GDOI payloads. The 96 GDOI-SRTP payload definitions apply GDOI key establishment procedures 97 to groups of SRTP receivers in accordance with Section 5.4.2 of the 98 GDOI protocol specification [RFC3547]. The SRTP payloads carry keys, 99 parameters, and other values needed for an SRTP session's 100 "cryptographic context", which is described in Section 8 of the SRTP 101 specification [RFC3711]. In addition to signaling SRTP, GDOI-SRTP 102 payloads MAY signal use of the Encrypted Key Transport (EKT) protocol 103 as an option [I-D.mcgrew-srtp-ekt]. These options, parameters and 104 keys are defined in two GDOI payloads, the "Security Association 105 Traffic Encrypting Key" (SA-TEK) payloads for SRTP (SRTP SA-TEK) and 106 EKT (EKT SA-TEK). 108 1.1. Overview of This Document 110 Section 2 of this document presents the GDOI-SRTP payloads. The SRTP 111 SA-TEK payload MAY carry IP address and port information, which have 112 implications for network address translation (NAT). Section 3 gives 113 NAT considerations, Section 4 discusses Security Considerations, and 114 Section 5 lists IANA requirements. 116 1.2. Conformance Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. GDOI Signaling of an SRTP Crypto Context 124 A service can use GDOI to establish keys (security associations) for 125 a data security protocol provided that GDOI is extended with one or 126 more payload definitions for that data security protocol. For GDOI, 127 a "data security protocol" is any protocol that uses the services of 128 GDOI. By contrast, TLS key establishment is packaged with the TLS 129 data-security protocol. This memo will review the GDOI model and how 130 the key management correlates to the traffic for which it provides 131 keys. GDOI follows the ISAKMP model in which key management and data 132 security may use separate transport addresses and underlying 133 transport protocols, typically UDP or TCP. By default, GDOI uses UDP 134 to negotiate an IKE phase 1 security association between a GDOI Group 135 Controller/Key Server (GCKS) and group member; the IKE phase 1 136 protects an exchange to establish a security association on behalf of 137 an application security protocol. In SRTP, a "security association" 138 is called a "cryptographic context", and this is the application- 139 specific information carried in GDOI payloads between the GCKS and a 140 GDOI member. This section defines these SRTP payloads for GDOI. 142 Figure 2.0-1: Member and SRTP Interfaces in a Central GCKS 143 Configuration 145 +-------+ 146 | GDOI | 147 | GCKS | 148 +-------+ 149 ^ 150 | 151 V 152 +--------------------------+ 153 | GDOI with SRTP payloads | 154 V V 155 +----------+ +----------+ 156 |+--------+| |+--------+| 157 || GDOI || || GDOI || 158 || Member || || Member || 159 |+--------+| |+--------+| 160 | ^ | | ^ 161 | | | | | | 162 | API | | API | 163 | | | | | | 164 | V | | V | 165 |+--------+| SRTP/SRTCP |+--------+| 166 || SRTP |---------------->| SRTP || 167 || Source |<----------------|Receiver|| 168 |+--------+| SRTCP |+--------+| 169 +----------+ +----------+ 170 MEMBERi MEMBERj 172 This section gives the SRTP payloads for GDOI key management 173 exchanges. SRTP is an application-layer security protocol that 174 operates above the transport layer. GDOI also operates above the 175 transport service. SRTP communicates with GDOI using the API shown 176 in Figure 2.0-1. SRTP or another application uses the API to request 177 that GDOI establish an SRTP cryptographic context (i.e. a GDOI 178 "security association"), which is described in Section 3.2 of the 179 SRTP specification [RFC3711]. The API of Figure 2.0-1 is not 180 considered further in this document, which is concerned solely with 181 extending the GDOI protocol with new payloads for SRTP. Using this 182 protocol extension, the GDOI Group Controller/Key Server (GCKS) can 183 provide the cryptographic keys, cryptographic parameters and session 184 parameters to SRTP (via the API to a GDOI Member) in accordance with 185 pre-configured group policy regarding which parameters are acceptable 186 and which are not. The GCKS might obtain policy and some SRTP 187 crypto-context information through a user console or event database. 188 The GCKS generates some information automatically, such as keying 189 materials. How the GCKS obtains or generates policy information for 190 the SRTP payload fields is specific to an implementation and not 191 considered further in this document. 193 Figure 2.0-2: A Distributed GCKS Configuration 194 +----------+ 195 +----------+ |+--------+| 196 +|+--------+| GDOI with || GDOI || 197 ||| GCKS & |<--------------->| GCKS & || 198 ||| Member || SRTP payloads|| Member || 199 ||+--------+| |+--------+| 200 || ^ | | ^ | 201 || | | | | | 202 || API | | API | 203 || | | | | | 204 || V | | V | 205 ||+--------+| SRTP/SRTCP |+--------+| 206 ||| SRTP |---------------->| SRTP || 207 ||| Source |<----------------|Receiver|| 208 ||+--------+| SRTCP |+--------+| 209 || MEMBERi | | MEMBERj | 210 |+----------+ +----------+ 211 | MEMBERk | 212 +----------+ 214 In the Distributed GCKS, each group member is physically co-located 215 with its own GKCS. This configuration is labeled a "Distributed 216 GCKS" in Figure 2.0-2 in that the function of establishing the key 217 for a particular sender to the group is distributed among each such 218 sender to the group. Whereas a centralized GCKS establishes keys for 219 all senders to a group (Figure 2.0-1), a distributed GCKS establishes 220 keys for a single sender to a group. A distributed GCKS, therefore, 221 is co-located with each sender to a group and is dedicated to 222 maintaining the group keys for that member's "SRTP Source". In this 223 configuration, the GCKS can more easily obtain the SRTP-specific 224 information for its payload across an API. The distinction between 225 Figures 2.0-1 and 2.0-2 are important because the SRTP data security 226 protocol has tight coupling with its key management in the use of the 227 SSRC, SEQ,and ROC parameters as discussed in the next section. 229 2.1. GDOI Signaling and SDP Signaling 231 SDP is a standard means to signal SRTP sessions when the SDP (RFC 232 4566) transport identifier for a media session is "SAVP." Some of 233 the information contained in an SDP message is identical to the 234 information conveyed in an GDOI-SRTP message such as the transport 235 addresses. This is unavoidable since both signaling messages need to 236 identify and describe the SRTP session. There is generally more 237 information in the GDOI-SRTP message than in the SDP such as the 238 keying material for the session, and it is possible that the two 239 messages may be linked. For example, an SDP message could be used to 240 trigger the initiation of the GDOI exchange for the SRTP session. 241 For example, an RFC 4566 "k=" field can designate the URI of a GDOI 242 key server in the SDP message. In this case, k=http:// 243 GCKS.example.com would direct the receiver of the SDP message to 244 obtain the keys for the SRTP session. Such usage is Informative 245 according to this document, not Normative, and further consideration 246 of SDP signaling is beyond the scope of this document. 248 2.2. GDOI and EKT 250 When the Group Controller/Key Server (GCKS) is centralized as a 251 third-party device, it is not co-located with the SRTP source, and it 252 is not always possible for the GCKS to get access to important SRTP 253 keystream parameters, which are the SSRC, the Rollover Counter (ROC) 254 and current SRTP sequence number (SEQ). This information is 255 generated internally by the SRTP source and used in the SRTP ciphers 256 and SRTP replay protection; the SSRC is used in combination with the 257 destination transport address to identify an RTP session [RFC3550] 258 and thus identify an SRTP session's crypto context. When the GCKS is 259 co-located with the SRTP source, this information can be obtained via 260 the API shown in the above figures. Such an API can be defined in an 261 implementation. But when the GCKS is physically separate from the 262 SRTP source, GDOI has no over-the-wire protocol for collecting the 263 SSRC, ROC and SEQ information from the source. The Encrypted Key 264 Transport (EKT) protocol solves this problem. 266 EKT extends SRTCP to securely provide the SSRC, ROC and the SEQ from 267 the SRTP source to the SRTP receiver, and EKT correctly initializes 268 the SSRC, ROC and SEQ for late joiners to the multicast group or 269 following RTP SSRC collision repair [I-D.mcgrew-srtp-ekt]. In a 270 centralized GCKS configuration (Fig 2.0-1), EKT is RECOMMENDED in 271 this document for transporting an SRTP sender's SSRC, ROC and SEQ to 272 SRTP receivers. In a distributed GCKS configuration, it is possible 273 for the GCKS to correctly initialize the SSRC, ROC and SEQ by 274 obtaining these values through an API with the GDOI member; in this 275 case, it is RECOMMENDED that GDOI peform this function. When the 276 GCKS provides current SSRC, ROC and SEQ values, these are carried in 277 GDOI-SRTP SA-TEK payload and the GDOI Key Download payload carries 278 the SRTP master key and salt. When EKT is used instead, the GDOI Key 279 Download payload carries the EKT key. 281 Whether or not to use EKT or to provide SRTP SSRC, ROC and SEQ 282 parameters via GDOI SHALL be a configurable option in GDOI-SRTP. 283 When the EKT option is not used, the SRTP receiver can begin 284 validating and decrypting packets without waiting for an EKT message 285 to arrive in the SRTCP session. EKT is needed, however, when the 286 GCKS cannot reliably initialize the SA-TEK with SSRC, ROC and SEQ 287 fields. 289 When EKT is used, there are two SA-TEK payloads. First, there is an 290 SRTP SA-TEK payload that describes an SRTP master key and salt; the 291 SRTP SA-TEK is always present. Second, there is an EKT SA-TEK 292 payload that describes an EKT key. In either case, there is exactly 293 one Key Download payload sent in a GDOI-SRTP exchange. If EKT is 294 signaled by the presence of an EKT SA-TEK, then the Key Download 295 payload SHALL carry an EKT key. If EKT is not signaled, then the KEY 296 Download payload SHALL carry an SRTP master key and master salt. In 297 either case, there MUST be exactly one Key Download payload when 298 signaling SRTP in GDOI. 300 2.3. GDOI Exchanges for SRTP 302 As mentioned above, GDOI exchanges for SRTP are protected by a "phase 303 1 security association", which is an IKE phase 1 connection in which 304 the GCKS and the member identify and authenticate each other. For 305 the IKE phase 1, RFC 3547 allows any defined IKE identity such as IP 306 address, fully-qualified domain name or an opaque byte string that 307 identifies a pre-shared key[ISAKMP-REG]. Also, any of the IKE 308 authentication methods MAY be used including pre-shared key, public- 309 key encryption, and digital signatures. The IKE phase 1 connection 310 is established using a six-message "Main Mode" exchange if identity 311 protection is desired or a 3-message "Aggressive Mode" if identity 312 protection is not needed [RFC2409]. With identity protection, a 313 passive attack will not reveal the identities that the initiator or 314 responder use to authenticate themselves. 316 In GDOI, the initiator is usually the group member and the responder 317 is usually the Group Controller/Key Server. This is true in both the 318 phase 1 and phase 2 exchanges. The phase 2 exchange uses a 4-message 319 exchange as defined in RFC 3547, Section 3 [RFC3547] and is 320 reproduced below for the convenience of the reader. 322 Figure 2.3-1: GDOI Phase 2 Exchange, from Section 3.2 [RFC3547] 324 Initiator (Member) Responder (GCKS) 325 ------------------ ---------------- 326 HDR*, HASH(1), Ni, ID --> 327 <-- HDR*, HASH(2), Nr, SA 328 HDR*, HASH(3) [,KE_I] --> 329 [,CERT] [,POP_I] 330 <-- HDR*, HASH(4),[KE_R,][SEQ,] 331 KD [,CERT] [,POP_R] 333 * Protected by the Phase 1 SA, encryption occurs after HDR 335 When sent to the GDOI port, the message header (HDR) of Fig. 2.3-1 336 identifies the phase 2 exchange, i.e. by the ISAKMP message id (M-ID) 337 field of HDR. Everything else is encrypted using the phase 1 338 encryption key and authenticated in the HASH payloads that appear in 339 each message. A nonce and an ID are sent in the first message from 340 the member to the GCKS, which responds by downloading the 341 cryptographic parameters, session parameters, authentication policy 342 and other information that the member needs to identify and 343 authenticate itself to the GCKS. The GCKS provides these parameters 344 and policy information in the Security-Association (SA) payload of 345 the second message along with its nonce, Nr. As described in the 346 previous section of this document, how these policies and parameters 347 are defined is out of scope for this document. The successful GDOI- 348 SRTP exchange establishes an SRTP cryptographic context (i.e. a 349 security association among SRTP endpoints). 351 The third message of Fig 2.3-1 is from the member to the GCKS. If 352 perfect forward secrecy is desired, Diffie-Hellman public value are 353 exchanged in the Key-Exchange (KE) payloads (KE_I and KE_R), which 354 are optional. If additional authorization and authentication are 355 desired beyond the IKE Phase 1, then a digital certificate can be 356 passed in a Cerficate (CERT) payload with an optional proof-of- 357 possession exchange to prove possession of the corresponding private 358 key (POP_I and POP_R). 360 The fourth and final message concludes a successful GDOI phase 2 361 exchange by passing a Key-Download (KD) payload. Any KE, CERT or POP 362 exchanges are completed in the final message. Another optional field 363 is SEQ, which is the sequence number associated with messages that 364 are sent (pushed) from the GCKS to the member. For pushed messages, 365 the SA payload will include a GDOI key-encrypting key (KEK) 366 definition in an SA-KEK payload. A GDOI group will not use pushed 367 messages if it does not need to perform key update of the SRTP Master 368 Key (SA-TEK) or member revocation. Thus, an SA-KEK is OPTIONAL 369 whereas one or two SA-TEKs are REQUIRED by this document; these are 370 the SRTP SA-TEK and the optional EKT SA-TEK. The SA-KEK and SA-TEK 371 are part of the SA payload shown in Figure 2.3-1. 373 2.4. SRTP SA-TEK Definitions 375 The RFC 3547 SA TEK payload has a header and a protocol-specific 376 payload. The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value 377 (assigned by IANA) in the Protocol-ID field of the SA TEK header, 378 which is defined in Section 5.4 of RFC 3547 [RFC3547]. The SA TEK 379 protocol-specific payload for SRTP is given in Figure 2.3-1. The SAT 380 Payload fields are shown in Figure 2.4-1. 382 Figure 2.4-1: SRTP SA-TEK 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 387 ! SRC ID Type ! SRC ID Port !SRC ID Data Len! 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 389 ! SRC Identification Data ~ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 391 ! DST ID Type ! DST ID Port !DST ID Data Len! 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 393 ! DST Identification Data ~ 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 395 ! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime! 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 397 ! Options ! Crypto Suite ! SPI ! Attributes ~ 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 400 Attribute Class Value Type 401 --------------- ----- ---- 402 RESERVED 0 403 SSRC 1 B 404 ROC 2 B 405 SEQ 3 B 406 MKI 4 V 408 The Group Controller/Key Server (GCKS) provides SA-TEK and Key- 409 Download payload information to an SRTP implementation through the 410 GDOI member to SRTP, which uses this information to initialize the 411 cryptographic context of an SRTP session. An SRTP crypto context is 412 identified by the SSRC and RTP destination transport address as 413 explained in Section 8 of the SRTP specification [RFC3711]. The RTP 414 destination address is identified in the SA-TEK, which is shown in 415 Figure 2.4-1. The "DST ID Type" defines the type of DST 416 Identification data, which is an IP address or a fully-qualified 417 domain name that resolves to one. The destination port is also 418 carried in the DST ID Port, also shown in Figure 2.4-1 following the 419 similar definitions for the source. 421 Replay window, key-derivation (KD) rate, SRTP and SRTCP lifetimes are 422 the crypto context parameters for the particular SRTP session. Also 423 shown in Figure 2.4-1 is the options field, that declares values for 424 boolean SRTP configuration parameters and also whether EKT is to be 425 used or not. Crypto Suite identifies the SRTP encryption and 426 authentication transforms. GDOI-SRTP uses the same encryption and 427 authentication transforms for SRTP and SRTCP. Finally, the SPI is 428 the "security parameter index", which identifies the particular 429 security association (SRTP crypto context) by a 8-bit number, a 430 positive integer. 432 The Attributes payloads are optional. The attributes must follow the 433 format defined in ISAKMP [RFC3547] section 3.3. In the table, 434 attributes that are defined as TV are marked as Basic (B); attributes 435 that are defined as TLV are marked as Variable (V). The SSRC, 436 rollover counter (ROC) and current sequence number (SEQ) MAY be 437 carried in the SA TEK payload that is shown in Figure 2.4-1. When 438 the SSRC, ROC and the SEQ are not carried in the SRTP SA-TEK payload, 439 the EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt]. 441 Each of the fields of Figure 2.4-1 is defined as follows. 443 o SRC ID Type (1 octet) -- Value describing the identity information 444 found in the SRC Identification Data field. Defined values are 445 specified by the IPSEC Identification Type section in the IANA 446 isakmp-registry [ISAKMP-REG]. 448 o SRC ID Port (2 octets) -- Value specifying a port associated with 449 the SRC Identification data. A value of zero means that the SRC 450 ID Port field should be ignored. 452 o SRC ID Data Len (1 octet) -- Value specifying the length of the 453 SRC Identification Data field. 455 o SRC Identification Data (variable length) -- Value as indicated by 456 the SRC ID Type. According to RFC 3547, SRC Identification Data 457 consists of three bytes of zero for multiple-source multicast 458 groups that use a common TEK for all senders. The TEK in an SRTP 459 Key Download payload is an SRTP master key, however, and it is NOT 460 RECOMMENDED that this key be shared for the counter mode and f8 461 ciphers of SRTP. Thus, it is NOT RECOMMENDED that this field 462 consist of three bytes of zero, because that would cause the TEK 463 to be shared. It SHOULD be ID_FQDN (see the "NAT Considerations" 464 section). 466 o DST ID Type (1 octet) -- Value describing the identity information 467 found in the DST Identification Data field. Defined values are 468 specified by the IPSEC Identification Type section in the IANA 469 isakmpd-registry [ISAKMP-REG]. 471 o DST ID Port (2 octets) -- Value specifying a port associated with 472 the source Id. A value of zero means that the DST ID Port field 473 should be ignored. 475 o DST ID Data Len (1 octet) -- Value specifying the length of the 476 DST Identification Data field. 478 o DST Identification Data (variable length) -- Value, as indicated 479 by the DST ID Type. 481 o Replay Window Size (1 octet) - The suggested size of the SRTP 482 Replay Window as specified in Section 3.3.2 of the SRTP standard 483 [RFC3711]. 485 o KD Rate (1 octet) - SRTP Key Derivation Rate as specified in 486 Section 4.3.1, second paragraph of the standard [RFC3711]. KD 487 Rate is an integer that is greater than or equal to zero. The 488 SRTP "packet index" of an outgoing or incoming SRTP packet is 489 computed modulo the KD Rate in cases where the KD Rate is greater 490 than zero. The reader is referred to Sections 3.3.1 and 4.3.1 of 491 the SRTP specification for the definitions of "packet index" and 492 "Key Derivation Rate". 494 o SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an 495 integer N to represent a lifetime of 2^N packets, where N cannot 496 exceed the maximum lifetime as specified by the Crypto Suite. A 497 value of zero signals the SRTP default (N=48). It is recommended 498 that SRTP Lifetime be set to the default. 500 o SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an 501 integer N to represent a lifetime of 2^N packets, where N cannot 502 exceed the maximum lifetime as specified by the Crypto Suite. A 503 value of zero signals the SRTP default (N=31). It is recommended 504 that SRTCP Lifetime be set to the default. 506 o Options (1 octet) - Reading from left to right (big-endian), SRTP 507 is unencrypted when bit 0 is set to '1'. SRTP is unauthenticated 508 when bit 1 is set to '1'. SRTCP is unencrypted when bit 2 is set 509 to '1'. The SSRC, ROC and SEQ are not included and MUST be 510 ignored when bit 3 is set to '1'. 512 o SSRC (2 octets) - Value of the Sender's SSRC when there is a 513 single sender associated with the KEK and TEK signaled in the SA- 514 TEK and Key Download payload. 516 o Crypto Suite (2 octets) -- The set of parameters that defines the 517 SRTP and SRTCP encryption transform, authentication transform, key 518 length, and salt length. The values are defined in the Table 519 2.4-2. Each row in the table defines a suite of parameters. Any 520 parameter can be changed and new parameters added by creating a 521 new Crypto Suite, documenting it in an Internet RFC, and 522 requesting a Suite Value for it from IANA. The lifetimes 523 mentioned in the crypto-suites are superseded by the lifetimes 524 passed in the fields mentioned above. 526 Table 2.4-2: SRTP Crypto Suites 528 Suite Master Master Max SRTP Max SRTCP 529 Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len 530 ----- ------ ------ ------- -------- -------- ------- 531 0 AES-CM 128 112 2^48 2^31 HMAC-SHA1/80 532 1 AES-CM 128 112 2^48 2^31 HMAC-SHA1/32 533 2 AES-F8 128 112 2^48 2^31 HMAC-SHA1/80 534 3 AES-CM 192 112 2^48 2^31 HMAC-SHA1/80 535 4 AES-CM 192 112 2^48 2^31 HMAC-SHA1/32 536 5 AES-CM 256 112 2^48 2^31 HMAC-SHA1/80 537 6 AES-CM 256 112 2^48 2^31 HMAC-SHA1/32 538 7-127 RESERVED 539 Note: All keylen values are in bits 541 The key values of 192 and 256 are specified in the "BIG AES" 542 Internet Draft document [I-D.mcgrew-srtp-big-aes]. In the vast 543 majority of SRTP applications, the BIG AES values SHOULD NOT be 544 used since they do not increase security as a practical matter but 545 could diminish interoperability, see Section 7 of the Big AES I-D. 547 o SPI (2 octets) - The value of the security parameter index that 548 identifies this security association between the GCKS and the 549 group member. 551 o SSRC (1 octet) - The value of the SRTP SSRC; this attribute MUST 552 be present when bit 3 of Options is cleared ('0') but MUST be 553 ignored otherwise. 555 o ROC (4 octets) - The current value of the SRTP rollover counter 556 (ROC); this attribute value MUST be present when bit 3 of Options 557 is cleared ('1') but MUST be ignored otherwise. 559 o SEQ (2 octets) - The current value of the SRTP sequence number; 560 this attribute MUST be present when bit 3 of Options is cleared 561 ('0') but MUST be ignored otherwise. 563 o MKI Length(variable) - An SRTP Master Key Indicator (MKI) SHALL 564 appear in SRTP packets when this attribute is present. As defined 565 in Section 3 of RFC 3711 [RFC3711], the maximum MKI length is 128 566 (bytes) though a smaller length of one or two bytes IS 567 RECOMMENDED. The MKI Length attribute MUST be present when an MKI 568 attribute is given. It is RECOMMENDED that the MKI Length be zero 569 (i.e., the MKI is not being used) unless there is a compelling 570 reason to change SRTP master keys for a particular source. 572 2.5. EKT SA-TEK Definitions 574 EKT is an abbreviation for "encrypted key transport", which carries 575 an SRTP master key, SEQ and ROC in an SRTCP packet. As described 576 above, these values are generated internally to SRTP, and a central 577 GCKS typically cannot obtain these values and the SSRC when it has no 578 interface to the SRTP sender. In this case, EKT is RECOMMENDED as a 579 means to correctly initialize an SRTP receiver with the SSRC, SEQ, 580 ROC and SRTP master key. In this case, GDOI-SRTP serves to 581 initialize the EKT system in a GDOI member by providing EKT 582 parameters and a key called the "EKT key", which is used to encrypt 583 the SRTP master key in the SRTCP packet. Thus, the security 584 association between the GCKS and GDOI member establishes and 585 maintains an EKT key. 587 The EKT identifying information and parameters are shown in Figure 588 2.5-1. 590 Figure 2.5-1: EKT-TEK 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 595 ! DST ID Type ! DST ID Port !DST ID Data Len! 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 597 ! DST Identification Data ~ 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 599 ! EKT Cipher ! SPI ! 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Each of the fields of Figure 2.5-1 is defined as follows. 604 o DST ID Type (1 octet) -- Value describing the identity information 605 found in the DST Identification Data field. Defined values are 606 specified by the IPSEC Identification Type section in the IANA 607 isakmpd-registry [ISAKMP-REG]. 609 o DST ID Port (2 octets) -- Value specifying a port associated with 610 the source Id. A value of zero means that the DST ID Port field 611 should be ignored. 613 o DST ID Data Len (1 octet) -- Value specifying the length of the 614 DST Identification Data field. 616 o DST Identification Data (variable length) -- Value, as indicated 617 by the DST ID Type. 619 o EKT Cipher (1 octet) - Value specifying the cipher and mode used 620 by EKT for the EKT key, which is carried in a GDOI Key Download 621 payload. The following table correlates each EKT Cipher Suite 622 [I-D.mcgrew-srtp-ekt] with a Suite Value. New EKT Cipher Suites 623 MAY be added when documented by an Internet RFC and once IANA 624 assigns a Suite Value to that Cipher Suite. 626 Table 2.5-2: EKT Cipher Suites 628 EKT Cipher Suite 629 Suite Value 630 ------ ----- 631 RESERVED 0 632 AES_128 1 633 AESKW_128 2 634 AESKW_196 3 635 AESKW_256 4 636 RESERVED 5-127 638 o EKT SPI (1 octet) - The EKT security parameter index, which 639 identifies the EKT security association between the GCKS and the 640 GDOI member. 642 2.6. SRTP Key Download 644 The SRTP SA-TEK Crypto Suite of Table 2.4-2 defines both the SRTP 645 master key and master salt. These two values are concatenated, with 646 the SRTP master key being followed by the SRTP master salt, in a Key 647 Download (KD) payload's TEK_ALGORITHM_KEY attribute. 649 When EKT is used, there is no KD payload corresponding to the SRTP 650 SA-TEK. Instead, the KD payload carries the EKT key as defined by 651 the EKT SA-TEK EKT Cipher. 653 3. NAT Considerations 655 Transport addresses are carried in the SA-TEK payloads and this 656 contradicts recommendations for application-layer signaling through 657 network address translators (NATs) [RFC2663][RFC3235]. The SA-TEK 658 destination IP address and port, however, are multicast addresses 659 which are not re-written by a NAT. The source address, however, 660 might be re-written on outgoing multicast packets 661 [I-D.wing-behave-multicast]. 663 If the SA TEK SRC ID type of Figure 2.4-1 is an IP address and if 664 there is an outgoing NAT that re-writes the source IP address field 665 of outgoing packets, then there will likely be a discrepancy between 666 the source address in the IP packet and the SRC Identification Data 667 field of Figure 2.4-1. It is therefore RECOMMENDED that SRC ID Type 668 be ID_FQDN [ISAKMP-REG] whenever there is network address translation 669 present on the network of the multicast source. 671 4. Security Considerations 673 The security of GDOI and its payloads is discussed in Section 6 of 674 the GDOI specification [RFC3547]. The security of SRTP and its 675 parameter settings is discussed in Section 9 of the SRTP 676 specification[RFC3711]. There are some additional risks in GDOI and 677 SRTP that are considered here. 679 4.1. No Sharing Counter-Mode Encryption Keys 681 One risk is the proper establishment of the SRTP SSRC, which is 682 subject to SSRC collisions that might be exploited by an attacker. 683 SRTP specifies that the SSRC is used in the AES counter mode and f8 684 initialization vectors (IV) to prevent counter reuse. RFC 3711 685 states that key management "SHOULD" install a unique SSRC. GDOI 686 relaxes this requirement since SSRCs collide. It is also difficult 687 to support an unchanged RTP module in a "bump-in-the-stack" SRTP 688 configuration. Instead of depending on SSRC uniqueness, IT IS 689 RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master 690 key for each sender. 692 To ensure SRTP master key uniqueness among senders to an SRTP 693 session, SA-TEK SRC Identification Data (Figure 2.4.1) MUST NOT 694 signal a group of senders sharing a key. GDOI specifies a means for 695 sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK 696 is an SRTP master key and this specification RECOMMENDS that a TEK 697 SHOULD NOT be shared among SRTP sources. 699 4.2. Enable Distributed Key Management 701 In many cases, SRTP sources are not co-located with a GCKS. This is 702 one possible configuration in a large scale "video pump", for 703 example, that is specialized to a purpose other than key management. 704 If there are geographically-dispersed video-pump sources, there is 705 the risk that the GCKS will be attacked and its ability to 706 disseminate source-unique values to such as the ROC to the multicast 707 group will be impaired. This is one possible attack out of many 708 where a central GCKS can disrupt the entire multicast group of SRTP 709 receivers. This document RECOMMENDS the use of EKT to securely 710 distribute the SSRC, ROC and SEQ. GDOI-SRTP payloads signal the EKT 711 Key. 713 Two protocols have more vulnerabilities than one, however, and there 714 are added risks that come from using both GDOI and EKT. A 715 programming bug in GDOI (e.g. signaling zeros in SA-TEK SRC 716 Identification Data), for example, might cause an attack on EKT (e.g. 717 a distributed denial of service attack on a group of EKT receivers). 718 In some cases, a feature that is useful for M:N groups might be risky 719 when used in 1:N groups. For these reasons, the GDOI-SRTP SA-TEK 720 SHOULD explicitly signal each source and provides a source TEK (SRTP 721 Master Key) as well as a KEK (EKT Key). In extraordinary cases such 722 as SSRC collision, the SSRC and SRTP master key MAY come from EKT, 723 but in normal operation only the SEQ and ROC SHOULD be obtained from 724 EKT. 726 4.3. Support Strong Source Authentication 728 Despite the precautions described above, there is always the 729 possibility of "source spoofing" when any member of the group 730 authorized only to receive can impersonate an authorized sender. 731 This is a limitation in symmetric-key authentication in secure 732 groups. To address this problem, SRTP can use TESLA source 733 authentication messaging [RFC4383]. A future revision of this 734 document will consider TESLA signaling. 736 5. IANA Considerations 738 IANA is requested to register "GDOI_PROTO_SRTP" with a new value and 739 that additional values be added to the Security Association Traffic 740 Encrypting Key payload definitions, "SA TEK Payload Values" 741 [GDOI-REG], as follows. 743 1. Table 2.1-2: SRTP Crypto Suites. 745 2. Table 2.1-3: EKT Cipher Suites 747 6. Acknowledgements 749 The authors thank David McGrew, Brian Weis and Liu Ya for their 750 helpful comments. 752 7. References 754 7.1. Normative References 756 [GDOI-REG] 757 "Group Domain of Interpretation (GDOI) Payloads - per 758 [RFC3547], http://www.iana.org/assignments/gdoi-payloads", 759 2003. 761 [I-D.mcgrew-srtp-big-aes] 762 McGrew, D., "The use of AES-192 and AES-256 in Secure 763 RTP", draft-mcgrew-srtp-big-aes-00 (work in progress), 764 April 2006. 766 [I-D.mcgrew-srtp-ekt] 767 McGrew, D., "Encrypted Key Transport for Secure RTP", 768 draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. 770 [ISAKMP-REG] 771 "FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP 772 Protocol, 773 http://www.iana.org/assignments/isakmp-registry", 774 September 2006. 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, March 1997. 779 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 780 (IKE)", RFC 2409, November 1998. 782 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 783 Multicast: Issues and Architectures", RFC 2627, June 1999. 785 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 786 Group Domain of Interpretation", RFC 3547, July 2003. 788 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 789 Jacobson, "RTP: A Transport Protocol for Real-Time 790 Applications", STD 64, RFC 3550, July 2003. 792 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 793 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 794 RFC 3711, March 2004. 796 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 797 Stream Loss-Tolerant Authentication (TESLA) in the Secure 798 Real-time Transport Protocol (SRTP)", RFC 4383, 799 February 2006. 801 7.2. Informative References 803 [I-D.wing-behave-multicast] 804 Wing, D., "IGMP Proxy Behavior", 805 draft-wing-behave-multicast-00 (work in progress), 806 October 2004. 808 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 809 Security Association and Key Management Protocol 810 (ISAKMP)", RFC 2408, November 1998. 812 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 813 Translator (NAT) Terminology and Considerations", 814 RFC 2663, August 1999. 816 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 817 Application Design Guidelines", RFC 3235, January 2002. 819 Authors' Addresses 821 Mark Baugher 822 Cisco Systems, Inc. 823 800 East Tasman Drive 824 San Jose, CA 95164 825 US 827 Phone: (503) 245-4543 828 Email: mbaugher@cisco.com 830 Adrian-Ken Rueegsegger 831 secunet SwissIT AG 832 Hauptbahnhofstrasse 12 833 4501 Solothurn, 834 Switzerland 836 Phone: +41 32 625 80 40 837 Email: rueegsegger@swiss-it.ch 839 Sheela Rowles 840 Cisco Systems, Inc. 841 1700 West Tasman Drive 842 San Jose, CA 95134-1706 843 US 845 Phone: (408) 527-7677 846 Email: srowles@cisco.com 848 Full Copyright Statement 850 Copyright (C) The IETF Trust (2007). 852 This document is subject to the rights, licenses and restrictions 853 contained in BCP 78, and except as set forth therein, the authors 854 retain all their rights. 856 This document and the information contained herein are provided on an 857 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 858 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 859 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 860 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 861 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 862 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 864 Intellectual Property 866 The IETF takes no position regarding the validity or scope of any 867 Intellectual Property Rights or other rights that might be claimed to 868 pertain to the implementation or use of the technology described in 869 this document or the extent to which any license under such rights 870 might or might not be available; nor does it represent that it has 871 made any independent effort to identify any such rights. Information 872 on the procedures with respect to rights in RFC documents can be 873 found in BCP 78 and BCP 79. 875 Copies of IPR disclosures made to the IETF Secretariat and any 876 assurances of licenses to be made available, or the result of an 877 attempt made to obtain a general license or permission for the use of 878 such proprietary rights by implementers or users of this 879 specification can be obtained from the IETF on-line IPR repository at 880 http://www.ietf.org/ipr. 882 The IETF invites any interested party to bring to its attention any 883 copyrights, patents or patent applications, or other proprietary 884 rights that may cover technology that may be required to implement 885 this standard. Please address the information to the IETF at 886 ietf-ipr@ietf.org. 888 Acknowledgment 890 Funding for the RFC Editor function is provided by the IETF 891 Administrative Support Activity (IASA).