draft-ietf-sip-dtls-srtp-framework-07.txt   rfc5763.txt 
SIP J. Fischl Internet Engineering Task Force (IETF) J. Fischl
Internet-Draft CounterPath Corporation Request for Comments: 5763 Skype, Inc.
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: September 8, 2009 Nokia Siemens Networks ISSN: 2070-1721 Nokia Siemens Networks
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
March 07, 2009 May 2010
Framework for Establishing an SRTP Security Context using DTLS
draft-ietf-sip-dtls-srtp-framework-07.txt
Status of this Memo Framework for Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security (DTLS)
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering This document specifies how to use the Session Initiation Protocol
Task Force (IETF), its areas, and its working groups. Note that (SIP) to establish a Secure Real-time Transport Protocol (SRTP)
other groups may also distribute working documents as Internet- security context using the Datagram Transport Layer Security (DTLS)
Drafts. protocol. It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake. The key
exchange travels along the media path as opposed to the signaling
path. The SIP Identity mechanism can be used to protect the
integrity of the fingerprint attribute from modification by
intermediate proxies.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 8, 2009. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5763.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document specifies how to use the Session Initiation Protocol This document may contain material from IETF Documents or IETF
(SIP) to establish an Secure Real-time Transport Protocol (SRTP) Contributions published or made publicly available before November
security context using the Datagram Transport Layer Security (DTLS) 10, 2008. The person(s) controlling the copyright in some of this
protocol. It describes a mechanism of transporting a fingerprint material may not have granted the IETF Trust the right to allow
attribute in the Session Description Protocol (SDP) that identifies modifications of such material outside the IETF Standards Process.
the key that will be presented during the DTLS handshake. The key Without obtaining an adequate license from the person(s) controlling
exchange travels along the media path as opposed to the signaling the copyright in such materials, this document may not be modified
path. The SIP Identity mechanism can be used to protect the outside the IETF Standards Process, and derivative works of it may
integrity of the fingerprint attribute from modification by not be created outside the IETF Standards Process, except to format
intermediate proxies. it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview ........................................................5
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Motivation ......................................................7
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Terminology .....................................................8
5. Establishing a Secure Channel . . . . . . . . . . . . . . . . 9 5. Establishing a Secure Channel ...................................8
6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 11 6. Miscellaneous Considerations ...................................10
6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 11 6.1. Anonymous Calls ...........................................10
6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Early Media ...............................................11
6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Forking ...................................................11
6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 12 6.4. Delayed Offer Calls .......................................11
6.5. Multiple Associations . . . . . . . . . . . . . . . . . . 12 6.5. Multiple Associations .....................................11
6.6. Session Modification . . . . . . . . . . . . . . . . . . . 12 6.6. Session Modification ......................................12
6.7. Middlebox Interaction . . . . . . . . . . . . . . . . . . 13 6.7. Middlebox Interaction .....................................12
6.7.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 13 6.7.1. ICE Interaction ....................................12
6.7.2. Latching Control Without ICE . . . . . . . . . . . . . 13 6.7.2. Latching Control without ICE .......................13
6.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.8. Rekeying ..................................................13
6.9. Conference Servers and Shared Encryptions Contexts . . . . 14 6.9. Conference Servers and Shared Encryptions Contexts ........13
6.10. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 14 6.10. Media over SRTP ..........................................14
6.11. Best Effort Encryption . . . . . . . . . . . . . . . . . . 15 6.11. Best Effort Encryption ...................................14
7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 15
7.1. Basic Message Flow with Early Media and Identity . . . . . 15 7. Example Message Flow ...........................................14
7.2. Basic Message Flow with Connected Identity (RFC 4916) . . 20 7.1. Basic Message Flow with Early Media and SIP Identity ......14
7.3. Basic Message Flow with STUN check for NAT Case . . . . . 24 7.2. Basic Message Flow with Connected Identity (RFC 4916) .....19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.3. Basic Message Flow with STUN Check for NAT Case ...........23
8.1. Responder Identity . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations ........................................25
8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Responder Identity ........................................25
8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. SIPS ......................................................26
8.4. Continuity of Authentication . . . . . . . . . . . . . . . 27 8.3. S/MIME ....................................................26
8.5. Short Authentication String . . . . . . . . . . . . . . . 28 8.4. Continuity of Authentication ..............................26
8.6. Limits of Identity Assertions . . . . . . . . . . . . . . 28 8.5. Short Authentication String ...............................27
8.7. Third Party Certificates . . . . . . . . . . . . . . . . . 30 8.6. Limits of Identity Assertions .............................27
8.8. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 30 8.7. Third-Party Certificates ..................................29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8.8. Perfect Forward Secrecy ...................................29
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgments ................................................29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References ....................................................30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References .....................................30
11.2. Informational References . . . . . . . . . . . . . . . . . 32 10.2. Informative References ...................................31
Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 34 Appendix A. Requirements Analysis ................................33
A.1. Forking and retargeting (R-FORK-RETARGET, A.1. Forking and Retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 34 R-BEST-SECURE, R-DISTINCT) ...............................33
A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 34 A.2. Distinct Cryptographic Contexts (R-DISTINCT) .............33
A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 34 A.3. Reusage of a Security Context (R-REUSE) ..................33
A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 34 A.4. Clipping (R-AVOID-CLIPPING) ..............................33
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 35 A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) .........33
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 35 A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) .......34
A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 35 A.7. (R-SIG-MEDIA, R-ACT-ACT) .................................34
A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 35 A.8. Binding to Identifiers (R-ID-BINDING) ....................34
A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 35 A.9. Perfect Forward Secrecy (R-PFS) ..........................34
A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 36 A.10. Algorithm Negotiation (R-COMPUTE) ........................35
A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 36 A.11. RTP Validity Check (R-RTP-VALID) .........................35
A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 36 A.12. Third-Party Certificates (R-CERTS, R-EXISTING) ...........35
A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 36 A.13. FIPS 140-2 (R-FIPS) ......................................35
A.14. Linkage between Keying Exchange and SIP Signaling A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 36 (R-ASSOC) ................................................35
A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 36 A.15. Denial-of-Service Vulnerability (R-DOS) ..................35
A.16. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 36 A.16. Crypto-Agility (R-AGILITY) ...............................35
A.17. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 37 A.17. Downgrading Protection (R-DOWNGRADE) .....................36
A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 37 A.18. Media Security Negotiation (R-NEGOTIATE) .................36
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 37 A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) ......36
A.20. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 37 A.20. Media Recording (R-RECORDING) ............................36
A.21. Interworking with Intermediaries (R-TRANSCODER) . . . . . 37 A.21. Interworking with Intermediaries (R-TRANSCODER) ..........36
A.22. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 37 A.22. PSTN Gateway Termination (R-PSTN) ........................36
A.23. R-ALLOW-RTP . . . . . . . . . . . . . . . . . . . . . . . 37 A.23. R-ALLOW-RTP ..............................................36
A.24. R-HERFP . . . . . . . . . . . . . . . . . . . . . . . . . 38 A.24. R-HERFP ..................................................37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] and the Session The Session Initiation Protocol (SIP) [RFC3261] and the Session
Description Protocol (SDP) [RFC4566] are used to set up multimedia Description Protocol (SDP) [RFC4566] are used to set up multimedia
sessions or calls. SDP is also used to set up TCP [RFC4145] and sessions or calls. SDP is also used to set up TCP [RFC4145] and
additionally TCP/TLS connections for usage with media sessions additionally TCP/TLS connections for usage with media sessions
[RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used [RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used
to transmit real time media on top of UDP and TCP [RFC4571]. to transmit real-time media on top of UDP and TCP [RFC4571].
Datagram TLS [RFC4347] was introduced to allow TLS functionality to Datagram TLS [RFC4347] was introduced to allow TLS functionality to
be applied to datagram transport protocols, such as UDP and DCCP. be applied to datagram transport protocols, such as UDP and DCCP.
This draft provide guidelines on how to establish SRTP [RFC3711] This document provides guidelines on how to establish SRTP [RFC3711]
security over UDP using an extension to DTLS (see security over UDP using an extension to DTLS (see [RFC5764]).
[I-D.ietf-avt-dtls-srtp]).
The goal of this work is to provide a key negotiation technique that The goal of this work is to provide a key negotiation technique that
allows encrypted communication between devices with no prior allows encrypted communication between devices with no prior
relationships. It also does not require the devices to trust every relationships. It also does not require the devices to trust every
call signaling element that was involved in routing or session setup. call signaling element that was involved in routing or session setup.
This approach does not require any extra effort by end users and does This approach does not require any extra effort by end users and does
not require deployment of certificates that are signed by a well- not require deployment of certificates that are signed by a well-
known certificate authority to all devices. known certificate authority to all devices.
The media is transported over a mutually authenticated DTLS session The media is transported over a mutually authenticated DTLS session
where both sides have certificates. It is very important to note where both sides have certificates. It is very important to note
that certificates are being used purely as a carrier for the public that certificates are being used purely as a carrier for the public
keys of the peers. This is required because DTLS does not have a keys of the peers. This is required because DTLS does not have a
mode for carrying bare keys, but it is purely an issue of formatting. mode for carrying bare keys, but it is purely an issue of formatting.
The certificates can be self-signed and completely self-generated. The certificates can be self-signed and completely self-generated.
All major TLS stacks have the capability to generate such All major TLS stacks have the capability to generate such
certificates on demand. However, third party certificates MAY also certificates on demand. However, third-party certificates MAY also
be used if the peers have them (thus reducing the need to trust be used if the peers have them (thus reducing the need to trust
intermediaries). The certificate fingerprints are sent in SDP over intermediaries). The certificate fingerprints are sent in SDP over
SIP as part of the offer/answer exchange. SIP as part of the offer/answer exchange.
The fingerprint mechanism allows one side of the connection to verify The fingerprint mechanism allows one side of the connection to verify
that the certificate presented in the DTLS handshake matches the that the certificate presented in the DTLS handshake matches the
certificate used by the party in the signalling. However, this certificate used by the party in the signaling. However, this
requires some form of integrity protection on the signalling. S/MIME requires some form of integrity protection on the signaling. S/MIME
signatures, as described in RFC 3261, or SIP Identity, as described signatures, as described in RFC 3261, or SIP Identity, as described
in [RFC4474] provides the highest level of security because they are in [RFC4474], provide the highest level of security because they are
not susceptible to modification by malicious intermediaries. not susceptible to modification by malicious intermediaries.
However, even hop-by-hop security such as provided by SIPS provides However, even hop-by-hop security, such as provided by SIPS, offers
some protection against modification by attackers who are not in some protection against modification by attackers who are not in
control of on-path sigaling elements. Because DTLS-SRTP only control of on-path signaling elements. Because DTLS-SRTP only
requires message integrity and not confidentiality for the signaling, requires message integrity and not confidentiality for the signaling,
the number of elements which must have credentials and be trusted is the number of elements that must have credentials and be trusted is
significantly reduced. In particular, if RFC 4474 is used, only the significantly reduced. In particular, if RFC 4474 is used, only the
Authentication Service need have a certificate and be trusted. Authentication Service need have a certificate and be trusted.
Intermediate elements cannot undetectably modify the message and Intermediate elements cannot undetectably modify the message and
therefore cannot mount a MITM attack. By comparison, because therefore cannot mount a man-in-the-middle (MITM) attack. By
SDESCRIPTIONS [RFC4568] requires confidentiality for the signaling, comparison, because SDESCRIPTIONS [RFC4568] requires confidentiality
all intermediate elements must be trusted. for the signaling, all intermediate elements must be trusted.
This approach differs from previous attempts to secure media traffic This approach differs from previous attempts to secure media traffic
where the authentication and key exchange protocol (e.g., MIKEY where the authentication and key exchange protocol (e.g., Multimedia
[RFC3830]) is piggybacked in the signaling message exchange. With Internet KEYing (MIKEY) [RFC3830]) is piggybacked in the signaling
DTLS-SRTP, establishing the protection of the media traffic between message exchange. With DTLS-SRTP, establishing the protection of the
the endpoints is done by the media endpoints with only a media traffic between the endpoints is done by the media endpoints
cryptographic binding of the media keying to the SIP/SDP with only a cryptographic binding of the media keying to the SIP/SDP
communication. It allows RTP and SIP to be used in the usual manner communication. It allows RTP and SIP to be used in the usual manner
when there is no encrypted media. when there is no encrypted media.
In SIP, typically the caller sends an offer and the callee may In SIP, typically the caller sends an offer and the callee may
subsequently send one-way media back to the caller before a SIP subsequently send one-way media back to the caller before a SIP
answer is received by the caller. The approach in this answer is received by the caller. The approach in this
specification, where the media key negotiation is decoupled from the specification, where the media key negotiation is decoupled from the
SIP signaling, allows the early media to be set up before the SIP SIP signaling, allows the early media to be set up before the SIP
answer is received while preserving the important security property answer is received while preserving the important security property
of allowing the media sender to choose some of the keying material of allowing the media sender to choose some of the keying material
for the media. This also allows the media sessions to be changed, for the media. This also allows the media sessions to be changed,
re-keyed, and otherwise modified after the initial SIP signaling rekeyed, and otherwise modified after the initial SIP signaling
without any additional SIP signaling. without any additional SIP signaling.
Design decisions that influence the applicability of this Design decisions that influence the applicability of this
specification are discussed in Section 3. specification are discussed in Section 3.
2. Overview 2. Overview
Endpoints wishing to set up an RTP media session do so by exchanging Endpoints wishing to set up an RTP media session do so by exchanging
offers and answers in SDP messages over SIP. In a typical use case, offers and answers in SDP messages over SIP. In a typical use case,
two endpoints would negotiate to transmit audio data over RTP using two endpoints would negotiate to transmit audio data over RTP using
the UDP protocol. the UDP protocol.
Figure 1 shows a typical message exchange in the SIP Trapezoid. Figure 1 shows a typical message exchange in the SIP trapezoid.
+-----------+ +-----------+ +-----------+ +-----------+
|SIP | SIP/SDP |SIP | |SIP | SIP/SDP |SIP |
+------>|Proxy |----------->|Proxy |-------+ +------>|Proxy |----------->|Proxy |-------+
| |Server X | (+finger- |Server Y | | | |Server X | (+finger- |Server Y | |
| +-----------+ print, +-----------+ | | +-----------+ print, +-----------+ |
| +auth.id.) | | +auth.id.) |
| SIP/SDP SIP/SDP | | SIP/SDP SIP/SDP |
| (+fingerprint) (+fingerprint,| | (+fingerprint) (+fingerprint,|
| +auth.id.) | | +auth.id.) |
skipping to change at page 7, line 29 skipping to change at page 6, line 29
|Alice@X | <=================================> |Bob@Y | |Alice@X | <=================================> |Bob@Y |
+-----------+ +-----------+ +-----------+ +-----------+
Legend: Legend:
------>: Signaling Traffic ------>: Signaling Traffic
<-+-+->: Key Management Traffic <-+-+->: Key Management Traffic
<=====>: Data Traffic <=====>: Data Traffic
Figure 1: DTLS Usage in the SIP Trapezoid Figure 1: DTLS Usage in the SIP Trapezoid
Consider Alice wanting to set up an encrypted audio session with Bob. Consider Alice wanting to set up an encrypted audio session with
Both Bob and Alice could use public-key based authentication in order Bob. Both Bob and Alice could use public-key-based authentication in
to establish a confidentiality protected channel using DTLS. order to establish a confidentiality protected channel using DTLS.
Since providing mutual authentication between two arbitrary end Since providing mutual authentication between two arbitrary endpoints
points on the Internet using public key based cryptography tends to on the Internet using public-key-based cryptography tends to be
be problematic, we consider more deployment-friendly alternatives. problematic, we consider more deployment-friendly alternatives. This
This document uses one approach and several others are discussed in document uses one approach and several others are discussed in
Section 8. Section 8.
Alice sends an SDP offer to Bob over SIP. If Alice uses only self- Alice sends an SDP offer to Bob over SIP. If Alice uses only self-
signed certificates for the communication with Bob, a fingerprint is signed certificates for the communication with Bob, a fingerprint is
included in the SDP offer/answer exchange. This fingerprint binds included in the SDP offer/answer exchange. This fingerprint binds
the DTLS key exchange in the media plane to the signaling plane. the DTLS key exchange in the media plane to the signaling plane.
The fingerprint alone protects against active attacks on the media The fingerprint alone protects against active attacks on the media
but not active attacks on the signalling. In order to prevent active but not active attacks on the signaling. In order to prevent active
attacks on the signalling, Enhancements for Authenticated Identity attacks on the signaling, "Enhancements for Authenticated Identity
Management in SIP [RFC4474] may be is used. When Bob receives the Management in the Session Initiation Protocol (SIP)" [RFC4474] may be
offer, the peers establish some number of DTLS connections (depending used. When Bob receives the offer, the peers establish some number
on the number of media sessions) with mutual DTLS authentication of DTLS connections (depending on the number of media sessions) with
(i.e., both sides provide certificates) At this point, Bob can verify mutual DTLS authentication (i.e., both sides provide certificates).
that Alice's credentials offered in TLS match the fingerprint in the At this point, Bob can verify that Alice's credentials offered in TLS
SDP offer, and Bob can begin sending media to Alice. Once Bob match the fingerprint in the SDP offer, and Bob can begin sending
accepts Alice's offer and sends an SDP answer to Alice, Alice can media to Alice. Once Bob accepts Alice's offer and sends an SDP
begin sending confidential media to Bob over the appropriate streams. answer to Alice, Alice can begin sending confidential media to Bob
Alice and Bob will verify that the fingerprints from the certificates over the appropriate streams. Alice and Bob will verify that the
received over the DTLS handshakes match with the fingerprints fingerprints from the certificates received over the DTLS handshakes
received in the SDP of the SIP signaling. This provides the security match with the fingerprints received in the SDP of the SIP signaling.
property that Alice knows that the media traffic is going to Bob and This provides the security property that Alice knows that the media
vice-versa without necessarily requiring global PKI certificates for traffic is going to Bob and vice versa without necessarily requiring
Alice and Bob. (see Section 8 for detailed security analysis.) global Public Key Infrastructure (PKI) certificates for Alice and
Bob. (See Section 8 for detailed security analysis.)
3. Motivation 3. Motivation
Although there is already prior work in this area (e.g., Security Although there is already prior work in this area (e.g., Security
Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567]
combined with MIKEY [RFC3830] for authentication and key exchange), combined with MIKEY [RFC3830] for authentication and key exchange),
this specification is motivated as follows: this specification is motivated as follows:
o TLS will be used to offer security for connection-oriented media. o TLS will be used to offer security for connection-oriented media.
The design of TLS is well-known and implementations are widely The design of TLS is well-known and implementations are widely
skipping to change at page 8, line 23 skipping to change at page 7, line 24
3. Motivation 3. Motivation
Although there is already prior work in this area (e.g., Security Although there is already prior work in this area (e.g., Security
Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567]
combined with MIKEY [RFC3830] for authentication and key exchange), combined with MIKEY [RFC3830] for authentication and key exchange),
this specification is motivated as follows: this specification is motivated as follows:
o TLS will be used to offer security for connection-oriented media. o TLS will be used to offer security for connection-oriented media.
The design of TLS is well-known and implementations are widely The design of TLS is well-known and implementations are widely
available. available.
o This approach deals with forking and early media without requiring o This approach deals with forking and early media without requiring
support for PRACK [RFC3262] while preserving the important support for Provisional Response ACKnowledgement (PRACK) [RFC3262]
security property of allowing the offerer to choose keying while preserving the important security property of allowing the
material for encrypting the media. offerer to choose keying material for encrypting the media.
o The establishment of security protection for the media path is o The establishment of security protection for the media path is
also provided along the media path and not over the signaling also provided along the media path and not over the signaling
path. In many deployment scenarios, the signaling and media path. In many deployment scenarios, the signaling and media
traffic travel along a different path through the network. traffic travel along a different path through the network.
o When RFC 4474 Identity is used, this solution works even when the
SIP proxies downstream of the authentication service are not o When RFC 4474 is used, this solution works even when the SIP
trusted. There is no need to reveal keys in the SIP signaling or proxies downstream of the authentication service are not trusted.
in the SDP message exchange, as is done in SDESCRIPTIONS There is no need to reveal keys in the SIP signaling or in the SDP
[RFC4568]. Retargeting of a dialog-forming request (changing the message exchange, as is done in SDESCRIPTIONS [RFC4568].
value of the Request-URI), the UA that receives it (the User Agent Retargeting of a dialog-forming request (changing the value of the
Request-URI), the User Agent (UA) that receives it (the User Agent
Server, UAS) can have a different identity from that in the To Server, UAS) can have a different identity from that in the To
header field. When RFC 4916 is used then it is possible to supply header field. When RFC 4916 is used, then it is possible to
its identity to the peer UA by means of a request in the reverse supply its identity to the peer UA by means of a request in the
direction, and for that identity to be signed by an Authentication reverse direction, and for that identity to be signed by an
Service. Authentication Service.
o In this method, SSRC collisions do not result in any extra SIP
signaling. o In this method, synchronization source (SSRC) collisions do not
result in any extra SIP signaling.
o Many SIP endpoints already implement TLS. The changes to existing o Many SIP endpoints already implement TLS. The changes to existing
SIP and RTP usage are minimal even when DTLS-SRTP SIP and RTP usage are minimal even when DTLS-SRTP [RFC5764] is
[I-D.ietf-avt-dtls-srtp] is used. used.
4. Terminology 4. 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].
DTLS/TLS uses the term "session" to refer to a long-lived set of DTLS/TLS uses the term "session" to refer to a long-lived set of
keying material that spans associations. In this document, keying material that spans associations. In this document,
consistent with SIP/SDP usage, we use it to refer to a multimedia consistent with SIP/SDP usage, we use it to refer to a multimedia
session and use the term "TLS session" to refer to the TLS construct. session and use the term "TLS session" to refer to the TLS construct.
We use the term "association" to refer to a particular DTLS We use the term "association" to refer to a particular DTLS cipher
ciphersuite and keying material set which is associated with a single suite and keying material set that is associated with a single host/
host/port quartet. The same DTLS/TLS session can be used to port quartet. The same DTLS/TLS session can be used to establish the
establish the keying material for multiple associations. For keying material for multiple associations. For consistency with
consistency with other SIP/SDP usage, we use the term "connection" other SIP/SDP usage, we use the term "connection" when what's being
when what's being referred to is a multimedia stream that is not referred to is a multimedia stream that is not specifically DTLS/TLS.
specifically DTLS/TLS.
In this document, the term "Mutual DTLS" indicates that both the DTLS In this document, the term "Mutual DTLS" indicates that both the DTLS
client and server present certificates even if one or both client and server present certificates even if one or both
certificates are self-signed. certificates are self-signed.
5. Establishing a Secure Channel 5. Establishing a Secure Channel
The two endpoints in the exchange present their identities as part of The two endpoints in the exchange present their identities as part of
the DTLS handshake procedure using certificates. This document uses the DTLS handshake procedure using certificates. This document uses
certificates in the same style as described in Comedia over TLS in certificates in the same style as described in "Connection-Oriented
SDP [RFC4572]. Media Transport over the Transport Layer Security (TLS) Protocol in
the Session Description Protocol (SDP)" [RFC4572].
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. This is useful for debugging resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is the communication endpoints. The integrity of the certificate is
ensured through the fingerprint attribute in the SDP. The ensured through the fingerprint attribute in the SDP. The
subjectAltName is not an important component of the certificate subjectAltName is not an important component of the certificate
verification. verification.
The generation of public/private key pairs is relatively expensive. The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session. Endpoints are not required to generate certificates for each session.
The offer/answer model, defined in [RFC3264], is used by protocols The offer/answer model, defined in [RFC3264], is used by protocols
like the Session Initiation Protocol (SIP) [RFC3261] to set up like the Session Initiation Protocol (SIP) [RFC3261] to set up
multimedia sessions. In addition to the usual contents of an SDP multimedia sessions. In addition to the usual contents of an SDP
[RFC4566] message, each media description ('m' line and associated
[RFC4566] message, each media description ("m=" line and associated
parameters) will also contain several attributes as specified in parameters) will also contain several attributes as specified in
[I-D.ietf-avt-dtls-srtp], [RFC4145] and [RFC4572]. [RFC5764], [RFC4145], and [RFC4572].
When an endpoint wishes to set up a secure media session with another When an endpoint wishes to set up a secure media session with another
endpoint it sends an offer in a SIP message to the other endpoint. endpoint, it sends an offer in a SIP message to the other endpoint.
This offer includes, as part of the SDP payload, the fingerprint of This offer includes, as part of the SDP payload, the fingerprint of
the certificate that the endpoint wants to use. The endpoint SHOULD the certificate that the endpoint wants to use. The endpoint SHOULD
send the SIP message containing the offer to the offerer's sip proxy send the SIP message containing the offer to the offerer's SIP proxy
over an integrity protected channel. The proxy SHOULD add an over an integrity protected channel. The proxy SHOULD add an
Identity header field according to the procedures outlined in Identity header field according to the procedures outlined in
[RFC4474]. The SIP message containing the offer SHOULD be sent to [RFC4474]. The SIP message containing the offer SHOULD be sent to
the offerer's sip proxy over an integrity protected channel. When the offerer's SIP proxy over an integrity protected channel. When
the far endpoint receives the SIP message it can verify the identity the far endpoint receives the SIP message, it can verify the identity
of the sender using the Identity header field. Since the Identity of the sender using the Identity header field. Since the Identity
header field is a digital signature across several SIP header fields, header field is a digital signature across several SIP header fields,
in addition to the body of the SIP message, the receiver can also be in addition to the body of the SIP message, the receiver can also be
certain that the message has not been tampered with after the digital certain that the message has not been tampered with after the digital
signature was applied and added to the SIP message. signature was applied and added to the SIP message.
The far endpoint (answerer) may now establish a DTLS association with The far endpoint (answerer) may now establish a DTLS association with
DTLS to the offerer. Alternately, it can indicate in its answer that the offerer. Alternately, it can indicate in its answer that the
the offerer is to initiate the TLS association. In either case, offerer is to initiate the TLS association. In either case, mutual
mutual DTLS certificate-based authentication will be used. After DTLS certificate-based authentication will be used. After completing
completing the DTLS handshake, information about the authenticated the DTLS handshake, information about the authenticated identities,
identities, including the certificates, are made available to the including the certificates, are made available to the endpoint
endpoint application. The answerer is then able to verify that the application. The answerer is then able to verify that the offerer's
offerer's certificate used for authentication in the DTLS handshake certificate used for authentication in the DTLS handshake can be
can be associated to the certificate fingerprint contained in the associated to the certificate fingerprint contained in the offer in
offer in the SDP. At this point the answerer may indicate to the end the SDP. At this point, the answerer may indicate to the end user
user that the media is secured. The offerer may only tentatively that the media is secured. The offerer may only tentatively accept
accept the answerer's certificate since it may not yet have the the answerer's certificate since it may not yet have the answerer's
answerer's certificate fingerprint. certificate fingerprint.
When the answerer accepts the offer, it provides an answer back to When the answerer accepts the offer, it provides an answer back to
the offerer containing the answerer's certificate fingerprint. At the offerer containing the answerer's certificate fingerprint. At
this point the offerer can accept or reject the peer's certificate this point, the offerer can accept or reject the peer's certificate
and the offerer can indicate to the end user that the media is and the offerer can indicate to the end user that the media is
secured. secured.
Note that the entire authentication and key exchange for securing the Note that the entire authentication and key exchange for securing the
media traffic is handled in the media path through DTLS. The media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate signaling path is only used to verify the peers' certificate
fingerprints. fingerprints.
The offer and answer MUST be conform to the following requirements. The offer and answer MUST conform to the following requirements.
o The endpoint MUST use the setup attribute defined in [RFC4145]. o The endpoint MUST use the setup attribute defined in [RFC4145].
The endpoint which is the offerer MUST use the setup attribute The endpoint that is the offerer MUST use the setup attribute
value of setup:actpass and be prepared to receive a client_hello value of setup:actpass and be prepared to receive a client_hello
before it receives the answer. The answerer MUST use either a before it receives the answer. The answerer MUST use either a
setup attribute value of setup:active or setup:passive. Note that setup attribute value of setup:active or setup:passive. Note that
if the answerer uses setup:passive, then the DTLS handshake will if the answerer uses setup:passive, then the DTLS handshake will
not begin until the answerer is received, which adds additional not begin until the answerer is received, which adds additional
latency. setup:active allows the answer and the DTLS handshake to latency. setup:active allows the answer and the DTLS handshake to
occur in parallel. Thus, setup:active is RECOMMENDED. Whichever occur in parallel. Thus, setup:active is RECOMMENDED. Whichever
party is active MUST initiate a DTLS handshake by sending a party is active MUST initiate a DTLS handshake by sending a
ClientHello over each flow (host/port quartet). ClientHello over each flow (host/port quartet).
o The endpoint MUST NOT use the connection attribute defined in o The endpoint MUST NOT use the connection attribute defined in
[RFC4145]. [RFC4145].
o The endpoint MUST use the certificate fingerprint attribute as o The endpoint MUST use the certificate fingerprint attribute as
specified in [RFC4572]. specified in [RFC4572].
o The certificate presented during the DTLS handshake MUST match the o The certificate presented during the DTLS handshake MUST match the
fingerprint exchanged via the signaling path in the SDP. The fingerprint exchanged via the signaling path in the SDP. The
security properties of this mechanism are described in Section 8. security properties of this mechanism are described in Section 8.
o If the fingerprint does not match the hashed certificate then the
o If the fingerprint does not match the hashed certificate, then the
endpoint MUST tear down the media session immediately. Note that endpoint MUST tear down the media session immediately. Note that
it is permissible to wait until the other side's fingerprint has it is permissible to wait until the other side's fingerprint has
been received before establishing the connection, however this may been received before establishing the connection; however, this
have undesirable latency effects. may have undesirable latency effects.
6. Miscellaneous Considerations 6. Miscellaneous Considerations
6.1. Anonymous Calls 6.1. Anonymous Calls
The use of DTLS-SRTP does not provide anonymous calling, however it The use of DTLS-SRTP does not provide anonymous calling; however, it
also does not prevent it. However, if care is not taken when also does not prevent it. However, if care is not taken when
anonymous calling features such as those described in [RFC3325] or anonymous calling features, such as those described in [RFC3325] or
[I-D.ietf-sip-ua-privacy] are used DTLS-SRTP may allow deanonymizing [RFC5767] are used, DTLS-SRTP may allow deanonymizing an otherwise
an otherwise anonymous call. When anonymous calls are being made, anonymous call. When anonymous calls are being made, the following
the following procedures SHOULD be used to prevent deanonymization. procedures SHOULD be used to prevent deanonymization.
When making anonymous calls, a new self-signed certificate SHOULD be When making anonymous calls, a new self-signed certificate SHOULD be
used for each call so that the calls can not be correlated as to used for each call so that the calls cannot be correlated as to being
being from the same caller. In situations where some degree of from the same caller. In situations where some degree of correlation
correlation is acceptable, the same certificate SHOULD be used for a is acceptable, the same certificate SHOULD be used for a number of
number of calls in order to enable continuity of authentication, see calls in order to enable continuity of authentication; see
Section 8.4. Section 8.4.
Additionally note that in networks that deploy [RFC3325], RFC 3325 Additionally, note that in networks that deploy [RFC3325], RFC 3325
requires that the Privacy header field value defined in [RFC3323] requires that the Privacy header field value defined in [RFC3323]
needs to be set to 'id'. This is used in conjunction with the SIP needs to be set to 'id'. This is used in conjunction with the SIP
identity mechanism to ensure that the identity of the user is not identity mechanism to ensure that the identity of the user is not
asserted when enabling anonymous calls. Furthermore, the content of asserted when enabling anonymous calls. Furthermore, the content of
the subjectAltName attribute inside the certificate MUST NOT contain the subjectAltName attribute inside the certificate MUST NOT contain
information that either allows correlation or identification of the information that either allows correlation or identification of the
user that wishes to place an anonymous call. Note that following user that wishes to place an anonymous call. Note that following
this recommendation is not sufficient to provide anonymization. this recommendation is not sufficient to provide anonymization.
6.2. Early Media 6.2. Early Media
skipping to change at page 12, line 19 skipping to change at page 11, line 29
establish a DTLS association with the other endpoint and begin establish a DTLS association with the other endpoint and begin
sending media. The setup:passive endpoint may not yet have validated sending media. The setup:passive endpoint may not yet have validated
the fingerprint of the active endpoint's certificate. The security the fingerprint of the active endpoint's certificate. The security
aspects of media handling in this situation are discussed in aspects of media handling in this situation are discussed in
Section 8. Section 8.
6.3. Forking 6.3. Forking
In SIP, it is possible for a request to fork to multiple endpoints. In SIP, it is possible for a request to fork to multiple endpoints.
Each forked request can result in a different answer. Assuming that Each forked request can result in a different answer. Assuming that
the requester provided an offer, each of the answerers' will provide the requester provided an offer, each of the answerers will provide a
a unique answer. Each answerer will form a DTLS association with the unique answer. Each answerer will form a DTLS association with the
offerer. The offerer can then securely correlate the SDP answer offerer. The offerer can then securely correlate the SDP answer
received in the SIP message by comparing the fingerprint in the received in the SIP message by comparing the fingerprint in the
answer to the hashed certificate for each DTLS association. answer to the hashed certificate for each DTLS association.
6.4. Delayed Offer Calls 6.4. Delayed Offer Calls
An endpoint may send a SIP INVITE request with no offer in it. When An endpoint may send a SIP INVITE request with no offer in it. When
this occurs, the receiver(s) of the INVITE will provide the offer in this occurs, the receiver(s) of the INVITE will provide the offer in
the response and the originator will provide the answer in the the response and the originator will provide the answer in the
subsequent ACK request or in the PRACK request [RFC3262] if both subsequent ACK request or in the PRACK request [RFC3262], if both
endpoints support reliable provisional responses. In any event, the endpoints support reliable provisional responses. In any event, the
active endpoint still establishes the DTLS association with the active endpoint still establishes the DTLS association with the
passive endpoint as negotiated in the offer/answer exchange. passive endpoint as negotiated in the offer/answer exchange.
6.5. Multiple Associations 6.5. Multiple Associations
When there are multiple flows (e.g., multiple media streams, non- When there are multiple flows (e.g., multiple media streams, non-
multiplexed RTP and RTCP, etc.) the active side MAY perform the DTLS multiplexed RTP and RTCP, etc.) the active side MAY perform the DTLS
handshakes in any order. Appendix B of [I-D.ietf-avt-dtls-srtp] handshakes in any order. Appendix B of [RFC5764] provides some
provides some guidance on the performance of parallel DTLS guidance on the performance of parallel DTLS handshakes. Note that
handshakes. Note that if the answerer ends up being active, it may if the answerer ends up being active, it may only initiate handshakes
only initiate handshakes on some subset of the potential streams on some subset of the potential streams (e.g., if audio and video are
(e.g., if audio and video are offered but it only wishes to do offered but it only wishes to do audio). If the offerer ends up
audio.) If the offerer ands up being active, the complete answer being active, the complete answer will be received before the offerer
will be received before the offerer begins initiating handshakes. begins initiating handshakes.
6.6. Session Modification 6.6. Session Modification
Once an answer is provided to the offerer, either endpoint MAY Once an answer is provided to the offerer, either endpoint MAY
request a session modification which MAY include an updated offer. request a session modification that MAY include an updated offer.
This session modification can be carried in either an INVITE or This session modification can be carried in either an INVITE or
UPDATE request. The peers can reuse the the existing associations if UPDATE request. The peers can reuse the existing associations if
they are compatible (i.e., they have the same key fingerprints and they are compatible (i.e., they have the same key fingerprints and
transport parameters), or establish a new one following the same transport parameters), or establish a new one following the same
rules are for initial exchanges, tearing down the existing rules are for initial exchanges, tearing down the existing
association as soon as the offer/answer exchange is completed. Note association as soon as the offer/answer exchange is completed. Note
that if the active/passive status of the endpoints changes, a new that if the active/passive status of the endpoints changes, a new
connection MUST be established. connection MUST be established.
6.7. Middlebox Interaction 6.7. Middlebox Interaction
There are a number of potentially bad interactions between DTLS-SRTP There are a number of potentially bad interactions between DTLS-SRTP
and middleboxes, as documented in and middleboxes, as documented in [MMUSIC-MEDIA], which also provides
[I-D.ietf-mmusic-media-path-middleboxes], which also provides
recommendations for avoiding such problems. recommendations for avoiding such problems.
6.7.1. ICE Interaction 6.7.1. ICE Interaction
Interactive Connectivity Establishment (ICE), as specified in Interactive Connectivity Establishment (ICE), as specified in
[I-D.ietf-mmusic-ice], provides a methodology of allowing [RFC5245], provides a methodology of allowing participants in
participants in multi-media sessions to verify mutual connectivity. multimedia sessions to verify mutual connectivity. When ICE is being
When ICE is being used the ICE connectivity checks are performed used, the ICE connectivity checks are performed before the DTLS
before the DTLS handshake begins. Note that if aggressive nomination handshake begins. Note that if aggressive nomination mode is used,
mode is used, multiple candidate pairs may be marked valid before ICE multiple candidate pairs may be marked valid before ICE finally
finally converges on a single candidate pair. Implementations MUST converges on a single candidate pair. Implementations MUST treat all
treat all ICE candidate pairs associated with a single component as ICE candidate pairs associated with a single component as part of the
part of the same DTLS association. Thus, there will be only one DTLS same DTLS association. Thus, there will be only one DTLS handshake
handshake even if there are multiple valid candidate pairs. Note even if there are multiple valid candidate pairs. Note that this may
that this may mean adjusting the endpoint IP addresses if the mean adjusting the endpoint IP addresses if the selected candidate
selected candidate pair shifts, just as if the DTLS packets were an pair shifts, just as if the DTLS packets were an ordinary media
ordinary media stream. stream.
Note that STUN packets are sent directly over UDP, not over DTLS. Note that Simple Traversal of the UDP Protocol through NAT (STUN)
[I-D.ietf-avt-dtls-srtp] describes how to demultiplex STUN packets packets are sent directly over UDP, not over DTLS. [RFC5764]
from DTLS packets and SRTP packets. describes how to demultiplex STUN packets from DTLS packets and SRTP
packets.
6.7.2. Latching Control Without ICE 6.7.2. Latching Control without ICE
If ICE is not being used, then there is potential for a bad If ICE is not being used, then there is potential for a bad
interaction with SBCs via "latching", as described in interaction with Session Border Controllers (SBCs) via "latching", as
[I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this described in [MMUSIC-MEDIA]. In order to avoid this issue, if ICE is
issue, if ICE is not being used and the DTLS handshake has not not being used and the DTLS handshake has not completed upon
completed, upon receiving the other side's SDP then the passive side receiving the other side's SDP, then the passive side MUST do a
MUST do a single unauthenticated STUN [RFC5389] connectivity check in single unauthenticated STUN [RFC5389] connectivity check in order to
order to open up the appropriate pinhole. All implementations MUST open up the appropriate pinhole. All implementations MUST be
be prepared to answer this request during the handshake period even prepared to answer this request during the handshake period even if
if they do not otherwise do ICE. However, the active side MUST they do not otherwise do ICE. However, the active side MUST proceed
proceed with the DTLS handshake as appopriate even if no such STUN with the DTLS handshake as appropriate even if no such STUN check is
check is received and the passive MUST NOT wait for a STUN answer received and the passive MUST NOT wait for a STUN answer before
before sending its ServerHello. sending its ServerHello.
6.8. Rekeying 6.8. Rekeying
As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS
handshake. While the rekey is under way, the endpoints continue to handshake. While the rekey is under way, the endpoints continue to
use the previously established keying material for usage with DTLS. use the previously established keying material for usage with DTLS.
Once the new session keys are established the session can switch to Once the new session keys are established, the session can switch to
using these and abandon the old keys. This ensures that latency is using these and abandon the old keys. This ensures that latency is
not introduced during the rekeying process. not introduced during the rekeying process.
Further considerations regarding rekeying in case the SRTP security Further considerations regarding rekeying in case the SRTP security
context is established with DTLS can be found in Section 3.7 of context is established with DTLS can be found in Section 3.7 of
[I-D.ietf-avt-dtls-srtp]. [RFC5764].
6.9. Conference Servers and Shared Encryptions Contexts 6.9. Conference Servers and Shared Encryptions Contexts
It has been proposed that conference servers might use the same It has been proposed that conference servers might use the same
encryption context for all of the participants in a conference. The encryption context for all of the participants in a conference. The
advantage of this approach is that the conference server only needs advantage of this approach is that the conference server only needs
to encrypt the output for all speakers instead of once per to encrypt the output for all speakers instead of once per
participant. participant.
This shared encryption context approach is not possible under this This shared encryption context approach is not possible under this
specification because each DTLS handshake establishes fresh keys specification because each DTLS handshake establishes fresh keys that
which are not completely under the control of either side. However, are not completely under the control of either side. However, it is
it is argued that the effort to encrypt each RTP packet is small argued that the effort to encrypt each RTP packet is small compared
compared to the other tasks performed by the conference server such to the other tasks performed by the conference server such as the
as the codec processing. codec processing.
Future extensions such as [I-D.mcgrew-srtp-ekt] or Future extensions, such as [SRTP-EKT] or [KEY-TRANSPORT], could be
[I-D.wing-avt-dtls-srtp-key-transport] could be used to provide this used to provide this functionality in concert with the mechanisms
functionality in concert with the mechanisms described in this described in this specification.
specification.
6.10. Media over SRTP 6.10. Media over SRTP
Because DTLS's data transfer protocol is generic, it is less highly Because DTLS's data transfer protocol is generic, it is less highly
optimized for use with RTP than is SRTP [RFC3711], which has been optimized for use with RTP than is SRTP [RFC3711], which has been
specifically tuned for that purpose. DTLS-SRTP specifically tuned for that purpose. DTLS-SRTP [RFC5764] has been
[I-D.ietf-avt-dtls-srtp], has been defined to provide for the defined to provide for the negotiation of SRTP transport using a DTLS
negotiation of SRTP transport using a DTLS connection, thus allowing connection, thus allowing the performance benefits of SRTP with the
the performance benefits of SRTP with the easy key management of easy key management of DTLS. The ability to reuse existing SRTP
DTLS. The ability to reuse existing SRTP software and hardware software and hardware implementations may in some environments
implementations may in some environments provide another important provide another important motivation for using DTLS-SRTP instead of
motivation for using DTLS-SRTP instead of RTP over DTLS. RTP over DTLS. Implementations of this specification MUST support
Implementations of this specification MUST support DTLS-SRTP DTLS-SRTP [RFC5764].
[I-D.ietf-avt-dtls-srtp].
6.11. Best Effort Encryption 6.11. Best Effort Encryption
[I-D.ietf-sip-media-security-requirements] describes a requirement [RFC5479] describes a requirement for best-effort encryption where
for best effort encryption where SRTP is used where both endpoints SRTP is used and where both endpoints support it and key negotiation
support it and key negotiation succeeds, otherwise RTP is used. succeeds, otherwise RTP is used.
[I-D.ietf-mmusic-sdp-capability-negotiation] describes a mechanism [MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP
which can signal both RTP and SRTP as an alternative. This allows an as an alternative. This allows an offerer to express a preference
offerer to express a preference for SRTP, but RTP is the default and for SRTP, but RTP is the default and will be understood by endpoints
will be understood by endpoints that do not understand SRTP or this that do not understand SRTP or this key exchange mechanism.
key exchange mechanism. Implementations of this document MUST Implementations of this document MUST support [MMUSIC-SDP].
support [I-D.ietf-mmusic-sdp-capability-negotiation].
7. Example Message Flow 7. Example Message Flow
Prior to establishing the session, both Alice and Bob generate self- Prior to establishing the session, both Alice and Bob generate self-
signed certificates which are used for a single session or, more signed certificates that are used for a single session or, more
likely, reused for multiple sessions. In this example, Alice calls likely, reused for multiple sessions. In this example, Alice calls
Bob. In this example we assume that Alice and Bob share the same Bob. In this example, we assume that Alice and Bob share the same
proxy. proxy.
7.1. Basic Message Flow with Early Media and Identity 7.1. Basic Message Flow with Early Media and SIP Identity
This example shows the SIP message flows where Alice acts as the This example shows the SIP message flows where Alice acts as the
passive endpoint and Bob acts as the active endpoint meaning that as passive endpoint and Bob acts as the active endpoint; meaning that as
soon as Bob receives the INVITE from Alice, with DTLS specified in soon as Bob receives the INVITE from Alice, with DTLS specified in
the 'm' line of the offer, Bob will begin to negotiate a DTLS the "m=" line of the offer, Bob will begin to negotiate a DTLS
association with Alice for both RTP and RTCP streams. Early media association with Alice for both RTP and RTCP streams. Early media
(RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends (RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends
the DTLS finished message to Alice. Bi-directional media (RTP and the DTLS finished message to Alice. Bi-directional media (RTP and
RTCP) can flow after Alice receives the SIP 200 response and once RTCP) can flow after Alice receives the SIP 200 response and once
Alice has sent the DTLS finished message. Alice has sent the DTLS finished message.
The SIP signaling from Alice to her proxy is transported over TLS to The SIP signaling from Alice to her proxy is transported over TLS to
ensure an integrity protected channel between Alice and her identity ensure an integrity protected channel between Alice and her identity
service. Transport between proxies should also be protected somehow, service. Transport between proxies should also be protected somehow,
especially if Identity is not in use. especially if SIP Identity is not in use.
Alice Proxies Bob Alice Proxies Bob
|(1) INVITE | | |(1) INVITE | |
|---------------->| | |---------------->| |
| |(2) INVITE | | |(2) INVITE |
| |----------------->| | |----------------->|
| |(3) hello | | |(3) hello |
|<-----------------------------------| |<-----------------------------------|
|(4) hello | | |(4) hello | |
|----------------------------------->| |----------------------------------->|
skipping to change at page 16, line 33 skipping to change at page 15, line 38
|<----------------| | |<----------------| |
| |(10) media | | |(10) media |
|<---------------------------------->| |<---------------------------------->|
|(11) ACK | | |(11) ACK | |
|----------------------------------->| |----------------------------------->|
Message (1): INVITE Alice -> Proxy Message (1): INVITE Alice -> Proxy
This shows the initial INVITE from Alice to Bob carried over the This shows the initial INVITE from Alice to Bob carried over the
TLS transport protocol to ensure an integrity protected channel TLS transport protocol to ensure an integrity protected channel
between Alice and her proxy which acts as Alice's identity between Alice and her proxy that acts as Alice's identity service.
service. Alice has requested to be either the active or passive Alice has requested to be either the active or passive endpoint by
endpoint by specifying a=setup:actpass in the SDP. Bob chooses to specifying a=setup:actpass in the SDP. Bob chooses to act as the
act as the DTLS client and will initiate the session. Also note DTLS client and will initiate the session. Also note that there
that there is a fingerprint attribute in the SDP. This is is a fingerprint attribute in the SDP. This is computed from
computed from Alice's self-signed certificate. This offer Alice's self-signed certificate.
includes a default m-line offering RTP in case the answerer does
not support SRTP. However, the potential configuration utilizing This offer includes a default "m=" line offering RTP in case the
a transport of SRTP is preferred. See answerer does not support SRTP. However, the potential
[I-D.ietf-mmusic-sdp-capability-negotiation] for more details on configuration utilizing a transport of SRTP is preferred. See
the details of SDP capability negotiation. [MMUSIC-SDP] for more details on the details of SDP capability
negotiation.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com> To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 18, line 40 skipping to change at page 17, line 40
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
m=audio 6056 RTP/AVP 0 m=audio 6056 RTP/AVP 0
a=sendrecv a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1 a=pcfg:1 t=1
Message (3): ClientHello Bob -> Alice Message (3): ClientHello Bob -> Alice
Assuming that Alice's identity is valid, Line 3 shows Bob sending Assuming that Alice's identity is valid, Line 3 shows Bob sending
a DTLS ClientHello(s) directly to Alice. In this case two DTLS a DTLS ClientHello(s) directly to Alice. In this case, two DTLS
ClientHello messages would be sent to Alice: one to ClientHello messages would be sent to Alice: one to
ua1.example.com:6056 for RTP and another to port 6057 for RTCP, ua1.example.com:6056 for RTP and another to port 6057 for RTCP,
but only one arrow is drawn for compactness of the figure. but only one arrow is drawn for compactness of the figure.
Message (4): ServerHello+Certificate Alice -> Bob Message (4): ServerHello+Certificate Alice -> Bob
Alice sends back a ServerHello, Certificate, ServerHelloDone for Alice sends back a ServerHello, Certificate, and ServerHelloDone
both RTP and RTCP associations. Note that the same certificate is for both RTP and RTCP associations. Note that the same
used for both the RTP and RTCP associations. If RTP/RTCP certificate is used for both the RTP and RTCP associations. If
multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only RTP/RTCP multiplexing [RFC5761] were being used only a single
a single association would be required. association would be required.
Message (5): Certificate Bob -> Alice Message (5): Certificate Bob -> Alice
Bob sends a Certificate, ClientKeyExchange, CertificateVerify, Bob sends a Certificate, ClientKeyExchange, CertificateVerify,
change_cipher_spec and Finished for both RTP and RTCP change_cipher_spec, and Finished for both RTP and RTCP
associations. Again note that Bob uses the same server associations. Again note that Bob uses the same server
certificate for both associations. certificate for both associations.
Message (6): Early Media Bob -> Alice Message (6): Early Media Bob -> Alice
At this point, Bob can begin sending early media (RTP and RTCP) to At this point, Bob can begin sending early media (RTP and RTCP) to
Alice. Note that Alice can't yet trust the media since the Alice. Note that Alice can't yet trust the media since the
fingerprint has not yet been received. This lack of trusted, fingerprint has not yet been received. This lack of trusted,
secure media is indicated to Alice via the UA user interface. secure media is indicated to Alice via the UA user interface.
Message (7): Finished Alice -> Bob Message (7): Finished Alice -> Bob
After Message 7 is received by Bob, Alice sends change_cipher_spec After Message 7 is received by Bob, Alice sends change_cipher_spec
and Finished. and Finished.
Message (8): 200 OK Bob -> Alice Message (8): 200 OK Bob -> Alice
When Bob answers the call, Bob sends a 200 OK SIP message which When Bob answers the call, Bob sends a 200 OK SIP message that
contains the fingerprint for Bob's certificate. Bob signals the contains the fingerprint for Bob's certificate. Bob signals the
actual transport protocol configuration of SRTP over DTLS in the actual transport protocol configuration of SRTP over DTLS in the
acfg parameter. acfg parameter.
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816 To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr> Record-Route: <sip:proxy.example.com;lr>
skipping to change at page 21, line 36 skipping to change at page 20, line 36
|(11) UPDATE | | |(11) UPDATE | |
|<----------------| | |<----------------| |
|(12) 200 OK | | |(12) 200 OK | |
|---------------->| | |---------------->| |
| |(13) 200 OK | | |(13) 200 OK |
| |----------------->| | |----------------->|
| |(14) media | | |(14) media |
|<---------------------------------->| |<---------------------------------->|
The first 9 messages of this example are the same as before. The first 9 messages of this example are the same as before.
However, messages 10-13, performing the RFC 4916 UPDATE, are new. However, Messages 10-13, performing the RFC 4916 UPDATE, are new.
Message (10): UPDATE Bob -> Proxy Message (10): UPDATE Bob -> Proxy
Bob sends an RFC 4916 UPDATE towards Alice. This update contains Bob sends an RFC 4916 UPDATE towards Alice. This update contains
his fingerprint. Bob's UPDATE contains the same session his fingerprint. Bob's UPDATE contains the same session
information that he provided in his 200 OK (message (8)). Note information that he provided in his 200 OK (Message 8). Note that
that in principle an UPDATE here can be used to modify session in principle an UPDATE here can be used to modify session
parameters. However, in this case it's being used solely to parameters. However, in this case it's being used solely to
confirm the fingerprint. confirm the fingerprint.
UPDATE sip:alice@ua1.example.com SIP/2.0 UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816 From <sip:bob@example.com>;tag=6418913922105372816
Route: <sip:proxy.example.com;lr> Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE CSeq: 2 UPDATE
skipping to change at page 22, line 35 skipping to change at page 21, line 35
t=0 0 t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0 m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1 a=acfg:1 t=1
Message (11): UPDATE Proxy -> Alice Message (11): UPDATE Proxy -> Alice
This shows the UPDATE being relayed to Alice from Bob (and Alice's This shows the UPDATE being relayed to Alice from Bob (and Alice's
proxy). Note that Bob's proxy has inserted an Identity and proxy). Note that Bob's proxy has inserted an Identity and
Identity-Info header. As above, we only show one element for both Identity-Info header. As above, we only show one element for both
proxies for purposes of simplification. Alice verifies the proxies for purposes of simplification. Alice verifies the
identity provided [Note: the actual identity signatures here are identity provided. (Note: the actual identity signatures here are
incorrect and provided merely as examples.] incorrect and provided merely as examples.)
UPDATE sip:alice@ua1.example.com SIP/2.0 UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816 From <sip:bob@example.com>;tag=6418913922105372816
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at page 24, line 30 skipping to change at page 23, line 30
c=IN IP4 ua2.example.com c=IN IP4 ua2.example.com
a=setup:actpass a=setup:actpass
a=fingerprint: SHA-1 \ a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
m=audio 6056 RTP/AVP 0 m=audio 6056 RTP/AVP 0
a=sendrecv a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1 a=pcfg:1 t=1
7.3. Basic Message Flow with STUN check for NAT Case 7.3. Basic Message Flow with STUN Check for NAT Case
In the previous examples, the DTLS handshake has already completed by In the previous examples, the DTLS handshake has already completed by
the time Alice receives Bob's 200 OK (8). Therefore, no STUN check the time Alice receives Bob's 200 OK (8). Therefore, no STUN check
is sent. However, if Alice had a NAT, then Bob's ClientHello might is sent. However, if Alice had a NAT, then Bob's ClientHello might
get blocked by that NAT, in which case Alice would send the the STUN get blocked by that NAT, in which case Alice would send the STUN
check described in Section 6.7.1 upon receiving the 200 OK, as shown check described in Section 6.7.1 upon receiving the 200 OK, as shown
below: below:
Alice Proxies Bob Alice Proxies Bob
|(1) INVITE | | |(1) INVITE | |
|---------------->| | |---------------->| |
| |(2) INVITE | | |(2) INVITE |
| |----------------->| | |----------------->|
| |(3) hello | | |(3) hello |
| X<-----------------| | X<-----------------|
skipping to change at page 25, line 41 skipping to change at page 24, line 41
|----------------------------------->| |----------------------------------->|
The messages here are the same as in the first example (for The messages here are the same as in the first example (for
simplicity this example omits an UPDATE), with the following three simplicity this example omits an UPDATE), with the following three
new messages: new messages:
Message (5): STUN connectivity-check Alice -> Bob Message (5): STUN connectivity-check Alice -> Bob
Section 6.7.1 describes an approach to avoid an SBC interaction Section 6.7.1 describes an approach to avoid an SBC interaction
issue where the endpoints do not support ICE. Alice (the passive issue where the endpoints do not support ICE. Alice (the passive
endpoint) sends a STUN connectivity check to Bob. This opens a endpoint) sends a STUN connectivity check to Bob. This opens a
pinhole in Alice's NAT/firewall. pinhole in Alice's NAT/firewall.
Message (6): STUN connectivity-check response Bob -> Alice Message (6): STUN connectivity-check response Bob -> Alice
Bob (the active endpoint) sends a response to the STUN Bob (the active endpoint) sends a response to the STUN
connectivity check (Message 3) to Alice. This tells Alice that connectivity check (Message 3) to Alice. This tells Alice that
her connectivity check has succeeded and she can stop the her connectivity check has succeeded and she can stop the
retransmit state machine. retransmit state machine.
Message (7): Hello (retransmit) Bob -> Alice Message (7): Hello (retransmit) Bob -> Alice
Bob retransmits his DTLS ClientHello which now passes through the Bob retransmits his DTLS ClientHello, which now passes through the
pinhole created in Alice's firewall. At this point, the DTLS pinhole created in Alice's firewall. At this point, the DTLS
handshake proceeds as before. handshake proceeds as before.
8. Security Considerations 8. Security Considerations
DTLS or TLS media signalled with SIP requires a way to ensure that DTLS or TLS media signaled with SIP requires a way to ensure that the
the communicating peers' certificates are correct. communicating peers' certificates are correct.
The standard TLS/DTLS strategy for authenticating the communicating The standard TLS/DTLS strategy for authenticating the communicating
parties is to give the server (and optionally the client) a PKIX parties is to give the server (and optionally the client) a PKIX
[RFC5280] certificate. The client then verifies the certificate and [RFC5280] certificate. The client then verifies the certificate and
checks that the name in the certificate matches the server's domain checks that the name in the certificate matches the server's domain
name. This works because there are a relatively small number of name. This works because there are a relatively small number of
servers with well-defined names; a situation which does not usually servers with well-defined names; a situation that does not usually
occur in the VoIP context. occur in the VoIP context.
The design described in this document is intended to leverage the The design described in this document is intended to leverage the
authenticity of the signaling channel (while not requiring authenticity of the signaling channel (while not requiring
confidentiality). As long each side of the connection can verify the confidentiality). As long as each side of the connection can verify
integrity of the SDP received from the other side, then the DTLS the integrity of the SDP received from the other side, then the DTLS
handshake cannot be hijacked via a man-in-the-middle attack. This handshake cannot be hijacked via a man-in-the-middle attack. This
integrity protection is easily provided by the caller to the callee integrity protection is easily provided by the caller to the callee
(see Alice to Bob in Section 7) via the SIP Identity [RFC4474] (see Alice to Bob in Section 7) via the SIP Identity [RFC4474]
mechanism. Other mechanisms, such as the S/MIME mechanism described mechanism. Other mechanisms, such as the S/MIME mechanism described
in RFC 3261, or perhaps future mechanisms yet to be defined could in RFC 3261, or perhaps future mechanisms yet to be defined could
also serve this purpose. also serve this purpose.
While this mechanism can still be used without such integrity While this mechanism can still be used without such integrity
mechanisms, the security provided is limited to defense against mechanisms, the security provided is limited to defense against
passive attack by intermediaries. An active attack on the signaling passive attack by intermediaries. An active attack on the signaling
plus an active attack on the media plane can allow an attacker to plus an active attack on the media plane can allow an attacker to
attack the connection (R-SIG-MEDIA in the notation of attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
[I-D.ietf-sip-media-security-requirements]).
8.1. Responder Identity 8.1. Responder Identity
SIP Identity does not support signatures in responses. Ideally Alice SIP Identity does not support signatures in responses. Ideally,
would want to know that Bob's SDP had not been tampered with and who Alice would want to know that Bob's SDP had not been tampered with
it was from so that Alice's User Agent could indicate to Alice that and who it was from so that Alice's User Agent could indicate to
there was a secure phone call to Bob. [RFC4916] defines an approach Alice that there was a secure phone call to Bob. [RFC4916] defines
for a UA to supply its identity to its peer UA and for this identity an approach for a UA to supply its identity to its peer UA, and for
to be signed by an authentication service. For example, using this this identity to be signed by an authentication service. For
approach, Bob sends an answer, then immediately follows up with an example, using this approach, Bob sends an answer, then immediately
UPDATE that includes the fingerprint and uses the SIP Identity follows up with an UPDATE that includes the fingerprint and uses the
mechanism to assert that the message is from Bob@example.com. The SIP Identity mechanism to assert that the message is from
downside of this approach is that it requires the extra round trip of Bob@example.com. The downside of this approach is that it requires
the UPDATE. However, it is simple and secure even when not all of the extra round trip of the UPDATE. However, it is simple and secure
the proxies are trusted. In this example, Bob only needs to trust even when not all of the proxies are trusted. In this example, Bob
his proxy. Offerers SHOULD support this mechanism and Answerers only needs to trust his proxy. Offerers SHOULD support this
SHOULD use it. mechanism and answerers SHOULD use it.
In some cases, answerers will not send an UPDATE and in many calls, In some cases, answerers will not send an UPDATE and in many calls,
some media will be sent before the UPDATE is received. In these some media will be sent before the UPDATE is received. In these
cases, no integrity is provided for the fingerprint from Bob to cases, no integrity is provided for the fingerprint from Bob to
Alice. In this approach, an attacker that was on the signaling path Alice. In this approach, an attacker that was on the signaling path
could tamper with the fingerprint and insert themselves as a man-in- could tamper with the fingerprint and insert themselves as a man-in-
the-middle on the media. Alice would know that she had a secure call the-middle on the media. Alice would know that she had a secure call
with someone but would not know if it was with Bob or a man-in-the- with someone, but would not know if it was with Bob or a man-in-the-
middle. Bob would know that an attack was happening. The fact that middle. Bob would know that an attack was happening. The fact that
one side can detect this attack means that in most cases where Alice one side can detect this attack means that in most cases where Alice
and Bob both wish the communications to be encrypted there is not a and Bob both wish for the communications to be encrypted, there is
problem. Keep in mind that in any of the possible approaches Bob not a problem. Keep in mind that in any of the possible approaches,
could always reveal the media that was received to anyone. We are Bob could always reveal the media that was received to anyone. We
making the assumption that Bob also wants secure communications. In are making the assumption that Bob also wants secure communications.
this do nothing case, Bob knows the media has not been tampered with In this do nothing case, Bob knows the media has not been tampered
or intercepted by a third party and that it is from with or intercepted by a third party and that it is from
Alice@example.com. Alice knows that she is talking to someone and Alice@example.com. Alice knows that she is talking to someone and
that whoever that is has probably checked that the media is not being that whoever that is has probably checked that the media is not being
intercepted or tampered with. This approach is certainly less than intercepted or tampered with. This approach is certainly less than
ideal but very usable for many situations. ideal but very usable for many situations.
8.2. SIPS 8.2. SIPS
If SIP Identity is not used, but the signaling is protected by SIPS, If SIP Identity is not used, but the signaling is protected by SIPS,
the security guarantees are weaker. Some security is still provided the security guarantees are weaker. Some security is still provided
as long as all proxies are trusted. This provides integrity for the as long as all proxies are trusted. This provides integrity for the
fingerprint in a chain-of-trust security model. Note, however, that fingerprint in a chain-of-trust security model. Note, however, that
if the proxies are not trusted, then the level of security provided if the proxies are not trusted, then the level of security provided
is limited. is limited.
8.3. S/MIME 8.3. S/MIME
RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that RFC 3261 [RFC3261] defines an S/MIME security mechanism for SIP that
could be used to sign that the fingerprint was from Bob. This would could be used to sign that the fingerprint was from Bob. This would
be secure. be secure.
8.4. Continuity of Authentication 8.4. Continuity of Authentication
One desirable property of a secure media system is to provide One desirable property of a secure media system is to provide
continuity of authentication: being able to ensure cryptographically continuity of authentication: being able to ensure cryptographically
that you are talking to the same person as before. With DTLS, that you are talking to the same person as before. With DTLS,
continuity of authentication is achieved by having each side use the continuity of authentication is achieved by having each side use the
same public key/self-signed certificate for each connection (at least same public key/self-signed certificate for each connection (at least
with a given peer entity). It then becomes possible to cache the with a given peer entity). It then becomes possible to cache the
credential (or its hash) and verify that it is unchanged. Thus, once credential (or its hash) and verify that it is unchanged. Thus, once
a single secure connection has been established, an implementation a single secure connection has been established, an implementation
can establish a future secure channel even in the face of future can establish a future secure channel even in the face of future
insecure signalling. insecure signaling.
In order to enable continuity of authentication, implementations In order to enable continuity of authentication, implementations
SHOULD attempt to keep a constant long-term key. Verifying SHOULD attempt to keep a constant long-term key. Verifying
implementations SHOULD maintain a cache of the key used for each peer implementations SHOULD maintain a cache of the key used for each peer
identity and alert the user if that key changes. identity and alert the user if that key changes.
8.5. Short Authentication String 8.5. Short Authentication String
An alternative available to Alice and Bob is to use human speech to An alternative available to Alice and Bob is to use human speech to
verify each others' identity and then to verify each others' verify each other's identity and then to verify each other's
fingerprints also using human speech. Assuming that it is difficult fingerprints also using human speech. Assuming that it is difficult
to impersonate another's speech and seamlessly modify the audio to impersonate another's speech and seamlessly modify the audio
contents of a call, this approach is relatively safe. It would not contents of a call, this approach is relatively safe. It would not
be effective if other forms of communication were being used such as be effective if other forms of communication were being used such as
video or instant messaging. DTLS supports this mode of operation. video or instant messaging. DTLS supports this mode of operation.
The minimal secure fingerprint length is around 64 bits. The minimal secure fingerprint length is around 64 bits.
ZRTP [I-D.zimmermann-avt-zrtp] includes Short Authentication String ZRTP [AVT-ZRTP] includes Short Authentication String (SAS) mode in
mode in which a unique per-connection bitstring is generated as part which a unique per-connection bitstring is generated as part of the
of the cryptographic handshake. The SAS can be as short as 25 bits cryptographic handshake. The SAS can be as short as 25 bits and so
and so is somewhat easier to read. DTLS does not natively support is somewhat easier to read. DTLS does not natively support this
this mode. Based on the level of deployment interest a TLS extension mode. Based on the level of deployment interest, a TLS extension
[RFC4366] could provide support for it. Note that SAS schemes only [RFC5246] could provide support for it. Note that SAS schemes only
work well when the endpoints recognize each other's voices, which is work well when the endpoints recognize each other's voices, which is
not true in many settings (e.g., call centers). not true in many settings (e.g., call centers).
8.6. Limits of Identity Assertions 8.6. Limits of Identity Assertions
When RFC 4474 is used to bind the media keying material to the SIP When RFC 4474 is used to bind the media keying material to the SIP
signalling, the assurances about the provenance and security of the signaling, the assurances about the provenance and security of the
media are only as good as those for the signalling. There are two media are only as good as those for the signaling. There are two
important cases to note here: important cases to note here:
o RFC 4474 assumes that the proxy with the certificate "example.com" o RFC 4474 assumes that the proxy with the certificate "example.com"
controls the namespace "example.com". Therefore the RFC 4474 controls the namespace "example.com". Therefore, the RFC 4474
authentication service which is authoritative for a given authentication service that is authoritative for a given namespace
namespace can control which user is assigned each name. Thus, the can control which user is assigned each name. Thus, the
authentication service can take an address formerly assigned to authentication service can take an address formerly assigned to
Alice and transfer it to Bob. This is an intentional design Alice and transfer it to Bob. This is an intentional design
feature of RFC 4474 and a direct consequence of the SIP namespace feature of RFC 4474 and a direct consequence of the SIP namespace
architecture. architecture.
o When phone number URIs (e.g., o When phone number URIs (e.g.,
'sip:+17005551008@chicago.example.com' or 'sip:+17005551008@chicago.example.com' or
'sip:+17005551008@chicago.example.com;user=phone') are used, there 'sip:+17005551008@chicago.example.com;user=phone') are used, there
is no structural reason to trust that the domain name is is no structural reason to trust that the domain name is
authoritative for a given phone number, although individual authoritative for a given phone number, although individual
proxies and UAs may have private arrangements that allow them to proxies and UAs may have private arrangements that allow them to
trust other domains. This is a structural issue in that PSTN trust other domains. This is a structural issue in that Public
elements are trusted to assert their phone number correctly and Switched Telephone Network (PSTN) elements are trusted to assert
that there is no real concept of a given entity being their phone number correctly and that there is no real concept of
authoritative for some number space. a given entity being authoritative for some number space.
In both of these cases, the assurances that DTLS-SRTP provides in In both of these cases, the assurances that DTLS-SRTP provides in
terms of data origin integrity and confidentiality are necessarily no terms of data origin integrity and confidentiality are necessarily no
better than SIP provides for signalling integrity when RFC 4474 is better than SIP provides for signaling integrity when RFC 4474 is
used. Implementors should therefore take care not to indicate used. Implementors should therefore take care not to indicate
misleading peer identity information in the user interface. e.g. If misleading peer identity information in the user interface. That is,
the peer's identity is sip:+17005551008@chicago.example.com, it is if the peer's identity is sip:+17005551008@chicago.example.com, it is
not sufficient to display that the identity of the peer as not sufficient to display that the identity of the peer as
+17005551008, unless there is some policy that states that the domain +17005551008, unless there is some policy that states that the domain
"chicago.example.com" is trusted to assert the E.164 numbers it is "chicago.example.com" is trusted to assert the E.164 numbers it is
asserting. In cases where the UA can determine that the peer asserting. In cases where the UA can determine that the peer
identity is clearly an E.164 number, it may be less confusing to identity is clearly an E.164 number, it may be less confusing to
simply identify the call as encrypted but to an unknown peer. simply identify the call as encrypted but to an unknown peer.
In addition, some middleboxes (B2BUAs and Session Border Controllers) In addition, some middleboxes (back-to-back user agents (B2BUAs) and
are known to modify portions of the SIP message which are included in Session Border Controllers) are known to modify portions of the SIP
the RFC 4474 signature computation, thus breaking the signature. message that are included in the RFC 4474 signature computation, thus
This sort of man-in-the-middle operation is precisely the sort of breaking the signature. This sort of man-in-the-middle operation is
message modification that 4474 is intended to detect. In cases where precisely the sort of message modification that RFC 4474 is intended
the middlebox is itself permitted to generate valid RFC 4474 to detect. In cases where the middlebox is itself permitted to
signatures (e.g., it is within the same administrative domain as the generate valid RFC 4474 signatures (e.g., it is within the same
RFC 4474 authentication service), then it may generate a new administrative domain as the RFC 4474 authentication service), then
signature on the modified message. Alternately, the middlebox may be it may generate a new signature on the modified message.
able to sign with some other identity that it is permitted to assert. Alternately, the middlebox may be able to sign with some other
Otherwise, the recipient cannot rely on the RFC 4474 Identity identity that it is permitted to assert. Otherwise, the recipient
assertion and the UA MUST NOT indicate to the user that a secure call cannot rely on the RFC 4474 Identity assertion and the UA MUST NOT
has been established to the claimed identity. Implementations which indicate to the user that a secure call has been established to the
are configured to only establish secure calls SHOULD terminate the claimed identity. Implementations that are configured to only
call in this case. establish secure calls SHOULD terminate the call in this case.
If SIP Identity or an equivalent mechanism is not used, then only If SIP Identity or an equivalent mechanism is not used, then only
protection against attackers who cannot actively change the signaling protection against attackers who cannot actively change the signaling
is provided. While this is still superior to previous mechanisms, is provided. While this is still superior to previous mechanisms,
the security provided is inferior to that provided if integrity is the security provided is inferior to that provided if integrity is
provided for the signaling. provided for the signaling.
8.7. Third Party Certificates 8.7. Third-Party Certificates
This specification does not depend on the certificates being held by This specification does not depend on the certificates being held by
endpoints being independently verifiable (e.g., being issued by a endpoints being independently verifiable (e.g., being issued by a
trusted third party.) However, there is no limitation on such trusted third party). However, there is no limitation on such
certificates being used. Aside from the difficulty of obtaining such certificates being used. Aside from the difficulty of obtaining such
certificates, it is not clear what identities those certificates certificates, it is not clear what identities those certificates
would contain---RFC 3261 specifies a convention for S/MIME would contain -- RFC 3261 specifies a convention for S/MIME
certificates which could also be used here, but that has seen only certificates that could also be used here, but that has seen only
minimal deployment. However, in closed or semi-closed contexts where minimal deployment. However, in closed or semi-closed contexts where
such a convention can be established, third party certificates can such a convention can be established, third-party certificates can
reduce the reliance on trusting even proxies in the endpoint's reduce the reliance on trusting even proxies in the endpoint's
domains. domains.
8.8. Perfect Forward Secrecy 8.8. Perfect Forward Secrecy
One concern about the use of a long-term key is that compromise of One concern about the use of a long-term key is that compromise of
that key may lead to compromise of past communications. In order to that key may lead to compromise of past communications. In order to
prevent this attack, DTLS supports modes with Perfect Forward Secrecy prevent this attack, DTLS supports modes with Perfect Forward Secrecy
using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites.
When these modes are in use, the system is secure against such When these modes are in use, the system is secure against such
attacks. Note that compromise of a long-term key may still lead to attacks. Note that compromise of a long-term key may still lead to
future active attacks. If this is a concern, a backup authentication future active attacks. If this is a concern, a backup authentication
channel such as manual fingerprint establishment or a short channel, such as manual fingerprint establishment or a short
authentication string should be used. authentication string, should be used.
9. IANA Considerations
This specification does not require any IANA actions.
10. Acknowledgments 9. Acknowledgments
Cullen Jennings contributed substantial text and comments to this Cullen Jennings contributed substantial text and comments to this
document. This document benefited from discussions with Francois document. This document benefited from discussions with Francois
Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful
comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David
McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman, McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman,
David Oran, and Peter Schneider. David Oran, and Peter Schneider.
We would like to thank Thomas Belling, Guenther Horn, Steffen Fries, We would like to thank Thomas Belling, Guenther Horn, Steffen Fries,
Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa
Lehtovirta for their input regarding traversal of SBCs. Lehtovirta for their input regarding traversal of SBCs.
11. References 10. References
11.1. Normative References
10.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.
[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,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
skipping to change at page 32, line 5 skipping to change at page 31, line 9
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
11.2. Informational References 10.2. Informative References
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over
Oriented Transport", RFC 4571, July 2006. Connection-Oriented Transport", RFC 4571, July 2006.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[I-D.ietf-mmusic-ice] [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT)
(ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April
Traversal for Offer/Answer Protocols", 2010.
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[I-D.zimmermann-avt-zrtp] [AVT-ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress,
Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-15 (work in progress),
March 2009. March 2009.
[I-D.mcgrew-srtp-ekt] [SRTP-EKT] McGrew, D., Andreasen, F., and L. Dondeti, "Encrypted Key
McGrew, D., "Encrypted Key Transport for Secure RTP", Transport for Secure RTP", Work in Progress, March 2009.
draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
[I-D.ietf-avt-dtls-srtp] [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure
Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-07 (work in progress),
February 2009.
[I-D.ietf-sip-media-security-requirements] [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management "Requirements and Analysis of Media Security Management
Protocols", draft-ietf-sip-media-security-requirements-09 Protocols", RFC 5479, March 2009.
(work in progress), January 2009.
[I-D.ietf-mmusic-sdp-capability-negotiation] [MMUSIC-SDP]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation", Work
draft-ietf-mmusic-sdp-capability-negotiation-09 (work in in Progress, February 2010.
progress), July 2008.
[I-D.ietf-avt-rtp-and-rtcp-mux] [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
and T. Wright, "Transport Layer Security (TLS) (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Extensions", RFC 4366, April 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[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.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[I-D.wing-sipping-srtp-key] [SIPPING-SRTP]
Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
Johnston, "Secure Media Recording and Transcoding with the Johnston, "Secure Media Recording and Transcoding with the
Session Initiation Protocol", Session Initiation Protocol", Work in Progress,
draft-wing-sipping-srtp-key-04 (work in progress),
October 2008. October 2008.
[I-D.wing-avt-dtls-srtp-key-transport] [KEY-TRANSPORT]
Wing, D., "DTLS-SRTP Key Transport", Wing, D., "DTLS-SRTP Key Transport (KTR)", Work
draft-wing-avt-dtls-srtp-key-transport-02 (work in in Progress, March 2009.
progress), July 2008.
[I-D.ietf-mmusic-media-path-middleboxes] [MMUSIC-MEDIA]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along Interactions for Signaling Protocol Communication along
the Media Path", the Media Path", Work in Progress, March 2009.
draft-ietf-mmusic-media-path-middleboxes-01 (work in
progress), July 2008.
[I-D.ietf-sip-ua-privacy] [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-
Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-06
(work in progress), March 2009.
Appendix A. Requirements Analysis Appendix A. Requirements Analysis
[I-D.ietf-sip-media-security-requirements] describes security [RFC5479] describes security requirements for media keying. This
requirements for media keying. This section evaluates this proposal section evaluates this proposal with respect to each requirement.
with respect to each requirement.
A.1. Forking and retargeting (R-FORK-RETARGET, R-BEST-SECURE, A.1. Forking and Retargeting (R-FORK-RETARGET, R-BEST-SECURE,
R-DISTINCT) R-DISTINCT)
In this draft, the SDP offer (in the INVITE) is simply an In this document, the SDP offer (in the INVITE) is simply an
advertisement of the capability to do security. This advertisement advertisement of the capability to do security. This advertisement
does not depend on the identity of the communicating peer, so forking does not depend on the identity of the communicating peer, so forking
and retargeting work work when all the endpoints will do SRTP. When and retargeting work when all the endpoints will do SRTP. When a mix
a mix of SRTP and non-SRTP endpoints are present, we use the SDP of SRTP and non-SRTP endpoints are present, we use the SDP
capabilities mechanism currently being defined capabilities mechanism currently being defined [MMUSIC-SDP] to
[I-D.ietf-mmusic-sdp-capability-negotiation] to transparently transparently negotiate security where possible. Because DTLS
negotiate security where possible. Because DTLS establishes a new establishes a new key for each session, only the entity with which
key for each session, only the entity with which the call is finally the call is finally established gets the media encryption keys (R3).
established gets the media encryption keys (R3).
A.2. Distinct Cryptographic Contexts (R-DISTINCT) A.2. Distinct Cryptographic Contexts (R-DISTINCT)
DTLS performs a new DTLS handshake with each endpoint, which DTLS performs a new DTLS handshake with each endpoint, which
establishes distinct keys and cryptographic contexts for each establishes distinct keys and cryptographic contexts for each
endpoint. endpoint.
A.3. Reusage of a Security Context (R-REUSE) A.3. Reusage of a Security Context (R-REUSE)
DTLS allows sessions to be resumed with the 'TLS session resumption' DTLS allows sessions to be resumed with the 'TLS session resumption'
functionality. This feature can be used to lower the amount of functionality. This feature can be used to lower the amount of
cryptographic computation that needs to be done when two peers re- cryptographic computation that needs to be done when two peers
initiates the communication. See [I-D.ietf-avt-dtls-srtp] for more re-initiate the communication. See [RFC5764] for more on session
on session resumption in this context. resumption in this context.
A.4. Clipping (R-AVOID-CLIPPING) A.4. Clipping (R-AVOID-CLIPPING)
Because the key establishment occurs in the media plane, media need Because the key establishment occurs in the media plane, media need
not be clipped before the receipt of the SDP answer. Note, however, not be clipped before the receipt of the SDP answer. Note, however,
that only confidentiality is provided until the offerer receives the that only confidentiality is provided until the offerer receives the
answer: the answerer knows that they are not sending data to an answer: the answerer knows that they are not sending data to an
attacker but the offerer cannot know that they are receiving data attacker but the offerer cannot know that they are receiving data
from the answerer. from the answerer.
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) A.5. Passive Attacks on the Media Path (R-PASS-MEDIA)
The public key algorithms used by DTLS ciphersuites, such as RSA, The public key algorithms used by DTLS cipher suites, such as RSA,
Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against
passive attacks. passive attacks.
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) A.6. Passive Attacks on the Signaling Path (R-PASS-SIG)
DTLS provides protection against passive attacks by adversaries on DTLS provides protection against passive attacks by adversaries on
the signaling path since only a fingerprint is exchanged using SIP the signaling path since only a fingerprint is exchanged using SIP
signaling. signaling.
A.7. (R-SIG-MEDIA, R-ACT-ACT) A.7. (R-SIG-MEDIA, R-ACT-ACT)
An attacker who controls the media channel but not the signalling An attacker who controls the media channel but not the signaling
channel can perform a MITM attack on the DTLS handshake but this will channel can perform a MITM attack on the DTLS handshake but this will
change the certificates which will cause the fingerprint check to change the certificates that will cause the fingerprint check to
fail. Thus, any successful attack requires that the attacker modify fail. Thus, any successful attack requires that the attacker modify
the signalling messages to replace the fingerprints. the signaling messages to replace the fingerprints.
If RFC 4474 Identity or an equivalent mechanism is used, a attacker If RFC 4474 Identity or an equivalent mechanism is used, an attacker
who controls the signalling channel at any point between the proxies who controls the signaling channel at any point between the proxies
performing the Identity signatures cannot modify the fingerprints performing the Identity signatures cannot modify the fingerprints
without invalidating the signature. Thus, even an attacker who without invalidating the signature. Thus, even an attacker who
controls both signalling and media paths cannot successfully attack controls both signaling and media paths cannot successfully attack
the media traffic. Note that the channel between the UA and the the media traffic. Note that the channel between the UA and the
authentication service MUST be secured and the authentication service authentication service MUST be secured and the authentication service
MUST verify the UA's identity in order for this mechanism to be MUST verify the UA's identity in order for this mechanism to be
secure. secure.
Note that an attacker who controls the authentication service can Note that an attacker who controls the authentication service can
impersonate the UA using that authentication service. This is an impersonate the UA using that authentication service. This is an
intended feature of SIP Identity--the authentication service owns the intended feature of SIP Identity -- the authentication service owns
namespace and therefore defines which user has which identity. the namespace and therefore defines which user has which identity.
A.8. Binding to Identifiers (R-ID-BINDING) A.8. Binding to Identifiers (R-ID-BINDING)
When an end-to-end mechanism such as SIP-Identity [RFC4474] and SIP- When an end-to-end mechanism such as SIP-Identity [RFC4474] and SIP-
Connected-Identity [RFC4916] or S/MIME are used, they bind the Connected-Identity [RFC4916] or S/MIME are used, they bind the
endpoint's certificate fingerprints to the From: address in the endpoint's certificate fingerprints to the From: address in the
signalling. The fingerprint is covered by the Identity signature. signaling. The fingerprint is covered by the Identity signature.
When other mechanisms (e.g., SIPS) are used, then the binding is When other mechanisms (e.g., SIPS) are used, then the binding is
correspondingly weaker. correspondingly weaker.
A.9. Perfect Forward Secrecy (R-PFS) A.9. Perfect Forward Secrecy (R-PFS)
DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher
suites which provide PFS. suites that provide PFS.
A.10. Algorithm Negotiation (R-COMPUTE) A.10. Algorithm Negotiation (R-COMPUTE)
DTLS negotiates cipher suites before performing significant DTLS negotiates cipher suites before performing significant
cryptographic computation and therefore supports algorithm cryptographic computation and therefore supports algorithm
negotiation and multiple cipher suites without additional negotiation and multiple cipher suites without additional
computational expense. computational expense.
A.11. RTP Validity Check (R-RTP-VALID) A.11. RTP Validity Check (R-RTP-VALID)
DTLS packets do not pass the RTP validity check. The first byte of a DTLS packets do not pass the RTP validity check. The first byte of a
DTLS packet is the content type and All current DTLS content types DTLS packet is the content type and all current DTLS content types
have the first two bits set to zero, resulting in a version of 0, have the first two bits set to zero, resulting in a version of zero;
thus failing the first validity check. DTLS packets can also be thus, failing the first validity check. DTLS packets can also be
distinguished from STUN packets. See [I-D.ietf-avt-dtls-srtp] for distinguished from STUN packets. See [RFC5764] for details on
details on demultiplexing. demultiplexing.
A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) A.12. Third-Party Certificates (R-CERTS, R-EXISTING)
Third party certificates are not required because signalling (e.g., Third-party certificates are not required because signaling (e.g.,
[RFC4474]) is used to authenticate the certificates used by DTLS. [RFC4474]) is used to authenticate the certificates used by DTLS.
However, if the parties share an authentication infrastructure that However, if the parties share an authentication infrastructure that
is compatible with TLS (3rd party certificates or shared keys) it can is compatible with TLS (third-party certificates or shared keys) it
be used. can be used.
A.13. FIPS 140-2 (R-FIPS) A.13. FIPS 140-2 (R-FIPS)
TLS implementations already may be FIPS 140-2 approved and the TLS implementations already may be FIPS 140-2 approved and the
algorithms used here are consistent with the approval of DTLS and algorithms used here are consistent with the approval of DTLS and
DTLS-SRTP. DTLS-SRTP.
A.14. Linkage between Keying Exchange and SIP Signaling (R-ASSOC) A.14. Linkage between Keying Exchange and SIP Signaling (R-ASSOC)
The signaling exchange is linked to the key management exchange using The signaling exchange is linked to the key management exchange using
the fingerprints carried in SIP and the certificates are exchanged in the fingerprints carried in SIP and the certificates are exchanged in
DTLS. DTLS.
A.15. Denial of Service Vulnerability (R-DOS) A.15. Denial-of-Service Vulnerability (R-DOS)
DTLS offers some degree of DoS protection as a built-in feature (see DTLS offers some degree of Denial-of-Service (DoS) protection as a
Section 4.2.1 or RFC 4347). built-in feature (see Section 4.2.1 of [RFC4347]).
A.16. Crypto-Agility (R-AGILITY) A.16. Crypto-Agility (R-AGILITY)
DTLS allows ciphersuites to be negotiated and hence new algorithms DTLS allows cipher suites to be negotiated and hence new algorithms
can be incrementally deployed. Work on replacing the fixed MD5/SHA-1 can be incrementally deployed. Work on replacing the fixed MD5/SHA-1
key derivation function is ongoing. key derivation function is ongoing.
A.17. Downgrading Protection (R-DOWNGRADE) A.17. Downgrading Protection (R-DOWNGRADE)
DTLS provides protection against downgrading attacks since the DTLS provides protection against downgrading attacks since the
selection of the offered ciphersuites is confirmed in a later stage selection of the offered cipher suites is confirmed in a later stage
of the handshake. This protection is efficient unless an adversary of the handshake. This protection is efficient unless an adversary
is able to break a ciphersuite in real-time. RFC 4474 is able to is able to break a cipher suite in real-time. RFC 4474 is able to
prevent an active attacker on the signalling path from downgrading prevent an active attacker on the signaling path from downgrading the
the call from SRTP to RTP. call from SRTP to RTP.
A.18. Media Security Negotation (R-NEGOTIATE) A.18. Media Security Negotiation (R-NEGOTIATE)
DTLS allows a User Agent to negotiate media security parameters for DTLS allows a User Agent to negotiate media security parameters for
each individual session. each individual session.
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) A.19. Signaling Protocol Independence (R-OTHER-SIGNALING)
The DTLS-SRTP framework does not rely on SIP; every protocol that is The DTLS-SRTP framework does not rely on SIP; every protocol that is
capable of exchanging a fingerprint and the media description can be capable of exchanging a fingerprint and the media description can be
secured. secured.
A.20. Media Recording (R-RECORDING) A.20. Media Recording (R-RECORDING)
An extension, see [I-D.wing-sipping-srtp-key], has been specified to An extension, see [SIPPING-SRTP], has been specified to support media
support media recording that does not require intermediaries to act recording that does not require intermediaries to act as an MITM.
as a MITM.
When media recording is done by intermediaries then they need to act When media recording is done by intermediaries, then they need to act
as a MITM. as an MITM.
A.21. Interworking with Intermediaries (R-TRANSCODER) A.21. Interworking with Intermediaries (R-TRANSCODER)
In order to interface with any intermediary that transcodes the In order to interface with any intermediary that transcodes the
media, the transcoder must have access to the keying material and be media, the transcoder must have access to the keying material and be
treated as an endpoint for the purposes of this document. treated as an endpoint for the purposes of this document.
A.22. PSTN Gateway Termination (R-PSTN) A.22. PSTN Gateway Termination (R-PSTN)
The DTLS-SRTP framework allows the media security to terminate at a The DTLS-SRTP framework allows the media security to terminate at a
skipping to change at page 38, line 16 skipping to change at page 37, line 16
The Heterogeneous Error Response Forking Problem (HERFP) is not The Heterogeneous Error Response Forking Problem (HERFP) is not
applicable to DTLS-SRTP since the key exchange protocol will be applicable to DTLS-SRTP since the key exchange protocol will be
executed along the media path and hence error messages are executed along the media path and hence error messages are
communicated along this path and proxies do not need to progress communicated along this path and proxies do not need to progress
them. them.
Authors' Addresses Authors' Addresses
Jason Fischl Jason Fischl
CounterPath Corporation Skype, Inc.
Suite 300, One Bentall Centre, 505 Burrard Street 2145 Hamilton Ave.
Vancouver, BC V7X 1M3 San Jose, CA 95135
Canada USA
Phone: +1 604 320-3340 Phone: +1-415-692-1760
Email: jason@counterpath.com EMail: jason.fischl@skype.net
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Linnoitustie 6
Munich, Bavaria 81739 Espoo, 02600
Germany Finland
Email: Hannes.Tschofenig@nsn.com Phone: +358 (50) 4871445
URI: http://www.tschofenig.com EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: ekr@rtfm.com EMail: ekr@rtfm.com
 End of changes. 165 change blocks. 
522 lines changed or deleted 501 lines changed or added

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