draft-ietf-sip-dtls-srtp-framework-05.txt   draft-ietf-sip-dtls-srtp-framework-06.txt 
SIP J. Fischl SIP J. Fischl
Internet-Draft CounterPath Corporation Internet-Draft CounterPath Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: May 2, 2009 Nokia Siemens Networks Expires: September 1, 2009 Nokia Siemens Networks
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
October 29, 2008 February 28, 2009
Framework for Establishing an SRTP Security Context using DTLS Framework for Establishing an SRTP Security Context using DTLS
draft-ietf-sip-dtls-srtp-framework-05.txt draft-ietf-sip-dtls-srtp-framework-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 2, 2009. This Internet-Draft will expire on September 1, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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. The key the key that will be presented during the DTLS handshake. The key
exchange travels along the media path as opposed to the signaling exchange travels along the media path as opposed to the signaling
path. The SIP Identity mechanism can be used to protect the path. The SIP Identity mechanism can be used to protect the
integrity of the fingerprint attribute from modification by integrity of the fingerprint attribute from modification by
intermediate proxies. intermediate proxies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Establishing a Secure Channel . . . . . . . . . . . . . . . . 8 5. Establishing a Secure Channel . . . . . . . . . . . . . . . . 9
6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 10 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 11
6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 10 6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 11
6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 11 6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 12
6.5. Multiple Associations . . . . . . . . . . . . . . . . . . 11 6.5. Multiple Associations . . . . . . . . . . . . . . . . . . 12
6.6. Session Modification . . . . . . . . . . . . . . . . . . . 11 6.6. Session Modification . . . . . . . . . . . . . . . . . . . 12
6.7. Middlebox Interaction . . . . . . . . . . . . . . . . . . 12 6.7. Middlebox Interaction . . . . . . . . . . . . . . . . . . 13
6.7.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 12 6.7.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 13
6.7.2. Latching Control Without ICE . . . . . . . . . . . . . 12 6.7.2. Latching Control Without ICE . . . . . . . . . . . . . 13
6.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.9. Conference Servers and Shared Encryptions Contexts . . . . 13 6.9. Conference Servers and Shared Encryptions Contexts . . . . 14
6.10. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 13 6.10. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 14
6.11. Best Effort Encryption . . . . . . . . . . . . . . . . . . 14 6.11. Best Effort Encryption . . . . . . . . . . . . . . . . . . 15
7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 14 7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Basic Message Flow with Early Media and Identity . . . . . 15
8.1. Responder Identity . . . . . . . . . . . . . . . . . . . . 21 7.2. Basic Message Flow with Connected Identity (RFC 4916) . . 20
8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Basic Message Flow with STUN check for NAT Case . . . . . 24
8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.4. Continuity of Authentication . . . . . . . . . . . . . . . 22 8.1. Responder Identity . . . . . . . . . . . . . . . . . . . . 26
8.5. Short Authentication String . . . . . . . . . . . . . . . 23 8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.6. Limits of Identity Assertions . . . . . . . . . . . . . . 23 8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 25 8.4. Continuity of Authentication . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.5. Short Authentication String . . . . . . . . . . . . . . . 28
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8.6. Limits of Identity Assertions . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.7. Third Party Certificates . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.8. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 30
11.2. Informational References . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 28 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informational References . . . . . . . . . . . . . . . . . 32
Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 34
A.1. Forking and retargeting (R-FORK-RETARGET, A.1. Forking and retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 29 R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 34
A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 29 A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 34
A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 29 A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 34
A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 29 A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 34
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 29 A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 35
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 30 A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 35
A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 30 A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 35
A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 30 A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 35
A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 30 A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 35
A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 30 A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 36
A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 31 A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 36
A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 31 A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 36
A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 31 A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 36
A.14. Linkage between Keying Exchange and SIP Signaling A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 31 (R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 36
A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 31 A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 36
A.16. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 31 A.16. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 36
A.17. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 31 A.17. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 37
A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 32 A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 37
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 32 A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 37
A.20. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 32 A.20. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 37
A.21. Interworking with Intermediaries (R-TRANSCODER) . . . . . 32 A.21. Interworking with Intermediaries (R-TRANSCODER) . . . . . 37
A.22. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 32 A.22. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 37
A.23. R-ALLOW-RTP . . . . . . . . . . . . . . . . . . . . . . . 32 A.23. R-ALLOW-RTP . . . . . . . . . . . . . . . . . . . . . . . 37
A.24. R-HERFP . . . . . . . . . . . . . . . . . . . . . . . . . 32 A.24. R-HERFP . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 34
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 provides guidelines on how to establish SRTP [RFC3711] This draft provide 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
[I-D.ietf-avt-dtls-srtp]). [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 for extra security. The certificate fingerprints are sent in be used if the peers have them (thus reducing the need to trust
SDP over SIP as part of the offer/answer exchange. intermediaries). The certificate fingerprints are sent in SDP over
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 signalling. However, this
requires some form of integrity protection on the signalling. S/MIME requires some form of integrity protection on the signalling. 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] provides 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 provides
some protection against modification by attackers who are not in some protection against modification by attackers who are not in
skipping to change at page 7, line 6 skipping to change at page 8, line 6
but not active attacks on the signalling. In order to prevent active but not active attacks on the signalling. In order to prevent active
attacks on the signalling, Enhancements for Authenticated Identity attacks on the signalling, Enhancements for Authenticated Identity
Management in SIP [RFC4474] may be is used. When Bob receives the Management in SIP [RFC4474] may be is used. When Bob receives the
offer, the peers establish some number of DTLS connections (depending offer, the peers establish some number of DTLS connections (depending
on the number of media sessions) with mutual DTLS authentication on the number of media sessions) with mutual DTLS authentication
(i.e., both sides provide certificates) At this point, Bob can verify (i.e., both sides provide certificates) At this point, Bob can verify
that Alice's credentials offered in TLS match the fingerprint in the that Alice's credentials offered in TLS match the fingerprint in the
SDP offer, and Bob can begin sending media to Alice. Once Bob SDP offer, and Bob can begin sending media to Alice. Once Bob
accepts Alice's offer and sends an SDP answer to Alice, Alice can accepts Alice's offer and sends an SDP answer to Alice, Alice can
begin sending confidential media to Bob over the appropriate streams. begin sending confidential media to Bob over the appropriate streams.
Alice and Bob will verify the fingerprints from the certificates Alice and Bob will verify that the fingerprints from the certificates
received over the DTLS handshakes match with the fingerprints received over the DTLS handshakes match with the fingerprints
received in the SDP of the SIP signaling. This provides the security 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 property that Alice knows that the media traffic is going to Bob and
vice-versa without necessarily requiring global PKI certificates for vice-versa without necessarily requiring global PKI certificates for
Alice and Bob. (see Section 8 for detailed security analysis.) 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]
skipping to change at page 12, line 45 skipping to change at page 13, line 45
[I-D.ietf-avt-dtls-srtp] describes how to demultiplex STUN packets [I-D.ietf-avt-dtls-srtp] describes how to demultiplex STUN packets
from DTLS packets and SRTP 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 SBCs via "latching", as described in
[I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this [I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this
issue, if ICE is not being used and the DTLS handshake has not issue, if ICE is not being used and the DTLS handshake has not
completed, upon receiving the other side's SDP then the passive side completed, upon receiving the other side's SDP then the passive side
MUST do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis] MUST do a single unauthenticated STUN [RFC5389] connectivity check in
connectivity check in order to open up the appropriate pinhole. All order to open up the appropriate pinhole. All implementations MUST
implementations MUST be prepared to answer this request during the be prepared to answer this request during the handshake period even
handshake period even if they do not otherwise do ICE. However, the if they do not otherwise do ICE. However, the active side MUST
active side MUST proceed with the DTLS handshake as appopriate even proceed with the DTLS handshake as appopriate even if no such STUN
if no such STUN check is received and the passive MUST NOT wait for a check is received and the passive MUST NOT wait for a STUN answer
STUN answer before sending its ServerHello. before 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.
skipping to change at page 14, line 26 skipping to change at page 15, line 26
support [I-D.ietf-mmusic-sdp-capability-negotiation]. 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 which 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.
The example shows the SIP message flows where Alice acts as the 7.1. Basic Message Flow with Early Media and Identity
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,
especialy if Identity is not in use. Note that all other signaling especially if Identity is not in use.
is transported over TCP in 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) hello |
|<-----------------------------------| |<-----------------------------------|
|(4) hello | | |(4) hello | |
|----------------------------------->| |----------------------------------->|
| |(5) finished | | |(5) finished |
|<-----------------------------------| |<-----------------------------------|
| |(6) media | | |(6) media |
|<-----------------------------------| |<-----------------------------------|
|(7) finished | | |(7) finished | |
|----------------------------------->| |----------------------------------->|
| |(8) 200 OK | | |(8) 200 OK |
|<-----------------------------------| | <------------------|
| |(9) media | |(9) 200 OK | |
|----------------------------------->| |<----------------| |
|(10) ACK | | | |(10) media |
|<---------------------------------->|
|(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 which acts as Alice's identity
service. Note that Alice has requested to be either the active or service. Alice has requested to be either the active or passive
passive endpoint by specifying a=setup:actpass. Bob chooses to endpoint by specifying a=setup:actpass in the SDP. Bob chooses to
act as the DTLS client and will initiate the session. Also note act as the DTLS client and will initiate the session. Also note
that there is a fingerprint attribute in the SDP. This is that there is a fingerprint attribute in the SDP. This is
computed from Alice's self-signed certificate. computed from Alice's self-signed certificate. This offer
includes a default m-line offering RTP in case the answerer does
not support SRTP. However, the potential configuration utilizing
a transport of SRTP is preferred. See
[I-D.ietf-mmusic-sdp-capability-negotiation] 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
Via: SIP/2.0/TLS 192.0.2.101:5060;branch=z9hG4bK-0e53sadfkasldkfj
Max-Forwards: 70
Contact: <sip:alice@192.0.2.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
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
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 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
Supported: from-change
v=0 v=0
o=- 1181923068 1181923196 IN IP4 192.0.2.103 o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1 s=example1
c=IN IP4 192.0.2.103 c=IN IP4 ua1.example.com
a=setup:actpass a=setup:actpass
a=fingerprint: \ a=fingerprint: SHA-1 \
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
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.
a default m-line offering RTP in case the answerer does not
support SRTP. However, the potential configuration utilizing a
transport of SRTP is preferred. See
[I-D.ietf-mmusic-sdp-capability-negotiation] for more details on
the details of SDP capability negotiation.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.101:5060;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TCP 192.0.2.100:5060;branch=z9hG4bK-0e53244234324234
Via: SIP/2.0/TCP 192.0.2.103:6937;branch=z9hG4bK-0e5b7d3edb2add32
Max-Forwards: 70
Contact: <sip:alice@192.0.2.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
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
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
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert Identity-Info: https://example.com/cert
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
Supported: from-change
v=0 v=0
o=- 1181923068 1181923196 IN IP4 192.0.2.103 o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1 s=example1
c=IN IP4 192.0.2.103 c=IN IP4 ua1.example.com
a=setup:actpass a=setup:actpass
a=fingerprint: \ a=fingerprint: SHA-1 \
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
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 192.0.2.103: ClientHello messages would be sent to Alice: one to
6056 for RTP and another to port 6057 for RTCP, but only one arrow ua1.example.com:6056 for RTP and another to port 6057 for RTCP,
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, 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 (5): Certificate Bob -> Alice
skipping to change at page 18, line 28 skipping to change at page 19, line 29
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 which
contains the fingerprint for Bob's certificate. When Alice contains the fingerprint for Bob's certificate. Bob signals the
receives the message and validates the certificate presented in actual transport protocol configuration of SRTP over DTLS in the
Message 7. The endpoint now shows Alice that the call as secured. acfg parameter.
Note that in this case, Bob signals the actual transport protocol
configuration of SRTP over DTLS in the 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/TCP 192.0.2.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:192.0.2.104:5060;transport=TCP> Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
Supported: from-change
v=0 v=0
o=- 6418913922105372816 2105372818 IN IP4 192.0.2.104 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2 s=example2
c=IN IP4 192.0.2.104 c=IN IP4 ua2.example.com
a=setup:active a=setup:active
a=fingerprint:\ a=fingerprint: SHA-1 \
SHA-1 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 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=acfg:1 t=1 a=acfg:1 t=1
Message (9): RTP+RTCP Alice -> Bob Message (9): 200 OK Proxy -> Alice
Alice receives the message from her proxy and validates the
certificate presented in Message 7. The endpoint now shows Alice
that the call as secured.
Message (10): 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.
Message (10): ACK Alice -> Bob Message (11): ACK Alice -> Bob
Finally, Alice sends the SIP ACK to Bob. Finally, Alice sends the SIP ACK to Bob.
In this example, the DTLS handshake has already completed by the time 7.2. Basic Message Flow with Connected Identity (RFC 4916)
Alice receives Bob's 200 OK (8). Therefore, no STUN check is sent.
However, if Alice had a NAT, then Bob's ClientHello might get blocked The previous example did not show the use of RFC 4916 for connected
by that NAT, in which case Alice would send the the STUN check identity. The following example does:
described in Section 6.7.1 upon receiving the 200 OK, as shown below:
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
|<-----------------------------------|
|(9) ACK | |
|----------------------------------->|
| |(10) UPDATE |
| |<-----------------|
|(11) UPDATE | |
|<----------------| |
|(12) 200 OK | |
|---------------->| |
| |(13) 200 OK |
| |----------------->|
| |(14) media |
|<---------------------------------->|
The first 9 messages of this example are the same as before.
However, messages 10-13, performing the RFC 4916 UPDATE, are new.
Message (10): UPDATE Bob -> Proxy
Bob sends an RFC 4916 UPDATE towards Alice. This update contains
his fingerprint. Bob's UPDATE contains the same session
information that he provided in his 200 OK (message (8)). Note
that in principle an UPDATE here can be used to modify session
parameters. However, in this case it's being used solely to
confirm the fingerprint.
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 70
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: 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
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
Message (11): UPDATE Proxy -> Alice
This shows the UPDATE being relayed to Alice from Bob (and Alice's
proxy). Note that Bob's proxy has inserted an Identity and
Identity-Info header. As above, we only show one element for both
proxies for purposes of simplification. Alice verifies the
identity provided [Note: the actual identity signatures here are
incorrect and provided merely as examples.]
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 ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: 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
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
Message (12): 200 OK Alice -> Bob
This shows Alice's 200 OK response to Bob's UPDATE. Because Bob
has merely sent the same session parameters he sent in his 200 OK,
Alice can simply replay her view of the session parameters as
well.
SIP/2.0 200 OK
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua2.example.com
s=example1
c=IN IP4 ua2.example.com
a=setup:actpass
a=fingerprint: 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
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
7.3. Basic Message Flow with STUN check for NAT Case
In the previous examples, the DTLS handshake has already completed by
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
get blocked by that NAT, in which case Alice would send the the STUN
check described in Section 6.7.1 upon receiving the 200 OK, as shown
below:
Alice Proxies Bob Alice Proxies Bob
|(1) INVITE | | |(1) INVITE | |
|---------------->| | |---------------->| |
| |(2) INVITE | | |(2) INVITE |
| |----------------->| | |----------------->|
| |(3) hello | | |(3) hello |
| X<-----------------| | X<-----------------|
| |(4) 200 OK | | |(4) 200 OK |
|<-----------------------------------| |<-----------------------------------|
| (5) conn-check | | | (5) conn-check | |
|----------------------------------->| |----------------------------------->|
| |(6) conn-response | | |(6) conn-response |
|<-----------------------------------| |<-----------------------------------|
| |(7) hello | | |(7) hello (rtx) |
|<-----------------------------------| |<-----------------------------------|
|(8) hello (rtx) | | |(8) hello | |
|----------------------------------->| |----------------------------------->|
| |(9) finished | | |(9) finished |
|<-----------------------------------| |<-----------------------------------|
| |(10) media | | |(10) media |
|<-----------------------------------| |<-----------------------------------|
|(11) finished | | |(11) finished | |
|----------------------------------->| |----------------------------------->|
| |(11) media | | |(11) media |
|----------------------------------->| |----------------------------------->|
|(12) ACK | | |(12) ACK | |
|----------------------------------->| |----------------------------------->|
The messages here are the same as in the previous example, with the The messages here are the same as in the first example (for
following three new messages: simplicity this example omits an UPDATE), with the following three
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
skipping to change at page 21, line 18 skipping to change at page 26, line 18
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 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
[RFC3280] 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 which 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 each side of the connection can verify the
integrity of the SDP received from the other side, then the DTLS 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
skipping to change at page 22, line 10 skipping to change at page 27, line 10
it was from so that Alice's User Agent could indicate to Alice that it was from so that Alice's User Agent could indicate to Alice that
there was a secure phone call to Bob. [RFC4916] defines an approach there was a secure phone call to Bob. [RFC4916] defines an approach
for a UA to supply its identity to its peer UA and for this identity for a UA to supply its identity to its peer UA and for this identity
to be signed by an authentication service. For example, using this to be signed by an authentication service. For example, using this
approach, Bob sends an answer, then immediately follows up with an approach, Bob sends an answer, then immediately follows up with an
UPDATE that includes the fingerprint and uses the SIP Identity UPDATE that includes the fingerprint and uses the SIP Identity
mechanism to assert that the message is from Bob@example.com. The mechanism to assert that the message is from Bob@example.com. The
downside of this approach is that it requires the extra round trip of downside of this approach is that it requires the extra round trip of
the UPDATE. However, it is simple and secure even when not all of the UPDATE. However, it is simple and secure even when not all of
the proxies are trusted. In this example, Bob only needs to trust the proxies are trusted. In this example, Bob only needs to trust
his proxy. Answerers SHOULD use this UPDATE mechanism. his proxy. Offerers SHOULD support this 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
skipping to change at page 23, line 33 skipping to change at page 28, line 34
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 [I-D.zimmermann-avt-zrtp] includes Short Authentication String
mode in which a unique per-connection bitstring is generated as part mode in which a unique per-connection bitstring is generated as part
of the cryptographic handshake. The SAS can be as short as 25 bits of the cryptographic handshake. The SAS can be as short as 25 bits
and so is somewhat easier to read. DTLS does not natively support and so is somewhat easier to read. DTLS does not natively support
this mode. Based on the level of deployment interest a TLS extension this mode. Based on the level of deployment interest a TLS extension
[RFC3546] could provide support for it. Note that SAS schemes only [RFC4366] 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 signalling, 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 signalling. There are two
important cases to note here: important cases to note here:
skipping to change at page 24, line 16 skipping to change at page 29, line 16
'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 PSTN
elements are trusted to assert their phone number correctly and elements are trusted to assert their phone number correctly and
that there is no real concept of a given entity being that there is no real concept of a given entity being
authoritative for some number space. authoritative for some number space.
In both of these cases, the assurances taht 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 signalling 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. e.g. If
the peer's identity is sip:+17005551008@chicago.example.com, it is 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
skipping to change at page 24, line 47 skipping to change at page 29, line 47
signature on the modified message. Alternately, the middlebox may be signature on the modified message. Alternately, the middlebox may be
able to sign with some other identity that it is permitted to assert. able to sign with some other identity that it is permitted to assert.
Otherwise, the recipient cannot rely on the RFC 4474 Identity Otherwise, the recipient cannot rely on the RFC 4474 Identity
assertion and the UA MUST NOT indicate to the user that a secure call assertion and the UA MUST NOT indicate to the user that a secure call
has been established to the claimed identity. Implementations which has been established to the claimed identity. Implementations which
are configured to only establish secure calls SHOULD terminate the are configured to only establish secure calls SHOULD terminate the
call in this case. 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, the is provided. While this is still superior to previous mechanisms,
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. Perfect Forward Secrecy 8.7. Third Party Certificates
This specification does not depend on the certificates being held by
endpoints being independently verifiable (e.g., being issued by a
trusted third party.) However, there is no limitation on such
certificates being used. Aside from the difficulty of obtaining such
certificates, it is not clear what identities those certificates
would contain---RFC 3261 specifies a convention for S/MIME
certificates which could also be used here, but that has seen only
minimal deployment. However, in closed or semi-closed contexts where
such a convention can be established, third party certificates can
reduce the reliance on trusting even proxies in the endpoint's
domains.
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.
skipping to change at page 26, line 5 skipping to change at page 31, line 19
[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
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
X.509 Public Key Infrastructure Certificate and Housley, R., and W. Polk, "Internet X.509 Public Key
Certificate Revocation List (CRL) Profile", RFC 3280, Infrastructure Certificate and Certificate Revocation List
April 2002. (CRL) Profile", RFC 5280, May 2008.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[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,
skipping to change at page 26, line 35 skipping to change at page 31, line 49
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.ietf-behave-rfc3489bis] [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
"Session Traversal Utilities for (NAT) (STUN)", October 2008.
draft-ietf-behave-rfc3489bis-18 (work in progress),
July 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.
[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,
skipping to change at page 27, line 21 skipping to change at page 32, line 34
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] [I-D.zimmermann-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", Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-10 (work in progress), draft-zimmermann-avt-zrtp-14 (work in progress),
October 2008. February 2009.
[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-05 (work in progress), draft-ietf-avt-dtls-srtp-06 (work in progress),
September 2008. October 2008.
[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 Management "Requirements and Analysis of Media Security Management
Protocols", draft-ietf-sip-media-security-requirements-07 Protocols", draft-ietf-sip-media-security-requirements-09
(work in progress), June 2008. (work in progress), January 2009.
[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-09 (work in draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), July 2008. progress), July 2008.
[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.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003. 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] [I-D.wing-sipping-srtp-key]
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",
draft-wing-sipping-srtp-key-03 (work in progress), draft-wing-sipping-srtp-key-04 (work in progress),
February 2008. October 2008.
[I-D.wing-avt-dtls-srtp-key-transport] [I-D.wing-avt-dtls-srtp-key-transport]
Wing, D., "DTLS-SRTP Key Transport", Wing, D., "DTLS-SRTP Key Transport",
draft-wing-avt-dtls-srtp-key-transport-02 (work in draft-wing-avt-dtls-srtp-key-transport-02 (work in
progress), July 2008. progress), July 2008.
[I-D.ietf-mmusic-media-path-middleboxes] [I-D.ietf-mmusic-media-path-middleboxes]
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",
draft-ietf-mmusic-media-path-middleboxes-01 (work in draft-ietf-mmusic-media-path-middleboxes-01 (work in
progress), July 2008. progress), July 2008.
[I-D.ietf-sip-ua-privacy] [I-D.ietf-sip-ua-privacy]
Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Munakata, M., Schubert, S., and T. Ohba, "UA-Driven
Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-02 Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-05
(work in progress), July 2008. (work in progress), February 2009.
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 (R-FORK-RETARGET, R-BEST-SECURE, A.1. Forking and retargeting (R-FORK-RETARGET, R-BEST-SECURE,
R-DISTINCT) R-DISTINCT)
skipping to change at page 34, line 4 skipping to change at line 1616
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
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
Full 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.
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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 64 change blocks. 
169 lines changed or deleted 358 lines changed or added

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