draft-ietf-mmusic-sdp-uks-05.txt   draft-ietf-mmusic-sdp-uks-06.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 June 05, 2019 Intended status: Standards Track July 17, 2019
Expires: December 7, 2019 Expires: January 18, 2020
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-05 draft-ietf-mmusic-sdp-uks-06
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. Mitigation techniques are defined
defined for each. that implementations of RFC 8122 are encouraged to deploy.
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 December 7, 2019. This Internet-Draft will expire on January 18, 2020.
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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 6 3. Attack on Identity Bindings . . . . . . . . . . . . . . . . . 6
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8
4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 9 4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 9
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Unique Session Identity Solution . . . . . . . . . . . . 12 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12
4.3. The external_session_id TLS Extension . . . . . . . . . . 12 4.3. The external_session_id TLS Extension . . . . . . . . . . 13
5. Consequences of Session Concatenation . . . . . . . . . . . . 13 5. Consequences of Session Concatenation . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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].
skipping to change at page 3, line 6 skipping to change at page 3, line 6
peers check that a hash, or fingerprint, provided in the SDP matches peers check that a hash, or fingerprint, provided in the SDP matches
the certificate that is used in the TLS or DTLS handshake. the certificate that is used in the TLS or DTLS handshake.
WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity
[SIP-ID] both provide a mechanism that binds an external identity to [SIP-ID] both provide a mechanism that binds an external identity to
the certificate fingerprints from a session description. However, the certificate fingerprints from a session description. However,
this binding is not integrity-protected and therefore vulnerable to this binding is not integrity-protected and therefore vulnerable to
an identity misbinding attack - or unknown key-share (UKS) attack - an identity misbinding attack - or unknown key-share (UKS) attack -
where the attacker binds their identity to the fingerprint of another where the attacker binds their identity to the fingerprint of another
entity. A successful attack leads to the creation of sessions where entity. A successful attack leads to the creation of sessions where
peers are confused about the identify of the participants. peers are confused about the identity of the participants.
This document describes a TLS extension that can be used in This document describes a TLS extension that can be used in
combination with these identity bindings to prevent this attack. combination with these identity bindings to prevent this attack.
A similar attack is possible with the use of certificate fingerprints A similar attack is possible with the use of certificate fingerprints
alone. Though attacks in this setting are likely infeasible in alone. Though attacks in this setting are likely infeasible in
existing deployments due to the narrow conditions necessary (see existing deployments due to the narrow conditions necessary (see
Section 2.1), this document also describes mitigations for this Section 2.1), this document also describes mitigations for this
attack. attack.
skipping to change at page 4, line 15 skipping to change at page 4, line 15
identity to a session with any other entity. identity to a session with any other entity.
The attacker obtains an identity assertion for an identity it The attacker obtains an identity assertion for an identity it
controls, but binds that to the fingerprint of one peer. The controls, but binds that to the fingerprint of one peer. The
attacker is then able to cause a TLS connection to be established attacker is then able to cause a TLS connection to be established
where two endpoints communicate. The victim that has its fingerprint where two endpoints communicate. The victim that has its fingerprint
copied by the attack correctly believes that it is communicating with copied by the attack correctly believes that it is communicating with
the other victim; however, the other victim incorrectly believes that the other victim; however, the other victim incorrectly believes that
it is communicating with the attacker. it is communicating with the attacker.
An unknown key-share attack does not result in the attacker having
access to any confidential information exchanged between victims.
However, the failure in mutual authentication can enable other
attacks. A victim might send information to the wrong entity as a
result. Where information is interpreted in context, misrepresenting
that context could lead to the information being misinterpreted.
A similar attack can be mounted without any communications A similar attack can be mounted without any communications
established based on the SDP "fingerprint" attribute [FINGERPRINT]. established based on the SDP "fingerprint" attribute [FINGERPRINT].
This attack is an aspect of SDP-based protocols that the technique This attack is an aspect of SDP-based protocols that the technique
known as third-party call control (3PCC) [RFC3725] relies on. 3PCC known as third-party call control (3PCC) [RFC3725] relies on. 3PCC
exploits the potential for the identity of a signaling peer to be exploits the potential for the identity of a signaling peer to be
different than the media peer, allowing the media peer to be selected different than the media peer, allowing the media peer to be selected
by the signaling peer. Section 2.3 describes the consequences of the by the signaling peer. Section 2.3 describes the consequences of the
mitigations described here for systems that use 3PCC. mitigations described here for systems that use 3PCC.
skipping to change at page 6, line 27 skipping to change at page 6, line 34
the first victim. the first victim.
A variation on the same technique can be used to cause both victims 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 to both believe they are talking to the attacker when they are
talking to each other. In this case, the attacker performs the talking to each other. In this case, the attacker performs the
identity misbinding once for each victim. identity misbinding once for each victim.
The problem might appear to be caused by the fact that the authority 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. Neither SIP nor WebRTC identity providers are not
required to perform this validation. This is not an issue because required to perform this validation. However, validation of keys by
verifying control of the associated keys is not a necessary condition the identity provided is not relevant because verifying control of
for a secure protocol, nor would it be sufficient to prevent attack the associated keys is not a necessary condition for a secure
[SIGMA]. 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 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
skipping to change at page 7, line 48 skipping to change at page 8, line 9
presented by Mallory. This session (Signaling2 in the figure) can be presented by Mallory. This session (Signaling2 in the figure) can be
entirely legitimate. entirely legitimate.
A DTLS session is established directly between Norma and Patsy. In A DTLS session is established directly between Norma and Patsy. In
order for this to happen Mallory can substitute transport-level order for this to happen Mallory can substitute transport-level
information in both sessions to facilitate this, though this is not information in both sessions to facilitate this, though this is not
necessary if Mallory is on the network path between Norma and Patsy. necessary if Mallory is on the network path between Norma and Patsy.
As a result, Patsy correctly believes that she is communicating with As a result, Patsy correctly believes that she is communicating with
Norma. However, Norma incorrectly believes she is talking to Norma. However, Norma incorrectly believes she is talking to
Mallory. Mallory. As stated in Section 2, Mallory cannot access media, but
Norma might send information to Patsy that is Norma might not intend
or that Patsy might misinterpret.
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 Section 3 of [TLS13]: defined in Section 3 of [TLS13]:
skipping to change at page 11, line 23 skipping to change at page 11, line 50
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. Just like the example in Section 3.1, Mallory cannot access
media, but Norma might send information to Patsy that is Norma might
not intend or that Patsy might misinterpret.
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 also be established. Mallory only needs to ensure that that session also be established. Mallory only needs to ensure that
Patsy maintains the active session and does not abandon the session Patsy maintains the active session and does not abandon the session
prematurely. For this reason, it might be necessary to permit the prematurely. For this reason, it might be necessary to permit the
signaling from Patsy to reach Norma to allow Patsy to receive a call signaling from Patsy to reach Norma to allow Patsy to receive a call
setup completion signal, such as a SIP ACK. Once the second session setup completion signal, such as a SIP ACK. Once the second session
is established, Mallory might cause DTLS packets sent by Norma to is established, Mallory might cause DTLS packets sent by Norma to
Patsy to be dropped. It is likely that these DTLS packets will be Patsy to be dropped. It is likely that these DTLS packets will be
skipping to change at page 13, line 7 skipping to change at page 13, line 35
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].
Where RTP and RTCP [RTP] are not multiplexed, it is possible that the Where RTP and RTCP [RTP] are not multiplexed, it is possible that the
two separate DTLS connections carrying RTP and RTCP can be switched. two separate DTLS connections carrying RTP and RTCP can be switched.
This is considered benign since these protocols are usually This is considered benign since these protocols are designed to be
distinguishable. RTP/RTCP multiplexing is advised to address this distinguishable. RTP/RTCP multiplexing is advised to address this
problem. 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
"external_session_id" extension MUST NOT be included in a "external_session_id" extension MUST NOT be included in a
ServerHello. ServerHello.
Endpoints MUST check that the "session_id" parameter in the extension Endpoints MUST check that the "session_id" parameter in the extension
skipping to change at page 15, line 7 skipping to change at page 15, line 36
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]:
o The "external_id_hash" extension defined in Section 3.2 has been o The "external_id_hash" extension defined in Section 3.2 has been
assigned a code point of TBD; it is recommended and is marked as assigned a code point of TBD; it is recommended and is marked as
"CH, EE" in TLS 1.3. "CH, EE" in TLS 1.3.
o The "external_session_id" extension defined in Section 4.3 has o The "external_session_id" extension defined in Section 4.3 has
been assigned a code point of TBD; it is recommended and is marked been assigned a code point of TBD; it is recommended and is marked
as "Encrypted" in TLS 1.3. as "CH, EE" in TLS 1.3.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80, [ASCII] 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>.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
skipping to change at page 16, line 39 skipping to change at page 17, line 26
[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-18 (work in progress), February 2019. rtcweb-security-arch-19 (work in progress), July 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,
 End of changes. 14 change blocks. 
23 lines changed or deleted 34 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/