< draft-ietf-mmusic-sdp-uks-03.txt   draft-ietf-mmusic-sdp-uks-04.txt >
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft E. Rescorla Internet-Draft E. Rescorla
Updates: 8122 (if approved) Mozilla Updates: 8122 (if approved) Mozilla
Intended status: Standards Track January 04, 2019 Intended status: Standards Track May 07, 2019
Expires: July 8, 2019 Expires: November 8, 2019
Unknown Key Share Attacks on uses of TLS with the Session Description Unknown Key Share Attacks on uses of TLS with the Session Description
Protocol (SDP) Protocol (SDP)
draft-ietf-mmusic-sdp-uks-03 draft-ietf-mmusic-sdp-uks-04
Abstract Abstract
This document describes unknown key-share attacks on the use of This document describes unknown key-share attacks on the use of
Datagram Transport Layer Security for the Secure Real-Time Transport Datagram Transport Layer Security for the Secure Real-Time Transport
Protocol (DTLS-SRTP). Similar attacks are described on the use of Protocol (DTLS-SRTP). Similar attacks are described on the use of
DTLS-SRTP with the identity bindings used in Web Real-Time DTLS-SRTP with the identity bindings used in Web Real-Time
Communications (WebRTC) and SIP identity. These attacks are Communications (WebRTC) and SIP identity. These attacks are
difficult to mount, but they cause a victim to be mislead about the difficult to mount, but they cause a victim to be mislead about the
identity of a communicating peer. Simple mitigation techniques are identity of a communicating peer. Simple mitigation techniques are
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2019. This Internet-Draft will expire on November 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3
2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4
2.2. Interactions with Key Continuity . . . . . . . . . . . . 4 2.2. Interactions with Key Continuity . . . . . . . . . . . . 5
2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5 2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5
3. Attack on Identity Bindings . . . . . . . . . . . . . . . . . 5 3. Attack on Identity Bindings . . . . . . . . . . . . . . . . . 6
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. The external_id_hash TLS Extension . . . . . . . . . . . 7 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8
4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 8 4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 9
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Unique Session Identity Solution . . . . . . . . . . . . 11 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12
4.3. The external_session_id TLS Extension . . . . . . . . . . 11 4.3. The external_session_id TLS Extension . . . . . . . . . . 12
5. Consequences of Session Concatenation . . . . . . . . . . . . 12 5. Consequences of Session Concatenation . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The use of Transport Layer Security (TLS) [TLS13] with the Session The use of Transport Layer Security (TLS) [TLS13] with the Session
Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. Description Protocol (SDP) [SDP] is defined in [FINGERPRINT].
Further use with Datagram Transport Layer Security (DTLS) [DTLS] and Further use with Datagram Transport Layer Security (DTLS) [DTLS] and
the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as
DTLS-SRTP [DTLS-SRTP]. DTLS-SRTP [DTLS-SRTP].
In these specifications, key agreement is performed using TLS or In these specifications, key agreement is performed using TLS or
skipping to change at page 4, line 33 skipping to change at page 4, line 33
2.1. Limits on Attack Feasibility 2.1. Limits on Attack Feasibility
The use of TLS with SDP depends on the integrity of session The use of TLS with SDP depends on the integrity of session
signaling. Assuming signaling integrity limits the capabilities of signaling. Assuming signaling integrity limits the capabilities of
an attacker in several ways. In particular: an attacker in several ways. In particular:
1. An attacker can only modify the parts of the session signaling 1. An attacker can only modify the parts of the session signaling
for a session that they are part of, which is limited to their for a session that they are part of, which is limited to their
own offers and answers. own offers and answers.
2. No entity will complete communications with a peer unless they 2. No entity will successfully establish a session with a peer
are willing to participate in a session with that peer. unless they are willing to participate in a session with that
peer.
The combination of these two constraints make the spectrum of The combination of these two constraints make the spectrum of
possible attacks quite limited. An attacker is only able to switch possible attacks quite limited. An attacker is only able to switch
its own certificate fingerprint for a valid certificate that is its own certificate fingerprint for a valid certificate that is
acceptable to its peer. Attacks therefore rely on joining two acceptable to its peer. Attacks therefore rely on joining two
separate sessions into a single session. separate sessions into a single session.
However, the second condition might not be necessary when using an Systems that rely on strong identity bindings, such as those defined
identity binding such as those defined in [WEBRTC] or [SIP-ID]. When in [WEBRTC] or [SIP-ID], have a different threat model, which admits
using an identity binding, the threat model assumes the possibility the possibility of attack by an entity with access to the signaling
of attack by an entity with access to the signaling channel. channel. Attacks under these conditions are more feasible as an
Removing this constraint makes attacks considerably more feasible. attacker is assumed to be able to both observe and modify signaling
messages.
2.2. Interactions with Key Continuity 2.2. Interactions with Key Continuity
Systems that use key continuity might be able to detect an unknown Systems that use key continuity (as defined in Section 15.1 of [ZRTP]
key-share attack if a session with either the attacker or the geniune or as recommended in Section 7 of [FINGERPRINT]) might be able to
peer (i.e., the victim whose fingerprint was copied by an attacker) detect an unknown key-share attack if a session with either the
was established in the past. Whether this is possible depends on how attacker or the genuine peer (i.e., the victim whose fingerprint was
key continuity is implemented. copied by an attacker) was established in the past. Whether this is
possible depends on how key continuity is implemented.
Implementations that maintain a single database of identities with an Implementations that maintain a single database of identities with an
index on peer keys could discover that the identity saved for the index on peer keys could discover that the identity saved for the
peer key does not match the claimed identity. Such an implementation peer key does not match the claimed identity. Such an implementation
could notice the disparity between the actual keys (those copied from could notice the disparity between the actual keys (those copied from
a victim) and the expected keys (those of the attacker). a victim) and the expected keys (those of the attacker).
In comparison, implementations that first match based on peer In comparison, implementations that first match based on peer
identity could treat an unknown key-share attack as though their peer identity could treat an unknown key-share attack as though their peer
had used a newly-configured device. The apparent addition of a new had used a newly-configured device. The apparent addition of a new
skipping to change at page 5, line 27 skipping to change at page 5, line 34
have a new device"). However, such an event is not always considered have a new device"). However, such an event is not always considered
alarming; some implementations might silently save a new key. alarming; some implementations might silently save a new key.
2.3. Third-Party Call Control 2.3. Third-Party Call Control
Third-party call control (3PCC) [RFC3725] is a technique where a Third-party call control (3PCC) [RFC3725] is a technique where a
signaling peer establishes a call that is terminated by a different signaling peer establishes a call that is terminated by a different
entity. This attack is very similar to the 3PCC technique, except entity. This attack is very similar to the 3PCC technique, except
where the TLS peers are aware of the use of 3PCC. where the TLS peers are aware of the use of 3PCC.
3PCC as described in RFC 3725 is incompatible with SIP identity
[SIP-ID] as SIP Identity relies on creating a binding between SIP
requests and SDP. The controller is the only entity that generates
SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use
of the "fingerprint" attribute without additional bindings or WebRTC
identity [WEBRTC-SEC] is possible.
For 3PCC to work with the proposed mechanisms, TLS peers need to be For 3PCC to work with the proposed mechanisms, TLS peers need to be
aware of the signaling so that they can correctly generate (and aware of the signaling so that they can correctly generate and check
check) the extension. It is understood that this technique will the TLS extensions. For a connection to be successfully established,
prevent the use of 3PCC if peers are not able to access signaling. a 3PCC controller needs to either forward SDP without modification,
or to avoid modifications to "fingerprint", "tls-id", and "identity"
attributes. A controller that follows the best practices in RFC 3725
is expected to forward SDP without modification, thus ensuring the
integrity of these attributes.
It is understood that this technique will prevent the use of 3PCC if
peers have different views of the involved identities, or the value
of SDP "tls-id" attributes.
3. Attack on Identity Bindings 3. Attack on Identity Bindings
The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC])
and the SIP PASSPoRT using in SIP identity ([SIP-ID], [PASSPoRT]) are and the SIP PASSPoRT using in SIP identity ([SIP-ID], [PASSPoRT]) are
bound to the certificate fingerprint of an endpoint. An attacker bound to the certificate fingerprint of an endpoint. An attacker
causes an identity binding to be created that binds an identity they causes an identity binding to be created that binds an identity they
control to the fingerprint of a victim. control to the fingerprint of a first victim.
An attacker can thereby cause a victim to believe that they are An attacker can thereby cause a second victim to believe that they
communicating with an attacker-controlled identity, when they are are communicating with an attacker-controlled identity, when they are
really talking to another entity of the attacker's choice. The really talking to the first victim. The attacker only needs to
attacker only needs to create an identity assertion that covers a create an identity assertion that covers a certificate fingerprint of
certificate fingerprint of their choosing. the first victim.
The problem might appear to be caused by the fact that the entity A variation on the same technique can be used to cause both victims
to both believe they are talking to the attacker when they are
talking to each other. In this case, the attacker performs the
identity misbinding once for each victim.
The problem might appear to be caused by the fact that the authority
that certifies the identity binding is not required to verify that that certifies the identity binding is not required to verify that
the entity requesting the binding controls the keys associated with the entity requesting the binding controls the keys associated with
the fingerprints. Both SIP and WebRTC identity providers are not the fingerprints. Both SIP and WebRTC identity providers are not
required to perform this validation. This is not an issue because required to perform this validation. This is not an issue because
verifying control of the associated keys is not a necessary condition verifying control of the associated keys is not a necessary condition
for a secure protocol, nor would it be sufficient to prevent attack for a secure protocol, nor would it be sufficient to prevent attack
[SIGMA]. [SIGMA].
A simple solution to this problem is suggested by [SIGMA]. The A simple solution to this problem is suggested by [SIGMA]. The
identity of endpoints is included under a message authentication code identity of endpoints is included under a message authentication code
(MAC) during the cryptographic handshake. Endpoints then validate (MAC) during the cryptographic handshake. Endpoints then validate
that their peer has provided an identity that matches their that their peer has provided an identity that matches their
expectations. In TLS, the Finished message provides a MAC over the expectations. In TLS, the Finished message provides a MAC over the
entire handshake, so that including the identity in a TLS extension entire handshake, so that including the identity in a TLS extension
is sufficient to implement this solution. is sufficient to implement this solution.
Rather than include a complete identity binding - which could be Rather than include a complete identity binding - which could be
sizeable - a collision- and pre-image-resistant hash of the binding sizeable - a collision- and pre-image-resistant hash of the binding
is included in a TLS extension. Endpoints then need only validate is included in a TLS extension as described in Section 3.2.
that the extension contains a hash of the identity binding they Endpoints then need only validate that the extension contains a hash
received in signaling. If the identity binding is successfully of the identity binding they received in signaling. If the identity
validated, the identity of a peer is verified and bound to the binding is successfully validated, the identity of a peer is verified
session. and bound to the session.
The same technique can be used to cause two victims to both believe This form of unknown key-share attack is possible without
they are talking to the attacker when they are talking to each other. compromising signaling integrity, unless the defenses described in
Section 4 are used. Endpoints MUST use the "external_session_id"
extension (see Section 4.3) in addition to the "external_id_hash"
(Section 3.2) so that two calls between the same parties can't be
altered by an attacker.
3.1. Example 3.1. Example
In the example shown in Figure 1, it is assumed that the attacker In the example shown in Figure 1, it is assumed that the attacker
also controls the signaling channel. also controls the signaling channel.
Mallory (the attacker) presents two victims, Norma and Patsy, with Mallory (the attacker) presents two victims, Norma and Patsy, with
two separate sessions. In the first session, Patsy is presented with two separate sessions. In the first session, Norma is presented with
the option to communicate with Norma; a second session with Mallory the option to communicate with Mallory; a second session with Norma
is presented to Norma. is presented to Patsy.
Norma Mallory Patsy Norma Mallory Patsy
(fp=N) ----- (fp=P) (fp=N) ----- (fp=P)
| | | | | |
| |<---- Signaling1 ------>| |<---- Signaling1 ------>| |
| | Norma=N Patsy=P |
|<---- Signaling2 ------>| |
| Norma=N Mallory=P | | | Norma=N Mallory=P | |
| |<---- Signaling2 ------>|
| | Norma=N Patsy=P |
| | | |
|<=================DTLS (fp=N,P)=================>| |<=================DTLS (fp=N,P)=================>|
| | | |
(peer = Mallory!) (peer = Norma) (peer = Mallory!) (peer = Norma)
Figure 1: Example Attack on Identity Bindings Figure 1: Example Attack on Identity Bindings
The attack requires that Mallory obtain an identity binding for their The attack requires that Mallory obtain an identity binding for her
own identity with the fingerprints presented by Patsy (P). This own identity with the fingerprints presented by Patsy (P). This
false binding is then presented to Norma. false binding is then presented to Norma (Signaling1 in the figure).
Patsy could be similarly duped, but in this example, a correct Patsy could be similarly duped, but in this example, a correct
binding between Norma's identity and fingerprint (N) is faithfully binding between Norma's identity and fingerprint (N) is faithfully
presented by Mallory. presented by Mallory. This session (Signaling2 in the figure) can be
entirely legitimate.
The resulting DTLS session is established directly between Norma and A DTLS session is established directly between Norma and Patsy. In
Patsy. Patsy correctly believes that they are communicating with order for this to happen Mallory can substitute transport-level
Norma. However, Norma incorrectly believes they are talking to information in both sessions to facilitate this, though this is not
Mallory. necessary if Mallory is on the network path between Norma and Patsy.
In order for this attack to work without compromising signaling As a result, Patsy correctly believes that she is communicating with
integrity, it is likely that the attacker also needs to subvert the Norma. However, Norma incorrectly believes she is talking to
session as described in Section 4. Endpoints can use the Mallory.
"external_session_id" extension (see Section 4.3) in addition to this
so that two calls between the same parties can't be altered by an
attacker.
3.2. The external_id_hash TLS Extension 3.2. The external_id_hash TLS Extension
The "external_id_hash" TLS extension carries a hash of the identity The "external_id_hash" TLS extension carries a hash of the identity
assertion that communicating peers have exchanged. assertion that communicating peers have exchanged.
The "extension_data" for the "external_id_hash" extension contains a The "extension_data" for the "external_id_hash" extension contains a
"ExternalIdentityHash" struct, described below using the syntax "ExternalIdentityHash" struct, described below using the syntax
defined in [TLS13]: defined in Section 3 of [TLS13]:
struct { struct {
opaque binding_hash<0..32>; opaque binding_hash<0..32>;
} ExternalIdentityHash; } ExternalIdentityHash;
A WebRTC identity assertion is provided as a JSON [JSON] object that A WebRTC identity assertion is provided as a JSON [JSON] object that
is encoded into a JSON text. The resulting string is then encoded is encoded into a JSON text. The resulting string is then encoded
using UTF-8 [UTF8]. The content of the "external_id_hash" extension using UTF-8 [UTF8]. The content of the "external_id_hash" extension
are produced by hashing the resulting octets with SHA-256 [SHA]. are produced by hashing the resulting octets with SHA-256 [SHA].
This produces the 32 octets of the "binding_hash" parameter, which is This produces the 32 octets of the "binding_hash" parameter, which is
the sole contents of the extension. the sole contents of the extension.
The SDP "identity" attribute includes the base64 [BASE64] encoding of The SDP "identity" attribute includes the base64 [BASE64] encoding of
the same octets that were input to the hash. The "external_id_hash" the UTF-8 encoding of the same JSON text. The "external_id_hash"
extension is validated by performing base64 decoding on the value of extension is validated by performing base64 decoding on the value of
the SDP "identity" attribute, hashing the resulting octets using SHA- the SDP "identity" attribute, hashing the resulting octets using SHA-
256, and comparing the results with the content of the extension. 256, and comparing the results with the content of the extension. In
pseudocode form, using the "identity-assertion-value" field from the
"identity" attribute grammar as defined in [WEBRTC-SEC]:
"external_id_hash = SHA256(b64decode(identity-assertion-value)) "
Note: The base64 is decoded to avoid capturing variations in
padding. The base64-decoded identity assertion could include
leading or trailing whitespace octets. WebRTC identity assertions
are not canonicalized; all octets are hashed.
Where a PASSPoRT is used, the compact form of the PASSPoRT MUST be Where a PASSPoRT is used, the compact form of the PASSPoRT MUST be
expanded into the full form. The base64 encoding used in the expanded into the full form. The base64 encoding used in the
Identity (or 'y') header field MUST be decoded then used as input to Identity (or 'y') header field MUST be decoded then used as input to
SHA-256. This produces the 32 octet "binding_hash" value used for SHA-256. This produces the 32 octet "binding_hash" value used for
creating or validating the extension. creating or validating the extension. In pseudocode, using the
"signed-identity-digest" field from the "Identity" grammar defined
[SIP-ID]:
"external_id_hash = SHA256(b64decode(signed-identity-digest)) "
Note: Should SHA-256 prove to be inadequate at some point in the Note: Should SHA-256 prove to be inadequate at some point in the
future (see [AGILITY]), a new TLS extension can be defined that future (see [AGILITY]), a new TLS extension can be defined that
uses a different hash function. uses a different hash function.
Identity bindings in either form might be provided by only one peer. Identity bindings in either form might be provided by only one peer.
An endpoint that does not produce an identity binding MUST generate An endpoint that does not produce an identity binding MUST generate
an empty "external_id_hash" extension in its ClientHello. This an empty "external_id_hash" extension in its ClientHello. An empty
allows its peer to include a hash of its identity binding. An extension has a zero-length binding_hash field. This allows its peer
endpoint without an identity binding MUST include an empty to include a hash of its identity binding. An endpoint without an
"external_id_hash" extension in its ServerHello or identity binding MUST include an empty "external_id_hash" extension
EncryptedExtensions message, to indicate support for the extension. in its ServerHello or EncryptedExtensions message, to indicate
support for the extension.
A peer that receives an "external_id_hash" extension that does not A peer that receives an "external_id_hash" extension that does not
match the value of the identity binding from its peer MUST match the value of the identity binding from its peer MUST
immediately fail the TLS handshake with an error. This includes immediately fail the TLS handshake with an error. This includes
cases where the binding is absent, in which the extension MUST be cases where the binding is absent, in which case the extension MUST
present and empty. be present and empty.
An "external_id_hash" extension that is any length other than 0 or 32 An "external_id_hash" extension that is any length other than 0 or 32
is invalid and MUST cause the receiving endpoint to generate a fatal is invalid and MUST cause the receiving endpoint to generate a fatal
"decode_error" alert. "decode_error" alert.
A peer that receives an identity binding, but does not receive an A peer that receives an identity binding, but does not receive an
"external_id_hash" extension MAY choose to fail the connection, "external_id_hash" extension MAY choose to fail the connection,
though it is expected that implementations written prior to the though it is expected that implementations written prior to the
definition of the extensions in this document will not support both definition of the extensions in this document will not support both
for some time. for some time.
In TLS 1.3, the "external_id_hash" extension MUST be sent in the In TLS 1.3, the "external_id_hash" extension MUST be sent in the
EncryptedExtensions message. EncryptedExtensions message.
4. Unknown Key-Share with Fingerprints 4. Unknown Key-Share with Fingerprints
A similar attack can create a session where there is confusion about An attack on DTLS-SRTP is possible because the identity of peers
the communicating endpoints by substituting the fingerprint of a involved is not established prior to establishing the call.
communicating endpoint. Endpoints use certificate fingerprints as a proxy for authentication,
but as long as fingerprints are used in multiple calls, they are
vulnerable to attack.
Even if the integrity session signaling can be relied upon, an
attacker might still be able to create a session where there is
confusion about the communicating endpoints by substituting the
fingerprint of a communicating endpoint.
An endpoint that is configured to reuse a certificate can be attacked An endpoint that is configured to reuse a certificate can be attacked
if it is willing to initiate two calls at the same time, one of which if it is willing to initiate two calls at the same time, one of which
is with an attacker. The attacker can arrange for the victim to is with an attacker. The attacker can arrange for the victim to
incorrectly believe that is calling the attacker when it is in fact incorrectly believe that it is calling the attacker when it is in
calling a second party. The second party correctly believes that it fact calling a second party. The second party correctly believes
is talking to the victim. that it is talking to the victim.
As with the attack on identity bindings, this can be used to cause As with the attack on identity bindings, this can be used to cause
two victims to both believe they are talking to the attacker when two victims to both believe they are talking to the attacker when
they are talking to each other. they are talking to each other.
4.1. Example 4.1. Example
In this example, two sessions are created with the same endpoint at To mount this attack, two sessions need to be created with the same
the same time. One of those sessions is initiated with the attacker, endpoint at almost precisely the same time. One of those sessions is
the second session is created toward another honest endpoint. The initiated with the attacker, the second session is created toward
attacker convinces the endpoint that their session has completed, and another honest endpoint. The attacker convinces the endpoint that
that the session with the other endpoint has succeeded. their session has completed, and that the session with the other
endpoint has succeeded.
In addition to the constraints described in Section 2.1, the attacker In addition to the constraints described in Section 2.1, the attacker
in this example also needs to the ability to view and drop packets in this example also needs the ability to view and drop packets
between victims. That is, the attacker is on-path. between victims. That is, the attacker is on-path.
The attack shown in Figure 2 depends on a somewhat implausible set of The attack shown in Figure 2 depends on a somewhat implausible set of
conditions. It is intended to demonstrate what sort of attack is conditions. It is intended to demonstrate what sort of attack is
possible and what conditions are necessary to exploit this weakness possible and what conditions are necessary to exploit this weakness
in the protocol. in the protocol.
Norma Mallory Patsy Norma Mallory Patsy
(fp=N) ----- (fp=P) (fp=N) ----- (fp=P)
| | | | | |
skipping to change at page 10, line 5 skipping to change at page 11, line 5
In this scenario, there are two sessions initiated at the same time In this scenario, there are two sessions initiated at the same time
by Norma. Signaling is shown with single lines ('-'), DTLS and media by Norma. Signaling is shown with single lines ('-'), DTLS and media
with double lines ('='). with double lines ('=').
The first session is established with Mallory, who falsely uses The first session is established with Mallory, who falsely uses
Patsy's certificate fingerprint (denoted with 'fp=P'). A second Patsy's certificate fingerprint (denoted with 'fp=P'). A second
session is initiated between Norma and Patsy. Signaling for both session is initiated between Norma and Patsy. Signaling for both
sessions is permitted to complete. sessions is permitted to complete.
Once signaling is complete on the session that is ostensibly between Once signaling is complete on the first session, a DTLS connection is
Mallory and Norma is complete. Mallory begins forwarding DTLS and established. Ostensibly, this connection is between Mallory and
media packets sent to her by Norma to Patsy. These packets denoted Norma but Mallory forwards DTLS and media packets sent to her by
'DTLS1' because Norma associates these with the first signaling Norma to Patsy. These packets are denoted 'DTLS1' because Norma
session ('signaling1'). associates these with the first signaling session ('signaling1').
Mallory also intercepts packets from Patsy and forwards those to Mallory also intercepts packets from Patsy and forwards those to
Norma at the transport address that Norma associates with Mallory. Norma at the transport address that Norma associates with Mallory.
These packets are denoted 'DTLS2' to indicate that Patsy associates These packets are denoted 'DTLS2' to indicate that Patsy associates
these with the second signaling session ('signaling2'), however Norma these with the second signaling session ('signaling2'), however Norma
will interpret these as being associated with the first signaling will interpret these as being associated with the first signaling
session ('signaling1'). session ('signaling1').
The second signaling exchange - 'signaling2', between Norma and Patsy The second signaling exchange - 'signaling2', between Norma and Patsy
- is permitted to continue to the point where Patsy believes that it - is permitted to continue to the point where Patsy believes that it
has succeeded. This ensures that Patsy believes that she is has succeeded. This ensures that Patsy believes that she is
communicating with Norma. In the end, Norma believes that she is communicating with Norma. In the end, Norma believes that she is
communicating with Mallory, when she is really communicating with communicating with Mallory, when she is really communicating with
Patsy. Patsy.
Though Patsy needs to believe that the second signaling session has Though Patsy needs to believe that the second signaling session has
been successfully established, Mallory has no real interest in seeing been successfully established, Mallory has no real interest in seeing
that session complete. Mallory only needs to ensure that Patsy does that session also be established. Mallory only needs to ensure that
not abandon the session prematurely. For this reason, it might be Patsy maintains the active session and does not abandon the session
necessary to permit the signaling from Patsy to reach Norma to allow prematurely. For this reason, it might be necessary to permit the
Patsy to receive a call completion signal, such as a SIP ACK. Once signaling from Patsy to reach Norma to allow Patsy to receive a call
the second session completes, Mallory might cause DTLS packets sent setup completion signal, such as a SIP ACK. Once the second session
by Norma to Patsy to be dropped, though these will likely be is established, Mallory might cause DTLS packets sent by Norma to
discarded by Patsy. Patsy to be dropped. It is likely that these DTLS packets will be
discarded by Patsy as Patsy will already have a successful DTLS
connection established.
For the attacked session to be sustained beyond the point that Norma For the attacked session to be sustained beyond the point that Norma
detects errors in the second session, Mallory also needs to block any detects errors in the second session, Mallory also needs to block any
signaling that Norma might send to Patsy asking for the call to be signaling that Norma might send to Patsy asking for the call to be
abandoned. Otherwise, Patsy might receive a notice that the call is abandoned. Otherwise, Patsy might receive a notice that the call is
failed and thereby abort the call. failed and thereby abort the call.
This attack creates an asymmetry in the beliefs about the identity of This attack creates an asymmetry in the beliefs about the identity of
peers. However, this attack is only possible if the victim (Norma) peers. However, this attack is only possible if the victim (Norma)
is willing to conduct two sessions nearly simultaneously, if the is willing to conduct two sessions nearly simultaneously, if the
attacker (Mallory) is on the network path between the victims, and if attacker (Mallory) is on the network path between the victims, and if
the same certificate - and therefore SDP "fingerprint" attribute the same certificate - and therefore SDP "fingerprint" attribute
value - is used in both sessions. value - is used in both sessions.
Where ICE [ICE] is used, Mallory also needs to ensure that Where ICE [ICE] is used, Mallory also needs to ensure that
connectivity between Patsy and Norma succeed, either by forwarding connectivity checks between Patsy and Norma succeed, either by
checks or answering and generating the necessary messages. forwarding checks or answering and generating the necessary messages.
4.2. Unique Session Identity Solution 4.2. Unique Session Identity Solution
An attack on DTLS-SRTP is possible because the identity of peers
involved is not established prior to establishing the call.
Endpoints use certificate fingerprints as a proxy for authentication,
but as long as fingerprints are used in multiple calls, they are
vulnerable to attack.
The solution to this problem is to assign a new identifier to The solution to this problem is to assign a new identifier to
communicating peers. Each endpoint assigns their peer a unique communicating peers. Each endpoint assigns their peer a unique
identifier during call signaling. The peer echoes that identifier in identifier during call signaling. The peer echoes that identifier in
the TLS handshake, binding that identity into the session. Including the TLS handshake, binding that identity into the session. Including
this new identity in the TLS handshake means that it will be covered this new identity in the TLS handshake means that it will be covered
by the TLS Finished message, which is necessary to authenticate it by the TLS Finished message, which is necessary to authenticate it
(see [SIGMA]). Validating that peers use the correct identifier then (see [SIGMA]).
means that the session is established between the correct two
endpoints. Successful validation that the identifier matches the expected value
means that the connection corresponds to the signaled session and is
therefore established between the correct two endpoints.
This solution relies on the unique identifier given to DTLS sessions This solution relies on the unique identifier given to DTLS sessions
using the SDP "tls-id" attribute [DTLS-SDP]. This field is already using the SDP "tls-id" attribute [DTLS-SDP]. This field is already
required to be unique. Thus, no two offers or answers from the same required to be unique. Thus, no two offers or answers from the same
client will have the same value. client will have the same value.
A new "external_session_id" extension is added to the TLS or DTLS A new "external_session_id" extension is added to the TLS or DTLS
handshake for connections that are established as part of the same handshake for connections that are established as part of the same
call or real-time session. This carries the value of the "tls-id" call or real-time session. This carries the value of the "tls-id"
attribute and provides integrity protection for its exchange as part attribute and provides integrity protection for its exchange as part
of the TLS or DTLS handshake. of the TLS or DTLS handshake.
4.3. The external_session_id TLS Extension 4.3. The external_session_id TLS Extension
The "external_session_id" TLS extension carries the unique identifier The "external_session_id" TLS extension carries the unique identifier
that an endpoint selects. When used with SDP, the value includes the that an endpoint selects. When used with SDP, the value MUST include
"tls-id" attribute from the SDP that the endpoint generated when the "tls-id" attribute from the SDP that the endpoint generated when
negotiating the session. This document only defines use of this negotiating the session. This document only defines use of this
extension for SDP; other methods of external session negotiation can extension for SDP; other methods of external session negotiation can
use this extension to include a unique session identifier. use this extension to include a unique session identifier.
The "extension_data" for the "external_session_id" extension contains The "extension_data" for the "external_session_id" extension contains
a ExternalSessionId struct, described below using the syntax defined an ExternalSessionId struct, described below using the syntax defined
in [TLS13]: in [TLS13]:
struct { struct {
opaque session_id<20..255>; opaque session_id<20..255>;
} ExternalSessionId; } ExternalSessionId;
For SDP, the "session_id" field of the extension includes the value For SDP, the "session_id" field of the extension includes the value
of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the
"tls-id-value" ABNF production). The value of the "tls-id" attribute "tls-id-value" ABNF production). The value of the "tls-id" attribute
is encoded using ASCII [ASCII]. is encoded using ASCII [ASCII].
skipping to change at page 12, line 39 skipping to change at page 13, line 37
An endpoint that is communicating with a peer that does not support An endpoint that is communicating with a peer that does not support
this extension will receive a ClientHello, ServerHello or this extension will receive a ClientHello, ServerHello or
EncryptedExtensions that does not include this extension. An EncryptedExtensions that does not include this extension. An
endpoint MAY choose to continue a session without this extension in endpoint MAY choose to continue a session without this extension in
order to interoperate with peers that do not implement this order to interoperate with peers that do not implement this
specification. specification.
In TLS 1.3, the "external_session_id" extension MUST be sent in the In TLS 1.3, the "external_session_id" extension MUST be sent in the
EncryptedExtensions message. EncryptedExtensions message.
This defense is not effective if an attacker can rewrite "tls-id"
values in signaling. Only the mechanism in "external_id_hash" is
able to defend against an attacker that can compromise session
integrity.
5. Consequences of Session Concatenation 5. Consequences of Session Concatenation
Use of session identifiers does not prevent an attacker from Use of session identifiers does not prevent an attacker from
establishing two concurrent sessions with different peers and establishing two concurrent sessions with different peers and
forwarding signaling from those peers to each other. Concatenating forwarding signaling from those peers to each other. Concatenating
two signaling sessions creates a situation where both peers believe two signaling sessions in this way creates two signaling sessions,
that they are talking to the attacker when they are talking to each with two session identifiers, but only the TLS connections from a
other. single session are established as a result. In doing so, the
attacker creates a situation where both peers believe that they are
This kind of attack is prevented by systems that enable peer talking to the attacker when they are talking to each other.
authentication such as WebRTC identity [WEBRTC-SEC] or SIP identity
[SIP-ID]. However, session concatention remains possible at higher
layers: an attacker can establish two independent sessions and simply
forward any data it receives from one into the other.
In the absence of any higher-level concept of peer identity, the use In the absence of any higher-level concept of peer identity, the use
of session identifiers does not prevent session concatenation. The of session identifiers does not prevent session concatenation if the
value to an attacker is limited unless information from the TLS attacker is able to copy the session identifier from one signaling
connection is extracted and used with the signaling. For instance, a session to another. This kind of attack is prevented by systems that
key exporter [EXPORTER] might be used to create a shared secret or enable peer authentication such as WebRTC identity [WEBRTC-SEC] or
unique identifier that is used in a secondary protocol. SIP identity [SIP-ID]. However, session concatenation remains
possible at higher layers: an attacker can establish two independent
sessions and simply forward any data it receives from one into the
other.
If a secondary protocol uses the signaling channel with the Use of the "external_session_id" does not guarantee that the identity
assumption that the signaling and TLS peers are the same then that of the peer at the TLS layer is the same as the identity of the
protocol is vulnerable to attack unless they also validate the signaling peer. The advantage an attacker gains by concatenating
identity of peers at both layers. Use of the "external_session_id" sessions is limited unless it is assumed that signaling and TLS peers
does not guarantee that the identity of the peer at the TLS layer is are the same. If a secondary protocol uses the signaling channel
the same as the identity of the signaling peer. with the assumption that the signaling and TLS peers are the same
then that protocol is vulnerable to attack unless they also validate
the identity of peers at both layers.
It is important to note that multiple connections can be created It is important to note that multiple connections can be created
within the same signaling session. An attacker might concatenate within the same signaling session. An attacker might concatenate
only part of a session, choosing to terminate some connections (and only part of a session, choosing to terminate some connections (and
optionally forward data) while arranging to have peers interact optionally forward data) while arranging to have peers interact
directly for other connections. It is even possible to have directly for other connections. It is even possible to have
different peers interact for each connection. This means that the different peers interact for each connection. This means that the
actual identity of the peer for one connection might differ from the actual identity of the peer for one connection might differ from the
peer on another connection. peer on another connection.
Information extracted from a TLS connection therefore MUST NOT be Information extracted from a TLS connection therefore MUST NOT be
used in a secondary protocol outside of that connection if that used in a secondary protocol outside of that connection if that
protocol relies on the signaling protocol having the same peers. protocol relies on the signaling protocol having the same peers.
Similarly, data from one TLS connection MUST NOT be used in other TLS Similarly, security-sensitive information from one TLS connection
connections even if they are established as a result of the same MUST NOT be used in other TLS connections even if they are
signaling session. established as a result of the same signaling session.
6. Security Considerations 6. Security Considerations
This entire document contains security considerations. This entire document contains security considerations.
7. IANA Considerations 7. IANA Considerations
This document registers two extensions in the TLS "ExtensionType This document registers two extensions in the TLS "ExtensionType
Values" registry established in [TLS13]: Values" registry established in [TLS13]:
skipping to change at page 15, line 38 skipping to change at page 16, line 38
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[WEBRTC-SEC] [WEBRTC-SEC]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-17 (work in progress), November 2018. rtcweb-security-arch-18 (work in progress), February 2019.
8.2. Informative References 8.2. Informative References
[AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[EXPORTER]
Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
skipping to change at page 16, line 47 skipping to change at page 17, line 42
[UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share
Attacks on the Station-to-Station (STS) Protocol", Lecture Attacks on the Station-to-Station (STS) Protocol", Lecture
Notes in Computer Science 1560, Springer, pp. 154-170 , Notes in Computer Science 1560, Springer, pp. 154-170 ,
1999. 1999.
[WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C.,
Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0:
Real-time Communication Between Browsers", W3C Editor's Real-time Communication Between Browsers", W3C Editor's
Draft , November 2018. Draft , November 2018.
[ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This problem would not have been discovered if it weren't for This problem would not have been discovered if it weren't for
discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A
solution similar to the one presented here was first proposed by solution similar to the one presented here was first proposed by
Karthik Bhargavan who provided valuable input on this document. Karthik Bhargavan who provided valuable input on this document.
Thyla van der Merwe assisted with a formal model of the solution. Thyla van der Merwe assisted with a formal model of the solution.
Adam Roach and Paul E. Jones provided significant review and input. Adam Roach and Paul E. Jones provided significant review and input.
 End of changes. 48 change blocks. 
146 lines changed or deleted 197 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/