draft-ietf-straw-b2bua-dtls-srtp-07.txt   draft-ietf-straw-b2bua-dtls-srtp-08.txt 
STRAW R. Ravindranath STRAW R. Ravindranath
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track G. Salgueiro Intended status: Standards Track G. Salgueiro
Expires: March 17, 2016 Cisco Expires: April 21, 2016 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
September 14, 2015 October 19, 2015
DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
User Agents (B2BUAs) User Agents (B2BUAs)
draft-ietf-straw-b2bua-dtls-srtp-07 draft-ietf-straw-b2bua-dtls-srtp-08
Abstract Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
often act on the media plane, rather than just on the signaling path. often act on the media plane, rather than just on the signaling path.
This document describes the behavior such B2BUAs can adhere to when This document describes the behavior such B2BUAs can adhere to when
acting on the media plane that uses an Secure Real-time Transport acting on the media plane that uses an Secure Real-time Transport
(SRTP) security context set up with the Datagram Transport Layer (SRTP) security context set up with the Datagram Transport Layer
Security (DTLS) protocol. Security (DTLS) protocol.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 17, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 43 skipping to change at page 2, line 43
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
[RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261] [RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261]
can be used to establish a Secure Real-time Transport Protocol (SRTP) can be used to establish a Secure Real-time Transport Protocol (SRTP)
[RFC3711] security context with the Datagram Transport Layer Security [RFC3711] security context with the Datagram Transport Layer Security
(DTLS) [RFC6347] protocol. It describes a mechanism for transporting (DTLS) [RFC6347] protocol. It describes a mechanism for transporting
a certificate fingerprint using Session Description Protocol (SDP) a certificate fingerprint using Session Description Protocol (SDP)
[RFC4566]. The fingerprint, identifies the certificate that will be [RFC4566]. The fingerprint, identifies the certificate that will be
presented during the DTLS handshake. DTLS-SRTP is defined for point- presented during the DTLS handshake. DTLS-SRTP is currently defined
to-point media sessions, in which there are exactly two participants. for point-to-point media sessions, in which there are exactly two
Each DTLS-SRTP session (described in Section 3 of [RFC5764]) contains participants. Each DTLS-SRTP session (described in Section 3 of
a single DTLS connection (if RTP and RTCP are multiplexed) or two [RFC5764]) contains a single DTLS connection (if RTP and RTCP are
DTLS connections (if RTP and RTCP are not multiplexed), and either multiplexed) or two DTLS connections (if RTP and RTCP are not
two SRTP contexts (if media traffic is flowing in both directions on multiplexed), and either two SRTP contexts (if media traffic is
the same 5-tuple) or one SRTP context (if media traffic is only flowing in both directions on the same 5-tuple) or one SRTP context
flowing in one direction). (if media traffic is only flowing in one direction).
In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) In many SIP deployments, SIP Back-to-Back User Agents (B2BUA)
entities exist on the SIP signaling path between the endpoints. As entities exist on the SIP signaling path between the endpoints. As
described in [RFC7092], these B2BUAs can modify SIP and SDP described in [RFC7092], these B2BUAs can modify SIP and SDP
information. They can also be present on the media path, in which information. They can also be present on the media path, in which
case they modify parts of the SDP information (like IP address, port) case they modify parts of the SDP information (like IP address, port)
and subsequently modify the RTP headers as well. Such B2BUAs are and subsequently modify the RTP headers as well. Such B2BUAs are
referred to as media plane B2BUAs. referred to as media plane B2BUAs.
1.2. Goals 1.2. Goals
skipping to change at page 3, line 27 skipping to change at page 3, line 27
A B2BUA that acts as a simple media relay effectively unaware of A B2BUA that acts as a simple media relay effectively unaware of
anything that is transported and only terminates the media plane anything that is transported and only terminates the media plane
at the IP and transport (UDP/TCP) layers. at the IP and transport (UDP/TCP) layers.
A B2BUA that performs a media-aware role. It inspects and A B2BUA that performs a media-aware role. It inspects and
potentially modifies RTP headers or RTP Control Protocol (RTCP) potentially modifies RTP headers or RTP Control Protocol (RTCP)
packets. packets.
The following sections describe the behavior B2BUAs MUST follow in The following sections describe the behavior B2BUAs MUST follow in
order to avoid any impact to end-to-end DTLS-SRTP sessions. order to avoid any impact to end-to-end DTLS-SRTP sessions. The
DTLS-SRTP framework [RFC5763] recommends that endpoints or proxy
server in the endpoint domain use [RFC4474] to integrity protect the
fingerprint attributes. Thus, under most circumstances, B2BUAs
cannot terminate the DTLS-SRTP session without invalidating the
signature and causing the session to fail.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Transport Address: The combination of an IP address and port number.
The following generalized terms are defined in [RFC3261], Section 6. The following generalized terms are defined in [RFC3261], Section 6.
B2BUA: a SIP Back-to-Back User Agent, which is the logical B2BUA: a SIP Back-to-Back User Agent, which is the logical
combination of a User Agent Server (UAS) and User Agent Client combination of a User Agent Server (UAS) and User Agent Client
(UAC). (UAC).
UAS: a SIP User Agent Server. UAS: a SIP User Agent Server.
UAC: a SIP User Agent Client. UAC: a SIP User Agent Client.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
the sake of simplicity. In reality depending on whether the RTP and the sake of simplicity. In reality depending on whether the RTP and
RTCP flows are multiplexed or demultiplexed there will be one or two RTCP flows are multiplexed or demultiplexed there will be one or two
DTLS connections. DTLS connections.
If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a
single port then only a single DTLS connection is required between single port then only a single DTLS connection is required between
the peers. If RTP and RTCP are not multiplexed, then the peers would the peers. If RTP and RTCP are not multiplexed, then the peers would
have to establish two DTLS connections. In this case, Bob, after he have to establish two DTLS connections. In this case, Bob, after he
receives an INVITE request, triggers the establishment of a DTLS receives an INVITE request, triggers the establishment of a DTLS
connection. Note that the DTLS handshake and the sending of INVITE connection. Note that the DTLS handshake and the sending of INVITE
response can happen in parallel; thus, the B2BUA SHOULD be prepared response can happen in parallel; thus, the B2BUA MUST be prepared to
to receive DTLS, STUN and media on the ports it advertised to Bob in receive DTLS, STUN and media on the ports it advertised to Bob in the
the INVITE request. Since a media relay B2BUA does not differentiate SIP offer before it receives a SIP answer from Bob. Since a media
between a DTLS message, RTP or any packet it receives, it only relay B2BUA does not differentiate between a DTLS message, RTP or any
changes the transport layer (UDP/TCP) and IP headers and forwards the packet it receives, it only changes the transport layer (UDP/TCP) and
packet towards the other endpoint. B2BUA cannot decrypt the RTP IP headers and forwards the packet towards the other endpoint. The
payload as the payload is encrypted using the SRTP keys derived from B2BUA cannot decrypt the RTP payload as the payload is encrypted
the DTLS connection setup between Alice and Bob. using the SRTP keys derived from the DTLS connection setup between
Alice and Bob.
[I-D.ietf-stir-rfc4474bis] provides a means for signing portions of [RFC4474] provides a means for signing portions of SIP requests in
SIP requests in order to provide identity assurance and certificate order to provide identity assurance and certificate pinning by
pinning by providing a signature over the fingerprint of keying providing a signature over the SDP that carries the fingerprint of
material in SDP for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST keying for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST ensure that
ensure that it does not modify any of the information used to it does not modify any of the information used to construct the
construct the signature. signature.
In the above example, Alice can be authorized by the authorization In the above example, Alice can be authorized by the authorization
server (SIP proxy) in its domain using the procedures in Section 5 of server (SIP proxy) in its domain using the procedures in Section 5 of
[I-D.ietf-stir-rfc4474bis]. In such a case, if the B2BUA modifies [RFC4474]. In such a case, if the B2BUA modifies some of the SIP
some of the SIP headers or SDP content that was used by Alice's headers or SDP content that was used by Alice's authorization server
authorization server to generate the identity, it would break the to generate the identity, it would break the identity verification
identity verification procedure explained in Section 4.2 of procedure explained in Section 6 of [RFC4474] resulting in a 438
[I-D.ietf-stir-rfc4474bis] resulting in a 438 error response being error response being returned.
returned.
3.1.2. RTP/RTCP-aware Media Aware B2BUA 3.1.2. RTP/RTCP-aware Media Aware B2BUA
Unlike the media relay discussed in Section 3.1.1, a media-aware Unlike the media relay discussed in Section 3.1.1, a media-aware
relay as defined in Section 3.2.2 of [RFC7092], is aware of the type relay as defined in Section 3.2.2 of [RFC7092], is aware of the type
of media traffic it is receiving. There are two types of media-aware of media traffic it is receiving. There are two types of media-aware
relay, those that merely inspect the RTP headers and RTCP packets, relay, those that merely inspect the RTP headers and unencrypted
and those that inspect and modify the RTP headers and RTCP packets. portions of RTCP packets, and those that inspect and modify the RTP
The mechanism described in Security Considerations section MUST be headers and unencrypted portions of RTCP packets. The identity
used by endpoint to detect malicious B2BUA's that MAY attempt to integrity protection procedures described in Security Considerations
section MUST be used by the endpoint or the proxy server in the
endpoints network to detect malicious B2BUAs that attempt to
terminate the DTLS-SRTP session. terminate the DTLS-SRTP session.
3.1.2.1. RTP header and RTCP packets Inspection 3.1.2.1. RTP header and RTCP packets Inspection
This kind of media aware relay does not modify the RTP headers and This kind of media aware relay does not modify the RTP headers and
RTCP packets but only inspects the packets. It MUST NOT terminate RTCP packets but only inspects the packets. It MUST NOT terminate
the DTLS-SRTP session on which the packets are received. the DTLS-SRTP session on which the packets are received.
3.1.2.2. RTP header and RTCP packet Modification 3.1.2.2. RTP header and RTCP packet Modification
In order to modify headers a B2BUA needs to act as a DTLS endpoint A B2BUA cannot modify RTP headers or RTCP packets, as to do so it
and terminate the DTLS-SRTP session and decrypt/re-encrypt RTP would need to act as a DTLS endpoint, terminate the DTLS-SRTP session
payload. This would break end-to-end security and hence a B2BUA MUST and decrypt/re-encrypt RTP packet. This would cause the identity and
NOT terminate DTLS-SRTP session. This security and privacy problem integrity protection procedures discussed in [RFC4474] to fail and
can be mitigated by having different keys for protecting RTP header hence a B2BUA MUST NOT terminate the DTLS-SRTP session. This
integrity and encrypting the RTP payload. For example, the approach security and privacy problem can be mitigated by having different
discussed in [I-D.jones-perc-private-media-reqts] can be used. With keys for protecting RTP header integrity and encrypting the RTP
such an approach, the B2BUA is not aware of the keys used to decrypt payload. For example, the approach discussed in
the media payload. [I-D.jones-perc-private-media-reqts] can be used. With such an
approach, the B2BUA is not aware of the keys used to decrypt the
media payload.
3.2. Media Plane B2BUA with NAT Handling 3.2. Media Plane B2BUA with NAT Handling
DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may
happen in parallel. If an endpoint is behind a NAT, and the endpoint happen in parallel. If an endpoint is behind a NAT, and the endpoint
is acting as a DTLS server, the ClientHello message from a B2BUA is acting as a DTLS server, the ClientHello message from a B2BUA
(acting as DTLS client) is likely to be lost, as described in (acting as DTLS client) is likely to be lost, as described in
Section 7.3 of [RFC5763]. In order to overcome this problem, the Section 7.3 of [RFC5763]. In order to overcome this problem, the
endpoint and B2BUA can support the Interactive Connectivity endpoint and B2BUA can support the Interactive Connectivity
Establishment (ICE) mechanism [RFC5245], as discussed in Section 7.3 Establishment (ICE) mechanism [RFC5245], as discussed in Section 7.3
skipping to change at page 7, line 38 skipping to change at page 7, line 40
4. Forking Considerations 4. Forking Considerations
Due to forking [RFC3261], a SIP request carrying an SDP offer sent by Due to forking [RFC3261], a SIP request carrying an SDP offer sent by
an endpoint (offerer) can reach multiple remote endpoints. As a an endpoint (offerer) can reach multiple remote endpoints. As a
result, multiple DTLS-SRTP sessions can be established, one between result, multiple DTLS-SRTP sessions can be established, one between
the endpoint that sent the SIP request and each of the remote the endpoint that sent the SIP request and each of the remote
endpoints that received the request. Both media relays and media- endpoints that received the request. Both media relays and media-
aware relays MUST forward the certificate fingerprints and SDP setup aware relays MUST forward the certificate fingerprints and SDP setup
attributes it received in the SDP answer from each endpoint attributes it received in the SDP answer from each endpoint
(answerer) unmodified towards the offerer. Since DTLS operates on (answerer) unmodified towards the offerer. Since each DTLS
the 5-tuple, B2BUA MUST replace the answerer's transport addresses in connection is setup on a unique 5-tuple, B2BUA MUST replace the
each answer with its unique transport addresses so that the offerer answerer's transport addresses in each answer with its unique
can establish a DTLS connection with each answerer. transport addresses so that the offerer can establish a DTLS
connection with each answerer.
Bob (192.0.2.1:6666) Bob (192.0.2.1:6666)
/ /
/ /
/ DTLS-SRTP=XXX / DTLS-SRTP=XXX
/ /
/ /
DTLS-SRTP=XXX v DTLS-SRTP=XXX v
<-----------> (192.0.2.3:7777) <-----------> (192.0.2.3:7777)
Alice (192.0.2.0:5555) B2BUA Alice (192.0.2.0:5555) B2BUA
skipping to change at page 8, line 45 skipping to change at page 8, line 45
packets to Alice. packets to Alice.
5. Security Considerations 5. Security Considerations
This document describes the behavior media plane B2BUAs (media-aware This document describes the behavior media plane B2BUAs (media-aware
and media-unaware) MUST follow when acting on the media plane that and media-unaware) MUST follow when acting on the media plane that
uses SRTP security context setup with the DTLS protocol. Attempting uses SRTP security context setup with the DTLS protocol. Attempting
to cover media-aware relay modifying RTP headers and media to cover media-aware relay modifying RTP headers and media
termination scenarios involving secure sessions (like DTLS-SRTP) will termination scenarios involving secure sessions (like DTLS-SRTP) will
inevitably lead to the B2BUA acting as a man-in-the-middle, and hence inevitably lead to the B2BUA acting as a man-in-the-middle, and hence
a B2BUA MUST NOT terminate DTLS-SRTP session. This document does not a B2BUA MUST NOT terminate DTLS-SRTP session. Security
introduce any specific security considerations beyond those detailed considerations discussed in [RFC5763] are also applicable to this
in [RFC5763]. In addition, the B2BUA behaviors outlined in this document. In addition, the B2BUA behaviors outlined in this document
document do not impact the security and integrity of a DTLS-SRTP do not impact the security and integrity of a DTLS-SRTP session or
session or the data exchanged over it. A malicious B2BUA MAY try to the data exchanged over it. A malicious B2BUA can try to break into
break into the DTLS connection, but such an attack can be prevented the DTLS connection, but such an attack can be prevented using the
using the identity validation mechanism discussed in [RFC4474] and identity validation mechanism discussed in [RFC4474]. Either the
getting updated in [I-D.ietf-stir-rfc4474bis]. Either the endpoints endpoints or authentication service proxies involved in the call MUST
or authentication service proxies involved in the call MUST use the use the identity validation mechanisms discussed in [RFC4474] to
identity validation mechanisms discussed in [RFC4474] to validate the validate the identity of peers and detect malicious B2BUA's that can
identity of peers and detect malicious B2BUA's that can attempt to attempt to terminate the DTLS connection to decrypt the RTP payload.
terminate the DTLS connection to decrypt the RTP payload.
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
7. Acknowledgments 7. Acknowledgments
Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan,
Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing,
Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa,
Christer Holmberg and Colin Perkins for their constructive Christer Holmberg, Colin Perkins and Ben Campbell for their
comments,suggestions, and early reviews that were critical to the constructive comments,suggestions, and early reviews that were
formulation and refinement of this document. critical to the formulation and refinement of this document.
8. Contributors 8. Contributors
Rajeev Seth provided substantial contributions to this document. Rajeev Seth provided substantial contributions to this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 10, line 30 skipping to change at page 10, line 30
9.2. Informative References 9.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., and E. Rescorla,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-05
(work in progress), September 2015.
[I-D.jones-perc-private-media-reqts] [I-D.jones-perc-private-media-reqts]
Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson, Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson,
J., and R. Barnes, "Private Media Requirements in Privacy J., and R. Barnes, "Private Media Requirements in Privacy
Enhanced RTP Conferencing", draft-jones-perc-private- Enhanced RTP Conferencing", draft-jones-perc-private-
media-reqts-00 (work in progress), July 2015. media-reqts-00 (work in progress), July 2015.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 12, line 4 skipping to change at page 11, line 40
Email: rmohanr@cisco.com Email: rmohanr@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Cisco
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: tireddy@cisco.com
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
Victor Pascual Victor Pascual
Quobis Quobis
Spain
Email: victor.pascual.avila@gmail.com Email: victor.pascual.avila@gmail.com
Parthasarathi Ravindran Parthasarathi Ravindran
Nokia Networks Nokia Networks
Bangalore, Karnataka Bangalore, Karnataka
India India
Email: partha@parthasarathi.co.in Email: partha@parthasarathi.co.in
 End of changes. 19 change blocks. 
73 lines changed or deleted 77 lines changed or added

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