draft-ietf-sip-media-security-requirements-09.txt   rfc5479.txt 
SIP Working Group D. Wing, Ed. Network Working Group D. Wing, Ed.
Internet-Draft Cisco Request for Comments: 5479 Cisco
Intended status: Informational S. Fries Category: Informational S. Fries
Expires: July 13, 2009 Siemens AG Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
January 9, 2009
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-09
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 13, 2009. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document 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 Secure RTP (SRTP) media. In
natural security requirements, this negotiation protocol must addition to the natural security requirements, this negotiation
interoperate well with SIP in certain ways. A number of proposals protocol must interoperate well with SIP in certain ways. A number
have been published and a summary of these proposals is in the of proposals have been published and a summary of these proposals is
appendix of this document. in the appendix of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios and Requirements Considerations . . . . . . . . 8 4. Call Scenarios and Requirements Considerations . . . . . . . . 7
4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8 4.1. Clipping Media before Signaling Answer . . . . . . . . . . 7
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 9 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 13 4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12
4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 14 4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13
4.8. Interworking with Other Signaling Protocols . . . . . . . 14 4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 15 4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15 5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 17 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
5.3. Requirements Outside of the Key Management Protocol . . . 19 5.3. Requirements outside of the Key Management Protocol . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24 Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 26 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 26 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 25
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 27 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 27 A.1.8. SDP Security Descriptions with SIPS . . . . . . . . . 26
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 27 A.1.9. SDP Security Descriptions with S/MIME . . . . . . . . 27
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 27 A.1.10. SDP-DH (Expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 27 A.1.11. MIKEYv2 in SDP (Expired) . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 28 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 29 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 29 A.3.3. MIKEYv2 Inband (Expired) . . . . . . . . . . . . . . . 29
A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29 A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29 A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
A.4.2. Clipping Media Before SDP Answer . . . . . . . . . . . 32 A.4.2. Clipping Media before SDP Answer . . . . . . . . . . . 31
A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 34 A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 36 A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35
A.5.1. Distribution and Validation of Persistent Public A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 36 Keys and Certificates . . . . . . . . . . . . . . . . 35
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38 A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 40 A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 41 A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 43 Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 43 B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 42
Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
envisioned needs for the users on 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.
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, and 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, and acknowledgements in Section 7.
acknowledgement section in Section 8. Appendix A lists and compares Appendix A lists and compares available solution proposals. The
available solution proposals. The following Appendix A.4 compares following Appendix A.4 compares the different approaches regarding
the different approaches regarding their suitability for the SIP their suitability for the SIP signaling scenarios described in
signaling scenarios described in Appendix A, while Appendix A.5 Appendix A, while Appendix A.5 provides a comparison regarding
provides a comparison regarding security aspects. Appendix B lists 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.
Furthermore, the terminology described in SIP ([RFC3261]) regarding Furthermore, the terminology described in SIP [RFC3261] regarding
functions and components are used throughout the document functions and components are used throughout the document.
Additionally, the following items are used in this document: Additionally, the following items are used in this document:
AOR (Address-of-Record): A SIP or SIPS URI that points to a domain AOR (Address-of-Record): A SIP or SIPS URI that points to a domain
with a location service that can map the URI to another URI where with a location service that can map the URI to another URI where
the user might be available. Typically, the location service is the user might be available. Typically, the location service is
populated through registrations. An AOR is frequently thought of populated through registrations. An AOR is frequently thought of
as the "public address" of the user. as the "public address" of the user.
SSRC: The 32-bit value that defines the synchronization source, used SSRC: The 32-bit value that defines the synchronization source, used
skipping to change at page 5, line 27 skipping to change at page 4, line 35
active adversary: An active adversary is able to alter data active adversary: An active adversary is able to alter data
communication to affect its operation (see also [RFC4949]). communication to affect its operation (see also [RFC4949]).
passive adversary: A passive adversary is able to learn information passive adversary: A passive adversary is able to learn information
from data communication, but not alter that data communication from data communication, but not alter that data communication
(see also[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.
Moreover, as this document discusses requirements for media security, Moreover, as this document discusses requirements for media security,
the nomenclature R-XXX is used to mark requrements, were XXX is the the nomenclature R-XXX is used to mark requirements, where XXX is the
requirement, which needs to be met. requirement, which needs to be met.
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-ASSOC
R-PASS-SIG, R-ASSOC, R-SIG-MEDIA, R-ACT-ACT, and R-ID-BINDING. (specified in Section 5.1) R-PASS-MEDIA, R-PASS-SIG, R-SIG-MEDIA,
R-ACT-ACT, and R-ID-BINDING (specified in Section 5.2).
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.
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. This list is generally ordered from easiest to compromise labels. This list is generally ordered from easiest to compromise
(at the top) to more difficult to compromise: (at the top) to more difficult to compromise:
+---------------+---------+--------------------------------------+ +---------------+---------+--------------------------------------+
skipping to change at page 6, line 35 skipping to change at page 5, line 47
| none | passive | no-signaling-passive-media | | none | passive | no-signaling-passive-media |
| none | active | no-signaling-active-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 | | 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 only to 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-signaling-active-media:
Passive attack on the signaling and active attack on the media Passive attack on the signaling and active 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.
skipping to change at page 7, line 22 skipping to change at page 6, line 31
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 (as with active-signaling- reveal the content of the media traffic (as with active-signaling-
active-media), and the attack is detectable by protocol messages active-media), and the attack is detectable by protocol messages
exchanged between the end points. 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, SDP Security Descriptions [RFC4568], when
by TLS (as it is commonly implemented and deployed), belongs in the protected by TLS (as it is commonly implemented and deployed), belong
passive-signaling-passive-media category since the adversary needs to in the passive-signaling-passive-media category since the adversary
learn the Security Descriptions key by seeing the SIP signaling needs to learn the SDP Security Descriptions key by seeing the SIP
message at a SIP proxy (assuming that the adversary is in control of signaling message at a SIP proxy (assuming that the adversary is in
the SIP proxy). The media traffic can be decrypted using that control of the SIP proxy). The media traffic can be decrypted using
learned key. that learned key.
As another example, DTLS-SRTP falls into active-signaling-active- As another example, DTLS-SRTP (Datagram Transport Layer Security
media category when DTLS-SRTP is used with a public key based Extension for SRTP) falls into active-signaling-active-media category
ciphersuite with self-signed certificates and without SIP-Identity when DTLS-SRTP is used with a public-key-based ciphersuite with self-
[RFC4474]. An adversary would have to modify the fingerprint that is signed certificates and without SIP Identity [RFC4474]. An adversary
sent along the signaling path and subsequently to modify the would have to modify the fingerprint that is sent along the signaling
certificates carried in the DTLS handshake that travel along the path and subsequently to modify the certificates carried in the DTLS
media path. If DTLS-SRTP is used with both SIP Identity [RFC4474] handshake that travel along the media path. If DTLS-SRTP is used
and SIP Connected Identity [RFC4916], the RFC4474 signature protects with both SIP Identity [RFC4474] and SIP Connected Identity
both the offer and the answer, and such a system would then belong to [RFC4916], the RFC-4474 signature protects both the offer and the
the active-signaling-active-attack-detect category (provided, of answer, and such a system would then belong to the active-signaling-
course, the signaling path to the RFC4474 authenticator and verifier active-media-detect category (provided, of course, the signaling path
is secured as per RFC4474 and the RFC4474 authenticator and verifier to the RFC-4474 authenticator and verifier is secured as per RFC
are behaving as per RFC4474). 4474, and the RFC-4474 authenticator and verifier are behaving as per
RFC 4474).
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 a similar effect by
functions outside of the on-the-wire key management protocol itself. adding functions outside of the on-the-wire key management protocol
Although it may be appropriate to deploy lower-classed mechanisms in itself. Although it may be appropriate to deploy lower-classed
some cases, the ultimate security requirement for a media security mechanisms in some cases, the ultimate security requirement for a
negotiation protocol is that it have a mode of operation available in media security negotiation protocol is that it have a mode of
which is detect-attack, which provides protection against the passive operation available in which is detect-attack, which provides
and active attacks and provides detection of such attacks. That is, protection against the passive and active attacks and provides
there must be a way to use the protocol so that an active attack is detection of such attacks. That is, there must be a way to use the
required against both the signaling and media paths, and so that such protocol so that an active attack is required against both the
attacks are detectable by the endpoints. signaling and media paths, and so that such attacks are detectable by
the endpoints.
4. Call Scenarios and Requirements Considerations 4. Call Scenarios and Requirements Considerations
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.
Throughout the subsections requirements are stated by using the Throughout the subsections, requirements are stated by using the
nomenclature R- to state an explicit requirement. All of the stated nomenclature R- to state an explicit requirement. All of the stated
requirements are explanied in detail in section Section 5. The requirements are explained in detail in Section 5. They are listed
requirements in section Section 5 are listed according their according to their association to the key management protocol, to
association to the key management protocol, to attack scenarios, and attack scenarios, and requirements that can be met inside the key
requirements which can be met inside the key management protocol or management protocol or outside of the key management protocol.
outside of the key management protocol.
4.1. Clipping Media Before Signaling Answer 4.1. Clipping Media before Signaling Answer
The discussion in this section relates to requirement R-AVOID- The discussion in this section relates to requirements R-AVOID-
CLIPPING and R-ALLOW-RTP. CLIPPING and R-ALLOW-RTP.
Per the SDP Offer/Answer Model [RFC3264], Per the Session Description Protocol (SDP) Offer/Answer Model
[RFC3264]:
"Once the offerer has sent the offer, it MUST be prepared to Once the offerer has sent the offer, it MUST be prepared to
receive media for any recvonly streams described by that offer. receive media for any recvonly streams described by that offer.
It MUST be prepared to send and receive media for any sendrecv It MUST be prepared to send and receive media for any sendrecv
streams in the offer, and send media for any sendonly streams in streams in the offer, and send media for any sendonly streams in
the offer (of course, it cannot actually send until the peer the offer (of course, it cannot actually send until the peer
provides an answer with the needed address and port information)." provides an answer with the needed address and port information).
To meet this requirement with SRTP, the offerer needs to know the To meet this requirement with SRTP, the offerer needs to know the
SRTP key for arriving media. If either endpoint receives encrypted SRTP key for arriving media. If either endpoint receives encrypted
media before it has access to the associated SRTP key, it cannot play media before it has access to the associated SRTP key, it cannot play
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 endpoint support Provisional Response
across all SIP proxies, implement Security Preconditions [RFC5027], ACKnowledgement (PRACK) [RFC3262], use TCP across all SIP proxies,
or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer implement Security Preconditions [RFC5027], or both ends implement
Interactive Connectivity Establishment [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 require these techniques and there is industry reluctance to require these
techniques to avoid the problems described in this section. techniques to avoid the problems described in this 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 (for details see media can be received (for details, see [MIDDLEBOX]). In this case,
[I-D.ietf-mmusic-media-path-middleboxes]). In this case, even a even a solution that makes the key available before the SDP answer
solution that makes the key available before the SDP answer arrives arrives will not help.
will not help.
Preventing the arrival of early media (i.e., media that arrives at Preventing the arrival of early media (i.e., media that arrives at
the SDP offerer before the SDP answer arrives) might obsolete the the SDP offerer before the SDP answer arrives) might obsolete the
R-AVOID-CLIPPING requirement, but at the time of writing such early R-AVOID-CLIPPING requirement, but at the time of writing such early
media exists in many normal call scenarios. media exists in many normal call scenarios.
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-DISTINCT, R-HERFP, and R-BEST-SECURE. 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.
+-----+ +-----+
|Alice| |Alice|
+--+--+ +--+--+
| |
skipping to change at page 10, line 6 skipping to change at page 9, line 27
V | V V | V
++-++ ++----+ ++-++ ++----+
|Bob| |Carol| |Bob| |Carol|
+---+ +-----+ +---+ +-----+
Figure 1: Retargeting Figure 1: Retargeting
Using retargeting might lead to situations where the User Agent Using retargeting might lead to situations where the User Agent
Client (UAC) does not know where its request will be going. This Client (UAC) does not know where its request will be going. This
might not immediately seem like a serious problem; after all, when might not immediately seem like a serious problem; after all, when
one places a telephone call on the PSTN, one never really knows if it one places a telephone call on the Public Switched Telephone Network
will be forwarded to a different number, who will pick up the line (PSTN), one never really knows if it will be forwarded to a different
when it rings, and so on. However, when considering SIP mechanisms number, who will pick up the line when it rings, and so on. However,
for authenticating the called party, this function can also make it when considering SIP mechanisms for authenticating the called party,
difficult to differentiate an intermediary that is behaving this function can also make it difficult to differentiate an
legitimately from an attacker. From this perspective, the main intermediary that is behaving legitimately from an attacker. From
problems with retargeting are: this perspective, the main problems with retargeting are:
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. been set up.
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 retargeted.
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., Multimedia
However, those built-in identity mechanism also suffer from the SIP Internet KEYing (MIKEY)). However, those built-in identity mechanism
retargeting problem. While Connected Identity [RFC4916] allows also suffer from the SIP retargeting problem. While Connected
positive identification of the called party, the primary difficulty Identity [RFC4916] allows positive identification of the called
still remains that the calling party does not know if a mismatched party, the primary difficulty still remains that the calling party
called party is legitimate (i.e., due to authorized retargeting) or does not know if a mismatched called party is legitimate (i.e., due
illegitimate (i.e., due to unauthorized retargeting by an attacker to authorized retargeting) or illegitimate (i.e., due to unauthorized
above to modify SIP signaling). 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 27 skipping to change at page 10, line 35
+--+--+ +--+--+ +--+--+ +--+--+
|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 [ICE], and ICE is useful to make this
this association with RTP, it is not desirable to require ICE to 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 the security of the media traffic, only the endpoint that
answers the call should know the SRTP keys for the session. Forked answers the call should know the SRTP keys for the session. Forked
and re-targeted calls only reveal sensitive information to non- and retargeted calls only reveal sensitive information to non-
responders when the signaling messages contain sensitive information responders when the signaling messages contain sensitive information
(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 rekey 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.
Further compounding this problem is a unique feature of SIP that when Further compounding this problem is a unique feature of SIP that,
forking is used, there is always only one final error response when 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) [RFC3326], the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326],
is difficult to solve in SIP. Because we expect the HERFP to is difficult to solve in SIP. Because we expect the HERFP to
continue to be a problem in SIP for the foreseeable future, a media continue to be a problem in SIP for the foreseeable future, a media
security system should function even in the presence of HERFP security system should function even in the presence of HERFP
behavior. behavior.
4.3. Recording 4.3. Recording
The discussion in this section relates to requirement R-RECORDING. 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 brokerages, banks, and
call centers, require recording calls with customers. This is the catalog call centers, require recording calls with customers. This
familiar "this call is being recorded for quality purposes" heard is the familiar "this call is being recorded for quality purposes"
during calls to these sorts of businesses. In these environments, heard during calls to these sorts of businesses. In these
media recording is typically performed by an intermediate device environments, media recording is typically performed by an
(with RTP, this is typically implemented in a 'sniffer'). intermediate device (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
the operation of the business requires such recording. It is the operation of the business requires such recording. It is
desirable that the media security is not unduly compromised by the desirable that the media security is not unduly compromised by the
media recording. The endpoint within the organization needs to be media recording. The endpoint within the organization needs to be
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., [SRTP-KEY]).
4.4. PSTN gateway 4.4. 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 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. 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 Voice over IP (VoIP) conversation over IP-capable networks.
cases where the other end of the communication is not connected to an However, there are cases where the other end of the communication is
IP capable network. In this kind of setting, there needs to be some not connected to an IP-capable network. In this kind of setting,
kind of gateway at the edge of the IP network which converts the VoIP there needs to be some kind of gateway at the edge of the IP network
conversation to format understood by the other network. An example that converts the VoIP conversation to a format understood by the
of such gateway is a PSTN gateway sitting at the edge of IP and PSTN other network. An example of such a gateway is a PSTN gateway
networks (such as the architecture described in [RFC3372]). sitting at the edge of IP and PSTN 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
is terminated at the PSTN gateway. The other network (e.g., PSTN) is terminated at the PSTN gateway. The other network (e.g., PSTN)
may have its own measures to protect the communication, but this may have its own measures to protect the communication, but this
means that from media security point of view the media security is means that from media security point of view the media security is
not employed truely end-to-end between the communicating entities. not employed truly end-to-end between the communicating entities.
4.5. Call Setup Performance 4.5. Call Setup Performance
The discussion in this section relates to requirement R-REUSE. The discussion in this section relates to requirement R-REUSE.
Some devices lack sufficient processing power to perform public key Some devices lack sufficient processing power to perform public key
operations or Diffie-Hellman operations for each call, or prefer to operations or Diffie-Hellman operations for each call, or prefer to
avoid performing those operations on every call. The ability to re- avoid performing those operations on every call. The ability to
use previous public key or Diffie-Hellman operations can vastly reuse previous public key or Diffie-Hellman operations can vastly
decrease the call setup delay and processing requirements for such decrease the call setup delay and processing requirements for such
devices. devices.
In certain devices, it can take a second or two to perform a Diffie- In certain devices, it can take a second or two to perform a Diffie-
Hellman operation. Examples of these devices include handsets, IP Hellman operation. Examples of these devices include handsets, IP
Multimedia Services Identity Module (ISIMs), and PSTN gateways. PSTN Multimedia Services Identity Modules (ISIMs), and PSTN gateways.
gateways typically utilize a Digital Signal Processor (DSP) which is PSTN gateways typically utilize a Digital Signal Processor (DSP) that
not yet involved with typical DSP operations at the beginning of a 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 call; thus, the DSP could be used to perform the calculation, so as
avoid having the central host processor perform the calculation. to 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 Two scenarios where R-REUSE is useful are calls between an endpoint
and its voicemail server or its PSTN gateway. In those scenarios and its voicemail server or its PSTN gateway. In those scenarios,
calls are made relatively often and it can be useful for the calls are made relatively often and it can be useful for the
voicemail server or PSTN gateway to avoid public key operations for voicemail server or PSTN gateway to avoid public key operations for
subsequent calls. subsequent calls.
Storing keys across sessions often interferes with perfect forward Storing keys across sessions often interferes with perfect forward
secrecy (R-PFS). secrecy (R-PFS).
4.6. Transcoding 4.6. Transcoding
The discussion in this section relates to requirement R-TRANSCODER. The discussion in this section relates to requirement R-TRANSCODER.
In some environments is is necessary for network equipment to In some environments, it is necessary for network equipment to
transcode from one codec (e.g., a highly compressed codec which makes transcode from one codec (e.g., a highly compressed codec that makes
efficient use of wireless bandwidth) to another codec (e.g., a efficient use of wireless bandwidth) to another codec (e.g., a
standardized codec to a SIP peering interface). With RTP, a standardized codec to a SIP peering interface). With RTP, a
transcoding function can be performed with the combination of a SIP transcoding function can be performed with the combination of a SIP
B2BUA (to modify the SDP) and a processor to perform the transcoding back-to-back user agent (B2BUA) to modify the SDP and a processor to
between the codecs. However, with end-to-end secured SRTP, a perform the transcoding between the codecs. However, with end-to-end
transcoding function implemented the same way is a man in the middle secured SRTP, a transcoding function implemented the same way is a
attack, and the key management system prevents its use. man-in-the-middle attack, and the key management system prevents its
use.
However, such a network-based transcoder can still be realized with However, such a network-based transcoder can still be realized with
the cooperation and approval of the endpoint, and can provide end-to- the cooperation and approval of the endpoint, and can provide end-to-
transcoder and transcoder-to-end security. transcoder and transcoder-to-end security.
4.7. Upgrading to SRTP 4.7. Upgrading to SRTP
The discussion in this section relates to the requirement R-ALLOW- The discussion in this section relates to the requirement R-ALLOW-
RTP. RTP.
Legitimate RTP media can be sent to an endpoint for announcements, Legitimate RTP media can be sent to an endpoint for announcements,
colorful ringback tones (e.g., music), advertising, or normal call colorful ringback tones (e.g., music), advertising, or normal call
progress tones. The RTP may be received before an associated SDP progress tones. The RTP may be received before an associated SDP
answer. For details on various scenarios, see answer. For details on various scenarios, see [EARLY-MEDIA].
[I-D.stucker-sipping-early-media-coping].
While receiving such RTP exposes the calling party to a risk of While receiving such RTP exposes the calling party to a risk of
receiving malicious RTP from an attacker, SRTP endpoints will need to receiving malicious RTP from an attacker, SRTP endpoints will need to
receive and play out RTP media in order to be compatible with receive and play out RTP media in order to be compatible with
deployed systems that send RTP to calling parties. deployed systems that send RTP to calling parties.
4.8. Interworking with Other Signaling Protocols 4.8. Interworking with Other Signaling Protocols
The discussion in this section relates to the requirement R-OTHER- The discussion in this section relates to the requirement R-OTHER-
SIGNALING. SIGNALING.
In many environments, some devices are signaled with protocols other In many environments, some devices are signaled with protocols other
than SIP which do not share SIP's offer/answer model (e.g., [H.248.1] than SIP that do not share SIP's offer/answer model (e.g., [H.248.1]
or do not utilize SDP (e.g., H.323). In other environments, both or do not utilize SDP (e.g., H.323). In other environments, both
endpoints may be SIP, but may use different key management systems endpoints may be SIP, but may use different key management systems
(e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R). (e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R).
In these environments, it is desirable to have SRTP -- rather than In these environments, it is desirable to have SRTP -- rather than
RTP -- between the two endpoints. It is always possible, although RTP -- between the two endpoints. It is always possible, although
undesirable, to interwork those disparate signaling systems or undesirable, to interwork those disparate signaling systems or
disparate key management systems by decrypting and re-encrypting each disparate key management systems by decrypting and re-encrypting each
SRTP packet in a device in the middle of the network (often the same SRTP packet in a device in the middle of the network (often the same
device performing the signaling interworking). This is undesirable device performing the signaling interworking). This is undesirable
skipping to change at page 15, line 22 skipping to change at page 14, line 42
The discussion in this section relates to R-CERTS. The discussion in this section relates to R-CERTS.
On the Internet and on some private networks, validating another On the Internet and on some private networks, validating another
peer's certificate is often done through a trust anchor -- a list of peer's certificate is often done through a trust anchor -- a list of
Certificate Authorities that are trusted. It can be difficult or Certificate Authorities that are trusted. It can be difficult or
expensive for a peer to obtain these certificates. In all cases, expensive for a peer to obtain these certificates. In all cases,
both parties to the call would need to trust the same trust anchor both parties to the call would need to trust the same trust anchor
(i.e., "certificate authority"). For these reasons, it is important (i.e., "certificate authority"). For these reasons, it is important
that the media plane key management protocol offer a mechanism that that the media plane key management protocol offer a mechanism that
allows end-users who have no prior association to authenticate to allows end-users who have no prior association to authenticate to
each other without acquiring credentials from a third party trust each other without acquiring credentials from a third-party trust
point. Note that this does not rule out mechanisms in which servers point. Note that this does not rule out mechanisms in which servers
have certificates and attest to the identities of end-users. have certificates and attest to the identities of end-users.
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 that 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: R-FORK-RETARGET:
The media security key management protocol MUST securely The media security key management protocol MUST
support forking and retargeting when all endpoints are willing securely support forking and retargeting when all
to use SRTP without causing the call setup to fail. This endpoints are willing to use SRTP without causing
requirement means the endpoints that did not answer the call the call setup to fail. This requirement means the
MUST NOT learn the SRTP keys (in either direction) used by the endpoints that did not answer the call MUST NOT
answering endpoint. learn the SRTP keys (in either direction) used by
the answering endpoint.
R-DISTINCT: R-DISTINCT:
The media security key management protocol MUST be capable of The media security key management protocol MUST be
creating distinct, independent cryptographic contexts for each capable of creating distinct, independent cryptographic
endpoint in a forked session. contexts for each endpoint in a forked session.
R-HERFP: R-HERFP:
The media security key management protocol MUST function The media security key management protocol MUST function
securely even in the presence of HERFP behavior, i.e., the securely even in the presence of HERFP behavior, i.e., the
rejection of key information does not reach the sender. rejection of key information does not reach the sender.
Performance considerations: Performance considerations:
R-REUSE: R-REUSE:
The media security key management protocol MAY support the re- The media security key management protocol MAY support the
use of a previously established security context. reuse of a previously established security context.
Note: re-use of the security context does not imply re- Note: reuse of the security context does not imply reuse of RTP
use of RTP parameters (e.g., payload type or SSRC). parameters (e.g., payload type or SSRC).
Media considerations: Media considerations:
R-AVOID-CLIPPING: R-AVOID-CLIPPING:
The media security key management protocol SHOULD avoid The media security key management protocol SHOULD
clipping media before SDP answer without requiring Security avoid clipping media before SDP answer without
Preconditions [RFC5027]. This requirement comes from requiring Security Preconditions [RFC5027]. This
Section 4.1. requirement comes from Section 4.1.
R-RTP-CHECK: R-RTP-CHECK:
If SRTP key negotiation is performed over the media path (i.e., If SRTP key negotiation is performed over the media
using the same UDP/TCP ports as media packets), the key path (i.e., using the same UDP/TCP ports as media
negotiation packets MUST NOT pass the RTP validity check packets), the key negotiation packets MUST NOT pass the
defined in Appendix A.1 of [RFC3550], so that SRTP negotiation RTP validity check defined in Appendix A.1 of
packets can be differentiated from RTP packets. [RFC3550], so that SRTP negotiation packets can be
differentiated from RTP packets.
R-ASSOC: R-ASSOC:
The media security key management protocol SHOULD include a 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
signaling traffic that initiated the session and with protected the signaling traffic that initiated the session and with
media traffic. It is useful to associate key management protected media traffic. It is useful to associate key
messages with call signaling messages, as this allows the SDP management messages with call signaling messages, as this
offerer to avoid performing CPU-consuming operations (e.g., allows the SDP offerer to avoid performing CPU-consuming
Diffie-Hellman or public key operations) with attackers that operations (e.g., Diffie-Hellman or public key operations)
have not seen the signaling messages. with attackers that 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
security preconditions that forks to 20 end points, the call with security preconditions that forks to 20 endpoints, the
initiator would get 20 provisional responses containing 20 call initiator would get 20 provisional responses
signed Diffie-Hellman key pairs. Calculating 20 Diffie-Hellman containing 20 signed Diffie-Hellman key pairs. Calculating
secrets and validating signatures can be a difficult task for 20 Diffie-Hellman secrets and validating signatures can be
some devices. Hence, in the case of forking, it is not a difficult task for some devices. Hence, in the case of
desirable to perform a Diffie-Hellman operation with every forking, it is not desirable to perform a Diffie-Hellman
party, but rather only with the party that answers the call operation with every party, but rather only with the party
(and incur some media clipping). To do this, the signaling and that answers the call (and incur some media clipping). To
media need to be associated so the calling party knows which do this, the signaling and media need to be associated so
key management exchange needs to be completed. This might be the calling party knows which key management exchange needs
done by using the transport address indicated in the SDP, to be completed. This might be done by using the transport
although NATs can complicate this association. address indicated in the SDP, although NATs can complicate
this association.
Note: due to RTP's design requirements, it is expected Note: due to RTP's design requirements, it is expected that
that SRTP receivers will have to perform authentication SRTP receivers will have to perform authentication of any
of any received SRTP packets. received SRTP packets.
R-NEGOTIATE: R-NEGOTIATE:
The media security key management protocol MUST allow a SIP The media security key management protocol MUST allow a
User Agent to negotiate media security parameters for each SIP User Agent to negotiate media security parameters
individual session. Such negotiation MUST NOT cause a two-time for each individual session. Such negotiation MUST NOT
pad (Section 9.1 of [RFC3711]). cause a two-time pad (Section 9.1 of [RFC3711]).
R-PSTN: R-PSTN:
The media security key management protocol MUST support 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.4. requirement is from Section 4.4.
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).
skipping to change at page 17, line 42 skipping to change at page 17, line 18
The media security key management protocol MUST be able to The media security key management protocol MUST be able to
support perfect forward secrecy. support perfect forward secrecy.
R-COMPUTE: R-COMPUTE:
The media security key management protocol MUST support The media security key management protocol MUST support
offering additional SRTP cipher suites without incurring offering additional SRTP cipher suites without incurring
significant computational expense. significant computational expense.
R-CERTS: R-CERTS:
The key management protocol MUST NOT require that end-users The key management protocol MUST NOT require that end-users
obtain credentials (certificates or private keys) from a third- obtain credentials (certificates or private keys) from a
party trust anchor. third- party trust anchor.
R-FIPS: R-FIPS:
The media security key management protocol SHOULD use The media security key management protocol SHOULD use
algorithms that allow FIPS 140-2 [FIPS-140-2] certification or algorithms that allow FIPS 140-2 [FIPS-140-2] certification
similar country-specific certification (e.g., [AISITSEC]). or similar country-specific certification (e.g.,
[AISITSEC]).
The United States Government can only purchase and use crypto The United States Government can only purchase and use
implementations that have been validated by the FIPS-140 crypto implementations that have been validated by the
[FIPS-140-2] process: FIPS-140 [FIPS-140-2] process:
"The FIPS-140 standard is applicable to all Federal The FIPS-140 standard is applicable to all Federal agencies
agencies that use cryptographic-based security systems to that use cryptographic-based security systems to protect
protect sensitive information in computer and sensitive information in computer and telecommunication
telecommunication systems, including voice systems. The systems, including voice systems. The adoption and use
adoption and use of this standard is available to private of this standard is available to private and commercial
and commercial organizations." organizations.
Some commercial organizations, such as banks and defense Some commercial organizations, such as banks and defense
contractors, require or prefer equipment which has received the contractors, require or prefer equipment that has received the
same validation. same validation.
R-DOS: R-DOS:
The media security key management protocol MUST NOT introduce The media security key management protocol MUST NOT introduce
any new significant denial of service vulnerabilities (e.g., any new significant denial-of-service vulnerabilities (e.g.,
the protocol should not request the endpoint to perform CPU- the protocol should not request the endpoint to perform CPU-
intensive operations without the client being able to validate intensive operations without the client being able to
or authorize the request). validate or authorize the request).
R-EXISTING: R-EXISTING:
The media security key management protocol SHOULD allow The media security key management protocol SHOULD allow
endpoints to authenticate using pre-existing cryptographic endpoints to authenticate using pre-existing
credentials, e.g., certificates or pre-shared keys. cryptographic credentials, e.g., certificates or
pre-shared keys.
R-AGILITY: R-AGILITY:
The media security key management protocol MUST provide crypto- 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
without substantial disruption to deployed implementations) cryptographic algorithms without substantial disruption
to deployed implementations).
R-DOWNGRADE: R-DOWNGRADE:
The media security key management protocol MUST protect cipher The media security key management protocol MUST protect
suite negotiation against downgrading attacks. cipher suite negotiation against downgrading attacks.
R-PASS-MEDIA: R-PASS-MEDIA:
The media security key management protocol MUST have a mode The media security key management protocol MUST have a
which prevents a passive adversary with access to the media mode that prevents a passive adversary with access to
path from gaining access to keying material used to protect the media path from gaining access to keying material
SRTP media packets. used to protect SRTP media packets.
R-PASS-SIG: R-PASS-SIG:
The media security key management protocol MUST have a mode in The media security key management protocol MUST have a
which it prevents a passive adversary with access to the mode in which it prevents a passive adversary with
signaling path from gaining access to keying material used to access to the signaling path from gaining access to
protect SRTP media packets. keying material used to protect SRTP media packets.
R-SIG-MEDIA: R-SIG-MEDIA:
The media security key management protocol MUST have a mode in The media security key management protocol MUST have a
which it defends itself from an attacker that is solely on the mode in which it defends itself from an attacker that
media path and from an attacker that is solely on the signaling is solely on the media path and from an attacker that
path. A successful attack refers to the ability for the is solely on the signaling path. A successful attack
adversary to obtain keying material to decrypt the SRTP refers to the ability for the adversary to obtain
encrypted media traffic. keying material to decrypt the SRTP encrypted media
traffic.
R-ID-BINDING: R-ID-BINDING:
The media security key management protocol MUST enable the The media security key management protocol MUST enable
media security keys to be cryptographically bound to an the media security keys to be cryptographically bound
identity of the endpoint. to an identity of the endpoint.
This allows domains to deploy SIP Identity [RFC4474]. Note: This allows domains to deploy SIP Identity [RFC4474].
R-ACT-ACT: R-ACT-ACT:
The media security key management protocol MUST support a mode The media security key management protocol MUST support a
of operation that provides active-signaling-active-media-detect mode of operation that provides
robustness, and MAY support modes of operation that provide active-signaling-active-media-detect robustness, and MAY
lower levels of robustness (as described in Section 3). 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 Note: Failing to meet R-ACT-ACT indicates the protocol cannot
provide secure end-to-end media. 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: R-BEST-SECURE:
Even when some end points of a forked or retargeted call are Even when some endpoints of a forked or retargeted
incapable of using SRTP, a solution MUST be described which call are incapable of using SRTP, a solution MUST be
allows the establishment of SRTP associations with SRTP-capable described that allows the establishment of SRTP
endpoints and / or RTP associations with non-SRTP-capable associations with SRTP-capable endpoints and/or RTP
endpoints. associations with non-SRTP-capable endpoints.
R-OTHER-SIGNALING: R-OTHER-SIGNALING:
A solution SHOULD be able to negotiate keys for SRTP sessions A solution SHOULD be able to negotiate keys for
created via different call signaling protocols (e.g., between SRTP sessions created via different call
Jabber, SIP, H.323, MGCP). signaling protocols (e.g., between Jabber, SIP,
H.323, Media Gateway Control Protocol (MGCP).
R-RECORDING: R-RECORDING:
A solution SHOULD be described which supports recording of A solution SHOULD be described that supports recording
decrypted media. This requirement comes from Section 4.3. of decrypted media. This requirement comes from
Section 4.3.
R-TRANSCODER: R-TRANSCODER:
A solution SHOULD be described which supports intermediate A solution SHOULD be described that supports
nodes (e.g., transcoders), terminating or processing media, intermediate nodes (e.g., transcoders), terminating or
between the end points. processing media, between the endpoints.
R-ALLOW-RTP: A solution SHOULD be described which allows RTP media R-ALLOW-RTP: A solution SHOULD be described that allows RTP media to
to be received by the calling party until SRTP has been be received by the calling party until SRTP has been
negotiated with the answerer, after which SRTP is preferred negotiated with the answerer, after which SRTP is
over RTP. preferred over RTP.
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. Acknowledgements
This document does not require actions by IANA.
8. Acknowledgements
For contributions to the requirements portion of this document, the For contributions to the requirements portion of this document, the
authors would like to thank the active participants of the RTPSEC BoF authors would like to thank the active participants of the RTPSEC BoF
and on the RTPSEC mailing list, and a special thanks to Steffen Fries and on the RTPSEC mailing list, and a special thanks to Steffen Fries
and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197] and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197]
document. document.
The authors would furthermore like to thank the following people for The authors would furthermore like to thank the following people for
their review, suggestions, and comments: Flemming Andreasen, Richard their review, suggestions, and comments: Flemming Andreasen, Richard
Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath
Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer
Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic, Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic,
Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David
McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter
Schneider, Srinath Thiruvengadam, Dave Ward, Dan York, and Phil Schneider, Frank Shearar, Srinath Thiruvengadam, Dave Ward, Dan York,
Zimmermann. and Phil Zimmermann.
9. References 8. References
9.1. Normative References 8.1. Normative References
[FIPS-140-2] [FIPS-140-2] NIST, "Security Requirements for Cryptographic
NIST, "Security Requirements for Cryptographic Modules", Modules", June 2005, <http://csrc.nist.gov/
June 2005, <http://csrc.nist.gov/publications/fips/ 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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M., and E. Johnston, A., Peterson, J., Sparks, R., Handley, M.,
Schooler, "SIP: Session Initiation Protocol", RFC 3261, and E. Schooler, "SIP: Session Initiation Protocol",
June 2002. RFC 3261, June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
with Session Description Protocol (SDP)", RFC 3264, Model with Session Description Protocol (SDP)",
June 2002. RFC 3264, June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
9.2. Informative References
[AISITSEC]
"Anwendungshinweise und Interpretationen (AIS) zu ITSEC",
January 2002,
<http://www.bsi.de/zertifiz/zert/interpr/aisitsec.htm>.
[H.248.1] ITU, "Gateway control protocol", June 2000,
<http://www.itu.int/rec/T-REC-H.248/e>.
[I-D.baugher-mmusic-sdp-dh] [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for K. Norrman, "The Secure Real-time Transport Protocol
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work (SRTP)", RFC 3711, March 2004.
in progress), February 2006.
[I-D.dondeti-msec-rtpsec-mikeyv2] 8.2. Informative References
Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY,
revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in
progress), March 2007.
[I-D.fischl-sipping-media-dtls] [AISITSEC] Bundesamt fuer Sicherheit in der Informationstechnik
Fischl, J., "Datagram Transport Layer Security (DTLS) [Federal Office of Information Security - Germany],
Protocol for Protection of Media Traffic Established with "Anwendungshinweise und Interpretationen (AIS) zu
the Session Initiation Protocol", ITSEC", January 2002,
draft-fischl-sipping-media-dtls-03 (work in progress), <http://www.bsi.de/zertifiz/zert/interpr/
July 2007. aisitsec.htm>.
[I-D.ietf-avt-dtls-srtp] [DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer
McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)", Work
draft-ietf-avt-dtls-srtp-06 (work in progress), in Progress, October 2008.
October 2008.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
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-01 (work in
progress), July 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), July 2008.
[I-D.ietf-msec-mikey-ecc] [EARLY-MEDIA] Stucker, B., "Coping with Early Media in the Session
Milne, A., "ECC Algorithms for MIKEY", Initiation Protocol (SIP)", Work in Progress,
draft-ietf-msec-mikey-ecc-03 (work in progress), October 2006.
June 2007.
[I-D.ietf-sip-certs] [EKT] McGrew, D., "Encrypted Key Transport for Secure RTP",
Jennings, C. and J. Fischl, "Certificate Management Work in Progress, July 2007.
Service for The Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-07 (work in progress), November 2008.
[I-D.ietf-tls-rfc4346-bis] [H.248.1] ITU, "Gateway control protocol", Recommendation H.248,
Dierks, T. and E. Rescorla, "The Transport Layer Security June 2000, <http://www.itu.int/rec/T-REC-H.248/e>.
(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
(work in progress), March 2008.
[I-D.jennings-sipping-multipart] [ICE] Rosenberg, J., "Interactive Connectivity Establishment
Wing, D. and C. Jennings, "Session Initiation Protocol (ICE): A Protocol for Network Address Translator
(SIP) Offer/Answer with Multipart Alternative", (NAT) Traversal for Offer/Answer Protocols", Work
draft-jennings-sipping-multipart-02 (work in progress), in Progress, October 2007.
March 2006.
[I-D.mcgrew-srtp-ekt] [MIDDLEBOX] Stucker, B. and H. Tschofenig, "Analysis of Middlebox
McGrew, D., "Encrypted Key Transport for Secure RTP", Interactions for Signaling Protocol Communication
draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. along the Media Path", Work in Progress, July 2008.
[I-D.stucker-sipping-early-media-coping] [MIKEY-ECC] Milne, A., "ECC Algorithms for MIKEY", Work
Stucker, B., "Coping with Early Media in the Session in Progress, June 2007.
Initiation Protocol (SIP)",
draft-stucker-sipping-early-media-coping-03 (work in
progress), October 2006.
[I-D.wing-sipping-srtp-key] [MIKEYv2] Dondeti, L., "MIKEYv2: SRTP Key Management using
Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. MIKEY, revisited", Work in Progress, March 2007.
Johnston, "Secure Media Recording and Transcoding with the
Session Initiation Protocol",
draft-wing-sipping-srtp-key-04 (work in progress),
October 2008.
[I-D.zimmermann-avt-zrtp] [MULTIPART] Wing, D. and C. Jennings, "Session Initiation Protocol
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media (SIP) Offer/Answer with Multipart Alternative", Work
Path Key Agreement for Secure RTP", in Progress, March 2006.
draft-zimmermann-avt-zrtp-11 (work in progress),
November 2008.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The
Header Field for the Session Initiation Protocol (SIP)", Reason Header Field for the Session Initiation
RFC 3326, December 2002. Protocol (SIP)", RFC 3326, December 2002.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation
for Telephones (SIP-T): Context and Architectures", Protocol for Telephones (SIP-T): Context and
BCP 63, RFC 3372, September 2002. Architectures", BCP 63, RFC 3372, September 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
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, K. Norrman, "MIKEY: Multimedia Internet KEYing",
August 2004. RFC 3830, August 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites and B. Moeller, "Elliptic Curve Cryptography (ECC)
for Transport Layer Security (TLS)", RFC 4492, May 2006. Cipher Suites for Transport Layer Security (TLS)",
RFC 4492, May 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for
Streams", RFC 4568, July 2006. Media Streams", RFC 4568, July 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650, Multimedia Internet KEYing (MIKEY)", RFC 4650,
September 2006. September 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin,
RSA-R: An Additional Mode of Key Distribution in "MIKEY-RSA-R: An Additional Mode of Key Distribution
Multimedia Internet KEYing (MIKEY)", RFC 4738, in Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006. November 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman,
Transform Carrying Roll-Over Counter for the Secure Real- "Integrity Transform Carrying Roll-Over Counter for
time Transport Protocol (SRTP)", RFC 4771, January 2007. the Secure Real-time Transport Protocol (SRTP)",
RFC 4771, January 2007.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session
Protocol (SIP)", RFC 4916, June 2007. Initiation 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. FYI 36, 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.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008. Extensions", RFC 5197, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[SDP-CAP] Andreasen, F., "SDP Capability Negotiation", Work
in Progress, July 2008.
[SDP-DH] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges
for Multimedia Sessions", Work in Progress,
February 2006.
[SIP-CERTS] Jennings, C. and J. Fischl, "Certificate Management
Service for The Session Initiation Protocol (SIP)",
Work in Progress, November 2008.
[SIP-DTLS] Fischl, J., "Datagram Transport Layer Security (DTLS)
Protocol for Protection of Media Traffic Established
with the Session Initiation Protocol", Work
in Progress, July 2007.
[SRTP-KEY] Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
Johnston, "Secure Media Recording and Transcoding with
the Session Initiation Protocol", Work in Progress,
October 2008.
[ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP:
Media Path Key Agreement for Secure RTP", Work
in Progress, February 2009.
Appendix A. Overview and Evaluation of Existing 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:
signaling path: signaling path:
All the keying is carried in the call signaling (SIP or SDP) All the keying is carried in the call signaling (SIP
path. or SDP) path.
media path: media path:
All the keying is carried in the SRTP/SRTCP media path, and no All the keying is carried in the SRTP/SRTCP media path,
signaling whatsoever is carried in the call signaling path. and no signaling whatsoever is carried in the call
signaling path.
signaling and media path: signaling and media path:
Parts of the keying are carried in the SRTP/SRTCP media path, Parts of the keying are carried in the
and parts are carried in the call signaling (SIP or SDP) path. SRTP/SRTCP media path, and parts are
carried in the call signaling (SIP or SDP)
path.
One of the significant benefits of SRTP over other end-to-end One of the significant benefits of SRTP over other end-to-end
encryption mechanisms, such as for example IPsec, is that SRTP is encryption mechanisms, such as for example IPsec, is that SRTP is
bandwidth efficient and SRTP retains the header of RTP packets. bandwidth efficient and SRTP retains the header of RTP packets.
Bandwidth efficiency is vital for VoIP in many scenarios where access Bandwidth efficiency is vital for VoIP in many scenarios where access
bandwidth is limited or expensive, and retaining the RTP header is bandwidth is limited or expensive, and retaining the RTP header is
important for troubleshooting packet loss, delay, and jitter. important for troubleshooting packet loss, delay, and jitter.
Related to SRTP's characteristics is a goal that any SRTP keying Related to SRTP's characteristics is a goal that any SRTP keying
mechanism to also be efficient and not cause additional call setup mechanism to also be efficient and not cause additional call setup
delay. Contributors to additional call setup delay include network delay. Contributors to additional call setup delay include network
or database operations: retrieval of certificates and additional SIP or database operations: retrieval of certificates and additional SIP
or media path messages, and computational overhead of establishing or media path messages, and computational overhead of establishing
keys or validating certificates. keys or validating certificates.
skipping to change at page 25, line 18 skipping to change at page 24, line 41
Related to SRTP's characteristics is a goal that any SRTP keying Related to SRTP's characteristics is a goal that any SRTP keying
mechanism to also be efficient and not cause additional call setup mechanism to also be efficient and not cause additional call setup
delay. Contributors to additional call setup delay include network delay. Contributors to additional call setup delay include network
or database operations: retrieval of certificates and additional SIP or database operations: retrieval of certificates and additional SIP
or media path messages, and computational overhead of establishing or media path messages, and computational overhead of establishing
keys or validating certificates. keys or validating certificates.
When examining the choice between keying in the signaling path, When examining the choice between keying in the signaling path,
keying in the media path, or keying in both paths, it is important to keying in the media path, or keying in both paths, it is important to
realize the media path is generally 'faster' than the SIP signaling realize the media path is generally "faster" than the SIP signaling
path. The SIP signaling path has computational elements involved path. The SIP signaling path has computational elements involved
which parse and route SIP messages. The media path, on the other that 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. 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 Secure/Multipurpose Internet Mail Extensions
(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.
A.1.2. MIKEY-PSK A.1.2. MIKEY-PSK
MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints
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.
skipping to change at page 26, line 32 skipping to change at page 26, line 7
validation techniques. MIKEY-RSA-R also enables sending certificates validation techniques. MIKEY-RSA-R also enables sending certificates
in the MIKEY message. 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 (DH) exchange. In order to prevent an active
in-the-middle the DH exchange itself is signed using each endpoint's man-in-the-middle, the DH exchange itself is signed using each
private key and the associated public keys are validated using endpoint's private key and the associated public keys are validated
standard X.509 validation techniques. 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 certificate MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for certificate
authentication. 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 [MIKEY-ECC] describes how ECC can be used
can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY- with MIKEY-RSA (using Elliptic Curve Digital Signature Algorithm
DHSIGN (using a new DH-Group code), and also defines two new ECC- (ECDSA) signature) and with MIKEY-DHSIGN (using a new DH-Group code),
based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) and also defines two new ECC-based algorithms, Elliptic Curve
and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) . Integrated Encryption Scheme (ECIES) and Elliptic Curve Menezes-Qu-
Vanstone (ECMQV) .
With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
function exactly like MIKEY-RSA, and the new DH-Group code function function exactly like MIKEY-RSA, and the new DH-Group code function
exactly like MIKEY-DHSIGN. Therefore these ECC mechanisms are not exactly like MIKEY-DHSIGN. Therefore, these ECC mechanisms are not
discussed separately in this document. discussed separately in this document.
A.1.8. Security Descriptions with SIPS A.1.8. SDP Security Descriptions with SIPS
Security Descriptions [RFC4568] has each side indicate the key it SDP Security Descriptions [RFC4568] have each side indicate the key
will use for transmitting SRTP media, and the keys are sent in the they will use for transmitting SRTP media, and the keys are sent in
clear in SDP. Security Descriptions relies on hop-by-hop (TLS via the clear in SDP. SDP Security Descriptions rely on hop-by-hop (TLS
"SIPS:") encryption to protect the keys exchanged in signaling. via "SIPS:") encryption to protect the keys exchanged in signaling.
Security Descriptions requires one message from offerer to answerer, SDP Security Descriptions requires one message from offerer to
and one message from answerer to offerer (full round trip), and does answerer, and one message from answerer to offerer (full round trip),
not add additional media path messages. and does not add additional media path messages.
A.1.9. Security Descriptions with S/MIME A.1.9. SDP Security Descriptions with S/MIME
This keying mechanism is identical to Appendix A.1.8, except that This keying mechanism is identical to Appendix A.1.8 except that,
rather than protecting the signaling with TLS, the entire SDP is rather than protecting the signaling with TLS, the entire SDP is
encrypted with S/MIME. encrypted with S/MIME.
A.1.10. SDP-DH (expired) A.1.10. SDP-DH (Expired)
SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie- SDP Diffie-Hellman [SDP-DH] exchanges Diffie-Hellman messages in the
Hellman messages in the signaling path to establish session keys. To signaling path to establish session keys. To protect against active
protect against active man-in-the-middle attacks, the Diffie-Hellman man-in-the-middle attacks, the Diffie-Hellman exchange needs to be
exchange needs to be protected with S/MIME, SIPS, or SIP Identity protected with S/MIME, SIPS, or SIP Identity [RFC4474] and SIP
[RFC4474] and SIP Conected Identity [RFC4916]. Connected Identity [RFC4916].
SDP-DH requires one message from offerer to answerer, and one message SDP-DH requires one message from offerer to answerer, and one message
from answerer to offerer (full round trip), and does not add from answerer to offerer (full round trip), and does not add
additional media path messages. additional media path messages.
A.1.11. MIKEYv2 in SDP (expired) A.1.11. MIKEYv2 in SDP (Expired)
MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the
MIKEYv1 and removes the time synchronization requirement. It time synchronization requirement. It therefore now takes 2 round
therefore now takes 2 round-trips to complete. In the first round trips to complete. In the first round trip, the communicating
trip, the communicating parties learn each other's identities, agree parties learn each other's identities, agree on a MIKEY mode, crypto
on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces algorithm, SRTP policy, and exchanges nonces for replay protection.
for replay protection. In the second round trip, they negotiate In the second round trip, they negotiate unicast and/or group SRTP
unicast and/or group SRTP context for SRTP and/or SRTCP. context for SRTP and/or SRTCP.
Furthemore, MIKEYv2 also defines an in-band negotiation mode as an Furthermore, 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.2. Media Path Keying Technique
A.2.1. ZRTP A.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the ZRTP [ZRTP] does not exchange information in the signaling path
signaling path (although it's possible for endpoints to exchange a (although it's possible for endpoints to exchange a hash of the ZRTP
hash of the ZRTP Hello message with "a=zrtp-hash" in the initial Hello message with "a=zrtp-hash" in the initial offer if sent over an
Offer if sent over an integrity-protected signaling channel. This integrity-protected signaling channel. This provides some useful
provides some useful correlation between the signaling and media correlation between the signaling and media layers). In ZRTP, the
layers). In ZRTP the keys are exchanged entirely in the media path keys are exchanged entirely in the media path using a Diffie-Hellman
using a Diffie-Hellman exchange. The advantage to this mechanism is exchange. The advantage to this mechanism is that the signaling
that the signaling channel is used only for call setup and the media channel is used only for call setup and the media channel is used to
channel is used to establish an encrypted channel -- much like establish an encrypted channel -- much like encryption devices on the
encryption devices on the PSTN. ZRTP uses voice authentication of PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
its Diffie-Hellman exchange by having each person read digits or by having each person read digits or words to the other person.
words to the other person. Subsequent sessions with the same ZRTP Subsequent sessions with the same ZRTP endpoint can be authenticated
endpoint can be authenticated using the stored hash of the previously using the stored hash of the previously negotiated key rather than
negotiated key rather than voice authentication. ZRTP uses 4 media voice authentication. ZRTP uses four media path messages (Hello,
path messages (Hello, Commit, DHPart1, and DHPart2) to establish the Commit, DHPart1, and DHPart2) to establish the SRTP key, and three
SRTP key, and 3 media path confirmation messages. These initial media path confirmation messages. These initial messages are all
messages are all sent as non-RTP packets. sent as non-RTP packets.
Note that when ZRTP probing is used, unencrypted RTP can be Note: that when ZRTP probing is used, unencrypted RTP can be
exchanged until the SRTP keys are established. exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques A.3. Signaling and Media Path Keying Techniques
A.3.1. EKT A.3.1. EKT
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange EKT [EKT] relies on another SRTP key exchange protocol, such as SDP
protocol, such as Security Descriptions or MIKEY, for bootstrapping. Security Descriptions or MIKEY, for bootstrapping. In the initial
In the initial phase, each member of a conference uses an SRTP key phase, each member of a conference uses an SRTP key exchange protocol
exchange protocol to establish a common key encryption key (KEK). to establish a common key encryption key (KEK). Each member may use
Each member may use the KEK to securely transport its SRTP master key the KEK to securely transport its SRTP master key and current SRTP
and current SRTP rollover counter (ROC), via RTCP, to the other rollover counter (ROC), via RTCP, to the other participants in the
participants in the session. session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP such as SDP Security Descriptions or MIKEY. Each answerer sends an
message which contains the answerer's SRTP Master Key, rollover SRTCP message that contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent. need to be sent.
A.3.2. DTLS-SRTP A.3.2. DTLS-SRTP
DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints DTLS-SRTP [DTLS-SRTP] exchanges public key fingerprints in SDP
in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS [SIP-DTLS] and then establishes a DTLS session over the media
session over the media channel. The endpoints use the DTLS handshake channel. The endpoints use the DTLS handshake to agree on crypto
to agree on crypto suites and establish SRTP session keys. SRTP suites and establish SRTP session keys. SRTP packets are then
packets are then exchanged between the endpoints. 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 one message from the answerer to offerer (full round trip) trip), and one message from the answerer to offerer (full round trip)
so the offerer can correlate the SDP answer with the answering so the offerer can correlate the SDP answer with the answering
endpoint. DTLS-SRTP uses 4 media path messages to establish the SRTP endpoint. DTLS-SRTP uses four media path messages to establish the
key. SRTP key.
This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as
its cipher suite, which is the mandatory-to-implement cipher suite in its cipher suite, which is the mandatory-to-implement cipher suite in
TLS [I-D.ietf-tls-rfc4346-bis]. TLS [RFC5246].
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 document yet on what in-band
means (i.e., UDP, RTP, RTCP, etc.). actually means (i.e., UDP, RTP, RTCP, etc.).
A.4. Evaluation Criteria - SIP A.4. 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.
A.4.1. Secure Retargeting and Secure Forking A.4.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
answerer's keys. Answer is associated with media by the SSRC Secure Forking: No, all AORs see offerer's and answerer's keys.
in MIKEY. Additionally, a two-time pad occurs if two branches Answer is associated with media by the SSRC in MIKEY.
choose the same 32-bit SSRC and transmit SRTP packets. Additionally, a two-time pad occurs if two branches choose the
same 32-bit SSRC and transmit SRTP packets.
Secure Retargeting: No, all targets see offerer's and Secure Retargeting: No, all targets see offerer's and
answerer's keys. Suffers from retargeting identity problem. answerer's keys. Suffers from retargeting identity problem.
MIKEY-PSK MIKEY-PSK
Secure Forking: No, all AORs see offerer's and answerer's keys. Secure Forking: No, all AORs see offerer's and answerer's keys.
Answer is associated with media by the SSRC in MIKEY. Note Answer is associated with media by the SSRC in MIKEY. Note
that all AORs must share the same pre-shared key in order for that all AORs must share the same pre-shared key in order for
forking to work at all with MIKEY-PSK. Additionally, a two- forking to work at all with MIKEY-PSK. Additionally, a two-
time pad occurs if two branches choose the same 32-bit SSRC and time pad occurs if two branches choose the same 32-bit SSRC and
transmit SRTP packets. transmit SRTP packets.
Secure Retargeting: Not secure. For retargeting to work, the Secure Retargeting: Not secure. For retargeting to work, the
final target must possess the correct PSK. As this is likely final target must possess the correct PSK. As this is likely
in scenarios were the call is targeted to another device in scenarios where the call is targeted to another device
belonging to the same user (forking), it is very unlikely that belonging to the same user (forking), it is very unlikely that
other users will possess that PSK and be able to successfully other users will possess that PSK and be able to successfully
answer that call. answer that call.
MIKEY-RSA MIKEY-RSA
Secure Forking: No, all AORs see offerer's and answerer's keys. Secure Forking: No, all AORs see offerer's and answerer's keys.
Answer is associated with media by the SSRC in MIKEY. Note Answer is associated with media by the SSRC in MIKEY. Note
that all AORs must share the same private key in order for that all AORs must share the same private key in order for
forking to work at all with MIKEY-RSA. Additionally, a two- forking to work at all with MIKEY-RSA. Additionally, a two-
time pad occurs if two branches choose the same 32-bit SSRC and time pad occurs if two branches choose the same 32-bit SSRC and
transmit SRTP packets. transmit SRTP packets.
Secure Retargeting: No. Secure Retargeting: No.
MIKEY-RSA-R MIKEY-RSA-R
Secure Forking: Yes. Answer is associated with media by the Secure Forking: Yes, answer is associated with media by the
SSRC in MIKEY. SSRC in MIKEY.
Secure Retargeting: Yes. Secure Retargeting: Yes.
MIKEY-DHSIGN MIKEY-DHSIGN
Secure Forking: Yes, each forked endpoint negotiates unique Secure Forking: Yes, each forked endpoint negotiates unique
keys with the offerer for both directions. Answer is keys with the offerer for both directions. Answer is
associated with media by the SSRC in MIKEY. associated with media by the SSRC in MIKEY.
Secure Retargeting: Yes, each target negotiates unique keys Secure Retargeting: Yes, each target negotiates unique keys
skipping to change at page 31, line 19 skipping to change at page 30, line 43
Secure Forking: Yes, each forked endpoint negotiates unique Secure Forking: Yes, each forked endpoint negotiates unique
keys with the offerer for both directions. Answer is keys with the offerer for both directions. Answer is
associated with media by the SSRC in MIKEY. associated with media by the SSRC in MIKEY.
Secure Retargeting: Yes, each target negotiates unique keys Secure Retargeting: Yes, each target negotiates unique keys
with the offerer for both directions. Note that for the keys with the offerer for both directions. Note that for the keys
to be meaningful, it would require the PSK to be the same for to be meaningful, it would require the PSK to be the same for
all the potential intermediaries, which would only happen all the potential intermediaries, which would only happen
within a single domain. within a single domain.
Security Descriptions with SIPS SDP Security Descriptions with SIPS
Secure Forking: No. Each forked endpoint sees the offerer's Secure Forking: No, each forked endpoint sees the offerer's
key. Answer is not associated with media. key. Answer is not associated with media.
Secure Retargeting: No. Each target sees the offerer's key. Secure Retargeting: No, each target sees the offerer's key.
Security Descriptions with S/MIME SDP Security Descriptions with S/MIME
Secure Forking: No. Each forked endpoint sees the offerer's Secure Forking: No, each forked endpoint sees the offerer's
key. Answer is not associated with media. key. Answer is not associated with media.
Secure Retargeting: No. Each target sees the offerer's key. Secure Retargeting: No, each target sees the offerer's key.
Suffers from retargeting identity problem. Suffers from retargeting identity problem.
SDP-DH SDP-DH
Secure Forking: Yes. Each forked endpoint calculates a unique Secure Forking: Yes, each forked endpoint calculates a unique
SRTP key. Answer is not associated with media. SRTP key. Answer is not associated with media.
Secure Retargeting: Yes. The final target calculates a unique Secure Retargeting: Yes, the final target calculates a unique
SRTP key. SRTP key.
ZRTP ZRTP
Yes. Each forked endpoint calculates a unique SRTP key. With Secure Forking: Yes, each forked endpoint calculates a unique
the "a=zrtp-hash" attribute, the media can be associated with SRTP key. With the "a=zrtp-hash" attribute, the media can be
an answer. associated with an answer.
Secure Retargeting: Yes. The final target calculates a unique Secure Retargeting: Yes, the final target calculates a unique
SRTP key. SRTP key.
EKT EKT
Secure Forking: Inherited from the bootstrapping mechanism (the Secure Forking: Inherited from the bootstrapping mechanism (the
specific MIKEY mode or Security Descriptions). Answer is specific MIKEY mode or SDP Security Descriptions). Answer is
associated with media by the SPI in the EKT protocol. Answer associated with media by the SPI in the EKT protocol. Answer
is associated with media by the SPI in the EKT protocol. is associated with media by the SPI in the EKT protocol.
Secure Retargeting: Inherited from the bootstrapping mechanism Secure Retargeting: Inherited from the bootstrapping mechanism
(the specific MIKEY mode or Security Descriptions). (the specific MIKEY mode or SDP Security Descriptions).
DTLS-SRTP DTLS-SRTP
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.
A.4.2. Clipping Media Before SDP Answer A.4.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 33, line 12 skipping to change at page 32, line 33
Clipped. The answer contains the answerer's Diffie-Hellman Clipped. The answer contains the answerer's Diffie-Hellman
response. response.
MIKEY-DHHMAC MIKEY-DHHMAC
Clipped. The answer contains the answerer's Diffie-Hellman Clipped. The answer contains the answerer's Diffie-Hellman
response. response.
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 SDP Security Descriptions with SIPS
Clipped. The answer contains the answerer's encryption key. Clipped. The answer contains the answerer's encryption key.
Security Descriptions with S/MIME SDP Security Descriptions with S/MIME
Clipped. The answer contains the answerer's encryption key. Clipped. The answer contains the answerer's encryption key.
SDP-DH SDP-DH
Clipped. The answer contains the answerer's Diffie-Hellman Clipped. The answer contains the answerer's Diffie-Hellman
response. response.
ZRTP ZRTP
Not clipped because the session intially uses RTP. While RTP Not clipped because the session initially uses RTP. While RTP
is flowing, both ends negotiate SRTP keys in the media path and is flowing, both ends negotiate SRTP keys in the media path and
then switch to using SRTP. then switch to using SRTP.
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
No clipping after the DTLS-SRTP handshake has completed. SRTP No clipping after the DTLS-SRTP handshake has completed. SRTP
keys are exchanged in the media path. Need to wait for SDP keys are exchanged in the media path. Need to wait for SDP
answer to ensure DTLS-SRTP handshake was done with an answer to ensure DTLS-SRTP handshake was done with an
authorized party. authorized party.
If a middlebox interferes with the media path, there can be If a middlebox interferes with the media path, there can be
clipping [I-D.ietf-mmusic-media-path-middleboxes]. clipping [MIDDLEBOX].
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.
A.4.3. SSRC and ROC A.4.3. 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
exchange. Another, used by Security Descriptions, is to apply "late exchange. Another, used by SDP Security Descriptions, is to apply
binding" -- that is, any new packet containing a previously-unseen "late binding" -- that is, any new packet containing a previously
SSRC (which arrives at the same destination network address and unseen SSRC (which arrives at the same destination network address
destination transport port number) will create a new cryptographic and destination transport port number) will create a new
context. Another approach, common amongst techniques with media-path cryptographic context. Another approach, common amongst techniques
SRTP key establishment, is to require a handshake over that media with media-path SRTP key establishment, is to require a handshake
path before SRTP packets are sent. MIKEY's approach changes RTP's over that media path before SRTP packets are sent. MIKEY's approach
SSRC collision detection behavior by requiring RTP to pre-establish changes RTP's SSRC collision detection behavior by requiring RTP to
the SSRC values for each session. pre-establish the SSRC values for each session.
Another related issue is that SRTP introduces a rollover counter Another related issue is that SRTP introduces a rollover counter
(ROC), which records how many times the SRTP sequence number has (ROC), which records how many times the SRTP sequence number has
rolled over. As the sequence number is used for SRTP's default rolled over. As the sequence number is used for SRTP's default
ciphers, it is important that all endpoints know the value of the ciphers, it is important that all endpoints know the value of the
ROC. The ROC starts at 0 at the beginning of a session. ROC. The ROC starts at 0 at the beginning of a session.
Some keying mechanisms cause a two-time pad to occur if two endpoints Some keying mechanisms cause a two-time pad to occur if two endpoints
of a forked call have an SSRC collision. of a forked call have an SSRC collision.
skipping to change at page 35, line 25 skipping to change at page 34, line 42
packets it transmits. packets it transmits.
MIKEY-DHHMAC MIKEY-DHHMAC
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.
MIKEYv2 in SDP MIKEYv2 in SDP
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.
Security Descriptions with SIPS SDP Security Descriptions with SIPS
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC "late binding" is
used. used.
Security Descriptions with S/MIME SDP Security Descriptions with S/MIME
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC "late binding" is
used. used.
SDP-DH SDP-DH
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC "late binding" is
used. used.
ZRTP ZRTP
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC "late binding" is
used. used.
EKT EKT
The SSRC of the SRTCP packet containing an EKT update The SSRC of the SRTCP packet containing an EKT update
corresponds to the SRTP master key and other parameters within corresponds to the SRTP master key and other parameters within
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.
A.5. Evaluation Criteria - Security A.5. 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.
skipping to change at page 36, line 24 skipping to change at page 35, line 37
A.5.1. Distribution and Validation of Persistent Public Keys and A.5.1. Distribution and Validation of Persistent Public Keys and
Certificates Certificates
Using persistent public keys for confidentiality and authentication Using persistent public keys for confidentiality and authentication
can introduce requirements for two types of systems, often can introduce requirements for two types of systems, often
implemented using certificates: (1) a system to distribute those implemented using certificates: (1) a system to distribute those
persistent public keys certificates, and (2) a system for validating persistent public keys certificates, and (2) a system for validating
those persistent public keys. We refer to the former as a key those persistent public keys. 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 to 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
repository of keys. Any system in which the two endpoints have repository of keys. Any system in which the two endpoints have
access to trust anchors and intermediate CA certificates that can be access to trust anchors and intermediate CA certificates that can be
used to validate other endpoints' certificates (including a system of used to validate other endpoints' certificates (including a system of
self-signed certificates) can be used to support certificate self-signed certificates) can be used to support certificate
validation in the below schemes. validation in the below schemes.
With real-time communications it is desirable to avoid fetching or With real-time communications, it is desirable to avoid fetching or
validating certificates that delay call setup. Rather, it is validating certificates that delay call setup. Rather, it is
preferable to fetch or validate certificates in such a way that call preferable to fetch or validate certificates in such a way that call
setup is not delayed. For example, a certificate can be validated setup is not delayed. For example, a certificate can be validated
while the phone is ringing or can be validated while ring-back tones 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 are being played or even while the called party is answering the
phone and saying "hello". Even better is to avoid fetching or phone and saying "hello". Even better is to avoid fetching or
validating persistent public keys at all. validating persistent public keys at all.
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 [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 [SIP-CERTS] were deployed, the retargeting
retargeting problem (Appendix A.4.1) would still prevent problem (Appendix A.4.1) would still prevent successful deployment
successful deployment of keying techniques which require the of keying techniques which require the offerer to obtain the
offerer to obtain the actual target's public key. 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
must have some way to exchange per-endpoint or per-system pre- must have some way to exchange per-endpoint or per-system
shared keys. 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 [SIP-CERTS] might be
might be viable in the future. viable in the future.
The offer may also contain a certificate for the offeror, which The offer may also contain a certificate for the offerer, which
would require an authentication infrastructure in order to be would require an authentication infrastructure in order to be
validated by the receiver. validated by the receiver.
MIKEY-RSA-R MIKEY-RSA-R
The offer contains the offerer's certificate, and the answer The offer contains the offerer's certificate, and the answer
contains the answerer's certificate. The answerer uses the contains the answerer's certificate. The answerer uses the
public key in the certificate to encrypt the SRTP keys that public key in the certificate to encrypt the SRTP keys that
will be used by the offerer and the answerer. An will be used by the offerer and the answerer. An
authentication infrastructure is necessary to validate the authentication infrastructure is necessary to validate the
certificates. certificates.
MIKEY-DHSIGN MIKEY-DHSIGN
An authentication infrastructure is used to authenticate the An authentication infrastructure is used to authenticate the
public key that is included in the MIKEY message. public key that is included in the MIKEY message.
MIKEY-DHHMAC MIKEY-DHHMAC
Public-key cryptography is not used. Rather, all endpoints Public-key cryptography is not used. Rather, all endpoints
must have some way to exchange per-endpoint or per-system pre- must have some way to exchange per-endpoint or per-system
shared keys. 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 SDP Security Descriptions with SIPS
Public-key cryptography is not used. Public-key cryptography is not used.
Security Descriptions with S/MIME SDP Security Descriptions with S/MIME
Use of S/MIME requires that the endpoints be able to fetch and Use of S/MIME requires that the endpoints be able to fetch and
validate certificates for each other. The offerer must obtain validate certificates for each other. The offerer must obtain
the intended target's certificate and encrypts the SDP offer the intended target's certificate and encrypts the SDP offer
with the public key contained in target's certificate. The with the public key contained in target's certificate. The
answerer must obtain the offerer's certificate and encrypt the answerer must obtain the offerer's certificate and encrypt the
SDP answer with the public key contained in the offerer's SDP answer with the public key contained in the offerer's
certificate. certificate.
SDP-DH SDP-DH
Public-key cryptography is not used. Public-key cryptography is not used.
skipping to change at page 39, line 26 skipping to change at page 38, line 39
MIKEY-DHSIGN MIKEY-DHSIGN
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHHMAC MIKEY-DHHMAC
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
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 SDP Security Descriptions with SIPS
Not applicable; Security Descriptions does not have a long-term Not applicable; SDP Security Descriptions does not have a long-
secret. term secret.
Security Descriptions with S/MIME SDP Security Descriptions with S/MIME
Not applicable; Security Descriptions does not have a long-term Not applicable; SDP Security Descriptions does not have a long-
secret. term secret.
SDP-DH SDP-DH
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 provided if the negotiated cipher suite uses ephemeral PFS is provided if the negotiated cipher suite uses ephemeral
keys (e.g., Diffie-Hellman (DHE_RSA [I-D.ietf-tls-rfc4346-bis]) keys (e.g., Diffie-Hellman (DHE_RSA [RFC5246]) or Elliptic
or Elliptic Curve Diffie-Hellman [RFC4492]). 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.
A.5.3. Best Effort Encryption A.5.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
voice mail system that supports SRTP and RTP. If Alice calls Bob voice mail system that supports SRTP and RTP. If Alice calls Bob
with an SRTP offer, Bob's RTP-only phone will reject the media with an SRTP offer, Bob's RTP-only phone will reject the media
stream (with an empty "m=" line) because Bob's phone doesn't stream (with an empty "m=" line) because Bob's phone doesn't
understand SRTP (RTP/SAVP). Alice's phone will see this rejected understand SRTP (RTP/SAVP). Alice's phone will see this rejected
media stream and may terminate the entire call (BYE) and re- media stream and may terminate the entire call (BYE) and
initiate the call as RTP-only, or Alice's phone may decide to re-initiate the call as RTP-only, or Alice's phone may decide to
continue with call setup with the SRTP-capable leg (the voice mail continue with call setup with the SRTP-capable leg (the voice mail
system). If Alice's phone decided to re-initiate the call as RTP- system). If Alice's phone decided to re-initiate the call as RTP-
only, and Bob doesn't answer his phone, Alice will then leave only, and Bob doesn't answer his phone, Alice will then leave
voice mail using only RTP, rather than SRTP as expected. voice mail using only RTP, rather than SRTP as expected.
Currently, several techniques are commonly considered as candidates Currently, several techniques are commonly considered as candidates
to provide opportunistic encryption: to provide opportunistic encryption:
multipart/alternative multipart/alternative
[I-D.jennings-sipping-multipart] describes how to form a [MULTIPART] describes how to form a multipart/alternative body
multipart/alternative body part in SIP. The significant issues part in SIP. The significant issues with this technique are (1)
with this technique are (1) that multipart MIME is incompatible that multipart MIME is incompatible with existing SIP proxies,
with existing SIP proxies, firewalls, Session Border Controllers, firewalls, Session Border Controllers, and endpoints and (2) when
and endpoints and (2) when forking, the Heterogeneous Error forking, the Heterogeneous Error Response Forking Problem (HERFP)
Response Forking Problem (HERFP) [RFC3326] causes problems if such [RFC3326] causes problems if such non-multipart-capable endpoints
non-multipart-capable endpoints were involved in the forking. were involved in the forking.
session attribute session attribute
With this technique, the endpoints signal their desire to do SRTP With this technique, the endpoints signal their desire to do SRTP
by signaling RTP (RTP/AVP), and using an attribute ("a=") in the by signaling RTP (RTP/AVP), and using an attribute ("a=") in the
SDP. This technique is entirely backwards compatible with non- SDP. This technique is entirely backwards compatible with
SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol non-SRT-aware endpoints, but doesn't use the RTP/SAVP protocol
registered by SRTP [RFC3711]. registered by SRTP [RFC3711].
SDP Capability Negotiation SDP Capability Negotiation
SDP Capability Negotiation SDP Capability Negotiation [SDP-CAP] provides a backwards-
[I-D.ietf-mmusic-sdp-capability-negotiation] provides a backwards-
compatible mechanism to allow offering both SRTP and RTP in a compatible mechanism to allow offering both SRTP and RTP in a
single offer. This is the preferred technique. single offer. This is the preferred technique.
Probing Probing
With this technique, the endpoints first establish an RTP session With this technique, the endpoints first establish an RTP session
using RTP (RTP/AVP). The endpoints send probe messages, over the using RTP (RTP/AVP). The endpoints send probe messages, over the
media path, to determine if the remote endpoint supports their media path, to determine if the remote endpoint supports their
keying technique. A disadvantage of probing is an active attacker keying technique. A disadvantage of probing is an active attacker
can interfere with probes, and until probing completes (and SRTP can interfere with probes, and until probing completes (and SRTP
is established) the media is in the clear. is established) the media is in the clear.
The preferred technique, SDP Capability Negotiation The preferred technique, SDP Capability Negotiation [SDP-CAP], can be
[I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all used with all key exchange mechanisms. What remains unique is ZRTP,
key exchange mechanisms. What remains unique is ZRTP, which can also which can also accomplish its best effort encryption by probing
accomplish its best effort encryption by probing (sending ZRTP (sending ZRTP messages over the media path) or by session attribute
messages over the media path) or by session attribute (see "a=zrtp- (see "a=zrtp-hash" in [ZRTP]). Current implementations of ZRTP use
hash" in [I-D.zimmermann-avt-zrtp]). Current implementations of ZRTP probing.
use probing.
A.5.4. Upgrading Algorithms A.5.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 computationally 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, SDP
Security Descriptions) and all SRTP cryptographic suites (AES-128, Security Descriptions), 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
information which becomes computationally prohibitive. information that becomes computationally prohibitive.
Thus, it is important to keep the offerer's CPU impact fixed so that Thus, it is important to keep the offerer's CPU impact fixed so that
offering multiple new SRTP encryption and hash functions incurs no offering multiple new SRTP encryption and hash functions incurs no
additional expense. additional expense.
The following list describes the CPU effort involved in using each The following list describes the CPU effort involved in using each
key exchange technique. key exchange technique.
MIKEY-NULL MIKEY-NULL
No significant computational expense. No significant computational expense.
MIKEY-PSK MIKEY-PSK
No significant computational expense. No significant computational expense.
MIKEY-RSA MIKEY-RSA
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
RSA operation to encrypt the TGK RSA operation to encrypt the TGK (TEK Generation Key).
MIKEY-RSA-R MIKEY-RSA-R
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
public key operation to sign the MIKEY message. public key operation to sign the MIKEY message.
MIKEY-DHSIGN MIKEY-DHSIGN
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
Diffie-Hellman operation, and a public key operation to sign Diffie-Hellman operation, and a public key operation to sign
the Diffie-Hellman output. the Diffie-Hellman output.
MIKEY-DHHMAC MIKEY-DHHMAC
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
Diffie-Hellman operation. Diffie-Hellman operation.
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 SDP Security Descriptions with SIPS
No significant computational expense. No significant computational expense.
Security Descriptions with S/MIME SDP Security Descriptions with S/MIME
S/MIME requires the offerer and the answerer to encrypt the SDP S/MIME requires the offerer and the answerer to encrypt the SDP
with the other's public key, and to decrypt the received SDP with the other's public key, and to decrypt the received SDP
with their own private key. with their own private key.
SDP-DH SDP-DH
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
a Diffie-Hellman operation. a Diffie-Hellman operation.
ZRTP ZRTP
The offerer has no additional computational expense at all, as The offerer has no additional computational expense at all, as
the offer contains no information about ZRTP or might contain the offer contains no information about ZRTP or might contain
"a=zrtp-hash". "a=zrtp-hash".
EKT EKT
The offerer's Computational expense depends entirely on the EKT The offerer's computational expense depends entirely on the EKT
bootstrapping mechanism selected (one or more MIKEY modes or bootstrapping mechanism selected (one or more MIKEY modes or
Security Descriptions). SDP 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 B. Out-of-Scope Appendix B. Out-of-Scope
skipping to change at page 43, line 27 skipping to change at page 42, line 37
The consensus on the RTPSEC mailing list was to concentrate on The consensus on the RTPSEC mailing list was to concentrate on
unicast, point-to-point sessions. Thus, there are no requirements unicast, point-to-point sessions. Thus, there are no requirements
related to shared key conferencing. This section is retained for related to shared key conferencing. This section is retained for
informational purposes. informational purposes.
For efficient scaling, large audio and video conference bridges For efficient scaling, large audio and video conference bridges
operate most efficiently by encrypting the current speaker once and operate most efficiently by encrypting the current speaker once and
distributing that stream to the conference attendees. Typically, distributing that stream to the conference attendees. Typically,
inactive participants receive the same streams -- they hear (or see) inactive participants receive the same streams -- they hear (or see)
the active speaker(s), and the active speakers receive distinct the active speaker(s), and the active speakers receive distinct
streams that don't include themselves. In order to maintain streams that don't include themselves. In order to maintain the
confidentiality of such conferences where listeners share a common confidentiality of such conferences where listeners share a common
key, all listeners must rekeyed when a listener joins or leaves a key, all listeners must rekeyed when a listener joins or leaves a
conference. conference.
An important use case for mixers/translators is a conference bridge: An important use case for mixers/translators is a conference bridge:
+----+ +----+
A --- 1 --->| | A --- 1 --->| |
<-- 2 ----| M | <-- 2 ----| M |
| I | | I |
skipping to change at page 43, line 49 skipping to change at page 43, line 22
<-- 4 ----| E | <-- 4 ----| E |
| R | | R |
C --- 5 --->| | C --- 5 --->| |
<-- 6 ----| | <-- 6 ----| |
+----+ +----+
Figure 3: Centralized Keying Figure 3: Centralized Keying
In the figure above, 1, 3, and 5 are RTP media contributions from In the figure above, 1, 3, and 5 are RTP media contributions from
Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those
devices carrying the 'mixed' media. devices carrying the "mixed" media.
Several scenarios are possible: Several scenarios are possible:
a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions, a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions,
b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP
sessions, sessions,
c. Single inbound session: 1, 3, and 5 are just different sources c. Single inbound session: 1, 3, and 5 are just different sources
within the same RTP session, within the same RTP session,
d. Single outbound session: 2, 4, and 6 are different flows of the d. Single outbound session: 2, 4, and 6 are different flows of the
same (multi-unicast) RTP session same (multi-unicast) RTP session.
If there are multiple inbound sessions and multiple outbound sessions If there are multiple inbound sessions and multiple outbound sessions
(scenarios a and b), then every keying mechanism behaves as if the (scenarios a and b), then every keying mechanism behaves as if the
mixer were an end point and can set up a point-to-point secure mixer were an endpoint and can set up a point-to-point secure session
session between the participant and the mixer. This is the simplest between the participant and the mixer. This is the simplest
situation, but is computationally wasteful, since SRTP processing has situation, but is computationally wasteful, since SRTP processing has
to be done independently for each participant. The use of multiple to be done independently for each participant. The use of multiple
inbound sessions (scenario a) doesn't waste computational resources, inbound sessions (scenario a) doesn't waste computational resources,
though it does consume additional cryptographic context on the mixer though it does consume additional cryptographic context on the mixer
for each participant and has the advantage of data origin for each participant and has the advantage of data origin
authentication. authentication.
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
skipping to change at page 44, line 46 skipping to change at page 45, line 5
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. The significant advantage of a reversed for a particular call. The significant advantage of a
single outbound session is the number of SRTP encryption operations single outbound session is the number of SRTP encryption operations
remains constant even as the number of participants increases. remains constant even as the number of participants increases.
However, a disadvantage is that data origin authentication is lost, However, a disadvantage is that data origin authentication is lost,
allowing any participant to spoof the sender (because all allowing any participant to spoof the sender (because all
participants know the sender's SRTP key). participants know the sender's SRTP key).
Appendix C. 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-CHECK
R11 (folded into R4; was reuse previous session)
R12 R-CERTS
R13 R-FIPS
R14 R-ASSOC
R15 R-ALLOW-RTP
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
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: steffen.fries@siemens.com EMail: steffen.fries@siemens.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Linnoitustie 6
Munich, Bavaria 81739 Espoo, 02600
Germany Finland
Email: Hannes.Tschofenig@nsn.com Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
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
 End of changes. 219 change blocks. 
703 lines changed or deleted 607 lines changed or added

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