idnits 2.17.1 draft-ietf-mmusic-sdp-uks-07.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 draft header indicates that this document updates RFC8122, but the abstract doesn't seem to directly say this. It does mention RFC8122 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 09, 2019) is 1721 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 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 6234 (ref. 'SHA') Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 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 Updates: 8122 (if approved) Mozilla 5 Intended status: Standards Track August 09, 2019 6 Expires: February 10, 2020 8 Unknown Key Share Attacks on uses of TLS with the Session Description 9 Protocol (SDP) 10 draft-ietf-mmusic-sdp-uks-07 12 Abstract 14 This document describes unknown key-share attacks on the use of 15 Datagram Transport Layer Security for the Secure Real-Time Transport 16 Protocol (DTLS-SRTP). Similar attacks are described on the use of 17 DTLS-SRTP with the identity bindings used in Web Real-Time 18 Communications (WebRTC) and SIP identity. These attacks are 19 difficult to mount, but they cause a victim to be mislead about the 20 identity of a communicating peer. Mitigation techniques are defined 21 that implementations of RFC 8122 are encouraged to deploy. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 10, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 59 2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 60 2.2. Interactions with Key Continuity . . . . . . . . . . . . 5 61 2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5 62 3. Unknown Key-Share with Identity Bindings . . . . . . . . . . 6 63 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8 65 3.2.1. Calculating external_id_hash for WebRTC Identity . . 9 66 3.2.2. Calculating external_id_hash for PASSPoRT . . . . . . 10 67 4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 10 68 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12 70 4.3. The external_session_id TLS Extension . . . . . . . . . . 13 71 5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 8.2. Informative References . . . . . . . . . . . . . . . . . 18 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Introduction 82 The use of Transport Layer Security (TLS) [TLS13] with the Session 83 Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. 84 Further use with Datagram Transport Layer Security (DTLS) [DTLS] and 85 the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as 86 DTLS-SRTP [DTLS-SRTP]. 88 In these specifications, key agreement is performed using TLS or 89 DTLS, with authentication being tied back to the session description 90 (or SDP) through the use of certificate fingerprints. Communication 91 peers check that a hash, or fingerprint, provided in the SDP matches 92 the certificate that is used in the TLS or DTLS handshake. 94 WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity 95 [SIP-ID] both provide a mechanism that binds an external identity to 96 the certificate fingerprints from a session description. However, 97 this binding is not integrity-protected and therefore vulnerable to 98 an identity misbinding attack - or unknown key-share (UKS) attack - 99 where the attacker binds their identity to the fingerprint of another 100 entity. A successful attack leads to the creation of sessions where 101 peers are confused about the identity of the participants. 103 This document describes a TLS extension that can be used in 104 combination with these identity bindings to prevent this attack. 106 A similar attack is possible with the use of certificate fingerprints 107 alone. Though attacks in this setting are likely infeasible in 108 existing deployments due to the narrow conditions necessary (see 109 Section 2.1), this document also describes mitigations for this 110 attack. 112 The mechanisms defined in this document are intended to strengthen 113 the protocol by preventing the use of unknown key shares in 114 combination with other protocol or implementation vulnerabilities. 115 RFC 8122 [FINGERPRINT] is updated by this document to recommend the 116 use of these mechanisms. 118 This document assumes that signaling is integrity protected. 119 However, as Section 7 of [FINGERPRINT] explains, many deployments 120 that use SDP do not guarantee integrity of session signaling and so 121 are vulnerable to other attacks. [FINGERPRINT] offers key continuity 122 mechanisms as a potential means of reducing exposure to attack in the 123 absence of integrity protection. Section 2.2 provides some analysis 124 of the effect of key continuity in relation to the described attacks. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 2. Unknown Key-Share Attack 134 In an unknown key-share attack [UKS], a malicious participant in a 135 protocol claims to control a key that is in reality controlled by 136 some other actor. This arises when the identity associated with a 137 key is not properly bound to the key. 139 An endpoint that can acquire the certificate fingerprint of another 140 entity can advertise that fingerprint as their own in SDP. An 141 attacker can use a copy of that fingerprint to cause a victim to 142 communicate with another unaware victim, even though it believes that 143 it is communicating with the attacker. 145 When the identity of communicating peers is established by higher- 146 layer signaling constructs, such as those in SIP identity [SIP-ID] or 147 WebRTC [WEBRTC-SEC], this allows an attacker to bind their own 148 identity to a session with any other entity. 150 The attacker obtains an identity assertion for an identity it 151 controls, but binds that to the fingerprint of one peer. The 152 attacker is then able to cause a TLS connection to be established 153 where two victim endpoints communicate. The victim that has its 154 fingerprint copied by the attack correctly believes that it is 155 communicating with the other victim; however, the other victim 156 incorrectly believes that it is communicating with the attacker. 158 An unknown key-share attack does not result in the attacker having 159 access to any confidential information exchanged between victims. 160 However, the failure in mutual authentication can enable other 161 attacks. A victim might send information to the wrong entity as a 162 result. Where information is interpreted in context, misrepresenting 163 that context could lead to the information being misinterpreted. 165 A similar attack can be mounted based solely on the SDP "fingerprint" 166 attribute [FINGERPRINT] without compromising the integrity of the 167 signaling channel. 169 This attack is an aspect of SDP-based protocols that the technique 170 known as third-party call control (3PCC) [RFC3725] relies on. 3PCC 171 exploits the potential for the identity of a signaling peer to be 172 different than the media peer, allowing the media peer to be selected 173 by the signaling peer. Section 2.3 describes the consequences of the 174 mitigations described here for systems that use 3PCC. 176 2.1. Limits on Attack Feasibility 178 The use of TLS with SDP depends on the integrity of session 179 signaling. Assuming signaling integrity limits the capabilities of 180 an attacker in several ways. In particular: 182 1. An attacker can only modify the parts of the session signaling 183 that they are responsible for producing, namely their own offers 184 and answers. 186 2. No entity will successfully establish a session with a peer 187 unless they are willing to participate in a session with that 188 peer. 190 The combination of these two constraints make the spectrum of 191 possible attacks quite limited. An attacker is only able to switch 192 its own certificate fingerprint for a valid certificate that is 193 acceptable to its peer. Attacks therefore rely on joining two 194 separate sessions into a single session. Section 4 describes an 195 attack on SDP signaling under these constraints. 197 Systems that rely on strong identity bindings, such as those defined 198 in [WEBRTC] or [SIP-ID], have a different threat model, which admits 199 the possibility of attack by an entity with access to the signaling 200 channel. Attacks under these conditions are more feasible as an 201 attacker is assumed to be able to both observe and modify signaling 202 messages. Section 3 describes an attack that assumes this threat 203 model. 205 2.2. Interactions with Key Continuity 207 Systems that use key continuity (as defined in Section 15.1 of [ZRTP] 208 or as recommended in Section 7 of [FINGERPRINT]) might be able to 209 detect an unknown key-share attack if a session with either the 210 attacker or the genuine peer (i.e., the victim whose fingerprint was 211 copied by an attacker) was established in the past. Whether this is 212 possible depends on how key continuity is implemented. 214 Implementations that maintain a single database of identities with an 215 index on peer keys could discover that the identity saved for the 216 peer key does not match the claimed identity. Such an implementation 217 could notice the disparity between the actual keys (those copied from 218 a victim) and the expected keys (those of the attacker). 220 In comparison, implementations that first match based on peer 221 identity could treat an unknown key-share attack as though their peer 222 had used a newly-configured device. The apparent addition of a new 223 device could generate user-visible notices (e.g., "Mallory appears to 224 have a new device"). However, such an event is not always considered 225 alarming; some implementations might silently save a new key. 227 2.3. Third-Party Call Control 229 Third-party call control (3PCC) [RFC3725] is a technique where a 230 signaling peer establishes a call that is terminated by a different 231 entity. An unknown key-share attack is very similar in effect to 232 some 3PCC practices, so use of 3PCC could appear to be an attack. 233 However, 3PCC that follows RFC 3725 guidance is unaffected, and peers 234 that are aware of changes made by a 3PCC controller can correctly 235 distinguish actions of a 3PCC controller from attack. 237 3PCC as described in RFC 3725 is incompatible with SIP identity 238 [SIP-ID] as SIP Identity relies on creating a binding between SIP 239 requests and SDP. The controller is the only entity that generates 240 SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use 241 of the "fingerprint" attribute without additional bindings or WebRTC 242 identity [WEBRTC-SEC] is possible. 244 The attack mitigation mechanisms described in this document will 245 prevent the use of 3PCC if peers have different views of the involved 246 identities, or the value of SDP "tls-id" attributes. 248 For 3PCC to work with the proposed mechanisms, TLS peers need to be 249 aware of the signaling so that they can correctly generate and check 250 the TLS extensions. For a connection to be successfully established, 251 a 3PCC controller needs to either forward SDP without modification, 252 or to avoid modifications to "fingerprint", "tls-id", and "identity" 253 attributes. A controller that follows the best practices in RFC 3725 254 is expected to forward SDP without modification, thus ensuring the 255 integrity of these attributes. 257 3. Unknown Key-Share with Identity Bindings 259 The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) 260 and the SIP PASSPoRT used in SIP identity ([SIP-ID], [PASSPoRT]) are 261 bound to the certificate fingerprint of an endpoint. An attacker can 262 cause an identity binding to be created that binds an identity they 263 control to the fingerprint of a first victim. 265 An attacker can thereby cause a second victim to believe that they 266 are communicating with an attacker-controlled identity, when they are 267 really talking to the first victim. The attacker does this by 268 creating an identity assertion that covers a certificate fingerprint 269 of the first victim. 271 A variation on the same technique can be used to cause both victims 272 to both believe they are talking to the attacker when they are 273 talking to each other. In this case, the attacker performs the 274 identity misbinding once for each victim. 276 The problem might appear to be caused by the fact that the authority 277 that certifies the identity binding is not required to verify that 278 the entity requesting the binding controls the keys associated with 279 the fingerprints. SIP and WebRTC identity providers are not required 280 to perform this validation. However, validation of keys by the 281 identity provider is not relevant because verifying control of the 282 associated keys is not a necessary condition for a secure protocol, 283 nor would it be sufficient to prevent attack [SIGMA]. 285 A simple solution to this problem is suggested by [SIGMA]. The 286 identity of endpoints is included under a message authentication code 287 (MAC) during the cryptographic handshake. Endpoints then validate 288 that their peer has provided an identity that matches their 289 expectations. In TLS, the Finished message provides a MAC over the 290 entire handshake, so that including the identity in a TLS extension 291 is sufficient to implement this solution. 293 Rather than include a complete identity binding - which could be 294 sizeable - a collision- and pre-image-resistant hash of the binding 295 is included in a TLS extension as described in Section 3.2. 296 Endpoints then need only validate that the extension contains a hash 297 of the identity binding they received in signaling. If the identity 298 binding is successfully validated, the identity of a peer is verified 299 and bound to the session. 301 This form of unknown key-share attack is possible without 302 compromising signaling integrity, unless the defenses described in 303 Section 4 are used. In order to prevent both forms of attack, 304 endpoints MUST use the "external_session_id" extension (see 305 Section 4.3) in addition to the "external_id_hash" (Section 3.2) so 306 that two calls between the same parties can't be altered by an 307 attacker. 309 3.1. Example 311 In the example shown in Figure 1, it is assumed that the attacker 312 also controls the signaling channel. 314 Mallory (the attacker) presents two victims, Norma and Patsy, with 315 two separate sessions. In the first session, Norma is presented with 316 the option to communicate with Mallory; a second session with Norma 317 is presented to Patsy. 319 Norma Mallory Patsy 320 (fp=N) ----- (fp=P) 321 | | | 322 |<---- Signaling1 ------>| | 323 | Norma=N Mallory=P | | 324 | |<---- Signaling2 ------>| 325 | | Norma=N Patsy=P | 326 | | 327 |<=================DTLS (fp=N,P)=================>| 328 | | 329 (peer = Mallory!) (peer = Norma) 331 Figure 1: Example Attack on Identity Bindings 333 The attack requires that Mallory obtain an identity binding for her 334 own identity with the fingerprints presented by Patsy (P), which 335 Mallory might have obtained previously. This false binding is then 336 presented to Norma (Signaling1 in the figure). 338 Patsy could be similarly duped, but in this example, a correct 339 binding between Norma's identity and fingerprint (N) is faithfully 340 presented by Mallory. This session (Signaling2 in the figure) can be 341 entirely legitimate. 343 A DTLS session is established directly between Norma and Patsy. In 344 order for this to happen Mallory can substitute transport-level 345 information in both sessions to facilitate this, though this is not 346 necessary if Mallory is on the network path between Norma and Patsy. 348 As a result, Patsy correctly believes that she is communicating with 349 Norma. However, Norma incorrectly believes she is talking to 350 Mallory. As stated in Section 2, Mallory cannot access media, but 351 Norma might send information to Patsy that is Norma might not intend 352 or that Patsy might misinterpret. 354 3.2. The external_id_hash TLS Extension 356 The "external_id_hash" TLS extension carries a hash of the identity 357 assertion that the endpoint sending the extension has asserted to its 358 peer. Both peers include a hash of their own identity assertion. 360 The "extension_data" for the "external_id_hash" extension contains a 361 "ExternalIdentityHash" struct, described below using the syntax 362 defined in Section 3 of [TLS13]: 364 struct { 365 opaque binding_hash<0..32>; 366 } ExternalIdentityHash; 368 Where an identity assertion has been asserted by a peer, this 369 extension includes a SHA-256 hash of the assertion. An empty value 370 is used to indicate support for the extension. 372 Note: For both types of identity assertion, if SHA-256 should prove 373 to be inadequate at some point in the future (see [AGILITY]), a 374 new TLS extension can be defined that uses a different hash 375 function. 377 Identity bindings might be provided by only one peer. An endpoint 378 that does not produce an identity binding MUST generate an empty 379 "external_id_hash" extension in its ClientHello or - if a client 380 provides the extension - in ServerHello or EncryptedExtensions. An 381 empty extension has a zero-length binding_hash field. 383 A peer that receives an "external_id_hash" extension that does not 384 match the value of the identity binding from its peer MUST 385 immediately fail the TLS handshake with a illegal_parameter alert. 387 The absence of an identity binding does not relax this requirement; 388 if a peer provided no identity binding, a zero-length extension MUST 389 be present to be considered valid. 391 Implementations written prior to the definition of the extensions in 392 this document will not support this extension for some time. A peer 393 that receives an identity binding but does not receive an 394 "external_id_hash" extension MAY accept a TLS connection rather than 395 fail a connection where the extension is absent. 397 Any validation performed of the "external_id_hash" extension is done 398 in addition to the validation required by [FINGERPRINT] and any 399 identity assertion definition. 401 An "external_id_hash" extension that is any length other than 0 or 32 402 is invalid and MUST cause the receiving endpoint to generate a fatal 403 "decode_error" alert. 405 In TLS 1.3, an "external_id_hash" extension sent by a server MUST be 406 sent in the EncryptedExtensions message. 408 3.2.1. Calculating external_id_hash for WebRTC Identity 410 A WebRTC identity assertion (Section 7 of [WEBRTC-SEC]) is provided 411 as a JSON [JSON] object that is encoded into a JSON text. The JSON 412 text is encoded using UTF-8 [UTF8] as described by Section 8.1 of 413 [JSON]. The content of the "external_id_hash" extension is produced 414 by hashing the resulting octets with SHA-256 [SHA]. This produces 415 the 32 octets of the "binding_hash" parameter, which is the sole 416 contents of the extension. 418 The SDP "identity" attribute includes the base64 [BASE64] encoding of 419 the UTF-8 encoding of the same JSON text. The "external_id_hash" 420 extension is validated by performing base64 decoding on the value of 421 the SDP "identity" attribute, hashing the resulting octets using SHA- 422 256, and comparing the results with the content of the extension. In 423 pseudocode form, using the "identity-assertion-value" field from the 424 "identity" attribute grammar as defined in [WEBRTC-SEC]: 426 "external_id_hash = SHA-256(b64decode(identity-assertion-value)) " 428 Note: The base64 of the SDP "identity" attribute is decoded to avoid 429 capturing variations in padding. The base64-decoded identity 430 assertion could include leading or trailing whitespace octets. 431 WebRTC identity assertions are not canonicalized; all octets are 432 hashed. 434 3.2.2. Calculating external_id_hash for PASSPoRT 436 Where the compact form of PASSPoRT [PASSPoRT] is used, it MUST be 437 expanded into the full form. The base64 encoding used in the SIP 438 Identity (or 'y') header field MUST be decoded then used as input to 439 SHA-256. This produces the 32 octet "binding_hash" value used for 440 creating or validating the extension. In pseudocode, using the 441 "signed-identity-digest" field from the "Identity" grammar defined 442 [SIP-ID]: 444 "external_id_hash = SHA-256(b64decode(signed-identity-digest)) " 446 4. Unknown Key-Share with Fingerprints 448 An attack on DTLS-SRTP is possible because the identity of peers 449 involved is not established prior to establishing the call. 450 Endpoints use certificate fingerprints as a proxy for authentication, 451 but as long as fingerprints are used in multiple calls, they are 452 vulnerable to attack. 454 Even if the integrity of session signaling can be relied upon, an 455 attacker might still be able to create a session where there is 456 confusion about the communicating endpoints by substituting the 457 fingerprint of a communicating endpoint. 459 An endpoint that is configured to reuse a certificate can be attacked 460 if it is willing to initiate two calls at the same time, one of which 461 is with an attacker. The attacker can arrange for the victim to 462 incorrectly believe that it is calling the attacker when it is in 463 fact calling a second party. The second party correctly believes 464 that it is talking to the victim. 466 As with the attack on identity bindings, this can be used to cause 467 two victims to both believe they are talking to the attacker when 468 they are talking to each other. 470 4.1. Example 472 To mount this attack, two sessions need to be created with the same 473 endpoint at almost precisely the same time. One of those sessions is 474 initiated with the attacker, the second session is created toward 475 another honest endpoint. The attacker convinces the first endpoint 476 that their session with the attacker has been successfully 477 established, but media is exchanged with the other honest endpoint. 478 The attacker permits the session with the other honest endpoint to 479 complete only to the extent necessary to convince the other honest 480 endpoint to participate in the attacked session. 482 In addition to the constraints described in Section 2.1, the attacker 483 in this example also needs the ability to view and drop packets 484 between victims. That is, the attacker is on-path for media. 486 The attack shown in Figure 2 depends on a somewhat implausible set of 487 conditions. It is intended to demonstrate what sort of attack is 488 possible and what conditions are necessary to exploit this weakness 489 in the protocol. 491 Norma Mallory Patsy 492 (fp=N) ----- (fp=P) 493 | | | 494 +---Signaling1 (fp=N)--->| | 495 +-----Signaling2 (fp=N)------------------------>| 496 |<-------------------------Signaling2 (fp=P)----+ 497 |<---Signaling1 (fp=P)---+ | 498 | | | 499 |=======DTLS1=======>(Forward)======DTLS1======>| 500 |<======DTLS2========(Forward)<=====DTLS2=======| 501 |=======Media1======>(Forward)======Media1=====>| 502 |<======Media2=======(Forward)<=====Media2======| 503 | | | 504 |=======DTLS2========>(Drop) | 505 | | | 507 Figure 2: Example Attack Scenario using Fingerprints 509 In this scenario, there are two sessions initiated at the same time 510 by Norma. Signaling is shown with single lines ('-'), DTLS and media 511 with double lines ('='). 513 The first session is established with Mallory, who falsely uses 514 Patsy's certificate fingerprint (denoted with 'fp=P'). A second 515 session is initiated between Norma and Patsy. Signaling for both 516 sessions is permitted to complete. 518 Once signaling is complete on the first session, a DTLS connection is 519 established. Ostensibly, this connection is between Mallory and 520 Norma but Mallory forwards DTLS and media packets sent to her by 521 Norma to Patsy. These packets are denoted 'DTLS1' because Norma 522 associates these with the first signaling session ('signaling1'). 524 Mallory also intercepts packets from Patsy and forwards those to 525 Norma at the transport address that Norma associates with Mallory. 526 These packets are denoted 'DTLS2' to indicate that Patsy associates 527 these with the second signaling session ('signaling2'), however Norma 528 will interpret these as being associated with the first signaling 529 session ('signaling1'). 531 The second signaling exchange - 'signaling2', between Norma and Patsy 532 - is permitted to continue to the point where Patsy believes that it 533 has succeeded. This ensures that Patsy believes that she is 534 communicating with Norma. In the end, Norma believes that she is 535 communicating with Mallory, when she is really communicating with 536 Patsy. Just like the example in Section 3.1, Mallory cannot access 537 media, but Norma might send information to Patsy that is Norma might 538 not intend or that Patsy might misinterpret. 540 Though Patsy needs to believe that the second signaling session has 541 been successfully established, Mallory has no real interest in seeing 542 that session also be established. Mallory only needs to ensure that 543 Patsy maintains the active session and does not abandon the session 544 prematurely. For this reason, it might be necessary to permit the 545 signaling from Patsy to reach Norma to allow Patsy to receive a call 546 setup completion signal, such as a SIP ACK. Once the second session 547 is established, Mallory might cause DTLS packets sent by Norma to 548 Patsy to be dropped. However, if Mallory allows DTLS packets to 549 pass, it is likely that Patsy will discard them as Patsy will already 550 have a successful DTLS connection established. 552 For the attacked session to be sustained beyond the point that Norma 553 detects errors in the second session, Mallory also needs to block any 554 signaling that Norma might send to Patsy asking for the call to be 555 abandoned. Otherwise, Patsy might receive a notice that the call is 556 failed and thereby abort the call. 558 This attack creates an asymmetry in the beliefs about the identity of 559 peers. However, this attack is only possible if the victim (Norma) 560 is willing to conduct two sessions nearly simultaneously, if the 561 attacker (Mallory) is on the network path between the victims, and if 562 the same certificate - and therefore SDP "fingerprint" attribute 563 value - is used by Norma for both sessions. 565 Where ICE [ICE] is used, Mallory also needs to ensure that 566 connectivity checks between Patsy and Norma succeed, either by 567 forwarding checks or answering and generating the necessary messages. 569 4.2. Unique Session Identity Solution 571 The solution to this problem is to assign a new identifier to 572 communicating peers. Each endpoint assigns their peer a unique 573 identifier during call signaling. The peer echoes that identifier in 574 the TLS handshake, binding that identity into the session. Including 575 this new identity in the TLS handshake means that it will be covered 576 by the TLS Finished message, which is necessary to authenticate it 577 (see [SIGMA]). 579 Successful validation that the identifier matches the expected value 580 means that the connection corresponds to the signaled session and is 581 therefore established between the correct two endpoints. 583 This solution relies on the unique identifier given to DTLS sessions 584 using the SDP "tls-id" attribute [DTLS-SDP]. This field is already 585 required to be unique. Thus, no two offers or answers from the same 586 client will have the same value. 588 A new "external_session_id" extension is added to the TLS or DTLS 589 handshake for connections that are established as part of the same 590 call or real-time session. This carries the value of the "tls-id" 591 attribute and provides integrity protection for its exchange as part 592 of the TLS or DTLS handshake. 594 4.3. The external_session_id TLS Extension 596 The "external_session_id" TLS extension carries the unique identifier 597 that an endpoint selects. When used with SDP, the value MUST include 598 the "tls-id" attribute from the SDP that the endpoint generated when 599 negotiating the session. This document only defines use of this 600 extension for SDP; other methods of external session negotiation can 601 use this extension to include a unique session identifier. 603 The "extension_data" for the "external_session_id" extension contains 604 an ExternalSessionId struct, described below using the syntax defined 605 in [TLS13]: 607 struct { 608 opaque session_id<20..255>; 609 } ExternalSessionId; 611 For SDP, the "session_id" field of the extension includes the value 612 of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the 613 "tls-id-value" ABNF production). The value of the "tls-id" attribute 614 is encoded using ASCII [ASCII]. 616 Where RTP and RTCP [RTP] are not multiplexed, it is possible that the 617 two separate DTLS connections carrying RTP and RTCP can be switched. 618 This is considered benign since these protocols are designed to be 619 distinguishable as SRTP [SRTP] provides key separation. Using RTP/ 620 RTCP multiplexing [RTCP-MUX] further avoids this problem. 622 The "external_session_id" extension is included in a ClientHello and 623 - if the extension is present in the ClientHello - either ServerHello 624 (for TLS and DTLS versions less than 1.3) or EncryptedExtensions (for 625 TLS 1.3). 627 Endpoints MUST check that the "session_id" parameter in the extension 628 that they receive includes the "tls-id" attribute value that they 629 received in their peer's session description. Endpoints can perform 630 string comparison by ASCII decoding the TLS extension value and 631 comparing it to the SDP attribute value, or compare the encoded TLS 632 extension octets with the encoded SDP attribute value. An endpoint 633 that receives a "external_session_id" extension that is not identical 634 to the value that it expects MUST abort the connection with a fatal 635 "illegal_parameter" alert. 637 Any validation performed of the "external_session_id" extension is 638 done in addition to the validation required by [FINGERPRINT]. 640 An endpoint that is communicating with a peer that does not support 641 this extension will receive a ClientHello, ServerHello or 642 EncryptedExtensions that does not include this extension. An 643 endpoint MAY choose to continue a session without this extension in 644 order to interoperate with peers that do not implement this 645 specification. 647 In TLS 1.3, an "external_session_id" extension sent by a server MUST 648 be sent in the EncryptedExtensions message. 650 This defense is not effective if an attacker can rewrite "tls-id" 651 values in signaling. Only the mechanism in "external_id_hash" is 652 able to defend against an attacker that can compromise session 653 integrity. 655 5. Session Concatenation 657 Use of session identifiers does not prevent an attacker from 658 establishing two concurrent sessions with different peers and 659 forwarding signaling from those peers to each other. Concatenating 660 two signaling sessions in this way creates two signaling sessions, 661 with two session identifiers, but only the TLS connections from a 662 single session are established as a result. In doing so, the 663 attacker creates a situation where both peers believe that they are 664 talking to the attacker when they are talking to each other. 666 In the absence of any higher-level concept of peer identity, the use 667 of session identifiers does not prevent session concatenation if the 668 attacker is able to copy the session identifier from one signaling 669 session to another. This kind of attack is prevented by systems that 670 enable peer authentication such as WebRTC identity [WEBRTC-SEC] or 671 SIP identity [SIP-ID]. However, session concatenation remains 672 possible at higher layers: an attacker can establish two independent 673 sessions and simply forward any data it receives from one into the 674 other. 676 Use of the "external_session_id" does not guarantee that the identity 677 of the peer at the TLS layer is the same as the identity of the 678 signaling peer. The advantage an attacker gains by concatenating 679 sessions is limited unless data is exchanged on the assumption that 680 signaling and TLS peers are the same. If a secondary protocol uses 681 the signaling channel with the assumption that the signaling and TLS 682 peers are the same then that protocol is vulnerable to attack. A 683 signaling system that can defend against session concatenation, while 684 out of scope for this document, requires that the signaling layer is 685 authenticated and bound to any TLS connections. 687 It is important to note that multiple connections can be created 688 within the same signaling session. An attacker might concatenate 689 only part of a session, choosing to terminate some connections (and 690 optionally forward data) while arranging to have peers interact 691 directly for other connections. It is even possible to have 692 different peers interact for each connection. This means that the 693 actual identity of the peer for one connection might differ from the 694 peer on another connection. 696 Critically, information about the identity of TLS peers provides no 697 assurances about the identity of signaling peers and do not transfer 698 between TLS connections in the same session. Information extracted 699 from a TLS connection therefore MUST NOT be used in a secondary 700 protocol outside of that connection if that protocol assumes that the 701 signaling protocol has the same peers. Similarly, security-sensitive 702 information from one TLS connection MUST NOT be used in other TLS 703 connections even if they are established as a result of the same 704 signaling session. 706 6. Security Considerations 708 The mitigations in this document, when combined with identity 709 assertions, ensure that there is no opportunity to misrepresent the 710 identity of TLS peers. This assurance is provided even if an 711 attacker can modify signaling messages. 713 Without identity assertions, the mitigations in this document prevent 714 the session splicing attack described in Section 4. Defense against 715 session concatenation (Section 5) additionally requires protocol 716 peers are not able to claim the certificate fingerprints of other 717 entities. 719 7. IANA Considerations 721 This document registers two extensions in the TLS "ExtensionType 722 Values" registry established in [TLS13]: 724 o The "external_id_hash" extension defined in Section 3.2 has been 725 assigned a code point of TBD; it is recommended and is marked as 726 "CH, EE" in TLS 1.3. 728 o The "external_session_id" extension defined in Section 4.3 has 729 been assigned a code point of TBD; it is recommended and is marked 730 as "CH, EE" in TLS 1.3. 732 8. References 734 8.1. Normative References 736 [ASCII] Cerf, V., "ASCII format for network interchange", STD 80, 737 RFC 20, DOI 10.17487/RFC0020, October 1969, 738 . 740 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 741 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 742 . 744 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 745 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 746 January 2012, . 748 [DTLS-SDP] 749 Holmberg, C. and R. Shpount, "Session Description Protocol 750 (SDP) Offer/Answer Considerations for Datagram Transport 751 Layer Security (DTLS) and Transport Layer Security (TLS)", 752 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 753 2017. 755 [DTLS-SRTP] 756 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 757 for Establishing a Secure Real-time Transport Protocol 758 (SRTP) Security Context Using Datagram Transport Layer 759 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 760 2010, . 762 [FINGERPRINT] 763 Lennox, J. and C. Holmberg, "Connection-Oriented Media 764 Transport over the Transport Layer Security (TLS) Protocol 765 in the Session Description Protocol (SDP)", RFC 8122, 766 DOI 10.17487/RFC8122, March 2017, 767 . 769 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 770 Interchange Format", STD 90, RFC 8259, 771 DOI 10.17487/RFC8259, December 2017, 772 . 774 [PASSPoRT] 775 Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 776 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 777 . 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, 781 DOI 10.17487/RFC2119, March 1997, 782 . 784 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 785 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 786 May 2017, . 788 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 789 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 790 July 2006, . 792 [SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 793 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 794 DOI 10.17487/RFC6234, May 2011, 795 . 797 [SIP-ID] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 798 "Authenticated Identity Management in the Session 799 Initiation Protocol (SIP)", RFC 8224, 800 DOI 10.17487/RFC8224, February 2018, 801 . 803 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 804 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 805 RFC 3711, DOI 10.17487/RFC3711, March 2004, 806 . 808 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 809 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 810 . 812 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 813 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 814 2003, . 816 [WEBRTC-SEC] 817 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 818 rtcweb-security-arch-20 (work in progress), July 2019. 820 8.2. Informative References 822 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 823 Agility and Selecting Mandatory-to-Implement Algorithms", 824 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 825 . 827 [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 828 Connectivity Establishment (ICE): A Protocol for Network 829 Address Translator (NAT) Traversal", RFC 8445, 830 DOI 10.17487/RFC8445, July 2018, 831 . 833 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 834 Camarillo, "Best Current Practices for Third Party Call 835 Control (3pcc) in the Session Initiation Protocol (SIP)", 836 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 837 . 839 [RTCP-MUX] 840 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 841 Control Packets on a Single Port", RFC 5761, 842 DOI 10.17487/RFC5761, April 2010, 843 . 845 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 846 Jacobson, "RTP: A Transport Protocol for Real-Time 847 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 848 July 2003, . 850 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 851 authenticated Diffie-Hellman and its use in the IKE 852 protocols", Annual International Cryptology Conference, 853 Springer, pp. 400-425 , 2003. 855 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 856 Attacks on the Station-to-Station (STS) Protocol", Lecture 857 Notes in Computer Science 1560, Springer, pp. 154-170 , 858 1999. 860 [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., 861 Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: 862 Real-time Communication Between Browsers", W3C Editor's 863 Draft , November 2018. 865 [ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 866 Media Path Key Agreement for Unicast Secure RTP", 867 RFC 6189, DOI 10.17487/RFC6189, April 2011, 868 . 870 Appendix A. Acknowledgements 872 This problem would not have been discovered if it weren't for 873 discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A 874 solution similar to the one presented here was first proposed by 875 Karthik Bhargavan who provided valuable input on this document. 876 Thyla van der Merwe assisted with a formal model of the solution. 877 Adam Roach and Paul E. Jones provided significant review and input. 879 Authors' Addresses 881 Martin Thomson 882 Mozilla 884 Email: mt@lowentropy.net 886 Eric Rescorla 887 Mozilla 889 Email: ekr@rftm.com