draft-ietf-straw-b2bua-dtls-srtp-00.txt   draft-ietf-straw-b2bua-dtls-srtp-01.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: September 24, 2015 Cisco Expires: November 20, 2015 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
March 23, 2015 May 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-00 draft-ietf-straw-b2bua-dtls-srtp-01
Abstract Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
often function on the media plane, rather than just on the signaling often function on the media plane, rather than just on the signaling
path. This document describes the behavior B2BUAs should follow when path. This document describes the behavior B2BUAs should follow when
acting on the media plane that use Secure Real-time Transport (SRTP) acting on the media plane that use Secure Real-time Transport (SRTP)
security context setup with Datagram Transport Layer Security (DTLS) security context setup with Datagram Transport Layer Security (DTLS)
protocol. 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 September 24, 2015. This Internet-Draft will expire on November 20, 2015.
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 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 4 3. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 4
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Media Aware Relay . . . . . . . . . . . . . . . . . . . . 6 3.2. Media Aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.2.1. RTP and RTCP Header Inspection . . . . . . . . . . . 6 3.2.1. RTP and RTCP Header Inspection . . . . . . . . . . . 6
3.2.2. RTP and RTCP Header Modification . . . . . . . . . . 6 3.2.2. RTP and RTCP Header Modification . . . . . . . . . . 6
3.3. Media Plane B2BUA with NAT handling . . . . . . . . . . . 7 3.3. Media Plane B2BUA with NAT handling . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Forking . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 Datagram Transport Layer Security [RFC3711] security context with Datagram Transport Layer Security
(DTLS) [RFC6347] protocol. It describes a mechanism of transporting (DTLS) [RFC6347] protocol. It describes a mechanism of transporting
a certificate fingerprint in the Session Description Protocol (SDP) a certificate fingerprint in the Session Description Protocol (SDP)
[RFC4566], which identifies the certificate that will be presented [RFC4566], which identifies the certificate that will be presented
during the DTLS handshake. DTLS-SRTP is defined for point-to-point during the DTLS handshake. DTLS-SRTP is defined for point-to-point
media sessions, in which there are exactly two participants. Each media sessions, in which there are exactly two participants. Each
DTLS-SRTP session contains a single DTLS association, and either two DTLS-SRTP session (described in section 3 of [RFC5764]) contains a
SRTP contexts (if media traffic is flowing in both directions on the single DTLS association, and either two SRTP contexts (if media
same host/port quartet) or one SRTP context (if media traffic is only traffic is flowing in both directions on the same 5-tuple) or one
flowing in one direction). SRTP context (if media traffic is only flowing in one direction).
In many SIP deployments, SIP entities exist in the SIP signaling path In many SIP deployments, SIP entities exist in the SIP signaling path
between the originating and final terminating endpoints. These SIP between the originating and final terminating endpoints. These SIP
entities, as described in [RFC7092], modify SIP and SDP bodies and entities, as described in [RFC7092], modify SIP and SDP bodies and
also are likely to be on the media path. Such entities, when present also are likely to be on the media path. Such entities, when present
in the signaling/media path, are likely to do several things. For in the signaling/media path, are likely to do several things. For
example, some B2BUAs modify parts of the SDP body (like IP address, example, some B2BUAs modify parts of the SDP body (like IP address,
port) and subsequently modify the RTP headers as well. port) and subsequently modify the RTP headers as well.
1.2. Goals 1.2. Goals
skipping to change at page 5, line 27 skipping to change at page 5, line 27
| |<--------------------------| | |<--------------------------|
| | | | | |
| | (5)200 OK | | | (5)200 OK |
| | a=setup:active | | | a=setup:active |
| | a=fingerprint2 | | | a=fingerprint2 |
| | (Bob's IP, port) | | | (Bob's IP, port) |
|<------------------------|<--------------------------| |<------------------------|<--------------------------|
| (6) 200 OK | | | (6) 200 OK | |
| a=setup:active | | | a=setup:active | |
| a=fingerprint2 | | | a=fingerprint2 | |
| B2BUA's address,port | | | B2BUAs address,port | |
| (7, 8)ClientHello + use_srtp | | (7, 8)ClientHello + use_srtp |
|<------------------------|<--------------------------| |<------------------------|<--------------------------|
| | | | | |
| | | | | |
| (9,10)ServerHello + use_srtp | | (9,10)ServerHello + use_srtp |
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| (11) | | | (11) | |
| [Certificate exchange between Alice and Bob over | | [Certificate exchange between Alice and Bob over |
| DTLS ] | | | DTLS ] | |
| | | | | |
skipping to change at page 7, line 15 skipping to change at page 7, line 15
3.3. Media Plane B2BUA with NAT handling 3.3. Media Plane B2BUA with NAT handling
DTLS-SRTP handshakes and offer/answer can happen in parallel. If a DTLS-SRTP handshakes and offer/answer can happen in parallel. If a
UA is behind a NAT and acting as a DTLS server, the ClientHello UA is behind a NAT and acting as a DTLS server, the ClientHello
message from a B2BUA(DTLS client) is likely to be lost, as described message from a B2BUA(DTLS client) is likely to be lost, as described
in section 7.3 of [RFC5763]. In order to overcome this problem, a UA in section 7.3 of [RFC5763]. In order to overcome this problem, a UA
and B2BUA must support ICE as discussed in section 7.3 of [RFC5763]. and B2BUA must support ICE as discussed in section 7.3 of [RFC5763].
If ICE check is successful then UA will receive ClientHello packet If ICE check is successful then UA will receive ClientHello packet
from B2BUA. from B2BUA.
4. Security Considerations 4. Forking
In SIP, it is possible that a request can get forked and multiple
answers might be received for that request. So a single endpoint may
end up negotiating multiple DTLS-SRTP sessions due to forking. B2BUA
in both media relay and media aware relay modes MUST forward the
certificate fingerprints and setup attributes it receives from each
answerer as-is to the offerer.
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) should follow when acting on the media plane that and media-unaware) should follow when acting on the media plane that
uses SRTP security context setup with the DTLS protocol. It does not uses SRTP security context setup with the DTLS protocol. It does not
introduce any specific security considerations beyond those detailed introduce any specific security considerations beyond those detailed
in [RFC5763]. The B2BUA behaviors outlined here also do not impact in [RFC5763]. The B2BUA behaviors outlined here also do not impact
the security and integrity of the DTLS-SRTP session nor the data the security and integrity of the DTLS-SRTP session nor the data
exchanged over it. A malicious B2BUA can try to break into the DTLS exchanged over it. A malicious B2BUA can try to break into the DTLS
session, but such an attack can be prevented using the identity session, but such an attack can be prevented using the identity
validation mechanism discussed in [I-D.ietf-stir-rfc4474bis]. validation mechanism discussed in [I-D.ietf-stir-rfc4474bis].
5. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. 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 and Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing,
Charles Eckel for their constructive comments, suggestions, and early Charles Eckel and Simon Perreault for their constructive comments,
reviews that were critical to the formulation and refinement of this suggestions, and early reviews that were critical to the formulation
document. and refinement of this document.
7. Contributors 8. Contributors
Rajeev Seth provided substantial contributions to this document. Rajeev Seth provided substantial contributions to this document.
8. References 9. References
8.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
8.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., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
"A Taxonomy of Grouping Semantics and Mechanisms for Real- B. Burman, "A Taxonomy of Grouping Semantics and
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Mechanisms for Real-Time Transport Protocol (RTP)
rtp-grouping-taxonomy-06 (work in progress), March 2015. Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work
in progress), March 2015.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., and E. Rescorla, Peterson, J., Jennings, C., and E. Rescorla,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-03 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-03
(work in progress), March 2015. (work in progress), March 2015.
[I-D.jones-avtcore-private-media-reqts] [I-D.jones-avtcore-private-media-reqts]
Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson, Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson,
J., Cheng, Y., and R. Barnes, "Requirements for Private J., Cheng, Y., and R. Barnes, "Requirements for Private
 End of changes. 17 change blocks. 
31 lines changed or deleted 46 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/