draft-ietf-mmusic-sdp-uks-01.txt   draft-ietf-mmusic-sdp-uks-02.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft E. Rescorla Internet-Draft E. Rescorla
Intended status: Standards Track Mozilla Intended status: Standards Track Mozilla
Expires: August 4, 2018 January 31, 2018 Expires: February 9, 2019 August 08, 2018
Unknown Key Share Attacks on uses of Transport Layer Security with the Unknown Key Share Attacks on uses of Transport Layer Security with the
Session Description Protocol (SDP) Session Description Protocol (SDP)
draft-ietf-mmusic-sdp-uks-01 draft-ietf-mmusic-sdp-uks-02
Abstract Abstract
Unknown key-share attacks on the use of Datagram Transport Layer This document describes unknown key-share attacks on the use of
Security for the Secure Real-Time Transport Protocol (DTLS-SRTP) and Datagram Transport Layer Security for the Secure Real-Time Transport
its use with Web Real-Time Communications (WebRTC) identity Protocol (DTLS-SRTP). Similar attacks are described on the use of
assertions are described. Simple mitigation techniques are defined. DTLS-SRTP with Web Real-Time Communications (WebRTC) identity
assertions. Both attacks cause a victim to be mislead about the
identity of a communicating peer. Simple mitigation techniques are
defined for each.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 4, 2018. This Internet-Draft will expire on February 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Attack Overview . . . . . . . . . . . . . . . . . . . . . 3 2.1. Attack Overview . . . . . . . . . . . . . . . . . . . . . 4
2.2. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 2.2. Limits on Attack Feasibility . . . . . . . . . . . . . . 4
2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Interactions with Key Continuity . . . . . . . . . . . . 6 2.4. Interactions with Key Continuity . . . . . . . . . . . . 6
3. Adding a Session Identifier . . . . . . . . . . . . . . . . . 6 2.5. Third-Party Call Control . . . . . . . . . . . . . . . . 6
3. Adding a Session Identifier . . . . . . . . . . . . . . . . . 7
3.1. The external_session_id TLS Extension . . . . . . . . . . 7 3.1. The external_session_id TLS Extension . . . . . . . . . . 7
4. WebRTC Identity Binding . . . . . . . . . . . . . . . . . . . 8 4. WebRTC Identity Binding . . . . . . . . . . . . . . . . . . . 8
4.1. The webrtc_id_hash TLS Extension . . . . . . . . . . . . 8 4.1. The webrtc_id_hash TLS Extension . . . . . . . . . . . . 9
5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 10 5. Consequences of Session Concatenation . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The use of Transport Layer Security (TLS) [RFC5246] with the Session The use of Transport Layer Security (TLS) [RFC5246] with the Session
Description Protocol (SDP) [RFC4566] is defined in [RFC8122]. Description Protocol (SDP) [RFC4566] is defined in [RFC8122].
Further use with Datagram Transport Layer Security (DTLS) [RFC6347] Further use with Datagram Transport Layer Security (DTLS) [RFC6347]
and the Secure Real-time Transport Protocol (SRTP) [RFC3711] is and the Secure Real-time Transport Protocol (SRTP) [RFC3711] is
defined as DTLS-SRTP [RFC5763]. defined as DTLS-SRTP [RFC5763].
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 3, line 6 skipping to change at page 3, line 11
being subject to modification. However, this design is vulnerable to being subject to modification. However, this design is vulnerable to
an unknown key-share (UKS) attack where a misbehaving endpoint is an unknown key-share (UKS) attack where a misbehaving endpoint is
able to advertise a key that it does not control. This leads to the able to advertise a key that it does not control. This leads to the
creation of sessions where peers are confused about the identify of creation of sessions where peers are confused about the identify of
the participants. the participants.
An extension to TLS is defined that can be used to mitigate this An extension to TLS is defined that can be used to mitigate this
attack. attack.
A similar attack is possible with sessions that use WebRTC identity A similar attack is possible with sessions that use WebRTC identity
(see Section 5.6 of [I-D.ietf-rtcweb-security-arch]). This issue and (see Section 5.6 of [WEBRTC-SEC]). This issue and a mitigation for
a mitigation for it is discussed in more detail in Section 4. it is discussed in more detail in Section 4.
2. Unknown Key-Share Attack 2. Unknown Key-Share Attack
In an unknown key-share attack [UKS], a malicious participant in a In an unknown key-share attack [UKS], a malicious participant in a
protocol claims to control a key that is in reality controlled by protocol claims to control a key that is in reality controlled by
some other actor. This arises when the identity associated with a some other actor. This arises when the identity associated with a
key is not properly bound to the key. key is not properly bound to the key.
In usages of TLS and DTLS that use SDP for negotiation, an endpoint In usages of TLS that use SDP for negotiation, an endpoint is able to
is able to acquire the certificate fingerprint of another entity. By acquire the certificate fingerprint of another entity. By
advertising that fingerprint in place of one of its own, the advertising that fingerprint in place of one of its own, the
malicious endpoint can cause its peer to communicate with a different malicious endpoint can cause its peer to communicate with a different
peer, even though it believes that it is communicating with the peer, even though it believes that it is communicating with the
malicious endpoint. malicious endpoint.
When the identity of communicating peers is established by higher- When the identity of communicating peers is established by higher-
layer signaling constructs, such as those in SIP [RFC4474] or WebRTC layer signaling constructs, such as those in SIP [RFC4474] or WebRTC
[I-D.ietf-rtcweb-security-arch], this allows an attacker to bind [WEBRTC-SEC], this allows an attacker to bind their own identity to a
their own identity to a session with any other entity. session with any other entity.
By substituting the fingerprint of one peer for its own, an attacker By substituting the fingerprint of one peer for its own, an attacker
is able to cause a session to be established where one endpoint has is able to cause a TLS connection to be established where one
an incorrect value for the identity of its peer. However, the peer endpoint might make an incorrect assumption about the identity of its
does not suffer any such confusion, resulting in each peer involved peer. The TLS peer is not the same as the signaling peer.
in the session having a different view of the nature of the session.
The peer does not suffer any such confusion, resulting in each peer
involved in the session having a different view of the nature of the
session.
This attack applies to any communications established based on the This attack applies to any communications established based on the
SDP "fingerprint" attribute [RFC8122]. SDP "fingerprint" attribute [RFC8122].
This attack is an aspect of SDP-based protocols that the technique
known as third-party call control (3PCC) relies on. 3PCC exploits
the potential for the identity of a signaling peer to be different
than the media peer, allowing the media peer to be selected by the
signaling peer. Section 2.5 describes the consequences of the
mitigations described here for systems that use 3PCC.
2.1. Attack Overview 2.1. Attack Overview
This vulnerability can be used by an attacker to create a session This vulnerability can be used by an attacker to create a session
where there is confusion about the communicating endpoints. where there is confusion about the communicating endpoints.
A SIP endpoint or WebRTC endpoint that is configured to reuse a A SIP endpoint or WebRTC endpoint that is configured to reuse a
certificate can be attacked if it is willing to conduct two certificate can be attacked if it is willing to conduct two
concurrent calls, one of which is with an attacker. The attacker can concurrent calls, one of which is with an attacker. The attacker can
arrange for the victim to incorrectly believe that is calling the arrange for the victim to incorrectly believe that is calling the
attacker when it is in fact calling a second party. The second party attacker when it is in fact calling a second party. The second party
correctly believes that it is talking to the victim. correctly believes that it is talking to the victim.
The same technique can be used to cause two victims to both believe
they are talking to the attacker when they are talking to each other.
In a related attack, a single call using WebRTC identity can be In a related attack, a single call using WebRTC identity can be
attacked so that it produces the same outcome. This attack does not attacked so that it produces the same outcome. This attack does not
require a concurrent call. require a concurrent call.
2.2. Limits on Attack Feasibility 2.2. 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:
skipping to change at page 4, line 25 skipping to change at page 4, line 44
2. No entity will complete communications with a peer unless they 2. No entity will complete communications with a peer unless they
are willing to participate in a session with that peer. 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.
The second condition is not necessary with WebRTC identity if the The second condition is not necessary with WebRTC identity if the
victim has or is configured with a target peer identity (this is victim has or is configured with a target peer identity (as defined
defined in [WEBRTC]). Furthermore, any identity displayed by a in [WEBRTC]). Furthermore, any identity displayed by a browser could
browser could be different to the identity used by the application, be different to the identity used by the application, since the
since the attack affects the browser's understanding of the peer's attack affects the browser's understanding of the peer's identity.
identity.
2.3. Example 2.3. Example
In this example, two outgoing sessions are created by the same In this example, two sessions are created with the same endpoint
endpoint. One of those sessions is initiated with the attacker, concurrently. One of those sessions is initiated with the attacker,
another session is created toward another honest endpoint. The the second session is created toward another honest endpoint. The
attacker convinces the endpoint that their session has completed, and attacker convinces the endpoint that their session has completed, and
that the session with the other endpoint has succeeded. that the session with the other endpoint has succeeded.
Norma Mallory Patsy Norma Mallory Patsy
(fp=N) ----- (fp=P) (fp=N) ----- (fp=P)
| | | | | |
+---Offer1 (fp=N)--->| | +---Offer1 (fp=N)--->| |
+-----Offer2 (fp=N)-------------------->| +-----Offer2 (fp=N)-------------------->|
|<--------------------Answer2 (fp=P)----+ |<--------------------Answer2 (fp=P)----+
|<--Answer1 (fp=P)---+ | |<--Answer1 (fp=P)---+ |
skipping to change at page 5, line 27 skipping to change at page 5, line 35
| | | | | |
|======DTLS2===========>(Drop) | |======DTLS2===========>(Drop) |
| | | | | |
In this case, Norma is willing to conduct two concurrent sessions. In this case, Norma is willing to conduct two concurrent sessions.
The first session is established with Mallory, who falsely uses The first session is established with Mallory, who falsely uses
Patsy's certificate fingerprint. A second session is initiated Patsy's certificate fingerprint. A second session is initiated
between Norma and Patsy. Signaling for both sessions is permitted to between Norma and Patsy. Signaling for both sessions is permitted to
complete. complete.
Once complete, the session that is ostensibly between Mallory and Once signaling is complete on the session that is ostensibly between
Norma is completed by forwarding packets between Norma and Patsy. Mallory and Norma is complete. Mallory begins forwarding DTLS and
This requires that Mallory is able to intercept DTLS and media media packets sent to her by Norma to Patsy. Mallory also intercepts
packets from Patsy so that they can be forwarded to Norma at the packets from Patsy and forwards those to Norma at the transport
transport addresses that Norma associates with the first session. address that Norma associates with Mallory.
The second session - between Norma and Patsy - is permitted to The second signaling exchange - between Norma and Patsy - is
continue to the point where Patsy believes that it has succeeded. permitted to continue to the point where Patsy believes that it has
This ensures that Patsy believes that she is communicating with succeeded. This ensures that Patsy believes that she is
Norma. In the end, Norma believes that she is communicating with communicating with Norma. In the end, Norma believes that she is
Mallory, when she is actually communicating with Patsy. communicating with Mallory, when she is really communicating with
Patsy.
Though Patsy needs to believe that the second session is successful, Though Patsy needs to believe that the second signaling session has
Mallory has no real interest in seeing that session complete. been successfully established, Mallory has no real interest in seeing
Mallory only needs to ensure that Patsy does not abandon the session that session complete. Mallory only needs to ensure that Patsy does
prematurely. For this reason, it might be necessary to permit the not abandon the session prematurely. For this reason, it might be
answer from Patsy to reach Norma to allow Patsy to receive a call necessary to permit the signaling from Patsy to reach Norma to allow
completion signal, such as a SIP ACK. Once the second session Patsy to receive a call completion signal, such as a SIP ACK. Once
completes, Mallory causes any DTLS packets sent by Norma to Patsy to the second session completes, Mallory might cause DTLS packets sent
be dropped. by Norma to Patsy to be dropped, though these will likely be
discarded by Patsy.
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 concurrently, and if the same is willing to conduct two sessions concurrently, if the attacker
(Mallory) is on the network path between the victims, and if the same
certificate - and therefore SDP "fingerprint" attribute value - is certificate - and therefore SDP "fingerprint" attribute value - is
used in both sessions. used in both sessions.
Where ICE [ICE] is used, Mallory also needs to ensure that
connectivity between Patsy and Norma succeed, either by forwarding
checks or answering and generating the necessary messages.
2.4. Interactions with Key Continuity 2.4. Interactions with Key Continuity
Systems that use key continuity might be able to detect an unknown Systems that use key continuity might be able to detect an unknown
key-share attack if a session with the actual peer (i.e., Patsy in key-share attack if a session with the actual peer (i.e., Patsy in
the example) was established in the past. Whether this is possible the example) was established in the past. Whether this is possible
depends on how key continuity is implemented. 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 (Patsy) and the could notice the disparity between the actual keys (Patsy) and the
expected keys (Mallory). expected keys (Mallory).
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
device could generate user-visible notices (e.g., "Mallory appears to device could generate user-visible notices (e.g., "Mallory appears to
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.5. Third-Party Call Control
Third-party call control (3PCC) is a technique where a signaling peer
establishes a call that is terminated by a different entity. This
attack is very similar to the 3PCC technique, except where the TLS
peers are aware of the use of 3PCC.
For 3PCC to work with the proposed defense, TLS peers need to be
aware of the signaling so that they can correctly generate (and
check) the extension. It is understood that this technique will
prevent the use of 3PCC if peers are not able to access signaling.
3. Adding a Session Identifier 3. Adding a Session Identifier
An attack on DTLS-SRTP is possible because the identity of peers An attack on DTLS-SRTP is possible because the identity of peers
involved is not established prior to establishing the call. involved is not established prior to establishing the call.
Endpoints use certificate fingerprints as a proxy for authentication, Endpoints use certificate fingerprints as a proxy for authentication,
but as long as fingerprints are used in multiple calls, they are but as long as fingerprints are used in multiple calls, they are
vulnerable to attacks of the sort described. vulnerable to attacks of the sort described.
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]). Validating that peers use the correct identifier then
means that the session is established between the correct two means that the session is established between the correct two
endpoints. 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 [I-D.ietf-mmusic-dtls-sdp]. This using the SDP "tls-id" attribute [DTLS-SDP]. This field is already
field is already required to be unique. Thus, no two offers or required to be unique. Thus, no two offers or answers from the same
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.
3.1. The external_session_id TLS Extension 3.1. 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
skipping to change at page 7, line 29 skipping to change at page 8, line 10
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 a ExternalSessionId struct, described below using the syntax defined
in [RFC5246]: in [RFC5246]:
struct { struct {
opaque id<20..255>; opaque id<20..255>;
} ExternalSessionId; } ExternalSessionId;
For SDP, the "id" field of the extension includes the value of the For SDP, the "id" field of the extension includes the value of the
"tls-id" SDP attribute as defined in [I-D.ietf-mmusic-dtls-sdp] (that "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the "tls-
is, the "tls-id-value" ABNF production). The value of the "tls-id" id-value" ABNF production). The value of the "tls-id" attribute is
attribute is encoded using ASCII [RFC0020]. encoded using ASCII [RFC0020].
Where RTP and RTCP [RFC3550] are not multiplexed, it is possible that Where RTP and RTCP [RFC3550] are not multiplexed, it is possible that
the two separate DTLS connections carrying RTP and RTCP can be the two separate DTLS connections carrying RTP and RTCP can be
switched. This is considered benign since these protocols are switched. This is considered benign since these protocols are
usually distinguishable. RTP/RTCP multiplexing is advised to address usually distinguishable. RTP/RTCP multiplexing is advised to address
this problem. this problem.
The "external_session_id" extension is included in a ClientHello and The "external_session_id" extension is included in a ClientHello and
either ServerHello (for TLS and DTLS versions less than 1.3) or either ServerHello (for TLS and DTLS versions less than 1.3) or
EncryptedExtensions (for TLS 1.3). In TLS 1.3, the EncryptedExtensions (for TLS 1.3). In TLS 1.3, the
skipping to change at page 8, line 17 skipping to change at page 8, line 46
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.
4. WebRTC Identity Binding 4. WebRTC Identity Binding
The identity assertion used for WebRTC The identity assertion used for WebRTC [WEBRTC-SEC] is bound only to
[I-D.ietf-rtcweb-security-arch] is bound only to the certificate the certificate fingerprint of an endpoint and can therefore be
fingerprint of an endpoint and can therefore be copied by an attacker copied by an attacker along with any SDP "fingerprint" attributes.
along with any SDP "fingerprint" attributes. An attacker can exploit this by causing a victim to believe that they
are communicating with an attacker-controlled identity, when they are
really talking to another entity of the attacker's choice. The
attacker only needs to create an identity assertion that covers a
certificate fingerprint of their choosing.
The problem is compounded by the fact that an identity provider is The problem might appear to be caused by the fact that an identity
not required to verify that the entity requesting an identity provider is not required to verify that the entity requesting an
assertion controls the keys. Nor is it currently able to perform identity assertion controls the keys associated with the certificate
this validation. This is not an issue because verification is not a that is used. A WebRTC identity provider is not required, or even
necessary condition for a secure protocol, nor would it be sufficient able, to perform validation. This is not an issue because
as established in [SIGMA]. verification is not a necessary condition for a secure protocol, nor
would it be sufficient to prevent attack [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 are then (MAC) during the cryptographic handshake. Endpoints then validate
expected to validate that their peer has provided an identity that that their peer has provided an identity that matches their
matches their expectations. expectations.
In TLS, the Finished message provides a MAC over the entire In TLS, the Finished message provides a MAC over the entire
handshake, so that including the identity in a TLS extension is handshake, so that including the identity in a TLS extension is
sufficient to implement this solution. Rather than include a sufficient to implement this solution. Rather than include a
complete identity assertion - which could be sizeable - a collision- complete identity assertion - which could be sizeable - a collision-
resistant hash of the identity assertion is included in a TLS and pre-image-resistant hash of the identity assertion is included in
extension. Peers then need only validate that the extension contains a TLS extension. Peers then need only validate that the extension
a hash of the identity assertion they received in signaling in contains a hash of the identity assertion they received in signaling
addition to validating the identity assertion. in addition to validating the identity assertion.
Endpoints MAY use the "external_session_id" extension in addition to Endpoints can also use the "external_session_id" extension in
this so that two calls between the same parties can't be altered by addition to this so that two calls between the same parties can't be
an attacker. altered by an attacker.
4.1. The webrtc_id_hash TLS Extension 4.1. The webrtc_id_hash TLS Extension
The "webrtc_id_hash" TLS extension carries a hash of the identity The "webrtc_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 "webrtc_id_hash" extension contains a The "extension_data" for the "webrtc_id_hash" extension contains a
WebrtcIdentityHash struct, described below using the syntax defined WebrtcIdentityHash struct, described below using the syntax defined
in [RFC5246]: in [RFC5246]:
skipping to change at page 9, line 44 skipping to change at page 10, line 32
to the value of the identity assertion from its peer MUST immediately to the value of the identity assertion from its peer MUST immediately
fail the TLS handshake with an error. This includes cases where the fail the TLS handshake with an error. This includes cases where the
"identity" attribute is not present in the SDP. "identity" attribute is not present in the SDP.
A "webrtc_id_hash" extension that is any length other than 0 or 32 is A "webrtc_id_hash" extension that is any length other than 0 or 32 is
invalid and MUST cause the receiving endpoint to generate a fatal invalid and MUST cause the receiving endpoint to generate a fatal
"decode_error" alert. "decode_error" alert.
A peer that receives an identity assertion, but does not receive a A peer that receives an identity assertion, but does not receive a
"webrtc_id_hash" extension MAY choose to fail the connection, though "webrtc_id_hash" extension MAY choose to fail the connection, though
it is expected that implementations that were written prior to the it is expected that implementations written prior to the definition
existence of this document will not support these extensions for some of the extensions in this document will not support both for some
time. time.
In TLS 1.3, the "webrtc_id_hash" extension MUST be sent in the In TLS 1.3, the "webrtc_id_hash" extension MUST be sent in the
EncryptedExtensions message. EncryptedExtensions message.
5. 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 creates a situation where both peers believe
that they are talking to the attacker when they are talking to each that they are talking to the attacker when they are talking to each
other. other.
Session concatention is possible at higher layers: an attacker can This kind of attack is prevented by systems that enable peer
establish two independent sessions and simply forward any data it authentication such as WebRTC identity [WEBRTC-SEC] or SIP identity
receives from one into the other. This kind of attack is prevented [RFC4474]. However, session concatention remains possible at higher
by systems that enable peer authentication such as WebRTC identity layers: an attacker can establish two independent sessions and simply
[I-D.ietf-rtcweb-security-arch] or SIP identity [RFC4474]. 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. The
value to an attacker is limited unless information from the TLS value to an attacker is limited unless information from the TLS
connection is extracted and used with the signaling. For instance, a connection is extracted and used with the signaling. For instance, a
key exporter [RFC5705] might be used to create a shared secret or key exporter [RFC5705] might be used to create a shared secret or
unique identifier that is used in a secondary protocol. unique identifier that is used in a secondary protocol.
If a secondary protocol uses the signaling channel with the If a secondary protocol uses the signaling channel with the
assumption that the signaling and TLS peers are the same then that assumption that the signaling and TLS peers are the same then that
protocol is vulnerable to attack. The identity of the peer at the protocol is vulnerable to attack unless they also validate the
TLS layer is not guaranteed to be the same as the identity of the identity of peers at both layers. Use of the "external_session_id"
signaling peer. does not guarantee that the identity of the peer at the TLS layer is
the same as the identity of the signaling peer.
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.
skipping to change at page 11, line 24 skipping to change at page 12, line 9
o The "external_session_id" extension has been assigned a code point o The "external_session_id" extension has been assigned a code point
of TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. of TBD; it is recommended and is marked as "Encrypted" in TLS 1.3.
o The "webrtc_id_hash" extension has been assigned a code point of o The "webrtc_id_hash" extension has been assigned a code point of
TBD; it is recommended and is marked as "Encrypted" in TLS 1.3. TBD; it is recommended and is marked as "Encrypted" in TLS 1.3.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mmusic-dtls-sdp] [DTLS-SDP]
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-13 (work in progress), October 2017.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] 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>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
skipping to change at page 12, line 30 skipping to change at page 13, line 9
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[SHA] Dang, Q., "Secure Hash Standard", National Institute of [SHA] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.180-4, July 2015. DOI 10.6028/nist.fips.180-4, July 2015.
[WEBRTC-SEC]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-13 (work in progress), October 2017.
8.2. Informative References 8.2. Informative References
[ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-20 (work in progress), March 2018.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc4474>.
 End of changes. 38 change blocks. 
96 lines changed or deleted 142 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/