idnits 2.17.1 draft-peck-suiteb-dtls-srtp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (December 26, 2013) is 3773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Peck 3 Internet Draft The MITRE Corporation 4 Intended Status: Informational K. Igoe 5 Expires: June 29, 2014 National Security Agency 6 December 26, 2013 8 Suite B Profile for Datagram Transport Layer Security / Secure 9 Real-time Transport Protocol (DTLS-SRTP) 10 draft-peck-suiteb-dtls-srtp-04 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute working 19 documents as Internet-Drafts. The list of current Internet-Drafts is 20 at http://datatracker.ietf.org/drafts/current. 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 Copyright Notice 29 Copyright (c) 2013 IETF Trust and the persons identified as the 30 document authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal 33 Provisions Relating to IETF Documents 34 (http://trustee.ietf.org/license-info) in effect on the date of 35 publication of this document. Please review these documents 36 carefully, as they describe your rights and restrictions with respect 37 to this document. Code Components extracted from this document must 38 include Simplified BSD License text as described in Section 4.e of 39 the Trust Legal Provisions and are provided without warranty as 40 described in the Simplified BSD License. 42 Abstract 44 The United States government has published guidelines for "NSA Suite 45 B Cryptography", which defines cryptographic algorithm policy for 46 national security applications. This document describes the use of 47 Suite B cryptography with the Datagram Transport Layer Security 48 (DTLS) protocol, the Secure Real-Time Transport Protocol (SRTP), and 49 the Secure Real-Time Transport Control Protocol (SRTCP) to provide a 50 robust architecture for securing real-time data. 52 Table of Contents 54 1. Introduction.....................................................3 55 1.1. Requirements Terminology....................................3 56 2. Suite B Requirements.............................................3 57 3. Minimum Security Levels for Suite B Compliant Implementations....4 58 3.1. DTLS Cryptographic Suites for minLOS_128 and minLOS_192.....5 59 3.2. Suite B DTLS Authentication.................................5 60 3.3. Digital Signatures and Certificates.........................6 61 4. Client and Server Handshake to Create DTLS Premaster Secret......6 62 5. DTLS Master Secret...............................................7 63 6. SRTP Master Key and Master Salt..................................7 64 7. Suite B SRTP Protection Profiles.................................8 65 8. DTLS Cipher Suite and SRTP Protection Profile Negotiation........9 66 9. SRTP Key Derivation..............................................9 67 10. Security Considerations........................................10 68 11. IANA Considerations............................................10 69 12. References.....................................................10 70 12.1. Normative References......................................10 71 12.2. Informative References....................................11 73 1. Introduction 75 This document specifies the conventions for using NSA Suite B 76 Cryptography [SuiteB] with the Datagram Transport Layer Security 77 (DTLS) protocol, the Secure Real-time Transport Protocol (SRTP), and 78 the Secure Real-time Transport Control Protocol (SRTCP) to provide a 79 robust architecture for securing real-time data. 81 The Secure Real-time Transport Protocol (SRTP) provides 82 confidentiality and message authentication to RTP traffic. The 83 Secure Real-time Transport Control Protocol (SRTCP) provides message 84 authentication and optional confidentiality to the Real-time 85 Transport Control Protocol (RTCP) [RFC3711]. SRTP and SRTCP depend 86 upon external key management to provide secret master keys from which 87 to form encryption and authentication keys. RTP and RTCP are usually 88 run over the User Datagram Protocol, UDP. 90 Datagram Transport Layer Security (DTLS), based upon the Transport 91 Layer Security protocol (TLS), provides communication security for 92 datagram protocols such as UDP [RFC6347]. DTLS-SRTP is an extension 93 for DTLS that provides key management to SRTP and SRTCP as well as a 94 choice of algorithms and parameters for the SRTP and SRTCP sessions 95 [RFC5764]. 97 [RFC6460] describes a Suite B profile for TLS and DTLS. This 98 document builds upon RFC 6460, adding additional components to 99 provide a Suite B profile for DTLS-SRTP. 101 1.1 Requirements Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Suite B Requirements 109 Suite B requires that key establishment and signature algorithms be 110 based upon Elliptic Curve Cryptography and that the encryption 111 algorithm be AES [FIPS197]. Suite B algorithms are defined to 112 support two minimum levels of security: 128 and 192 bits. Suite B 113 includes [SuiteB]: 115 Encryption Advanced Encryption Standard (AES) (key sizes 116 of 128 and 256 bits) 118 Digital Signature Elliptic Curve Digital Signature Algorithm 119 (ECDSA) [FIPS186-4] (using the curves with 256- 120 and 384-bit prime moduli as specified in FIPS 121 PUB 186-4) 123 Key Agreement Elliptic Curve Diffie-Hellman (ECDH) 124 [SP800-56A] (using the curves with 256- and 125 384-bit prime moduli as specified in FIPS PUB 126 186-4) 128 Secure Hash SHA-256 and SHA-384 [FIPS180-4] 130 The curves with 256- and 384-bit prime moduli are described in NIST 131 FIPS 186-4 [FIPS186-4]. They are referred to as P-256 and P-384, 132 respectively. These elliptic curves appear in the literature under 133 two different names. For sake of clarity, we list both names below: 135 Curve NIST name SECG name 136 ------------------------------------ 137 P-256 nistp256 secp256r1 138 P-384 nistp384 secp384r1 140 3. Minimum Security Levels for Suite B Compliant Implementations 142 Suite B provides for two levels of cryptographic security, namely a 143 128-bit minimum level of security (minLOS_128) and a 192-bit minimum 144 level of security (minLOS_192). Each level defines a minimum 145 strength that all cryptographic algorithms must provide. We divide 146 the Suite B non-signature primitives into two columns as shown in 147 Table 1. 149 Column 1 Column 2 150 +-------------------+------------------+ 151 Encryption | AES-128 | AES-256 | 152 +-------------------+------------------+ 153 Key Agreement | ECDH on P-256 | ECDH on P-384 | 154 +-------------------+------------------+ 155 Hash for PRF/MAC | SHA-256 | SHA-384 | 156 +-------------------+------------------+ 158 Table 1: Suite B Cryptographic 159 Non-Signature Primitives 161 At the 128-bit minimum level of security the non-signature primitives 162 MUST either come exclusively from Column 1 or exclusively from Column 163 2. 165 At the 192-bit minimum level of security the non-signature primitives 166 MUST come exclusively from Column 2. 168 3.1. DTLS Cryptographic Suites for minLOS_128 and minLOS_192 170 Each system MUST specify a security level of a minimum of 128 bits or 171 192 bits. The security level determines which suites from the Suite 172 B compliant profile of [RFC6460] are allowed. 174 The two Suite B combinations, "SuiteB_Combination_1" or 175 "SuiteB_Combination_2" from section 3.1 of [RFC6460], satisfy the 176 requirements of section 3 of this document for the DTLS connection. 178 For a system to implement the Suite B compliant DLTS-SRTP profile, it 179 MUST follow the requirements of [RFC6460] for the DTLS connection. 180 The cipher suite rules from section 4 of [RFC6460] are summarized 181 here: 183 o A Suite B compliant DTLS MUST use version 1.2 or higher. 185 o A system configured at a minimum level of security of 128 bits 186 MUST use either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or 187 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, with 188 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 being the preferred 189 choice. 191 o If configured at a minimum level of security of 192 bits, the 192 system MUST use TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. 194 o The choice of curve used in the ECDH key exchange MUST agree 195 with the requirements listed in Table 1 of section 3. 197 3.2. Suite B DTLS Authentication 199 Digital signatures using ECDSA MUST be used for authentication by 200 Suite B compliant implementations. Using the notation of [RFC6460], 201 "ECDSA-256" represents an instantiation of the ECDSA algorithm using 202 the P-256 curve and the SHA-256 hash function. "ECDSA-384" represents 203 an instantiation of the ECDSA algorithm using the P-384 curve and the 204 SHA-384 hash function. 206 When running in Suite B compliant mode, a system configured at a 207 minimum level of security of 128 bits MUST use either ECDSA-256 or 208 ECDSA-384 for client and server authentication. It is allowable for 209 one party to authenticate with ECDSA-256 and the other party to 210 authenticate with ECDSA-384. This flexibility will allow 211 interoperability between a client and a server that have different 212 sizes of ECDSA authentication keys. 214 In Suite B compliant mode, clients and servers in a system configured 215 at a minimum level of security of 128 bits MUST be able to verify 216 ECDSA-256 signatures and SHOULD be able to verify ECDSA-384 217 signatures unless it is absolutely certain that the implementation 218 will never need to verify certificates from an authority which uses 219 an ECDSA-384 signing key. 221 A system compliant with the Suite B profile and configured at a 222 minimum level of security of 192 bits MUST use ECDSA-384 for both 223 client and server DTLS authentication. 225 Clients and servers in a system configured at a minimum level of 226 security of 192 bits MUST be able to verify ECDSA-384 signatures. 228 When in Suite B compliant mode, authentication methods other than 229 ECDSA-256 and ECDSA-384 MUST NOT be used for DTLS authentication. If 230 a relying party receives a message signed with any other 231 authentication method, it MUST return a DTLS error and stop the DTLS 232 handshake. 234 Mutual authentication MUST be performed by client and server 235 [RFC5764]. 237 3.3. Digital Signatures and Certificates 239 The initiator and responder, at both minimum levels of security, MUST 240 each have an X.509 certificate that complies with the end entity 241 signature certificate format defined in section 4.5.3 of "Suite B 242 Certificate and Certificate Revocation List (CRL) Profile" [RFC5759]. 244 4. Client and Server Handshake to Create DTLS Premaster Secret 246 DTLS-SRTP is defined for point-to-point media sessions, in which 247 there are exactly two participants [RFC5764]. Two DTLS peers MUST 248 follow the guidelines in [RFC6460] in order to be Suite B compliant. 249 Two peers who wish to implement the Suite B DTLS-SRTP profile MUST 250 implement DTLS 1.2 or later. 252 The peers MUST each generate an ephemeral elliptic curve key pair for 253 key agreement using either the P-256 or P-384 curve. The curve 254 chosen will depend upon the selected cipher suite, following the 255 requirements of section 3. The peers will then execute the elliptic 256 curve Diffie-Hellman (ECDH) key agreement to obtain a DTLS premaster 257 secret [SP800-56A, section 6.1.2.2]). 259 The DTLS premaster secret will be 32 bytes in length when using the 260 P-256 curve and 48 bytes in length when using the P-384 curve. 262 Two Suite B DTLS-SRTP compliant peers MUST each have an X.509 263 certificate that complies with the Suite B end entity digital 264 signature certificate profile [RFC5759]. The peer acting as the DTLS 265 server will use his key and the ECDSA algorithm to sign the DTLS 266 server key exchange message. For DTLS-SRTP implementations 267 [RFC5764], the peer acting as server will send the CertificateRequest 268 message. The peer acting as the client MUST then use his key and the 269 ECDSA algorithm to sign the CertificateVerify message. 271 Peers compliant with Suite B for DTLS-SRTP MUST follow the 272 certificate guidance in section 4.3 of [RFC6460]. 274 5. DTLS Master Secret 276 For Suite B applications using DTLS 1.2 or later versions, the PRF 277 used to compute the DTLS master secret will be: 279 When selecting the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher 280 suite, the TLS PRF with SHA-256 as the hash function MUST be used 281 as in [RFC5246]. 283 When selecting the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher 284 suite, the TLS PRF with SHA-384 as the hash function MUST be used 285 as in [RFC5246]. 287 The master secret will be 48 bytes in length for both PRFs. 289 6. SRTP Master Key and Master Salt 291 The DTLS master key is used in DTLS-SRTP to create SRTP master key 292 and salt pairs for the two peers acting as client and server via the 293 TLS exporter [RFC5764]. In particular, the PRF used to compute each 294 SRTP master key and salt is the following: 296 o When the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is 297 chosen, the TLS PRF with SHA-256 as the hash function MUST be 298 used. The SRTP master keys exported for the client and server 299 MUST be 128 bits in size. The SRTP master salt values for the 300 client and server MUST be 112 bits. 302 o When the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite is 303 chosen, the TLS PRF with SHA-384 as the hash function MUST be 304 used. The SRTP master keys exported for the client and server 305 MUST be 256 bits in size. The SRTP master salt values for the 306 client and server MUST be 112 bits. 308 7. Suite B SRTP Protection Profiles 310 For Suite B applications, AES in Galois Counter Mode, AES-GCM, MUST 311 be used to protect SRTP and SRTCP packets. Note that encryption is 312 OPTIONAL but message authentication is MANDATORY for SRTCP packets 313 [RFC3711]. Section 14.2 of [srtp-gcm] defines the DTLS-SRTP "SRTP 314 Protection Profiles" used for Suite B. 316 The following AES_128 based SRTP protection profiles are applicable 317 when using the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite 318 for DTLS: 320 AEAD_AES_128_GCM_8 321 AEAD_AES_128_GCM_12 323 The following AES_256 based SRTP protection profiles are applicable 324 when using the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite 325 for DTLS: 327 AEAD_AES_256_GCM_8 328 AEAD_AES_256_GCM_12 330 Any Suite B compliant DTLS-SRTP application MUST use one of the 331 above, no other encryption or integrity algorithms are allowed. In 332 addition, the following constraints are imposed upon on any Suite B 333 compliant DTLS-SRTP applications: 335 o Any application running at the 192-bit minimum level of security 336 MUST support AEAD_AES_256_GCM_8 and SHOULD support 337 AEAD_AES_256_GCM_12. The AES_128 based profiles MUST NOT be 338 used. 340 o For applications running at the 128-bit minimum level of 341 security, there are three options: 343 o Option 1 (AES_128 based): The application MUST support 344 AEAD_AES_128_GCM_8 and and SHOULD support 345 AEAD_AES_128_GCM_12. 347 o Option 2 (AES_256 based): The application MUST support 348 AEAD_AES_256_GCM_8 and and SHOULD support 349 AEAD_AES_256_GCM_12. 351 o Option 3 (both AES_128 and AES_256): The application MUST 352 support both AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8 and 353 SHOULD support AEAD_AES_128_GCM_12 and AEAD_AES_256_GCM_12. 355 o Since the AES_128 based profiles are the preferred choice at 356 the 128-bit minimum level of security, if Option 3 is used 357 the AES_128 based profiles MUST be offered before the AES_256 358 based profiles. 360 8. DTLS Cipher Suite and SRTP Protection Profile Negotiation 362 As described in [RFC5764], the DTLS-SRTP peer acting as the client 363 signals its acceptable SRTP protection profiles to the DTLS-SRTP peer 364 acting as the server with the "use_srtp" DTLS extension. For Suite 365 B, the client determines its acceptable SRTP protection profiles 366 based on its offered TLS cipher suites. 368 o If the client offers TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 369 then the client MUST offer AEAD_AES_128_GCM_8 and MAY offer 370 AEAD_AES_128_GCM_12. 372 o If the client offers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 373 then the client MUST offer AEAD_AES_256_GCM_8 and MAY offer 374 AEAD_AES_256_GCM_12. 376 The client MAY offer other cipher suites or protection profiles, but 377 if used, the connection will not be Suite B compliant. 379 For Suite B, the DTLS-SRTP peer acting as the server chooses the DTLS 380 cipher suite from the client's offerings and also chooses the SRTP 381 protection profile from the client's offerings. 383 o If the server chooses TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 384 then it MUST choose AEAD_AES_128_GCM_8 or AEAD_AES_128_GCM_12. 386 o If the server chooses TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 387 then it MUST choose AEAD_AES_256_GCM_8 or AEAD_AES_256_GCM_12. 389 The server MAY choose other cipher suites or protection profiles, but 390 if used, the connection will not be Suite B compliant. The client 391 and server each have the option to terminate the connection if the 392 chosen cipher suite and protection profile are not acceptable. 394 9. SRTP/SRTCP Key Derivation 396 The AES Counter Mode based key derivation function is used to derive 397 session keys and salts for SRTP/SRTCP [RFC3711]. The session keys 398 and salts MUST have the following bit sizes: 400 When using the AEAD_AES_128_GCM_8 or AEAD_AES_128_GCM_12 401 protection profile: 403 SRTP master key (generated from DTLS): 128 bits 404 SRTP master salt (generated from DTLS): 112 bits 405 SRTP session encryption key: 128 bits 406 SRTP session authentication key: not used for GCM 407 SRTP session salting key: 96 bits 409 When using the AEAD_AES_256_GCM_8 or AEAD_AES_256_GCM_12 410 protection profile: 412 SRTP master key (generated from DTLS): 256 bits 413 SRTP master salt (generated from DTLS): 112 bits 414 SRTP session encryption key: 256 bits 415 SRTP session authentication key: not used for GCM 416 SRTP session salting key: 96 bits 418 10. Security Considerations 420 The security considerations of this document follow those in [srtp- 421 gcm], [RFC3711], [RFC5759], [RFC5764], [RFC6347], and [RFC6460]. 423 11. IANA Considerations 425 This document has no actions for IANA. 427 12. References 429 12.1. Normative References 431 [FIPS180-4] National Institute of Standards and Technology, 432 FIPS Publication 180-4: "Secure Hash Standard", 433 March 2012. 435 [FIPS186-4] National Institute of Standards and Technology, 436 FIPS Publication 186-4: "Digital Signature Standard 437 (DSS)", July 2013. 439 [FIPS197] National Institute of Standards and Technology, 440 "Advanced Encryption Standard (AES)", FIPS 441 Publication 197, November 2001. 443 [srtp-gcm] McGrew, D., and K. Igoe, "AES-GCM and AES-CCM 444 Authenticated Encryption in Secure RTP (SRTP)", 445 draft-ietf-avtcore-srtp-aes-gcm-10, Work in Progress, 446 September 2013. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC3711] Baugher, M. McGrew, D., Naslund, M., Carrara, E., and K. 452 Norrman, "The Secure Real-time Transport Protocol 453 (SRTP)", RFC 3711, March 2004. 455 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 456 Security (TLS) Protocol Version 1.2", RFC 5246, May 457 2008. 459 [RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and 460 Certificate Revocation List (CRL) Profile", 461 RFC 5759, January 2010. 463 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 464 Security (DTLS) Extension to Establish Keys for 465 Secure Real-time Transport Protocol (SRTP)", RFC 466 5764, May 2010. 468 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport 469 Layer Security Version 1.2", RFC 6347, January 2012. 471 [RFC6460] Salter, M. and R. Housley, "Suite B 472 Profile for Transport Layer Security (TLS)", 473 RFC 6460, January 2012. 475 12.2. Informative References 477 [SuiteB] U.S. National Security Agency, "NSA Suite B 478 Cryptography", January 2009, 479 . 481 [SP800-56A] National Institute of Standards and Technology, Special 482 Publication 800-56A: "Recommendation for Pair-Wise Key 483 Establishment Schemes Using Discrete Logarithm 484 Cryptography (Revised)", March 2007. 486 Authors' Addresses 488 Michael A. Peck 489 The MITRE Corporation 490 Email: mpeck@mitre.org 491 Kevin M. Igoe 492 NSA/CSS Commercial Solutions Center 493 National Security Agency 494 Email: kmigoe@nsa.gov 496 Acknowledgement 498 Funding for the RFC Editor function is provided by the IETF 499 Administrative Support Activity (IASA).