idnits 2.17.1 draft-ietf-mmusic-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 315: '...on_id" extension MUST NOT be included ...' RFC 2119 keyword, line 318: '... Endpoints MUST check that the "id" ...' RFC 2119 keyword, line 323: '... that it expects MUST abort the connec...' RFC 2119 keyword, line 329: '... endpoint MAY choose to continue a s...' RFC 2119 keyword, line 333: '...sion_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 (January 31, 2018) is 2277 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) == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-13 ** 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' -- 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: August 4, 2018 January 31, 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-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 https://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 August 4, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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 (https://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 external_session_id TLS Extension . . . . . . . . . . 7 60 4. WebRTC Identity Binding . . . . . . . . . . . . . . . . . . . 8 61 4.1. The webrtc_id_hash TLS Extension . . . . . . . . . . . . 8 62 5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 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 [RFC8122]. 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 [RFC8122]. 86 The design in RFC 8122 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 of 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 fingerprint of one peer for its own, an attacker 122 is able to cause a session to be established where one endpoint has 123 an incorrect value for the identity of its peer. However, the peer 124 does not suffer any such confusion, resulting in each peer involved 125 in the session having a different view of the nature of the session. 127 This attack applies to any communications established based on the 128 SDP "fingerprint" attribute [RFC8122]. 130 2.1. Attack Overview 132 This vulnerability can be used by an attacker to create a session 133 where 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 "tls-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 "external_session_id" extension is added to the TLS or DTLS 279 handshake for connections that are established as part of the same 280 call or real-time session. This carries the value of the "tls-id" 281 attribute and provides integrity protection for its exchange as part 282 of the TLS or DTLS handshake. 284 3.1. The external_session_id TLS Extension 286 The "external_session_id" TLS extension carries the unique identifier 287 that an endpoint selects. When used with SDP, the value includes the 288 "tls-id" attribute from the SDP that the endpoint generated when 289 negotiating the session. This document only defines use of this 290 extensions for SDP; other methods of external session negotiation can 291 use this extension to include a unique session identifier. 293 The "extension_data" for the "external_session_id" extension contains 294 a ExternalSessionId struct, described below using the syntax defined 295 in [RFC5246]: 297 struct { 298 opaque id<20..255>; 299 } ExternalSessionId; 301 For SDP, the "id" field of the extension includes the value of the 302 "tls-id" SDP attribute as defined in [I-D.ietf-mmusic-dtls-sdp] (that 303 is, the "tls-id-value" ABNF production). The value of the "tls-id" 304 attribute is encoded using ASCII [RFC0020]. 306 Where RTP and RTCP [RFC3550] are not multiplexed, it is possible that 307 the two separate DTLS connections carrying RTP and RTCP can be 308 switched. This is considered benign since these protocols are 309 usually distinguishable. RTP/RTCP multiplexing is advised to address 310 this problem. 312 The "external_session_id" extension is included in a ClientHello and 313 either ServerHello (for TLS and DTLS versions less than 1.3) or 314 EncryptedExtensions (for TLS 1.3). In TLS 1.3, the 315 "external_session_id" extension MUST NOT be included in a 316 ServerHello. 318 Endpoints MUST check that the "id" parameter in the extension that 319 they receive includes the "tls-id" attribute value that they received 320 in their peer's session description. Comparison can be performed 321 with either the decoded ASCII string or the encoded octets. An 322 endpoint that receives a "external_session_id" extension that is not 323 identical to the value that it expects MUST abort the connection with 324 a fatal "handshake_failure" alert. 326 An endpoint that is communicating with a peer that does not support 327 this extension will receive a ClientHello, ServerHello or 328 EncryptedExtensions that does not include this extension. An 329 endpoint MAY choose to continue a session without this extension in 330 order to interoperate with peers that do not implement this 331 specification. 333 In TLS 1.3, the "external_session_id" extension MUST be sent in the 334 EncryptedExtensions message. 336 4. WebRTC Identity Binding 338 The identity assertion used for WebRTC 339 [I-D.ietf-rtcweb-security-arch] is bound only to the certificate 340 fingerprint of an endpoint and can therefore be copied by an attacker 341 along with any SDP "fingerprint" attributes. 343 The problem is compounded by the fact that an identity provider is 344 not required to verify that the entity requesting an identity 345 assertion controls the keys. Nor is it currently able to perform 346 this validation. This is not an issue because verification is not a 347 necessary condition for a secure protocol, nor would it be sufficient 348 as established in [SIGMA]. 350 A simple solution to this problem is suggested by [SIGMA]. The 351 identity of endpoints is included under a message authentication code 352 (MAC) during the cryptographic handshake. Endpoints are then 353 expected to validate that their peer has provided an identity that 354 matches their expectations. 356 In TLS, the Finished message provides a MAC over the entire 357 handshake, so that including the identity in a TLS extension is 358 sufficient to implement this solution. Rather than include a 359 complete identity assertion - which could be sizeable - a collision- 360 resistant hash of the identity assertion is included in a TLS 361 extension. Peers then need only validate that the extension contains 362 a hash of the identity assertion they received in signaling in 363 addition to validating the identity assertion. 365 Endpoints MAY use the "external_session_id" extension in addition to 366 this so that two calls between the same parties can't be altered by 367 an attacker. 369 4.1. The webrtc_id_hash TLS Extension 371 The "webrtc_id_hash" TLS extension carries a hash of the identity 372 assertion that communicating peers have exchanged. 374 The "extension_data" for the "webrtc_id_hash" extension contains a 375 WebrtcIdentityHash struct, described below using the syntax defined 376 in [RFC5246]: 378 struct { 379 opaque assertion_hash<0..32>; 380 } WebrtcIdentityHash; 382 A WebRTC identity assertion is provided as a JSON [RFC7159] object 383 that is encoded into a JSON text. The resulting string is then 384 encoded using UTF-8 [RFC3629]. The content of the "webrtc_id_hash" 385 extension are produced by hashing the resulting octets with SHA-256 386 [SHA]. This produces the 32 octets of the assertion_hash parameter, 387 which is the sole contents of the extension. 389 The SDP "identity" attribute includes the base64 [RFC4648] encoding 390 of the same octets that were input to the hash. The "webrtc_id_hash" 391 extension is validated by performing base64 decoding on the value of 392 the SDP "identity" attribute, hashing the resulting octets using SHA- 393 256, and comparing the results with the content of the extension. 395 Identity assertions might be provided by only one peer. An endpoint 396 that does not produce an identity assertion MUST generate an empty 397 "webrtc_id_hash" extension in its ClientHello. This allows its peer 398 to include a hash of its identity assertion. An endpoint without an 399 identity assertion MUST omit the "webrtc_id_hash" extension from its 400 ServerHello or EncryptedExtensions message. 402 A peer that receives a "webrtc_id_hash" extension that is not equal 403 to the value of the identity assertion from its peer MUST immediately 404 fail the TLS handshake with an error. This includes cases where the 405 "identity" attribute is not present in the SDP. 407 A "webrtc_id_hash" extension that is any length other than 0 or 32 is 408 invalid and MUST cause the receiving endpoint to generate a fatal 409 "decode_error" alert. 411 A peer that receives an identity assertion, but does not receive a 412 "webrtc_id_hash" extension MAY choose to fail the connection, though 413 it is expected that implementations that were written prior to the 414 existence of this document will not support these extensions for some 415 time. 417 In TLS 1.3, the "webrtc_id_hash" extension MUST be sent in the 418 EncryptedExtensions message. 420 5. Session Concatenation 422 Use of session identifiers does not prevent an attacker from 423 establishing two concurrent sessions with different peers and 424 forwarding signaling from those peers to each other. Concatenating 425 two signaling sessions creates a situation where both peers believe 426 that they are talking to the attacker when they are talking to each 427 other. 429 Session concatention is possible at higher layers: an attacker can 430 establish two independent sessions and simply forward any data it 431 receives from one into the other. This kind of attack is prevented 432 by systems that enable peer authentication such as WebRTC identity 433 [I-D.ietf-rtcweb-security-arch] or SIP identity [RFC4474]. 435 In the absence of any higher-level concept of peer identity, the use 436 of session identifiers does not prevent session concatenation. The 437 value to an attacker is limited unless information from the TLS 438 connection is extracted and used with the signaling. For instance, a 439 key exporter [RFC5705] might be used to create a shared secret or 440 unique identifier that is used in a secondary protocol. 442 If a secondary protocol uses the signaling channel with the 443 assumption that the signaling and TLS peers are the same then that 444 protocol is vulnerable to attack. The identity of the peer at the 445 TLS layer is not guaranteed to be the same as the identity of the 446 signaling peer. 448 It is important to note that multiple connections can be created 449 within the same signaling session. An attacker might concatenate 450 only part of a session, choosing to terminate some connections (and 451 optionally forward data) while arranging to have peers interact 452 directly for other connections. It is even possible to have 453 different peers interact for each connection. This means that the 454 actual identity of the peer for one connection might differ from the 455 peer on another connection. 457 Information extracted from a TLS connection therefore MUST NOT be 458 used in a secondary protocol outside of that connection if that 459 protocol relies on the signaling protocol having the same peers. 460 Similarly, data from one TLS connection MUST NOT be used in other TLS 461 connections even if they are established as a result of the same 462 signaling session. 464 6. Security Considerations 466 This entire document contains security considerations. 468 7. IANA Considerations 470 This document registers two extensions in the TLS "ExtensionType 471 Values" registry established in [RFC5246]: 473 o The "external_session_id" extension has been assigned a code point 474 of TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. 476 o The "webrtc_id_hash" extension has been assigned a code point of 477 TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. 479 8. References 481 8.1. Normative References 483 [I-D.ietf-mmusic-dtls-sdp] 484 Holmberg, C. and R. Shpount, "Session Description Protocol 485 (SDP) Offer/Answer Considerations for Datagram Transport 486 Layer Security (DTLS) and Transport Layer Security (TLS)", 487 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 488 2017. 490 [I-D.ietf-rtcweb-security-arch] 491 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 492 rtcweb-security-arch-13 (work in progress), October 2017. 494 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 495 RFC 20, DOI 10.17487/RFC0020, October 1969, 496 . 498 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 499 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 500 2003, . 502 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 503 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 504 RFC 3711, DOI 10.17487/RFC3711, March 2004, 505 . 507 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 508 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 509 July 2006, . 511 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 512 (TLS) Protocol Version 1.2", RFC 5246, 513 DOI 10.17487/RFC5246, August 2008, 514 . 516 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 517 for Establishing a Secure Real-time Transport Protocol 518 (SRTP) Security Context Using Datagram Transport Layer 519 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 520 2010, . 522 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 523 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 524 January 2012, . 526 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 527 Transport over the Transport Layer Security (TLS) Protocol 528 in the Session Description Protocol (SDP)", RFC 8122, 529 DOI 10.17487/RFC8122, March 2017, 530 . 532 [SHA] Dang, Q., "Secure Hash Standard", National Institute of 533 Standards and Technology report, 534 DOI 10.6028/nist.fips.180-4, July 2015. 536 8.2. Informative References 538 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 539 Jacobson, "RTP: A Transport Protocol for Real-Time 540 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 541 July 2003, . 543 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 544 Authenticated Identity Management in the Session 545 Initiation Protocol (SIP)", RFC 4474, 546 DOI 10.17487/RFC4474, August 2006, 547 . 549 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 550 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 551 . 553 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 554 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 555 March 2010, . 557 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 558 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 559 2014, . 561 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 562 authenticated Diffie-Hellman and its use in the IKE 563 protocols", Annual International Cryptology Conference, 564 Springer, pp. 400-425 , 2003. 566 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 567 Attacks on the Station-to-Station (STS) Protocol", Lecture 568 Notes in Computer Science 1560, Springer, pp. 154-170 , 569 1999. 571 [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., 572 and B. Aboba, "WebRTC 1.0: Real-time Communication Between 573 Browsers", W3C WD-webrtc-30160531 , May 2016. 575 Appendix A. Acknowledgements 577 This problem would not have been discovered if it weren't for 578 discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A 579 solution similar to the one presented here was first proposed by 580 Karthik Bhargavan who provided valuable input on this document. 581 Thyla van der Merwe assisted with a formal model of the solution. 582 Adam Roach and Paul E. Jones provided useful review and input. 584 Authors' Addresses 586 Martin Thomson 587 Mozilla 589 Email: martin.thomson@gmail.com 591 Eric Rescorla 592 Mozilla 594 Email: ekr@rftm.com