idnits 2.17.00 (12 Aug 2021) /tmp/idnits34767/draft-lennox-avtcore-dtls-srtp-bigaes-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 1776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3711' is defined on line 178, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCore Working Group J. Lennox 3 Internet-Draft Vidyo 4 Intended status: Informational July 3, 2017 5 Expires: January 4, 2018 7 DTLS/SRTP Protection Profiles for 256-bit AES-CTR Encryption 8 draft-lennox-avtcore-dtls-srtp-bigaes-01 10 Abstract 12 This memo defines Datagram Transport Layer Security (DTLS) Secure 13 Real-time Transport Protocol (SRTP) Protection Profiles for 256-bit 14 Advanced Encryption Standard (AES) Counter Mode. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 4, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 53 3. SRTP Protection Profiles . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 58 6.2. Informative References . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 This memo defines Datagram Transport Layer Security (DTLS) Secure 64 Real-time Transport Protocol (SRTP) Protection Profiles for 256-bit 65 Advanced Encryption Standard (AES) Counter Mode. 67 DTLS-based key establishment for SRTP is defined in [RFC5764]. The 68 use of AES-256 counter mode with SRTP is defined in [RFC6188]. 70 The draft document that became [RFC5764] initially defined protection 71 profiles for AES-256; they were removed because the document that 72 became [RFC6188] was not yet ready. However, the definitions of the 73 protection profiles were not transfered to the [RFC6188] drafts, 74 apparently as an oversight. This document restores those codepoints, 75 with their original values. 77 1.1. Motivation 79 The question might arise as to why this is necessary. [RFC7714] 80 defines the use of AES-256 with Galois Counter Mode, and current 81 thought is that Galois Counter Mode is preferable to Counter Mode 82 plus HMAC-based authentication. 84 The reason is to minimize the difficulty of moving implementations 85 away from Security Descriptions-based keying [RFC4568]. Use of 86 Security Descriptions is strongly discouraged, as its security 87 properties are much weaker than those of DTLS/SRTP. However, as 88 [RFC6188] defines Security Descriptions signaling elements for AES- 89 256-CTR, existing implementations use them to negotiate the use of 90 these crypto suites, and many of the these implementations do not 91 have Galois Counter Mode cryptography implemented (or certified). 92 Thus, defining AES-256-CTR codepoints for DTLS/SRTP allows these 93 implementations to continue using their existing SRTP cryptography 94 while moving to a more secure keying protocol. 96 2. Conventions, Definitions and Acronyms 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. SRTP Protection Profiles 104 A DTLS-SRTP SRTP Protection Profile defines the parameters and 105 options that are in effect for the SRTP processing. This document 106 defines the following SRTP protection profiles. 108 SRTPProtectionProfile SRTP_AES256_CM_SHA1_80 = {0x00, 0x03}; 109 SRTPProtectionProfile SRTP_AES256_CM_SHA1_32 = {0x00, 0x04}; 111 The following list indicates the SRTP transform parameters for each 112 protection profile. The parameters cipher_key_length, 113 cipher_salt_length, auth_key_length, and auth_tag_length express the 114 number of bits in the values to which they refer. The 115 maximum_lifetime parameter indicates the maximum number of packets 116 that can be protected with each single set of keys when the parameter 117 profile is in use. All of these parameters apply to both RTP and 118 RTCP, unless the RTCP parameters are separately specified. 120 All of the crypto algorithms in these profiles are from [RFC6188]. 122 SRTP_AES256_CM_HMAC_SHA1_80 123 cipher: AES_256_CM 124 cipher_key_length: 256 125 cipher_salt_length: 112 126 maximum_lifetime: 2^31 127 auth_function: HMAC-SHA1 128 auth_key_length: 160 129 auth_tag_length: 80 130 SRTP_AES256_CM_HMAC_SHA1_32 131 cipher: AES_256_CM 132 cipher_key_length: 256 133 cipher_salt_length: 112 134 maximum_lifetime: 2^31 135 auth_function: HMAC-SHA1 136 auth_key_length: 160 137 auth_tag_length: 32 138 RTCP auth_tag_length: 80 140 With both of these SRTP Parameter profiles, the following SRTP 141 options are in effect: 143 o The TLS Key Derivation Function (KDF) is used to generate keys to 144 feed into the SRTP KDF. 146 o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are 147 not re-derived based on the SRTP sequence number. 149 o The key derivation procedures from Section 3 of AES_256_CM_KDF 150 [RFC6188] are used. 152 o For all other parameters, (in particular, SRTP replay window size 153 and FEC order) the default values are used. 155 If values other than the defaults for these parameters are required, 156 they can be enabled by writing a separate specification specifying 157 SDP syntax to signal them. 159 4. Security Considerations 161 This document defines security mechanisms. No additional security 162 issues beyond those of [RFC5764] and [RFC6188] apply. 164 5. IANA Considerations 166 IANA is requested to add the SRTP Protection Profiles defined in 167 Section 3 to the DTLS SRTPProtectionProfile registry. 169 6. References 171 6.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 175 RFC2119, March 1997, 176 . 178 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 179 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 180 RFC 3711, DOI 10.17487/RFC3711, March 2004, 181 . 183 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 184 Security (DTLS) Extension to Establish Keys for the Secure 185 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 186 10.17487/RFC5764, May 2010, 187 . 189 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 190 RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011, 191 . 193 6.2. Informative References 195 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 196 Description Protocol (SDP) Security Descriptions for Media 197 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 198 . 200 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 201 in the Secure Real-time Transport Protocol (SRTP)", RFC 202 7714, DOI 10.17487/RFC7714, December 2015, 203 . 205 Author's Address 207 Jonathan Lennox 208 Vidyo, Inc. 209 433 Hackensack Avenue 210 Seventh Floor 211 Hackensack, NJ 07601 212 US 214 Email: jonathan@vidyo.com