draft-ietf-sip-media-security-requirements-04.txt   draft-ietf-sip-media-security-requirements-05.txt 
SIP Working Group D. Wing, Ed. SIP Working Group D. Wing, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational S. Fries Intended status: Informational S. Fries
Expires: September 21, 2008 Siemens AG Expires: November 6, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
March 20, 2008 May 5, 2008
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-04 draft-ietf-sip-media-security-requirements-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 21, 2008. This Internet-Draft will expire on November 6, 2008.
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 SRTP media. In addition to the
natural security requirements, this negotiation protocol must natural security requirements, this negotiation protocol must
interoperate well with SIP in certain ways. A number of proposals interoperate well with SIP in certain ways. A number of proposals
have been published and a summary of these proposals is in the have been published and a summary of these proposals is in the
appendix of this document. appendix of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Call Scenarios and Requirements Considerations . . . . . . . . 8
4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8 4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 9 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 9
4.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 11 4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12
4.6. Call Setup Performance . . . . . . . . . . . . . . . . . . 14 4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13
4.8. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 15 4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Key Management Protocol Requirements . . . . . . . . . . . 16 5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 17 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 25 Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 26 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 26 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 27 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 27 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. Security Descriptions with SIPS . . . . . . . . . . . 26
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 28 A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 27
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 28 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 28 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 27
A.1.12. Evaluation Criteria - SIP . . . . . . . . . . . . . . 28 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27
A.1.13. Evaluation Criteria - Security . . . . . . . . . . . . 37 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 44 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 44 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 29
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 45 A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 45 A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 45 A.4.2. Clipping Media Before SDP Answer . . . . . . . . . . . 31
Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 45 A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 49 A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 35
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 42
Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
The work on media security started when the Session Initiation The work on media security started when the Session Initiation
Protocol (SIP) was still in its infancy. With the increased SIP Protocol (SIP) was still in its infancy. With the increased SIP
deployment and the availability of new SIP extensions and related deployment and the availability of new SIP extensions and related
protocols, the need for end-to-end security was re-evaluated. The protocols, the need for end-to-end security was re-evaluated. The
procedure of re-evaluating prior protocol work and design decisions procedure of re-evaluating prior protocol work and design decisions
is not an uncommon strategy and, to some extent, considered necessary is not an uncommon strategy and, to some extent, considered necessary
to ensure that the developed protocols indeed meet the previously to ensure that the developed protocols indeed meet the previously
skipping to change at page 4, line 27 skipping to change at page 4, line 27
requirements for mechanisms that negotiate security context such as requirements for mechanisms that negotiate security context such as
cryptographic keys and parameters for SRTP. cryptographic keys and parameters for SRTP.
The organization of this document is as follows: Section 2 introduces The organization of this document is as follows: Section 2 introduces
terminology, Section 3 describes various attack scenarios against the terminology, Section 3 describes various attack scenarios against the
signaling path and media path, Section 4 provides an overview about signaling path and media path, Section 4 provides an overview about
possible call scenarios, Section 5 lists requirements for media possible call scenarios, Section 5 lists requirements for media
security. The main part of the document concludes with the security security. The main part of the document concludes with the security
considerations Section 6, IANA considerations Section 7 and an considerations Section 6, IANA considerations Section 7 and an
acknowledgement section in Section 8. Appendix A lists and compares acknowledgement section in Section 8. Appendix A lists and compares
available solution proposals. The following Appendix A.1.12 compares available solution proposals. The following Appendix A.4 compares
the different approaches regarding their suitability for the SIP the different approaches regarding their suitability for the SIP
signaling scenarios described in Appendix A, while Appendix A.1.13 signaling scenarios described in Appendix A, while Appendix A.5
provides a comparison regarding security aspects. Appendix B lists provides a comparison regarding security aspects. Appendix B lists
non-goals for this document. non-goals for this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the document are to be interpreted as described in [RFC2119], with the
important qualification that, unless otherwise stated, these terms important qualification that, unless otherwise stated, these terms
apply to the design of the media security key management protocol, apply to the design of the media security key management protocol,
skipping to change at page 7, line 47 skipping to change at page 7, line 47
is secured as per RFC4474 and the RFC4474 authenticator and verifier is secured as per RFC4474 and the RFC4474 authenticator and verifier
are behaving as per RFC4474). are behaving as per RFC4474).
The above discussion of DTLS-SRTP demonstrates how a single security The above discussion of DTLS-SRTP demonstrates how a single security
protocol can be in different classes depending on the mode in which protocol can be in different classes depending on the mode in which
it is operated. Other protocols can achieve similar effect by adding it is operated. Other protocols can achieve similar effect by adding
functions outside of the on-the-wire key management protocol itself. functions outside of the on-the-wire key management protocol itself.
Although it may be appropriate to deploy lower-classed mechanisms in Although it may be appropriate to deploy lower-classed mechanisms in
some cases, the ultimate security requirement for a media security some cases, the ultimate security requirement for a media security
negotiation protocol is that it have a mode of operation available in negotiation protocol is that it have a mode of operation available in
which it is detect-attack, which provides protection against the which is detect-attack, which provides protection against the passive
passive and active attacks and provides detection of such attacks. and active attacks and provides detection of such attacks. That is,
That is, there must be a way to use the protocol so that an active there must be a way to use the protocol so that an active attack is
attack is required against both the signaling and media paths, and so required against both the signaling and media paths, and so that such
that such attacks are detectable by the endpoints. attacks are detectable by the endpoints.
4. Call Scenarios 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.
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 requirement R-AVOID-
CLIPPING. CLIPPING and R-ALLOW-RTP.
Per the SDP Offer/Answer Model [RFC3264], Per the SDP Offer/Answer Model [RFC3264],
"Once the offerer has sent the offer, it MUST be prepared to "Once the offerer has sent the offer, it MUST be prepared to
receive media for any recvonly streams described by that offer. receive media for any recvonly streams described by that offer.
It MUST be prepared to send and receive media for any sendrecv It MUST be prepared to send and receive media for any sendrecv
streams in the offer, and send media for any sendonly streams in streams in the offer, and send media for any sendonly streams in
the offer (of course, it cannot actually send until the peer the offer (of course, it cannot actually send until the peer
provides an answer with the needed address and port information)." provides an answer with the needed address and port information)."
skipping to change at page 8, line 49 skipping to change at page 8, line 49
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
[I-D.ietf-mmusic-media-path-middleboxes]). In this case, even a [I-D.ietf-mmusic-media-path-middleboxes]). In this case, even a
solution that makes the key available before the SDP answer arrives solution that makes the key available before the SDP answer arrives
will not help. will not help.
Fixes to early media (i.e., the media that arrives at the SDP offerer Preventing the arrival of early media (i.e., media that arrives at
before the SDP answer arrives) might make the requirements to become the SDP offerer before the SDP answer arrives) might obsolete the
obsolete, but at the time of writing no progress has been R-AVOID-CLIPPING requirement, but at the time of writing such early
accomplished. 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
skipping to change at page 11, line 37 skipping to change at page 11, line 37
Further compounding this problem is a unique feature of SIP that when Further compounding this problem is a unique feature of SIP that when
forking is used, there is always only one final error response forking is used, there is always only one final error response
delivered to the sender of the request: the forking proxy is delivered to the sender of the request: the forking proxy is
responsible for choosing which final response to choose in the event responsible for choosing which final response to choose in the event
where forking results in multiple final error responses being where forking results in multiple final error responses being
received by the forking proxy. This means that if a request is received by the forking proxy. This means that if a request is
rejected, say with information that the keying information was rejected, say with information that the keying information was
rejected and providing the far end's credentials, it is very possible rejected and providing the far end's credentials, it is very possible
that the rejection will never reach the sender. This problem, called that the rejection will never reach the sender. This problem, called
the Heterogeneous Error Response Forking Problem (HERFP) the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326],
[I-D.mahy-sipping-herfp-fix], is difficult to solve in SIP. Because is difficult to solve in SIP. Because we expect the HERFP to
we expect the HERFP to continue to be a problem in SIP for the continue to be a problem in SIP for the foreseeable future, a media
foreseeable future, a media security system should function even in security system should function even in the presence of HERFP
the presence of HERFP behavior. behavior.
4.3. Shared Key Conferencing
The consensus on the RTPSEC mailing list was to concentrate on
unicast, point-to-point sessions. Thus, there are no requirements
related to shared key conferencing. This section is retained for
informational purposes.
For efficient scaling, large audio and video conference bridges
operate most efficiently by encrypting the current speaker once and
distributing that stream to the conference attendees. Typically,
inactive participants receive the same streams -- they hear (or see)
the active speaker(s), and the active speakers receive distinct
streams that don't include themselves. In order to maintain
confidentiality of such conferences where listeners share a common
key, all listeners must rekeyed when a listener joins or leaves a
conference.
An important use case for mixers/translators is a conference bridge:
+----+
A --- 1 --->| |
<-- 2 ----| M |
| I |
B --- 3 --->| X |
<-- 4 ----| E |
| R |
C --- 5 --->| |
<-- 6 ----| |
+----+
Figure 3: Centralized Keying
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
devices carrying the 'mixed' media.
Several scenarios are possible:
a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions,
b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP
sessions,
c. Single inbound session: 1, 3, and 5 are just different sources
within the same RTP session,
d. Single outbound session: 2, 4, and 6 are different flows of the
same (multi-unicast) RTP session
If there are multiple inbound sessions and multiple outbound sessions
(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
session between the participant and the mixer. This is the simplest
situation, but is computationally wasteful, since SRTP processing has
to be done independently for each participant. The use of multiple
inbound sessions (scenario a) doesn't waste computational resources,
though it does consume additional cryptographic context on the mixer
for each participant and has the advantage of data origin
authentication.
To support a single outbound session (scenario d), the mixer has to
dictate its encryption key to the participants. Some keying
mechanisms allow the transmitter to determine its own key, and others
allow the offerer to determine the key for the offerer and answerer.
Depending on how the call is established, the offerer might be a
participant (such as a participant dialing into a conference bridge)
or the offerer might be the mixer (such as a conference bridge
calling a participant). The use of offerless INVITEs may help some
keying mechanisms reverse the role of offerer/answerer. A
difficulty, however, is knowing a priori if the role should be
reversed for a particular call. The significant advantage of a
single outbound session is the number of SRTP encryption operations
remains constant even as the number of participants increases.
However, a disadvantage is that data origin authentication is lost,
allowing any participant to spoof the sender (because all
participants know the sender's SRTP key).
4.4. 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 brokers, banks, and catalog
call centers, require recording calls with customers. This is the call centers, require recording calls with customers. This is the
familiar "this call is being recorded for quality purposes" heard familiar "this call is being recorded for quality purposes" heard
during calls to these sorts of businesses. In these environments, during calls to these sorts of businesses. In these environments,
media recording is typically performed by an intermediate device media recording is typically performed by an intermediate device
(with RTP, this is typically implemented in a 'sniffer'). (with RTP, this is typically implemented in a 'sniffer').
skipping to change at page 14, line 5 skipping to change at page 12, line 19
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., [I-D.wing-sipping-srtp-key]).
4.5. 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 VoIP conversation over IP capable networks. However, there are
cases where the other end of the communication is not connected to an cases where the other end of the communication is not connected to an
IP capable network. In this kind of setting, there needs to be some IP capable network. In this kind of setting, there needs to be some
skipping to change at page 14, line 28 skipping to change at page 12, line 42
of such gateway is a PSTN gateway sitting at the edge of IP and PSTN of such gateway is a PSTN gateway sitting at the edge of IP and PSTN
networks (such as the architecture described in [RFC3372]). networks (such as the architecture described in [RFC3372]).
If media security (e.g., SRTP protection) is employed in this kind of If media security (e.g., SRTP protection) is employed in this kind of
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 truely end-to-end between the communicating entities.
4.6. 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 re-
use previous public key or Diffie-Hellman operations can vastly use 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.
skipping to change at page 15, line 11 skipping to change at page 13, line 26
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.7. 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 is 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 which 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 B2BUA (to modify the SDP) and a processor to perform the transcoding
between the codecs. However, with end-to-end secured SRTP, a between the codecs. However, with end-to-end secured SRTP, a
transcoding function implemented the same way is a man in the middle transcoding function implemented the same way is a man in the middle
attack, and the key management system prevents its use. 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.8. 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
[I-D.stucker-sipping-early-media-coping]. [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
The discussion in this section relates to the requirement R-OTHER-
SIGNALING.
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]
or do not utilize SDP (e.g., H.323). In other environments, both
endpoints may be SIP, but may use different key management systems
(e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R).
In these environments, it is desirable to have SRTP -- rather than
RTP -- between the two endpoints. It is always possible, although
undesirable, to interwork those disparate signaling systems or
disparate key management systems by decrypting and re-encrypting each
SRTP packet in a device in the middle of the network (often the same
device performing the signaling interworking). This is undesirable
due to the cost and increased attack area, as such an SRTP/SRTP
interworking device is a valuable attack target.
At the time of this writing, interworking is considered important.
Interworking without decryption/encryption of the SRTP, while useful,
is not yet deemed critical because the scale of such SRTP deployments
is, to date, relatively small.
4.9. Certificates
The discussion in this section relates to R-CERTS.
On the Internet and on some private networks, validating another
peer's certificate is often done through a trust anchor -- a list of
Certificate Authorities that are trusted. It can be difficult or
expensive for a peer to obtain these certificates. In all cases,
both parties to the call would need to trust the same trust anchor
(i.e., "certificate authority"). For these reasons, it is important
that authentication mechanisms that utilize trust anchors not rely
exclusively on such Certificate Authority-issued certificates, but to
also allow self-signed certificates. By allowing the use of such
self-signed certificates, an out-of-band mechanism (e.g., manual
configuration) can be used to trust a peer's certificate.
5. Requirements 5. Requirements
This section is divided into several parts: requirements specific to This section is divided into several parts: requirements specific to
the key management protocol (Section 5.1), attack scenarios the key management protocol (Section 5.1), attack scenarios
(Section 5.2), and requirements which can be met inside the key (Section 5.2), and requirements which can be met inside the key
management protocol or outside of the key management protocol management protocol or outside of the key management protocol
(Section 5.3). (Section 5.3).
5.1. Key Management Protocol Requirements 5.1. Key Management Protocol Requirements
skipping to change at page 16, line 19 skipping to change at page 15, line 26
R-FORK-RETARGET: R-FORK-RETARGET:
The media security key management protocol MUST securely The media security key management protocol MUST securely
support forking and retargeting when all endpoints are willing support forking and retargeting when all endpoints are willing
to use SRTP without causing the call setup to fail. This to use SRTP without causing the call setup to fail. This
requirement means the endpoints that did not answer the call requirement means the endpoints that did not answer the call
MUST NOT learn the SRTP keys (in either direction) used by the MUST NOT learn the SRTP keys (in either direction) used by the
answering endpoint. answering endpoint.
R-DISTINCT: R-DISTINCT:
The media security key management protocol MUST be capble of The media security key management protocol MUST be capable of
creating distinct, independent cryptographic contexts for each creating distinct, independent cryptographic contexts for each
endpoint in a forked session. 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. securely even in the presence of HERFP behavior.
Performance considerations: Performance considerations:
R-REUSE: R-REUSE:
skipping to change at page 17, line 9 skipping to change at page 16, line 15
R-RTP-VALID: R-RTP-VALID:
If SRTP key negotiation is performed over the media path (i.e., If SRTP key negotiation is performed over the media path (i.e.,
using the same UDP/TCP ports as media packets), the key using the same UDP/TCP ports as media packets), the key
negotiation packets MUST NOT pass the RTP validity check negotiation packets MUST NOT pass the RTP validity check
defined in Appendix A.1 of [RFC3550]. defined in Appendix A.1 of [RFC3550].
R-ASSOC: 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 the
signaling traffic that initiated the session and with protected signaling traffic that initiated the session and with protected
media traffic. Allowing such an association also allows the media traffic. It is useful to associate key management
SDP offerer to avoid performing CPU-consuming operations (e.g., messages with call signaling messages, as this allows the SDP
offerer to avoid performing CPU-consuming operations (e.g.,
Diffie-Hellman or public key operations) with attackers that Diffie-Hellman or public key operations) with attackers that
have not seen the signaling messages. have not seen the signaling messages.
For example, if using a Diffie-Hellman keying technique with For example, if using a Diffie-Hellman keying technique with
security preconditions that forks to 20 end points, the call security preconditions that forks to 20 end points, the call
initiator would get 20 provisional responses containing 20 initiator would get 20 provisional responses containing 20
signed Diffie-Hellman key pairs. Calculating 20 DH secrets and signed Diffie-Hellman key pairs. Calculating 20 Diffie-Hellman
validating signatures can be a difficult task depending on the secrets and validating signatures can be a difficult task for
device capabilities. Hence, in the case of forking, it is not some devices. Hence, in the case of forking, it is not
desirable to perform a DH or PK operation with every party, but desirable to perform a Diffie-Hellman operation with every
rather only with the party that answers the call (and incur party, but rather only with the party that answers the call
some media clipping). To do this, the signaling and media need (and incur some media clipping). To do this, the signaling and
to be associated so the calling party knows which key media need to be associated so the calling party knows which
management needs to be completed. This might be done by using key management exchange needs to be completed. This might be
the transport address indicated in the SDP, although NATs can done by using the transport address indicated in the SDP,
complicate this association. 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 SRTP receivers will have to perform authentication that SRTP receivers will have to perform authentication
of any received SRTP packets. of any 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 SIP
User Agent to negotiate media security parameters for each User Agent to negotiate media security parameters for each
individual session. individual session.
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.5. 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).
Overall security requirements: Overall security requirements:
R-PFS: R-PFS:
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:
If the media security key management protocol employs The media security key management protocol MUST NOT constrain
certificates, it MUST be able to make use of both self-signed the set of trust anchors that a peer can use to validate
and CA-issued certificates. As an alternative, the media certificates used in the protocol.
security key management protocol MAY make use of "bare" public
keys.
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. algorithms that allow FIPS 140-2 [FIPS-140-2] certification.
Note that the United States Government can only purchase and The United States Government can only purchase and use crypto
use crypto implementations that have been validated by the implementations that have been validated by the FIPS-140
FIPS-140 [FIPS-140-2] process: [FIPS-140-2] process:
"The FIPS-140 standard is applicable to all Federal agencies "The FIPS-140 standard is applicable to all Federal
that use cryptographic-based security systems to protect agencies that use cryptographic-based security systems to
sensitive information in computer and telecommunication protect sensitive information in computer and
systems, including voice systems. The adoption and use of this telecommunication systems, including voice systems. The
standard is available to private and commercial adoption and use of this standard is available to private
organizations."[cryptval] and commercial organizations."
Some commercial organizations, such as banks and defense Some commercial organizations, such as banks and defense
contractors, also require or prefer equipment which has contractors, require or prefer equipment which has received the
validated by the FIPS-140 process. same validation.
R-DOS: R-DOS:
The media security key management protocol SHOULD NOT introduce The media security key management protocol SHOULD NOT introduce
new denial of service vulnerabilities (e.g., the protocol new denial of service vulnerabilities (e.g., the protocol
should not request the endpoint to perform CPU-intensive should not request the endpoint to perform CPU-intensive
operations without the client being able to validate or operations without the client being able to validate or
authorize the request). authorize the request).
R-EXISTING: R-EXISTING:
The media security key management protocol SHOULD allow The media security key management protocol SHOULD allow
skipping to change at page 20, line 10 skipping to change at page 19, line 20
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 end points of a forked or retargeted call are
incapable of using SRTP, a solution MUST be described which incapable of using SRTP, a solution MUST be described which
allows the establishment of SRTP associations with SRTP-capable allows the establishment of SRTP associations with SRTP-capable
endpoints and / or RTP associations with non-SRTP-capable endpoints and / or RTP associations with non-SRTP-capable
endpoints. This requirement comes from Section 4.2. 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 SRTP sessions
created via different call signaling protocols (e.g., between created via different call signaling protocols (e.g., between
Jabber, SIP, H.323, MGCP). Jabber, SIP, H.323, MGCP).
R-RECORDING: R-RECORDING:
A solution SHOULD be described which supports recording of A solution SHOULD be described which supports recording of
decrypted media. This requirement comes from Section 4.4. 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 which supports intermediate
nodes (e.g., transcoders), terminating or processing media, nodes (e.g., transcoders), terminating or processing media,
between the end points. between the end points.
R-ALLOW-RTP: A solution SHOULD be described which allows RTP media R-ALLOW-RTP: A solution SHOULD be described which allows RTP media
to be received by the calling party until SRTP has been to 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 preferred
over RTP. over RTP.
skipping to change at page 20, line 44 skipping to change at page 20, line 9
such, it addresses security throughout the document. such, it addresses security throughout the document.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgements 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. The authors would furthermore like and on the RTPSEC mailing list, and a special thanks to Steffen Fries
to thank Wolfgang Buecker, Guenther Horn, Peter Howard, Hans-Heinrich and Dragan Ignjatic for their excellent MIKEY comparison document
Grusdt, Srinath Thiruvengadam, Martin Euchner, Eric Rescorla, Matt [I-D.ietf-msec-mikey-applicability].
Lepinski, Dan York, Werner Dittmann, Richard Barnes, Vesa Lehtovirta,
Colin Perkins, Peter Schneider, and Christer Holmberg for their
feedback to this document.
For contributions to the analysis portion of this document, the
authors would like to thank Special thanks to Steffen Fries and
Dragan Ignjatic for their excellent MIKEY comparison document
[I-D.ietf-msec-mikey-applicability]. The authors would furthermore
like to thank Cullen Jennings, David Oran, David McGrew, Mark
Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric
Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan
Ignjatic and John Elwell for their feedback to this document.
Thanks to Richard Barnes and Peter Schneider for thorough reviews and The authors would furthermore like to thank the following people for
suggestions which improved the document considerably. their review, suggestions, and comments: Flemming Andreasen, Richard
Barnes, Richard Barnes, Mark Baugher, Wolfgang Buecker, Werner
Dittmann, Lakshminath Dondeti, John Elwell, Martin Euchner, Steffen
Fries, Hans-Heinrich Grusdt, Christer Holmberg, Guenther Horn, Peter
Howard, Leo Huang, Dragan Ignjatic, Cullen Jennings, Alan Johnston,
Vesa Lehtovirta, Matt Lepinski, David McGrew, David Oran, Colin
Perkins, Eric Raymond, Eric Rescorla, Peter Schneider, Srinath
Thiruvengadam, Dave Ward, Dan York, and Phil Zimmermann.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-140-2] [FIPS-140-2]
NIST, "Security Requirements for Cryptographic Modules", NIST, "Security Requirements for Cryptographic Modules",
June 2005, <http://csrc.nist.gov/publications/fips/ June 2005, <http://csrc.nist.gov/publications/fips/
fips140-2/fips1402.pdf>. fips140-2/fips1402.pdf>.
skipping to change at page 22, line 7 skipping to change at page 21, line 12
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[cryptval] [cryptval]
NIST, "Cryptographic Module Validation Program", NIST, "Cryptographic Module Validation Program",
December 2006, December 2006,
<http://csrc.nist.gov/cryptval/140-2APP.htm>. <http://csrc.nist.gov/cryptval/140-2APP.htm>.
9.2. Informative References 9.2. Informative References
[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] [I-D.baugher-mmusic-sdp-dh]
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
in progress), February 2006. in progress), February 2006.
[I-D.dondeti-msec-rtpsec-mikeyv2] [I-D.dondeti-msec-rtpsec-mikeyv2]
Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY,
revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in
progress), March 2007. progress), March 2007.
skipping to change at page 22, line 52 skipping to change at page 22, line 11
progress), January 2008. progress), January 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 2007. progress), December 2007.
[I-D.ietf-msec-mikey-applicability] [I-D.ietf-msec-mikey-applicability]
Fries, S. and D. Ignjatic, "On the applicability of Fries, S. and D. Ignjatic, "On the applicability of
various MIKEY modes and extensions", various MIKEY modes and extensions",
draft-ietf-msec-mikey-applicability-08 (work in progress), draft-ietf-msec-mikey-applicability-09 (work in progress),
February 2008. March 2008.
[I-D.ietf-msec-mikey-ecc] [I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY", Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress), draft-ietf-msec-mikey-ecc-03 (work in progress),
June 2007. June 2007.
[I-D.ietf-sip-certs] [I-D.ietf-sip-certs]
Jennings, C., Peterson, J., and J. Fischl, "Certificate Jennings, C. and J. Fischl, "Certificate Management
Management Service for The Session Initiation Protocol Service for The Session Initiation Protocol (SIP)",
(SIP)", draft-ietf-sip-certs-05 (work in progress), draft-ietf-sip-certs-06 (work in progress), April 2008.
February 2008.
[I-D.ietf-tls-rfc4346-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
(work in progress), March 2008.
[I-D.jennings-sipping-multipart] [I-D.jennings-sipping-multipart]
Wing, D. and C. Jennings, "Session Initiation Protocol Wing, D. and C. Jennings, "Session Initiation Protocol
(SIP) Offer/Answer with Multipart Alternative", (SIP) Offer/Answer with Multipart Alternative",
draft-jennings-sipping-multipart-02 (work in progress), draft-jennings-sipping-multipart-02 (work in progress),
March 2006. March 2006.
[I-D.mahy-sipping-herfp-fix]
Mahy, R., "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP) in the Session Initiation
Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in
progress), March 2006.
[I-D.mcgrew-srtp-ekt] [I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP", McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
[I-D.stucker-sipping-early-media-coping] [I-D.stucker-sipping-early-media-coping]
Stucker, B., "Coping with Early Media in the Session Stucker, B., "Coping with Early Media in the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-stucker-sipping-early-media-coping-03 (work in draft-stucker-sipping-early-media-coping-03 (work in
progress), October 2006. progress), October 2006.
skipping to change at page 24, line 5 skipping to change at page 23, line 11
Session Initiation Protocol", Session Initiation Protocol",
draft-wing-sipping-srtp-key-03 (work in progress), draft-wing-sipping-srtp-key-03 (work in progress),
February 2008. February 2008.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP", Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-06 (work in progress), draft-zimmermann-avt-zrtp-06 (work in progress),
March 2008. March 2008.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures", for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[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., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. 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 Media
skipping to change at page 25, line 15 skipping to change at page 24, line 18
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams", Session Description Protocol (SDP) Media Streams",
RFC 5027, October 2007. RFC 5027, October 2007.
Appendix A. Overview 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: All the keying is carried in the call signaling signaling path:
(SIP or SDP) path. All the keying is carried in the call signaling (SIP or SDP)
path.
media path: All the keying is carried in the SRTP/SRTCP media media path:
path, and no signaling whatsoever is carried in the call All the keying is carried in the SRTP/SRTCP media path, and no
signaling path. signaling whatsoever is carried in the call signaling path.
signaling and media path: Parts of the keying are carried in the signaling and media path:
SRTP/SRTCP media path, and parts are carried in the call Parts of the keying are carried in the SRTP/SRTCP media path,
signaling (SIP or SDP) 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
skipping to change at page 28, line 40 skipping to change at page 27, line 41
MIKEYv1 and removes the time synchronization requirement. It MIKEYv1 and removes the time synchronization requirement. It
therefore now takes 2 round-trips to complete. In the first round therefore now takes 2 round-trips to complete. In the first round
trip, the communicating parties learn each other's identities, agree trip, the communicating parties learn each other's identities, agree
on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces
for replay protection. In the second round trip, they negotiate for replay protection. In the second round trip, they negotiate
unicast and/or group SRTP context for SRTP and/or SRTCP. unicast and/or group SRTP context for SRTP and/or SRTCP.
Furthemore, MIKEYv2 also defines an in-band negotiation mode as an Furthemore, MIKEYv2 also defines an in-band negotiation mode as an
alternative to SDP (see Appendix A.3.3). alternative to SDP (see Appendix A.3.3).
A.1.12. Evaluation Criteria - SIP A.2. Media Path Keying Technique
A.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the
signaling path (although it's possible for endpoints to exchange a
hash of the ZRTP Hello message with "a=zrtp-hash" in the initial
Offer if sent over an integrity-protected signaling channel. This
provides some useful correlation between the signaling and media
layers). In ZRTP the keys are exchanged entirely in the media path
using a Diffie-Hellman exchange. The advantage to this mechanism is
that the signaling channel is used only for call setup and the media
channel is used to establish an encrypted channel -- much like
encryption devices on the PSTN. ZRTP uses voice authentication of
its Diffie-Hellman exchange by having each person read digits or
words to the other person. Subsequent sessions with the same ZRTP
endpoint can be authenticated using the stored hash of the previously
negotiated key rather than voice authentication. ZRTP uses 4 media
path messages (Hello, Commit, DHPart1, and DHPart2) to establish the
SRTP key, and 3 media path confirmation messages. These initial
messages are all sent as non-RTP packets.
Note that when ZRTP probing is used, unencrypted RTP can be
exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques
A.3.1. EKT
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange
protocol, such as Security Descriptions or MIKEY, for bootstrapping.
In the initial phase, each member of a conference uses an SRTP key
exchange protocol to establish a common key encryption key (KEK).
Each member may use the KEK to securely transport its SRTP master key
and current SRTP rollover counter (ROC), via RTCP, to the other
participants in the session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP
message which contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent.
A.3.2. DTLS-SRTP
DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints
in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS
session over the media channel. The endpoints use the DTLS handshake
to agree on crypto suites and establish SRTP session keys. SRTP
packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round
trip), and one message from the answerer to offerer (full round trip)
so the offerer can correlate the SDP answer with the answering
endpoint. DTLS-SRTP uses 4 media path messages to establish the SRTP
key.
This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as
its cipher suite, which is the mandatory-to-implement cipher suite in
TLS [I-D.ietf-tls-rfc4346-bis].
A.3.3. MIKEYv2 Inband (expired)
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band
negotiation mode as an alternative to SDP (see Appendix A.3.3). The
details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.).
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.1.12.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 Secure Forking: No, all AORs see offerer's and
answerer's keys. Answer is associated with media by the SSRC answerer's keys. Answer is associated with media by the SSRC
skipping to change at page 30, line 40 skipping to change at page 31, line 20
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
Secure Forking: Yes. Each forked endpoint calculates a unique Yes. Each forked endpoint calculates a unique SRTP key. With
SRTP key. As ZRTP isn't signaled in SDP, there is no the "a=zrtp-hash" attribute, the media can be associated with
association of the answer with media. 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 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.
skipping to change at page 31, line 19 skipping to change at page 31, line 47
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.1.12.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 5 skipping to change at page 33, line 32
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 [I-D.ietf-mmusic-media-path-middleboxes].
MIKEYv2 Inband MIKEYv2 Inband
Not clipped. Keys are exchanged in the media path without Not clipped. Keys are exchanged in the media path without
relying on the signaling path. relying on the signaling path.
A.1.12.3. Centralized Keying A.4.3. SSRC and ROC
Centralized keying is described within Section 4.3. The following
builds upon this description.
The following list describes how each keying mechanism behaves with
centralized keying (scenario d) and rekeying.
MIKEY-NULL
Keying: Yes, if offerer is the mixer. No, if offerer is the
participant (end user).
Rekeying: Yes, via re-INVITE
MIKEY-PSK
Keying: Yes, if offerer is the mixer. No, if offerer is the
participant (end user).
Rekeying: Yes, with a re-INVITE
MIKEY-RSA
Keying: Yes, if offerer is the mixer. No, if offerer is the
participant (end user).
Rekeying: Yes, with a re-INVITE
MIKEY-RSA-R
Keying: No, if offerer is the mixer. Yes, if offerer is the
participant (end user).
Rekeying: n/a
MIKEY-DHSIGN
Keying: No; a group-key Diffie-Hellman protocol is not
supported.
Rekeying: n/a
MIKEY-DHHMAC
Keying: No; a group-key Diffie-Hellman protocol is not
supported.
Rekeying: n/a
MIKEYv2 in SDP
The behavior will depend on which mode is picked.
Security Descriptions with SIPS
Keying: Yes, if offerer is the mixer. Yes, if offerer is the
participant.
Rekeying: Yes, with a re-INVITE.
Security Descriptions with S/MIME
Keying: Yes, if offerer is the mixer. Yes, if offerer is the
participant.
Rekeying: Yes, with a re-INVITE.
SDP-DH
Keying: No; a group-key Diffie-Hellman protocol is not
supported.
Rekeying: n/a
ZRTP
Keying: No; a group-key Diffie-Hellman protocol is not
supported.
Rekeying: n/a
EKT
Keying: Yes. After bootstrapping a KEK using Security
Descriptions or MIKEY, each member originating an SRTP stream
can send its SRTP master key, sequence number and ROC via RTCP.
Rekeying: Yes. EKT supports each sender to transmit its SRTP
master key to the group via RTCP packets. Thus, EKT supports
each originator of an SRTP stream to rekey at any time.
DTLS-SRTP
Keying: Yes, because with the assumed cipher suite,
TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key.
Rekeying: via DTLS in the media path.
MIKEYv2 Inband
The behavior will depend on which mode is picked.
A.1.12.4. SSRC and ROC
In SRTP, a cryptographic context is defined as the SSRC, destination In SRTP, a cryptographic context is defined as the SSRC, destination
network address, and destination transport port number. Whereas RTP, network address, and destination transport port number. Whereas RTP,
a flow is defined as the destination network address and destination a flow is defined as the destination network address and destination
transport port number. This results in a problem -- how to transport port number. This results in a problem -- how to
communicate the SSRC so that the SSRC can be used for the communicate the SSRC so that the SSRC can be used for the
cryptographic context. cryptographic context.
Two approaches have emerged for this communication. One, used by all Two approaches have emerged for this communication. One, used by all
MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY
skipping to change at page 37, line 9 skipping to change at page 35, line 34
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.1.13. 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.
A.1.13.1. Distribution and Validation of Public Keys and Certificates A.5.1. Distribution and Validation of Persistent Public Keys and
Certificates
Using public key cryptography for confidentiality and authentication Using persistent public keys for confidentiality and authentication
can introduce requirements for two types of systems: (1) a system to can introduce requirements for two types of systems, often
distribute public keys (often in the form of certificates), and (2) a implemented using certificates: (1) a system to distribute those
system for validating certificates. We refer to the former as a key persistent public keys certificates, and (2) a system for validating
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 for fulfill both of these roles.
However, these functions can be provided by many other systems. For However, these functions can be provided by many other systems. For
instance, key distribution may be accomplished by any public instance, key distribution may be accomplished by any public
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 keys With real-time communications it is desirable to avoid fetching or
or certificates that delay call setup; rather it is preferable to validating certificates that delay call setup. Rather, it is
fetch or validate certificates in such a way that call setup isn't preferable to fetch or validate certificates in such a way that call
delayed. For example, a certificate can be validated while the phone setup is not delayed. For example, a certificate can be validated
is ringing or can be validated while ring-back tones are being played while the phone is ringing or can be validated while ring-back tones
or even while the called party is answering the phone and saying are being played or even while the called party is answering the
"hello". phone and saying "hello". Even better is to avoid fetching or
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 [I-D.ietf-sip-certs] might be used to obtain the certificate of
a peer. a peer.
Note: Even if sip-certs [I-D.ietf-sip-certs] was deployed, the Note: Even if sip-certs [I-D.ietf-sip-certs] was deployed, the
retargeting problem (Appendix A.1.12.1) would still prevent retargeting problem (Appendix A.4.1) would still prevent
successful deployment of keying techniques which require the successful deployment of keying techniques which require the
offerer to obtain the actual target's public key. offerer to obtain the actual target's public key.
The following list compares the requirements introduced by the use of The following list compares the requirements introduced by the use of
public-key cryptography in each keying mechanism, both for public key public-key cryptography in each keying mechanism, both for public key
distribution and for certificate validation. distribution and for certificate validation.
MIKEY-NULL MIKEY-NULL
Public-key cryptography is not used. Public-key cryptography is not used.
skipping to change at page 39, line 18 skipping to change at page 37, line 45
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.
ZRTP ZRTP
Public-key cryptography is not used. Public-key cryptography is used (Diffie-Hellman), but without
dependence on persistent public keys. Thus, certificates are
not fetched or validated.
EKT EKT
Public-key cryptography is not used by itself, but might be Public-key cryptography is not used by itself, but might be
used by the EKT bootstrapping keying mechanism (such as certain used by the EKT bootstrapping keying mechanism (such as certain
MIKEY modes). MIKEY modes).
DTLS-SRTP DTLS-SRTP
Remote party's certificate is sent in media path, and a Remote party's certificate is sent in media path, and a
fingerprint of the same certificate is sent in the signaling fingerprint of the same certificate is sent in the signaling
path. path.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
A.1.13.2. Perfect Forward Secrecy A.5.2. Perfect Forward Secrecy
In the context of SRTP, Perfect Forward Secrecy is the property that In the context of SRTP, Perfect Forward Secrecy is the property that
SRTP session keys that protected a previous session are not SRTP session keys that protected a previous session are not
compromised if the static keys belonging to the endpoints are compromised if the static keys belonging to the endpoints are
compromised. That is, if someone were to record your encrypted compromised. That is, if someone were to record your encrypted
session content and later acquires either party's private key, that session content and later acquires either party's private key, that
encrypted session content would be safe from decryption if your key encrypted session content would be safe from decryption if your key
exchange mechanism had perfect forward secrecy. exchange mechanism had perfect forward secrecy.
The following list describes how each key exchange mechanism provides The following list describes how each key exchange mechanism provides
skipping to change at page 40, line 41 skipping to change at page 39, line 19
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 achieved if the negotiated cipher suite includes an PFS is provided if the negotiated cipher suite uses ephemeral
exponential or discrete-logarithmic key exchange (e.g., Diffie- keys (e.g., Diffie-Hellman (DHE_RSA [I-D.ietf-tls-rfc4346-bis])
Hellman (DH_RSA from [RFC4346]) or Elliptic Curve Diffie- or Elliptic Curve Diffie-Hellman [RFC4492]).
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.1.13.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
skipping to change at page 41, line 36 skipping to change at page 40, line 11
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 [I-D.jennings-sipping-multipart] describes how to form a
multipart/alternative body part in SIP. The significant issues multipart/alternative body part in SIP. The significant issues
with this technique are (1) that multipart MIME is incompatible with this technique are (1) that multipart MIME is incompatible
with existing SIP proxies, firewalls, Session Border Controllers, with existing SIP proxies, firewalls, Session Border Controllers,
and endpoints and (2) when forking, the Heterogeneous Error and endpoints and (2) when forking, the Heterogeneous Error
Response Forking Problem (HERFP) [I-D.mahy-sipping-herfp-fix] Response Forking Problem (HERFP) [RFC3326] causes problems if such
causes problems if such non-multipart-capable endpoints were non-multipart-capable endpoints were involved in the forking.
involved in the forking.
SDP Grouping
A new SDP grouping mechanism (following the idea introduced in
[RFC3388]) has been discussed which would allow a media line to
indicate RTP/AVP and another media line to indicate RTP/SAVP,
allowing non-SRTP-aware endpoints to choose RTP/AVP and SRTP-aware
endpoints to choose RTP/SAVP. As of this writing, this SDP
grouping mechanism has not been published as an Internet Draft.
session attribute session attribute
With this technique, the endpoints signal their desire to do SRTP With this technique, the endpoints signal their desire to do SRTP
by signaling RTP (RTP/AVP), and using an attribute ("a=") in the by signaling RTP (RTP/AVP), and using an attribute ("a=") in the
SDP. This technique is entirely backwards compatible with non- SDP. This technique is entirely backwards compatible with non-
SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol
registered by SRTP [RFC3711]. registered by SRTP [RFC3711].
SDP Capability Negotiation SDP Capability Negotiation
SDP Capability Negotiation SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation] 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. keying technique. A disadvantage of probing is an active attacker
can interfere with probes, and until probing completes (and SRTP
is established) the media is in the clear.
The preferred technique, SDP Capability Negotiation The preferred technique, SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all [I-D.ietf-mmusic-sdp-capability-negotiation], can be used with all
key exchange mechanisms. What remains unique is ZRTP, which can also key exchange mechanisms. What remains unique is ZRTP, which can also
accomplish its best effort encryption by probing (sending ZRTP accomplish its best effort encryption by probing (sending ZRTP
messages over the media path) or by session attribute (see "a=zrtp", messages over the media path) or by session attribute (see "a=zrtp-
defined in Section 10 of [I-D.zimmermann-avt-zrtp]). Current hash" in [I-D.zimmermann-avt-zrtp]). Current implementations of ZRTP
implementations of ZRTP use probing. use probing.
A.1.13.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 computionally expensive because the offer needs to contain all
combinations of the key exchange mechanisms (all MIKEY modes, combinations of the key exchange mechanisms (all MIKEY modes,
Security Descriptions) and all SRTP cryptographic suites (AES-128, Security Descriptions) and all SRTP cryptographic suites (AES-128,
AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256) AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256)
that the offerer supports. In order to do this, the offerer has to that the offerer supports. In order to do this, the offerer has to
expend CPU resources to build an offer containing all of this expend CPU resources to build an offer containing all of this
skipping to change at page 43, line 43 skipping to change at page 42, line 12
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". "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). 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.
A.2. Media Path Keying Technique Appendix B. Out-of-Scope
A.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the
signaling path (although it's possible for endpoints to indicate
support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the
keys are exchanged entirely in the media path using a Diffie-Hellman
exchange. The advantage to this mechanism is that the signaling
channel is used only for call setup and the media channel is used to
establish an encrypted channel -- much like encryption devices on the
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
by having each person read digits to the other person. Subsequent
sessions with the same ZRTP endpoint can be authenticated using the
stored hash of the previously negotiated key rather than voice
authentication.
ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2) The compromise of an endpoint that has access to decrypted media
to establish the SRTP key, and 3 media path confirmation messages. (e.g., SIP user agent, transcoder, recorder) is out of scope of this
These initial messages are all sent as non-RTP packets. document. Such a compromise might be via privilege escalation,
installation of a virus or trojan horse, or similar attacks.
Note that when ZRTP probing is used, unencrypted RTP is being B.1. Shared Key Conferencing
exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques The consensus on the RTPSEC mailing list was to concentrate on
unicast, point-to-point sessions. Thus, there are no requirements
related to shared key conferencing. This section is retained for
informational purposes.
A.3.1. EKT For efficient scaling, large audio and video conference bridges
operate most efficiently by encrypting the current speaker once and
distributing that stream to the conference attendees. Typically,
inactive participants receive the same streams -- they hear (or see)
the active speaker(s), and the active speakers receive distinct
streams that don't include themselves. In order to maintain
confidentiality of such conferences where listeners share a common
key, all listeners must rekeyed when a listener joins or leaves a
conference.
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange An important use case for mixers/translators is a conference bridge:
protocol, such as Security Descriptions or MIKEY, for bootstrapping.
In the initial phase, each member of a conference uses an SRTP key
exchange protocol to establish a common key encryption key (KEK).
Each member may use the KEK to securely transport its SRTP master key
and current SRTP rollover counter (ROC), via RTCP, to the other
participants in the session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, +----+
and security parameter index (SPI)) via the bootstrapping protocol A --- 1 --->| |
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP <-- 2 ----| M |
message which contains the answerer's SRTP Master Key, rollover | I |
counter, and the SRTP sequence number. Rekeying is done by sending a B --- 3 --->| X |
new SRTCP message. For reliable transport, multiple RTCP messages <-- 4 ----| E |
need to be sent. | R |
C --- 5 --->| |
<-- 6 ----| |
+----+
A.3.2. DTLS-SRTP Figure 3: Centralized Keying
DTLS-SRTP [I-D.ietf-avt-dtls-srtp] exchanges public key fingerprints In the figure above, 1, 3, and 5 are RTP media contributions from
in SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those
session over the media channel. The endpoints use the DTLS handshake devices carrying the 'mixed' media.
to agree on crypto suites and establish SRTP session keys. SRTP
packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round Several scenarios are possible:
trip), and one message from the answerer to offerer (full round trip)
so the offerer can correlate the SDP answer with the answering
endpoint. DTLS-SRTP uses 4 media path messages to establish the SRTP
key.
This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions,
its cipher suite, which is the mandatory-to-implement cipher suite in
TLS [RFC4346].
A.3.3. MIKEYv2 Inband (expired) b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP
sessions,
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band c. Single inbound session: 1, 3, and 5 are just different sources
negotiation mode as an alternative to SDP (see Appendix A.3.3). The within the same RTP session,
details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.).
Appendix B. Out-of-Scope d. Single outbound session: 2, 4, and 6 are different flows of the
same (multi-unicast) RTP session
Discussions concluded that key management for shared-key encryption If there are multiple inbound sessions and multiple outbound sessions
of conferencing is outside the scope of this document. As the (scenarios a and b), then every keying mechanism behaves as if the
priority is point-to-point unicast SRTP session keying, resolving mixer were an end point and can set up a point-to-point secure
shared-key SRTP session keying is deferred to later and left as an session between the participant and the mixer. This is the simplest
item for future investigations. situation, but is computationally wasteful, since SRTP processing has
to be done independently for each participant. The use of multiple
inbound sessions (scenario a) doesn't waste computational resources,
though it does consume additional cryptographic context on the mixer
for each participant and has the advantage of data origin
authentication.
The compromise of an endpoint that has access to decrypted media To support a single outbound session (scenario d), the mixer has to
(e.g., SIP user agent, transcoder, recorder) is out of scope of this dictate its encryption key to the participants. Some keying
document. Such a compromise might be via privilege escalation, mechanisms allow the transmitter to determine its own key, and others
installation of a virus or trojan horse, or similar attacks. allow the offerer to determine the key for the offerer and answerer.
Depending on how the call is established, the offerer might be a
participant (such as a participant dialing into a conference bridge)
or the offerer might be the mixer (such as a conference bridge
calling a participant). The use of offerless INVITEs may help some
keying mechanisms reverse the role of offerer/answerer. A
difficulty, however, is knowing a priori if the role should be
reversed for a particular call. The significant advantage of a
single outbound session is the number of SRTP encryption operations
remains constant even as the number of participants increases.
However, a disadvantage is that data origin authentication is lost,
allowing any participant to spoof the sender (because all
participants know the sender's SRTP key).
Appendix C. Requirement renumbering in -02 Appendix C. Requirement renumbering in -02
[[RFC Editor: Please delete this section prior to publication.]] [[RFC Editor: Please delete this section prior to publication.]]
Previous versions of this document used requirement numbers, which Previous versions of this document used requirement numbers, which
were changed to mnemonics as follows: were changed to mnemonics as follows:
R1 R-FORK-RETARGET R1 R-FORK-RETARGET
R2 R-BEST-SECURE R2 R-BEST-SECURE
R3 R-DISTINCT R3 R-DISTINCT
R4 R-REUSE; changed from 'MAY' to 'protocol MUST support, and R4 R-REUSE; changed from 'MAY' to 'protocol MUST support, and
skipping to change at page 47, line 44 skipping to change at page 46, line 19
Email: steffen.fries@siemens.com Email: steffen.fries@siemens.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.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
Full Copyright Statement Full Copyright Statement
 End of changes. 82 change blocks. 
418 lines changed or deleted 368 lines changed or added

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