idnits 2.17.1 draft-ietf-mmusic-sdp-uks-04.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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 07, 2019) is 1813 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-18 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft E. Rescorla 4 Updates: 8122 (if approved) Mozilla 5 Intended status: Standards Track May 07, 2019 6 Expires: November 8, 2019 8 Unknown Key Share Attacks on uses of TLS with the Session Description 9 Protocol (SDP) 10 draft-ietf-mmusic-sdp-uks-04 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. Simple mitigation techniques are 21 defined for each. 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 November 8, 2019. 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. Attack on Identity Bindings . . . . . . . . . . . . . . . . . 6 63 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8 65 4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 9 66 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12 68 4.3. The external_session_id TLS Extension . . . . . . . . . . 12 69 5. Consequences of Session Concatenation . . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 8.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 The use of Transport Layer Security (TLS) [TLS13] with the Session 81 Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. 82 Further use with Datagram Transport Layer Security (DTLS) [DTLS] and 83 the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as 84 DTLS-SRTP [DTLS-SRTP]. 86 In these specifications, key agreement is performed using TLS or 87 DTLS, with authentication being tied back to the session description 88 (or SDP) through the use of certificate fingerprints. Communication 89 peers check that a hash, or fingerprint, provided in the SDP matches 90 the certificate that is used in the TLS or DTLS handshake. 92 WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity 93 [SIP-ID] both provide a mechanism that binds an external identity to 94 the certificate fingerprints from a session description. However, 95 this binding is not integrity-protected and therefore vulnerable to 96 an identity misbinding attack - or unknown key-share (UKS) attack - 97 where the attacker binds their identity to the fingerprint of another 98 entity. A successful attack leads to the creation of sessions where 99 peers are confused about the identify of the participants. 101 This document describes a TLS extension that can be used in 102 combination with these identity bindings to prevent this attack. 104 A similar attack is possible with the use of certificate fingerprints 105 alone. Though attacks in this setting are likely infeasible in 106 existing deployments due to the narrow conditions necessary (see 107 Section 2.1), this document also describes mitigations for this 108 attack. 110 The mechanisms defined in this document are intended to strengthen 111 the protocol by preventing the use of unknown key shares in 112 combination with other protocol or implementation vulnerabilities. 114 This document assumes that signaling is integrity protected. 115 However, as Section 7 of [FINGERPRINT] explains, many deployments 116 that use SDP do not guarantee integrity of session signaling and so 117 are vulnerable to other attacks. [FINGERPRINT] offers key continuity 118 mechanisms as a potential means of reducing exposure to attack in the 119 absence of integrity protection. Section 2.2 provides some analysis 120 of the effect of key continuity in relation to the described attacks. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. Unknown Key-Share Attack 130 In an unknown key-share attack [UKS], a malicious participant in a 131 protocol claims to control a key that is in reality controlled by 132 some other actor. This arises when the identity associated with a 133 key is not properly bound to the key. 135 An endpoint that can acquire the certificate fingerprint of another 136 entity can advertise that fingerprint as their own in SDP. An 137 attacker can use a copy of that fingerprint to cause a victim to 138 communicate with another unaware victim, even though it believes that 139 it is communicating with the attacker. 141 When the identity of communicating peers is established by higher- 142 layer signaling constructs, such as those in SIP identity [SIP-ID] or 143 WebRTC [WEBRTC-SEC], this allows an attacker to bind their own 144 identity to a session with any other entity. 146 The attacker obtains an identity assertion for an identity it 147 controls, but binds that to the fingerprint of one peer. The 148 attacker is then able to cause a TLS connection to be established 149 where two endpoints communicate. The victim that has its fingerprint 150 copied by the attack correctly believes that it is communicating with 151 the other victim; however, the other victim incorrectly believes that 152 it is communicating with the attacker. 154 A similar attack can be mounted without any communications 155 established based on the SDP "fingerprint" attribute [FINGERPRINT]. 157 This attack is an aspect of SDP-based protocols that the technique 158 known as third-party call control (3PCC) [RFC3725] relies on. 3PCC 159 exploits the potential for the identity of a signaling peer to be 160 different than the media peer, allowing the media peer to be selected 161 by the signaling peer. Section 2.3 describes the consequences of the 162 mitigations described here for systems that use 3PCC. 164 2.1. Limits on Attack Feasibility 166 The use of TLS with SDP depends on the integrity of session 167 signaling. Assuming signaling integrity limits the capabilities of 168 an attacker in several ways. In particular: 170 1. An attacker can only modify the parts of the session signaling 171 for a session that they are part of, which is limited to their 172 own offers and answers. 174 2. No entity will successfully establish a session with a peer 175 unless they are willing to participate in a session with that 176 peer. 178 The combination of these two constraints make the spectrum of 179 possible attacks quite limited. An attacker is only able to switch 180 its own certificate fingerprint for a valid certificate that is 181 acceptable to its peer. Attacks therefore rely on joining two 182 separate sessions into a single session. 184 Systems that rely on strong identity bindings, such as those defined 185 in [WEBRTC] or [SIP-ID], have a different threat model, which admits 186 the possibility of attack by an entity with access to the signaling 187 channel. Attacks under these conditions are more feasible as an 188 attacker is assumed to be able to both observe and modify signaling 189 messages. 191 2.2. Interactions with Key Continuity 193 Systems that use key continuity (as defined in Section 15.1 of [ZRTP] 194 or as recommended in Section 7 of [FINGERPRINT]) might be able to 195 detect an unknown key-share attack if a session with either the 196 attacker or the genuine peer (i.e., the victim whose fingerprint was 197 copied by an attacker) was established in the past. Whether this is 198 possible depends on how key continuity is implemented. 200 Implementations that maintain a single database of identities with an 201 index on peer keys could discover that the identity saved for the 202 peer key does not match the claimed identity. Such an implementation 203 could notice the disparity between the actual keys (those copied from 204 a victim) and the expected keys (those of the attacker). 206 In comparison, implementations that first match based on peer 207 identity could treat an unknown key-share attack as though their peer 208 had used a newly-configured device. The apparent addition of a new 209 device could generate user-visible notices (e.g., "Mallory appears to 210 have a new device"). However, such an event is not always considered 211 alarming; some implementations might silently save a new key. 213 2.3. Third-Party Call Control 215 Third-party call control (3PCC) [RFC3725] is a technique where a 216 signaling peer establishes a call that is terminated by a different 217 entity. This attack is very similar to the 3PCC technique, except 218 where the TLS peers are aware of the use of 3PCC. 220 3PCC as described in RFC 3725 is incompatible with SIP identity 221 [SIP-ID] as SIP Identity relies on creating a binding between SIP 222 requests and SDP. The controller is the only entity that generates 223 SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use 224 of the "fingerprint" attribute without additional bindings or WebRTC 225 identity [WEBRTC-SEC] is possible. 227 For 3PCC to work with the proposed mechanisms, TLS peers need to be 228 aware of the signaling so that they can correctly generate and check 229 the TLS extensions. For a connection to be successfully established, 230 a 3PCC controller needs to either forward SDP without modification, 231 or to avoid modifications to "fingerprint", "tls-id", and "identity" 232 attributes. A controller that follows the best practices in RFC 3725 233 is expected to forward SDP without modification, thus ensuring the 234 integrity of these attributes. 236 It is understood that this technique will prevent the use of 3PCC if 237 peers have different views of the involved identities, or the value 238 of SDP "tls-id" attributes. 240 3. Attack on Identity Bindings 242 The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) 243 and the SIP PASSPoRT using in SIP identity ([SIP-ID], [PASSPoRT]) are 244 bound to the certificate fingerprint of an endpoint. An attacker 245 causes an identity binding to be created that binds an identity they 246 control to the fingerprint of a first victim. 248 An attacker can thereby cause a second victim to believe that they 249 are communicating with an attacker-controlled identity, when they are 250 really talking to the first victim. The attacker only needs to 251 create an identity assertion that covers a certificate fingerprint of 252 the first victim. 254 A variation on the same technique can be used to cause both victims 255 to both believe they are talking to the attacker when they are 256 talking to each other. In this case, the attacker performs the 257 identity misbinding once for each victim. 259 The problem might appear to be caused by the fact that the authority 260 that certifies the identity binding is not required to verify that 261 the entity requesting the binding controls the keys associated with 262 the fingerprints. Both SIP and WebRTC identity providers are not 263 required to perform this validation. This is not an issue because 264 verifying control of the associated keys is not a necessary condition 265 for a secure protocol, nor would it be sufficient to prevent attack 266 [SIGMA]. 268 A simple solution to this problem is suggested by [SIGMA]. The 269 identity of endpoints is included under a message authentication code 270 (MAC) during the cryptographic handshake. Endpoints then validate 271 that their peer has provided an identity that matches their 272 expectations. In TLS, the Finished message provides a MAC over the 273 entire handshake, so that including the identity in a TLS extension 274 is sufficient to implement this solution. 276 Rather than include a complete identity binding - which could be 277 sizeable - a collision- and pre-image-resistant hash of the binding 278 is included in a TLS extension as described in Section 3.2. 279 Endpoints then need only validate that the extension contains a hash 280 of the identity binding they received in signaling. If the identity 281 binding is successfully validated, the identity of a peer is verified 282 and bound to the session. 284 This form of unknown key-share attack is possible without 285 compromising signaling integrity, unless the defenses described in 286 Section 4 are used. Endpoints MUST use the "external_session_id" 287 extension (see Section 4.3) in addition to the "external_id_hash" 288 (Section 3.2) so that two calls between the same parties can't be 289 altered by an attacker. 291 3.1. Example 293 In the example shown in Figure 1, it is assumed that the attacker 294 also controls the signaling channel. 296 Mallory (the attacker) presents two victims, Norma and Patsy, with 297 two separate sessions. In the first session, Norma is presented with 298 the option to communicate with Mallory; a second session with Norma 299 is presented to Patsy. 301 Norma Mallory Patsy 302 (fp=N) ----- (fp=P) 303 | | | 304 |<---- Signaling1 ------>| | 305 | Norma=N Mallory=P | | 306 | |<---- Signaling2 ------>| 307 | | Norma=N Patsy=P | 308 | | 309 |<=================DTLS (fp=N,P)=================>| 310 | | 311 (peer = Mallory!) (peer = Norma) 313 Figure 1: Example Attack on Identity Bindings 315 The attack requires that Mallory obtain an identity binding for her 316 own identity with the fingerprints presented by Patsy (P). This 317 false binding is then presented to Norma (Signaling1 in the figure). 319 Patsy could be similarly duped, but in this example, a correct 320 binding between Norma's identity and fingerprint (N) is faithfully 321 presented by Mallory. This session (Signaling2 in the figure) can be 322 entirely legitimate. 324 A DTLS session is established directly between Norma and Patsy. In 325 order for this to happen Mallory can substitute transport-level 326 information in both sessions to facilitate this, though this is not 327 necessary if Mallory is on the network path between Norma and Patsy. 329 As a result, Patsy correctly believes that she is communicating with 330 Norma. However, Norma incorrectly believes she is talking to 331 Mallory. 333 3.2. The external_id_hash TLS Extension 335 The "external_id_hash" TLS extension carries a hash of the identity 336 assertion that communicating peers have exchanged. 338 The "extension_data" for the "external_id_hash" extension contains a 339 "ExternalIdentityHash" struct, described below using the syntax 340 defined in Section 3 of [TLS13]: 342 struct { 343 opaque binding_hash<0..32>; 344 } ExternalIdentityHash; 346 A WebRTC identity assertion is provided as a JSON [JSON] object that 347 is encoded into a JSON text. The resulting string is then encoded 348 using UTF-8 [UTF8]. The content of the "external_id_hash" extension 349 are produced by hashing the resulting octets with SHA-256 [SHA]. 350 This produces the 32 octets of the "binding_hash" parameter, which is 351 the sole contents of the extension. 353 The SDP "identity" attribute includes the base64 [BASE64] encoding of 354 the UTF-8 encoding of the same JSON text. The "external_id_hash" 355 extension is validated by performing base64 decoding on the value of 356 the SDP "identity" attribute, hashing the resulting octets using SHA- 357 256, and comparing the results with the content of the extension. In 358 pseudocode form, using the "identity-assertion-value" field from the 359 "identity" attribute grammar as defined in [WEBRTC-SEC]: 361 "external_id_hash = SHA256(b64decode(identity-assertion-value)) " 363 Note: The base64 is decoded to avoid capturing variations in 364 padding. The base64-decoded identity assertion could include 365 leading or trailing whitespace octets. WebRTC identity assertions 366 are not canonicalized; all octets are hashed. 368 Where a PASSPoRT is used, the compact form of the PASSPoRT MUST be 369 expanded into the full form. The base64 encoding used in the 370 Identity (or 'y') header field MUST be decoded then used as input to 371 SHA-256. This produces the 32 octet "binding_hash" value used for 372 creating or validating the extension. In pseudocode, using the 373 "signed-identity-digest" field from the "Identity" grammar defined 374 [SIP-ID]: 376 "external_id_hash = SHA256(b64decode(signed-identity-digest)) " 378 Note: Should SHA-256 prove to be inadequate at some point in the 379 future (see [AGILITY]), a new TLS extension can be defined that 380 uses a different hash function. 382 Identity bindings in either form might be provided by only one peer. 383 An endpoint that does not produce an identity binding MUST generate 384 an empty "external_id_hash" extension in its ClientHello. An empty 385 extension has a zero-length binding_hash field. This allows its peer 386 to include a hash of its identity binding. An endpoint without an 387 identity binding MUST include an empty "external_id_hash" extension 388 in its ServerHello or EncryptedExtensions message, to indicate 389 support for the extension. 391 A peer that receives an "external_id_hash" extension that does not 392 match the value of the identity binding from its peer MUST 393 immediately fail the TLS handshake with an error. This includes 394 cases where the binding is absent, in which case the extension MUST 395 be present and empty. 397 An "external_id_hash" extension that is any length other than 0 or 32 398 is invalid and MUST cause the receiving endpoint to generate a fatal 399 "decode_error" alert. 401 A peer that receives an identity binding, but does not receive an 402 "external_id_hash" extension MAY choose to fail the connection, 403 though it is expected that implementations written prior to the 404 definition of the extensions in this document will not support both 405 for some time. 407 In TLS 1.3, the "external_id_hash" extension MUST be sent in the 408 EncryptedExtensions message. 410 4. Unknown Key-Share with Fingerprints 412 An attack on DTLS-SRTP is possible because the identity of peers 413 involved is not established prior to establishing the call. 414 Endpoints use certificate fingerprints as a proxy for authentication, 415 but as long as fingerprints are used in multiple calls, they are 416 vulnerable to attack. 418 Even if the integrity session signaling can be relied upon, an 419 attacker might still be able to create a session where there is 420 confusion about the communicating endpoints by substituting the 421 fingerprint of a communicating endpoint. 423 An endpoint that is configured to reuse a certificate can be attacked 424 if it is willing to initiate two calls at the same time, one of which 425 is with an attacker. The attacker can arrange for the victim to 426 incorrectly believe that it is calling the attacker when it is in 427 fact calling a second party. The second party correctly believes 428 that it is talking to the victim. 430 As with the attack on identity bindings, this can be used to cause 431 two victims to both believe they are talking to the attacker when 432 they are talking to each other. 434 4.1. Example 436 To mount this attack, two sessions need to be created with the same 437 endpoint at almost precisely the same time. One of those sessions is 438 initiated with the attacker, the second session is created toward 439 another honest endpoint. The attacker convinces the endpoint that 440 their session has completed, and that the session with the other 441 endpoint has succeeded. 443 In addition to the constraints described in Section 2.1, the attacker 444 in this example also needs the ability to view and drop packets 445 between victims. That is, the attacker is on-path. 447 The attack shown in Figure 2 depends on a somewhat implausible set of 448 conditions. It is intended to demonstrate what sort of attack is 449 possible and what conditions are necessary to exploit this weakness 450 in the protocol. 452 Norma Mallory Patsy 453 (fp=N) ----- (fp=P) 454 | | | 455 +---Signaling1 (fp=N)--->| | 456 +-----Signaling2 (fp=N)------------------------>| 457 |<-------------------------Signaling2 (fp=P)----+ 458 |<---Signaling1 (fp=P)---+ | 459 | | | 460 |=======DTLS1=======>(Forward)======DTLS1======>| 461 |<======DTLS2========(Forward)<=====DTLS2=======| 462 |=======Media1======>(Forward)======Media1=====>| 463 |<======Media2=======(Forward)<=====Media2======| 464 | | | 465 |=======DTLS2========>(Drop) | 466 | | | 468 Figure 2: Example Attack Scenario using Fingerprints 470 In this scenario, there are two sessions initiated at the same time 471 by Norma. Signaling is shown with single lines ('-'), DTLS and media 472 with double lines ('='). 474 The first session is established with Mallory, who falsely uses 475 Patsy's certificate fingerprint (denoted with 'fp=P'). A second 476 session is initiated between Norma and Patsy. Signaling for both 477 sessions is permitted to complete. 479 Once signaling is complete on the first session, a DTLS connection is 480 established. Ostensibly, this connection is between Mallory and 481 Norma but Mallory forwards DTLS and media packets sent to her by 482 Norma to Patsy. These packets are denoted 'DTLS1' because Norma 483 associates these with the first signaling session ('signaling1'). 485 Mallory also intercepts packets from Patsy and forwards those to 486 Norma at the transport address that Norma associates with Mallory. 487 These packets are denoted 'DTLS2' to indicate that Patsy associates 488 these with the second signaling session ('signaling2'), however Norma 489 will interpret these as being associated with the first signaling 490 session ('signaling1'). 492 The second signaling exchange - 'signaling2', between Norma and Patsy 493 - is permitted to continue to the point where Patsy believes that it 494 has succeeded. This ensures that Patsy believes that she is 495 communicating with Norma. In the end, Norma believes that she is 496 communicating with Mallory, when she is really communicating with 497 Patsy. 499 Though Patsy needs to believe that the second signaling session has 500 been successfully established, Mallory has no real interest in seeing 501 that session also be established. Mallory only needs to ensure that 502 Patsy maintains the active session and does not abandon the session 503 prematurely. For this reason, it might be necessary to permit the 504 signaling from Patsy to reach Norma to allow Patsy to receive a call 505 setup completion signal, such as a SIP ACK. Once the second session 506 is established, Mallory might cause DTLS packets sent by Norma to 507 Patsy to be dropped. It is likely that these DTLS packets will be 508 discarded by Patsy as Patsy will already have a successful DTLS 509 connection established. 511 For the attacked session to be sustained beyond the point that Norma 512 detects errors in the second session, Mallory also needs to block any 513 signaling that Norma might send to Patsy asking for the call to be 514 abandoned. Otherwise, Patsy might receive a notice that the call is 515 failed and thereby abort the call. 517 This attack creates an asymmetry in the beliefs about the identity of 518 peers. However, this attack is only possible if the victim (Norma) 519 is willing to conduct two sessions nearly simultaneously, if the 520 attacker (Mallory) is on the network path between the victims, and if 521 the same certificate - and therefore SDP "fingerprint" attribute 522 value - is used in both sessions. 524 Where ICE [ICE] is used, Mallory also needs to ensure that 525 connectivity checks between Patsy and Norma succeed, either by 526 forwarding checks or answering and generating the necessary messages. 528 4.2. Unique Session Identity Solution 530 The solution to this problem is to assign a new identifier to 531 communicating peers. Each endpoint assigns their peer a unique 532 identifier during call signaling. The peer echoes that identifier in 533 the TLS handshake, binding that identity into the session. Including 534 this new identity in the TLS handshake means that it will be covered 535 by the TLS Finished message, which is necessary to authenticate it 536 (see [SIGMA]). 538 Successful validation that the identifier matches the expected value 539 means that the connection corresponds to the signaled session and is 540 therefore established between the correct two endpoints. 542 This solution relies on the unique identifier given to DTLS sessions 543 using the SDP "tls-id" attribute [DTLS-SDP]. This field is already 544 required to be unique. Thus, no two offers or answers from the same 545 client will have the same value. 547 A new "external_session_id" extension is added to the TLS or DTLS 548 handshake for connections that are established as part of the same 549 call or real-time session. This carries the value of the "tls-id" 550 attribute and provides integrity protection for its exchange as part 551 of the TLS or DTLS handshake. 553 4.3. The external_session_id TLS Extension 555 The "external_session_id" TLS extension carries the unique identifier 556 that an endpoint selects. When used with SDP, the value MUST include 557 the "tls-id" attribute from the SDP that the endpoint generated when 558 negotiating the session. This document only defines use of this 559 extension for SDP; other methods of external session negotiation can 560 use this extension to include a unique session identifier. 562 The "extension_data" for the "external_session_id" extension contains 563 an ExternalSessionId struct, described below using the syntax defined 564 in [TLS13]: 566 struct { 567 opaque session_id<20..255>; 568 } ExternalSessionId; 570 For SDP, the "session_id" field of the extension includes the value 571 of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the 572 "tls-id-value" ABNF production). The value of the "tls-id" attribute 573 is encoded using ASCII [ASCII]. 575 Where RTP and RTCP [RTP] are not multiplexed, it is possible that the 576 two separate DTLS connections carrying RTP and RTCP can be switched. 577 This is considered benign since these protocols are usually 578 distinguishable. RTP/RTCP multiplexing is advised to address this 579 problem. 581 The "external_session_id" extension is included in a ClientHello and 582 either ServerHello (for TLS and DTLS versions less than 1.3) or 583 EncryptedExtensions (for TLS 1.3). In TLS 1.3, the 584 "external_session_id" extension MUST NOT be included in a 585 ServerHello. 587 Endpoints MUST check that the "session_id" parameter in the extension 588 that they receive includes the "tls-id" attribute value that they 589 received in their peer's session description. Endpoints can perform 590 string comparison by ASCII decoding the TLS extension value and 591 comparing it to the SDP attribute value, or compare the encoded TLS 592 extension octets with the encoded SDP attribute value. An endpoint 593 that receives a "external_session_id" extension that is not identical 594 to the value that it expects MUST abort the connection with a fatal 595 "handshake_failure" alert. 597 An endpoint that is communicating with a peer that does not support 598 this extension will receive a ClientHello, ServerHello or 599 EncryptedExtensions that does not include this extension. An 600 endpoint MAY choose to continue a session without this extension in 601 order to interoperate with peers that do not implement this 602 specification. 604 In TLS 1.3, the "external_session_id" extension MUST be sent in the 605 EncryptedExtensions message. 607 This defense is not effective if an attacker can rewrite "tls-id" 608 values in signaling. Only the mechanism in "external_id_hash" is 609 able to defend against an attacker that can compromise session 610 integrity. 612 5. Consequences of Session Concatenation 614 Use of session identifiers does not prevent an attacker from 615 establishing two concurrent sessions with different peers and 616 forwarding signaling from those peers to each other. Concatenating 617 two signaling sessions in this way creates two signaling sessions, 618 with two session identifiers, but only the TLS connections from a 619 single session are established as a result. In doing so, the 620 attacker creates a situation where both peers believe that they are 621 talking to the attacker when they are talking to each other. 623 In the absence of any higher-level concept of peer identity, the use 624 of session identifiers does not prevent session concatenation if the 625 attacker is able to copy the session identifier from one signaling 626 session to another. This kind of attack is prevented by systems that 627 enable peer authentication such as WebRTC identity [WEBRTC-SEC] or 628 SIP identity [SIP-ID]. However, session concatenation remains 629 possible at higher layers: an attacker can establish two independent 630 sessions and simply forward any data it receives from one into the 631 other. 633 Use of the "external_session_id" does not guarantee that the identity 634 of the peer at the TLS layer is the same as the identity of the 635 signaling peer. The advantage an attacker gains by concatenating 636 sessions is limited unless it is assumed that signaling and TLS peers 637 are the same. If a secondary protocol uses the signaling channel 638 with the assumption that the signaling and TLS peers are the same 639 then that protocol is vulnerable to attack unless they also validate 640 the identity of peers at both layers. 642 It is important to note that multiple connections can be created 643 within the same signaling session. An attacker might concatenate 644 only part of a session, choosing to terminate some connections (and 645 optionally forward data) while arranging to have peers interact 646 directly for other connections. It is even possible to have 647 different peers interact for each connection. This means that the 648 actual identity of the peer for one connection might differ from the 649 peer on another connection. 651 Information extracted from a TLS connection therefore MUST NOT be 652 used in a secondary protocol outside of that connection if that 653 protocol relies on the signaling protocol having the same peers. 654 Similarly, security-sensitive information from one TLS connection 655 MUST NOT be used in other TLS connections even if they are 656 established as a result of the same signaling session. 658 6. Security Considerations 660 This entire document contains security considerations. 662 7. IANA Considerations 664 This document registers two extensions in the TLS "ExtensionType 665 Values" registry established in [TLS13]: 667 o The "external_id_hash" extension defined in Section 3.2 has been 668 assigned a code point of TBD; it is recommended and is marked as 669 "Encrypted" in TLS 1.3. 671 o The "external_session_id" extension defined in Section 4.3 has 672 been assigned a code point of TBD; it is recommended and is marked 673 as "Encrypted" in TLS 1.3. 675 8. References 677 8.1. Normative References 679 [ASCII] Cerf, V., "ASCII format for network interchange", STD 80, 680 RFC 20, DOI 10.17487/RFC0020, October 1969, 681 . 683 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 684 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 685 January 2012, . 687 [DTLS-SDP] 688 Holmberg, C. and R. Shpount, "Session Description Protocol 689 (SDP) Offer/Answer Considerations for Datagram Transport 690 Layer Security (DTLS) and Transport Layer Security (TLS)", 691 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 692 2017. 694 [DTLS-SRTP] 695 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 696 for Establishing a Secure Real-time Transport Protocol 697 (SRTP) Security Context Using Datagram Transport Layer 698 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 699 2010, . 701 [FINGERPRINT] 702 Lennox, J. and C. Holmberg, "Connection-Oriented Media 703 Transport over the Transport Layer Security (TLS) Protocol 704 in the Session Description Protocol (SDP)", RFC 8122, 705 DOI 10.17487/RFC8122, March 2017, 706 . 708 [PASSPoRT] 709 Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 710 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 711 . 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, 715 DOI 10.17487/RFC2119, March 1997, 716 . 718 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 719 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 720 May 2017, . 722 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 723 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 724 July 2006, . 726 [SHA] Dang, Q., "Secure Hash Standard", National Institute of 727 Standards and Technology report, 728 DOI 10.6028/nist.fips.180-4, July 2015. 730 [SIP-ID] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 731 "Authenticated Identity Management in the Session 732 Initiation Protocol (SIP)", RFC 8224, 733 DOI 10.17487/RFC8224, February 2018, 734 . 736 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 737 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 738 RFC 3711, DOI 10.17487/RFC3711, March 2004, 739 . 741 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 742 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 743 . 745 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 746 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 747 2003, . 749 [WEBRTC-SEC] 750 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 751 rtcweb-security-arch-18 (work in progress), February 2019. 753 8.2. Informative References 755 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 756 Agility and Selecting Mandatory-to-Implement Algorithms", 757 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 758 . 760 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 761 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 762 . 764 [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 765 Connectivity Establishment (ICE): A Protocol for Network 766 Address Translator (NAT) Traversal", RFC 8445, 767 DOI 10.17487/RFC8445, July 2018, 768 . 770 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 771 Interchange Format", STD 90, RFC 8259, 772 DOI 10.17487/RFC8259, December 2017, 773 . 775 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 776 Camarillo, "Best Current Practices for Third Party Call 777 Control (3pcc) in the Session Initiation Protocol (SIP)", 778 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 779 . 781 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 782 Jacobson, "RTP: A Transport Protocol for Real-Time 783 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 784 July 2003, . 786 [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to 787 authenticated Diffie-Hellman and its use in the IKE 788 protocols", Annual International Cryptology Conference, 789 Springer, pp. 400-425 , 2003. 791 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 792 Attacks on the Station-to-Station (STS) Protocol", Lecture 793 Notes in Computer Science 1560, Springer, pp. 154-170 , 794 1999. 796 [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., 797 Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: 798 Real-time Communication Between Browsers", W3C Editor's 799 Draft , November 2018. 801 [ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 802 Media Path Key Agreement for Unicast Secure RTP", 803 RFC 6189, DOI 10.17487/RFC6189, April 2011, 804 . 806 Appendix A. Acknowledgements 808 This problem would not have been discovered if it weren't for 809 discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A 810 solution similar to the one presented here was first proposed by 811 Karthik Bhargavan who provided valuable input on this document. 813 Thyla van der Merwe assisted with a formal model of the solution. 814 Adam Roach and Paul E. Jones provided significant review and input. 816 Authors' Addresses 818 Martin Thomson 819 Mozilla 821 Email: mt@lowentropy.net 823 Eric Rescorla 824 Mozilla 826 Email: ekr@rftm.com