draft-ietf-straw-b2bua-dtls-srtp-08.txt   draft-ietf-straw-b2bua-dtls-srtp-09.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: April 21, 2016 Cisco Expires: May 25, 2016 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
October 19, 2015 November 22, 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-08 draft-ietf-straw-b2bua-dtls-srtp-09
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 behaviour of such B2BUAs when acting on
acting on the media plane that uses an Secure Real-time Transport the media plane that uses an Secure Real-time Transport (SRTP)
(SRTP) security context set up with the Datagram Transport Layer security context set up with the Datagram Transport Layer Security
Security (DTLS) protocol. (DTLS) protocol.
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 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 April 21, 2016. This Internet-Draft will expire on May 25, 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 42 skipping to change at page 2, line 42
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 currently defined presented during the DTLS handshake. DTLS-SRTP is currently defined
for point-to-point media sessions, in which there are exactly two for point-to-point media sessions, in which there are exactly two
participants. Each DTLS-SRTP session (described in Section 3 of participants. Each DTLS-SRTP session (described in Section 3 of
[RFC5764]) contains a single DTLS connection (if RTP and RTCP are [RFC5764]) contains a single DTLS connection (if RTP and RTCP are
multiplexed) or two DTLS connections (if RTP and RTCP are not multiplexed) or two DTLS connections (if RTP and RTCP are not
multiplexed), and either two SRTP contexts (if media traffic is multiplexed), and either two SRTP contexts (if media traffic is
flowing in both directions on the same 5-tuple) or one SRTP context flowing in both directions on the same 5-tuple) or one SRTP context
(if media traffic is only 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)
skipping to change at page 3, line 26 skipping to change at page 3, line 26
according to the level of activities performed on the media plane: according to the level of activities performed on the media plane:
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 can follow to
order to avoid any impact to end-to-end DTLS-SRTP sessions. The avoid breaking end-to-end DTLS-SRTP sessions. B2BUAs terminating
DTLS-SRTP framework [RFC5763] recommends that endpoints or proxy DTLS-SRTP session are outside the scope of this document. When
server in the endpoint domain use [RFC4474] to integrity protect the [RFC4474] is used for DTLS-SRTP sessions, the fingerprint attributes
fingerprint attributes. Thus, under most circumstances, B2BUAs are integrity protected. Thus, under circumstances when [RFC4474] is
cannot terminate the DTLS-SRTP session without invalidating the used, B2BUAs cannot terminate the DTLS-SRTP session without
signature and causing the session to fail. 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. 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.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
setup attribute it receives from one endpoint unmodified towards the setup attribute it receives from one endpoint unmodified towards the
other endpoint and vice-versa. The example below shows a SIP call other endpoint and vice-versa. The example below shows a SIP call
establishment flow, with both SIP endpoints (user agents) using DTLS- establishment flow, with both SIP endpoints (user agents) using DTLS-
SRTP, and a media relay B2BUA. SRTP, and a media relay B2BUA.
+-------+ +------------------+ +-----+ +-------+ +------------------+ +-----+
| Alice | | MediaRelay B2BUA | | Bob | | Alice | | MediaRelay B2BUA | | Bob |
+-------+ +------------------+ +-----+ +-------+ +------------------+ +-----+
|(1) INVITE | (3)INVITE | |(1) INVITE | (3)INVITE |
| a=setup:actpass | a=setup:actpass | | a=setup:actpass | a=setup:actpass |
| a=fingerprint1 | a= fingerprint1 | | a=fingerprint1 | a=fingerprint1 |
| (alice's IP/port) | (B2BUAs IP/port) | | (alice's IP/port) | (B2BUAs IP/port) |
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| | | | | |
| (2) 100 trying | | | (2) 100 trying | |
|<------------------------| | |<------------------------| |
| | (4) 100 trying | | | (4) 100 trying |
| |<--------------------------| | |<--------------------------|
| | | | | |
| | (5)200 OK | | | (5)200 OK |
| | a=setup:active | | | a=setup:active |
skipping to change at page 6, line 9 skipping to change at page 6, line 9
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 MUST be prepared to response can happen in parallel; thus, the B2BUA MUST be prepared to
receive DTLS, STUN and media on the ports it advertised to Bob in the receive DTLS, STUN and media on the ports it advertised to Bob in the
SIP offer before it receives a SIP answer from Bob. Since a media SDP offer before it receives a SDP answer from Bob. Since a media
relay B2BUA does not differentiate between a DTLS message, RTP or any relay B2BUA does not differentiate between a DTLS message, RTP or any
packet it receives, it only changes the transport layer (UDP/TCP) and packet it receives, it only changes the transport layer (UDP/TCP) and
IP headers and forwards the packet towards the other endpoint. The IP headers and forwards the packet towards the other endpoint. The
B2BUA cannot decrypt the RTP payload as the payload is encrypted B2BUA cannot decrypt the RTP payload as the payload is encrypted
using the SRTP keys derived from the DTLS connection setup between using the SRTP keys derived from the DTLS connection setup between
Alice and Bob. Alice and Bob.
[RFC4474] provides a means for signing portions of SIP requests in [RFC4474] provides a means for signing portions of SIP requests in
order to provide identity assurance and certificate pinning by order to provide identity assurance and certificate pinning by
providing a signature over the SDP that carries the fingerprint of providing a signature over the SDP that carries the fingerprint of
keying for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST ensure that keying for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST ensure that
it does not modify any of the information used to construct the it does not modify any of the information used to 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
[RFC4474]. In such a case, if the B2BUA modifies some of the SIP [RFC4474]. In such a case, if the B2BUA modifies some of the SIP
headers or SDP content that was used by Alice's authorization server headers or SDP content that was used by Alice's authorization server
to generate the identity, it would break the identity verification to generate the identity signature and place it in the Identity
procedure explained in Section 6 of [RFC4474] resulting in a 438 header field, it would break the identity verification procedure
error response being returned. explained in Section 6 of [RFC4474] resulting in a 438 error response
being 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 unencrypted relays, those that merely inspect the RTP headers and unencrypted
portions of RTCP packets, and those that inspect and modify the RTP portions of RTCP packets, and those that inspect and modify the RTP
headers and unencrypted portions of RTCP packets. The identity headers and unencrypted portions of RTCP packets. The identity
integrity protection procedures described in Security Considerations integrity protection procedures described in Section 5 can be used by
section MUST be used by the endpoint or the proxy server in the the endpoint or the proxy server in the endpoints network to detect
endpoints network to detect malicious B2BUAs that attempt to 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 A RTP/RTCP aware media relay does not modify the RTP headers and RTCP
RTCP packets but only inspects the packets. It MUST NOT terminate packets but only inspects the packets. It is RECOMMENDED that these
the DTLS-SRTP session on which the packets are received. B2BUAs do not terminate 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
A B2BUA cannot modify RTP headers or RTCP packets, as to do so it A B2BUA cannot modify RTP headers or RTCP packets, as to do so it
would need to act as a DTLS endpoint, terminate the DTLS-SRTP session would need to act as a DTLS endpoint, terminate the DTLS-SRTP session
and decrypt/re-encrypt RTP packet. This would cause the identity and and decrypt/re-encrypt RTP packet. This would cause the identity and
integrity protection procedures discussed in [RFC4474] to fail and integrity protection procedures discussed in [RFC4474] to fail. This
hence a B2BUA MUST NOT terminate the DTLS-SRTP session. This
security and privacy problem can be mitigated by having different security and privacy problem can be mitigated by having different
keys for protecting RTP header integrity and encrypting the RTP keys for protecting RTP header integrity and encrypting the RTP
payload. For example, the approach discussed in payload. For example, the approach discussed in
[I-D.jones-perc-private-media-reqts] can be used. With such an [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 approach, the B2BUA is not aware of the keys used to decrypt the
media payload. 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
skipping to change at page 8, line 29 skipping to change at page 8, line 29
\ \
\ \
Charlie (192.0.2.2:6666) Charlie (192.0.2.2:6666)
Figure 2: B2BUA handling multiple answers Figure 2: B2BUA handling multiple answers
For instance, as shown in Figure 2 Alice sends a request with an For instance, as shown in Figure 2 Alice sends a request with an
offer, and the request is forked. Alice receives answers from both offer, and the request is forked. Alice receives answers from both
Bob and Charlie. B2BUA MUST advertise different B2BUA transport Bob and Charlie. B2BUA MUST advertise different B2BUA transport
address in each answer, as shown in Figure2, where XXX and YYY address in each answer, as shown in Figure2, where XXX and YYY
represent different DTLS-SRTP sessions. B2BUA replaces the Bob's represent different DTLS-SRTP sessions. B2BUA replaces Bob's
transport address (192.0.2.1:6666) in the answer with its transport transport address (192.0.2.1:6666) in the answer with its transport
address (192.0.2.3:7777) and Charlie's transport address address (192.0.2.3:7777) and Charlie's transport address
(192.0.2.2:6666) in the answer with its transport address (192.0.2.2:6666) in the answer with its transport address
(192.0.2.3:8888). B2BUA tracks the remote sources (Bob and Charlie) (192.0.2.3:8888). B2BUA tracks the remote sources (Bob and Charlie)
and associates them to the local sources that are used to send and associates them to the local sources that are used to send
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. Security it is RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session.
considerations discussed in [RFC5763] are also applicable to this Security considerations discussed in [RFC5763] are also applicable to
document. In addition, the B2BUA behaviors outlined in this document this document. In addition, the B2BUA behaviors outlined in this
do not impact the security and integrity of a DTLS-SRTP session or document do not impact the security and integrity of a DTLS-SRTP
the data exchanged over it. A malicious B2BUA can try to break into session or the data exchanged over it. A malicious B2BUA can try to
the DTLS connection, but such an attack can be prevented using the break into the DTLS connection, but such an attack can be prevented
identity validation mechanism discussed in [RFC4474]. Either the using the identity validation mechanism discussed in [RFC4474].
endpoints or authentication service proxies involved in the call MUST Either the endpoints or authentication service proxies involved in
use the identity validation mechanisms discussed in [RFC4474] to the call MUST use the identity validation mechanisms discussed in
validate the identity of peers and detect malicious B2BUA's that can [RFC4474] to validate the identity of peers and detect malicious
attempt to terminate the DTLS connection to decrypt the RTP payload. B2BUA's that can attempt to 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, Colin Perkins and Ben Campbell for their Christer Holmberg, Colin Perkins and Ben Campbell for their
constructive comments,suggestions, and early reviews that were constructive comments, suggestions, and early reviews that were
critical to the formulation and refinement of this document. critical to the formulation and refinement of this document. The
authors would also like to thank Dan Romascanu, Vijay K. Gurbani,
Francis Dupont and Paul Wouters for their review and feedback 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 11, line 34 skipping to change at page 11, line 38
Cisco Cisco
Cessna Business Park Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: rmohanr@cisco.com Email: rmohanr@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Cisco
Cessna Business Park, Varthur Hobli Cessna Business Park
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
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
 End of changes. 20 change blocks. 
48 lines changed or deleted 52 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/