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