draft-ietf-sip-media-security-requirements-00.txt   draft-ietf-sip-media-security-requirements-01.txt 
SIP D. Wing SIP D. Wing, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational S. Fries Intended status: Informational S. Fries
Expires: March 31, 2008 Siemens AG Expires: May 21, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
September 28, 2007 November 18, 2007
Requirements and Analysis of Media Security Key Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-00.txt draft-ietf-sip-media-security-requirements-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 March 31, 2008. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A number of proposals have been published to address the need of This documents describes requirements for a protocol to negotiate
securing media traffic. A summary of the proposals available at that security context for SIP-signaled SRTP media. In addition to the
time is available in the appendix of this document. Different natural security requirements, this negotiation protocol must
assumptions, requirements, and usage environments justify every one interoperate well with SIP in certain ways. A number of proposals
of them. This document aims to summarize the discussed media have been published and a summary of these proposals is in the
security requirements. A comparison of the requirements against the appendix of this document.
individual proposals is provided.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Organization . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Clipping Media Before Signaling Answer . . . . . . . . . . 5 4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 6 4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 7
3.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 8 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 11
5. Requirements Classification . . . . . . . . . . . . . . . . . 14 4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Key Management Protocol Requirements . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Attack Scenario Requirements . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 5.3. Requirements Outside of the Key Management Protocol . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 22
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 22 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 23
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 22 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 23
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 22 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 23
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 22 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 24
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 23 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 24
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 23 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 24
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 23 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 24
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 23 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 25
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 25
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 24 A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 25
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 25
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 24 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 25
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 25 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 26
Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 25 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 25 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 26
B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 27 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 29 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 27
B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 31 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 27
Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 33 Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 27
C.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 33 B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 27
C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 35 B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 30
C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 36 B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 31
C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 39 B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 40 Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 C.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 42 C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 37
C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 39
C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 40
Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
The work on media security started a long time ago where the The work on media security started when the Session Initiation
capability of the Session Initiation Protocol (SIP) was still at its Protocol (SIP) was still in its infancy. With the increased SIP
infancy. With the increased SIP deployment and the availability of deployment and the availability of new SIP extensions and related
new SIP extensions and related protocols the need for end-to-end protocols, the need for end-to-end security was re-evaluated. The
security was re-evaluated. The procedure of re-evaluating prior procedure of re-evaluating prior protocol work and design decisions
protocol work and design decisions is not an uncommon strategy and, is not an uncommon strategy and, to some extent, considered necessary
to some extend, considered necessary protocol work to ensure that the protocol work to ensure that the developed protocols indeed meet the
developed protocols indeed meet the previously envisioned needs for previously envisioned needs for the users in the Internet.
the users in the Internet.
This document aims to summarize the discussed media security This document summarizes media security requirements, i.e.,
requirements, i.e., requirements for mechanisms that negotiate keys requirements for mechanisms that negotiate security context such as
and parameters for SRTP. The organization of this document is as cryptographic keys and parameters for SRTP.
follows: Section 2 introduces terminology, Section 3 provides an
overview about possible call scenarios, Section 4 lists requirements 1.1. Document Organization
for media security, Section 5 will provide a clustering of
requirements to certain deployment environments to adress the problem The organization of this document is as follows: Section 2 introduces
that there might not be a single solution with universal terminology, Section 3 describes various attack scenarios against the
applicability. The main part of the document concludes with the signaling path and media path, Section 4 provides an overview about
security considerations Section 6, IANA considerations Section 7 and possible call scenarios, Section 5 lists requirements for media
an acknowledgement section in Section 8. The appendix contains an security. The main part of the document concludes with the security
overview of the Appendix A lists the available solution proposals and considerations Section 6, IANA considerations Section 7 and an
compares them to the requirements. Appendix D lists non-goals for acknowledgement section in Section 8. Appendix A lists and compares
this document. available solution proposals. The following Appendix B compares the
different approaches regarding their suitability for the SIP
signaling scenarios described in Appendix A, while Appendix C
provides a comparison regarding security aspects. Appendix D lists
non-goals for this document.
2. Terminology 2. 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], with the document are to be interpreted as described in [RFC2119], with the
important qualification that, unless otherwise stated, these terms important qualification that, unless otherwise stated, these terms
apply to the design of the media security key management protocol, apply to the design of the media security key management protocol,
not its implementation or application. not its implementation or application.
Additionally, the following items are used in this document: Additionally, the following items are used in this document:
AOR (Address-of-Record): A SIP or SIPS URI that points to a domain AOR (Address-of-Record): A SIP or SIPS URI that points to a domain
with a location service that can map the URI to another URI where with a location service that can map the URI to another URI where
the user might be available. Typically, the location service is the user might be available. Typically, the location service is
populated through registrations. An AOR is frequently thought of populated through registrations. An AOR is frequently thought of
as the "public address" of the user. as the "public address" of the user.
SSRC: The 32-bit value that defines the synchronization source, SSRC: The 32-bit value that defines the synchronization source, used
used in RTP. These are generally unique, but collisions can in RTP. These are generally unique, but collisions can occur.
occur.
two-time pad: The use of the same key and the same key index to two-time pad: The use of the same key and the same key index to
encrypt different data. For SRTP, a two-time pad occurs if two encrypt different data. For SRTP, a two-time pad occurs if two
senders are using the same key and the same RTP SSRC value. senders are using the same key and the same RTP SSRC value.
PKI Public Key Infrastructure. Throughout this paper, the term PKI PKI: Public Key Infrastructure (see [RFC3280])
refers to a global PKI.
3. Call Scenarios Perfect Forward Secrecy (PFS): The property that disclosure of the
long-term secret keying material that is used to derive an agreed
ephemeral key does not compromise the secrecy of agreed keys from
earlier runs.
The following subsections describe call scenarios with relevance for active adversary: An active adversary attempts to alter system
media security. These call scenarios pose the most challenge to the resources or affect their operation (see [RFC4949]).
key management for media data in cooperation with SIP signaling.
3.1. Clipping Media Before Signaling Answer passive adversary: A passive adversary attempts to learn or make use
of information from a system but does not affect resources of that
system (see [RFC4949]).
signaling path: The signaling path is the route taken by SIP
signaling messages transmitted between the calling and called user
agents. This can be either direct signaling between the calling
and called user agents or, more commonly involves the SIP proxy
servers that were involved in the call setup.
media path: The media path is the route taken by media packets
exchanged by the endpoints. In the simplest case, the endpoints
exchange media directly, and the "media path" is defined by a
quartet of IP addresses and TCP/UDP ports, along with an IP route.
In other cases, this path may include RTP relays, mixers,
transcoders, session border controllers, NATs, or media gateways.
3. Attack Scenarios
The discussion in this section refers to requirements R6, R7, R14,
R17, and R27.
This document classifies adversaries according to their access and
their capabilities. An adversary might have access to:
1. only the media path,
2. only the signaling path,
3. both the media path and the signaling path.
An attacker that can solely be located along the signaling path, and
does not have access to media (item 2), is not considered in this
document.
There are two different types of adversaries, active and passive. An
active adversary may need to be active with regard to the key
exchange relevant information traveling along the media path or
traveling along the signaling path.
Based on their robustness against the adversary capabilities
described above, we can group security mechanisms using the following
labels, ordered from least secure at the top to most secure at the
bottom:
no-signaling-passive-media:
Access to only the media path is sufficient to reveal the content
of the media traffic. This is how unencrypted RTP functions.
passive-signaling-passive-media:
Passive attack on the signaling and passive attack on the media
path is necessary to reveal the content of the media traffic.
active-signaling-passive-media:
Active attack on the signaling path and passive attack on the
media path is necessary to reveal the content of the media
traffic.
active-signaling-active-media:
Active attack on both the signaling path and the media path is
necessary to reveal the content of the media traffic.
detect-attack:
Active attack on both signaling and media path is necessary to
reveal the content of the media traffic (active-signaling-active-
media), but the attack is detectable by the end points when
adversary tampers with the signaling and/or media messages.
For example, Security Descriptions [RFC4568], when protected by TLS
(as it is commonly implemented and deployed), belongs in the passive-
signaling-passive-media category since the adversary needs to learn
the Security Descriptions key by seeing the SIP signaling message at
a SIP proxy (assuming that the adversary is in control of the SIP
proxy). The media traffic can be decrypted using that learned key.
As another example, DTLS-SRTP falls into active-signaling-active-
media category when DTLS-SRTP is used with a public key based
ciphersuite with self-signed certificates and without SIP-Identity
[RFC4474]. An adversary would have to modify the fingerprint that is
sent along the signaling path and subsequently to modify the
certificates carried in the DTLS handshake that travel along the
media path. If DTLS-SRTP is used with SIP-Identity [RFC4474] and
protects both the offer and the answer, it would belong to the
detect-attack category.
The above discussion of DTLS-SRTP demonstrates how a single security
protocol can be in different classes depending on the mode in which
it is operated. Other protocols can achieve similar effect by adding
functions outside of the on-the-wire key management protocol itself.
Although it may be appropriate to deploy lower-classed mechanisms in
some cases, the ultimate security requirement for a media security
negotiation protocol is that it have a mode of operation available in
which it is detect-attack, which provides protection against the
passive and active attacks and provides detection of such attacks.
That is, there must be a way to use the protocol so that an active
attack is required against both the signaling and media paths, and so
that such attacks are detectable by the endpoints.
4. Call Scenarios
The following subsections describe call scenarios that pose the most
challenge to the key management system for media data in cooperation
with SIP signaling.
4.1. Clipping Media Before Signaling Answer
The discussion in this section refers to requirement R5.
Per the SDP Offer/Answer Model [RFC3264], Per the SDP Offer/Answer Model [RFC3264],
"Once the offerer has sent the offer, it MUST be prepared to "Once the offerer has sent the offer, it MUST be prepared to
receive media for any recvonly streams described by that offer. receive media for any recvonly streams described by that offer.
It MUST be prepared to send and receive media for any sendrecv It MUST be prepared to send and receive media for any sendrecv
streams in the offer, and send media for any sendonly streams in streams in the offer, and send media for any sendonly streams in
the offer (of course, it cannot actually send until the peer the offer (of course, it cannot actually send until the peer
provides an answer with the needed address and port information)." provides an answer with the needed address and port information)."
To meet this requirement with SRTP, the offerer needs to know the To meet this requirement with SRTP, the offerer needs to know the
SRTP key for arriving media. If encrypted SRTP media arrives before SRTP key for arriving media. If either endpoint receives encrypted
the associated SRTP key, the offerer cannot play the media -- causing media before it has access to the associated SRTP key, it cannot play
clipping. the media -- causing clipping.
For key exchange mechanisms that send the answerer's key in SDP, a For key exchange mechanisms that send the answerer's key in SDP, a
SIP provisional response [RFC3261], such as 183 (session progress), SIP provisional response [RFC3261], such as 183 (session progress),
is useful. However, the 183 messages are not reliable unless both is useful. However, the 183 messages are not reliable unless both
the calling and called end point support PRACK [RFC3262], use TCP the calling and called end point support PRACK [RFC3262], use TCP
across all SIP proxies, implement Security Preconditions across all SIP proxies, implement Security Preconditions [RFC5027],
[I-D.ietf-mmusic-securityprecondition], or the both ends implement or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer
ICE [I-D.ietf-mmusic-ice] and the answerer implements the reliable implements the reliable provisional response mechanism described in
provisional response mechanism described in ICE. Unfortunately, ICE. Unfortunately, there is not wide deployment of any of these
there is not wide deployment of any of these techniques and there is techniques and there is industry reluctance to set requirements
industry reluctance to set requirements regarding these techniques to regarding these techniques to avoid the problem described in this
avoid the problem described in this section. section.
Note that the receipt of an SDP answer is not always sufficient to Note that the receipt of an SDP answer is not always sufficient to
allow media to be played to the offerer. Sometimes, the offerer must allow media to be played to the offerer. Sometimes, the offerer must
send media in order to open up firewall holes or NAT bindings before send media in order to open up firewall holes or NAT bindings before
media can be received. In this case a solution that makes the key media can be received. In this case, even a solution that makes the
available before the SDP answer arrives will not help. key available before the SDP answer arrives will not help.
Requirements are created due to early media, in the sense of pre-
offer/answer media, as described in [I-D.barnes-sip-em-ps-req-sol].
Fixes to early media might make the requirements to become obsolete, Fixes to early media might make the requirements to become obsolete,
but at the time of writing no progress has been accomplished. but at the time of writing no progress has been accomplished.
3.2. Retargeting and Forking 4.2. Retargeting and Forking
The discussion in this section relates to requirements R1, R2, and
R3.
In SIP, a request sent to a specific AOR but delivered to a different In SIP, a request sent to a specific AOR but delivered to a different
AOR is called a "retarget". A typical scenario is a "call AOR is called a "retarget". A typical scenario is a "call
forwarding" feature. In Figure 1 Alice sends an Invite in step 1 forwarding" feature. In Figure 1 Alice sends an Invite in step 1
that is sent to Bob in step 2. Bob responds with a redirect (SIP that is sent to Bob in step 2. Bob responds with a redirect (SIP
response code 3xx) pointing to Carol in step 3. This redirect response code 3xx) pointing to Carol in step 3. This redirect
typically does not propagate back to Alice but only goes to a proxy typically does not propagate back to Alice but only goes to a proxy
(i.e., the retargeting proxy) that sends the original Invite to Carol (i.e., the retargeting proxy) that sends the original Invite to Carol
in step 4. in step 4.
skipping to change at page 6, line 43 skipping to change at page 9, line 24
| ^ | | ^ |
Invite (2) | | | Invite (4) Invite (2) | | | Invite (4)
& redirect (3) | | | & redirect (3) | | |
V | V V | V
++-++ ++----+ ++-++ ++----+
|Bob| |Carol| |Bob| |Carol|
+---+ +-----+ +---+ +-----+
Figure 1: Retargeting Figure 1: Retargeting
Using retargeting might lead to situations where the UAC does not
know where its request will be going. This might not immediately
seem like a serious problem; after all, when one places a telephone
call on the PSTN, one never really knows if it will be forwarded to a
different number, who will pick up the line when it rings, and so on.
However, when considering SIP mechanisms for authenticating the
called party, this function can also make it difficult to
differentiate an intermediary that is behaving legitimately from an
attacker. From this perspective, the main problems with retargeting
ares:
Not detectable by the caller: The originating user agent has no
means of anticipating that the condition will arise, nor any means
of determining that it has occurred until the call has already
been set up, i.e. the negative consequences have already been
realized.
Not preventable by the caller: There is no existing security
mechanism that might be employed by the originating user agent in
order to guarantee that the call will not be re-targeted.
The mechanism used by SIP for identifying the calling party is SIP The mechanism used by SIP for identifying the calling party is SIP
Identity [RFC3261]. However, due to SIP retargeting issues Identity [RFC3261]. However, due to the nature of retargeting SIP
[I-D.peterson-sipping-retarget], SIP Identity can only identify the Identity can only identify the calling party (that is, the party that
calling party (that is, the party that initiated the SIP request). initiated the SIP request). Some key exchange mechanisms predate SIP
Some key exchange mechanisms predate SIP Identity and include their Identity and include their own identity mechanism. However, those
own identity mechanism. However, those built-in identity mechanism built-in identity mechanism also suffer from the SIP retargeting
suffer from the same SIP retargeting problem described in the above problem. Going forward, Connected Identity [RFC4916] allows
draft. Going forward, Connected Identity [RFC4916] allows identifying the called party.
identifying the called party. This is also described as the
'retargeting identity' problem.
In SIP, 'forking' is the delivery of a request to multiple locations. In SIP, 'forking' is the delivery of a request to multiple locations.
This happens when a single AOR is registered more than once. An This happens when a single AOR is registered more than once. An
example of forking is when a user has a desk phone, PC client, and example of forking is when a user has a desk phone, PC client, and
mobile handset all registered with the same AOR. mobile handset all registered with the same AOR.
+-----+ +-----+
|Alice| |Alice|
+--+--+ +--+--+
| |
skipping to change at page 7, line 39 skipping to change at page 10, line 37
With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP
responses. Alice will see those intermediate (18x) and final (200) responses. Alice will see those intermediate (18x) and final (200)
responses. It is useful for Alice to be able to associate the SIP responses. It is useful for Alice to be able to associate the SIP
response with the incoming media stream. Although this association response with the incoming media stream. Although this association
can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make
this association with RTP, it is not desirable to require ICE to this association with RTP, it is not desirable to require ICE to
accomplish this association. accomplish this association.
Forking and retargeting are often used together. For example, a boss Forking and retargeting are often used together. For example, a boss
and secretary might have both phones ring and rollover to voice mail and secretary might have both phones ring (forking) and rollover to
if neither phone is answered. voice mail if neither phone is answered (retargeting).
To maintain security of the media traffic, only the end point that To maintain security of the media traffic, only the end point that
answers the call should know the SRTP keys for the session. This is answers the call should know the SRTP keys for the session. This is
only an issue with public key encryption and not with DH-based only an issue when the key management is encrypted with a key
approaches. For key exchange mechanisms that do not provide secure corresponding to the responder. It does not lead to problems with
forking or secure retargeting, one workaround is to re-key DH-based approaches. For key exchange mechanisms that do not provide
immediately after forking or retargeting (that is, perform a re- secure forking or secure retargeting, one workaround is to re-key
Invite). However, because the originator may not be aware that the immediately after forking or retargeting. However, because the
call forked this mechanism requires rekeying immediately after every originator may not be aware that the call forked this mechanism
session is established. This doubles the Invite messages processed requires rekeying immediately after every session is established.
by the network. This doubles the number of messages processed by the network.
Retargeting securely introduces a more significant problem. With Retargeting securely introduces a more significant problem. With
retargeting, the actual recipient of the request is not the original retargeting, the actual recipient of the request is not the original
recipient. This means that if the offerer encrypted material (such recipient. This means that if the offerer encrypted material (such
as the session key or the SDP) using the original recipient's public as the session key or the SDP) using the original recipient's public
key, the actual recipient will not be able to decrypt that material key (or a shared secret established previously), the actual recipient
because the recipient won't have the original recipient's private will not be able to decrypt that material because the recipient won't
key. In some cases, this is the intended behavior, i.e., you wanted have the original recipient's private key. In some cases, this is
to establish a secure connection with a specific individual. In the intended behavior, i.e., you wanted to establish a secure
other cases, it is not intended behavior (you want all voice media to connection with a specific individual. In other cases, it is not
be encrypted, regardless of who answers). intended behavior (you want all voice media to be encrypted,
regardless of who answers).
For some forms of key management the calling party needs to know in
advance the certificate or shared secret of the called party, and
retargeting can interfere with this.
Further compounding this problem is a particularity of SIP that when Further compounding this problem is a particularity of SIP that when
forking is used, there is always only one final error response forking is used, there is always only one final error response
delivered to the sender of the request: the forking proxy is delivered to the sender of the request: the forking proxy is
responsible for choosing which final response to choose in the event responsible for choosing which final response to choose in the event
where forking results in multiple final error responses being where forking results in multiple final error responses being
received by the forking proxy. This means that if a request is received by the forking proxy. This means that if a request is
rejected, say with information that the keying information was rejected, say with information that the keying information was
rejected and providing the far end's credentials, it is very possible rejected and providing the far end's credentials, it is very possible
that the rejection will never reach the sender. This problem, called that the rejection will never reach the sender. This problem, called
the Heterogeneous Error Response Forking Problem (HERFP) the Heterogeneous Error Response Forking Problem (HERFP)
[I-D.mahy-sipping-herfp-fix], is difficult to solve in SIP. [I-D.mahy-sipping-herfp-fix], is difficult to solve in SIP. Because
we expect the HERFP to continue to be a problem in SIP for the
foreseeable future, a media security system should function even in
the presence of HERFP behavior.
3.3. Shared Key Conferencing 4.3. Shared Key Conferencing
The consensus on the RTPSEC mailing list was to concentrate on
unicast, point-to-point sessions. Thus, there are no requirements
related to shared key conferencing. This section is retained for
informational purposes.
For efficient scaling, large audio and video conference bridges For efficient scaling, large audio and video conference bridges
operate most efficiently by encrypting the current speaker once and operate most efficiently by encrypting the current speaker once and
distributing that stream to the conference attendees. Typically, distributing that stream to the conference attendees. Typically,
inactive participants receive the same streams -- they hear (or see) inactive participants receive the same streams -- they hear (or see)
the active speaker(s), and the active speakers receive distinct the active speaker(s), and the active speakers receive distinct
streams that don't include themselves. In order to maintain streams that don't include themselves. In order to maintain
confidentiality of such conferences where listeners share a common confidentiality of such conferences where listeners share a common
key, all listeners must rekeyed when a listener joins or leaves a key, all listeners must rekeyed when a listener joins or leaves a
conference. conference.
skipping to change at page 10, line 9 skipping to change at page 13, line 9
mechanisms allow the transmitter to determine its own key, and others mechanisms allow the transmitter to determine its own key, and others
allow the offerer to determine the key for the offerer and answerer. allow the offerer to determine the key for the offerer and answerer.
Depending on how the call is established, the offerer might be a Depending on how the call is established, the offerer might be a
participant (such as a participant dialing into a conference bridge) participant (such as a participant dialing into a conference bridge)
or the offerer might be the mixer (such as a conference bridge or the offerer might be the mixer (such as a conference bridge
calling a participant). The use of offerless Invites may help some calling a participant). The use of offerless Invites may help some
keying mechanisms reverse the role of offerer/answerer. A keying mechanisms reverse the role of offerer/answerer. A
difficulty, however, is knowing a priori if the role should be difficulty, however, is knowing a priori if the role should be
reversed for a particular call. reversed for a particular call.
4. Requirements 4.4. Recording
R1: Negotiation of SRTP keys MUST NOT cause the call setup to fail The discussion in this section relates to requirement R23.
in forked and retargeted calls where all end points are
willing to use SRTP, unless the execution of the
authentication and key exchange protocol leads to a failure
(e.g., an unsuccessful authentication attempt).
R2: Even when some end points of a forked or retargeted call are Some business environments, such as stock brokers, banks, and catalog
incapable of using SRTP, the key management protocol MUST call centers, require recording calls with customers. This is the
allow the establishment of SRTP associations with SRTP-capable familiar "this call is being recorded for quality purposes" heard
endpoints and / or RTP associations with non-SRTP-capable during calls to these sorts of businesses. In these environments,
endpoints. media recording is typically performed by an intermediate device
(with RTP, this is typically implemented in a 'sniffer').
R3: Forked end points MUST NOT know the SRTP key of any call When performing such call recording with SRTP, the end-to-end
established with another forked end point. security is compromised. This is unavoidable, but necessary because
the operation of the business requires such recording. It is
desirable that the media security is not unduly compromised by the
media recording. The endpoint within the organization needs to be
informed that there is an intermediate device and needs to cooperate
with that intermediate device.
R4: The media security key management protocol MAY support the This scenario does not place a requirement directly on the key
ability to utilize an initially established security context management protocol. The requirement could be met directly by the
that was established as part of the first call setup with a key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an
remote end point. external out-of-band-mechanism (e.g., [I-D.wing-sipping-srtp-key]).
Specialized devices may need to avoid public key operations or 4.5. PSTN gateway
Diffie-Hellman operations as much as possible because of the
computational cost or because of the additional call setup
delay. For example, it can take a second or two to perform a
Diffie-Hellman operation in certain devices. Examples of
these specialized devices would include some handsets,
intelligent SIMs, and PSTN gateways. For the typical case
because a phone call has not yet been established, ancillary
processing cycles can be utilized to perform the PK or DH
operation; for example, in a PSTN gateway the DSP, which is
not yet involved with typical DSP operations, could be used to
perform the calculation, so as to avoid having the central
host processor perform the calculation. Some devices, such as
handsets, and intelligent SIMs do not have such ancillary
processing capability.
R5: The media security key management protocol SHOULD avoid The discussion in this section relates to requirement R26.
clipping media before SDP answer without requiring PRACK
[RFC3262].
R6: The media security key management protocol MUST provide A typical case of using media security is the one where two entities
protection against passive attacks on the media path. are having a VoIP conversation over IP capable networks. However,
there are cases where the other end of the communication is not
connected to an IP capable network. In this kind of setting, there
needs to be some kind of gateway at the edge of the IP network which
converts the VoIP conversation to format understood by the other
network. An example of such gateway is a PSTN gateway sitting at the
edge of IP and PSTN networks.
R7: The media security key management protocol MUST provide If media security (e.g., SRTP protection) is employed in this kind of
protection against passive attacks of a SIP proxy that is gateway-setting, then media security and the related key management
legitimately routing SIP messages. needs to be terminated at the gateway. The other network (e.g.,
PSTN) may have its own measures to protect the communication, but
this means that from media security point of view the media security
is not employed end-to-end between the communicating entities.
5. Requirements
This section is divided into several parts: requirements specific to
the key management protocol (Section 5.1), attack scenarios
(Section 5.2), and requirements which can be met inside the key
management protocol or outside of the key management protocol
(Section 5.3).
5.1. Key Management Protocol Requirements
SIP Forking and Retargeting, from Section 4.2:
R1: The media security key management protocol MUST support forking
and retargeting when all endpoints are willing to use SRTP
without causing the call setup to fail, unless the execution of
the authentication and key exchange protocol leads to a failure
(e.g., an unsuccessful authentication attempt).
R3: The media security key management protocol MUST create
distinct, independent cryptographic contexts for each endpoint
in a forked session.
Security characteristics:
R8: The media security key management protocol MUST be able to R8: The media security key management protocol MUST be able to
support perfect forward secrecy (or PFS). The term PFS is the support perfect forward secrecy.
property that disclosure of the long-term secret keying
material that is used to derive an agreed ephemeral key does
not compromise the secrecy of agreed keys from earlier runs.
R9: The media security key management protocol MUST support R9: The media security key management protocol MUST support
negotiation of SRTP cipher suites without incurring per- negotiation of SRTP cipher suites without incurring per-
algorithm computational expense. This allows an offer to be algorithm computational expense. This allows an offer to be
built without incurring computational expense for each built without incurring computational expense for each
algorithm. algorithm.
R10: If SRTP keying is performed over the media path, the keying R12: The media security key management protocol MUST NOT require 3rd
packets MUST NOT pass the RTP validity check defined in parties to sign certificates.
Appendix A.1 of [RFC3550].
R11: The media security key management protocol that utilizes
expensive cryptographic computations SHOULD offer the ability
to resume previous sessions in an efficient way.
R12: The media security key management protocol MUST NOT require
3rd parties to sign certificates.
This requirement points to the fact that a global PKI cannot
be assumed and opportunistic security approaches should be
considered as part of the solution.
R13: The media security key management protocol SHOULD use R13: The media security key management protocol SHOULD use
algorithms that allow FIPS 140-2 [FIPS-140-2] certification. algorithms that allow FIPS 140-2 [FIPS-140-2] certification.
Note that the United States Government can only purchase and Note that the United States Government can only purchase and
use crypto implementations that have been validated by the use crypto implementations that have been validated by the
FIPS-140 [FIPS-140-2] process: FIPS-140 [FIPS-140-2] process:
"The FIPS-140 standard is applicable to all Federal agencies "The FIPS-140 standard is applicable to all Federal agencies
that use cryptographic-based security systems to protect that use cryptographic-based security systems to protect
sensitive information in computer and telecommunication sensitive information in computer and telecommunication
systems, including voice systems. The adoption and use of systems, including voice systems. The adoption and use of this
this standard is available to private and commercial standard is available to private and commercial
organizations."[cryptval] organizations."[cryptval]
Some commercial organizations, such as banks and defense Some commercial organizations, such as banks and defense
contractors, also require or prefer equipment which has contractors, also require or prefer equipment which has
validated by the FIPS-140 process. validated by the FIPS-140 process.
R14: The media security key management protocol SHOULD be able to R16: The media security key management protocol SHOULD NOT introduce
associate the signaling exchange with the media traffic. new denial of service vulnerabilities (e.g., the protocol
should not request the endpoint to perform CPU-intensive
For example, if using a Diffie-Hellman keying technique with operations without the client being able to validate or
security preconditions that forks to 20 end points, the call authorize the request).
initiator would get 20 provisional responses containing 20
signed Diffie-Hellman key pairs. Calculating 20 DH secrets
and validating signatures can be a difficult task depending on
the device capabilities. Hence, in the case of forking, it is
not desirable to perform a DH or PK operation with every
party, but rather only with the party that answers the call
(and incur some media clipping). To do this, the signaling
and media need to be associated so the calling party knows
which key management needs to be completed. This might be
done by using the transport address indicated in the SDP,
although NATs can complicate this association.
Allowing such an association also allows the SDP offerer to
avoid performing CPU-consuming operations (e.g., DH or public
key operations) with attackers that have not seen the
signaling messages.
R15: The media security key management protocol SHOULD allow to
start with RTP and then upgrade to SRTP.
R16: The media security key management protocol SHOULD NOT
introduce new denial of service vulnerabilities.
R17: The media security key management protocol SHOULD require the
adversary to have access to the data as well as the signaling
path for a successful attack to be launched. An adversary
that is located only along the data or only along the
signaling path MUST NOT be able to successfully mount an
attack. A successful attack refers to the ability for the
adversary to obtain keying material to decrypt the SRTP
encrypted media traffic.
R18: If two parties share an authentication infrastructure that has R18: If two parties share an authentication infrastructure, they
3rd parties signing certificates, they SHOULD be able to make SHOULD be able to make use of it.
use of it.
R19: The media security key management protocol MUST provide R19: The media security key management protocol MUST provide crypto-
crypto-agility. agility, i.e., the ability to adapt to evolving cryptography
and security requirements (update of cryptographic algorithms
without substantial disruption to deployed implementations)
R20: The media security key management protocol MUST protect cipher R20: The media security key management protocol MUST protect cipher
suite negotiation against downgrading attacks. suite negotiation against downgrading attacks.
R21: The media security key management protocol MUST allow a SIP R24: <deleted>
User Agent to negotiate media security parameters for each
individual session.
R22: The media security key management protocol SHOULD allow
establishing SRTP keying between different call signaling
protocols (e.g., between Jabber, SIP, H.323, MGCP)
R23: The media security key management protocol SHOULD support
recording of decrypted media.
Media recording may be realized by an intermediate nodes. An Performance considerations:
example for those intermediate nodes are devices, which could
be used in banking applications or for quality monitoring in
call centers. Here, it must be ensured, that the media
security is ensured by the intermediate nodes on the
connections to the involved endpoints as originally
negotiated. The endpoints need to be informed that there is
an intermediate device and need to cooperate. A solution
approach for this is described in [I-D.wing-sipping-srtp-key].
R24: The media security key management protocol SHOULD NOT allow R4: The media security key management protocol MAY support the re-
end users to determine whether their end-to-end interaction is use of a previously established security context.
subject to lawful interception.
R25: The media security key management protocol MUST work when Specialized devices may need to avoid public key operations or
there are intermediate nodes, terminating or processing media, Diffie-Hellman operations as much as possible because of the
between the end points. computational cost or because of the additional call setup
delay. For example, it can take a second or two to perform a
Diffie-Hellman operation in certain devices. Examples of these
specialized devices would include some handsets, intelligent
SIMs, and PSTN gateways. For the typical case because a phone
call has not yet been established, ancillary processing cycles
can be utilized to perform the PK or DH operation; for example,
in a PSTN gateway the DSP, which is not yet involved with
typical DSP operations, could be used to perform the
calculation, so as to avoid having the central host processor
perform the calculation. Some devices, such as handsets, and
intelligent SIMs do not have such ancillary processing
capability.
R26: The media security key management protocol MUST consider R11: <Requirement R11 has been folded into R4.>
termination of media security in a PSTN gateway.
A typical case of using media security is the one where two Media considerations:
entities are having a VoIP conversation over IP capable
networks. However, there are cases where the other end of the
communication is not connected to an IP capable network. In
this kind of setting, there needs to be some kind of gateway
at the edge of the IP network which converts the VoIP
conversation to format understood by the other network. An
example of such gateway is a PSTN gateway sitting at the edge
of IP and PSTN networks.
If media security (e.g., SRTP protection) is employed in this R5: The media security key management protocol SHOULD avoid
kind of gateway-setting, then media security and the related clipping media before SDP answer without requiring PRACK
key management needs to be terminated at the gateway. The [RFC3262]. This requirement comes from Section 4.1.
other network (e.g., PSTN) may have its own measures to
protect the communication, but this means that from media
security point of view the media security is not employed end-
to-end between the communicating entities.
5. Requirements Classification R10: If SRTP key negotiation is performed over the media path (i.e.,
using the same UDP/TCP ports as media packets), the key
negotiation packets MUST NOT pass the RTP validity check
defined in Appendix A.1 of [RFC3550].
An adversary might be located along R15: The media security key management protocol SHOULD allow
endpoints to start with RTP and then upgrade to SRTP.
1. the media path, Issue: Does this mean
[I-D.ietf-mmusic-sdp-capability-negotiation] (which overlaps
with R1 and R2), allow RTP during early media (and upgrade to
SRTP when the SDP answer arrives), or support an "Encrypt this
call" button on the phone?
2. the signaling path, R21: The media security key management protocol MUST allow a SIP
User Agent to negotiate media security parameters for each
individual session.
3. the media and the signaling path. R25: The media security key management protocol MUST work when there
are intermediate nodes (e.g., transcoders), terminating or
processing media, between the end points.
An attacker that can solely be located along the signaling path, and Issue: Unclear how requirement for transcoders is met.
does not have access to media, is not considered (ref item 2).
Furthermore, it is reasonable to consider the capabilities of the R26: The media security key management protocol MUST support
adversary. We also have different types of adversaries, namely termination of media security in a PSTN gateway. This
requirement is from Section 4.5.
a. active adversary 5.2. Attack Scenario Requirements
b. passive adversary This section describes requirements from the attack scenarios
(Section 3).
Note that the adversary model for (a) and (b) also assumes the Required for the passive-signaling-passive-media scenario:
attacker being able to control SIP signaling entities.
With respect to item (a) an adversary may need to be active with R6: The media security key management protocol MUST have a mode
regard to the key exchange relevant information traveling along the which prevents a passive adversary with access to the media
data or the signaling path. path from gaining access to keying material used to protect
SRTP media packets.
Some of the deployment variants of the media security key management R7: The media security key management protocol MUST have a mode in
proposals under considerations do not provide protection against man- which it prevents a passive adversary with access to the
in-the-middle adversaries under certain conditions, for example when signaling path from gaining access to keying material used to
SIP signaling entities are compromised, when a global PKI is missing protect SRTP media packets.
or pre-shared secrets are not exchanged between the end points prior
to the protocol exchange.
Based on the above-mentioned considerations the following Required for the active-signaling-passive-media scenario:
classifications can be made:
Class I: R14: The media security key management protocol SHOULD include a
mechanism for associating key management messages with both the
signaling traffic that initiated the session and with protected
media traffic. Allowing such an association also allows the
SDP offerer to avoid performing CPU-consuming operations (e.g.,
DH or public key operations) with attackers that have not seen
the signaling messages.
Passive attack on the signaling and the data path sufficient to For example, if using a Diffie-Hellman keying technique with
reveal the content of the media traffic. security preconditions that forks to 20 end points, the call
initiator would get 20 provisional responses containing 20
signed Diffie-Hellman key pairs. Calculating 20 DH secrets and
validating signatures can be a difficult task depending on the
device capabilities. Hence, in the case of forking, it is not
desirable to perform a DH or PK operation with every party, but
rather only with the party that answers the call (and incur
some media clipping). To do this, the signaling and media need
to be associated so the calling party knows which key
management needs to be completed. This might be done by using
the transport address indicated in the SDP, although NATs can
complicate this association.
Class II: Required for the active-signaling-active-media scenario:
Active attack on the signaling path and passive attack on the data R17: The media security key management protocol SHOULD require the
path to reveal the content of the media traffic. adversary to have access to the signaling path as well as the
media path for a successful attack to be launched. An
adversary that is located only along the data or only along the
signaling path MUST NOT be able to successfully mount an
attack. A successful attack refers to the ability for the
adversary to obtain keying material to decrypt the SRTP
encrypted media traffic.
Class III: Required for the detect-attack scenario::
Active attack on the signaling and the data path necessary to R27: The media security key management protocol SHOULD include
reveal the content of the media traffic. information in the SDP that can be signed by SIP signaling and
validated by the either party (e.g., SIP-Identity [RFC4474] and
SIP-Connected-Identity [RFC4916]). This allows the both
parties to validate the From: address. The called party can
validate the From: address prior to accepting the call.
Class IV: 5.3. Requirements Outside of the Key Management Protocol
Active attack is required and will be detected by the end points The requirements in this section can be solved within the key
when adversary tampers with the messages. management protocol itself, or can be solved outside of the key
management protocol itself (e.g., solved in SIP or in SDP).
For example, SDES falls into Class I since the adversary needs to R2: Even when some end points of a forked or retargeted call are
learn the SDES key by progressing a signaling message at a SIP proxy incapable of using SRTP, the solution MUST be described which
(assuming that the adversary is in control of the SIP proxy). allows the establishment of SRTP associations with SRTP-capable
Subsequent media traffic can be decrypted with the help of the endpoints and / or RTP associations with non-SRTP-capable
learned key. endpoints. This requirement comes from Section 4.2.
As another example, DTLS-RTP falls into Class III when DTLS is used a R23: The media security key management protocol SHOULD be able to
public key based ciphersuite with self-signed certificates and negotiate keys for SRTP sessions created via different call
without SIP Identity. An adversary would have to modify the signaling protocols (e.g., between Jabber, SIP, H.323, MGCP).
fingerprint that is sent along the signaling path and subsequently to
modify the certificates carried in the DTLS handshake that travel
along the media path.
An attack is not successful when SIP Identity is used, the adversary R23: A solution SHOULD be described which supports recording of
is not between the SIP UA and its Authentication Service (or at the decrypted media. This requirement comes from Section 4.4.
Authentication Service), both end points are able to verify the
digital signature (of the SIP Identity) and are able to validate the
corresponding certificates.
6. Security Considerations 6. Security Considerations
This document lists requirements for securing media traffic. As This document lists requirements for securing media traffic. As
such, it addresses security throughout the document. such, it addresses security throughout the document.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
skipping to change at page 17, line 18 skipping to change at page 19, line 43
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[cryptval] [cryptval]
NIST, "Cryptographic Module Validation Program", NIST, "Cryptographic Module Validation Program",
December 2006, December 2006,
<http://csrc.nist.gov/cryptval/140-2APP.htm>. <http://csrc.nist.gov/cryptval/140-2APP.htm>.
9.2. Informative References 9.2. Informative References
[I-D.barnes-sip-em-ps-req-sol]
Barnes, R. and M. Lepinski, "Early Media in SIP: Problem
Statement, Requirements, and Analysis of Solutions",
draft-barnes-sip-em-ps-req-sol-00 (work in progress),
February 2007.
[I-D.baugher-mmusic-sdp-dh] [I-D.baugher-mmusic-sdp-dh]
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
in progress), February 2006. in progress), February 2006.
[I-D.dondeti-msec-rtpsec-mikeyv2] [I-D.dondeti-msec-rtpsec-mikeyv2]
Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY,
revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in
progress), March 2007. progress), March 2007.
[I-D.fischl-sipping-media-dtls] [I-D.fischl-sipping-media-dtls]
Fischl, J., "Datagram Transport Layer Security (DTLS) Fischl, J., "Datagram Transport Layer Security (DTLS)
Protocol for Protection of Media Traffic Established with Protocol for Protection of Media Traffic Established with
the Session Initiation Protocol", the Session Initiation Protocol",
draft-fischl-sipping-media-dtls-03 (work in progress), draft-fischl-sipping-media-dtls-03 (work in progress),
July 2007. July 2007.
[I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-01 (work in progress),
November 2007.
[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)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-18 (work in progress), draft-ietf-mmusic-ice-19 (work in progress), October 2007.
September 2007.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-06 (work in draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
progress), July 2007. progress), October 2007.
[I-D.ietf-mmusic-securityprecondition]
Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams",
draft-ietf-mmusic-securityprecondition-04 (work in
progress), July 2007.
[I-D.ietf-msec-mikey-applicability] [I-D.ietf-msec-mikey-applicability]
Fries, S. and D. Ignjatic, "On the applicability of Fries, S. and D. Ignjatic, "On the applicability of
various MIKEY modes and extensions", various MIKEY modes and extensions",
draft-ietf-msec-mikey-applicability-06 (work in progress), draft-ietf-msec-mikey-applicability-06 (work in progress),
July 2007. July 2007.
[I-D.ietf-msec-mikey-ecc] [I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY", Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress), draft-ietf-msec-mikey-ecc-03 (work in progress),
skipping to change at page 18, line 43 skipping to change at page 21, line 15
[I-D.mahy-sipping-herfp-fix] [I-D.mahy-sipping-herfp-fix]
Mahy, R., "A Solution to the Heterogeneous Error Response Mahy, R., "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP) in the Session Initiation Forking Problem (HERFP) in the Session Initiation
Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in
progress), March 2006. progress), March 2006.
[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.mcgrew-tls-srtp]
Rescorla, E. and D. McGrew, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-mcgrew-tls-srtp-02 (work in progress), March 2007.
[I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements",
draft-peterson-sipping-retarget-00 (work in progress),
February 2005.
[I-D.wing-sipping-srtp-key] [I-D.wing-sipping-srtp-key]
Wing, D., "Disclosing Secure RTP (SRTP) Session Keys with Wing, D., Audet, F., Fries, S., and H. Tschofenig,
a SIP Event Package", draft-wing-sipping-srtp-key-01 (work "Disclosing Secure RTP (SRTP) Session Keys with a SIP
in progress), July 2007. Event Package", draft-wing-sipping-srtp-key-02 (work in
progress), November 2007.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
RTP", draft-zimmermann-avt-zrtp-04 (work in progress), RTP", draft-zimmermann-avt-zrtp-04 (work in progress),
July 2007. July 2007.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 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.
[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,
skipping to change at page 20, line 12 skipping to change at page 22, line 25
Multimedia Internet KEYing (MIKEY)", RFC 4738, Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006. November 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real- Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007. time Transport Protocol (SRTP)", RFC 4771, January 2007.
[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.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams",
RFC 5027, October 2007.
Appendix A. Overview of Keying Mechanisms Appendix A. Overview of Keying Mechanisms
Based on how the SRTP keys are exchanged, each SRTP key exchange Based on how the SRTP keys are exchanged, each SRTP key exchange
mechanism belongs to one general category: mechanism belongs to one general category:
signaling path: All the keying is carried in the call signaling signaling path: All the keying is carried in the call signaling
(SIP or SDP) path. (SIP or SDP) path.
media path: All the keying is carried in the SRTP/SRTCP media media path: All the keying is carried in the SRTP/SRTCP media
path, and no signaling whatsoever is carried in the call path, and no signaling whatsoever is carried in the call
skipping to change at page 21, line 43 skipping to change at page 24, line 17
MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both
directions using the intended answerer's public key, which is directions using the intended answerer's public key, which is
obtained from a PKI. obtained from a PKI.
MIKEY-RSA requires one message from offerer to answerer (half a round MIKEY-RSA requires one message from offerer to answerer (half a round
trip), and does not add additional media path messages. MIKEY-RSA trip), and does not add additional media path messages. MIKEY-RSA
requires the offerer to obtain the intended answerer's certificate. requires the offerer to obtain the intended answerer's certificate.
A.1.4. MIKEY-RSA-R A.1.4. MIKEY-RSA-R
MIKEY-RSA-R An additional mode of key distribution in MIKEY: MIKEY- MIKEY-RSA-R [RFC4738] is essentially the same as MIKEY-RSA but
RSA-R [RFC4738] is essentially the same as MIKEY-RSA but reverses the reverses the role of the offerer and the answerer with regards to
role of the offerer and the answerer with regards to providing the providing the keys. That is, the answerer encrypts the keys for both
keys. That is, the answerer encrypts the keys for both directions directions using the offerer's public key. Both the offerer and
using the offerer's public key. Both the offerer and answerer answerer validate each other's public keys using a PKI. MIKEY-RSA-R
validate each other's public keys using a PKI. MIKEY-RSA-R also also enables sending certificates in the MIKEY message.
enables sending certificates in the MIKEY message.
MIKEY-RSA-R requires one message from offerer to answer, and one MIKEY-RSA-R requires one message from offerer to answer, and one
message from answerer to offerer (full round trip), and does not add message from answerer to offerer (full round trip), and does not add
additional media path messages. MIKEY-RSA-R requires the offerer additional media path messages. MIKEY-RSA-R requires the offerer
validate the answerer's certificate. validate the answerer's certificate.
A.1.5. MIKEY-DHSIGN A.1.5. MIKEY-DHSIGN
In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key
from a Diffie-Hellman exchange. In order to prevent an active man- from a Diffie-Hellman exchange. In order to prevent an active man-
skipping to change at page 24, line 10 skipping to change at page 26, line 30
channel is used only for call setup and the media channel is used to channel is used only for call setup and the media channel is used to
establish an encrypted channel -- much like encryption devices on the establish an encrypted channel -- much like encryption devices on the
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
by having each person read digits to the other person. Subsequent by having each person read digits to the other person. Subsequent
sessions with the same ZRTP endpoint can be authenticated using the sessions with the same ZRTP endpoint can be authenticated using the
stored hash of the previously negotiated key rather than voice stored hash of the previously negotiated key rather than voice
authentication. authentication.
ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2) ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2)
to establish the SRTP key, and 3 media path confirmation messages. to establish the SRTP key, and 3 media path confirmation messages.
The first 4 are sent as RTP packets (using RTP header extensions), These initial messages are all sent as non-RTP packets.
and the last 3 are sent in conjunction with SRTP media packets (again
as SRTP header extensions). Note that unencrypted RTP is being Note that when ZRTP probing is used, unencrypted RTP is being
exchanged until the SRTP keys are established. exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques A.3. Signaling and Media Path Keying Techniques
A.3.1. EKT A.3.1. EKT
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange
protocol, such as Security Descriptions or MIKEY, for bootstrapping. protocol, such as Security Descriptions or MIKEY, for bootstrapping.
In the initial phase, each member of a conference uses an SRTP key In the initial phase, each member of a conference uses an SRTP key
exchange protocol to establish a common key encryption key (KEK). exchange protocol to establish a common key encryption key (KEK).
skipping to change at page 24, line 37 skipping to change at page 27, line 9
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP such as Security Descriptions or MIKEY. Each answerer sends an SRTCP
message which contains the answerer's SRTP Master Key, rollover message which contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent. need to be sent.
A.3.2. DTLS-SRTP A.3.2. DTLS-SRTP
DTLS-SRTP [I-D.mcgrew-tls-srtp] exchanges public key fingerprints in DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints
SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS
session over the media channel. The endpoints use the DTLS handshake session over the media channel. The endpoints use the DTLS handshake
to agree on crypto suites and establish SRTP session keys. SRTP to agree on crypto suites and establish SRTP session keys. SRTP
packets are then exchanged between the endpoints. packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round DTLS-SRTP requires one message from offerer to answerer (half round
trip), and, if the offerer wishes to correlate the SDP answer with trip), and, if the offerer wishes to correlate the SDP answer with
the endpoint, requires one message from answer to offerer (full round the endpoint, requires one message from answer to offerer (full round
trip). DTLS-SRTP uses 4 media path messages to establish the SRTP trip). DTLS-SRTP uses 4 media path messages to establish the SRTP
key. key.
skipping to change at page 25, line 20 skipping to change at page 27, line 40
means (i.e., UDP, RTP, RTCP, etc.). means (i.e., UDP, RTP, RTCP, etc.).
Appendix B. Evaluation Criteria - SIP Appendix B. Evaluation Criteria - SIP
This section considers how each keying mechanism interacts with SIP This section considers how each keying mechanism interacts with SIP
features. features.
B.1. Secure Retargeting and Secure Forking B.1. Secure Retargeting and Secure Forking
Retargeting and forking of signaling requests is described within Retargeting and forking of signaling requests is described within
Section 3.2. The following builds upon this description. Section 4.2. The following builds upon this description.
The following list compares the behavior of secure forking, answering The following list compares the behavior of secure forking, answering
association, two-time pads, and secure retargeting for each keying association, two-time pads, and secure retargeting for each keying
mechanism. mechanism.
MIKEY-NULL Secure Forking: No, all AORs see offerer's and MIKEY-NULL Secure Forking: No, all AORs see offerer's and
answerer's keys. Answer is associated with media by the SSRC answerer's keys. Answer is associated with media by the SSRC
in MIKEY. Additionally, a two-time pad occurs if two branches in MIKEY. Additionally, a two-time pad occurs if two branches
choose the same 32-bit SSRC and transmit SRTP packets. choose the same 32-bit SSRC and transmit SRTP packets.
skipping to change at page 27, line 46 skipping to change at page 30, line 22
Secure Retargeting: Yes. The final target calculates a unique Secure Retargeting: Yes. The final target calculates a unique
SRTP key. SRTP key.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
B.2. Clipping Media Before SDP Answer B.2. Clipping Media Before SDP Answer
Clipping media before receiving the signaling answer is described Clipping media before receiving the signaling answer is described
within Section 3.1. The following builds upon this description. within Section 4.1. The following builds upon this description.
Furthermore, the problem of clipping gets compounded when forking is Furthermore, the problem of clipping gets compounded when forking is
used. For example, if using a Diffie-Hellman keying technique with used. For example, if using a Diffie-Hellman keying technique with
security preconditions that forks to 20 endpoints, the call initiator security preconditions that forks to 20 endpoints, the call initiator
would get 20 provisional responses containing 20 signed Diffie- would get 20 provisional responses containing 20 signed Diffie-
Hellman half keys. Calculating 20 DH secrets and validating Hellman half keys. Calculating 20 DH secrets and validating
signatures can be a difficult task depending on the device signatures can be a difficult task depending on the device
capabilities. capabilities.
The following list compares the behavior of clipping before SDP The following list compares the behavior of clipping before SDP
skipping to change at page 29, line 24 skipping to change at page 31, line 46
DTLS-SRTP DTLS-SRTP
Not clipped. Keys are exchanged in the media path without Not clipped. Keys are exchanged in the media path without
relying on the signaling path. relying on the signaling path.
MIKEYv2 Inband MIKEYv2 Inband
Not clipped. Keys are exchanged in the media path without Not clipped. Keys are exchanged in the media path without
relying on the signaling path. relying on the signaling path.
B.3. Centralized Keying B.3. Centralized Keying
Centralized keying is described within Section 3.3. The following Centralized keying is described within Section 4.3. The following
builds upon this description. builds upon this description.
The following list describes how each keying mechanism behaves with The following list describes how each keying mechanism behaves with
centralized keying (scenario d) and rekeying. centralized keying (scenario d) and rekeying.
MIKEY-NULL MIKEY-NULL
Keying: Yes, if offerer is the mixer. No, if offerer is the Keying: Yes, if offerer is the mixer. No, if offerer is the
participant (end user). participant (end user).
Rekeying: Yes, via re-Invite Rekeying: Yes, via re-Invite
skipping to change at page 33, line 39 skipping to change at page 36, line 11
There are two aspects of PKI requirements -- one aspect is if PKI is There are two aspects of PKI requirements -- one aspect is if PKI is
necessary in order for the mechanism to function at all, the other is necessary in order for the mechanism to function at all, the other is
if PKI is used to authenticate a certificate. With interactive if PKI is used to authenticate a certificate. With interactive
communications it is desirable to avoid fetching certificates that communications it is desirable to avoid fetching certificates that
delay call setup; rather it is preferable to fetch or validate delay call setup; rather it is preferable to fetch or validate
certificates in such a way that call setup isn't delayed. For certificates in such a way that call setup isn't delayed. For
example, a certificate can be validated while the phone is ringing or example, a certificate can be validated while the phone is ringing or
can be validated while ring-back tones are being played or even while can be validated while ring-back tones are being played or even while
the called party is answering the phone and saying "hello". the called party is answering the phone and saying "hello".
SRTP key exchange mechanisms that require a global PKI to operate are SRTP key exchange mechanisms that require a particular authentication
gated on the deployment of a common PKI available to both endpoints. infrastructure to operate are gated on the deployment of a such an
This means that no media security is achievable until such a PKI infrastructure available to both endpoints. This means that no media
exists. For SIP, something like sip-certs [I-D.ietf-sip-certs] might security is achievable until such an infrastructure exists. For SIP,
be used to obtain the certificate of a peer. something like sip-certs [I-D.ietf-sip-certs] might be used to obtain
the certificate of a peer.
Note: Even if SIP CERTs was deployed, the retargeting problem Note: Even if sip-certs [I-D.ietf-sip-certs] was deployed, the
(Appendix B.1) would still prevent successful deployment of keying retargeting problem (Appendix B.1) would still prevent successful
techniques which require the offerer to obtain the actual target's deployment of keying techniques which require the offerer to
public key. obtain the actual target's public key.
The following list compares the PKI requirements of each keying The following list compares the PKI requirements of each keying
mechanism, both if a PKI is required for the key exchange itself, and mechanism, both if a PKI is required for the key exchange itself, and
if PKI is only used to authenticate the certificate supplied in if PKI is only used to authenticate the certificate supplied in
signaling. signaling.
MIKEY-NULL MIKEY-NULL
PKI not used. PKI not used.
MIKEY-PSK MIKEY-PSK
skipping to change at page 36, line 39 skipping to change at page 39, line 10
DTLS-SRTP DTLS-SRTP
PFS is achieved if the negotiated cipher suite includes an PFS is achieved if the negotiated cipher suite includes an
exponential or discrete-logarithmic key exchange (such as exponential or discrete-logarithmic key exchange (such as
Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]). Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]).
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
C.3. Best Effort Encryption C.3. Best Effort Encryption
Note: With the ongoing efforts in SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions
reached in this section may no longer be accurate.
With best effort encryption, SRTP is used with endpoints that support With best effort encryption, SRTP is used with endpoints that support
SRTP, otherwise RTP is used. SRTP, otherwise RTP is used.
SIP needs a backwards-compatible best effort encryption in order for SIP needs a backwards-compatible best effort encryption in order for
SRTP to work successfully with SIP retargeting and forking when there SRTP to work successfully with SIP retargeting and forking when there
is a mix of forked or retargeted devices that support SRTP and don't is a mix of forked or retargeted devices that support SRTP and don't
support SRTP. support SRTP.
Consider the case of Bob, with a phone that only does RTP and a Consider the case of Bob, with a phone that only does RTP and a
voice mail system that supports SRTP and RTP. If Alice calls Bob voice mail system that supports SRTP and RTP. If Alice calls Bob
skipping to change at page 37, line 45 skipping to change at page 40, line 12
endpoints to choose RTP/SAVP. As of this writing, this SDP endpoints to choose RTP/SAVP. As of this writing, this SDP
grouping mechanism has not been published as an Internet Draft. grouping mechanism has not been published as an Internet Draft.
session attribute session attribute
With this technique, the endpoints signal their desire to do SRTP With this technique, the endpoints signal their desire to do SRTP
by signaling RTP (RTP/AVP), and using an attribute ("a=") in the by signaling RTP (RTP/AVP), and using an attribute ("a=") in the
SDP. This technique is entirely backwards compatible with non- SDP. This technique is entirely backwards compatible with non-
SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol
registered by SRTP [RFC3711]. registered by SRTP [RFC3711].
SDP Capability Negotiation
SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation] provides a backwards-
compatible mechanism to allow offering both SRTP and RTP in a
single offer. This is the preferred technique.
Probing Probing
With this technique, the endpoints first establish an RTP session With this technique, the endpoints first establish an RTP session
using RTP (RTP/AVP). The endpoints send probe messages, over the using RTP (RTP/AVP). The endpoints send probe messages, over the
media path, to determine if the remote endpoint supports their media path, to determine if the remote endpoint supports their
keying technique. keying technique.
The following list compares the availability of best effort The preferred technique, SDP Capability Negotiation
encryption for each keying mechanism. [I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all
key exchange mechanisms. What remains unique is ZRTP, which can also
MIKEY-NULL accomplish its best effort encryption by probing (sending ZRTP
No best effort encryption. messages over the media path) or by session attribute (see "a=zrtp",
MIKEY-PSK
No best effort encryption.
MIKEY-RSA
No best effort encryption.
MIKEY-RSA-R
No best effort encryption.
MIKEY-DHSIGN
No best effort encryption.
MIKEY-DHHMAC
No best effort encryption.
MIKEYv2 in SDP
No best effort encryption.
Security Descriptions with SIPS
No best effort encryption.
Security Descriptions with S/MIME
No best effort encryption.
SDP-DH
No best effort encryption.
ZRTP
Best effort encryption is done by probing (sending RTP messages
with header extensions) or by session attribute (see "a=zrtp",
defined in Section 10 of [I-D.zimmermann-avt-zrtp]). Current defined in Section 10 of [I-D.zimmermann-avt-zrtp]). Current
implementations of ZRTP use probing. implementations of ZRTP use probing.
EKT
No best effort encryption.
DTLS-SRTP
No best effort encryption.
MIKEY Inband
No best effort encryption.
C.4. Upgrading Algorithms C.4. Upgrading Algorithms
It is necessary to allow upgrading SRTP encryption and hash It is necessary to allow upgrading SRTP encryption and hash
algorithms, as well as upgrading the cryptographic functions used for algorithms, as well as upgrading the cryptographic functions used for
the key exchange mechanism. With SIP's offer/answer model, this can the key exchange mechanism. With SIP's offer/answer model, this can
be computionally expensive because the offer needs to contain all be computionally expensive because the offer needs to contain all
combinations of the key exchange mechanisms (all MIKEY modes, combinations of the key exchange mechanisms (all MIKEY modes,
Security Descriptions) and all SRTP cryptographic suites (AES-128, Security Descriptions) and all SRTP cryptographic suites (AES-128,
AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256) AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256)
that the offerer supports. In order to do this, the offerer has to that the offerer supports. In order to do this, the offerer has to
skipping to change at page 41, line 7 skipping to change at page 42, line 28
Appendix D. Out-of-Scope Appendix D. Out-of-Scope
Discussions concluded that key management for shared-key encryption Discussions concluded that key management for shared-key encryption
of conferencing is outside the scope of this document. As the of conferencing is outside the scope of this document. As the
priority is point-to-point unicast SRTP session keying, resolving priority is point-to-point unicast SRTP session keying, resolving
shared-key SRTP session keying is deferred to later and left as an shared-key SRTP session keying is deferred to later and left as an
item for future investigations. item for future investigations.
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
 End of changes. 95 change blocks. 
437 lines changed or deleted 520 lines changed or added

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