draft-ietf-sip-dtls-srtp-framework-01.txt   draft-ietf-sip-dtls-srtp-framework-02.txt 
SIP J. Fischl SIP J. Fischl
Internet-Draft CounterPath Corporation Internet-Draft CounterPath Corporation
Expires: August 26, 2008 H. Tschofenig Intended status: Standards Track H. Tschofenig
Nokia Siemens Networks Expires: January 14, 2009 Nokia Siemens Networks
E. Rescorla E. Rescorla
Network Resonance RTFM, Inc.
February 23, 2008 July 13, 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-01.txt draft-ietf-sip-dtls-srtp-framework-02.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 August 26, 2008. This Internet-Draft will expire on January 14, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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. The key
on the SIP identity mechanism to ensure the integrity of the exchange travels along the media path as opposed to the signaling
fingerprint attribute. The key exchange travels along the media path path. The SIP Identity mechanism can be used to protect the
as opposed to the signaling path. integrity of the fingerprint attribute from modification by
intermediate proxies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 7 5. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 8
6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 9 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 10
6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 9 6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 10
6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 10 6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 11
6.5. Session Modification . . . . . . . . . . . . . . . . . . . 10 6.5. Session Modification . . . . . . . . . . . . . . . . . . . 11
6.6. ICE Interaction . . . . . . . . . . . . . . . . . . . . . 10 6.6. ICE Interaction . . . . . . . . . . . . . . . . . . . . . 11
6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.8. Conference Servers and Shared Encryptions Contexts . . . . 11 6.8. Conference Servers and Shared Encryptions Contexts . . . . 12
6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 12 6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 12
6.10. Best Effort Encryption . . . . . . . . . . . . . . . . . . 12 6.10. Best Effort Encryption . . . . . . . . . . . . . . . . . . 13
7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 12 7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Responder Identity . . . . . . . . . . . . . . . . . . . . 20
8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. Single-sided Verification . . . . . . . . . . . . . . . . 19 8.4. Continuity of Authentication . . . . . . . . . . . . . . . 22
8.5. Continuity of Authentication . . . . . . . . . . . . . . . 19 8.5. Short Authentication String . . . . . . . . . . . . . . . 22
8.6. Short Authentication String . . . . . . . . . . . . . . . 19 8.6. Limits of Identity Assertions . . . . . . . . . . . . . . 22
8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 20 8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informational References . . . . . . . . . . . . . . . . . 22 11.2. Informational References . . . . . . . . . . . . . . . . . 25
Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 24 Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 28
A.1. Forking and retargeting (R-FORK-RETARGET, A.1. Forking and retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 24 R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 28
A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 24 A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 28
A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 24 A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 28
A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 24 A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 28
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 24 A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 28
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 24 A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 28
A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 25 A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 29
A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 25 A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 29
A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 25 A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 29
A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 25 A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 29
A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 25 A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 29
A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 26 A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 30
A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 26 A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 30
A.14. Linkage between Keying Exchange and SIP Signaling A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 26 (R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 30
A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 26 A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 30
A.16. Adversary Model (R-SIG-MEDIA) . . . . . . . . . . . . . . 26 A.16. Adversary Model (R-SIG-MEDIA) . . . . . . . . . . . . . . 30
A.17. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 26 A.17. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 30
A.18. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 26 A.18. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 30
A.19. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 26 A.19. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 30
A.20. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 27 A.20. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 31
A.21. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 27 A.21. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 31
A.22. Interworking with Intermediaries (R-TRANSCODER) . . . . . 27 A.22. Interworking with Intermediaries (R-TRANSCODER) . . . . . 31
A.23. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 27 A.23. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 33
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 security This draft provides guidelines on how to establish SRTP [RFC3711]
using extensions to DTLS (see [I-D.ietf-avt-dtls-srtp]). security using an extension 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 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 for extra security. The certificate fingerprints are sent in
SDP over SIP as part of the offer/answer exchange. The SIP Identity SDP over SIP as part of the offer/answer exchange.
mechanism [RFC4474] is used to provide integrity for the
fingerprints.
This DTLS-SRTP approach differs from previous attempts to secure The fingerprint mechanism allows one side of the connection to verify
media traffic where the authentication and key exchange protocol that the certificate presented in the DTLS handshake matches the
(e.g., MIKEY [RFC3830]) is piggybacked in the signaling message certificate used by the party in the signalling. However, this
exchange. With DTLS-SRTP, establishing the protection of the media requires some form of integrity protection on the signalling. S/MIME
traffic between the endpoints is done by the media endpoints without signatures, as described in RFC 3261, or SIP Identity, as described
involving the SIP/SDP communication. It allows RTP and SIP to be in [RFC4474] provides the highest level of security because they are
used in the usual manner when there is no encrypted media. not susceptible to modification by malicious intermediaries.
However, even hop-by-hop security such as provided by SIPS provides
some protection against modification by attackers who are not on the
signalling path.
This approach differs from previous attempts to secure media traffic
where the authentication and key exchange protocol (e.g., MIKEY
[RFC3830]) is piggybacked in the signaling message exchange. With
DTLS-SRTP, establishing the protection of the media traffic between
the endpoints is done by the media endpoints without involving the
SIP/SDP communication. It allows RTP and SIP to be 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
for the media. This also allows the media sessions to be changed, for the media. This also allows the media sessions to be changed,
re-keyed, and otherwise modified after the initial SIP signaling re-keyed, and otherwise modified after the initial SIP signaling
skipping to change at page 6, line 10 skipping to change at page 6, line 41
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 binds
integrity protected using the identity mechanism defined in the DTLS key exchange in the media plan to the signaling plane.
Enhancements for Authenticated Identity Management in SIP [RFC4474].
When Bob receives the offer, Bob establishes a mutually authenticated The fingerprint alone protects against active attacks on the media
DTLS connection with Alice. At this point Bob can begin sending but not active attacks on the signalling. In order to prevent active
media to Alice. Once Bob accepts Alice's offer and sends an SDP attacks on the signalling, in Enhancements for Authenticated Identity
answer to Alice, Alice can begin sending confidential media to Bob. Management in SIP [RFC4474] is used. When Bob receives the offer,
Alice and Bob will verify the fingerprints from the certificates Bob establishes a mutually authenticated DTLS connection with Alice.
received over the DTLS handshakes match with the fingerprints At this point Bob can begin sending media to Alice. Once Bob accepts
received in the SDP of the SIP signaling. This provides the security Alice's offer and sends an SDP answer to Alice, Alice can begin
property that Alice knows that the media traffic is going to Bob and sending confidential media to Bob. Alice and Bob will verify the
vice-versa without necessarily requiring global PKI certificates for fingerprints from the certificates received over the DTLS handshakes
Alice and Bob. 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., Security
Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567]
combined with MIKEY [RFC3830] for authentication and key exchange), combined with MIKEY [RFC3830] for authentication and key exchange),
this specification is motivated as follows: this specification is motivated as follows:
o TLS will be used to offer security for connection-oriented media. o TLS will be used to offer security for connection-oriented media.
The design of TLS is well-known and implementations are widely The design of TLS is well-known and implementations are widely
available. available.
o This approach deals with forking and early media without requiring o This approach deals with forking and early media without requiring
support for PRACK [RFC3262] while preserving the important support for PRACK [RFC3262] while preserving the important
security property of allowing the offerer to choose keying security property of allowing the offerer to choose keying
material for encrypting the media. material for encrypting the media.
o The establishment of security protection for the media path is o The establishment of security protection for the media path is
also provided along the media path and not over the signaling also provided along the media path and not over the signaling
path. In many deployment scenarios, the signaling and media path. In many deployment scenarios, the signaling and media
traffic travel along a different path through the network. traffic travel along a different path through the network.
o This solution works even when the SIP proxies downstream of the o When RFC 4474 Identity is used, this solution works even when the
identity service are not trusted. There is no need to reveal keys SIP proxies downstream of the identity service are not trusted.
in the SIP signaling or in the SDP message exchange. In order for There is no need to reveal keys in the SIP signaling or in the SDP
SDES and MIKEY to provide this security property, they require message exchange. In order for SDES and MIKEY to provide this
distribution of certificates to the endpoints that are signed by security property, they require distribution of certificates to
well known certificate authorities. SDES further requires that the endpoints that are signed by well known certificate
the endpoints employ S/MIME to encrypt the keying material. authorities. SDES further requires that 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 [I-D.ietf-avt- SIP and RTP usage are minimal even when DTLS-SRTP
dtls-srtp] is used. [I-D.ietf-avt-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
skipping to change at page 8, line 12 skipping to change at page 8, line 43
The generation of public/private key pairs is relatively expensive. The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session. Endpoints are not required to generate certificates for each session.
The offer/answer model, defined in [RFC3264], is used by protocols The offer/answer model, defined in [RFC3264], is used by protocols
like the Session Initiation Protocol (SIP) [RFC3261] to set up like the Session Initiation Protocol (SIP) [RFC3261] to set up
multimedia sessions. In addition to the usual contents of an SDP multimedia sessions. In addition to the usual contents of an SDP
[RFC4566] message, each media description ('m' line and associated [RFC4566] message, each media description ('m' line and associated
parameters) will also contain several attributes as specified in parameters) will also contain several attributes as specified in
[I-D.ietf-avt-dtls-srtp], [RFC4145] and [RFC4572]. [I-D.ietf-avt-dtls-srtp], [RFC4145] and [RFC4572].
The endpoint MUST use the setup attribute defined in [RFC4145]. The
endpoint which is the offerer MUST use the setup attribute value of
setup:actpass and be prepared to receive a client_hello before it
receives the answer. The answerer SHOULD use the setup attribute
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
specified in [RFC4572].
The certificate presented during the DTLS handshake MUST match the
fingerprint exchanged via the signaling path in the SDP. The
security properties of this mechanism are described in Section 8.
If the fingerprint does not match the hashed certificate then the
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
the certificate that the endpoint wants to use. The SIP message the certificate that the endpoint wants to use. The SIP message
containing the offer is sent to the offerer's sip proxy over an containing the offer SHOULD be sent to the offerer's sip proxy over
integrity protected channel which will add an identity header an integrity protected channel which SHOULD add an identity header
according to the procedures outlined in [RFC4474]. When the far according to the procedures outlined in [RFC4474]. When the far
endpoint receives the SIP message it can verify the identity of the endpoint receives the SIP message it can verify the identity of the
sender using the identity header. Since the identity header is a sender using the identity header. Since the identity header is a
digital signature across several SIP headers, in addition to the digital signature across several SIP headers, in addition to the
bodies of the SIP message, the receiver can also be certain that the bodies of the SIP message, the receiver can also be certain that the
message has not been tampered with after the digital signature was message has not been tampered with after the digital signature was
applied and added to the SIP message. applied and added to the SIP message.
The far endpoint (answerer) may now establish a mutually The far endpoint (answerer) may now establish a mutually
authenticated DTLS association to the offerer. After completing the authenticated DTLS association to the offerer. After completing the
skipping to change at page 9, line 20 skipping to change at page 9, line 33
the offerer containing the answerer's certificate fingerprint. At the offerer containing the answerer's certificate fingerprint. At
this point the offerer can accept or reject the peer's certificate this point the offerer can accept or reject the peer's certificate
and the offerer can indicate to the end user that the media is and the offerer can indicate to the end user that the media is
secured. secured.
Note that the entire authentication and key exchange for securing the Note that the entire authentication and key exchange for securing the
media traffic is handled in the media path through DTLS. The media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate signaling path is only used to verify the peers' certificate
fingerprints. fingerprints.
The offer and answer MUST be conform to the following requirements.
o The endpoint MUST use the setup attribute defined in [RFC4145].
The endpoint which is the offerer MUST use the setup attribute
value of setup:actpass and be prepared to receive a client_hello
before it receives the answer. The answerer SHOULD use the setup
attribute value of setup:active and will send the client_hello in
the media path.
o The endpoint MUST NOT use the connection attribute defined in
[RFC4145].
o The endpoint MUST use the certificate fingerprint attribute as
specified in [RFC4572].
o The certificate presented during the DTLS handshake MUST match the
fingerprint exchanged via the signaling path in the SDP. The
security properties of this mechanism are described in Section 8.
o If the fingerprint does not match the hashed certificate then the
endpoint MUST tear down the media session immediately.
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 DTLS-SRTP does not provide anonymous calling. However, if care is
not taken, DTLS-SRTP may allow deanonymizing an otherwise anonymous not taken, DTLS-SRTP may allow deanonymizing an otherwise anonymous
call. The following procedures should be used to prevent call. When anonymous calls are being made, the following procedures
deanonymization. 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.4.
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. Note that following this recommendation is not an anonymous call. Note that following this recommendation is not
sufficient to provide anonymization. sufficient to provide anonymization.
skipping to change at page 11, line 11 skipping to change at page 11, line 46
handshake even if there are multiple valid candidate pairs. Note handshake even if there are multiple valid candidate pairs. Note
that this may mean adjusting the endpoint IP addresses if the that this may mean adjusting the endpoint IP addresses if the
selected candidate pair shifts, just as if the DTLS packets were an selected candidate pair shifts, just as if the DTLS packets were an
ordinary media stream. ordinary media stream.
Note that STUN packets are sent directly over UDP, not over DTLS. Note that STUN packets are sent directly over UDP, not over DTLS.
[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.
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 [I-D.ietf- interaction with SBCs via "latching", as described in
mmusic-media-path-middleboxes]. In order to avoid this issue, if ICE [I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this
is not being used, then the passive side MUST do a single issue, if ICE is not being used and the DTLS handshake has not
unauthenticad STUN [I-D.ietf-behave-rfc3489bis] connectivity check in completed, upon receiving the other side's then the passive side MUST
order to open up the appropriate pinhole. All implementations MUST do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis]
be prepared to answer this request during the handshake period even connectivity check in order to open up the appropriate pinhole. All
if they do not otherwise do ICE. 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 47 skipping to change at page 12, line 34
to encrypt the output for all speakers instead of once per to encrypt the output for all speakers instead of once per
participant. participant.
This shared encryption context approach is not possible under this This shared encryption context approach is not possible under this
specification because each DTLS handshake establishes fresh keys specification because each DTLS handshake establishes fresh keys
which are not completely under the control of either side. However, which are not completely under the control of either side. However,
it is argued that the effort to encrypt each RTP packet is small it is argued that the effort to encrypt each RTP packet is small
compared to the other tasks performed by the conference server such compared to the other tasks performed by the conference server such
as the codec processing. as the codec processing.
Future extensions such as [I-D.mcgrew-srtp-ekt] or [I-D.wing-avt- Future extensions such as [I-D.mcgrew-srtp-ekt] or
dtls-srtp-key-transport] could be used to provide this functionality [I-D.wing-avt-dtls-srtp-key-transport] could be used to provide this
in concert with the mechanisms described in this specification. functionality 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 [I-D.ietf-avt-dtls- specifically tuned for that purpose. DTLS-SRTP
srtp], has been defined to provide for the negotiation of SRTP [I-D.ietf-avt-dtls-srtp], has been defined to provide for the
transport using a DTLS connection, thus allowing the performance negotiation of SRTP transport using a DTLS connection, thus allowing
benefits of SRTP with the easy key management of DTLS. The ability the performance benefits of SRTP with the easy key management of
to reuse existing SRTP software and hardware implementations may in DTLS. The ability to reuse existing SRTP software and hardware
some environments provide another important motivation for using implementations may in some environments provide another important
DTLS-SRTP instead of RTP over DTLS. Implementations of this motivation for using DTLS-SRTP instead of RTP over DTLS.
specification SHOULD support DTLS-SRTP [I-D.ietf-avt-dtls-srtp]. Implementations of this 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 13, line 10 skipping to change at page 14, line 10
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) conn-check | | |(3) hello |
|<-----------------------------------|
| |(4) hello |
|<-----------------------------------| |<-----------------------------------|
| |(5) conn-response | |(4) hello | |
|----------------------------------->|
|(6) hello | |
|----------------------------------->| |----------------------------------->|
| |(7) finished | | |(5) finished |
|<-----------------------------------| |<-----------------------------------|
| |(8) media | | |(6) media |
|<-----------------------------------| |<-----------------------------------|
|(9) finished | | |(7) finished | |
|----------------------------------->| |----------------------------------->|
| |(10) 200 OK | | |(8) 200 OK |
|<-----------------------------------| |<-----------------------------------|
| |(11) media | | |(9) media |
|----------------------------------->| |----------------------------------->|
|(12) ACK | | |(10) 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. Note that Alice has requested to be either the active or
passive endpoint by specifying a=setup:actpass. Bob chooses to passive endpoint by specifying a=setup:actpass. Bob chooses to
act as the DTLS server and will initiate the session. Also note act as the DTLS server and will initiate the session. Also note
skipping to change at page 14, line 39 skipping to change at page 15, line 39
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 [I-D.ietf-mmusic-sdp- transport of SRTP is preferred. See
capability-negotiation] for more details on the details of SDP [I-D.ietf-mmusic-sdp-capability-negotiation] for more details on
capability negotiation. 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.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 15, line 36 skipping to change at page 16, line 36
c=IN IP4 192.168.1.103 c=IN IP4 192.168.1.103
a=setup:actpass a=setup:actpass
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): ICE connectivity-check Bob -> Alice Message (3): ClientHello 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 (5): ICE connectivity-check response Alice -> Bob Message (4): ServerHello+Certificate 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 (7): Certificate Bob -> Alice Message (5): Certificate Bob -> Alice
Bob sends a Certificate, ClientKeyExchange, CertificateVerify, Bob sends a Certificate, ClientKeyExchange, CertificateVerify,
change_cipher_spec and Finished for both RTP and RTCP change_cipher_spec and Finished for both RTP and RTCP
associations. Again note that Bob uses the same server associations. Again note that Bob uses the same server
certificate for both associations. certificate for both associations.
Message (8): Early Media Bob -> Alice Message (6): Early Media Bob -> Alice
At this point, Bob can begin sending early media (RTP and RTCP) to At this point, Bob can begin sending early media (RTP and RTCP) to
Alice. Note that Alice can't yet trust the media since the Alice. Note that Alice can't yet trust the media since the
fingerprint has not yet been received. This lack of trusted, fingerprint has not yet been received. This lack of trusted,
secure media is indicated to Alice. secure media is indicated to Alice.
Message (9): 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 (10): 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. When Alice
receives the message and validates the certificate presented in receives the message and validates the certificate presented in
Message 7. 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
skipping to change at page 17, line 27 skipping to change at page 18, line 27
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=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=acfg:1 t=1 a=acfg:1 t=1
Message (11): RTP+RTCP Alice -> Bob Message (9): 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 (12): ACK Alice -> Bob Message (10): 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
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.6 upon receiving the 200 OK, as shown below:
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
| X<-----------------|
| |(4) 200 OK |
|<-----------------------------------|
| (5) conn-check | |
|----------------------------------->|
| |(6) conn-response |
|<-----------------------------------|
| |(7) hello |
|<-----------------------------------|
|(8) hello (rtx) | |
|----------------------------------->|
| |(9) finished |
|<-----------------------------------|
| |(10) media |
|<-----------------------------------|
|(11) finished | |
|----------------------------------->|
| |(11) media |
|----------------------------------->|
|(12) ACK | |
|----------------------------------->|
The messages here are the same as in the previous example, with the
following three new messages:
Message (5): STUN connectivity-check Alice -> Bob
Section 6.6 describes an approach to avoid an SBC interaction
issue where the endpoints do not support ICE. Alice (the passive
endpoint) sends a STUN connectivity check to Bob. This opens a
pinhole in Alice's NAT/firewall.
Message (6): STUN connectivity-check response Bob -> Alice
Bob (the active endpoint) sends a response to the STUN
connectivity check (Message 3) to Alice. This tells Alice that
her connectivity check has succeeded and she can stop the
retransmit state machine.
Message (7): Hello (retransmit) Bob -> Alice
Bob retransmits his DTLS ClientHello which now passes through the
pinhole created in Alice's firewall. At this point, the DTLS
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 [RFC3280] 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 as each side of the connection can verify confidentiality). As long each side of the connection can verify the
the integrity of the SDP INVITE then the DTLS handshake cannot be integrity of the SDP received from the other side, then the DTLS
hijacked via a man-in-the-middle attack. This integrity protection handshake cannot be hijacked via a man-in-the-middle attack. This
is easily provided by the caller to the callee (see Alice to Bob in integrity protection is easily provided by the caller to the callee
Section 7) via the SIP Identity [RFC4474] mechanism. However, it is (see Alice to Bob in Section 7) via the SIP Identity [RFC4474]
less straightforward for the responder. mechanism. Other mechanisms, such as the S/MIME mechanism described
in RFC 3261, or the mechanisms described in
[I-D.wing-sip-identity-media] or [I-D.fischer-sip-e2e-sec-media],
could also serve this purpose.
Ideally Alice would want to know that Bob's SDP had not been tampered While this mechanism can still be used without such integrity
with and who it was from so that Alice's User Agent could indicate to mechanisms, the security provided is limited to defense against
Alice that there was a secure phone call to Bob. This is known as the passive attack by intermediaries. An active attack on the signaling
SIP connected party problem and is still a topic of ongoing work in plus an active attack on the media plane can allow an attacker to
the SIP community. In the meantime, there are several approaches attack the connection (R-SIG-MEDIA in the notation of
that can be used to mitigate this problem: Use UPDATE, Use SIPS, Use [I-D.ietf-sip-media-security-requirements]).
S/MIME, Single Sided Verification, or use human-read Short
Authentication String (SAS) to validate the certificates. Each one
is discussed here followed by the security implications of that
approach.
8.1. UPDATE 8.1. Responder Identity
[RFC4916] defines an approach for a UA to supply its identity to its SIP Identity does not support signatures in responses. Ideally Alice
peer UA and for this identity to be signed by an authentication would want to know that Bob's SDP had not been tampered with and who
service. For example, using this approach, Bob sends an answer, then it was from so that Alice's User Agent could indicate to Alice that
immediately follows up with an UPDATE that includes the fingerprint there was a secure phone call to Bob. [RFC4916] defines an approach
and uses the SIP Identity mechanism to assert that the message is for a UA to supply its identity to its peer UA and for this identity
from Bob@example.com. The downside of this approach is that it to be signed by an authentication service. For example, using this
requires the extra round trip of the UPDATE. However, it is simple approach, Bob sends an answer, then immediately follows up with an
and secure even when not all of the proxies are trusted. In this UPDATE that includes the fingerprint and uses the SIP Identity
example, Bob only needs to trust his proxy. Answerers SHOULD send mechanism to assert that the message is from Bob@example.com. The
use this UPDATE mechanisms. 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 proxies are trusted. In this example, Bob only needs to trust
his proxy. Answerers SHOULD use this UPDATE mechanisms.
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
cases, no integrity is provided for the fingerprint from Bob to
Alice. In this approach, an attacker that was on the signaling path
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
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
one side can detect this attack means that in most cases where Alice
and Bob both wish the communications to be encrypted there is not a
problem. Keep in mind that in any of the possible approaches Bob
could always reveal the media that was received to anyone. We are
making the assumption that Bob also wants secure communications. In
this do nothing case, Bob knows the media has not been tampered with
or intercepted by a third party and that it is from
Alice@example.com. Alice knows that she is talking to someone and
that whoever that is has probably checked that the media is not being
intercepted or tampered with. This approach is certainly less than
ideal but very usable for many situations.
8.2. SIPS 8.2. SIPS
In this approach, the signaling is protected by TLS from hop to hop. If SIP Identity is not used, but the signaling is protected by SIPS,
As long as all proxies are trusted, this provides integrity for the the security guarantees are weaker, but some security is still
fingerprint. It does not provide a strong assertion of who Alice is provided as long as all proxies are trusted, this provides integrity
communicating with. However, as much as the target domain can be for the fingerprint. It does not provide a strong assertion of who
trusted to correctly populate the From header field value, Alice can Alice is communicating with. However, as much as the target domain
use that. The security issue with this approach is that if one of can be trusted to correctly populate the From header field value,
the Proxies wished to mount a man-in-the-middle attack, it could Alice can use that. The security issue with this approach is that if
convince Alice that she was talking to Bob when really the media was one of the Proxies wished to mount a man-in-the-middle attack, it
flowing through a man in the middle media relay. However, this could convince Alice that she was talking to Bob when really the
attack could not convince Bob that he was taking to Alice. media was flowing through a man in the middle media relay. However,
this attack could not convince Bob that he was taking to Alice.
8.3. S/MIME 8.3. S/MIME
RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that
could be used to sign that the fingerprint was from Bob. This would could be used to sign that the fingerprint was from Bob. This would
be secure. However, so far there have been no deployments of S/MIME be secure. However, so far there have been no deployments of S/MIME
for SIP. for SIP.
8.4. Single-sided Verification 8.4. Continuity of Authentication
In this approach, no integrity is provided for the fingerprint from
Bob to Alice. In this approach, an attacker that was on the
signaling path 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 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 one side can detect this attack means that
in most cases where Alice and Bob both wish the communications to be
encrypted there is not a problem. Keep in mind that in any of the
possible approaches Bob could always reveal the media that was
received to anyone. We are making the assumption that Bob also wants
secure communications. In this do nothing case, Bob knows the media
has not been tampered with or intercepted by a third party and that
it is from Alice@example.com. Alice knows that she is talking to
someone and that whoever that is has probably checked that the media
is not being intercepted or tampered with. This approach is
certainly less than ideal but very usable for many situations.
8.5. Continuity of Authentication
One desirable property of a secure media system is to provide One desirable property of a secure media system is to provide
continuity of authentication: being able to ensure cryptographically continuity of authentication: being able to ensure cryptographically
that you are talking to the same person as before. With DTLS, that you are talking to the same person as before. With DTLS,
continuity of authentication is achieved by having each side use the continuity of authentication is achieved by having each side use the
same public key/self-signed certificate for each connection (at least same public key/self-signed certificate for each connection (at least
with a given peer entity). It then becomes possible to cache the with a given peer entity). It then becomes possible to cache the
credential (or its hash) and verify that it is unchanged. Thus, once credential (or its hash) and verify that it is unchanged. Thus, once
a single secure connection has been established, an implementation a single secure connection has been established, an implementation
can establish a future secure channel even in the face of future can establish a future secure channel even in the face of future
insecure signalling. insecure signalling.
In order to enable continuity of authentication, implementations In order to enable continuity of authentication, implementations
SHOULD attempt to keep a constant long-term key. Verifying SHOULD attempt to keep a constant long-term key. Verifying
implementations SHOULD maintain a cache of the key used for each peer implementations SHOULD maintain a cache of the key used for each peer
identity and alert the user if that key changes. identity and alert the user if that key changes.
8.6. Short Authentication String 8.5. Short Authentication String
An alternative available to Alice and Bob is to use human speech to An alternative available to Alice and Bob is to use human speech to
verify each others' identity and then to verify each others' verify each others' identity and then to verify each others'
fingerprints also using human speech. Assuming that it is difficult fingerprints also using human speech. Assuming that it is difficult
to impersonate another's speech and seamlessly modify the audio to impersonate another's speech and seamlessly modify the audio
contents of a call, this approach is relatively safe. It would not contents of a call, this approach is relatively safe. It would not
be effective if other forms of communication were being used such as be effective if other forms of communication were being used such as
video or instant messaging. DTLS supports this mode of operation. video or instant messaging. DTLS supports this mode of operation.
The minimal secure fingerprint length is around 64 bits. The minimal secure fingerprint length is around 64 bits.
ZRTP [I-D.zimmermann-avt-zrtp] includes Short Authentication String ZRTP [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, however it would be straightforward to add one as a TLS this mode, however it would be straightforward to add one as a TLS
extension [RFC3546]. extension [RFC3546].
8.6. Limits of Identity Assertions
When RFC 4474 is used to bind the media keying material to the SIP
signalling, the assurances about the provenance and security of the
media are only as good as those for the signalling. There are two
important cases to note here:
o RFC 4474 assumes that the proxy with the certificate "example.com"
controls the namespace "example.com". Therefore the RFC 4474
authentication service which is authoritative for a given
namespace can control which user is assigned each name. Thus, the
authentication service can take an address formerly assigned to
Alice and transfer it to Bob. This is an intentional design
feature of RFC 4474 and a direct consequence of the SIP namespace
architecture.
o When phone number URIs (e.g.,
'sip:+17005551008@chicago.example.com') are used, there is no
structural reason to trust that the domain name is authoritative
for a given phone number, although individual proxies and UAs may
have private arrangements that allow them to trust other domains.
This is a structural issue in that PSTN elements are trusted to
assert their phone number correctly and that there is no real
concept of a given entity being authoritative for some number
space.
In both of these cases, the assurances of DTLS-SRTP provides in terms
of data origin integrity and confidentiality are necessarily no
better than SIP provides for signalling integrity when RFC 4474 is
used. Implementors should therefore take care not to indicate
misleading peer identity information in the user interface. e.g. If
the peer's identity is sip:+17005551008@chicago.example.com, it is
not sufficient to display that the identity of the peer as
+17005551008, unless there is some policy that states that the domain
"chicago.example.com" is trusted to assert E.164 numbers. In cases
where the UA can determine that the peer identity is clearly an E.164
number, it may be less confusing to simply identify the call as
encrypted but to an unknown peer.
In addition, some middleboxes (B2BUAs and Session Border Controllers)
are known to modify portions of the SIP message which are included in
the RFC 4474 signature computation, thus breaking the signature.
This sort of man-in-the-middle operation is precisely the sort of
message modification that 4474 is intended to detect. In cases where
the middlebox is itself permitted to generate valid RFC 4474
signatures (e.g., it is within the same administrative domain as the
RFC 4474 authentication service), then it may generate a new
signature on the modified message. Alternately, the middlebox may be
able to sign with some other identity that it is permitted to assert.
Otherwise, the recipient cannot rely on the RFC 4474 Identity
assertion and the UA MUST not indicate to the user that a secure call
has been established to the claimed identity. Implementations which
are configured to only establish secure calls SHOULD terminate the
call in this case.
If SIP Identity or an equivalent mechanism is not used, then only
protection against attackers who cannot actively change the signaling
is provided. while this is still superior to previous mechanisms, the
security provided is inferior to that provided if integrity is
provided for the signaling.
8.7. Perfect Forward Secrecy 8.7. 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
skipping to change at page 22, line 5 skipping to change at page 25, line 41
[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] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress), draft-ietf-behave-rfc3489bis-16 (work in progress),
February 2008. 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.
[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 22, line 30 skipping to change at page 26, line 18
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
RTP", draft-zimmermann-avt-zrtp-04 (work in progress), Path Key Agreement for Secure RTP",
July 2007. draft-zimmermann-avt-zrtp-07 (work in progress),
June 2008.
[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-01 (work in progress), draft-ietf-avt-dtls-srtp-02 (work in progress),
November 2007. February 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-03 Protocols", draft-ietf-sip-media-security-requirements-07
(work in progress), February 2008. (work in progress), June 2008.
[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-08 (work in draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 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),
skipping to change at page 24, line 5 skipping to change at page 27, line 41
Transport", draft-wing-avt-dtls-srtp-key-transport-01 Transport", draft-wing-avt-dtls-srtp-key-transport-01
(work in progress), February 2008. (work in progress), February 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-00 (work in draft-ietf-mmusic-media-path-middleboxes-00 (work in
progress), January 2008. progress), January 2008.
[I-D.fischer-sip-e2e-sec-media]
Fischer, K., "End-to-End Security for DTLS-SRTP",
draft-fischer-sip-e2e-sec-media-00 (work in progress),
January 2008.
[I-D.wing-sip-identity-media]
Wing, D. and H. Kaplan, "SIP Identity using Media Path",
draft-wing-sip-identity-media-02 (work in progress),
February 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 (R-FORK-RETARGET, R-BEST-SECURE, A.1. Forking and retargeting (R-FORK-RETARGET, R-BEST-SECURE,
R-DISTINCT) R-DISTINCT)
In this draft, the SDP offer (in the INVITE) is simply an In this 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 use the SDP a mix of SRTP and non-SRTP endpoints are present, we use the SDP
capabilities mechanism currently being defined [I-D.ietf-mmusic-sdp- capabilities mechanism currently being defined
capability-negotiation] to transparently negotiate security where [I-D.ietf-mmusic-sdp-capability-negotiation] to transparently
possible. Because DTLS establishes a new key for each session, only negotiate security where possible. Because DTLS establishes a new
the entity with which the call is finally established gets the media key for each session, only the entity with which the call is finally
encryption keys (R3). established gets the media encryption keys (R3).
A.2. Distinct Cryptographic Contexts (R-DISTINCT) A.2. Distinct Cryptographic Contexts (R-DISTINCT)
DTLS performs a new DTLS handshake with each endpoint, which DTLS performs a new DTLS handshake with each endpoint, which
establishes distinct keys and cryptographic contexts for each establishes distinct keys and cryptographic contexts for each
endpoint. endpoint.
A.3. Reusage of a Security Context (R-REUSE) A.3. Reusage of a Security Context (R-REUSE)
DTLS allows sessions to be resumed with the 'TLS session resumption' DTLS allows sessions to be resumed with the 'TLS session resumption'
skipping to change at page 25, line 14 skipping to change at page 29, line 14
signaling. signaling.
A.7. (R-SIG-MEDIA, R-ACT-ACT) A.7. (R-SIG-MEDIA, R-ACT-ACT)
An attacker who controls the media channel but not the signalling An attacker who controls the media channel but not the signalling
channel can perform a MITM attack on the DTLS handshake but this will channel can perform a MITM attack on the DTLS handshake but this will
change the certificates which will cause the fingerprint check to change the certificates which will cause the fingerprint check to
fail. Thus, any successful attack requires that the attacker modify fail. Thus, any successful attack requires that the attacker modify
the signalling messages to replace the fingerprints. the signalling messages to replace the fingerprints.
An attacker who controls the signalling channel at any point between If RFC 4474 Identity or an equivalent mechanism is used, a attacker
the proxies performing the Identity signatures cannot modify the who controls the signalling channel at any point between the proxies
fingerprints without invalidating the Identity signature. Thus, even performing the Identity signatures cannot modify the fingerprints
an attacker who controls both signalling and media paths cannot without invalidating the signature. Thus, even an attacker who
successfully attack the media traffic. controls both signalling and media paths cannot successfully attack
the media traffic.
Note that an attacker who controls the authentication service can Note that an attacker who controls the authentication service can
impersonate the UA using that authentication service. This is an impersonate the UA using that authentication service. This is an
intended feature of SIP Identity--the authentication service owns the intended feature of SIP Identity--the authentication service owns the
namespace and therefore defines which user has which identity. namespace and therefore defines which user has which identity.
A.8. Binding to Identifiers (R-ID-BINDING) A.8. Binding to Identifiers (R-ID-BINDING)
This mechanism uses SIP-Identity [RFC4474] and SIP-Connected-Identity This mechanism uses SIP-Identity [RFC4474] and SIP-Connected-Identity
[RFC4916] to bind the endpoint's certificate fingerprints to the [RFC4916] to bind the endpoint's certificate fingerprints to the
skipping to change at page 28, line 26 skipping to change at page 32, line 14
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 RTFM, Inc.
2483 E. Bayshore #212 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: ekr@networkresonance.com Email: ekr@rtfm.com
Intellectual Property Statement 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 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 29, line 29 skipping to change at page 33, line 45
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 currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 64 change blocks. 
273 lines changed or deleted 402 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/