idnits 2.17.1 draft-thomson-avtcore-sdp-uks-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 311: '... 1.3). In TLS 1.3, the extension MUST...' RFC 2119 keyword, line 314: '... Endpoints MUST check that the "dtls...' RFC 2119 keyword, line 319: '... that it expects MUST abort the connec...' RFC 2119 keyword, line 325: '... endpoint MAY choose to continue a s...' RFC 2119 keyword, line 329: '...dtls_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 (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 374 == Outdated reference: A later version (-32) exists of draft-ietf-mmusic-dtls-sdp-21 == 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 (==), 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: Informational Mozilla 5 Expires: September 14, 2017 March 13, 2017 7 Unknown Key Share Attacks on uses of Transport Layer Security with the 8 Session Description Protocol (SDP) 9 draft-thomson-avtcore-sdp-uks-01 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 September 14, 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_dtls_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 the TLS or 80 DTLS handshaking protocol, with authentication being tied back to the 81 session description (or SDP) through the use of certificate 82 fingerprints. Communication peers check that a hash, or fingerprint, 83 provided in the SDP matches the certificate that is used in the TLS 84 (or DTLS) handshake. This is defined in [RFC4572]. 86 The design of DTLS-SRTP 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 DTLS-SRTP, an endpoint is able to acquire the certificate 110 fingerprint another entity. By advertising that fingerprint in place 111 of one of its own, the malicious endpoint can cause its peer to 112 communicate with a different peer, even though it believes that it is 113 communicating with the malicious endpoint. 115 When the identity of communicating peers is established by higher- 116 layer signaling constructs, such as those in SIP [RFC4474] or WebRTC 117 [I-D.ietf-rtcweb-security-arch], this allows an attacker to bind 118 their own identity to a session with any other entity. 120 By substituting the the fingerprint of one peer for its own, an 121 attacker is able to cause a session to be established where one 122 endpoint has an incorrect value for the identity of its peer. 123 However, the peer does not suffer any such confusion, resulting in 124 each peer involved in the session having a different view of the 125 nature of the session. 127 This attack applies to any communications established based on the 128 SDP "fingerprint" attribute [RFC4572]. 130 2.1. Attack Overview 132 This vulnerability can be used by an attacker to create a call where 133 there is confusion about the communicating endpoints. 135 A SIP endpoint or WebRTC endpoint that is configured to reuse a 136 certificate can be attacked if it is willing to conduct two 137 concurrent calls, one of which is with an attacker. The attacker can 138 arrange for the victim to incorrectly believe that is calling the 139 attacker when it is in fact calling a second party. The second party 140 correctly believes that it is talking to the victim. 142 In a related attack, a single call using WebRTC identity can be 143 attacked so that it produces the same outcome. This attack does not 144 require a concurrent call. 146 2.2. Limits on Attack Feasibility 148 The use of TLS with SDP depends on the integrity of session 149 signaling. Assuming signaling integrity limits the capabilities of 150 an attacker in several ways. In particular: 152 1. An attacker can only modify the parts of the session signaling 153 for a session that they are part of, which is limited to their 154 own offers and answers. 156 2. No entity will complete communications with a peer unless they 157 are willing to participate in a session with that peer. 159 The combination of these two constraints make the spectrum of 160 possible attacks quite limited. An attacker is only able to switch 161 its own certificate fingerprint for a valid certificate that is 162 acceptable to its peer. Attacks therefore rely on joining two 163 separate sessions into a single session. 165 The second condition is not necessary with WebRTC identity if the 166 victim has or is configured with a target peer identity (this is 167 defined in [WEBRTC]). Furthermore, any identity displayed by a 168 browser could be different to the identity used by the application, 169 since the attack affects the browser's understanding of the peer's 170 identity. 172 2.3. Example 174 In this example, two outgoing sessions are created by the same 175 endpoint. One of those sessions is initiated with the attacker, 176 another session is created toward another honest endpoint. The 177 attacker convinces the endpoint that their session has completed, and 178 that the session with the other endpoint has succeeded. 180 Norma Mallory Patsy 181 (fp=N) ----- (fp=P) 182 | | | 183 +---Offer1 (fp=N)--->| | 184 +-----Offer2 (fp=N)-------------------->| 185 |<--------------------Answer2 (fp=P)----+ 186 |<--Answer1 (fp=P)---+ | 187 | | | 188 |======DTLS1====>(Forward)====DTLS1====>| 189 |<=====DTLS2=====(Forward)<===DTLS2=====| 190 |======Media1===>(Forward)====Media1===>| 191 |<=====Media2====(Forward)<===Media2====| 192 | | | 193 |======DTLS2===========>(Drop) | 194 | | | 196 In this case, Norma is willing to conduct two concurrent sessions. 197 The first session is established with Mallory, who falsely uses 198 Patsy's certificate fingerprint. A second session is initiated 199 between Norma and Patsy. Signaling for both sessions is permitted to 200 complete. 202 Once complete, the session that is ostensibly between Mallory and 203 Norma is completed by forwarding packets between Norma and Patsy. 204 This requires that Mallory is able to intercept DTLS and media 205 packets from Patsy so that they can be forwarded to Norma at the 206 transport addresses that Norma associates with the first session. 208 The second session - between Norma and Patsy - is permitted to 209 continue to the point where Patsy believes that it has succeeded. 210 This ensures that Patsy believes that she is communicating with 211 Norma. In the end, Norma believes that she is communicating with 212 Mallory, when she is actually communicating with Patsy. 214 Though Patsy needs to believe that the second session is successful, 215 Mallory has no real interest in seeing that session complete. 216 Mallory only needs to ensure that Patsy does not abandon the session 217 prematurely. For this reason, it might be necessary to permit the 218 answer from Patsy to reach Norma to allow Patsy to receive a call 219 completion signal, such as a SIP ACK. Once the second session 220 completes, Mallory causes any DTLS packets sent by Norma to Patsy to 221 be dropped. 223 For the attacked session to be sustained beyond the point that Norma 224 detects errors in the second session, Mallory also needs to block any 225 signaling that Norma might send to Patsy asking for the call to be 226 abandoned. Otherwise, Patsy might receive a notice that the call is 227 failed and thereby abort the call. 229 This attack creates an asymmetry in the beliefs about the identity of 230 peers. However, this attack is only possible if the victim (Norma) 231 is willing to conduct two sessions concurrently, and if the same 232 certificate - and therefore SDP "fingerprint" attribute value - is 233 used in both sessions. 235 2.4. Interactions with Key Continuity 237 Systems that use key continuity might be able to detect an unknown 238 key-share attack if a session with the actual peer (i.e., Patsy in 239 the example) was established in the past. Whether this is possible 240 depends on how key continuity is implemented. 242 Implementations that maintain a single database of identities with an 243 index on peer keys could discover that the identity saved for the 244 peer key does not match the claimed identity. Such an implementation 245 could notice the disparity between the actual keys (Patsy) and the 246 expected keys (Mallory). 248 In comparison, implementations that first match based on peer 249 identity could treat an unknown key-share attack as though their peer 250 had used a newly-configured device. The apparent addition of a new 251 device could generate user-visible notices (e.g., "Mallory appears to 252 have a new device"). However, such an event is not always considered 253 alarming; some implementations might silently save a new key. 255 3. Adding a Session Identifier 257 An attack on DTLS-SRTP is possible because the identity of peers 258 involved is not established prior to establishing the call. 259 Endpoints use certificate fingerprints as a proxy for authentication, 260 but as long as fingerprints are used in multiple calls, they are 261 vulnerable to attacks of the sort described. 263 The solution to this problem is to assign a new identifier to 264 communicating peers. Each endpoint assigns their peer a unique 265 identifier during call signaling. The peer echoes that identifier in 266 the TLS handshake, binding that identity into the session. Including 267 this new identity in the TLS handshake means that it will be covered 268 by the TLS Finished message, which is necessary to authenticate it 269 (see [SIGMA]). Validating that peers use the correct identifier then 270 means that the session is established between the correct two 271 endpoints. 273 This solution relies on the unique identifier given to DTLS sessions 274 using the SDP "dtls-id" attribute [I-D.ietf-mmusic-dtls-sdp]. This 275 field is already required to be unique. Thus, no two offers or 276 answers from the same client will have the same value. 278 A new "sdp_dtls_id" extension is added to the TLS or DTLS handshake 279 for connections that are established as part of the same call or 280 real-time session. This carries the value of the "dtls-id" attribute 281 and provides integrity protection for its exchange as part of the TLS 282 or DTLS handshake. 284 3.1. The sdp_dtls_id TLS Extension 286 The "sdp_dtls_id" TLS extension carries the unique identifier that an 287 endpoint selects. The value includes the "sess-id" field from the 288 SDP that the endpoint generated when negotiating the session. 290 The "extension_data" for the "sdp_dtls_id" extension contains a 291 SdpDtlsId struct, described below using the syntax defined in 292 [RFC5246]: 294 struct { 295 opaque dtls_id<1..255>; 296 } SdpDtlsId; 298 The "dtls_id" field of the extension includes the value of the "dtls- 299 id" SDP attribute as defined in [I-D.ietf-mmusic-dtls-sdp] (that is, 300 the "dtls-id-value" ABNF production). The value of the "dtls-id" 301 attribute is encoded using ASCII [RFC0020]. 303 Where RTP and RTCP [RFC3550] are not multiplexed, it is possible that 304 the two separate DTLS connections carrying RTP and RTCP can be 305 switched. This is considered benign since these protocols are often 306 distinguishable. RTP/RTCP multiplexing is advised to address this 307 problem. 309 The "sdp_dtls_id" extension is included in a ClientHello and either 310 ServerHello (for TLS and DTLS versions less than 1.3) or 311 EncryptedExtensions (for TLS 1.3). In TLS 1.3, the extension MUST 312 NOT be included in a ServerHello. 314 Endpoints MUST check that the "dtls_id" parameter in the extension 315 that they receive includes the "dtls-id" attribute value that they 316 received in their peer's session description. Comparison can be 317 performed with either the decoded ASCII string or the encoded octets. 318 An endpoint that receives a "sdp_dtls_id" extension that is not 319 identical to the value that it expects MUST abort the connection with 320 a fatal "handshake_failure" alert. 322 An endpoint that is communicating with a peer that does not support 323 this extension will receive a ClientHello, ServerHello or 324 EncryptedExtensions that does not include this extension. An 325 endpoint MAY choose to continue a session without this extension in 326 order to interoperate with peers that do not implement this 327 specification. 329 In TLS 1.3, the "sdp_dtls_id" extension MUST be sent in the 330 EncryptedExtensions message. 332 4. WebRTC Identity Binding 334 The identity assertion used for WebRTC 335 [I-D.ietf-rtcweb-security-arch] is bound only to the certificate 336 fingerprint of an endpoint and can therefore be copied by an attacker 337 along with any SDP "fingerprint" attributes. 339 The problem is compounded by the fact that an identity provider is 340 not required to verify that the entity requesting an identity 341 assertion controls the keys. Nor is it currently able to perform 342 this validation. Note however that this verification is not a 343 necessary condition for a secure protocol, as established in [SIGMA]. 345 A simple solution to this problem is suggested by [SIGMA]. The 346 identity of endpoints is included under a message authentication code 347 (MAC) during the cryptographic handshake. Endpoints are then 348 expected to validate that their peer has provided an identity that 349 matches their expectations. 351 In TLS, the Finished message provides a MAC over the entire 352 handshake, so that including the identity in a TLS extension is 353 sufficient to implement this solution. Rather than include a 354 complete identity assertion, a collision-resistant hash of the 355 identity assertion is included in a TLS extension. Peers then need 356 only validate that the extension contains a hash of the identity 357 assertion they received in signaling in addition to validating the 358 identity assertion. 360 Endpoints MAY use the "sdp_dtls_id" extension in addition to this so 361 that two calls between the same parties can't be altered by an 362 attacker. 364 4.1. The webrtc_id_hash TLS Extension 366 The "webrtc_id_hash" TLS extension carries a hash of the identity 367 assertion that communicating peers have exchanged. 369 The "extension_data" for the "webrtc_id_hash" extension contains a 370 WebrtcIdentityHash struct, described below using the syntax defined 371 in [RFC5246]: 373 struct { 374 opaque assertion_hash[32]; 375 } WebrtcIdentityHash; 377 A WebRTC identity assertion is provided as a JSON [RFC7159] object 378 that is encoded into a JSON text. The resulting string is then 379 encoded using UTF-8 [RFC3629]. The content of the "webrtc_id_hash" 380 extension are produced by hashing the resulting octets with SHA-256 381 [FIPS180-2]. This produces the 32 octets of the assertion_hash 382 parameter, which is the sole contents of the extension. 384 The SDP "identity" attribute includes the base64 [RFC4648] encoding 385 of the same octets that were input to the hash. The "webrtc_id_hash" 386 extension is validated by performing base64 decoding on the value of 387 the SDP "identity" attribute, hashing the resulting octets using SHA- 388 256, and comparing the results with the content of the extension. 390 Identity assertions might be provided by only one peer. An endpoint 391 that does not produce an identity assertion MUST generate an empty 392 "webrtc_id_hash" extension in its ClientHello. This allows its peer 393 to include a hash of its identity assertion. An endpoint without an 394 identity assertion MUST omit the "webrtc_id_hash" extension from its 395 ServerHello or EncryptedExtensions message. 397 A peer that receives a "webrtc_id_hash" extension that is not equal 398 to the value of the identity assertion from its peer MUST immediately 399 fail the TLS handshake with an error. This includes cases where the 400 "a=identity" attribute is not present in the SDP. 402 A peer that receives an identity assertion, but does not receive a 403 "webrtc_id_hash" extension MAY choose to fail the connection, though 404 it is expected that implementations that were written prior to the 405 existence of this document will not support these extensions for some 406 time. 408 In TLS 1.3, the "webrtc_id_hash" extension MUST be sent in the 409 EncryptedExtensions message. 411 5. Session Concatenation 413 Use of session identifiers does not prevent an attacker from 414 establishing two concurrent sessions with different peers and 415 forwarding signaling from those peers to each other. Concatenating 416 two signaling sessions creates a situation where both peers believe 417 that they are talking to the attacker when they are talking to each 418 other. 420 Session concatention is possible at higher layers: an attacker can 421 establish two independent sessions and simply forward any data it 422 receives from one into the other. This kind of attack is prevented 423 by systems that enable peer authentication such as WebRTC identity 424 [I-D.ietf-rtcweb-security-arch] or SIP identity [RFC4474]. 426 In the absence of any higher-level concept of peer identity, the use 427 of session identifiers does not prevent session concatenation. The 428 value to an attacker is limited unless information from the TLS 429 connection is extracted and used with the signaling. For instance, a 430 key exporter [RFC5705] might be used to create a shared secret or 431 unique identifier that is used in a secondary protocol. 433 If a secondary protocol uses the signaling channel with the 434 assumption that the signaling and TLS peers are the same then that 435 protocol is vulnerable to attack. The identity of the peer at the 436 TLS layer is not guranteed to be the same as the identity of the 437 signaling peer. 439 It is important to note that multiple connections can be created 440 within the same signaling session. An attacker can concatenate only 441 part of a session, choosing to terminate some connections (and 442 optionally forward data) while arranging to have peers interact 443 directly for other connections. It is even possible to have 444 different peers interact for each connection. This means that the 445 actual identity of the peer for one connection might differ from the 446 peer on another connection. 448 Information extracted from a TLS connection therefore MUST NOT be 449 used in a secondary protocol outside of that connection if that 450 protocol relies on the signaling protocol having the same peers. 451 Similarly, data from one TLS connection MUST NOT be used in other TLS 452 connections even if they are established as a result of the same 453 signaling session. 455 6. Security Considerations 457 This entire document contains security considerations. 459 7. IANA Considerations 461 This document registers two extensions in the TLS "ExtensionType 462 Values" registry established in [RFC5246]: 464 o The "sdp_dtls_id" extension has been assigned a code point of TBD; 465 it is recommended and is marked as "Encrypted" in TLS 1.3. 467 o The "webrtc_id_hash" extension has been assigned a code point of 468 TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. 470 8. References 472 8.1. Normative References 474 [FIPS180-2] 475 Department of Commerce, National., "NIST FIPS 180-2, 476 Secure Hash Standard", August 2002. 478 [I-D.ietf-mmusic-dtls-sdp] 479 Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer 480 Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-21 (work 481 in progress), March 2017. 483 [I-D.ietf-rtcweb-security-arch] 484 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 485 rtcweb-security-arch-12 (work in progress), June 2016. 487 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 488 RFC 20, DOI 10.17487/RFC0020, October 1969, 489 . 491 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 492 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 493 2003, . 495 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 496 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 497 RFC 3711, DOI 10.17487/RFC3711, March 2004, 498 . 500 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 501 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 502 July 2006, . 504 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 505 Transport Layer Security (TLS) Protocol in the Session 506 Description Protocol (SDP)", RFC 4572, 507 DOI 10.17487/RFC4572, July 2006, 508 . 510 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 511 (TLS) Protocol Version 1.2", RFC 5246, 512 DOI 10.17487/RFC5246, August 2008, 513 . 515 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 516 for Establishing a Secure Real-time Transport Protocol 517 (SRTP) Security Context Using Datagram Transport Layer 518 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 519 2010, . 521 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 522 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 523 January 2012, . 525 8.2. Informative References 527 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 528 Jacobson, "RTP: A Transport Protocol for Real-Time 529 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 530 July 2003, . 532 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 533 Authenticated Identity Management in the Session 534 Initiation Protocol (SIP)", RFC 4474, 535 DOI 10.17487/RFC4474, August 2006, 536 . 538 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 539 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 540 . 542 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 543 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 544 March 2010, . 546 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 547 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 548 2014, . 550 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 551 authenticated Diffie-Hellman and its use in the IKE 552 protocols", Annual International Cryptology Conference, 553 Springer, pp. 400-425 , 2003. 555 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 556 Attacks on the Station-to-Station (STS) Protocol", Lecture 557 Notes in Computer Science 1560, Springer, pp. 154-170 , 558 1999. 560 [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., 561 and B. Aboba, "WebRTC 1.0: Real-time Communication Between 562 Browsers", W3C WD-webrtc-30160531 , May 2016. 564 Appendix A. Acknowledgements 566 This problem would not have been discovered if it weren't for 567 discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A 568 solution similar to the one presented here was first proposed by 569 Karthik Bhargavan who provided valuable input on this document. 570 Thyla van der Merwe assisted with a formal model of the solution. 571 Adam Roach and Paul E. Jones provided useful input. 573 Authors' Addresses 575 Martin Thomson 576 Mozilla 578 Email: martin.thomson@gmail.com 580 Eric Rescorla 581 Mozilla 583 Email: ekr@rftm.com