draft-ietf-sip-dtls-srtp-framework-00.txt   draft-ietf-sip-dtls-srtp-framework-01.txt 
SIP J. Fischl SIP J. Fischl
Internet-Draft CounterPath Solutions, Inc. Internet-Draft CounterPath Corporation
Intended status: Standards Track H. Tschofenig Expires: August 26, 2008 H. Tschofenig
Expires: May 15, 2008 Nokia Siemens Networks Nokia Siemens Networks
E. Rescorla E. Rescorla
Network Resonance Network Resonance
November 12, 2007 February 23, 2008
Framework for Establishing an SRTP Security Context using DTLS Framework for Establishing an SRTP Security Context using DTLS
draft-ietf-sip-dtls-srtp-framework-00.txt draft-ietf-sip-dtls-srtp-framework-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2008. This Internet-Draft will expire on August 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies how to use the Session Initiation Protocol This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP) (SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS) security context using the Datagram Transport Layer Security (DTLS)
protocol. It describes a mechanism of transporting a fingerprint protocol. It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake. It relies the key that will be presented during the DTLS handshake. It relies
on the SIP identity mechanism to ensure the integrity of the on the SIP identity mechanism to ensure the integrity of the
fingerprint attribute. The key management exchange travels along the fingerprint attribute. The key exchange travels along the media path
media path as opposed to the signaling path. as opposed to the signaling path.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Verifying Certificate Integrity . . . . . . . . . . . . . . . 7 5. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 7
6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 8 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 9
6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 8 6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 9
6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 9 6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 10
6.5. Session Modification . . . . . . . . . . . . . . . . . . . 10 6.5. Session Modification . . . . . . . . . . . . . . . . . . . 10
6.6. UDP Payload De-multiplex . . . . . . . . . . . . . . . . . 10 6.6. ICE Interaction . . . . . . . . . . . . . . . . . . . . . 10
6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.8. Conference Servers and Shared Encryptions Contexts . . . . 11 6.8. Conference Servers and Shared Encryptions Contexts . . . . 11
6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 11 6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 12
6.10. Best Effort Encryption . . . . . . . . . . . . . . . . . . 11 6.10. Best Effort Encryption . . . . . . . . . . . . . . . . . . 12
7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 11 7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. Single-sided Verification . . . . . . . . . . . . . . . . 18 8.4. Single-sided Verification . . . . . . . . . . . . . . . . 19
8.5. Continuity of Authentication . . . . . . . . . . . . . . . 18 8.5. Continuity of Authentication . . . . . . . . . . . . . . . 19
8.6. Short Authentication String . . . . . . . . . . . . . . . 19 8.6. Short Authentication String . . . . . . . . . . . . . . . 19
8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 19 8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informational References . . . . . . . . . . . . . . . . . 21 11.2. Informational References . . . . . . . . . . . . . . . . . 22
Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 23 Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 24
A.1. Forking and retargeting (R1, R2, R3) . . . . . . . . . . . 23 A.1. Forking and retargeting (R-FORK-RETARGET,
A.2. Reusage of a Security Context (R4), (R11) . . . . . . . . 23 R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 24
A.3. Clipping (R5) . . . . . . . . . . . . . . . . . . . . . . 23 A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 24
A.4. Passive Attacks on the Media Path (R6) . . . . . . . . . . 24 A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 24
A.5. Passive Attacks on the Signaling Path (R7) . . . . . . . . 24 A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 24
A.6. Perfect Forward Secrecy (R8) . . . . . . . . . . . . . . . 24 A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 24
A.7. Algorithm Negotiation (R9) . . . . . . . . . . . . . . . . 24 A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 24
A.8. RTP Validity Check (R10) . . . . . . . . . . . . . . . . . 24 A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 25
A.9. 3rd Party Certificates (R12, R18) . . . . . . . . . . . . 24 A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 25
A.10. FIPS 140-2 (R13) . . . . . . . . . . . . . . . . . . . . . 24 A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 25
A.11. Linkage between Keying Exchange and SIP Signaling (R14) . 24 A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 25
A.12. Start with RTP and Upgrade to SRTP (R15) . . . . . . . . . 25 A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 25
A.13. Denial of Service Vulnerability (R16) . . . . . . . . . . 25 A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 26
A.14. Adversary Model (R17) . . . . . . . . . . . . . . . . . . 25 A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 26
A.15. Crypto-Agility (R19) . . . . . . . . . . . . . . . . . . . 25 A.14. Linkage between Keying Exchange and SIP Signaling
A.16. Downgrading Protection (R20) . . . . . . . . . . . . . . . 25 (R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 26
A.17. Media Security Negotation (R21) . . . . . . . . . . . . . 25 A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 26
A.18. Signaling Protocol Independence (R22) . . . . . . . . . . 25 A.16. Adversary Model (R-SIG-MEDIA) . . . . . . . . . . . . . . 26
A.19. Media Recording (R23) . . . . . . . . . . . . . . . . . . 25 A.17. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 26
A.20. Lawful Interception (R24) . . . . . . . . . . . . . . . . 26 A.18. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 26
A.21. Interworking with Intermediaries (R25) . . . . . . . . . . 26 A.19. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 26
A.22. PSTN Gateway Termination (R26) . . . . . . . . . . . . . . 26 A.20. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 A.21. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 A.22. Interworking with Intermediaries (R-TRANSCODER) . . . . . 27
A.23. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
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 Protocol (RTP) [RFC3550] is used to [RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used
transmit real time media on top of UDP, TCP [RFC4571], and TLS to transmit real time media on top of UDP and TCP [RFC4571].
[RFC4572]. Datagram TLS [RFC4347] was introduced to allow TLS Datagram TLS [RFC4347] was introduced to allow TLS functionality to
functionality to be applied to datagram transport protocols, such as be applied to datagram transport protocols, such as UDP and DCCP.
UDP and DCCP. This draft provides guidelines on how to use and to This draft provides guidelines on how to establish SRTP security
support for (a) transmission of media over DTLS and (b) to establish using extensions to DTLS (see [I-D.ietf-avt-dtls-srtp]).
SRTP security using extensions to DTLS (see
[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 to all devices that are signed not require deployment of certificates that are signed by a well-
by a well-known certificate authority. 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. The certificate fingerprints are where both sides have certificates. It is very important to note
sent in SDP over SIP as part of the offer/answer exchange. The SIP that certificates are being used purely as a carrier for the public
Identity mechanism [RFC4474] is used to provide integrity for the keys of the peers. This is required because DTLS does not have a
fingerprints. It is very important to note that certificates are mode for carrying bare keys, but it is purely an issue of formatting.
being used purely as a carrier for the public keys of the peers. The certificates can be self-signed and completely self-generated.
This is required because DTLS does not have a mode for carrying bare All major TLS stacks have the capability to generate such
keys, but it is purely an issue of formatting. The certificates can certificates on demand. However, third party certificates MAY also
be self-signed and completely self-generated. All major TLS stacks be used for extra security. The certificate fingerprints are sent in
have the capability to generate such certificates on demand. SDP over SIP as part of the offer/answer exchange. The SIP Identity
However, third party certificates MAY also be used for extra mechanism [RFC4474] is used to provide integrity for the
security. fingerprints.
This approach differs from previous attempts to secure media traffic This DTLS-SRTP approach differs from previous attempts to secure
where the authentication and key exchange protocol (e.g., MIKEY media traffic where the authentication and key exchange protocol
[RFC3830]) is piggybacked in the signaling message exchange. With (e.g., MIKEY [RFC3830]) is piggybacked in the signaling message
this approach, establishing the protection of the media traffic exchange. With DTLS-SRTP, establishing the protection of the media
between the endpoints is done by the media endpoints without traffic between the endpoints is done by the media endpoints without
involving the SIP/SDP communication. It allows RTP and SIP to be involving the SIP/SDP communication. It allows RTP and SIP to be
used in the usual manner when there is no encrypted media. used in the usual manner 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
skipping to change at page 5, line 25 skipping to change at page 5, line 23
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.) |
| | | |
v v | v
+-----------+ Datagram TLS +-----------+ +-----------+ Datagram TLS +-----------+
|SIP | <---------------------------------> |SIP | |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP |
|User Agent | Media |User Agent | |User Agent | Media |User Agent |
|Alice@X | <=================================> |Bob@Y | |Alice@X | <=================================> |Bob@Y |
+-----------+ +-----------+ +-----------+ +-----------+
Legend: Legend:
<--->: Signaling Traffic ------>: Signaling Traffic
<===>: Data Traffic <-+-+->: Key Management 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 Bob.
Both Bob and Alice could use public-key based authentication in order Both Bob and Alice could use public-key based authentication in order
to establish a confidentiality protected channel using DTLS. to establish a confidentiality protected channel using DTLS.
Since providing mutual authentication between two arbitrary end Since providing mutual authentication between two arbitrary end
points on the Internet using public key based cryptography tends to points on the Internet using public key based cryptography tends to
be problematic, we consider more deployment friendly alternatives. be problematic, we consider more deployment-friendly alternatives.
This document uses one approach and several others are discussed in This 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 is included in the SDP offer/answer exchange. This fingerprint is
integrity protected using the identity mechanism defined in integrity protected using the identity mechanism defined in
Enhancements for Authenticated Identity Management in SIP [RFC4474]. Enhancements for Authenticated Identity Management in SIP [RFC4474].
When Bob receives the offer, Bob establishes a mutually authenticated When Bob receives the offer, Bob establishes a mutually authenticated
DTLS connection with Alice. At this point Bob can begin sending DTLS connection with Alice. At this point Bob can begin sending
media to Alice. Once Bob accepts Alice's offer and sends an SDP media to Alice. Once Bob accepts Alice's offer and sends an SDP
answer to Alice, Alice can begin sending confidential media to Bob. answer to Alice, Alice can begin sending confidential media to Bob.
Alice and Bob will verify the fingerprints from the certificates
received over the DTLS handshakes match with the fingerprints
received in the SDP of the SIP signaling. This provides the security
property that Alice knows that the media traffic is going to Bob and
vice-versa without necessarily requiring global PKI certificates for
Alice and Bob.
3. Motivation 3. Motivation
Although there is already prior work in this area (e.g., Secure Although there is already prior work in this area (e.g., Secure
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 6, line 44 skipping to change at page 7, line 4
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 This solution works even when the SIP proxies downstream of the o This solution works even when the SIP proxies downstream of the
identity service are not trusted. There is no need to reveal keys identity service are not trusted. There is no need to reveal keys
in the SIP signaling or in the SDP message exchange. In order for in the SIP signaling or in the SDP message exchange. In order for
SDES and MIKEY to provide this security property, they require SDES and MIKEY to provide this security property, they require
distribution of certificates to the endpoints that are signed by distribution of certificates to the endpoints that are signed by
well known certificate authorities. SDES further requires that well known certificate authorities. SDES further requires that
the endpoints employ S/MIME to encrypt the keying material. the endpoints employ S/MIME to encrypt the keying material.
o In this method, SSRC collisions do not result in any extra SIP o In this method, SSRC collisions do not result in any extra SIP
signaling. 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 [I-D.ietf-avt-
[I-D.ietf-avt-dtls-srtp] is used. dtls-srtp] is 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
ciphersuite and keying material set. For consistency with other SIP/ ciphersuite and keying material set which is associated with a single
SDP usage, we use the term "connection" when what's being referred to host/port quartet. The same DTLS/TLS session can be used to
is a multimedia stream that is not specifically DTLS/TLS. establish the keying material for multiple associations. For
consistency with other SIP/SDP usage, we use the term "connection"
when what's being referred to is a multimedia stream that is not
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. Verifying Certificate Integrity 5. Exchanging Certificates
The two endpoints in the exchange present their identities as part of
the DTLS handshake procedure using certificates. This document uses
certificates in the same style as described in Comedia over TLS in
SDP [RFC4572].
If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is
ensured through the fingerprint attribute in the SDP. The
subjectAltName is not an important component of the certificate
verification.
The generation of public/private key pairs is relatively expensive.
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 'm' line will also contain several attributes [RFC4566] message, each media description ('m' line and associated
as specified in [I-D.fischl-mmusic-sdp-dtls], [RFC4145] and parameters) will also contain several attributes as specified in
[RFC4572]. [I-D.ietf-avt-dtls-srtp], [RFC4145] and [RFC4572].
The endpoint MUST use the setup and connection attributes defined in The endpoint MUST use the setup attribute defined in [RFC4145]. The
[RFC4145]. A setup:active endpoint will act as a DTLS client and a endpoint which is the offerer MUST use the setup attribute value of
setup:passive endpoint will act as a DTLS server. The connection setup:actpass and be prepared to receive a client_hello before it
attribute indicates whether or not to reuse an existing DTLS receives the answer. The answerer SHOULD use the setup attribute
association. value of setup:active and will send the client_hello in the media
path.
The endpoint MUST NOT use the connection attribute defined in
[RFC4145].
The endpoint MUST use the certificate fingerprint attribute as The endpoint MUST use the certificate fingerprint attribute as
specified in [RFC4572]. specified in [RFC4572].
The setup:active endpoint establishes a DTLS association with the
setup:passive endpoint [RFC4145]. Typically, the receiver of the SIP
INVITE request containing an offer will take the setup:active role.
The certificate presented during the DTLS handshake MUST match the 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.
If the fingerprint does not match the hashed certificate then the If the fingerprint does not match the hashed certificate then the
endpoint MUST tear down the media session immediately. endpoint MUST tear down the media session immediately.
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
skipping to change at page 8, line 33 skipping to change at page 9, line 11
application. The answerer is then able to verify that the offerer's application. The answerer is then able to verify that the offerer's
certificate used for authentication in the DTLS handshake can be certificate used for authentication in the DTLS handshake can be
associated to the certificate fingerprint contained in the offer in associated to the certificate fingerprint contained in the offer in
the SDP. At this point the answerer may indicate to the end user the SDP. At this point the answerer may indicate to the end user
that the media is secured. The offerer may only tentatively accept that the media is secured. The offerer may only tentatively accept
the answerer's certificate since it may not yet have the answerer's the answerer's certificate since it may not yet have the 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 definitively accept or reject the peer's this point the offerer can accept or reject the peer's certificate
certificate and the offerer can indicate to the end user that the and the offerer can indicate to the end user that the media is
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.
6. Miscellaneous Considerations 6. Miscellaneous Considerations
6.1. Anonymous Calls 6.1. Anonymous Calls
DTLS-SRTP does not provide anonymous calling. However, if care is
not taken, DTLS-SRTP may allow deanonymizing an otherwise anonymous
call. The following 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 can not be correlated as to
being from the same caller. In situations where some degree of being from the same caller. In situations where some degree of
correlation is acceptable, the same certificate SHOULD be used for a correlation is acceptable, the same certificate SHOULD be used for a
number of calls in order to enable continuity of authentication, see number of calls in order to enable continuity of authentication, see
Section 8.5. Section 8.5.
Additionally, it MUST be ensured that the Privacy header [RFC3325] is Additionally, it MUST be ensured that the Privacy header [RFC3325] is
used in conjunction with the SIP identity mechanism to ensure that used in conjunction with the SIP identity mechanism to ensure that
the identity of the user is not asserted when enabling anonymous the identity of the user is not asserted when enabling anonymous
calls. Furthermore, the content of the subjectAltName attribute calls. Furthermore, the content of the subjectAltName attribute
inside the certificate MUST NOT contain information that either inside the certificate MUST NOT contain information that either
allows correlation or identification of the user that wishes to place allows correlation or identification of the user that wishes to place
an anonymous call. an anonymous call. Note that following this recommendation is not
sufficient to provide anonymization.
6.2. Early Media 6.2. Early Media
If an offer is received by an endpoint that wishes to provide early If an offer is received by an endpoint that wishes to provide early
media, it MUST take the setup:active role and can immediately media, it MUST take the setup:active role and can immediately
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 unique answer. Each answerer will create a DTLS association with a unique answer. Each answerer will create a DTLS association with
the offerer. The offerer can then correlate the SDP answer received the offerer. The offerer can then securely correlate the SDP answer
in the SIP message by comparing the fingerprint in the answer to the received in the SIP message by comparing the fingerprint in the
hashed certificate for each DTLS association. answer to the hashed certificate for each DTLS association.
Note that in the situation where a request forks to multiple
endpoints that all share the same certificate, there is no way for
the caller to correlate the DTLS associations with the SIP dialogs.
Practically, this is not a problem, since the callees will terminate
the unused associations. No new security problem is introduced here
since endpoints which share the same certificate are assumed to
represent the same user.
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. Session Modification 6.5. 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 which 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. In this case, it is RECOMMENDED that the offerer UPDATE request. Once the answer is received, the active endpoint
indicate a request to reuse the existing association (using the will either reuse the existing association or establish a new one,
connection attribute) as described in Connection-Oriented Media tearing down the existing association as soon as the offer/answer
[RFC4145]. Once the answer is received, the active endpoint will exchange is completed.
either reuse the existing association or establish a new one, tearing
down the existing association as soon as the offer/answer exchange is
completed. The exact association/connection reuse behavior is
specified in RFC 4145 [RFC4145].
6.6. UDP Payload De-multiplex 6.6. 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 [I-D.ietf-mmusic-ice], provides a methodology of allowing
participants in multi-media sessions to verify mutual connectivity. participants in multi-media sessions to verify mutual connectivity.
In order to make ICE work with this specification the endpoints MUST When ICE is being used the ICE connectivity checks are performed
be able to demultiplex STUN packets from DTLS packets. STUN before the DTLS handshake begins. Note that if aggressive nomination
[RFC3489] packets MUST NOT be sent over DTLS. mode is used, multiple candidate pairs may be marked valid before ICE
finally converges on a single candidate pair. Implementations MUST
treat all ICE candidate pairs associated with a single component as
part of the same DTLS association. Thus, there will be only one DTLS
handshake even if there are multiple valid candidate pairs. Note
that this may mean adjusting the endpoint IP addresses if the
selected candidate pair shifts, just as if the DTLS packets were an
ordinary media stream.
The first byte of a STUN message is 0 or 1 and it is reasonable to Note that STUN packets are sent directly over UDP, not over DTLS.
expect it to remain 0 or 1 for the near future. The first byte of a [I-D.ietf-avt-dtls-srtp] describes how to demultiplex STUN packets
DTLS packet is "Type" which can currently have values of 20, 21, 22, from DTLS packets and SRTP packets.
and 23 as defined in ContentType declaration in [RFC4346]. It is
reasonable to expect the first byte to remain under 64 and greater If ICE is not being used, then there is potential for a bad
than 1. For RTP the first byte has a value that is 196 or above. A interaction with SBCs via "latching", as described in [I-D.ietf-
viable demultiplexing strategy would be to look at the first byte of mmusic-media-path-middleboxes]. In order to avoid this issue, if ICE
the UDP payload and if the value is less than 2, assume STUN, if is not being used, then the passive side MUST do a single
greater or equal to 196 assume RTP, otherwise assume DTLS. unauthenticad STUN [I-D.ietf-behave-rfc3489bis] connectivity check in
order to open up the appropriate pinhole. All implementations MUST
be prepared to answer this request during the handshake period even
if they do not otherwise do ICE.
6.7. Rekeying 6.7. 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.
skipping to change at page 11, line 14 skipping to change at page 11, line 41
6.8. Conference Servers and Shared Encryptions Contexts 6.8. 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. However, it is argued that the effort to encrypt each specification because each DTLS handshake establishes fresh keys
RTP packet is small compared to the other tasks performed by the which are not completely under the control of either side. However,
conference server such as the codec processing. it is argued that the effort to encrypt each RTP packet is small
compared to the other tasks performed by the conference server such
as the codec processing.
Future extensions such as [I-D.mcgrew-srtp-ekt] could be used to Future extensions such as [I-D.mcgrew-srtp-ekt] or [I-D.wing-avt-
provide this functionality in concert with the mechanisms described dtls-srtp-key-transport] could be used to provide this functionality
in this specification. in concert with the mechanisms described in this specification.
6.9. Media over SRTP 6.9. 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 [I-D.ietf-avt-dtls-
[I-D.ietf-avt-dtls-srtp], has been defined to provide for the srtp], has been defined to provide for the negotiation of SRTP
negotiation of SRTP transport using a DTLS connection, thus allowing transport using a DTLS connection, thus allowing the performance
the performance benefits of SRTP with the easy key management of benefits of SRTP with the easy key management of DTLS. The ability
DTLS. The ability to reuse existing SRTP software and hardware to reuse existing SRTP software and hardware implementations may in
implementations may in some environments another important motivation some environments provide another important motivation for using
for using DTLS-SRTP instead of RTP over DTLS. Implementations of DTLS-SRTP instead of RTP over DTLS. Implementations of this
this specification SHOULD support DTLS-SRTP [I-D.ietf-avt-dtls-srtp]. specification SHOULD support DTLS-SRTP [I-D.ietf-avt-dtls-srtp].
6.10. Best Effort Encryption 6.10. Best Effort Encryption
[I-D.ietf-sip-media-security-requirements] describes a requirement [I-D.ietf-sip-media-security-requirements] describes a requirement
for best effort encryption where SRTP is used where both endpoints for best effort encryption where SRTP is used where both endpoints
support it and key negotiation succeeds otherwise RTP is used. support it and key negotiation succeeds otherwise RTP is used.
[I-D.ietf-mmusic-sdp-capability-negotiation] describes a mechanism [I-D.ietf-mmusic-sdp-capability-negotiation] describes a mechanism
which can signal both RTP and SRTP as an alternative. RTP is the which can signal both RTP and SRTP as an alternative. RTP is the
default and will be understood by endpoints that do not understand default and will be understood by endpoints that do not understand
skipping to change at page 12, line 13 skipping to change at page 12, line 44
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.
The example shows the SIP message flows where Alice acts as the The 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 Bob sends the SIP 200 response and once Alice RTCP) can flow after Alice receives the SIP 200 response and once
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. Note that all other signaling is transported over TCP in service. Note that all other signaling is transported over TCP in
this example although it could be done over any supported transport. this example although it could be done over any supported transport.
Alice Proxies Bob Alice Proxies Bob
|(1) INVITE | | |(1) INVITE | |
|---------------->| | |---------------->| |
| |(2) INVITE | | |(2) INVITE |
| |----------------->| | |----------------->|
| | (3) hello | | |(3) conn-check |
|<-----------------------------------| |<-----------------------------------|
|(4) hello | | | |(4) hello |
|<-----------------------------------|
| |(5) conn-response |
|----------------------------------->| |----------------------------------->|
| | (5) finished | |(6) hello | |
|----------------------------------->|
| |(7) finished |
|<-----------------------------------| |<-----------------------------------|
| | (6) media | | |(8) media |
|<-----------------------------------| |<-----------------------------------|
|(7) finished | | |(9) finished | |
|----------------------------------->| |----------------------------------->|
| | (8) 200 OK | | |(10) 200 OK |
|<-----------------------------------| |<-----------------------------------|
| | (9) media | | |(11) media |
|----------------------------------->| |----------------------------------->|
|(10) ACK | | |(12) 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 which acts as Alice's identity
service. Note that Alice has requested to be the passive endpoint service. Note that Alice has requested to be either the active or
which means that it will act as the DTLS server and Bob will passive endpoint by specifying a=setup:actpass. Bob chooses to
initiate the session. Also note that there is a fingerprint act as the DTLS server and will initiate the session. Also note
attribute on the 'c' line of the SDP. This is computed from Bob's that there is a fingerprint attribute on the 'c' line of the SDP.
self-signed certificate. This is computed from Bob's self-signed certificate.
[[ NOTE: This example is not completely correct because the exact
syntax of the SDP is not yet determined. The MMUSIC working group
is currently working on standardizing mechanisms for SDP
capability negotiation which will enable this sort of best-effort
encryption. When that work is finished, this draft will be
harmonized with it.]]
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:alice@192.168.1.103:6937;transport=TLS> Contact: <sip:alice@192.168.1.103:6937;transport=TLS>
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
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
v=0 v=0
o=- 1181923068 1181923196 IN IP4 192.168.1.103 o=- 1181923068 1181923196 IN IP4 192.168.1.103
s=example1 s=example1
c=IN IP4 192.168.1.103 c=IN IP4 192.168.1.103
a=setup:passive a=setup:actpass
a=connection:new
a=fingerprint: \ a=fingerprint: \
SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SHA-1 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/AVP RTP/AVP a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP
a=pcfg:1 t=1 a=pcfg:1 t=1
Message (2): INVITE Proxy -> Bob Message (2): INVITE Proxy -> Bob
This shows the INVITE being relayed to Bob from Alice (and Bob's) This shows the INVITE being relayed to Bob from Alice (and Bob's)
proxy. Note that Alice's proxy has inserted an Identity and proxy. Note that Alice's proxy has inserted an Identity and
Identity-Info header. This example only shows one element for Identity-Info header. This example only shows one element for
both proxies for the purposes of simplification. Bob verifies the both proxies for the purposes of simplification. Bob verifies the
identity provided with the INVITE. Note that this offer includes identity provided with the INVITE. Note that this offer includes
a default m-line offering RTP in case the answerer does not a default m-line offering RTP in case the answerer does not
support SRTP. However, the potential configuration utilizing a support SRTP. However, the potential configuration utilizing a
transport of SRTP is preferred. See transport of SRTP is preferred. See [I-D.ietf-mmusic-sdp-
[I-D.ietf-mmusic-sdp-capability-negotiation] for more details on capability-negotiation] for more details on the details of SDP
the details of SDP capability negotiation. capability negotiation.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TCP 192.168.1.100:5060;branch=z9hG4bK-0e53244234324234 Via: SIP/2.0/TCP 192.168.1.100:5060;branch=z9hG4bK-0e53244234324234
Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:alice@192.168.1.103:6937;transport=TLS> Contact: <sip:alice@192.168.1.103:6937;transport=TLS>
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
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
skipping to change at page 14, line 32 skipping to change at page 15, line 27
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert Identity-Info: https://example.com/cert
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
v=0 v=0
o=- 1181923068 1181923196 IN IP4 192.168.1.103 o=- 1181923068 1181923196 IN IP4 192.168.1.103
s=example1 s=example1
c=IN IP4 192.168.1.103 c=IN IP4 192.168.1.103
a=setup:passive a=setup:actpass
a=connection:new
a=fingerprint: \ a=fingerprint: \
SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SHA-1 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): ICE connectivity-check Bob -> Alice
Section 6.6 describes an approach to avoid an SBC interaction
issue where the endpoints do not support ICE. Bob (the active
endpoint) sends a STUN connectivity check to Alice and may begin
the DTLS negotiation immediately after sending the STUN check.
Message (4): ClientHello Bob -> Alice
Assuming that Alice's identity is valid, Message 3 shows Bob Assuming that Alice's identity is valid, Message 3 shows Bob
sending a DTLS ClientHello directly to Alice for each 'm' line in sending a DTLS ClientHello directly to Alice for each 'm' line in
the SDP. In this case two DTLS ClientHello messages are sent to the SDP. In this case two DTLS ClientHello messages are sent to
Alice. Bob sends a DTLS ClientHello to 192.168.1.103:6056 for RTP Alice. Bob sends a DTLS ClientHello to 192.168.1.103:6056 for RTP
and another to port 6057 for RTCP. and another to port 6057 for RTCP.
Message (4): ServerHello+Certificate Alice -> Bob Message (5): ICE connectivity-check response Alice -> Bob
Alice (the passive endpoint) sends a response to the STUN
connectivity check (Message 3) to Bob.
Message (6): ServerHello+Certificate Alice -> Bob
Alice sends back a ServerHello, Certificate, ServerHelloDone for Alice sends back a ServerHello, Certificate, ServerHelloDone for
both RTP and RTCP associations. Note that the same certificate is both RTP and RTCP associations. Note that the same certificate is
used for both the RTP and RTCP associations. If RTP/RTCP used for both the RTP and RTCP associations. If RTP/RTCP
multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only
a single association would be required. a single association would be required.
Message (5): Certificate Bob -> Alice Message (7): 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 (8): 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. secure media is indicated to Alice.
Message (7): Finished Alice -> Bob Message (9): Finished Alice -> Bob
After Message 5 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 (10): 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 which
contains the fingerprint for Bob's certificate. When Alice contains the fingerprint for Bob's certificate. When Alice
receives the message and validates the certificate presented in receives the message and validates the certificate presented in
Message 5. The endpoint now shows Alice that the call as secured. Message 7. The endpoint now shows Alice that the call as secured.
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/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:192.168.1.104:5060;transport=TCP> Contact: <sip:192.168.1.104:5060;transport=TCP>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
v=0 v=0
o=- 6418913922105372816 2105372818 IN IP4 192.168.1.104 o=- 6418913922105372816 2105372818 IN IP4 192.168.1.104
s=example2 s=example2
c=IN IP4 192.168.1.104 c=IN IP4 192.168.1.104
a=setup:active a=setup:active
a=connection:new
a=fingerprint:\ a=fingerprint:\
SHA-1 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SHA-1 FF:FF:FF: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 12000 UDP/TLS/RTP/SAVP 0 m=audio 12000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000/1
a=acfg:1 t=1 a=acfg:1 t=1
Message (9): RTP+RTCP Alice -> Bob Message (11): RTP+RTCP Alice -> Bob
At this point, Alice can also start sending RTP and RTCP to Bob. At this point, Alice can also start sending RTP and RTCP to Bob.
Note that in this case, Bob signals the actual transport protocol Note that in this case, Bob signals the actual transport protocol
configuration of SRTP over DTLS in the acfg parameter. configuration of SRTP over DTLS in the acfg parameter.
Message 10: ACK Alice -> Bob Message (12): ACK Alice -> Bob
Finally, Alice sends the SIP ACK to Bob. Finally, Alice sends the SIP ACK to Bob.
8. Security Considerations 8. Security Considerations
DTLS or TLS media signalled with SIP requires a way to ensure that DTLS or TLS media signalled with SIP requires a way to ensure that
the communicating peers' certificates are correct. the 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
skipping to change at page 17, line 38 skipping to change at page 18, line 36
8.1. UPDATE 8.1. UPDATE
[RFC4916] defines an approach for a UA to supply its identity to its [RFC4916] defines an approach for a UA to supply its identity to its
peer UA and for this identity to be signed by an authentication peer UA and for this identity to be signed by an authentication
service. For example, using this approach, Bob sends an answer, then service. For example, using this approach, Bob sends an answer, then
immediately follows up with an UPDATE that includes the fingerprint immediately follows up with an UPDATE that includes the fingerprint
and uses the SIP Identity mechanism to assert that the message is and uses the SIP Identity mechanism to assert that the message is
from Bob@example.com. The downside of this approach is that it from Bob@example.com. The downside of this approach is that it
requires the extra round trip of the UPDATE. However, it is simple requires the extra round trip of the UPDATE. However, it is simple
and secure even when not all of the proxies are trusted. In this and secure even when not all of the proxies are trusted. In this
example, Bob only needs to trust his proxy. example, Bob only needs to trust his proxy. Answerers SHOULD send
use this UPDATE mechanisms.
[[OPEN ISSUE: Note that there is a window of vulnerability during
the early media phase of this operation before Alice receives the
UPDATE (which immediately follows the SDP answer). During this
window, Alice cannot be sure of Bob's identity. This risk might be
mitigated by including a secret in the offer which must be used to
establish the DTLS association, for instance via TLS PSK [RFC4279].
We are still studying this issue. Obviously, this is more attractive
if SIPS is used.]]
8.2. SIPS 8.2. SIPS
In this approach, the signaling is protected by TLS from hop to hop. In this approach, the signaling is protected by TLS from hop to hop.
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. It does not provide a strong assertion of who Alice is fingerprint. It does not provide a strong assertion of who Alice is
communicating with. However, as much as the target domain can be communicating with. However, as much as the target domain can be
trusted to correctly populate the From header field value, Alice can trusted to correctly populate the From header field value, Alice can
use that. The security issue with this approach is that if one of use that. The security issue with this approach is that if one of
the Proxies wished to mount a man-in-the-middle attack, it could the Proxies wished to mount a man-in-the-middle attack, it could
skipping to change at page 20, line 10 skipping to change at page 20, line 40
9. IANA Considerations 9. IANA Considerations
This specification does not require any IANA actions. This specification does not require any IANA actions.
10. Acknowledgments 10. 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, Rohan Mahy, David McGrew, Miguel comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David
Garcia, Steffen Fries, Brian Stucker, and David Oran. McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman
and David Oran.
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 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 20, line 43 skipping to change at page 21, line 29
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[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.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
skipping to change at page 21, line 23 skipping to change at page 21, line 51
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
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.
[I-D.fischl-mmusic-sdp-dtls] [I-D.ietf-behave-rfc3489bis]
Fischl, J. and H. Tschofenig, "Session Description Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Protocol (SDP) Indicators for Datagram Transport Layer "Session Traversal Utilities for (NAT) (STUN)",
Security (DTLS)", draft-fischl-mmusic-sdp-dtls-03 (work in draft-ietf-behave-rfc3489bis-15 (work in progress),
progress), July 2007. February 2008.
11.2. Informational References 11.2. Informational 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 Connection-
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
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)
skipping to change at page 21, line 50 skipping to change at page 22, line 29
[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.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
RTP", draft-zimmermann-avt-zrtp-04 (work in progress), RTP", draft-zimmermann-avt-zrtp-04 (work in progress),
July 2007. July 2007.
[I-D.mcgrew-srtp-ekt] [I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP", McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
[I-D.ietf-avt-dtls-srtp] [I-D.ietf-avt-dtls-srtp]
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)", Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-00 (work in progress), July 2007. draft-ietf-avt-dtls-srtp-01 (work in progress),
November 2007.
[I-D.ietf-sip-media-security-requirements] [I-D.ietf-sip-media-security-requirements]
Wing, D., Fries, S., Tschofenig, H., and F. Audet, Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Key "Requirements and Analysis of Media Security Management
Management Protocols", Protocols", draft-ietf-sip-media-security-requirements-03
draft-ietf-sip-media-security-requirements-00 (work in (work in progress), February 2008.
progress), September 2007.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-07 (work in draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), October 2007. progress), December 2007.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. 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.
skipping to change at page 23, line 9 skipping to change at page 23, line 33
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.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[I-D.wing-sipping-srtp-key] [I-D.wing-sipping-srtp-key]
Wing, D., "Disclosing Secure RTP (SRTP) Session Keys with Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
a SIP Event Package", draft-wing-sipping-srtp-key-01 (work Johnston, "Secure Media Recording and Transcoding with the
in progress), July 2007. Session Initiation Protocol",
draft-wing-sipping-srtp-key-03 (work in progress),
February 2008.
[I-D.wing-avt-dtls-srtp-key-transport]
Wing, D., "Datagram TLS Secure RTP (DTLS-SRTP) Key
Transport", draft-wing-avt-dtls-srtp-key-transport-01
(work in progress), February 2008.
[I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along
the Media Path",
draft-ietf-mmusic-media-path-middleboxes-00 (work in
progress), January 2008.
Appendix A. Requirements Analysis Appendix A. Requirements Analysis
[I-D.ietf-sip-media-security-requirements] describes security [I-D.ietf-sip-media-security-requirements] describes security
requirements for media keying. This section evaluates this proposal requirements for media keying. This section evaluates this proposal
with respect to each requirement. with respect to each requirement.
A.1. Forking and retargeting (R1, R2, R3) A.1. Forking and retargeting (R-FORK-RETARGET, R-BEST-SECURE,
R-DISTINCT)
In this draft, the SDP offer (in the INVITE) is simply an In this draft, 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 work when all the endpoints will do SRTP. When
a mix of SRTP and non-SRTP endpoints are present, we expect to use a mix of SRTP and non-SRTP endpoints are present, we use the SDP
the SDP capabilities mechanism currently being defined capabilities mechanism currently being defined [I-D.ietf-mmusic-sdp-
[I-D.ietf-mmusic-sdp-capability-negotiation] to transparently capability-negotiation] to transparently negotiate security where
negotiate security where possible. Because DTLS establishes a new possible. Because DTLS establishes a new key for each session, only
key for each session, only the entity with which the call is finally the entity with which the call is finally established gets the media
established gets the media encryption keys (R3). encryption keys (R3).
A.2. Reusage of a Security Context (R4), (R11) A.2. Distinct Cryptographic Contexts (R-DISTINCT)
DTLS performs a new DTLS handshake with each endpoint, which
establishes distinct keys and cryptographic contexts for each
endpoint.
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 re-
initiates the communication. initiates the communication.
A.3. Clipping (R5) 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. not be clipped before the receipt of the SDP answer.
A.4. Passive Attacks on the Media Path (R6) 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 ciphersuites, 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.5. Passive Attacks on the Signaling Path (R7) 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.6. Perfect Forward Secrecy (R8) A.7. (R-SIG-MEDIA, R-ACT-ACT)
An attacker who controls the media channel but not the signalling
channel can perform a MITM attack on the DTLS handshake but this will
change the certificates which will cause the fingerprint check to
fail. Thus, any successful attack requires that the attacker modify
the signalling messages to replace the fingerprints.
An attacker who controls the signalling channel at any point between
the proxies performing the Identity signatures cannot modify the
fingerprints without invalidating the Identity signature. Thus, even
an attacker who controls both signalling and media paths cannot
successfully attack the media traffic.
Note that an attacker who controls the authentication service can
impersonate the UA using that authentication service. This is an
intended feature of SIP Identity--the authentication service owns the
namespace and therefore defines which user has which identity.
A.8. Binding to Identifiers (R-ID-BINDING)
This mechanism uses SIP-Identity [RFC4474] and SIP-Connected-Identity
[RFC4916] to bind the endpoint's certificate fingerprints to the
From: address in the signalling. The fingerprint is covered by the
Identity signature.
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 which provide PFS.
A.7. Algorithm Negotiation (R9) 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.8. RTP Validity Check (R10) A.11. RTP Validity Check (R-RTP-VALID)
TBD 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
have the first two bits set to zero, resulting in a version of 0,
thus failing the first validity check.
A.9. 3rd Party Certificates (R12, R18) A.12. 3rd Party Certificates (R-CERTS, R-EXISTING)
Third party certificates are not required. However, if the parties Third party certificates are not required. However, if the parties
share an authentication infrastructure that is compatible with TLS share an authentication infrastructure that is compatible with TLS
(3rd party certificates or shared keys) it can be used. (3rd party certificates or shared keys) it can be used.
A.10. FIPS 140-2 (R13) 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.11. Linkage between Keying Exchange and SIP Signaling (R14) 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.12. Start with RTP and Upgrade to SRTP (R15) A.15. Denial of Service Vulnerability (R-DOS)
DTLS-SRTP as described in this framework does not require an SRTP
security context to be established as part of the initial
communication setup. Instead, the DTLS handshake can be initiated
later during on ongoing session.
A.13. Denial of Service Vulnerability (R16)
DTLS offers some degree of DoS protection particuarly as a built-in DTLS offers some degree of DoS protection particuarly as a built-in
feature. feature.
A.14. Adversary Model (R17) A.16. Adversary Model (R-SIG-MEDIA)
DTLS-SRTP requires that an adversary is at least able to intercept DTLS-SRTP requires that an adversary is at least able to intercept
the fingerprint exchange along the SIP signaling path (i.e., active the fingerprint exchange along the SIP signaling path (i.e., active
attack) and to intercept the DTLS handshake by acting as a man-in- attack) and to intercept the DTLS handshake by acting as a man-in-
the-middle adversary (i.e., active attack). the-middle adversary (i.e., active attack).
A.15. Crypto-Agility (R19) A.17. Crypto-Agility (R-AGILITY)
DTLS allows ciphersuites to be negotiated and hence new algorithms DTLS allows ciphersuites 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.16. Downgrading Protection (R20) A.18. 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 ciphersuites 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. is able to break a ciphersuite in real-time.
A.17. Media Security Negotation (R21) A.19. Media Security Negotation (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.18. Signaling Protocol Independence (R22) A.20. 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.19. Media Recording (R23) A.21. Media Recording (R-RECORDING)
An extension, see [I-D.wing-sipping-srtp-key], has been specified to An extension, see [I-D.wing-sipping-srtp-key], has been specified to
support media recording that does not require intermediaries to act support media recording that does not require intermediaries to act
as a 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 a MITM.
A.20. Lawful Interception (R24) A.22. Interworking with Intermediaries (R-TRANSCODER)
Lawful interception requires an active MITM who is located along the
signaling and the data path.
A.21. Interworking with Intermediaries (R25)
A description of the interworking with Session Border Controllers is A description of the interworking with Session Border Controllers is
described in this document. described in this document.
A.22. PSTN Gateway Termination (R26) A.23. 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
PSTN gateway. [Editor's Note: A detailed description will be PSTN gateway. This does not provide end-to-end security, but is
provided in a future version of this document.] consistent with the security goals of this framework because the
gateway is authorized to speak for the PSTN namespace.
Authors' Addresses Authors' Addresses
Jason Fischl Jason Fischl
CounterPath Solutions, Inc. CounterPath Corporation
Suite 300, One Bentall Centre, 505 Burrard Street Suite 300, One Bentall Centre, 505 Burrard Street
Vancouver, BC V7X 1M3 Vancouver, BC V7X 1M3
Canada Canada
Phone: +1 604 320-3340 Phone: +1 604 320-3340
Email: jason@counterpath.com Email: jason@counterpath.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
skipping to change at page 27, line 4 skipping to change at page 28, line 24
Email: jason@counterpath.com Email: jason@counterpath.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Eric Rescorla Eric Rescorla
Network Resonance Network Resonance
2483 E. Bayshore #212 2483 E. Bayshore #212
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: ekr@networkresonance.com Email: ekr@networkresonance.com
Full Copyright Statement Intellectual Property Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 28, line 45 skipping to change at page 29, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 104 change blocks. 
293 lines changed or deleted 354 lines changed or added

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