idnits 2.17.1 draft-jennings-perc-double-00.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 (October 18, 2015) is 3113 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 5285 (Obsoleted by RFC 8285) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mmusic C. Jennings 3 Internet-Draft P. Jones 4 Intended status: Standards Track Cisco 5 Expires: April 20, 2016 A. Roach 6 Mozilla 7 October 18, 2015 9 SRTP Double Encryption Procedures 10 draft-jennings-perc-double-00 12 Abstract 14 In some conferencing scenarios, it is desirable for an intermediary 15 to be able to manipulate some RTP parameters, while still providing 16 strong end-to-end security guarantees. This document defines a SRTP 17 procedures that uses two separate but related cryptographic contexts 18 to provide "hop by hop" and "end to end" security guarantees. Both 19 the end-to-end and hop-by-hop cryptographic transforms can utilizes 20 an authenticated encryption with associated data scheme or take 21 advantage of future SRTP transforms with different properties. SRTCP 22 is encrypted hop-by-hop using an already-defined SRTCP cryptographic 23 transform. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 20, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 Cloud conferencing systems that are based on switched conferencing 60 have a central media distribution device (MDD) that receives media 61 from clients and distributes it to other clients, but does not need 62 to interpret or change the media content. For these systems, it is 63 desirable to have one security association from the sending client to 64 the receiving client that can encrypt and authenticated the media 65 end-to-end while still allowing certain RTP header information to be 66 changed by the MDD. At the same time, a separate security 67 association provides integrity and optional confidentiality for the 68 RTP and media flowing between the MDD and the clients. More 69 information about the requirements can be found in 70 [I-D.jones-perc-private-media-reqts]. 72 This specification RECOMMENDS the SRTP AES-GCM transform 73 [I-D.ietf-avtcore-srtp-aes-gcm] to encrypt an RTP packet to form the 74 end-to-end security association. The output of this is treated as an 75 RTP packet and (optionally) again encrypted with an SRTP transform to 76 form the hop-by-hop security association between the client and the 77 MDD. The MDD decrypts and checks integrity of the hop-by-hop 78 security. At this point the MDD may change some of the RTP header 79 information that would impact the end-to-end integrity. For any 80 values that are changed, the original values before changing are 81 included in a new RTP header extension called the Original Header 82 Block. The new RTP packet is encrypted with the hop-by-hop security 83 association for the destination client before being sent. The 84 receiving client decrypts and checks integrity for the hop-by-hop 85 association from the MDD then replaces any parameters the MDD changes 86 using the information in the Original Header Block before decrypting 87 and checking the end-to-end integrity. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 Terms: 97 o MDD: media distribution device that routes media from one client 98 to other clients 100 o E2E: end-to-end meaning the link from one client through the MDD 101 to the client at the other end. 103 o HBH: hop-by-hop meaning the link from the client to or from the 104 MDD. 106 o OHB: Original Header Block containing a TLVs for each value that 107 the MDD Changed in the RTP header. 109 3. Cryptographic Contexts 111 This specification uses two cryptographic contexts: An "end-to-end" 112 context that is used by endpoints that originate and consume media, 113 and a "hop-by-hop" context" that is used by an MDD that wishes to 114 make modifications to some RTP header fields. The RECOMMENDED cipher 115 for the hop-by-hop and end-to-end context is AES-GCM but as new SRTP 116 ciphers are defined, new combination of the double encryption version 117 of them can be added to the IANA registry. 119 The keys and salt for these contexts are generated with the following 120 steps: 122 o Generate key and salt values of twice the length required by the 123 E2E and HBH transforms 125 o Assign the first part of each value to be the key and salt, 126 respectively, for the inner transform. 128 o Assign the second part of each value to be the key and salt, 129 respectively, for the outer transform. 131 Obviously, if the MDD is to be able to modify header fields but not 132 decrypt the payload, then it must have cryptographic context for the 133 outer transform, but not the inner transform. This document does not 134 define how the MDD should be provisioned with this information. 136 4. Original Header Block 138 Any SRTP packet processed following these procedures MAY contain an 139 Original Header Block (OHB) extension. 141 This RTP header extension contains the original values of any 142 modified header fields, in the following form: 144 (type || value) || (type || value) || ... 146 In each type/value pair, the "type" field indicates the type of 147 parameter that was changed, and the "value" field carries the 148 original value of the parameter. The mapping from RTP header 149 parameters to type values, and the length of the value field is as 150 follows 152 +-----------+------+--------------+ 153 | Field | Type | Value length | 154 +-----------+------+--------------+ 155 | X | 1 | 1 | 156 | | | | 157 | CC | 2 | 1 | 158 | | | | 159 | M | 3 | 1 | 160 | | | | 161 | PT | 4 | 1 | 162 | | | | 163 | Seq Num | 5 | 2 | 164 | | | | 165 | Timestamp | 6 | 4 | 166 | | | | 167 | SSRC | 7 | 4 | 168 | | | | 169 | Ext Len | 8 | 2 | 170 +-----------+------+--------------+ 172 Open Issue: We could make a efficient coding by packing the above 173 values as bits in bit field and perhaps packing some of the single 174 values into the same byte. 176 5. Operations 178 5.1. Encrypting a Packet 180 To encrypt a packet, the endpoint encrypts the packet with the inner 181 transform, may add an OHB, then applies the outer transform. 183 o Form an RTP packet. If there are any header extensions, they MUST 184 use [RFC5285]. 186 o Apply the transform to the RTP packet 188 o Optionally add an OHB header extension. The endpoint MAY include 189 any header fields that are signaled to be modified by the MDD, to 190 reduce processing burden on the MDD. Open Issue: do we want the 191 sending client to be able to add an OHB? 193 o Apply the SRTP cryptographic transform with the outer parameters 194 (outer transform) 196 5.2. Modifying a Packet 198 In order to modify a packet, the MDD undoes the outer transform, 199 modifies the packet, updates the OHB with any new modifications, and 200 re-applies the outer tranform. 202 o Apply the (outer) decryption transform to the packet 204 o Separate the OHB from the (encrypted) original payload 206 o Change any required parameters 208 o If a changed parameter is not already in the OHB, add it with its 209 original value to the OHB. Note that in the case of cascaded 210 MDDs, the first MDD may have already added an OHB. 212 o If the MDD resets a parameter to its original value, it MAY drop 213 it from the OHB. 215 o The MDD MUST NOT delete any header extensions, but MAY add them. 217 * If the MDD adds any header extensions, it must append them and 218 it must maintain the order of the original headers in the 219 [RFC5285] block. 221 * If the MDD appends headers, then it MUST add the value of the 222 original [RFC5285] length field to the OHB, or update it if it 223 is already there. The original [RFC5285] length is counted in 224 words and stored in the Ext Len field of the OHB. 226 o Recombine the new OHB and the (encrypted) original payload 228 o Apply the (outer) encryption transform to the packet 230 5.3. Decrypting a Packet 232 To decrypt a packet, the endpoint first decrypts and verifies using 233 the outer transform, then uses the OHB to reconstruct the original 234 packet, which it decrypts and verifies with the inner transform. 236 o Apply the (outer) decryption transform to the packet 238 o Separate the OHB from the (encrypted) original payload 240 o Form a new SRTP packet with: 242 * Header = Received header, with header fields replaced with 243 values from OHB 245 * Header extensions truncated to the [RFC5285] length in OHB 247 * Payload = (encrypted) original payload 249 o Apply the (inner) decryption transform to this synthetic SRTP 250 packet 252 5.4. Recommended Inner and Outer Cryptographic Transforms 254 This specification recommends and defines values for AES-GCM as both 255 the inner and outer cryptographic transforms 256 (DOUBLE_SRTP_AEAD_AES_128_GCM and DOUBLE_SRTP_AEAD_AES_256_GCM). 257 This transform provides for authenticated encryption and will consume 258 additional processing time double-encrypting for HBH. However, the 259 approach is secure and simple, and is thus viewed as an acceptable 260 tradeoff in processing efficiency. 262 If a new SRTP transform was defined that encrypted some of all of the 263 RTP header, it would be reasonable for systems to have the option of 264 using that for the outer transform. Similarly if a new transform was 265 defined that provided only integrity, that would also be reasonable 266 to use for the HBH as the payload data is already encrypted by the 267 E2E. 269 6. Security Considerations 271 It is obviously critical that the intermediary have only the outer 272 transform parameters, and not the inner. We rely on an external key 273 management protocol to assure this property. 275 Modifications by the intermediary result in the recipient getting two 276 values for changed parameters (original and modified). The recipient 277 will have to choose which to use; there is risk in using either that 278 depends on the session setup. 280 The security properties for both the inner and outer key holders are 281 the same as the security properties of classic SRTP 283 7. IANA Considerations 285 7.1. RTP Header Extension 287 TODO - Define RTP header extension for the OBP block. 289 7.2. DTLS-SRTP 291 We request IANA to add the following values to defines a DTLS-SRTP 292 "SRTP Protection Profile" defined in [RFC5764]. 294 DOUBLE_SRTP_AEAD_AES_128_GCM = {TBD, TBD } 295 DOUBLE_SRTP_AEAD_AES_256_GCM = {TBD, TBD } 297 The SRTP transform parameters for each of these protection are: 299 DOUBLE_SRTP_AEAD_AES_128_GCM 300 cipher: AES_128_GCM 301 cipher_key_length: 256 bits 302 cipher_salt_length: 192 bits 303 aead_auth_tag_length: 32 octets 304 auth_function: NULL 305 auth_key_length: N/A 306 auth_tag_length: N/A 307 maximum lifetime: at most 2^31 SRTCP packets and 308 at most 2^48 SRTP packets 310 DOUBLE_SRTP_AEAD_AES_256_GCM 311 cipher: AES_256_GCM 312 cipher_key_length: 512 bits 313 cipher_salt_length: 192 bits 314 aead_auth_tag_length: 32 octets 315 auth_function: NULL 316 auth_key_length: N/A 317 auth_tag_length: N/A 318 maximum lifetime: at most 2^31 SRTCP packets and 319 at most 2^48 SRTP packets 321 The first half of the key and salt is used for the inner (E2E) 322 transform and the second half is used for the outer (HBH) transform. 324 8. Acknowledgements 326 Many thanks to review from GET YOUR NAME HERE. Send comments. 328 9. References 330 9.1. Normative References 332 [I-D.ietf-avtcore-srtp-aes-gcm] 333 McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 334 in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-aes-gcm-17 335 (work in progress), June 2015. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 339 RFC2119, March 1997, 340 . 342 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 343 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 344 2008, . 346 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 347 Security (DTLS) Extension to Establish Keys for the Secure 348 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 349 10.17487/RFC5764, May 2010, 350 . 352 9.2. Informative References 354 [I-D.jones-perc-private-media-reqts] 355 Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson, 356 J., and R. Barnes, "Private Media Requirements in Privacy 357 Enhanced RTP Conferencing", draft-jones-perc-private- 358 media-reqts-00 (work in progress), July 2015. 360 Authors' Addresses 362 Cullen Jennings 363 Cisco 365 Email: fluffy@iii.ca 367 Paul E. Jones 368 Cisco 370 Email: paulej@packetizer.com 372 Adam Roach 373 Mozilla 375 Email: adam@nostrum.com