idnits 2.17.1 draft-thomson-mmusic-sdp-uks-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 : ---------------------------------------------------------------------------- ** 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 313: '... extension MUST NOT be included in a...' RFC 2119 keyword, line 315: '... Endpoints MUST check that the "tls_...' RFC 2119 keyword, line 320: '... that it expects MUST abort the connec...' RFC 2119 keyword, line 326: '... endpoint MAY choose to continue a s...' RFC 2119 keyword, line 330: '..._tls_id" extension MUST be sent in the...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2017) is 2553 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-32) exists of draft-ietf-mmusic-dtls-sdp-23 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- 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: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Informational Mozilla 5 Expires: October 22, 2017 April 20, 2017 7 Unknown Key Share Attacks on uses of Transport Layer Security with the 8 Session Description Protocol (SDP) 9 draft-thomson-mmusic-sdp-uks-00 11 Abstract 13 Unknown key-share attacks on the use of Datagram Transport Layer 14 Security for the Secure Real-Time Transport Protocol (DTLS-SRTP) and 15 its use with Web Real-Time Communications (WebRTC) identity 16 assertions are described. Simple mitigation techniques are defined. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 22, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 54 2.1. Attack Overview . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 56 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.4. Interactions with Key Continuity . . . . . . . . . . . . 6 58 3. Adding a Session Identifier . . . . . . . . . . . . . . . . . 6 59 3.1. The sdp_tls_id TLS Extension . . . . . . . . . . . . . . 7 60 4. WebRTC Identity Binding . . . . . . . . . . . . . . . . . . . 8 61 4.1. The webrtc_id_hash TLS Extension . . . . . . . . . . . . 8 62 5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 8.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 The use of Transport Layer Security (TLS) [RFC5246] with the Session 74 Description Protocol (SDP) [RFC4566] is defined in [RFC4572]. 75 Further use with Datagram Transport Layer Security (DTLS) [RFC6347] 76 and the Secure Real-time Transport Protocol (SRTP) [RFC3711] is 77 defined as DTLS-SRTP [RFC5763]. 79 In these specifications, key agreement is performed using TLS or 80 DTLS, with authentication being tied back to the session description 81 (or SDP) through the use of certificate fingerprints. Communication 82 peers check that a hash, or fingerprint, provided in the SDP matches 83 the certificate that is used in the TLS or DTLS handshake. This is 84 defined in [RFC4572]. 86 The design in RFC 4572 relies on the integrity of the signaling 87 channel. Certificate fingerprints are assumed to be provided by the 88 communicating peers and carried by the signaling channel without 89 being subject to modification. However, this design is vulnerable to 90 an unknown key-share (UKS) attack where a misbehaving endpoint is 91 able to advertise a key that it does not control. This leads to the 92 creation of sessions where peers are confused about the identify of 93 the participants. 95 An extension to TLS is defined that can be used to mitigate this 96 attack. 98 A similar attack is possible with sessions that use WebRTC identity 99 (see Section 5.6 of [I-D.ietf-rtcweb-security-arch]). This issue and 100 a mitigation for it is discussed in more detail in Section 4. 102 2. Unknown Key-Share Attack 104 In an unknown key-share attack [UKS], a malicious participant in a 105 protocol claims to control a key that is in reality controlled by 106 some other actor. This arises when the identity associated with a 107 key is not properly bound to the key. 109 In usages of TLS and DTLS that use SDP for negotiation, an endpoint 110 is able to acquire the certificate fingerprint another entity. By 111 advertising that fingerprint in place of one of its own, the 112 malicious endpoint can cause its peer to communicate with a different 113 peer, even though it believes that it is communicating with the 114 malicious endpoint. 116 When the identity of communicating peers is established by higher- 117 layer signaling constructs, such as those in SIP [RFC4474] or WebRTC 118 [I-D.ietf-rtcweb-security-arch], this allows an attacker to bind 119 their own identity to a session with any other entity. 121 By substituting the the fingerprint of one peer for its own, an 122 attacker is able to cause a session to be established where one 123 endpoint has an incorrect value for the identity of its peer. 124 However, the peer does not suffer any such confusion, resulting in 125 each peer involved in the session having a different view of the 126 nature of the session. 128 This attack applies to any communications established based on the 129 SDP "fingerprint" attribute [RFC4572]. 131 2.1. Attack Overview 133 This vulnerability can be used by an attacker to create a session 134 where there is confusion about the communicating endpoints. 136 A SIP endpoint or WebRTC endpoint that is configured to reuse a 137 certificate can be attacked if it is willing to conduct two 138 concurrent calls, one of which is with an attacker. The attacker can 139 arrange for the victim to incorrectly believe that is calling the 140 attacker when it is in fact calling a second party. The second party 141 correctly believes that it is talking to the victim. 143 In a related attack, a single call using WebRTC identity can be 144 attacked so that it produces the same outcome. This attack does not 145 require a concurrent call. 147 2.2. Limits on Attack Feasibility 149 The use of TLS with SDP depends on the integrity of session 150 signaling. Assuming signaling integrity limits the capabilities of 151 an attacker in several ways. In particular: 153 1. An attacker can only modify the parts of the session signaling 154 for a session that they are part of, which is limited to their 155 own offers and answers. 157 2. No entity will complete communications with a peer unless they 158 are willing to participate in a session with that peer. 160 The combination of these two constraints make the spectrum of 161 possible attacks quite limited. An attacker is only able to switch 162 its own certificate fingerprint for a valid certificate that is 163 acceptable to its peer. Attacks therefore rely on joining two 164 separate sessions into a single session. 166 The second condition is not necessary with WebRTC identity if the 167 victim has or is configured with a target peer identity (this is 168 defined in [WEBRTC]). Furthermore, any identity displayed by a 169 browser could be different to the identity used by the application, 170 since the attack affects the browser's understanding of the peer's 171 identity. 173 2.3. Example 175 In this example, two outgoing sessions are created by the same 176 endpoint. One of those sessions is initiated with the attacker, 177 another session is created toward another honest endpoint. The 178 attacker convinces the endpoint that their session has completed, and 179 that the session with the other endpoint has succeeded. 181 Norma Mallory Patsy 182 (fp=N) ----- (fp=P) 183 | | | 184 +---Offer1 (fp=N)--->| | 185 +-----Offer2 (fp=N)-------------------->| 186 |<--------------------Answer2 (fp=P)----+ 187 |<--Answer1 (fp=P)---+ | 188 | | | 189 |======DTLS1====>(Forward)====DTLS1====>| 190 |<=====DTLS2=====(Forward)<===DTLS2=====| 191 |======Media1===>(Forward)====Media1===>| 192 |<=====Media2====(Forward)<===Media2====| 193 | | | 194 |======DTLS2===========>(Drop) | 195 | | | 197 In this case, Norma is willing to conduct two concurrent sessions. 198 The first session is established with Mallory, who falsely uses 199 Patsy's certificate fingerprint. A second session is initiated 200 between Norma and Patsy. Signaling for both sessions is permitted to 201 complete. 203 Once complete, the session that is ostensibly between Mallory and 204 Norma is completed by forwarding packets between Norma and Patsy. 205 This requires that Mallory is able to intercept DTLS and media 206 packets from Patsy so that they can be forwarded to Norma at the 207 transport addresses that Norma associates with the first session. 209 The second session - between Norma and Patsy - is permitted to 210 continue to the point where Patsy believes that it has succeeded. 211 This ensures that Patsy believes that she is communicating with 212 Norma. In the end, Norma believes that she is communicating with 213 Mallory, when she is actually communicating with Patsy. 215 Though Patsy needs to believe that the second session is successful, 216 Mallory has no real interest in seeing that session complete. 217 Mallory only needs to ensure that Patsy does not abandon the session 218 prematurely. For this reason, it might be necessary to permit the 219 answer from Patsy to reach Norma to allow Patsy to receive a call 220 completion signal, such as a SIP ACK. Once the second session 221 completes, Mallory causes any DTLS packets sent by Norma to Patsy to 222 be dropped. 224 For the attacked session to be sustained beyond the point that Norma 225 detects errors in the second session, Mallory also needs to block any 226 signaling that Norma might send to Patsy asking for the call to be 227 abandoned. Otherwise, Patsy might receive a notice that the call is 228 failed and thereby abort the call. 230 This attack creates an asymmetry in the beliefs about the identity of 231 peers. However, this attack is only possible if the victim (Norma) 232 is willing to conduct two sessions concurrently, and if the same 233 certificate - and therefore SDP "fingerprint" attribute value - is 234 used in both sessions. 236 2.4. Interactions with Key Continuity 238 Systems that use key continuity might be able to detect an unknown 239 key-share attack if a session with the actual peer (i.e., Patsy in 240 the example) was established in the past. Whether this is possible 241 depends on how key continuity is implemented. 243 Implementations that maintain a single database of identities with an 244 index on peer keys could discover that the identity saved for the 245 peer key does not match the claimed identity. Such an implementation 246 could notice the disparity between the actual keys (Patsy) and the 247 expected keys (Mallory). 249 In comparison, implementations that first match based on peer 250 identity could treat an unknown key-share attack as though their peer 251 had used a newly-configured device. The apparent addition of a new 252 device could generate user-visible notices (e.g., "Mallory appears to 253 have a new device"). However, such an event is not always considered 254 alarming; some implementations might silently save a new key. 256 3. Adding a Session Identifier 258 An attack on DTLS-SRTP is possible because the identity of peers 259 involved is not established prior to establishing the call. 260 Endpoints use certificate fingerprints as a proxy for authentication, 261 but as long as fingerprints are used in multiple calls, they are 262 vulnerable to attacks of the sort described. 264 The solution to this problem is to assign a new identifier to 265 communicating peers. Each endpoint assigns their peer a unique 266 identifier during call signaling. The peer echoes that identifier in 267 the TLS handshake, binding that identity into the session. Including 268 this new identity in the TLS handshake means that it will be covered 269 by the TLS Finished message, which is necessary to authenticate it 270 (see [SIGMA]). Validating that peers use the correct identifier then 271 means that the session is established between the correct two 272 endpoints. 274 This solution relies on the unique identifier given to DTLS sessions 275 using the SDP "tls-id" attribute [I-D.ietf-mmusic-dtls-sdp]. This 276 field is already required to be unique. Thus, no two offers or 277 answers from the same client will have the same value. 279 A new "sdp_tls_id" extension is added to the TLS or DTLS handshake 280 for connections that are established as part of the same call or 281 real-time session. This carries the value of the "tls-id" attribute 282 and provides integrity protection for its exchange as part of the TLS 283 or DTLS handshake. 285 3.1. The sdp_tls_id TLS Extension 287 The "sdp_tls_id" TLS extension carries the unique identifier that an 288 endpoint selects. The value includes the "tls-id" attribute from the 289 SDP that the endpoint generated when negotiating the session. 291 The "extension_data" for the "sdp_tls_id" extension contains a 292 SdpTlsId struct, described below using the syntax defined in 293 [RFC5246]: 295 struct { 296 opaque tls_id<20..255>; 297 } SdpTlsId; 299 The "tls_id" field of the extension includes the value of the "tls- 300 id" SDP attribute as defined in [I-D.ietf-mmusic-dtls-sdp] (that is, 301 the "tls-id-value" ABNF production). The value of the "tls-id" 302 attribute is encoded using ASCII [RFC0020]. 304 Where RTP and RTCP [RFC3550] are not multiplexed, it is possible that 305 the two separate DTLS connections carrying RTP and RTCP can be 306 switched. This is considered benign since these protocols are 307 usually distinguishable. RTP/RTCP multiplexing is advised to address 308 this problem. 310 The "sdp_tls_id" extension is included in a ClientHello and either 311 ServerHello (for TLS and DTLS versions less than 1.3) or 312 EncryptedExtensions (for TLS 1.3). In TLS 1.3, the "sdp_tls_id" 313 extension MUST NOT be included in a ServerHello. 315 Endpoints MUST check that the "tls_id" parameter in the extension 316 that they receive includes the "tls-id" attribute value that they 317 received in their peer's session description. Comparison can be 318 performed with either the decoded ASCII string or the encoded octets. 319 An endpoint that receives a "sdp_tls_id" extension that is not 320 identical to the value that it expects MUST abort the connection with 321 a fatal "handshake_failure" alert. 323 An endpoint that is communicating with a peer that does not support 324 this extension will receive a ClientHello, ServerHello or 325 EncryptedExtensions that does not include this extension. An 326 endpoint MAY choose to continue a session without this extension in 327 order to interoperate with peers that do not implement this 328 specification. 330 In TLS 1.3, the "sdp_tls_id" extension MUST be sent in the 331 EncryptedExtensions message. 333 4. WebRTC Identity Binding 335 The identity assertion used for WebRTC 336 [I-D.ietf-rtcweb-security-arch] is bound only to the certificate 337 fingerprint of an endpoint and can therefore be copied by an attacker 338 along with any SDP "fingerprint" attributes. 340 The problem is compounded by the fact that an identity provider is 341 not required to verify that the entity requesting an identity 342 assertion controls the keys. Nor is it currently able to perform 343 this validation. This is not an issue because verification is not a 344 necessary condition for a secure protocol, nor would it be sufficient 345 as established in [SIGMA]. 347 A simple solution to this problem is suggested by [SIGMA]. The 348 identity of endpoints is included under a message authentication code 349 (MAC) during the cryptographic handshake. Endpoints are then 350 expected to validate that their peer has provided an identity that 351 matches their expectations. 353 In TLS, the Finished message provides a MAC over the entire 354 handshake, so that including the identity in a TLS extension is 355 sufficient to implement this solution. Rather than include a 356 complete identity assertion - which could be sizeable - a collision- 357 resistant hash of the identity assertion is included in a TLS 358 extension. Peers then need only validate that the extension contains 359 a hash of the identity assertion they received in signaling in 360 addition to validating the identity assertion. 362 Endpoints MAY use the "sdp_tls_id" extension in addition to this so 363 that two calls between the same parties can't be altered by an 364 attacker. 366 4.1. The webrtc_id_hash TLS Extension 368 The "webrtc_id_hash" TLS extension carries a hash of the identity 369 assertion that communicating peers have exchanged. 371 The "extension_data" for the "webrtc_id_hash" extension contains a 372 WebrtcIdentityHash struct, described below using the syntax defined 373 in [RFC5246]: 375 struct { 376 opaque assertion_hash<0..32>; 377 } WebrtcIdentityHash; 379 A WebRTC identity assertion is provided as a JSON [RFC7159] object 380 that is encoded into a JSON text. The resulting string is then 381 encoded using UTF-8 [RFC3629]. The content of the "webrtc_id_hash" 382 extension are produced by hashing the resulting octets with SHA-256 383 [FIPS180-2]. This produces the 32 octets of the assertion_hash 384 parameter, which is the sole contents of the extension. 386 The SDP "identity" attribute includes the base64 [RFC4648] encoding 387 of the same octets that were input to the hash. The "webrtc_id_hash" 388 extension is validated by performing base64 decoding on the value of 389 the SDP "identity" attribute, hashing the resulting octets using SHA- 390 256, and comparing the results with the content of the extension. 392 Identity assertions might be provided by only one peer. An endpoint 393 that does not produce an identity assertion MUST generate an empty 394 "webrtc_id_hash" extension in its ClientHello. This allows its peer 395 to include a hash of its identity assertion. An endpoint without an 396 identity assertion MUST omit the "webrtc_id_hash" extension from its 397 ServerHello or EncryptedExtensions message. 399 A peer that receives a "webrtc_id_hash" extension that is not equal 400 to the value of the identity assertion from its peer MUST immediately 401 fail the TLS handshake with an error. This includes cases where the 402 "identity" attribute is not present in the SDP. 404 A "webrtc_id_hash" extension that is any length other than 0 or 32 is 405 invalid and MUST cause the receiving endpoint to generate a fatal 406 "decode_error" alert. 408 A peer that receives an identity assertion, but does not receive a 409 "webrtc_id_hash" extension MAY choose to fail the connection, though 410 it is expected that implementations that were written prior to the 411 existence of this document will not support these extensions for some 412 time. 414 In TLS 1.3, the "webrtc_id_hash" extension MUST be sent in the 415 EncryptedExtensions message. 417 5. Session Concatenation 419 Use of session identifiers does not prevent an attacker from 420 establishing two concurrent sessions with different peers and 421 forwarding signaling from those peers to each other. Concatenating 422 two signaling sessions creates a situation where both peers believe 423 that they are talking to the attacker when they are talking to each 424 other. 426 Session concatention is possible at higher layers: an attacker can 427 establish two independent sessions and simply forward any data it 428 receives from one into the other. This kind of attack is prevented 429 by systems that enable peer authentication such as WebRTC identity 430 [I-D.ietf-rtcweb-security-arch] or SIP identity [RFC4474]. 432 In the absence of any higher-level concept of peer identity, the use 433 of session identifiers does not prevent session concatenation. The 434 value to an attacker is limited unless information from the TLS 435 connection is extracted and used with the signaling. For instance, a 436 key exporter [RFC5705] might be used to create a shared secret or 437 unique identifier that is used in a secondary protocol. 439 If a secondary protocol uses the signaling channel with the 440 assumption that the signaling and TLS peers are the same then that 441 protocol is vulnerable to attack. The identity of the peer at the 442 TLS layer is not guaranteed to be the same as the identity of the 443 signaling peer. 445 It is important to note that multiple connections can be created 446 within the same signaling session. An attacker might concatenate 447 only part of a session, choosing to terminate some connections (and 448 optionally forward data) while arranging to have peers interact 449 directly for other connections. It is even possible to have 450 different peers interact for each connection. This means that the 451 actual identity of the peer for one connection might differ from the 452 peer on another connection. 454 Information extracted from a TLS connection therefore MUST NOT be 455 used in a secondary protocol outside of that connection if that 456 protocol relies on the signaling protocol having the same peers. 457 Similarly, data from one TLS connection MUST NOT be used in other TLS 458 connections even if they are established as a result of the same 459 signaling session. 461 6. Security Considerations 463 This entire document contains security considerations. 465 7. IANA Considerations 467 This document registers two extensions in the TLS "ExtensionType 468 Values" registry established in [RFC5246]: 470 o The "sdp_tls_id" extension has been assigned a code point of TBD; 471 it is recommended and is marked as "Encrypted" in TLS 1.3. 473 o The "webrtc_id_hash" extension has been assigned a code point of 474 TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. 476 8. References 478 8.1. Normative References 480 [FIPS180-2] 481 Department of Commerce, National., "NIST FIPS 180-2, 482 Secure Hash Standard", August 2002. 484 [I-D.ietf-mmusic-dtls-sdp] 485 Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer 486 Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-23 (work 487 in progress), April 2017. 489 [I-D.ietf-rtcweb-security-arch] 490 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 491 rtcweb-security-arch-12 (work in progress), June 2016. 493 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 494 RFC 20, DOI 10.17487/RFC0020, October 1969, 495 . 497 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 498 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 499 2003, . 501 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 502 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 503 RFC 3711, DOI 10.17487/RFC3711, March 2004, 504 . 506 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 507 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 508 July 2006, . 510 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 511 Transport Layer Security (TLS) Protocol in the Session 512 Description Protocol (SDP)", RFC 4572, 513 DOI 10.17487/RFC4572, July 2006, 514 . 516 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 517 (TLS) Protocol Version 1.2", RFC 5246, 518 DOI 10.17487/RFC5246, August 2008, 519 . 521 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 522 for Establishing a Secure Real-time Transport Protocol 523 (SRTP) Security Context Using Datagram Transport Layer 524 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 525 2010, . 527 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 528 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 529 January 2012, . 531 8.2. Informative References 533 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 534 Jacobson, "RTP: A Transport Protocol for Real-Time 535 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 536 July 2003, . 538 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 539 Authenticated Identity Management in the Session 540 Initiation Protocol (SIP)", RFC 4474, 541 DOI 10.17487/RFC4474, August 2006, 542 . 544 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 545 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 546 . 548 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 549 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 550 March 2010, . 552 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 553 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 554 2014, . 556 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 557 authenticated Diffie-Hellman and its use in the IKE 558 protocols", Annual International Cryptology Conference, 559 Springer, pp. 400-425 , 2003. 561 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 562 Attacks on the Station-to-Station (STS) Protocol", Lecture 563 Notes in Computer Science 1560, Springer, pp. 154-170 , 564 1999. 566 [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., 567 and B. Aboba, "WebRTC 1.0: Real-time Communication Between 568 Browsers", W3C WD-webrtc-30160531 , May 2016. 570 Appendix A. Acknowledgements 572 This problem would not have been discovered if it weren't for 573 discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A 574 solution similar to the one presented here was first proposed by 575 Karthik Bhargavan who provided valuable input on this document. 576 Thyla van der Merwe assisted with a formal model of the solution. 577 Adam Roach and Paul E. Jones provided useful review and input. 579 Authors' Addresses 581 Martin Thomson 582 Mozilla 584 Email: martin.thomson@gmail.com 586 Eric Rescorla 587 Mozilla 589 Email: ekr@rftm.com