idnits 2.17.1 draft-ietf-avtcore-cryptex-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 date (10 March 2021) is 1136 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE J. Uberti 3 Internet-Draft Google 4 Intended status: Standards Track C. Jennings 5 Expires: 11 September 2021 Cisco 6 S. Garcia Murillo 7 CoSMo 8 10 March 2021 10 Completely Encrypting RTP Header Extensions and Contributing Sources 11 draft-ietf-avtcore-cryptex-01 13 Abstract 15 While the Secure Real-time Transport Protocol (SRTP) provides 16 confidentiality for the contents of a media packet, a significant 17 amount of metadata is left unprotected, including RTP header 18 extensions and contributing sources (CSRCs). However, this data can 19 be moderately sensitive in many applications. While there have been 20 previous attempts to protect this data, they have had limited 21 deployment, due to complexity as well as technical limitations. 23 This document proposes a new mechanism to completely encrypt header 24 extensions and CSRCs as well a simpler signaling mechanism intended 25 to facilitate deployment. 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/juberti/cryptex. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 11 September 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Previous Solutions . . . . . . . . . . . . . . . . . . . 3 69 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. RTP Header Processing . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Encryption and Decryption . . . . . . . . . . . . . . . . . . 7 77 6.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 7 78 6.2. Encryption Procedure . . . . . . . . . . . . . . . . . . 8 79 6.3. Decryption Procedure . . . . . . . . . . . . . . . . . . 8 80 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 8 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 11.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 90 1.1. Problem Statement 92 The Secure Real-time Transport Protocol [RFC3711] mechanism provides 93 message authentication for the entire RTP packet, but only encrypts 94 the RTP payload. This has not historically been a problem, as much 95 of the information carried in the header has minimal sensitivity 96 (e.g., RTP timestamp); in addition, certain fields need to remain as 97 cleartext because they are used for key scheduling (e.g., RTP SSRC 98 and sequence number). 100 However, as noted in [RFC6904], the security requirements can be 101 different for information carried in RTP header extensions, including 102 the per-packet sound levels defined in [RFC6464] and [RFC6465], which 103 are specifically noted as being sensitive in the Security 104 Considerations section of those RFCs. 106 In addition to the contents of the header extensions, there are now 107 enough header extensions in active use that the header extension 108 identifiers themselves can provide meaningful information in terms of 109 determining the identity of endpoint and/or application. 110 Accordingly, these identifiers can be considered at least slightly 111 sensitive. 113 Finally, the CSRCs included in RTP packets can also be sensitive, 114 potentially allowing a network eavesdropper to determine who was 115 speaking and when during an otherwise secure conference call. 117 1.2. Previous Solutions 119 [RFC6904] was proposed in 2013 as a solution to the problem of 120 unprotected header extension values. However, it has not seen 121 significant adoption, and has a few technical shortcomings. 123 First, the mechanism is complicated. Since it allows encryption to 124 be negotiated on a per-extension basis, a fair amount of signaling 125 logic is required. And in the SRTP layer, a somewhat complex 126 transform is required to allow only the selected header extension 127 values to be encrypted. One of the most popular SRTP implementations 128 had a significant bug in this area that was not detected for five 129 years. 131 Second, it only protects the header extension values, and not their 132 ids or lengths. It also does not protect the CSRCs. As noted above, 133 this leaves a fair amount of potentially sensitive information 134 exposed. 136 Third, it bloats the header extension space. Because each extension 137 must be offered in both unencrypted and encrypted forms, twice as 138 many header extensions must be offered, which will in many cases push 139 implementations past the 14-extension limit for the use of one-byte 140 extension headers defined in [RFC8285]. Accordingly, implementations 141 will need to use two-byte headers in many cases, which are not 142 supported well by some existing implementations. 144 Finally, the header extension bloat combined with the need for 145 backwards compatibility results in additional wire overhead. Because 146 two-byte extension headers may not be handled well by existing 147 implementations, one-byte extension identifiers will need to be used 148 for the unencrypted (backwards compatible) forms, and two-byte for 149 the encrypted forms. Thus, deployment of [RFC6904] encryption for 150 header extensions will typically result in multiple extra bytes in 151 each RTP packet, compared to the present situation. 153 1.3. Goals 155 From this analysis we can state the desired properties of a solution: 157 * Build on existing [RFC3711] SRTP framework (simple to understand) 159 * Build on existing [RFC8285] header extension framework (simple to 160 implement) 162 * Protection of header extension ids, lengths, and values 164 * Protection of CSRCs when present 166 * Simple signaling 168 * Simple crypto transform and SRTP interactions 170 * Backward compatible with unencrypted endpoints, if desired 172 * Backward compatible with existing RTP tooling 174 The last point deserves further discussion. While we considered 175 possible solutions that would have encrypted more of the RTP header 176 (e.g., the number of CSRCs), we felt the inability to parse the 177 resultant packets with current tools, as well as additional 178 complexity incurred, outweighed the slight improvement in 179 confidentiality. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 3. Design 189 This specification proposes a mechanism to negotiate encryption of 190 all RTP header extensions (ids, lengths, and values) as well as CSRC 191 values. It reuses the existing SRTP framework, is accordingly simple 192 to implement, and is backward compatible with existing RTP packet 193 parsing code, even when support for this mechanism has been 194 negotiated. 196 4. Signaling 198 In order to determine whether this mechanism defined in this 199 specification is supported, this document defines a new "a=cryptex" 200 Session Description Protocol (SDP) [RFC4566] attribute to indicate 201 support. This attribute takes no value, and can be used at the 202 session level or media level. Offering this attribute indicates that 203 the endpoint is capable of receiving RTP packets encrypted as defined 204 below. 206 The formal definition of this attribute is: 208 Name: cryptex 210 Value: None 212 Usage Level: session, media 214 Charset Dependent: No 216 Example: 218 a=cryptex 220 When used with BUNDLE, this attribute is assigned to the TRANSPORT 221 category [RFC8859]. 223 5. RTP Header Processing 225 [RFC8285] defines two values for the "defined by profile" field for 226 carrying one-byte and two-byte header extensions. In order to allow 227 a receiver to determine if an incoming RTP packet is using the 228 encryption scheme in this specification, two new values are defined: 230 * 0xC0DE for the encrypted version of the one-byte header extensions 231 (instead of 0xBEDE). 233 * 0xC2DE for the encrypted versions of the two-byte header 234 extensions (instead of 0x100). 236 In the case of using two-byte header extensions, the extension id 237 with value 256 MUST NOT be negotiated, as the value of this id is 238 meant to be contained in the "appbits" of the "defined by profile" 239 field, which are not available when using the values above. 241 If the "a=extmap-allow-mixed" attribute defined in [RFC8285] is 242 negotiated, either one-byte or two-byte header ids can be used (with 243 the values above), as in [RFC8285]. 245 5.1. Sending 247 When the mechanism defined by this specification has been negotiated, 248 sending a RTP packet that has any CSRCs or contains any {RFC8285}} 249 header extensions follows the steps below. This mechanism MUST NOT 250 be used with header extensions other than the [RFC8285] variety. 252 If the packet contains solely one-byte extension ids, the 16-bit RTP 253 header extension tag MUST be set to 0xC0DE to indicate that the 254 encryption has been applied, and the one-byte framing is being used. 255 If the packet contains only two-byte extension ids, the header 256 extension tag MUST be set to 0xC2DE to indicate encryption has been 257 applied, and the two-byte framing is being used. 259 If the packet contains CSRCs but no header extensions, an empty 260 extension block consisting of the 0xC0DE tag and a 16-bit length 261 field set to zero (explicitly permitted by [RFC3550]) MUST be 262 appended, and the X bit MUST be set to 1 to indicate an extension 263 block is present. This is necessary to provide the receiver an 264 indication that the CSRCs in the packet are encrypted. 266 The RTP packet MUST then be encrypted as described in Encryption 267 Procedure. 269 5.2. Receiving 271 When receiving an RTP packet that contains header extensions, the 272 "defined by profile" field MUST be checked to ensure the payload is 273 formatted according to this specification. If the field does not 274 match one of the values defined above, the implementation MUST 275 instead handle it according to the specification that defines that 276 value. The implemntation MAY stop and report an error if it 277 considers use of this specification mandatory for the RTP stream. 279 If the RTP packet passes this check, it is then decrypted according 280 to Decryption Procedure, and passed to the the next layer to process 281 the packet and its extensions. In the event that a zero-length 282 extension block was added as indicated above, it can be left as-is 283 and will be processed normally. 285 6. Encryption and Decryption 287 6.1. Packet Structure 289 When this mechanism is active, the SRTP packet is protected as 290 follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 295 |V=2|P|X| CC |M| PT | sequence number | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 297 | timestamp | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 299 | synchronization source (SSRC) identifier | | 300 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 301 | | contributing source (CSRC) identifiers | | 302 | | .... | | 303 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 304 X | 0xC0 | 0xDE | length=3 | | 305 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 306 | | RFC 8285 header extensions | | 307 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 308 | | payload ... | | 309 | | +-------------------------------+ | 310 | | | RTP padding | RTP pad count | | 311 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 312 | ~ SRTP MKI (OPTIONAL) ~ | 313 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 314 | : authentication tag (RECOMMENDED) : | 315 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 316 | | 317 +- Encrypted Portions* Authenticated Portion ---+ 319 * Note that the 4 bytes at the start of the extension block are not 320 encrypted, as required by [RFC8285]. 322 Specifically, the encrypted portion MUST include any CSRC 323 identifiers, any RTP header extension (except for the first 4 bytes), 324 and the RTP payload. 326 6.2. Encryption Procedure 328 The encryption procedure is identical to that of [RFC3711] except for 329 the region to encrypt, which is as shown in the section above. 331 To minimize changes to surrounding code, the encryption mechanism can 332 choose to replace a "defined by profile" field from [RFC8285] with 333 its counterpart defined in RTP Header Processing above and encrypt at 334 the same time. 336 6.3. Decryption Procedure 338 The decryption procedure is identical to that of [RFC3711] except for 339 the region to decrypt, which is as shown in the section above. 341 To minimize changes to surrounding code, the decryption mechanism can 342 choose to replace the "defined by profile" field with its no- 343 encryption counterpart from [RFC8285] and decrypt at the same time. 345 7. Backwards Compatibility 347 This specification attempts to encrypt as much as possible without 348 interfering with backwards compatibility for systems that expect a 349 certain structure from an RTPv2 packet, including systems that 350 perform demultiplexing based on packet headers. Accordingly, the 351 first two bytes of the RTP packet are not encrypted. 353 This specification also attempts to reuse the key scheduling from 354 SRTP, which depends on the RTP packet sequence number and SSRC 355 identifier. Accordingly these values are also not encrypted. 357 8. Security Considerations 359 This specification extends SRTP by expanding the portion of the 360 packet that is encrypted, as shown in Packet Structure. It does not 361 change how SRTP authentication works in any way. Given that more of 362 the packet is being encrypted than before, this is necessarily an 363 improvement. 365 The RTP fields that are left unencrypted (see rationale above) are as 366 follows: 368 * RTP version 370 * padding bit 372 * extension bit 373 * number of CSRCs 375 * marker bit 377 * payload type 379 * sequence number 381 * timestamp 383 * SSRC identifier 385 * number of [RFC8285] header extensions 387 These values contain a fixed set (i.e., one that won't be changed by 388 extensions) of information that, at present, is observed to have low 389 sensitivity. In the event any of these values need to be encrypted, 390 SRTP is likely the wrong protocol to use and a fully-encapsulating 391 protocol such as DTLS is preferred (with its attendant per-packet 392 overhead). 394 9. IANA Considerations 396 This document defines two new 'defined by profile' attributes, as 397 noted in RTP Header Processing. 399 10. Acknowledgements 401 The authors wish to thank Lennart Grahl for pointing out many of the 402 issues with the existing header encryption mechanism, as well as 403 suggestions for this proposal. Thanks also to Jonathan Lennox and 404 Inaki Castillo for their review and suggestions. 406 11. References 408 11.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 416 Jacobson, "RTP: A Transport Protocol for Real-Time 417 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 418 July 2003, . 420 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 421 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 422 RFC 3711, DOI 10.17487/RFC3711, March 2004, 423 . 425 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 426 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 427 July 2006, . 429 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 430 Mechanism for RTP Header Extensions", RFC 8285, 431 DOI 10.17487/RFC8285, October 2017, 432 . 434 [RFC8859] Nandakumar, S., "A Framework for Session Description 435 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 436 DOI 10.17487/RFC8859, January 2021, 437 . 439 11.2. Informative References 441 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 442 Transport Protocol (RTP) Header Extension for Client-to- 443 Mixer Audio Level Indication", RFC 6464, 444 DOI 10.17487/RFC6464, December 2011, 445 . 447 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 448 time Transport Protocol (RTP) Header Extension for Mixer- 449 to-Client Audio Level Indication", RFC 6465, 450 DOI 10.17487/RFC6465, December 2011, 451 . 453 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 454 Real-time Transport Protocol (SRTP)", RFC 6904, 455 DOI 10.17487/RFC6904, April 2013, 456 . 458 Authors' Addresses 460 Justin Uberti 461 Google 463 Email: justin@uberti.name 464 Cullen Jennings 465 Cisco 467 Email: fluffy@iii.ca 469 Sergio Garcia Murillo 470 CoSMo 472 Email: sergio.garcia.murillo@cosmosoftware.io