idnits 2.17.1 draft-ietf-mmusic-sdp-uks-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 350: '...on_id" extension MUST NOT be included ...' RFC 2119 keyword, line 353: '... Endpoints MUST check that the "id" ...' RFC 2119 keyword, line 358: '... that it expects MUST abort the connec...' RFC 2119 keyword, line 364: '... endpoint MAY choose to continue a s...' RFC 2119 keyword, line 368: '...sion_id" extension MUST be sent in the...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 08, 2018) is 2088 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-13 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft E. Rescorla 4 Intended status: Standards Track Mozilla 5 Expires: February 9, 2019 August 08, 2018 7 Unknown Key Share Attacks on uses of Transport Layer Security with the 8 Session Description Protocol (SDP) 9 draft-ietf-mmusic-sdp-uks-02 11 Abstract 13 This document describes unknown key-share attacks on the use of 14 Datagram Transport Layer Security for the Secure Real-Time Transport 15 Protocol (DTLS-SRTP). Similar attacks are described on the use of 16 DTLS-SRTP with Web Real-Time Communications (WebRTC) identity 17 assertions. Both attacks cause a victim to be mislead about the 18 identity of a communicating peer. Simple mitigation techniques are 19 defined for each. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 9, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 57 2.1. Attack Overview . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 59 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Interactions with Key Continuity . . . . . . . . . . . . 6 61 2.5. Third-Party Call Control . . . . . . . . . . . . . . . . 6 62 3. Adding a Session Identifier . . . . . . . . . . . . . . . . . 7 63 3.1. The external_session_id TLS Extension . . . . . . . . . . 7 64 4. WebRTC Identity Binding . . . . . . . . . . . . . . . . . . . 8 65 4.1. The webrtc_id_hash TLS Extension . . . . . . . . . . . . 9 66 5. Consequences of Session Concatenation . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 The use of Transport Layer Security (TLS) [RFC5246] with the Session 78 Description Protocol (SDP) [RFC4566] is defined in [RFC8122]. 79 Further use with Datagram Transport Layer Security (DTLS) [RFC6347] 80 and the Secure Real-time Transport Protocol (SRTP) [RFC3711] is 81 defined as DTLS-SRTP [RFC5763]. 83 In these specifications, key agreement is performed using TLS or 84 DTLS, with authentication being tied back to the session description 85 (or SDP) through the use of certificate fingerprints. Communication 86 peers check that a hash, or fingerprint, provided in the SDP matches 87 the certificate that is used in the TLS or DTLS handshake. This is 88 defined in [RFC8122]. 90 The design in RFC 8122 relies on the integrity of the signaling 91 channel. Certificate fingerprints are assumed to be provided by the 92 communicating peers and carried by the signaling channel without 93 being subject to modification. However, this design is vulnerable to 94 an unknown key-share (UKS) attack where a misbehaving endpoint is 95 able to advertise a key that it does not control. This leads to the 96 creation of sessions where peers are confused about the identify of 97 the participants. 99 An extension to TLS is defined that can be used to mitigate this 100 attack. 102 A similar attack is possible with sessions that use WebRTC identity 103 (see Section 5.6 of [WEBRTC-SEC]). This issue and a mitigation for 104 it is discussed in more detail in Section 4. 106 2. Unknown Key-Share Attack 108 In an unknown key-share attack [UKS], a malicious participant in a 109 protocol claims to control a key that is in reality controlled by 110 some other actor. This arises when the identity associated with a 111 key is not properly bound to the key. 113 In usages of TLS that use SDP for negotiation, an endpoint is able to 114 acquire the certificate fingerprint of another entity. By 115 advertising that fingerprint in place of one of its own, the 116 malicious endpoint can cause its peer to communicate with a different 117 peer, even though it believes that it is communicating with the 118 malicious endpoint. 120 When the identity of communicating peers is established by higher- 121 layer signaling constructs, such as those in SIP [RFC4474] or WebRTC 122 [WEBRTC-SEC], this allows an attacker to bind their own identity to a 123 session with any other entity. 125 By substituting the fingerprint of one peer for its own, an attacker 126 is able to cause a TLS connection to be established where one 127 endpoint might make an incorrect assumption about the identity of its 128 peer. The TLS peer is not the same as the signaling peer. 130 The peer does not suffer any such confusion, resulting in each peer 131 involved in the session having a different view of the nature of the 132 session. 134 This attack applies to any communications established based on the 135 SDP "fingerprint" attribute [RFC8122]. 137 This attack is an aspect of SDP-based protocols that the technique 138 known as third-party call control (3PCC) relies on. 3PCC exploits 139 the potential for the identity of a signaling peer to be different 140 than the media peer, allowing the media peer to be selected by the 141 signaling peer. Section 2.5 describes the consequences of the 142 mitigations described here for systems that use 3PCC. 144 2.1. Attack Overview 146 This vulnerability can be used by an attacker to create a session 147 where there is confusion about the communicating endpoints. 149 A SIP endpoint or WebRTC endpoint that is configured to reuse a 150 certificate can be attacked if it is willing to conduct two 151 concurrent calls, one of which is with an attacker. The attacker can 152 arrange for the victim to incorrectly believe that is calling the 153 attacker when it is in fact calling a second party. The second party 154 correctly believes that it is talking to the victim. 156 The same technique can be used to cause two victims to both believe 157 they are talking to the attacker when they are talking to each other. 159 In a related attack, a single call using WebRTC identity can be 160 attacked so that it produces the same outcome. This attack does not 161 require a concurrent call. 163 2.2. Limits on Attack Feasibility 165 The use of TLS with SDP depends on the integrity of session 166 signaling. Assuming signaling integrity limits the capabilities of 167 an attacker in several ways. In particular: 169 1. An attacker can only modify the parts of the session signaling 170 for a session that they are part of, which is limited to their 171 own offers and answers. 173 2. No entity will complete communications with a peer unless they 174 are willing to participate in a session with that peer. 176 The combination of these two constraints make the spectrum of 177 possible attacks quite limited. An attacker is only able to switch 178 its own certificate fingerprint for a valid certificate that is 179 acceptable to its peer. Attacks therefore rely on joining two 180 separate sessions into a single session. 182 The second condition is not necessary with WebRTC identity if the 183 victim has or is configured with a target peer identity (as defined 184 in [WEBRTC]). Furthermore, any identity displayed by a browser could 185 be different to the identity used by the application, since the 186 attack affects the browser's understanding of the peer's identity. 188 2.3. Example 190 In this example, two sessions are created with the same endpoint 191 concurrently. One of those sessions is initiated with the attacker, 192 the second session is created toward another honest endpoint. The 193 attacker convinces the endpoint that their session has completed, and 194 that the session with the other endpoint has succeeded. 196 Norma Mallory Patsy 197 (fp=N) ----- (fp=P) 198 | | | 199 +---Offer1 (fp=N)--->| | 200 +-----Offer2 (fp=N)-------------------->| 201 |<--------------------Answer2 (fp=P)----+ 202 |<--Answer1 (fp=P)---+ | 203 | | | 204 |======DTLS1====>(Forward)====DTLS1====>| 205 |<=====DTLS2=====(Forward)<===DTLS2=====| 206 |======Media1===>(Forward)====Media1===>| 207 |<=====Media2====(Forward)<===Media2====| 208 | | | 209 |======DTLS2===========>(Drop) | 210 | | | 212 In this case, Norma is willing to conduct two concurrent sessions. 213 The first session is established with Mallory, who falsely uses 214 Patsy's certificate fingerprint. A second session is initiated 215 between Norma and Patsy. Signaling for both sessions is permitted to 216 complete. 218 Once signaling is complete on the session that is ostensibly between 219 Mallory and Norma is complete. Mallory begins forwarding DTLS and 220 media packets sent to her by Norma to Patsy. Mallory also intercepts 221 packets from Patsy and forwards those to Norma at the transport 222 address that Norma associates with Mallory. 224 The second signaling exchange - between Norma and Patsy - is 225 permitted to continue to the point where Patsy believes that it has 226 succeeded. This ensures that Patsy believes that she is 227 communicating with Norma. In the end, Norma believes that she is 228 communicating with Mallory, when she is really communicating with 229 Patsy. 231 Though Patsy needs to believe that the second signaling session has 232 been successfully established, Mallory has no real interest in seeing 233 that session complete. Mallory only needs to ensure that Patsy does 234 not abandon the session prematurely. For this reason, it might be 235 necessary to permit the signaling from Patsy to reach Norma to allow 236 Patsy to receive a call completion signal, such as a SIP ACK. Once 237 the second session completes, Mallory might cause DTLS packets sent 238 by Norma to Patsy to be dropped, though these will likely be 239 discarded by Patsy. 241 For the attacked session to be sustained beyond the point that Norma 242 detects errors in the second session, Mallory also needs to block any 243 signaling that Norma might send to Patsy asking for the call to be 244 abandoned. Otherwise, Patsy might receive a notice that the call is 245 failed and thereby abort the call. 247 This attack creates an asymmetry in the beliefs about the identity of 248 peers. However, this attack is only possible if the victim (Norma) 249 is willing to conduct two sessions concurrently, if the attacker 250 (Mallory) is on the network path between the victims, and if the same 251 certificate - and therefore SDP "fingerprint" attribute value - is 252 used in both sessions. 254 Where ICE [ICE] is used, Mallory also needs to ensure that 255 connectivity between Patsy and Norma succeed, either by forwarding 256 checks or answering and generating the necessary messages. 258 2.4. Interactions with Key Continuity 260 Systems that use key continuity might be able to detect an unknown 261 key-share attack if a session with the actual peer (i.e., Patsy in 262 the example) was established in the past. Whether this is possible 263 depends on how key continuity is implemented. 265 Implementations that maintain a single database of identities with an 266 index on peer keys could discover that the identity saved for the 267 peer key does not match the claimed identity. Such an implementation 268 could notice the disparity between the actual keys (Patsy) and the 269 expected keys (Mallory). 271 In comparison, implementations that first match based on peer 272 identity could treat an unknown key-share attack as though their peer 273 had used a newly-configured device. The apparent addition of a new 274 device could generate user-visible notices (e.g., "Mallory appears to 275 have a new device"). However, such an event is not always considered 276 alarming; some implementations might silently save a new key. 278 2.5. Third-Party Call Control 280 Third-party call control (3PCC) is a technique where a signaling peer 281 establishes a call that is terminated by a different entity. This 282 attack is very similar to the 3PCC technique, except where the TLS 283 peers are aware of the use of 3PCC. 285 For 3PCC to work with the proposed defense, TLS peers need to be 286 aware of the signaling so that they can correctly generate (and 287 check) the extension. It is understood that this technique will 288 prevent the use of 3PCC if peers are not able to access signaling. 290 3. Adding a Session Identifier 292 An attack on DTLS-SRTP is possible because the identity of peers 293 involved is not established prior to establishing the call. 294 Endpoints use certificate fingerprints as a proxy for authentication, 295 but as long as fingerprints are used in multiple calls, they are 296 vulnerable to attacks of the sort described. 298 The solution to this problem is to assign a new identifier to 299 communicating peers. Each endpoint assigns their peer a unique 300 identifier during call signaling. The peer echoes that identifier in 301 the TLS handshake, binding that identity into the session. Including 302 this new identity in the TLS handshake means that it will be covered 303 by the TLS Finished message, which is necessary to authenticate it 304 (see [SIGMA]). Validating that peers use the correct identifier then 305 means that the session is established between the correct two 306 endpoints. 308 This solution relies on the unique identifier given to DTLS sessions 309 using the SDP "tls-id" attribute [DTLS-SDP]. This field is already 310 required to be unique. Thus, no two offers or answers from the same 311 client will have the same value. 313 A new "external_session_id" extension is added to the TLS or DTLS 314 handshake for connections that are established as part of the same 315 call or real-time session. This carries the value of the "tls-id" 316 attribute and provides integrity protection for its exchange as part 317 of the TLS or DTLS handshake. 319 3.1. The external_session_id TLS Extension 321 The "external_session_id" TLS extension carries the unique identifier 322 that an endpoint selects. When used with SDP, the value includes the 323 "tls-id" attribute from the SDP that the endpoint generated when 324 negotiating the session. This document only defines use of this 325 extensions for SDP; other methods of external session negotiation can 326 use this extension to include a unique session identifier. 328 The "extension_data" for the "external_session_id" extension contains 329 a ExternalSessionId struct, described below using the syntax defined 330 in [RFC5246]: 332 struct { 333 opaque id<20..255>; 334 } ExternalSessionId; 336 For SDP, the "id" field of the extension includes the value of the 337 "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the "tls- 338 id-value" ABNF production). The value of the "tls-id" attribute is 339 encoded using ASCII [RFC0020]. 341 Where RTP and RTCP [RFC3550] are not multiplexed, it is possible that 342 the two separate DTLS connections carrying RTP and RTCP can be 343 switched. This is considered benign since these protocols are 344 usually distinguishable. RTP/RTCP multiplexing is advised to address 345 this problem. 347 The "external_session_id" extension is included in a ClientHello and 348 either ServerHello (for TLS and DTLS versions less than 1.3) or 349 EncryptedExtensions (for TLS 1.3). In TLS 1.3, the 350 "external_session_id" extension MUST NOT be included in a 351 ServerHello. 353 Endpoints MUST check that the "id" parameter in the extension that 354 they receive includes the "tls-id" attribute value that they received 355 in their peer's session description. Comparison can be performed 356 with either the decoded ASCII string or the encoded octets. An 357 endpoint that receives a "external_session_id" extension that is not 358 identical to the value that it expects MUST abort the connection with 359 a fatal "handshake_failure" alert. 361 An endpoint that is communicating with a peer that does not support 362 this extension will receive a ClientHello, ServerHello or 363 EncryptedExtensions that does not include this extension. An 364 endpoint MAY choose to continue a session without this extension in 365 order to interoperate with peers that do not implement this 366 specification. 368 In TLS 1.3, the "external_session_id" extension MUST be sent in the 369 EncryptedExtensions message. 371 4. WebRTC Identity Binding 373 The identity assertion used for WebRTC [WEBRTC-SEC] is bound only to 374 the certificate fingerprint of an endpoint and can therefore be 375 copied by an attacker along with any SDP "fingerprint" attributes. 376 An attacker can exploit this by causing a victim to believe that they 377 are communicating with an attacker-controlled identity, when they are 378 really talking to another entity of the attacker's choice. The 379 attacker only needs to create an identity assertion that covers a 380 certificate fingerprint of their choosing. 382 The problem might appear to be caused by the fact that an identity 383 provider is not required to verify that the entity requesting an 384 identity assertion controls the keys associated with the certificate 385 that is used. A WebRTC identity provider is not required, or even 386 able, to perform validation. This is not an issue because 387 verification is not a necessary condition for a secure protocol, nor 388 would it be sufficient to prevent attack [SIGMA]. 390 A simple solution to this problem is suggested by [SIGMA]. The 391 identity of endpoints is included under a message authentication code 392 (MAC) during the cryptographic handshake. Endpoints then validate 393 that their peer has provided an identity that matches their 394 expectations. 396 In TLS, the Finished message provides a MAC over the entire 397 handshake, so that including the identity in a TLS extension is 398 sufficient to implement this solution. Rather than include a 399 complete identity assertion - which could be sizeable - a collision- 400 and pre-image-resistant hash of the identity assertion is included in 401 a TLS extension. Peers then need only validate that the extension 402 contains a hash of the identity assertion they received in signaling 403 in addition to validating the identity assertion. 405 Endpoints can also use the "external_session_id" extension in 406 addition to this so that two calls between the same parties can't be 407 altered by an attacker. 409 4.1. The webrtc_id_hash TLS Extension 411 The "webrtc_id_hash" TLS extension carries a hash of the identity 412 assertion that communicating peers have exchanged. 414 The "extension_data" for the "webrtc_id_hash" extension contains a 415 WebrtcIdentityHash struct, described below using the syntax defined 416 in [RFC5246]: 418 struct { 419 opaque assertion_hash<0..32>; 420 } WebrtcIdentityHash; 422 A WebRTC identity assertion is provided as a JSON [RFC7159] object 423 that is encoded into a JSON text. The resulting string is then 424 encoded using UTF-8 [RFC3629]. The content of the "webrtc_id_hash" 425 extension are produced by hashing the resulting octets with SHA-256 427 [SHA]. This produces the 32 octets of the assertion_hash parameter, 428 which is the sole contents of the extension. 430 The SDP "identity" attribute includes the base64 [RFC4648] encoding 431 of the same octets that were input to the hash. The "webrtc_id_hash" 432 extension is validated by performing base64 decoding on the value of 433 the SDP "identity" attribute, hashing the resulting octets using SHA- 434 256, and comparing the results with the content of the extension. 436 Identity assertions might be provided by only one peer. An endpoint 437 that does not produce an identity assertion MUST generate an empty 438 "webrtc_id_hash" extension in its ClientHello. This allows its peer 439 to include a hash of its identity assertion. An endpoint without an 440 identity assertion MUST omit the "webrtc_id_hash" extension from its 441 ServerHello or EncryptedExtensions message. 443 A peer that receives a "webrtc_id_hash" extension that is not equal 444 to the value of the identity assertion from its peer MUST immediately 445 fail the TLS handshake with an error. This includes cases where the 446 "identity" attribute is not present in the SDP. 448 A "webrtc_id_hash" extension that is any length other than 0 or 32 is 449 invalid and MUST cause the receiving endpoint to generate a fatal 450 "decode_error" alert. 452 A peer that receives an identity assertion, but does not receive a 453 "webrtc_id_hash" extension MAY choose to fail the connection, though 454 it is expected that implementations written prior to the definition 455 of the extensions in this document will not support both for some 456 time. 458 In TLS 1.3, the "webrtc_id_hash" extension MUST be sent in the 459 EncryptedExtensions message. 461 5. Consequences of Session Concatenation 463 Use of session identifiers does not prevent an attacker from 464 establishing two concurrent sessions with different peers and 465 forwarding signaling from those peers to each other. Concatenating 466 two signaling sessions creates a situation where both peers believe 467 that they are talking to the attacker when they are talking to each 468 other. 470 This kind of attack is prevented by systems that enable peer 471 authentication such as WebRTC identity [WEBRTC-SEC] or SIP identity 472 [RFC4474]. However, session concatention remains possible at higher 473 layers: an attacker can establish two independent sessions and simply 474 forward any data it receives from one into the other. 476 In the absence of any higher-level concept of peer identity, the use 477 of session identifiers does not prevent session concatenation. The 478 value to an attacker is limited unless information from the TLS 479 connection is extracted and used with the signaling. For instance, a 480 key exporter [RFC5705] might be used to create a shared secret or 481 unique identifier that is used in a secondary protocol. 483 If a secondary protocol uses the signaling channel with the 484 assumption that the signaling and TLS peers are the same then that 485 protocol is vulnerable to attack unless they also validate the 486 identity of peers at both layers. Use of the "external_session_id" 487 does not guarantee that the identity of the peer at the TLS layer is 488 the same as the identity of the signaling peer. 490 It is important to note that multiple connections can be created 491 within the same signaling session. An attacker might concatenate 492 only part of a session, choosing to terminate some connections (and 493 optionally forward data) while arranging to have peers interact 494 directly for other connections. It is even possible to have 495 different peers interact for each connection. This means that the 496 actual identity of the peer for one connection might differ from the 497 peer on another connection. 499 Information extracted from a TLS connection therefore MUST NOT be 500 used in a secondary protocol outside of that connection if that 501 protocol relies on the signaling protocol having the same peers. 502 Similarly, data from one TLS connection MUST NOT be used in other TLS 503 connections even if they are established as a result of the same 504 signaling session. 506 6. Security Considerations 508 This entire document contains security considerations. 510 7. IANA Considerations 512 This document registers two extensions in the TLS "ExtensionType 513 Values" registry established in [RFC5246]: 515 o The "external_session_id" extension has been assigned a code point 516 of TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. 518 o The "webrtc_id_hash" extension has been assigned a code point of 519 TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. 521 8. References 523 8.1. Normative References 525 [DTLS-SDP] 526 Holmberg, C. and R. Shpount, "Session Description Protocol 527 (SDP) Offer/Answer Considerations for Datagram Transport 528 Layer Security (DTLS) and Transport Layer Security (TLS)", 529 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 530 2017. 532 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 533 RFC 20, DOI 10.17487/RFC0020, October 1969, 534 . 536 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 537 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 538 2003, . 540 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 541 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 542 RFC 3711, DOI 10.17487/RFC3711, March 2004, 543 . 545 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 546 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 547 July 2006, . 549 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 550 (TLS) Protocol Version 1.2", RFC 5246, 551 DOI 10.17487/RFC5246, August 2008, 552 . 554 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 555 for Establishing a Secure Real-time Transport Protocol 556 (SRTP) Security Context Using Datagram Transport Layer 557 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 558 2010, . 560 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 561 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 562 January 2012, . 564 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 565 Transport over the Transport Layer Security (TLS) Protocol 566 in the Session Description Protocol (SDP)", RFC 8122, 567 DOI 10.17487/RFC8122, March 2017, 568 . 570 [SHA] Dang, Q., "Secure Hash Standard", National Institute of 571 Standards and Technology report, 572 DOI 10.6028/nist.fips.180-4, July 2015. 574 [WEBRTC-SEC] 575 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 576 rtcweb-security-arch-13 (work in progress), October 2017. 578 8.2. Informative References 580 [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 581 Connectivity Establishment (ICE): A Protocol for Network 582 Address Translator (NAT) Traversal", draft-ietf-ice- 583 rfc5245bis-20 (work in progress), March 2018. 585 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 586 Jacobson, "RTP: A Transport Protocol for Real-Time 587 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 588 July 2003, . 590 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 591 Authenticated Identity Management in the Session 592 Initiation Protocol (SIP)", RFC 4474, 593 DOI 10.17487/RFC4474, August 2006, 594 . 596 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 597 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 598 . 600 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 601 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 602 March 2010, . 604 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 605 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 606 2014, . 608 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 609 authenticated Diffie-Hellman and its use in the IKE 610 protocols", Annual International Cryptology Conference, 611 Springer, pp. 400-425 , 2003. 613 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 614 Attacks on the Station-to-Station (STS) Protocol", Lecture 615 Notes in Computer Science 1560, Springer, pp. 154-170 , 616 1999. 618 [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., 619 and B. Aboba, "WebRTC 1.0: Real-time Communication Between 620 Browsers", W3C WD-webrtc-30160531 , May 2016. 622 Appendix A. Acknowledgements 624 This problem would not have been discovered if it weren't for 625 discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A 626 solution similar to the one presented here was first proposed by 627 Karthik Bhargavan who provided valuable input on this document. 628 Thyla van der Merwe assisted with a formal model of the solution. 629 Adam Roach and Paul E. Jones provided useful review and input. 631 Authors' Addresses 633 Martin Thomson 634 Mozilla 636 Email: martin.thomson@gmail.com 638 Eric Rescorla 639 Mozilla 641 Email: ekr@rftm.com