draft-ietf-sip-media-security-requirements-02.txt   draft-ietf-sip-media-security-requirements-03.txt 
SIP Working Group 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: July 25, 2008 Siemens AG Expires: August 27, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
January 22, 2008 February 24, 2008
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-02 draft-ietf-sip-media-security-requirements-03
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 July 25, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This documents describes requirements for a protocol to negotiate a This document 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8 4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 9
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 4.6. Call Setup Performance . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Key Management Protocol Requirements . . . . . . . . . . . 14 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16 5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.3. Requirements Outside of the Key Management Protocol . . . 18 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5.3. Requirements Outside of the Key Management Protocol . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 23 Appendix A. Overview and Evaluation of Existing Keying
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 23 Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 24 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 24
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 24 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 24 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 24 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 25 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 25 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 25 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 25 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 26 A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 26 A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 26 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 27
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 27
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 27 A.1.12. Evaluation Criteria - SIP . . . . . . . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.1.13. Evaluation Criteria - Security . . . . . . . . . . . . 36
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 27 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 43
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 27 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 28 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 43
B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 28 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 30 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 44
B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 32 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 44
B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 44
Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 36 Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44
C.1. Distribution and Validation of Public Keys and Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Certificates . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 48
C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 38
C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 40
C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 41
Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 43
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
to ensure that the developed protocols indeed meet the previously to ensure that the developed protocols indeed meet the previously
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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.
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 A.1.12 compares
different approaches regarding their suitability for the SIP the 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 A.1.13
provides a comparison regarding security aspects. Appendix D lists provides a comparison regarding security aspects. Appendix B lists
non-goals for this document. 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.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
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, 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 keystream 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.
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 is able to alter system active adversary: An active adversary is able to alter data
resources or affect their operation (see [RFC4949]). communication to affect its operation (see also [RFC4949]).
passive adversary: A passive adversary is able to learn or make use passive adversary: A passive adversary is able to learn information
of information from a system but does not affect resources of that from data communication, but not alter that data communication
system (see [RFC4949]). (see also[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 relates to requirements R-PASS-MEDIA, The discussion in this section relates to requirements R-PASS-MEDIA,
R-PASS-SIG, R-ASSOC, R-SIG-MEDIA, and R-ID-BINDING. R-PASS-SIG, R-ASSOC, R-SIG-MEDIA, R-ACT-ACT, 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: their capabilities. An adversary might have access:
1. only to the media path, 1. only to the media path,
2. only to the signaling path, 2. only to the signaling path,
3. to the media path and to the signaling path. 3. to the media path and to the signaling path.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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. This list is generally ordered from easiest to compromise
bottom: (at the top) to more difficult to compromise:
+---------------+---------+--------------------------------------+ +---------------+---------+--------------------------------------+
| SIP signaling | media | abbreviation | | SIP signaling | media | abbreviation |
+---------------+---------+--------------------------------------+ +---------------+---------+--------------------------------------+
| none | passive | no-signaling-passive-media | | none | passive | no-signaling-passive-media |
| none | passive | no-signaling-passive-media | | none | active | no-signaling-active-media |
| passive | passive | passive-signaling-passive-media | | passive | passive | passive-signaling-passive-media |
| passive | active | passive-signaling-active-media |
| active | passive | active-signaling-passive-media | | active | passive | active-signaling-passive-media |
| active | active | active-signaling-active-media | | active | active | active-signaling-active-media |
| active | active | active-signaling-active-media-detect | | 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. 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.
passive-signaling-active-media:
Passive attack on the signaling and active attack on the media
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: no-signaling-active-media:
Active attack on the media path is sufficient to reveal the Active attack on the media path is sufficient to reveal the
content of the media traffic. 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.
active-signaling-active-media-detect: 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 (as with active-signaling-
media), and the attack is detectable by the end points when the active-media), and the attack is detectable by protocol messages
adversary tampers with the signaling and/or media messages. exchanged between the end points.
For example, unencrypted RTP is vulnerable to no-signaling-passive- For example, unencrypted RTP is vulnerable to no-signaling-passive-
media. media.
As another example, Security Descriptions [RFC4568], when protected As another example, Security Descriptions [RFC4568], when protected
by TLS (as it is commonly implemented and deployed), belongs in the by TLS (as it is commonly implemented and deployed), belongs in the
passive-signaling-passive-media category since the adversary needs to passive-signaling-passive-media category since the adversary needs to
learn the Security Descriptions key by seeing the SIP signaling learn the Security Descriptions key by seeing the SIP signaling
message at a SIP proxy (assuming that the adversary is in control of message at a SIP proxy (assuming that the adversary is in control of
the SIP proxy). The media traffic can be decrypted using that the SIP proxy). The media traffic can be decrypted using that
learned key. 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 both SIP Identity [RFC4474]
protects both the offer and the answer, it would belong to the and SIP Connected Identity [RFC4916], the RFC4474 signature protects
detect-attack category. both the offer and the answer, and such a system would then belong to
the active-signaling-active-attack-detect category (provided, of
course, the signaling path to the RFC4474 authenticator and verifier
is secured as per RFC4474 and the RFC4474 authenticator and verifier
are behaving as per RFC4474).
The above discussion of DTLS-SRTP demonstrates how a single security The above discussion of DTLS-SRTP demonstrates how a single security
protocol can be in different classes depending on the mode in which protocol can be in different classes depending on the mode in which
it is operated. Other protocols can achieve similar effect by adding it is operated. Other protocols can achieve similar effect by adding
functions outside of the on-the-wire key management protocol itself. functions outside of the on-the-wire key management protocol itself.
Although it may be appropriate to deploy lower-classed mechanisms in Although it may be appropriate to deploy lower-classed mechanisms in
some cases, the ultimate security requirement for a media security some cases, the ultimate security requirement for a media security
negotiation protocol is that it have a mode of operation available in negotiation protocol is that it have a mode of operation available in
which it is detect-attack, which provides protection against the which it is detect-attack, which provides protection against the
passive and active attacks and provides detection of such attacks. passive and active attacks and provides detection of such attacks.
skipping to change at page 8, line 49 skipping to change at page 9, line 8
key available before the SDP answer arrives will not help. key available before the SDP answer arrives will not help.
Fixes to early media (i.e., the media that arrives at the SDP offerer Fixes to early media (i.e., the media that arrives at the SDP offerer
before the SDP answer arrives) might make the requirements to become before the SDP answer arrives) might make the requirements to become
obsolete, but at the time of writing no progress has been obsolete, but at the time of writing no progress has been
accomplished. accomplished.
4.2. Retargeting and Forking 4.2. Retargeting and Forking
The discussion in this section relates to requirements R-FORK- The discussion in this section relates to requirements R-FORK-
RETARGET, R-BEST-SECURE, and R-DISTINCT. RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE.
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 10, line 9 skipping to change at page 10, line 20
Not preventable by the caller: There is no existing mechanism that Not preventable by the caller: There is no existing mechanism that
might be employed by the originating user agent in order to might be employed by the originating user agent in 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 [RFC4474]. 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 (e.g., MIKEY). Identity and include their own identity mechanism (e.g., MIKEY).
However, those built-in identity mechanism also suffer from the SIP However, those built-in identity mechanism also suffer from the SIP
retargeting problem. Going forward, Connected Identity [RFC4916] retargeting problem. While Connected Identity [RFC4916] allows
allows identifying the called party. positive identification of the called party, the primary difficulty
still remains that the calling party does not know if a mismatched
called party is legitimate (i.e., due to authorized retargeting) or
illegitimate (i.e., due to unauthorized retargeting by an attacker
above to modify SIP signaling).
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 11, line 14 skipping to change at page 11, line 28
(e.g., SRTP keys) that is accessible by parties that receive the (e.g., SRTP keys) that is accessible by parties that receive the
offer, but may not respond (i.e., the original recipients in a offer, but may not respond (i.e., the original recipients in a
retargeted call, or non-answering endpoints in a forked call). For retargeted call, or non-answering endpoints in a forked call). For
key exchange mechanisms that do not provide secure forking or secure key exchange mechanisms that do not provide secure forking or secure
retargeting, one workaround is to re-key immediately after forking or retargeting, one workaround is to re-key immediately after forking or
retargeting. However, because the originator may not be aware that retargeting. However, because the originator may not be aware that
the call forked this mechanism requires rekeying immediately after the call forked this mechanism requires rekeying immediately after
every session is established. This doubles the number of messages every session is established. This doubles the number of messages
processed by the network. processed by the network.
Retargeting securely introduces a more significant problem. With
retargeting, the actual recipient of the request is not the original
recipient. This means that if the offerer encrypted material (such
as the session key or the SDP) using the original recipient's public
key (or a shared secret established previously), the actual recipient
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
the intended behavior, i.e., you wanted to establish a secure
connection with a specific individual. In other cases, it is not
intended behavior (you want all voice media to be encrypted,
regardless of who answers).
Further compounding this problem is a unique feature 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)
skipping to change at page 13, line 46 skipping to change at page 13, line 48
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 R-PSTN. The discussion in this section relates to requirement R-PSTN.
It is desirable, even when one leg of a call is on the PSTN, that the
IP leg of the call be protected with SRTP.
A typical case of using media security where two entities are having A typical case of using media security where two entities are having
a VoIP conversation over IP capable networks. However, there are a VoIP conversation over IP capable networks. However, there are
cases where the other end of the communication is not connected to an 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 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 kind of gateway at the edge of the IP network which converts the VoIP
conversation to format understood by the other network. An example 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 of such gateway is a PSTN gateway sitting at the edge of IP and PSTN
networks (such as the architecture described in [RFC3372]). 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
skipping to change at page 14, line 37 skipping to change at page 14, line 42
Multimedia Services Identity Module (ISIMs), and PSTN gateways. PSTN Multimedia Services Identity Module (ISIMs), and PSTN gateways. PSTN
gateways typically utilize a Digital Signal Processor (DSP) which is gateways typically utilize a Digital Signal Processor (DSP) which is
not yet involved with typical DSP operations at the beginning of a 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 call, thus the DSP could be used to perform the calculation, so as to
avoid having the central host processor perform the calculation. avoid having the central host processor perform the calculation.
However, not all PSTN gateways use DSPs (some have only central However, not all PSTN gateways use DSPs (some have only central
processors or their DSPs are incapable of performing the necessary processors or their DSPs are incapable of performing the necessary
public key or Diffie-Hellman operation), and handsets lack a public key or Diffie-Hellman operation), and handsets lack a
separate, unused processor to perform these operations. separate, unused processor to perform these operations.
Two scenarios where R-REUSE is useful are calls between an endpoint
and its voicemail server or its PSTN gateway. In those scenarios
calls are made relatively often and it can be useful for the
voicemail server or PSTN gateway to avoid public key operations for
subsequent calls.
Storing keys across sessions often interferes with perfect forward
secrecy (R-PFS).
4.7. Transcoding
The discussion in this section relates to requirement R-TRANSCODER.
In some environments is is necessary for network equipment to
transcode from one codec (e.g., a highly compressed codec which makes
efficient use of wireless bandwidth) to another codec (e.g., a
standardized codec to a SIP peering interface). With RTP, a
transcoding function can be performed with the combination of a SIP
B2BUA (to modify the SDP) and a processor to perform the transcoding
between the codecs. However, with end-to-end secured SRTP, a
transcoding function implemented the same way is a man in the middle
attack, and the key management system prevents its use.
However, such a network-based transcoder can still be realized with
the cooperation and approval of the endpoint, and can provide end-to-
transcoder and transcoder-to-end security.
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:
R-FORK-RETARGET The media security key management protocol MUST R-FORK-RETARGET:
The media security key management protocol MUST securely
support forking and retargeting when all endpoints are willing support forking and retargeting when all endpoints are willing
to use SRTP without causing the call setup to fail, unless the to use SRTP without causing the call setup to fail. This
execution of the authentication and key exchange protocol leads requirement means the endpoints that did not answer the call
to a failure (e.g., an unsuccessful authentication attempt). MUST NOT learn the SRTP keys (in either direction) used by the
answering endpoint.
R-DISTINCT The media security key management protocol MUST be capble R-DISTINCT:
of creating distinct, independent cryptographic contexts for The media security key management protocol MUST be capble of
each endpoint in a forked session. creating distinct, independent cryptographic contexts for each
endpoint in a forked session.
R-HERFP:
The media security key management protocol MUST function
securely even in the presence of HERFP behavior.
Performance considerations: Performance considerations:
R-REUSE The media security key management protocol MUST support the R-REUSE:
re-use of a previously established security context, and The media security key management protocol MAY support the re-
implementations SHOULD implement the re-use mechanism. use of a previously established security context.
Note: re-use of the security context does not imply re-
use of RTP parameters (e.g., payload type or SSRC).
Media considerations: Media considerations:
R-AVOID-CLIPPING The media security key management protocol SHOULD R-AVOID-CLIPPING:
avoid clipping media before SDP answer without requiring PRACK The media security key management protocol SHOULD avoid
[RFC3262]. This requirement comes from Section 4.1. clipping media before SDP answer without requiring Security
Preconditions [RFC5027]. This requirement comes from
Section 4.1.
R-RTP-VALID If SRTP key negotiation is performed over the media path R-RTP-VALID:
(i.e., using the same UDP/TCP ports as media packets), the key 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 negotiation packets MUST NOT pass the RTP validity check
defined in Appendix A.1 of [RFC3550]. defined in Appendix A.1 of [RFC3550].
R-ASSOC The media security key management protocol SHOULD include a R-ASSOC:
The media security key management protocol SHOULD include a
mechanism for associating key management messages with both the mechanism for associating key management messages with both the
signaling traffic that initiated the session and with protected signaling traffic that initiated the session and with protected
media traffic. Allowing such an association also allows the media traffic. Allowing such an association also allows the
SDP offerer to avoid performing CPU-consuming operations (e.g., SDP offerer to avoid performing CPU-consuming operations (e.g.,
Diffie-Hellman or public key operations) with attackers that Diffie-Hellman or public key operations) with attackers that
have not seen the signaling messages. have not seen the signaling messages.
For example, if using a Diffie-Hellman keying technique with For example, if using a Diffie-Hellman keying technique with
security preconditions that forks to 20 end points, the call security preconditions that forks to 20 end points, the call
initiator would get 20 provisional responses containing 20 initiator would get 20 provisional responses containing 20
skipping to change at page 16, line 5 skipping to change at page 17, line 5
validating signatures can be a difficult task depending on the validating signatures can be a difficult task depending on the
device capabilities. Hence, in the case of forking, it is not device capabilities. Hence, in the case of forking, it is not
desirable to perform a DH or PK operation with every party, but desirable to perform a DH or PK operation with every party, but
rather only with the party that answers the call (and incur rather only with the party that answers the call (and incur
some media clipping). To do this, the signaling and media need some media clipping). To do this, the signaling and media need
to be associated so the calling party knows which key to be associated so the calling party knows which key
management needs to be completed. This might be done by using management needs to be completed. This might be done by using
the transport address indicated in the SDP, although NATs can the transport address indicated in the SDP, although NATs can
complicate this association. complicate this association.
R-NEGOTIATE The media security key management protocol MUST allow a Note: due to RTP's design requirements, it is expected
SIP User Agent to negotiate media security parameters for each that SRTP receivers will have to perform authentication
of any received SRTP packets.
R-NEGOTIATE:
The media security key management protocol MUST allow a SIP
User Agent to negotiate media security parameters for each
individual session. individual session.
R-PSTN The media security key management protocol MUST support R-PSTN:
The media security key management protocol MUST support
termination of media security in a PSTN gateway. This termination of media security in a PSTN gateway. This
requirement is from Section 4.5. requirement is from Section 4.5.
5.2. Security Requirements 5.2. Security Requirements
This section describes overall security requirements and specific This section describes overall security requirements and specific
requirements from the attack scenarios (Section 3). requirements from the attack scenarios (Section 3).
Overall security requirements: Overall security requirements:
R-PFS The media security key management protocol MUST be able to R-PFS:
The media security key management protocol MUST be able to
support perfect forward secrecy. support perfect forward secrecy.
R-COMPUTE The media security key management protocol MUST support R-COMPUTE:
negotiation of SRTP cipher suites without incurring per- The media security key management protocol MUST support
algorithm computational expense. This allows a multiple SRTP offering additional SRTP cipher suites without incurring
cipher suites to be negotiated without incurring computational significant computational expense.
expense for each cipher suite.
R-CERTS If the media security key management protocol employs R-CERTS:
If the media security key management protocol employs
certificates, it MUST be able to make use of both self-signed certificates, it MUST be able to make use of both self-signed
and CA-issued certificates. As an alternative, the media and CA-issued certificates. As an alternative, the media
security key management protocol MAY make use of "bare" public security key management protocol MAY make use of "bare" public
keys. keys.
R-FIPS 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.
R-DOS 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).
R-EXISTING The media security key management protocol SHOULD allow R-EXISTING:
The media security key management protocol SHOULD allow
endpoints to authenticate using pre-existing cryptographic endpoints to authenticate using pre-existing cryptographic
credentials, e.g., certificates or pre-shared keys. credentials, e.g., certificates or pre-shared keys.
R-AGILITY The media security key management protocol MUST provide R-AGILITY:
crypto-agility, i.e., the ability to adapt to evolving The media security key management protocol MUST provide crypto-
cryptography and security requirements (update of cryptographic agility, i.e., the ability to adapt to evolving cryptography
algorithms without substantial disruption to deployed and security requirements (update of cryptographic algorithms
implementations) without substantial disruption to deployed implementations)
R-DOWNGRADE The media security key management protocol MUST protect R-DOWNGRADE:
cipher suite negotiation against downgrading attacks. The media security key management protocol MUST protect cipher
suite negotiation against downgrading attacks.
R24: <deleted> R-PASS-MEDIA:
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.
R-PASS-MEDIA The media security key management protocol MUST have a R-PASS-SIG:
mode which prevents a passive adversary with access to the The media security key management protocol MUST have a mode in
media path from gaining access to keying material used to 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.
R-PASS-SIG The media security key management protocol MUST have a R-SIG-MEDIA:
mode in which it prevents a passive adversary with access to The media security key management protocol MUST have a mode in
the signaling path from gaining access to keying material used which it defends itself from an attacker that is solely on the
to protect SRTP media packets. media path and from an attacker that is solely on the signaling
path. A successful attack refers to the ability for the
R-SIG-MEDIA The media security key management protocol SHOULD
require the 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 media path 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 adversary to obtain keying material to decrypt the SRTP
encrypted media traffic. encrypted media traffic.
R-ID-BINDING When the media security key management protocol uses R-ID-BINDING:
identifiers for endpoints other than the From: addresses The media security key management protocol MUST use identifiers
asserted by SIP-Identity [RFC4474] and SIP-Connected-Identity for endpoints that allow a domain to create signatures over
[RFC4916] (e.g., public keys, hashes, or certificate those identifiers and the From address.
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.
R-ACT-ACT The media security key management protocol MUST support a This allows domains to deploy SIP Identity [RFC4474].
mode operation that provides active-signaling-active-media-
detect robustness, and MAY support modes of operation that R-ACT-ACT:
provide lower levels of robustness (as described in Section 3). The media security key management protocol MUST support a mode
of operation that provides active-signaling-active-media-detect
robustness, and MAY support modes of operation that provide
lower levels of robustness (as described in Section 3).
Failing to meet R-ACT-ACT indicates the protocol can not
provide secure end-to-end media.
5.3. Requirements Outside of the Key Management Protocol 5.3. Requirements Outside of the Key Management Protocol
The requirements in this section are for an overall VoIP security The requirements in this section are for an overall VoIP security
system. These requirements can be met within the key management system. These requirements can be met within the key management
protocol itself, or can be solved outside of the key management protocol itself, or can be solved outside of the key management
protocol itself (e.g., solved in SIP or in SDP). protocol itself (e.g., solved in SIP or in SDP).
R-BEST-SECURE Even when some end points of a forked or retargeted R-BEST-SECURE:
call are incapable of using SRTP, a solution MUST be described Even when some end points of a forked or retargeted call are
which allows the establishment of SRTP associations with SRTP- incapable of using SRTP, a solution MUST be described which
capable endpoints and / or RTP associations with non-SRTP- allows the establishment of SRTP associations with SRTP-capable
capable endpoints. This requirement comes from Section 4.2. endpoints and / or RTP associations with non-SRTP-capable
endpoints. This requirement comes from Section 4.2.
R-OTHER-SIGNALING A solution SHOULD be able to negotiate keys for R-OTHER-SIGNALING:
SRTP sessions created via different call signaling protocols A solution SHOULD be able to negotiate keys for SRTP sessions
(e.g., between Jabber, SIP, H.323, MGCP). created via different call signaling protocols (e.g., between
Jabber, SIP, H.323, MGCP).
R-RECORDING A solution SHOULD be described which supports recording R-RECORDING:
of decrypted media. This requirement comes from Section 4.4. A solution SHOULD be described which supports recording of
decrypted media. This requirement comes from Section 4.4.
R-TRANSCODER A solution SHOULD be described which supports R-TRANSCODER:
intermediate nodes (e.g., transcoders), terminating or A solution SHOULD be described which supports intermediate
processing media, between the end points. 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 17 skipping to change at page 20, line 34
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 Thanks to Richard Barnes and Peter Schneider for thorough reviews and
which improved the document considerably. 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>.
skipping to change at page 20, line 39 skipping to change at page 22, line 9
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-01 (work in progress), draft-ietf-avt-dtls-srtp-01 (work in progress),
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-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along
the Media Path",
draft-ietf-mmusic-media-path-middleboxes-00 (work in
progress), January 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 2007. progress), December 2007.
[I-D.ietf-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-08 (work in progress),
July 2007. February 2008.
[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),
June 2007. June 2007.
[I-D.ietf-sip-certs] [I-D.ietf-sip-certs]
Jennings, C., "Certificate Management Service for The Jennings, C., Peterson, J., and J. Fischl, "Certificate
Session Initiation Protocol (SIP)", Management Service for The Session Initiation Protocol
draft-ietf-sip-certs-04 (work in progress), July 2007. (SIP)", draft-ietf-sip-certs-05 (work in progress),
February 2008.
[I-D.jennings-sipping-multipart] [I-D.jennings-sipping-multipart]
Wing, D. and C. Jennings, "Session Initiation Protocol Wing, D. and C. Jennings, "Session Initiation Protocol
(SIP) Offer/Answer with Multipart Alternative", (SIP) Offer/Answer with Multipart Alternative",
draft-jennings-sipping-multipart-02 (work in progress), draft-jennings-sipping-multipart-02 (work in progress),
March 2006. March 2006.
[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
skipping to change at page 22, line 46 skipping to change at page 24, line 24
[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", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams", Session Description Protocol (SDP) Media Streams",
RFC 5027, October 2007. RFC 5027, October 2007.
Appendix A. Overview of Keying Mechanisms Appendix A. Overview and Evaluation of Existing 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:
A.1. Signaling Path Keying Techniques
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
signaling path. signaling path.
signaling and media path: Parts of the keying are carried in the signaling and media path: Parts of the keying are carried in the
SRTP/SRTCP media path, and parts are carried in the call SRTP/SRTCP media path, and parts are carried in the call
signaling (SIP or SDP) path. signaling (SIP or SDP) path.
skipping to change at page 23, line 44 skipping to change at page 25, line 24
which parse and route SIP messages. The media path, on the other which parse and route SIP messages. The media path, on the other
hand, does not normally have computational elements involved, and hand, does not normally have computational elements involved, and
even when computational elements such as firewalls are involved, they even when computational elements such as firewalls are involved, they
cause very little additional delay. Thus, the media path can be cause very little additional delay. Thus, the media path can be
useful for exchanging several messages to establish SRTP keys. A useful for exchanging several messages to establish SRTP keys. A
disadvantage of keying over the media path is that interworking disadvantage of keying over the media path is that interworking
different key exchange requires the interworking function be in the different key exchange requires the interworking function be in the
media path, rather than just in the signaling path; in practice this media path, rather than just in the signaling path; in practice this
involvement is probably unavoidable anyway. involvement is probably unavoidable anyway.
A.1. Signaling Path Keying Techniques
A.1.1. MIKEY-NULL A.1.1. MIKEY-NULL
MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both
directions. The key is sent unencrypted in SDP, which means the SDP directions. The key is sent unencrypted in SDP, which means the SDP
must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to- must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-
end (e.g., by using S/MIME). end (e.g., by using S/MIME).
MIKEY-NULL requires one message from offerer to answerer (half a MIKEY-NULL requires one message from offerer to answerer (half a
round trip), and does not add additional media path messages. round trip), and does not add additional media path messages.
skipping to change at page 26, line 30 skipping to change at page 28, line 5
MIKEYv1 and removes the time synchronization requirement. It MIKEYv1 and removes the time synchronization requirement. It
therefore now takes 2 round-trips to complete. In the first round therefore now takes 2 round-trips to complete. In the first round
trip, the communicating parties learn each other's identities, agree trip, the communicating parties learn each other's identities, agree
on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces
for replay protection. In the second round trip, they negotiate for replay protection. In the second round trip, they negotiate
unicast and/or group SRTP context for SRTP and/or SRTCP. unicast and/or group SRTP context for SRTP and/or SRTCP.
Furthemore, MIKEYv2 also defines an in-band negotiation mode as an Furthemore, MIKEYv2 also defines an in-band negotiation mode as an
alternative to SDP (see Appendix A.3.3). alternative to SDP (see Appendix A.3.3).
A.2. Media Path Keying Technique A.1.12. Evaluation Criteria - SIP
A.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the
signaling path (although it's possible for endpoints to indicate
support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the
keys are exchanged entirely in the media path using a Diffie-Hellman
exchange. The advantage to this mechanism is that the signaling
channel is used only for call setup and the media channel is used to
establish an encrypted channel -- much like encryption devices on the
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
by having each person read digits to the other person. Subsequent
sessions with the same ZRTP endpoint can be authenticated using the
stored hash of the previously negotiated key rather than voice
authentication.
ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2)
to establish the SRTP key, and 3 media path confirmation messages.
These initial messages are all sent as non-RTP packets.
Note that when ZRTP probing is used, unencrypted RTP is being
exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques
A.3.1. EKT
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange
protocol, such as Security Descriptions or MIKEY, for bootstrapping.
In the initial phase, each member of a conference uses an SRTP key
exchange protocol to establish a common key encryption key (KEK).
Each member may use the KEK to securely transport its SRTP master key
and current SRTP rollover counter (ROC), via RTCP, to the other
participants in the session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP
message which contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent.
A.3.2. DTLS-SRTP
DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints
in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS
session over the media channel. The endpoints use the DTLS handshake
to agree on crypto suites and establish SRTP session keys. SRTP
packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round
trip), and, if the offerer wishes to correlate the SDP answer with
the endpoint, requires one message from answer to offerer (full round
trip). DTLS-SRTP uses 4 media path messages to establish the SRTP
key.
This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as
its cipher suite, which is the mandatory-to-implement cipher suite in
TLS [RFC4346].
A.3.3. MIKEYv2 Inband (expired)
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
details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.).
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 A.1.12.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 4.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
skipping to change at page 30, line 33 skipping to change at page 30, line 33
Secure Forking: Yes. Each forked endpoint calculates a unique Secure Forking: Yes. Each forked endpoint calculates a unique
SRTP key. Answer is associated with media by the certificate SRTP key. Answer is associated with media by the certificate
fingerprint in signaling and certificate in the media path. fingerprint in signaling and certificate in the media path.
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 A.1.12.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 4.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
skipping to change at page 32, line 6 skipping to change at page 32, line 6
EKT EKT
Not clipped, as long as the first RTCP packet (containing the Not clipped, as long as the first RTCP packet (containing the
answerer's key) is not lost in transit. The answerer sends its answerer's key) is not lost in transit. The answerer sends its
encryption key in RTCP, which arrives at the same time (or encryption key in RTCP, which arrives at the same time (or
before) the first SRTP packet encrypted with that key. before) the first SRTP packet encrypted with that key.
Note: RTCP needs to work, in the answerer-to-offerer Note: RTCP needs to work, in the answerer-to-offerer
direction, before the offerer can decrypt SRTP media. direction, before the offerer can decrypt SRTP media.
DTLS-SRTP DTLS-SRTP
Not clipped. Keys are exchanged in the media path without No clipping after the DTLS-SRTP handshake has completed. SRTP
relying on the signaling path. keys are exchanged in the media path. Need to wait for SDP
answer to ensure DTLS-SRTP handshake was done with an
authorized party.
If a middlebox interferes with the media path, there can be
clipping [I-D.ietf-mmusic-media-path-middleboxes].
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 A.1.12.3. Centralized Keying
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).
skipping to change at page 34, line 8 skipping to change at page 34, line 14
DTLS-SRTP DTLS-SRTP
Keying: Yes, because with the assumed cipher suite, Keying: Yes, because with the assumed cipher suite,
TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key.
Rekeying: via DTLS in the media path. Rekeying: via DTLS in the media path.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
B.4. SSRC and ROC A.1.12.4. SSRC and ROC
In SRTP, a cryptographic context is defined as the SSRC, destination In SRTP, a cryptographic context is defined as the SSRC, destination
network address, and destination transport port number. Whereas RTP, network address, and destination transport port number. Whereas RTP,
a flow is defined as the destination network address and destination a flow is defined as the destination network address and destination
transport port number. This results in a problem -- how to transport port number. This results in a problem -- how to
communicate the SSRC so that the SSRC can be used for the communicate the SSRC so that the SSRC can be used for the
cryptographic context. cryptographic context.
Two approaches have emerged for this communication. One, used by all Two approaches have emerged for this communication. One, used by all
MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY
skipping to change at page 36, line 13 skipping to change at page 36, line 13
that packet. that packet.
DTLS-SRTP DTLS-SRTP
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used. used.
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 A.1.13. 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. Distribution and Validation of Public Keys and Certificates A.1.13.1. Distribution and Validation of Public Keys and Certificates
Using public key cryptography for confidentiality and authentication Using public key cryptography for confidentiality and authentication
can introduce requirements for two types of systems: (1) a system to can introduce requirements for two types of systems: (1) a system to
distribute public keys (often in the form of certificates), and (2) a distribute public keys (often in the form of certificates), and (2) a
system for validating certificates. We refer to the former as a key system for validating certificates. We refer to the former as a key
distribution system and the latter as an authentication distribution system and the latter as an authentication
infrastructure. In many cases, a monolithic public key infrastructure. In many cases, a monolithic public key
infrastructure (PKI) is used for fulfill both of these roles. infrastructure (PKI) is used for fulfill both of these roles.
However, these functions can be provided by many other systems. For However, these functions can be provided by many other systems. For
instance, key distribution may be accomplished by any public instance, key distribution may be accomplished by any public
skipping to change at page 37, line 6 skipping to change at page 37, line 6
SRTP key exchange mechanisms that require a particular authentication SRTP key exchange mechanisms that require a particular authentication
infrastructure to operate (whether for distribution or validation) infrastructure to operate (whether for distribution or validation)
are gated on the deployment of a such an infrastructure available to are gated on the deployment of a such an infrastructure available to
both endpoints. This means that no media security is achievable both endpoints. This means that no media security is achievable
until such an infrastructure exists. For SIP, something like sip- until such an infrastructure exists. For SIP, something like sip-
certs [I-D.ietf-sip-certs] might be used to obtain the certificate of certs [I-D.ietf-sip-certs] might be used to obtain the certificate of
a peer. 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 A.1.12.1) would still prevent
deployment of keying techniques which require the offerer to successful deployment of keying techniques which require the
obtain the actual target's public key. offerer to obtain the actual target's public key.
The following list compares the requirements introduced by the use of The following list compares the requirements introduced by the use of
public-key cryptography in each keying mechanism, both for public key public-key cryptography in each keying mechanism, both for public key
distribution and for certificate validation. distribution and for certificate validation.
MIKEY-NULL MIKEY-NULL
Public-key cryptography is not used. Public-key cryptography is not used.
MIKEY-PSK MIKEY-PSK
Public-key cryptography is not used. Rather, all endpoints Public-key cryptography is not used. Rather, all endpoints
skipping to change at page 38, line 39 skipping to change at page 38, line 39
MIKEY modes). 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 A.1.13.2. Perfect Forward Secrecy
In the context of SRTP, Perfect Forward Secrecy is the property that In the context of SRTP, Perfect Forward Secrecy is the property that
SRTP session keys that protected a previous session are not SRTP session keys that protected a previous session are not
compromised if the static keys belonging to the endpoints are compromised if the static keys belonging to the endpoints are
compromised. That is, if someone were to record your encrypted compromised. That is, if someone were to record your encrypted
session content and later acquires either party's private key, that session content and later acquires either party's private key, that
encrypted session content would be safe from decryption if your key encrypted session content would be safe from decryption if your key
exchange mechanism had perfect forward secrecy. exchange mechanism had perfect forward secrecy.
The following list describes how each key exchange mechanism provides The following list describes how each key exchange mechanism provides
skipping to change at page 39, line 43 skipping to change at page 39, line 43
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
ZRTP ZRTP
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
EKT EKT
No PFS. No PFS.
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 (e.g., Diffie-
Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]). Hellman (DH_RSA from [RFC4346]) 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 A.1.13.3. Best Effort Encryption
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
skipping to change at page 41, line 26 skipping to change at page 41, line 26
keying technique. keying technique.
The preferred technique, SDP Capability Negotiation The preferred technique, SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all [I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all
key exchange mechanisms. What remains unique is ZRTP, which can also key exchange mechanisms. What remains unique is ZRTP, which can also
accomplish its best effort encryption by probing (sending ZRTP accomplish its best effort encryption by probing (sending ZRTP
messages over the media path) or by session attribute (see "a=zrtp", messages over the media path) 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.
C.4. Upgrading Algorithms A.1.13.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
expend CPU resources to build an offer containing all of this expend CPU resources to build an offer containing all of this
skipping to change at page 43, line 13 skipping to change at page 43, line 13
Security Descriptions). Security Descriptions).
DTLS-SRTP DTLS-SRTP
The offerer has no additional computational expense at all, as The offerer has no additional computational expense at all, as
the offer contains only a fingerprint of the certificate that the offer contains only a fingerprint of the certificate that
will be presented in the DTLS exchange. will be presented in the DTLS exchange.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
Appendix D. Out-of-Scope A.2. Media Path Keying Technique
A.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the
signaling path (although it's possible for endpoints to indicate
support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the
keys are exchanged entirely in the media path using a Diffie-Hellman
exchange. The advantage to this mechanism is that the signaling
channel is used only for call setup and the media channel is used to
establish an encrypted channel -- much like encryption devices on the
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
by having each person read digits to the other person. Subsequent
sessions with the same ZRTP endpoint can be authenticated using the
stored hash of the previously negotiated key rather than voice
authentication.
ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2)
to establish the SRTP key, and 3 media path confirmation messages.
These initial messages are all sent as non-RTP packets.
Note that when ZRTP probing is used, unencrypted RTP is being
exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques
A.3.1. EKT
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange
protocol, such as Security Descriptions or MIKEY, for bootstrapping.
In the initial phase, each member of a conference uses an SRTP key
exchange protocol to establish a common key encryption key (KEK).
Each member may use the KEK to securely transport its SRTP master key
and current SRTP rollover counter (ROC), via RTCP, to the other
participants in the session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP
message which contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent.
A.3.2. DTLS-SRTP
DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints
in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS
session over the media channel. The endpoints use the DTLS handshake
to agree on crypto suites and establish SRTP session keys. SRTP
packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round
trip), and one message from the answerer to offerer (full round trip)
so the offerer can correlate the SDP answer with the answering
endpoint. DTLS-SRTP uses 4 media path messages to establish the SRTP
key.
This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as
its cipher suite, which is the mandatory-to-implement cipher suite in
TLS [RFC4346].
A.3.3. MIKEYv2 Inband (expired)
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
details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.).
Appendix B. 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 The compromise of an endpoint that has access to decrypted media
(e.g., SIP user agent, transcoder, recorder) is out of scope of this
document. Such a compromise might be via privilege escalation,
installation of a virus or trojan horse, or similar attacks.
[[RFC Editor: Please delete this section prior to publication.]] Appendix C. Requirement renumbering in -02
[[RFC Editor: Please delete this section prior to publication.]]
Previous versions of this document used requirement numbers, which Previous versions of this document used requirement numbers, which
were changed to mnemonics as follows: were changed to mnemonics as follows:
R1 R-FORK-RETARGET R1 R-FORK-RETARGET
R2 R-BEST-SECURE R2 R-BEST-SECURE
R3 R-DISTINCT R3 R-DISTINCT
R4 R-REUSE; changed from 'MAY' to 'protocol MUST support, and R4 R-REUSE; changed from 'MAY' to 'protocol MUST support, and
skipping to change at page 46, line 47 skipping to change at page 48, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF This document was produced using xml2rfc v1.33pre8 (of
Administrative Support Activity (IASA). http://xml.resource.org/) from a source in RFC-2629 XML format.
 End of changes. 75 change blocks. 
265 lines changed or deleted 333 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/