draft-ietf-sip-media-security-requirements-01.txt   draft-ietf-sip-media-security-requirements-02.txt 
SIP D. Wing, Ed. SIP Working Group D. Wing, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational S. Fries Intended status: Informational S. Fries
Expires: May 21, 2008 Siemens AG Expires: July 25, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
November 18, 2007 January 22, 2008
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-01.txt draft-ietf-sip-media-security-requirements-02
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 May 21, 2008. This Internet-Draft will expire on July 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This documents describes requirements for a protocol to negotiate This documents describes requirements for a protocol to negotiate a
security context for SIP-signaled SRTP media. In addition to the security context for SIP-signaled SRTP media. In addition to the
natural security requirements, this negotiation protocol must natural security requirements, this negotiation protocol must
interoperate well with SIP in certain ways. A number of proposals interoperate well with SIP in certain ways. A number of proposals
have been published and a summary of these proposals is in the have been published and a summary of these proposals is in the
appendix of this document. appendix of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Organization . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 7 4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 11 4.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 11
4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Call Setup Performance . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Management Protocol Requirements . . . . . . . . . . . 14 5.1. Key Management Protocol Requirements . . . . . . . . . . . 14
5.2. Attack Scenario Requirements . . . . . . . . . . . . . . . 16 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
5.3. Requirements Outside of the Key Management Protocol . . . 18 5.3. Requirements Outside of the Key Management Protocol . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 22 Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 22
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 23 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 23
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 23 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 23
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 23 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 24
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 24 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 24
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 24 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 24
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 24 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 24
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 24 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 25
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 25 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 25
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 25 A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 25
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 25 A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 25
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 25 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 26
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 25 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 26
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 26 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 26
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 26 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 27
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 27 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 27
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 27 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 27
Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 27 Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 28
B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 27 B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 28
B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 30 B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 30
B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 31 B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 32
B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 33 B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 35 Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 36
C.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 35 C.1. Distribution and Validation of Public Keys and
C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 37 Certificates . . . . . . . . . . . . . . . . . . . . . . . 36
C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 39 C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 38
C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 40 C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 40
Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42 C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Appendix E. Requirement renumbering in -02 . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 46
1. Introduction 1. Introduction
The work on media security started when the Session Initiation The work on media security started when the Session Initiation
Protocol (SIP) was still in its infancy. With the increased SIP Protocol (SIP) was still in its infancy. With the increased SIP
deployment and the availability of new SIP extensions and related deployment and the availability of new SIP extensions and related
protocols, the need for end-to-end security was re-evaluated. The protocols, the need for end-to-end security was re-evaluated. The
procedure of re-evaluating prior protocol work and design decisions procedure of re-evaluating prior protocol work and design decisions
is not an uncommon strategy and, to some extent, considered necessary is not an uncommon strategy and, to some extent, considered necessary
protocol work to ensure that the developed protocols indeed meet the to ensure that the developed protocols indeed meet the previously
previously envisioned needs for the users in the Internet. envisioned needs for the users on the Internet.
This document summarizes media security requirements, i.e., This document summarizes media security requirements, i.e.,
requirements for mechanisms that negotiate security context such as requirements for mechanisms that negotiate security context such as
cryptographic keys and parameters for SRTP. cryptographic keys and parameters for SRTP.
1.1. Document Organization
The organization of this document is as follows: Section 2 introduces The organization of this document is as follows: Section 2 introduces
terminology, Section 3 describes various attack scenarios against the terminology, Section 3 describes various attack scenarios against the
signaling path and media path, Section 4 provides an overview about signaling path and media path, Section 4 provides an overview about
possible call scenarios, Section 5 lists requirements for media possible call scenarios, Section 5 lists requirements for media
security. The main part of the document concludes with the security security. The main part of the document concludes with the security
considerations Section 6, IANA considerations Section 7 and an considerations Section 6, IANA considerations Section 7 and an
acknowledgement section in Section 8. Appendix A lists and compares acknowledgement section in Section 8. Appendix A lists and compares
available solution proposals. The following Appendix B compares the available solution proposals. The following Appendix B compares the
different approaches regarding their suitability for the SIP different approaches regarding their suitability for the SIP
signaling scenarios described in Appendix A, while Appendix C signaling scenarios described in Appendix A, while Appendix C
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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, used SSRC: The 32-bit value that defines the synchronization source, used
in RTP. These are generally unique, but collisions can occur. in RTP. These are generally unique, but collisions can 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 (see [RFC3280])
Perfect Forward Secrecy (PFS): The property that disclosure of the Perfect Forward Secrecy (PFS): The property that disclosure of the
long-term secret keying material that is used to derive an agreed long-term secret keying material that is used to derive an agreed
ephemeral key does not compromise the secrecy of agreed keys from ephemeral key does not compromise the secrecy of agreed keys from
earlier runs. earlier runs.
active adversary: An active adversary attempts to alter system active adversary: An active adversary is able to alter system
resources or affect their operation (see [RFC4949]). resources or affect their operation (see [RFC4949]).
passive adversary: A passive adversary attempts to learn or make use passive adversary: A passive adversary is able to learn or make use
of information from a system but does not affect resources of that of information from a system but does not affect resources of that
system (see [RFC4949]). system (see [RFC4949]).
signaling path: The signaling path is the route taken by SIP signaling path: The signaling path is the route taken by SIP
signaling messages transmitted between the calling and called user signaling messages transmitted between the calling and called user
agents. This can be either direct signaling between the calling agents. This can be either direct signaling between the calling
and called user agents or, more commonly involves the SIP proxy and called user agents or, more commonly involves the SIP proxy
servers that were involved in the call setup. servers that were involved in the call setup.
media path: The media path is the route taken by media packets media path: The media path is the route taken by media packets
exchanged by the endpoints. In the simplest case, the endpoints exchanged by the endpoints. In the simplest case, the endpoints
exchange media directly, and the "media path" is defined by a exchange media directly, and the "media path" is defined by a
quartet of IP addresses and TCP/UDP ports, along with an IP route. quartet of IP addresses and TCP/UDP ports, along with an IP route.
In other cases, this path may include RTP relays, mixers, In other cases, this path may include RTP relays, mixers,
transcoders, session border controllers, NATs, or media gateways. transcoders, session border controllers, NATs, or media gateways.
3. Attack Scenarios 3. Attack Scenarios
The discussion in this section refers to requirements R6, R7, R14, The discussion in this section relates to requirements R-PASS-MEDIA,
R17, and R27. R-PASS-SIG, R-ASSOC, R-SIG-MEDIA, and R-ID-BINDING.
This document classifies adversaries according to their access and This document classifies adversaries according to their access and
their capabilities. An adversary might have access to: their capabilities. An adversary might have access:
1. only the media path, 1. only to the media path,
2. only the signaling path, 2. only to the signaling path,
3. both the media path and the signaling path.
3. to the media path and to the signaling path.
An attacker that can solely be located along the signaling path, and 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 does not have access to media (item 2), is not considered in this
document. document.
There are two different types of adversaries, active and passive. An There are two different types of adversaries, active and passive. An
active adversary may need to be active with regard to the key active adversary may need to be active with regard to the key
exchange relevant information traveling along the media path or exchange relevant information traveling along the media path or
traveling along the signaling path. traveling along the signaling path.
Based on their robustness against the adversary capabilities Based on their robustness against the adversary capabilities
described above, we can group security mechanisms using the following described above, we can group security mechanisms using the following
labels, ordered from least secure at the top to most secure at the labels, ordered from least secure at the top to most secure at the
bottom: bottom:
+---------------+---------+--------------------------------------+
| SIP signaling | media | abbreviation |
+---------------+---------+--------------------------------------+
| none | passive | no-signaling-passive-media |
| none | passive | no-signaling-passive-media |
| passive | passive | passive-signaling-passive-media |
| active | passive | active-signaling-passive-media |
| active | active | active-signaling-active-media |
| active | active | active-signaling-active-media-detect |
+---------------+---------+--------------------------------------+
no-signaling-passive-media: no-signaling-passive-media:
Access to only the media path is sufficient to reveal the content Access to only the media path is sufficient to reveal the content
of the media traffic. This is how unencrypted RTP functions. of the media traffic.
passive-signaling-passive-media: passive-signaling-passive-media:
Passive attack on the signaling and passive attack on the media Passive attack on the signaling and passive attack on the media
path is necessary to reveal the content of the media traffic. path is necessary to reveal the content of the media traffic.
active-signaling-passive-media: active-signaling-passive-media:
Active attack on the signaling path and passive attack on the Active attack on the signaling path and passive attack on the
media path is necessary to reveal the content of the media media path is necessary to reveal the content of the media
traffic. traffic.
no-signaling-active-media:
Active attack on the media path is sufficient to reveal the
content of the media traffic.
active-signaling-active-media: active-signaling-active-media:
Active attack on both the signaling path and the media path is Active attack on both the signaling path and the media path is
necessary to reveal the content of the media traffic. necessary to reveal the content of the media traffic.
detect-attack: active-signaling-active-media-detect:
Active attack on both signaling and media path is necessary to Active attack on both signaling and media path is necessary to
reveal the content of the media traffic (active-signaling-active- reveal the content of the media traffic (active-signaling-active-
media), but the attack is detectable by the end points when media), and the attack is detectable by the end points when the
adversary tampers with the signaling and/or media messages. adversary tampers with the signaling and/or media messages.
For example, Security Descriptions [RFC4568], when protected by TLS For example, unencrypted RTP is vulnerable to no-signaling-passive-
(as it is commonly implemented and deployed), belongs in the passive- media.
signaling-passive-media category since the adversary needs to learn
the Security Descriptions key by seeing the SIP signaling message at As another example, Security Descriptions [RFC4568], when protected
a SIP proxy (assuming that the adversary is in control of the SIP by TLS (as it is commonly implemented and deployed), belongs in the
proxy). The media traffic can be decrypted using that learned key. 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- As another example, DTLS-SRTP falls into active-signaling-active-
media category when DTLS-SRTP is used with a public key based media category when DTLS-SRTP is used with a public key based
ciphersuite with self-signed certificates and without SIP-Identity ciphersuite with self-signed certificates and without SIP-Identity
[RFC4474]. An adversary would have to modify the fingerprint that is [RFC4474]. An adversary would have to modify the fingerprint that is
sent along the signaling path and subsequently to modify the sent along the signaling path and subsequently to modify the
certificates carried in the DTLS handshake that travel along the certificates carried in the DTLS handshake that travel along the
media path. If DTLS-SRTP is used with SIP-Identity [RFC4474] and media path. If DTLS-SRTP is used with SIP-Identity [RFC4474] and
protects both the offer and the answer, it would belong to the protects both the offer and the answer, it would belong to the
detect-attack category. detect-attack category.
skipping to change at page 7, line 33 skipping to change at page 8, line 7
that such attacks are detectable by the endpoints. that such attacks are detectable by the endpoints.
4. Call Scenarios 4. Call Scenarios
The following subsections describe call scenarios that pose the most The following subsections describe call scenarios that pose the most
challenge to the key management system for media data in cooperation challenge to the key management system for media data in cooperation
with SIP signaling. with SIP signaling.
4.1. Clipping Media Before Signaling Answer 4.1. Clipping Media Before Signaling Answer
The discussion in this section refers to requirement R5. The discussion in this section relates to requirement R-AVOID-
CLIPPING.
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)."
skipping to change at page 8, line 10 skipping to change at page 8, line 32
the media -- causing 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 [RFC5027], across all SIP proxies, implement Security Preconditions [RFC5027],
or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer
implements the reliable provisional response mechanism described in implements the reliable provisional response mechanism described in
ICE. Unfortunately, there is not wide deployment of any of these ICE. Unfortunately, there is not wide deployment of any of these
techniques and there is industry reluctance to set requirements techniques and there is industry reluctance to require these
regarding these techniques to avoid the problem described in this techniques to avoid the problems 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, even a solution that makes the media can be received. In this case, even a solution that makes the
key available before the SDP answer arrives will not help. key available before the SDP answer arrives will not help.
Fixes to early media might make the requirements to become obsolete, Fixes to early media (i.e., the media that arrives at the SDP offerer
but at the time of writing no progress has been accomplished. before the SDP answer arrives) might make the requirements to become
obsolete, but at the time of writing no progress has been
accomplished.
4.2. Retargeting and Forking 4.2. Retargeting and Forking
The discussion in this section relates to requirements R1, R2, and The discussion in this section relates to requirements R-FORK-
R3. RETARGET, R-BEST-SECURE, and R-DISTINCT.
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.
+-----+ +-----+
|Alice| |Alice|
+--+--+ +--+--+
| |
| Invite (1) | INVITE (1)
V V
+----+----+ +----+----+
| proxy | | proxy |
++-+-----++ ++-+-----++
| ^ | | ^ |
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 Using retargeting might lead to situations where the UAC does not
know where its request will be going. This might not immediately know where its request will be going. This might not immediately
skipping to change at page 9, line 38 skipping to change at page 9, line 44
different number, who will pick up the line when it rings, and so on. different number, who will pick up the line when it rings, and so on.
However, when considering SIP mechanisms for authenticating the However, when considering SIP mechanisms for authenticating the
called party, this function can also make it difficult to called party, this function can also make it difficult to
differentiate an intermediary that is behaving legitimately from an differentiate an intermediary that is behaving legitimately from an
attacker. From this perspective, the main problems with retargeting attacker. From this perspective, the main problems with retargeting
ares: ares:
Not detectable by the caller: The originating user agent has no Not detectable by the caller: The originating user agent has no
means of anticipating that the condition will arise, nor any means means of anticipating that the condition will arise, nor any means
of determining that it has occurred until the call has already of determining that it has occurred until the call has already
been set up, i.e. the negative consequences have already been been set up.
realized.
Not preventable by the caller: There is no existing security Not preventable by the caller: There is no existing mechanism that
mechanism that might be employed by the originating user agent in might be employed by the originating user agent in order to
order to guarantee that the call will not be re-targeted. 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 the nature of retargeting SIP Identity [RFC4474]. However, due to the nature of retargeting SIP
Identity can only identify the calling party (that is, the party that Identity can only identify the calling party (that is, the party that
initiated the SIP request). Some key exchange mechanisms predate SIP initiated the SIP request). Some key exchange mechanisms predate SIP
Identity and include their own identity mechanism. However, those Identity and include their own identity mechanism (e.g., MIKEY).
built-in identity mechanism also suffer from the SIP retargeting However, those built-in identity mechanism also suffer from the SIP
problem. Going forward, Connected Identity [RFC4916] allows retargeting problem. Going forward, Connected Identity [RFC4916]
identifying the called party. allows identifying the called party.
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|
+--+--+ +--+--+
| |
| Invite | INVITE
V V
+-----+-----+ +-----+-----+
| proxy | | proxy |
++---------++ ++---------++
| | | |
Invite | | Invite INVITE | | INVITE
V V V V
+--+--+ +--+--+ +--+--+ +--+--+
|Bob-1| |Bob-2| |Bob-1| |Bob-2|
+-----+ +-----+ +-----+ +-----+
Figure 2: Forking Figure 2: Forking
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 (forking) and rollover to and secretary might have both phones ring (forking) and rollover to
voice mail if neither phone is answered (retargeting). 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. Forked
only an issue when the key management is encrypted with a key and re-targeted calls only reveal sensitive information to non-
corresponding to the responder. It does not lead to problems with responders when the signaling messages contain sensitive information
DH-based approaches. For key exchange mechanisms that do not provide (e.g., SRTP keys) that is accessible by parties that receive the
secure forking or secure retargeting, one workaround is to re-key offer, but may not respond (i.e., the original recipients in a
immediately after forking or retargeting. However, because the retargeted call, or non-answering endpoints in a forked call). For
originator may not be aware that the call forked this mechanism key exchange mechanisms that do not provide secure forking or secure
requires rekeying immediately after every session is established. retargeting, one workaround is to re-key immediately after forking or
This doubles the number of messages processed by the network. retargeting. However, because the originator may not be aware that
the call forked this mechanism requires rekeying immediately after
every session is established. 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 (or a shared secret established previously), the actual recipient key (or a shared secret established previously), the actual recipient
will not be able to decrypt that material because the recipient won't will not be able to decrypt that material because the recipient won't
have the original recipient's private key. In some cases, this is have the original recipient's private key. In some cases, this is
the intended behavior, i.e., you wanted to establish a secure the intended behavior, i.e., you wanted to establish a secure
connection with a specific individual. In other cases, it is not connection with a specific individual. In other cases, it is not
intended behavior (you want all voice media to be encrypted, intended behavior (you want all voice media to be encrypted,
regardless of who answers). regardless of who answers).
Further compounding this problem is a particularity of SIP that when Further compounding this problem is a unique feature 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. Because [I-D.mahy-sipping-herfp-fix], is difficult to solve in SIP. Because
skipping to change at page 13, line 4 skipping to change at page 13, line 13
for each participant and has the advantage of non-repudiation of the for each participant and has the advantage of non-repudiation of the
originator of the incoming stream. originator of the incoming stream.
To support a single outbound session (scenario d), the mixer has to To support a single outbound session (scenario d), the mixer has to
dictate its encryption key to the participants. Some keying dictate its encryption key to the participants. Some keying
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.4. Recording 4.4. Recording
The discussion in this section relates to requirement R23. The discussion in this section relates to requirement R-RECORDING.
Some business environments, such as stock brokers, banks, and catalog Some business environments, such as stock brokers, banks, and catalog
call centers, require recording calls with customers. This is the call centers, require recording calls with customers. This is the
familiar "this call is being recorded for quality purposes" heard familiar "this call is being recorded for quality purposes" heard
during calls to these sorts of businesses. In these environments, during calls to these sorts of businesses. In these environments,
media recording is typically performed by an intermediate device media recording is typically performed by an intermediate device
(with RTP, this is typically implemented in a 'sniffer'). (with RTP, this is typically implemented in a 'sniffer').
When performing such call recording with SRTP, the end-to-end When performing such call recording with SRTP, the end-to-end
security is compromised. This is unavoidable, but necessary because security is compromised. This is unavoidable, but necessary because
skipping to change at page 13, line 35 skipping to change at page 13, line 44
informed that there is an intermediate device and needs to cooperate informed that there is an intermediate device and needs to cooperate
with that intermediate device. with that intermediate device.
This scenario does not place a requirement directly on the key This scenario does not place a requirement directly on the key
management protocol. The requirement could be met directly by the management protocol. The requirement could be met directly by the
key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an
external out-of-band-mechanism (e.g., [I-D.wing-sipping-srtp-key]). external out-of-band-mechanism (e.g., [I-D.wing-sipping-srtp-key]).
4.5. PSTN gateway 4.5. PSTN gateway
The discussion in this section relates to requirement R26. The discussion in this section relates to requirement R-PSTN.
A typical case of using media security is the one where two entities A typical case of using media security where two entities are having
are having a VoIP conversation over IP capable networks. However, a VoIP conversation over IP capable networks. However, there are
there are cases where the other end of the communication is not cases where the other end of the communication is not connected to an
connected to an IP capable network. In this kind of setting, there IP capable network. In this kind of setting, there needs to be some
needs to be some kind of gateway at the edge of the IP network which kind of gateway at the edge of the IP network which converts the VoIP
converts the VoIP conversation to format understood by the other conversation to format understood by the other network. An example
network. An example of such gateway is a PSTN gateway sitting at the of such gateway is a PSTN gateway sitting at the edge of IP and PSTN
edge of IP and PSTN networks. networks (such as the architecture described in [RFC3372]).
If media security (e.g., SRTP protection) is employed in this kind of If media security (e.g., SRTP protection) is employed in this kind of
gateway-setting, then media security and the related key management gateway-setting, then media security and the related key management
needs to be terminated at the gateway. The other network (e.g., is terminated at the PSTN gateway. The other network (e.g., PSTN)
PSTN) may have its own measures to protect the communication, but may have its own measures to protect the communication, but this
this means that from media security point of view the media security means that from media security point of view the media security is
is not employed end-to-end between the communicating entities. not employed truely end-to-end between the communicating entities.
4.6. Call Setup Performance
The discussion in this section relates to requirement R-REUSE.
Some devices lack sufficient processing power to perform public key
operations or Diffie-Hellman operations for each call, or prefer to
avoid performing those operations on every call. The ability to re-
use previous public key or Diffie-Hellman operations can vastly
decrease the call setup delay and processing requirements for such
devices.
In certain devices, it can take a second or two to perform a Diffie-
Hellman operation. Examples of these devices include handsets, IP
Multimedia Services Identity Module (ISIMs), and PSTN gateways. PSTN
gateways typically utilize a Digital Signal Processor (DSP) which is
not yet involved with typical DSP operations at the beginning of a
call, thus the DSP could be used to perform the calculation, so as to
avoid having the central host processor perform the calculation.
However, not all PSTN gateways use DSPs (some have only central
processors or their DSPs are incapable of performing the necessary
public key or Diffie-Hellman operation), and handsets lack a
separate, unused processor to perform these operations.
5. Requirements 5. Requirements
This section is divided into several parts: requirements specific to This section is divided into several parts: requirements specific to
the key management protocol (Section 5.1), attack scenarios the key management protocol (Section 5.1), attack scenarios
(Section 5.2), and requirements which can be met inside the key (Section 5.2), and requirements which can be met inside the key
management protocol or outside of the key management protocol management protocol or outside of the key management protocol
(Section 5.3). (Section 5.3).
5.1. Key Management Protocol Requirements 5.1. Key Management Protocol Requirements
SIP Forking and Retargeting, from Section 4.2: SIP Forking and Retargeting, from Section 4.2:
R1: The media security key management protocol MUST support forking R-FORK-RETARGET The media security key management protocol MUST
and retargeting when all endpoints are willing to use SRTP support forking and retargeting when all endpoints are willing
without causing the call setup to fail, unless the execution of to use SRTP without causing the call setup to fail, unless the
the authentication and key exchange protocol leads to a failure execution of the authentication and key exchange protocol leads
(e.g., an unsuccessful authentication attempt). to a failure (e.g., an unsuccessful authentication attempt).
R3: The media security key management protocol MUST create R-DISTINCT The media security key management protocol MUST be capble
distinct, independent cryptographic contexts for each endpoint of creating distinct, independent cryptographic contexts for
in a forked session. each endpoint in a forked session.
Security characteristics: Performance considerations:
R8: The media security key management protocol MUST be able to R-REUSE The media security key management protocol MUST support the
re-use of a previously established security context, and
implementations SHOULD implement the re-use mechanism.
Media considerations:
R-AVOID-CLIPPING The media security key management protocol SHOULD
avoid clipping media before SDP answer without requiring PRACK
[RFC3262]. This requirement comes from Section 4.1.
R-RTP-VALID 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].
R-ASSOC 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.,
Diffie-Hellman or public key operations) with attackers that
have not seen the signaling messages.
For example, if using a Diffie-Hellman keying technique with
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.
R-NEGOTIATE The media security key management protocol MUST allow a
SIP User Agent to negotiate media security parameters for each
individual session.
R-PSTN The media security key management protocol MUST support
termination of media security in a PSTN gateway. This
requirement is from Section 4.5.
5.2. Security Requirements
This section describes overall security requirements and specific
requirements from the attack scenarios (Section 3).
Overall security requirements:
R-PFS The media security key management protocol MUST be able to
support perfect forward secrecy. support perfect forward secrecy.
R9: The media security key management protocol MUST support R-COMPUTE 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 a multiple SRTP
built without incurring computational expense for each cipher suites to be negotiated without incurring computational
algorithm. expense for each cipher suite.
R12: The media security key management protocol MUST NOT require 3rd R-CERTS If the media security key management protocol employs
parties to sign certificates. certificates, it MUST be able to make use of both self-signed
and CA-issued certificates. As an alternative, the media
security key management protocol MAY make use of "bare" public
keys.
R13: The media security key management protocol SHOULD use R-FIPS 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 this systems, including voice systems. The adoption and use of 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.
R16: The media security key management protocol SHOULD NOT introduce R-DOS The media security key management protocol SHOULD NOT introduce
new denial of service vulnerabilities (e.g., the protocol new denial of service vulnerabilities (e.g., the protocol
should not request the endpoint to perform CPU-intensive should not request the endpoint to perform CPU-intensive
operations without the client being able to validate or operations without the client being able to validate or
authorize the request). authorize the request).
R18: If two parties share an authentication infrastructure, they R-EXISTING The media security key management protocol SHOULD allow
SHOULD be able to make use of it. endpoints to authenticate using pre-existing cryptographic
credentials, e.g., certificates or pre-shared keys.
R19: The media security key management protocol MUST provide crypto- R-AGILITY The media security key management protocol MUST provide
agility, i.e., the ability to adapt to evolving cryptography crypto-agility, i.e., the ability to adapt to evolving
and security requirements (update of cryptographic algorithms cryptography and security requirements (update of cryptographic
without substantial disruption to deployed implementations) algorithms without substantial disruption to deployed
implementations)
R20: The media security key management protocol MUST protect cipher R-DOWNGRADE The media security key management protocol MUST protect
suite negotiation against downgrading attacks. cipher suite negotiation against downgrading attacks.
R24: <deleted> R24: <deleted>
Performance considerations: R-PASS-MEDIA The media security key management protocol MUST have a
mode which prevents a passive adversary with access to the
R4: The media security key management protocol MAY support the re- media path from gaining access to keying material used to
use of a previously established security context.
Specialized devices may need to avoid public key operations or
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.
R11: <Requirement R11 has been folded into R4.>
Media considerations:
R5: The media security key management protocol SHOULD avoid
clipping media before SDP answer without requiring PRACK
[RFC3262]. This requirement comes from Section 4.1.
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].
R15: The media security key management protocol SHOULD allow
endpoints to start with RTP and then upgrade to SRTP.
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?
R21: The media security key management protocol MUST allow a SIP
User Agent to negotiate media security parameters for each
individual session.
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.
Issue: Unclear how requirement for transcoders is met.
R26: The media security key management protocol MUST support
termination of media security in a PSTN gateway. This
requirement is from Section 4.5.
5.2. Attack Scenario Requirements
This section describes requirements from the attack scenarios
(Section 3).
Required for the passive-signaling-passive-media scenario:
R6: The media security key management protocol MUST have a mode
which prevents a passive adversary with access to the media
path from gaining access to keying material used to protect
SRTP media packets.
R7: The media security key management protocol MUST have a mode in
which it prevents a passive adversary with access to the
signaling path from gaining access to keying material used to
protect SRTP media packets. protect SRTP media packets.
Required for the active-signaling-passive-media scenario: R-PASS-SIG The media security key management protocol MUST have a
mode in which it prevents a passive adversary with access to
R14: The media security key management protocol SHOULD include a the signaling path from gaining access to keying material used
mechanism for associating key management messages with both the to protect SRTP media packets.
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.
For example, if using a Diffie-Hellman keying technique with
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.
Required for the active-signaling-active-media scenario:
R17: The media security key management protocol SHOULD require the R-SIG-MEDIA The media security key management protocol SHOULD
adversary to have access to the signaling path as well as the require the adversary to have access to the signaling path as
media path for a successful attack to be launched. An well as the media path for a successful attack to be launched.
adversary that is located only along the data or only along the An adversary that is located only along the media path or only
signaling path MUST NOT be able to successfully mount an along the signaling path MUST NOT be able to successfully mount
attack. A successful attack refers to the ability for the an attack. A successful attack refers to the ability for the
adversary to obtain keying material to decrypt the SRTP adversary to obtain keying material to decrypt the SRTP
encrypted media traffic. encrypted media traffic.
Required for the detect-attack scenario:: R-ID-BINDING When the media security key management protocol uses
identifiers for endpoints other than the From: addresses
asserted by SIP-Identity [RFC4474] and SIP-Connected-Identity
[RFC4916] (e.g., public keys, hashes, or certificate
fingerprints), it MUST provide a mechanism for binding those
identifiers to the From: address. For example, the protocol
could include the identifier in an SDP offer or a SIP header
that is covered by the Identity signature.
R27: The media security key management protocol SHOULD include R-ACT-ACT The media security key management protocol MUST support a
information in the SDP that can be signed by SIP signaling and mode operation that provides active-signaling-active-media-
validated by the either party (e.g., SIP-Identity [RFC4474] and detect robustness, and MAY support modes of operation that
SIP-Connected-Identity [RFC4916]). This allows the both provide lower levels of robustness (as described in Section 3).
parties to validate the From: address. The called party can
validate the From: address prior to accepting the call.
5.3. Requirements Outside of the Key Management Protocol 5.3. Requirements Outside of the Key Management Protocol
The requirements in this section can be solved within the key The requirements in this section are for an overall VoIP security
management protocol itself, or can be solved outside of the key system. These requirements can be met within the key management
management protocol itself (e.g., solved in SIP or in SDP). protocol itself, or can be solved outside of the key management
protocol itself (e.g., solved in SIP or in SDP).
R2: Even when some end points of a forked or retargeted call are R-BEST-SECURE Even when some end points of a forked or retargeted
incapable of using SRTP, the solution MUST be described which call are incapable of using SRTP, a solution MUST be described
allows the establishment of SRTP associations with SRTP-capable which allows the establishment of SRTP associations with SRTP-
endpoints and / or RTP associations with non-SRTP-capable capable endpoints and / or RTP associations with non-SRTP-
endpoints. This requirement comes from Section 4.2. capable endpoints. This requirement comes from Section 4.2.
R23: The media security key management protocol SHOULD be able to R-OTHER-SIGNALING A solution SHOULD be able to negotiate keys for
negotiate keys for SRTP sessions created via different call SRTP sessions created via different call signaling protocols
signaling protocols (e.g., between Jabber, SIP, H.323, MGCP). (e.g., between Jabber, SIP, H.323, MGCP).
R23: A solution SHOULD be described which supports recording of R-RECORDING A solution SHOULD be described which supports recording
decrypted media. This requirement comes from Section 4.4. of decrypted media. This requirement comes from Section 4.4.
R-TRANSCODER A solution SHOULD be described which supports
intermediate nodes (e.g., transcoders), terminating or
processing media, between the end points.
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 19, line 7 skipping to change at page 19, line 17
For contributions to the analysis portion of this document, the For contributions to the analysis portion of this document, the
authors would like to thank Special thanks to Steffen Fries and authors would like to thank Special thanks to Steffen Fries and
Dragan Ignjatic for their excellent MIKEY comparison document Dragan Ignjatic for their excellent MIKEY comparison document
[I-D.ietf-msec-mikey-applicability]. The authors would furthermore [I-D.ietf-msec-mikey-applicability]. The authors would furthermore
like to thank Cullen Jennings, David Oran, David McGrew, Mark like to thank Cullen Jennings, David Oran, David McGrew, Mark
Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric
Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan
Ignjatic and John Elwell for their feedback to this document. Ignjatic and John Elwell for their feedback to this document.
Thanks to Richard Barnes for his thorough reviews and suggestions
which improved the document considerably.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-140-2] [FIPS-140-2]
NIST, "Security Requirements for Cryptographic Modules", NIST, "Security Requirements for Cryptographic Modules",
June 2005, <http://csrc.nist.gov/publications/fips/ June 2005, <http://csrc.nist.gov/publications/fips/
fips140-2/fips1402.pdf>. fips140-2/fips1402.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 20, line 28 skipping to change at page 20, line 41
November 2007. 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-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-07 (work in draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), October 2007. progress), December 2007.
[I-D.ietf-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 21, line 26 skipping to change at page 21, line 39
Wing, D., Audet, F., Fries, S., and H. Tschofenig, Wing, D., Audet, F., Fries, S., and H. Tschofenig,
"Disclosing Secure RTP (SRTP) Session Keys with a SIP "Disclosing Secure RTP (SRTP) Session Keys with a SIP
Event Package", draft-wing-sipping-srtp-key-02 (work in Event Package", draft-wing-sipping-srtp-key-02 (work in
progress), November 2007. 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 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
X.509 Public Key Infrastructure Certificate and for Telephones (SIP-T): Context and Architectures",
Certificate Revocation List (CRL) Profile", RFC 3280, BCP 63, RFC 3372, September 2002.
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.
skipping to change at page 24, line 9 skipping to change at page 24, line 22
share one common key. MIKEY-PSK has the offerer encrypt the SRTP share one common key. MIKEY-PSK has the offerer encrypt the SRTP
keys for both directions using this pre-shared key. keys for both directions using this pre-shared key.
MIKEY-PSK requires one message from offerer to answerer (half a round MIKEY-PSK requires one message from offerer to answerer (half a round
trip), and does not add additional media path messages. trip), and does not add additional media path messages.
A.1.3. MIKEY-RSA A.1.3. MIKEY-RSA
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 mechanism outside of MIKEY.
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 [RFC4738] is essentially the same as MIKEY-RSA but MIKEY-RSA-R [RFC4738] is essentially the same as MIKEY-RSA but
reverses the role of the offerer and the answerer with regards to reverses the role of the offerer and the answerer with regards to
providing the keys. That is, the answerer encrypts the keys for both providing the keys. That is, the answerer encrypts the keys for both
directions using the offerer's public key. Both the offerer and directions using the offerer's public key. Both the offerer and
answerer validate each other's public keys using a PKI. MIKEY-RSA-R answerer validate each other's public keys using a standard X.509
also enables sending certificates in the MIKEY message. validation techniques. MIKEY-RSA-R also 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-
in-the-middle the DH exchange itself is signed using each endpoint's in-the-middle the DH exchange itself is signed using each endpoint's
private key and the associated public keys are validated using a PKI. private key and the associated public keys are validated using
standard X.509 validation techniques.
MIKEY-DHSIGN requires one message from offerer to answerer, and one MIKEY-DHSIGN requires one message from offerer to answerer, 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-DHSIGN requires the offerer additional media path messages. MIKEY-DHSIGN requires the offerer
and answerer to validate each other's certificates. MIKEY-DHSIGN and answerer to validate each other's certificates. MIKEY-DHSIGN
also enables sending the answerer's certificate in the MIKEY message. also enables sending the answerer's certificate in the MIKEY message.
A.1.6. MIKEY-DHHMAC A.1.6. MIKEY-DHHMAC
MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie- MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-
Hellman exchange, essentially combining aspects of MIKEY-PSK with Hellman exchange, essentially combining aspects of MIKEY-PSK with
MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a PKI to MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for certificate
authenticate the Diffie-Hellman exchange. authentication.
MIKEY-DHHMAC requires one message from offerer to answerer, and one MIKEY-DHHMAC requires one message from offerer to answerer, 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. additional media path messages.
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)
ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC
can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY- can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY-
DHSIGN (using a new DH-Group code), and also defines two new ECC- DHSIGN (using a new DH-Group code), and also defines two new ECC-
based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES)
and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) . and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) .
For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group function exactly like MIKEY-RSA, and the new DH-Group code function
code function exactly like MIKEY-DHSIGN. Therefore these ECC exactly like MIKEY-DHSIGN. Therefore these ECC mechanisms are not
mechanisms aren't discussed separately in this paper. discussed separately in this document.
A.1.8. Security Descriptions with SIPS A.1.8. Security Descriptions with SIPS
Security Descriptions [RFC4568] has each side indicate the key it Security Descriptions [RFC4568] has each side indicate the key it
will use for transmitting SRTP media, and the keys are sent in the will use for transmitting SRTP media, and the keys are sent in the
clear in SDP. Security Descriptions relies on hop-by-hop (TLS via clear in SDP. Security Descriptions relies on hop-by-hop (TLS via
"SIPS:") encryption to protect the keys exchanged in signaling. "SIPS:") encryption to protect the keys exchanged in signaling.
Security Descriptions requires one message from offerer to answerer, Security Descriptions requires one message from offerer to answerer,
and one message from answerer to offerer (full round trip), and does and one message from answerer to offerer (full round trip), and does
skipping to change at page 27, line 21 skipping to change at page 27, line 39
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.
This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as
cipher suite, which is the mandatory-to-implement cipher suite in TLS its cipher suite, which is the mandatory-to-implement cipher suite in
[RFC4346]. TLS [RFC4346].
A.3.3. MIKEYv2 Inband (expired) A.3.3. MIKEYv2 Inband (expired)
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band As defined in Appendix A.1.11, MIKEYv2 also defines an in-band
negotiation mode as an alternative to SDP (see Appendix A.3.3). The negotiation mode as an alternative to SDP (see Appendix A.3.3). The
details are not sorted out in the draft yet on what in-band actually details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.). means (i.e., UDP, RTP, RTCP, etc.).
Appendix B. Evaluation Criteria - SIP Appendix B. Evaluation Criteria - SIP
skipping to change at page 32, line 9 skipping to change at page 32, line 25
Centralized keying is described within Section 4.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
MIKEY-PSK MIKEY-PSK
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, with a re-Invite Rekeying: Yes, with a re-INVITE
MIKEY-RSA MIKEY-RSA
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, with a re-Invite Rekeying: Yes, with a re-INVITE
MIKEY-RSA-R MIKEY-RSA-R
Keying: No, if offerer is the mixer. Yes, if offerer is the Keying: No, if offerer is the mixer. Yes, if offerer is the
participant (end user). participant (end user).
Rekeying: n/a Rekeying: n/a
MIKEY-DHSIGN MIKEY-DHSIGN
Keying: No; a group-key Diffie-Hellman protocol is not Keying: No; a group-key Diffie-Hellman protocol is not
supported. supported.
skipping to change at page 32, line 48 skipping to change at page 33, line 17
Rekeying: n/a Rekeying: n/a
MIKEYv2 in SDP MIKEYv2 in SDP
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
Security Descriptions with SIPS Security Descriptions with SIPS
Keying: Yes, if offerer is the mixer. Yes, if offerer is the Keying: Yes, if offerer is the mixer. Yes, if offerer is the
participant. participant.
Rekeying: Yes, with a Re-Invite. Rekeying: Yes, with a re-INVITE.
Security Descriptions with S/MIME Security Descriptions with S/MIME
Keying: Yes, if offerer is the mixer. Yes, if offerer is the Keying: Yes, if offerer is the mixer. Yes, if offerer is the
participant. participant.
Rekeying: Yes, with a Re-Invite. Rekeying: Yes, with a re-INVITE.
SDP-DH SDP-DH
Keying: No; a group-key Diffie-Hellman protocol is not Keying: No; a group-key Diffie-Hellman protocol is not
supported. supported.
Rekeying: n/a Rekeying: n/a
ZRTP ZRTP
Keying: No; a group-key Diffie-Hellman protocol is not Keying: No; a group-key Diffie-Hellman protocol is not
supported. supported.
skipping to change at page 35, line 47 skipping to change at page 36, line 18
MIKEYv2 Inband MIKEYv2 Inband
Each endpoint indicates a set of SSRCs and the ROC for SRTP Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits. packets it transmits.
Appendix C. Evaluation Criteria - Security Appendix C. Evaluation Criteria - Security
This section evaluates each keying mechanism on the basis of their This section evaluates each keying mechanism on the basis of their
security properties. security properties.
C.1. Public Key Infrastructure C.1. Distribution and Validation of Public Keys and Certificates
There are two aspects of PKI requirements -- one aspect is if PKI is Using public key cryptography for confidentiality and authentication
necessary in order for the mechanism to function at all, the other is can introduce requirements for two types of systems: (1) a system to
if PKI is used to authenticate a certificate. With interactive distribute public keys (often in the form of certificates), and (2) a
communications it is desirable to avoid fetching certificates that system for validating certificates. We refer to the former as a key
delay call setup; rather it is preferable to fetch or validate distribution system and the latter as an authentication
certificates in such a way that call setup isn't delayed. For infrastructure. In many cases, a monolithic public key
example, a certificate can be validated while the phone is ringing or infrastructure (PKI) is used for fulfill both of these roles.
can be validated while ring-back tones are being played or even while However, these functions can be provided by many other systems. For
the called party is answering the phone and saying "hello". instance, key distribution may be accomplished by any public
repository of keys. Any system in which the two endpoints have
access to trust anchors and intermediate CA certificates that can be
used to validate other endpoints' certificates (including a system of
self-signed certificates) can be used to support certificate
validation in the below schemes.
With real-time communications it is desirable to avoid fetching keys
or certificates that delay call setup; rather it is preferable to
fetch or validate certificates in such a way that call setup isn't
delayed. For 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 the called party is answering the phone and saying
"hello".
SRTP key exchange mechanisms that require a particular authentication SRTP key exchange mechanisms that require a particular authentication
infrastructure to operate are gated on the deployment of a such an infrastructure to operate (whether for distribution or validation)
infrastructure available to both endpoints. This means that no media are gated on the deployment of a such an infrastructure available to
security is achievable until such an infrastructure exists. For SIP, both endpoints. This means that no media security is achievable
something like sip-certs [I-D.ietf-sip-certs] might be used to obtain until such an infrastructure exists. For SIP, something like sip-
the certificate of a peer. certs [I-D.ietf-sip-certs] might be used to obtain the certificate of
a peer.
Note: Even if sip-certs [I-D.ietf-sip-certs] was deployed, the Note: Even if sip-certs [I-D.ietf-sip-certs] was deployed, the
retargeting problem (Appendix B.1) would still prevent successful retargeting problem (Appendix B.1) would still prevent successful
deployment of keying techniques which require the offerer to deployment of keying techniques which require the offerer to
obtain the actual target's public key. obtain the actual target's public key.
The following list compares the PKI requirements of each keying The following list compares the requirements introduced by the use of
mechanism, both if a PKI is required for the key exchange itself, and public-key cryptography in each keying mechanism, both for public key
if PKI is only used to authenticate the certificate supplied in distribution and for certificate validation.
signaling.
MIKEY-NULL MIKEY-NULL
PKI not used. Public-key cryptography is not used.
MIKEY-PSK MIKEY-PSK
PKI not used; rather, all endpoints must have some way to Public-key cryptography is not used. Rather, all endpoints
exchange per-endpoint or per-system pre-shared keys. must have some way to exchange per-endpoint or per-system pre-
shared keys.
MIKEY-RSA MIKEY-RSA
The offerer obtains the intended answerer's public key before The offerer obtains the intended answerer's public key before
initiating the call. This public key is used to encrypt the initiating the call. This public key is used to encrypt the
SRTP keys. There is no defined mechanism for the offerer to SRTP keys. There is no defined mechanism for the offerer to
obtain the answerer's public key, although [I-D.ietf-sip-certs] obtain the answerer's public key, although [I-D.ietf-sip-certs]
might be viable in the future. might be viable in the future.
The offer may also contain a certificate for the offeror, which
would require an authentication infrastructure in order to be
validated by the receiver.
MIKEY-RSA-R MIKEY-RSA-R
The offer contains the offerer's public key. The answerer uses The offer contains the offerer's certificate, and the answer
that public key to encrypt the SRTP keys that will be used by contains the answerer's certificate. The answerer uses the
the offerer and the answerer. A PKI is necessary to validate public key in the certificate to encrypt the SRTP keys that
the certificates. will be used by the offerer and the answerer. An
authentication infrastructure is necessary to validate the
certificates.
MIKEY-DHSIGN MIKEY-DHSIGN
PKI is used to authenticate the public key that is included in An authentication infrastructure is used to authenticate the
the MIKEY message, by walking the CA trust chain. public key that is included in the MIKEY message.
MIKEY-DHHMAC MIKEY-DHHMAC
PKI not used; rather, all endpoints must have some way to Public-key cryptography is not used. Rather, all endpoints
exchange per-endpoint or per-system pre-shared keys. must have some way to exchange per-endpoint or per-system pre-
shared keys.
MIKEYv2 in SDP MIKEYv2 in SDP
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
Security Descriptions with SIPS Security Descriptions with SIPS
PKI not used. Public-key cryptography is not used.
Security Descriptions with S/MIME Security Descriptions with S/MIME
PKI is needed for S/MIME. The offerer must obtain the intended Use of S/MIME requires that the endpoints be able to fetch and
target's public key and encrypt their SDP with that key. The validate certificates for each other. The offerer must obtain
answerer must obtain the offerer's public key and encrypt their the intended target's certificate and encrypts the SDP offer
SDP with that key. with the public key contained in target's certificate. The
answerer must obtain the offerer's certificate and encrypt the
SDP answer with the public key contained in the offerer's
certificate.
SDP-DH SDP-DH
PKI not used. Public-key cryptography is not used.
ZRTP ZRTP
PKI not used. Public-key cryptography is not used.
EKT EKT
PKI not used by EKT itself, but might be used by the EKT Public-key cryptography is not used by itself, but might be
bootstrapping keying mechanism (such as certain MIKEY modes). used by the EKT bootstrapping keying mechanism (such as certain
MIKEY modes).
DTLS-SRTP DTLS-SRTP
Remote party's certificate is sent in media path, and a Remote party's certificate is sent in media path, and a
fingerprint of the same certificate is sent in the signaling fingerprint of the same certificate is sent in the signaling
path. path.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
C.2. Perfect Forward Secrecy C.2. Perfect Forward Secrecy
skipping to change at page 42, line 26 skipping to change at page 43, line 21
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
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.
Appendix E. Requirement renumbering in -02
[[RFC Editor: Please delete this section prior to publication.]]
Previous versions of this document used requirement numbers, which
were changed to mnemonics as follows:
R1 R-FORK-RETARGET
R2 R-BEST-SECURE
R3 R-DISTINCT
R4 R-REUSE; changed from 'MAY' to 'protocol MUST support, and
SHOULD implement'
R5 R-AVOID-CLIPPING
R6 R-PASS-MEDIA
R7 R-PASS-SIG
R8 R-PFS
R9 R-COMPUTE
R10 R-RTP-VALID
R11 (folded into R4; was reuse previous session)
R12 R-CERTS
R13 R-FIPS
R14 R-ASSOC
R15 (deleted; was ability to upgrade from RTP to SRTP, but
requirement was unclear on what it meant)
R16 R-DOS
R17 R-SIG-MEDIA
R18 R-EXISTING
R19 R-AGILITY
R20 R-DOWNGRADE
R21 R-NEGOTIATE
R23 R-OTHER-SIGNALING
R23 R-RECORDING (R23 was duplicated in previous versions of the
document)
R24 (deleted; was lawful intercept)
R25 R-TRANSCODER
R26 R-PSTN
R27 R-ID-BINDING
R28 R-ACT-ACT
Authors' Addresses Authors' Addresses
Dan Wing (editor) 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
skipping to change at page 44, line 7 skipping to change at page 46, line 7
Francois Audet Francois Audet
Nortel Nortel
4655 Great America Parkway 4655 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: audet@nortel.com Email: audet@nortel.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 106 change blocks. 
314 lines changed or deleted 430 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/