idnits 2.17.1 draft-jones-perc-dtls-tunnel-02.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 (March 21, 2016) is 2957 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 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 P. Jones 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track March 21, 2016 5 Expires: September 22, 2016 7 DTLS Tunnel between Media Distribution Device and Key Management 8 Function to Facilitate Key Exchange 9 draft-jones-perc-dtls-tunnel-02 11 Abstract 13 This document defines a DTLS tunneling protocol for use in multimedia 14 conferences that enables a Media Distribution Device (MDD) to 15 facilitate key exchange between an endpoint in a conference and the 16 Key Management Function (KMF) responsible for key distribution. The 17 protocol is designed to ensure that the keying material used for hop- 18 by-hop encryption and authentication is accessible to the MDD, while 19 the keying material used for end-to-end encryption and authentication 20 is inaccessible to the MDD. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 58 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 60 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 5 62 5.2. Media Distribution Device Tunneling Procedures . . . . . 5 63 5.3. Key Management Function Tunneling Procedures . . . . . . 7 64 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Tunnel Message . . . . . . . . . . . . . . . . . . . . . 8 66 6.2. Tunnel Message + Profiles . . . . . . . . . . . . . . . . 8 67 6.3. Tunnel Message + Key Info . . . . . . . . . . . . . . . . 9 68 7. To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 An objective of the work in the Privacy-Enhanced RTP Conferencing 78 (PERC) working group is to ensure that endpoints in a multimedia 79 conference have access to the end-to-end (E2E) and hop-by-hop (HBH) 80 keying material used to encrypt and authenticate Real-time Transport 81 Protocol (RTP) [RFC3550] packets, while the Media Distribution Device 82 (MDD) has access only to the hop-by-hop (HBH) keying material for 83 encryption and authentication. 85 This specification defines a tunneling protocol that enables the MDD 86 to tunnel DTLS [RFC6347] messages between an endpoint and the KMF, 87 thus allowing an endpoint to use DTLS-SRTP [RFC5764] for establishing 88 encryption and authentication keys with the KMF. 90 The tunnel established between the MDD and KMF is a DTLS association 91 that is established before any messages are forwarded on behalf of 92 the endpoint by the MDD. DTLS packets received from the endpoint are 93 encapsulated by the MDD inside this tunnel as data to be sent to the 94 KMF. Likewise, when the MDD receives data from the KMF over the 95 tunnel, it extracts the DTLS message inside and forwards that to the 96 endpoint. In this way, the DTLS association for the DTLS-SRTP 97 procedures is established between the endpoint and the KMF, with the 98 MDD simply forwarding packets between the two entities and having no 99 visibility into the confidential information exchanged or derived. 101 Following the existing DTLS-SRTP procedures, the endpoint and KMF 102 will arrive at a selected cipher and keying material, which are used 103 for HBH encryption and authentication by both the endpoint and the 104 MDD. However, since the MDD would not have direct access to this 105 information, the KMF explicitly shares the HBH key information with 106 the MDD via the tunneling protocol defined in this document. 108 By establishing this DTLS tunnel between the MDD and KMF and 109 implementing the protocol defined in this document, it is possible 110 for the MDD to facilitate the establishment of a secure DTLS 111 association between an endpoint and the KMF in order for the endpoint 112 to receive E2E and HBH keying material. At the same time, the KMF 113 can securely provide the HBH keying material to the MDD. 115 2. Conventions Used In This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119] when they 120 appear in ALL CAPS. These words may also appear in this document in 121 lower case as plain English words, absent their normative meanings. 123 3. Tunneling Concept 125 A DTLS association (tunnel) is established between the MDD and the 126 KMF. This tunnel is used to relay DTLS messages between the endpoint 127 and KMF, as depicted in Figure 1: 129 +------------------------------+ 130 +-----+ | Switching MDD | 131 | | | | 132 | KMF |<===============>|<============+ (Tunnels DTLS) | 133 | | DTLS | v | 134 +-----+ Tunnel +------------------------------+ 135 ^ 136 | 137 | DLTS-SRTP 138 | 139 v 140 +----------+ 141 | Endpoint | 142 +----------+ 144 Figure 1: DTLS Tunnel to KMF 146 The three entities involved in this communication flow are the 147 endpoint, the MDD, and the KMF. The behavior of each entity is 148 described in Section 5. 150 The KMF is a logical function that might might be co-resident with a 151 key management server operated by an enterprise, reside in one of the 152 endpoints participating in the conference, or elsewhere that is 153 trusted with E2E keying material. This document does not preclude 154 any location, only requiring that the KMF not allow the MDD to gain 155 access to the E2E keying material by following the operations 156 defined. 158 4. Example Message Flows 160 This section provides an example message flow to help clarify the 161 procedures described later in this document. Note that it is assumed 162 that a mutually authenticated DTLS association is already established 163 between the MDD and KMF for the purpose of sending tunneled messages. 165 Once the tunnel is established, it is possible for the MDD to relay 166 the DTLS messages between the endpoint and the KMF. Figure 2 shows a 167 message flow wherein the endpoint uses DTLS-SRTP to establish an 168 association with the KMF. In the process, the MDD shares its 169 supported SRTP protection profile information (see [RFC5764]) and the 170 KMF shares HBH keying material and selected cipher with the MDD. The 171 message used to tunnel the DTLS messages is named "Tunnel" and can 172 include Profiles or Key Info data. 174 Endpoint MDD KMF 175 | | | 176 |------------------------>|========================>| 177 | DTLS handshake message | Tunnel + Profiles | 178 | | | 179 |<------------------------|<========================| 180 | DTLS handshake message | Tunnel | 181 | | | 182 .... may be multiple handshake messages ... 183 |------------------------>|========================>| 184 | DTLS handshake message | Tunnel + Profiles | 185 | | | 186 |<------------------------|<========================| 187 | DTLS handshake message | Tunnel + Key Info | 188 | (including Finished) | | 189 | | | 191 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 193 Each of these tunneled messages on the right-hand side of Figure 2 is 194 a message of type "Tunnel" (see Section 6). Each message contains 195 the following information: 197 o Protocol version 198 o Association ID 199 o DTLS message being tunneled 201 Additionally, all messages sent by the MDD will contain MDD-supported 202 SRTP protection profiles at the end of the Tunnel message. The KMF 203 will need to select a common profile supported by both the endpoint 204 and the MDD to ensure that hop-by-hop operations can successfully be 205 performed. 207 Further, the KMF will provide the SRTP [RFC3711] keying material for 208 HBH operations at the time it sends a DTLS Finished message to the 209 endpoint via the tunnel. The MDD would extract this Key Info when 210 received and use it for hop-by-hop encryption and authentication. 211 The delivery of the keying information along with the completion of 212 the DTLS handshake ensures the delivery of the keying information is 213 fate shared with completion of the DTLS handshake so that the MDD is 214 guaranteed to have the HBH keying information before it receives any 215 media that is encrypted or authenticated with that key. 217 5. Tunneling Procedures 219 The following sub-sections explain in detail the expected behavior of 220 the endpoint, the media distribution device (MDD), and the key 221 management function (KMF). 223 It is important to note that the tunneling protocol described in this 224 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 225 Rather, it is a protocol that transports endpoint or KMF-generated 226 DTLS messages as data inside of the DTLS association established 227 between the MDD and KMF. 229 5.1. Endpoint Procedures 231 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 232 in order to establish the keys used for encryption and 233 authentication. The endpoint uses the normal procedures to establish 234 a DTLS-SRTP association with the KMF. 236 5.2. Media Distribution Device Tunneling Procedures 238 The MDD, acting as a client, establishes a mutually authenticated 239 DTLS association between itself and a KMF to relay DTLS messages from 240 any number of endpoints to that KMF. This MDD initiated DTLS 241 association is called a "tunnel" to differentiate it from the DTLS 242 associations initiated by endpoints. 244 The MDD MUST establish a tunnel with the KMF in advance of, or no 245 later than the point, when an endpoint attempts to establish a DTLS 246 association with the KMF. 248 The MDD MUST forward all messages received from an endpoint for a 249 given DTLS association through the same tunnel if more than one 250 tunnel has been established between it and a KMF. An MDD is not 251 precluded from establishing more than one tunnel to a given KMF. 253 The MDD MUST assign a tunnel-unique "association identifier" for each 254 endpoint-initiated DTLS association and include it in all messages 255 forwarded to the KMF. The KMF will subsequently include in this 256 identifier in all messages it sends so that the MDD can map messages 257 received via a given tunnel and forward those messages to the correct 258 endpoint. 260 The tunnel protocol enables the KMF to separately provide HBH keying 261 material to the MDD for each of the individual endpoint DTLS 262 associations, though the MDD cannot decrypt messages between the KMF 263 and endpoints. 265 When a DTLS message is received by the MDD from an endpoint, it 266 forwards the UDP payload portion of that message to the KMF 267 encapsulated in a Tunnel + Profiles message (see Section 6). The 268 Tunnel + Profiles message allows the MDD to signal which SRTP 269 protection profiles it supports for HBH operations. 271 The MDD MUST support the same list of protection profiles for the 272 life of a given endpoint's DTLS association, which is represented by 273 the association identifier. 275 When a message from the KMF includes "Key Info," the MDD MUST extract 276 the cipher and keying material conveyed in order to subsequently 277 perform HBH encryption and authentication operations for RTP and RTCP 278 packets sent between it and an endpoint. Since the HBH keying 279 material will be different for each endpoint, the MDD uses the 280 tunnel-unique association identifier included by the KMF to ensure 281 that the HBH keying material is used with the correct endpoint. 283 The MDD MUST forward all messages received from either the endpoint 284 or the KMF to ensure proper communication between those two entities. 286 5.3. Key Management Function Tunneling Procedures 288 The KMF MUST be prepared to establish one or more tunnels (DTLS 289 associations) with the MDD for the purpose of relaying DTLS messages 290 between an endpoint and the KMF. The KMF acts as a server and the 291 MDD acts as a client to establish a tunnel. 293 When the MDD relays a DTLS message from an endpoint, the MDD will 294 include an association identifier that is unique per endpoint- 295 originated DTLS association and is relayed via the tunnel. The 296 association identifier remains constant for the life of the DTLS 297 association. The KMF identifies each distinct endpoint-originated 298 DTLS association by the association identifier and the tunnel over 299 which the DTLS association was established. 301 The KMF MUST encapsulate the DTLS message inside a Tunnel message 302 (see Section 6) when sending a message to an endpoint. 304 The KMF MUST use the same association identifier in messages sent to 305 an endpoint and MUST send all messages for a given endpoint DTLS 306 association via the same tunnel. This ensures the MDD can forward 307 the messages to the correct endpoint. 309 The KMF extracts tunneled DTLS messages from an endpoint and acts on 310 those messages as if that endpoint had established the DTLS 311 association directly with the KMF, which is acting as the server and 312 the endpoint as the client. The handling of the messages and 313 certificates is exactly the same as normal DTLS-SRTP procedures 314 between endpoints. 316 The KMF MUST send a DTLS Finished message to the endpoint at the 317 point the the DTLS handshake completes. This is accomplished by 318 utilizing the Tunnel + Key Info message. The Key Info includes the 319 selected cipher (i.e. protection profile), , MKI [RFC3711] value (if 320 any), SRTP master keys, and SRTP master salt values. 322 The KMF MUST select a cipher that is supported by both the endpoint 323 and the MDD for proper operations. 325 6. Tunneling Protocol 327 The tunneling protocol is transmitted over the DTLS association 328 established between the MDD and KMF as application data. The basic 329 message is referred to as the Tunnel message. The MDD will append 330 supported SRTP protection profiles to all Tunnel messages it sends, 331 forming the Tunnel + Profiles message. The KMF will append 332 information necessary for the MDD to perform HBH encryption and 333 authentication as it transmits the DTLS Finished message to the 334 endpoint, forming the Tunnel + Key Info message. The Tunnel, Tunnel 335 + Profiles, and Tunnel + Key Info messages are detailed in the 336 following sub-sections. 338 6.1. Tunnel Message 340 Tunneled DTLS messages are transported via the "Tunnel" message as 341 application data between the MDD and the KMF. The "Tunnel" Message 342 has the following format: 344 0 1 2 3 345 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 346 +---------------+---------------+-------------------------------+ 347 | Version (H) | Version (L) | | 348 +---------------+---------------+ | 349 | | 350 | Association Identifier | 351 | | 352 | +-------------------------------+ 353 | | DTLS Message Length | 354 +-------------------------------+-------------------------------: 355 : : 356 : Tunneled DTLS Message : 357 : : 358 +---------------------------------------------------------------+ 360 Version (H): This is the protocol major version number (set to 0x01). 362 Version (L): This is the protocol minor version number (set to 0x00). 364 Association Identifier: This is the 16-octet association identifier. 366 DTLS Message Length: Length in octets of following Tunneled DTLS 367 Message. 369 Tunneled DTLS Message: This is the DTLS message exchanged between the 370 endpoint and KMF. 372 6.2. Tunnel Message + Profiles 374 Each Tunnel message transmitted by the MDD contains an array of SRTP 375 protection profiles at the end of the message. The format of the 376 message is shown below: 378 0 1 2 3 379 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 380 +---------------+---------------+-------------------------------+ 381 | Version (H) | Version (L) | | 382 +---------------+---------------+ | 383 | | 384 | Association Identifier | 385 | | 386 | +-------------------------------+ 387 | | DTLS Message Length | 388 +-------------------------------+-------------------------------: 389 : : 390 : Tunneled DTLS Message : 391 : : 392 +---------------+---------------+-------------------------------+ 393 | Data Type | Length | : 394 +---------------+---------------+ : 395 : Protection Profiles : 396 +---------------------------------------------------------------+ 398 Beyond the fields included in the Tunnel message, this message 399 introduces the following additional fields. 401 Data Type: Indicates the type of data that follows. For MDD 402 supported SRTP protection profiles, this value is 0x01. 404 Length: This is the length in octets of the protection profiles. 405 This length must be greater than or equal to 2. 407 Protection Profiles: This is an array of two-octet SRTP protection 408 profile values as per [RFC5764], with each value represented in 409 network byte order. 411 6.3. Tunnel Message + Key Info 413 When the KMF has key information to share with the MDD so it can 414 perform HBH encryption and authentication on received media packets, 415 the KMF will send a Tunnel message with the Key Info appended as 416 shown below: 418 0 1 2 3 419 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 420 +---------------+---------------+-------------------------------+ 421 | Version (H) | Version (L) | | 422 +---------------+---------------+ | 423 | | 424 | Association Identifier | 425 | | 426 | +---------------+---------------+ 427 | | DTLS Message Length | 428 +-------------------------------+-------------------------------: 429 : : 430 : Tunneled DTLS Message : 431 : : 432 +---------------+-------------------------------+---------------+ 433 | Data Type | Protection Profile | MKI Length | 434 +---------------+-------------------------------+---------------+ 435 ~ Master Key Identifier (MKI) ~ 436 +---------------+---------------+-------------------------------+ 437 | CWSMK Length | : 438 +-------------------------------+ : 439 : Client Write SRTP Master Key : 440 +-------------------------------+-------------------------------+ 441 | SWSMK Length | : 442 +-------------------------------+ : 443 : Server Write SRTP Master Key : 444 +-------------------------------+-------------------------------+ 445 | CWSMS Length | : 446 +-------------------------------+ : 447 : Client Write SRTP Master Salt : 448 +-------------------------------+-------------------------------+ 449 | SWSMS Length | : 450 +-------------------------------+ : 451 : Server Write SRTP Master Salt : 452 +---------------------------------------------------------------+ 454 Beyond the fields included in the Tunnel message, this message 455 introduces the following additional fields. 457 Data Type: Indicates the type of data that follows. For key 458 information, this value is 0x02. 460 Protection Profile: This is the SRTP protection profile (see 461 [RFC5764]) the MDD MUST use to encrypt and decrypt packets sent and 462 received between itself and the endpoint. 464 MKI Length: This is the length in octets of the MKI field. A value 465 of zero indicates that the MKI field is absent. 467 CWSMK Length: The length of the "Client Write SRTP Master Key" field. 469 Client Write SRTP Master Key: The value of the SRTP master key used 470 by the client (endpoint). 472 SWSMK Length: The length of the "Server Write SRTP Master Key" field. 474 Server Write SRTP Master Key: The value of the SRTP master key used 475 by the server (MDD). 477 CWSMS Length: The length of the "Client Write SRTP Master Salt" 478 field. 480 Client Write SRTP Master Salt: The value of the SRTP master salt used 481 by the client (endpoint). 483 SWSMS Length: The length of the "Server Write SRTP Master Salt" 484 field. 486 Server Write SRTP Master Salt: The value of the SRTP master salt used 487 by the server (MDD). 489 7. To-Do List 491 The MDD and KMF may need to coordinate or exchange a "conference 492 identifier" common to the endpoints a MDD is bridging together. 493 Alternatively, information the KMF needs to know about conference-to- 494 endpoint correlations might be satisfied by getting info directly 495 from the endpoints, or some trusted entity on their behalf, via some 496 other means. Need to revisit this design choice in the context of 497 all the alternatives. 499 8. IANA Considerations 501 There are no IANA considerations for this document. 503 9. Security Considerations 505 TODO - Much more needed. 507 The encapsulated data is protected by the DTLS session from the 508 endpoint to KMF and the MDD is merely an on path entity. This does 509 not introduce any additional security concerns beyond a normal DTLS- 510 SRTP session. 512 The HBH keying material is protected by the mutual authenticated DTLS 513 session between the MDD and KMF. The KMF MUST ensure that it only 514 forms associations with authorized MDDs or it could hand HBH keying 515 information to untrusted parties. 517 The supported profile information send from the MDD to the KMF is not 518 particularly sensitive as it only provides the crypt algorithms 519 supported by the MDD but it is still protected by the DTLS session 520 from the MDD to KMF. 522 10. Acknowledgments 524 The author would like to thank David Benham and Cullen Jennings for 525 reviewing this document and providing constructive comments. 527 11. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 531 RFC2119, March 1997, 532 . 534 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 535 Jacobson, "RTP: A Transport Protocol for Real-Time 536 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 537 July 2003, . 539 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 540 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 541 RFC 3711, DOI 10.17487/RFC3711, March 2004, 542 . 544 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 545 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 546 RFC5246, August 2008, 547 . 549 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 550 Security (DTLS) Extension to Establish Keys for the Secure 551 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 552 10.17487/RFC5764, May 2010, 553 . 555 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 556 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 557 January 2012, . 559 Author's Address 561 Paul Jones 562 Cisco Systems 563 7025 Kit Creek Rd. 564 Research Triangle Park, North Carolina 27709 565 USA 567 Phone: +1 919 476 2048 568 Email: paulej@packetizer.com