< draft-wing-media-security-requirements-04.txt   draft-wing-media-security-requirements-05.txt >
Network Working Group D. Wing Network Working Group D. Wing
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational S. Fries Intended status: Informational S. Fries
Expires: December 27, 2007 Siemens AG Expires: March 23, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
June 25, 2007 F. Audet
B. Stucker
Nortel
September 20, 2007
Requirements for a Media Security Key Management Protocol Requirements and Analysis of Media Security Key Management Protocols
draft-wing-media-security-requirements-04.txt draft-wing-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 37 skipping to change at page 1, line 40
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 December 27, 2007. This Internet-Draft will expire on March 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A number of proposals have been published to address the need of A number of proposals have been published to address the need of
securing media traffic. Different assumptions, requirements, and securing media traffic. A summary of the proposals available at that
usage environments justify every one of them. This document aims to time is available in the appendix of this document. Different
summarize the discussed media security requirements in order progress assumptions, requirements, and usage environments justify every one
the work on identifying a small subset applicable to a large range of of them. This document aims to summarize the discussed media
deployment environments. security requirements. A comparison of the requirements against the
individual proposals is provided.
This document is discussed on the RTPSEC mailing list, This document is discussed on the SIP mailing list,
http://www.imc.org/ietf-rtpsec. <http://www1.ietf.org/mailman/listinfo/sip>.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Discussion of Call Scenarios . . . . . . . . . . . . . . . . . 3 3. Call Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Clipping Media Before Signaling Answer . . . . . . . . . . 4 3.1. Clipping Media Before Signaling Answer . . . . . . . . . . 5
3.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 4 3.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 6
3.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 7 3.3. Shared Key Conferencing . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. B2BUA Signaling Manipulation . . . . . . . . . . . . . . . 10
5. Requirements Classification . . . . . . . . . . . . . . . . . 12 3.5. Policy and Media Gating Interactions . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Requirements Classification . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Appendix A. Overview of Keying Mechanisms . . . . . . . . . . . . 22
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 23
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 23
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 23
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 23
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 23
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 24
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 24
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 24
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 24
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 25
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 25
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 25
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 25
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 26
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 26
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 27
Appendix B. Evaluation Criteria - SIP . . . . . . . . . . . . . . 27
B.1. Secure Retargeting and Secure Forking . . . . . . . . . . 27
B.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 29
B.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 31
B.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix C. Evaluation Criteria - Security . . . . . . . . . . . 35
C.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 35
C.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 37
C.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 38
C.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 41
Appendix D. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
The work on media security started a long time ago where the The work on media security started a long time ago where the
capability of the Session Initiation Protocol (SIP) was still at its capability of the Session Initiation Protocol (SIP) was still at its
infancy. With the increased SIP deployment and the availability of infancy. With the increased SIP deployment and the availability of
new SIP extensions and related protocols the need for end-to-end new SIP extensions and related protocols the need for end-to-end
security was re-evaluated. The procedure of re-evaluating prior security was re-evaluated. The procedure of re-evaluating prior
protocol work and design decisions is not an uncommon strategy and, protocol work and design decisions is not an uncommon strategy and,
to some extend, considered necessary protocol work to ensure that the to some extend, considered necessary protocol work to ensure that the
developed protocols indeed meet the previously envisioned needs for developed protocols indeed meet the previously envisioned needs for
the users in the Internet. the users in the Internet.
This document aims to summarize the discussed media security This document aims to summarize the discussed media security
requirements, i.e., requirements for mechanisms that negotiate keys requirements, i.e., requirements for mechanisms that negotiate keys
for SRTP. Once the list of requirements and architectural aspects for SRTP. The organization of this document is as follows: Section 2
have been investigated, the work on the protocol proposals can be introduces terminology, Section 3 provides an overview about possible
progressed by identifying a small number of soltuions and to complete call scenarios, Section 4 lists requirements for media security,
the protocol work. Section 5 will provide a clustering of requirements to certain
deployment environments to address the problem that there might not
This document is organized as follows. Section 2 introduces be a single solution with universal applicability and Appendix D
terminology, Section 3 provides an overview about possible call provides out-of-scope items and aspects for further discussion. The
scenarios, Section 4 lists requirements for media security, Section 5 document concludes with a security considerations Section 6, IANA
will provide a clustering of requirements to certain deployment
environments to adress the problem that there might not be a single
solution with universal applicability and Appendix A provides out-of-
scope items and aspects for further discussion. The document
concludes with a security considerations Section 6, IANA
considerations Section 7 and an acknowledgement section in Section 8. considerations Section 7 and an acknowledgement section in Section 8.
Appendix A lists the available solution proposals and compares them
to the requirements.
2. Terminology 2. Terminology
The keywords "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,
(referred as ', not its implementation or application. not its implementation or application.
3. Discussion of Call Scenarios Additionally, the following items are used in this document:
The following subsections describe call scenarios, which have been AOR (Address-of-Record): A SIP or SIPS URI that points to a domain
discussed elaborately. These call scenarios pose the most challenge with a location service that can map the URI to another URI where
to the key management for media data in cooperation with SIP the user might be available. Typically, the location service is
signaling. The scenarios have already been described as part of the populated through registrations. An AOR is frequently thought of
key management evaluation draft [I-D.wing-rtpsec-keying-eval], and as the "public address" of the user.
are stated here to give a better insight in these discussion.
SSRC: The 32-bit value that defines the synchronization source,
used in RTP. These are generally unique, but collisions can
occur.
two-time pad: The use of the same key and the same key index to
encrypt different data. For SRTP, a two-time pad occurs if two
senders are using the same key and the same RTP SSRC value.
PKI Public Key Infrastructure. Throughout this paper, the term PKI
refers to a global PKI.
3. Call Scenarios
The following subsections describe call scenarios with relevance for
media security. These call scenarios pose the most challenge to the
key management for media data in cooperation with SIP signaling.
3.1. Clipping Media Before Signaling Answer 3.1. Clipping Media Before Signaling Answer
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
skipping to change at page 4, line 41 skipping to change at page 6, line 7
avoid the problem described in this section. avoid the problem 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. In this case a solution that makes the key media can be received. In this case a solution that makes the key
available before the SDP answer arrives will not help. available before the SDP answer arrives will not help.
Requirements are created due to early media, in the sense of pre- Requirements are created due to early media, in the sense of pre-
offer/answer media, as described in [I-D.barnes-sip-em-ps-req-sol]. offer/answer media, as described in [I-D.barnes-sip-em-ps-req-sol].
Fixes to early media might make the requirements to become obsolete. Fixes to early media might make the requirements to become obsolete,
but at the time of writing no progress has been accomplished.
3.2. Retargeting and Forking 3.2. Retargeting and Forking
In SIP, a request sent to a specific AOR but delivered to a different In SIP, a request sent to a specific AOR but delivered to a different
AOR is called a "retarget". A typical scenario is a "call AOR is called a "retarget". A typical scenario is a "call
forwarding" feature. In Figure 1 Alice sends an Invite in step 1 forwarding" feature. In Figure 1 Alice sends an Invite in step 1
that is sent to Bob in step 2. Bob responds with a redirect (SIP that is sent to Bob in step 2. Bob responds with a redirect (SIP
response code 3xx) pointing to Carol in step 3. This redirect response code 3xx) pointing to Carol in step 3. This redirect
typically does not propagate back to Alice but only goes to a proxy typically does not propagate back to Alice but only goes to a proxy
(i.e., the retargeting proxy) that sends the original Invite to Carol (i.e., the retargeting proxy) that sends the original Invite to Carol
skipping to change at page 5, line 31 skipping to change at page 6, line 47
Figure 1: Retargeting Figure 1: Retargeting
The mechanism used by SIP for identifying the calling party is SIP The mechanism used by SIP for identifying the calling party is SIP
Identity [RFC3261]. However, due to SIP retargeting issues Identity [RFC3261]. However, due to SIP retargeting issues
[I-D.peterson-sipping-retarget], SIP Identity can only identify the [I-D.peterson-sipping-retarget], SIP Identity can only identify the
calling party (that is, the party that initiated the SIP request). calling party (that is, the party that initiated the SIP request).
Some key exchange mechanisms predate SIP Identity and include their Some key exchange mechanisms predate SIP Identity and include their
own identity mechanism. However, those built-in identity mechanism own identity mechanism. However, those built-in identity mechanism
suffer from the same SIP retargeting problem described in the above suffer from the same SIP retargeting problem described in the above
draft. Going forward, it is anticipated that Connected Identity draft. Going forward, Connected Identity [RFC4916] allows
[I-D.ietf-sip-connected-identity] may allow identifying the called identifying the called party. This is also described as the
party. This is also described as the 'retargeting identity' problem. 'retargeting identity' problem.
In SIP, 'forking' is the delivery of a request to multiple locations. In SIP, 'forking' is the delivery of a request to multiple locations.
This happens when a single AOR is registered more than once. An This happens when a single AOR is registered more than once. An
example of forking is when a user has a desk phone, PC client, and example of forking is when a user has a desk phone, PC client, and
mobile handset all registered with the same AOR. mobile handset all registered with the same AOR.
+-----+ +-----+
|Alice| |Alice|
+--+--+ +--+--+
| |
| Invite | Invite
V V
skipping to change at page 8, line 45 skipping to change at page 10, line 9
mechanisms allow the transmitter to determine its own key, and others mechanisms allow the transmitter to determine its own key, and others
allow the offerer to determine the key for the offerer and answerer. allow the offerer to determine the key for the offerer and answerer.
Depending on how the call is established, the offerer might be a Depending on how the call is established, the offerer might be a
participant (such as a participant dialing into a conference bridge) participant (such as a participant dialing into a conference bridge)
or the offerer might be the mixer (such as a conference bridge or the offerer might be the mixer (such as a conference bridge
calling a participant). The use of offerless Invites may help some calling a participant). The use of offerless Invites may help some
keying mechanisms reverse the role of offerer/answerer. A keying mechanisms reverse the role of offerer/answerer. A
difficulty, however, is knowing a priori if the role should be difficulty, however, is knowing a priori if the role should be
reversed for a particular call. reversed for a particular call.
4. Requirements 3.4. B2BUA Signaling Manipulation
SRTP keying may be impacted due the presence of Back-to-Back User
Agents (B2BUA) in the signaling path. Not only does this potentially
impact the ability to exchange keying material as part of SIP
signaling, but because B2BUAs often limit the exchange of SDP, B2BUAs
can impact exchange of keying material in the media path as well.
Specifically, a number of scenarios can arise during initial call
setup that can interfere with exchanging SRTP keying material between
endpoints:
1. UAC indicated support for PRACK [RFC3262] is stripped from
signaling,
2. SDP from either endpoint is not exchanged on the same message
type or message sequence in which it was sent,
3. UAC reliability extensions, such as PRACK [RFC3262] and Security
Preconditions [I-D.ietf-mmusic-securityprecondition] are
terminated at the B2BUA itself instead of at the intended
recipient,
4. the B2BUA introduces new branches to the call flow (forking) to
network media endpoints
B2BUAs may strip support for PRACK from INVITEs in order to simplify
the types of signaling scenarios they must support when, usually,
trying to trigger network-provided early media. This impacts SRTP
keying by preventing the UAS from exchanging keying material in the
SDP answer until the next response can be sent. Even UPDATE cannot
be used to transport keying material due to limitations in [RFC3261]
requiring the answer to the offer in an INVITE being limited to a
reliable response.
Another not-uncommon manipulation of SIP call setup signaling is to
change the ordering in which SDP is exchanged. For example, a B2BUA
may hold onto SDP sent to it by a UAS as part of a 18x response or
UPDATE exchange and not forward that information back to the UAC
until some later point in time (typically the 200 OK to the INVITE).
This can delay key exchanges and cause clipping as a result.
A less common, but observed B2BUA tactic for handling signaling
interactions during call setup, primarily for network-provided early
media, is to "fake-out" the UAC into thinking that reliability
extensions such as PRACK [RFC3262] or Resource Management
Preconditions [RFC3312] are in effect end-to-end when they are not.
This manifests itself by sending provisional responses reliably from
the perspective of the B2BUA while stripping the extensions from
INVITEs sent to the callee's UAS. It is worth noting that such
behavior is likely to be applied to Security Preconditions
[I-D.ietf-mmusic-securityprecondition] as well for similar reasons.
Finally, B2BUAs may introduce early SIP dialogs to network-provided
early media services even though no forking occurs towards the
intended callee. The impact of forking of signaling requests is
described within section Section 3.2.
The impacts of these types of signaling manipulations by B2BUAs is
currently left as an OPEN ISSUE.
3.5. Policy and Media Gating Interactions
Another class of SRTP key exchange interactions that can occur is due
to policy policing and media stream gating mechanisms. These
functions are often performed by Session Border Controllers or by
firewalls. In the case of media stream gating, the flow of RTP
packets between endpoints is not authorized until a complete SDP
offer/answer exchange has taken place, commonly contingent upon the
200 OK to the INVITE being received by the network entity controlling
the media gates. As a result, in-band keying cannot start prior to
the flow of packets being authorized. If in-band keying is used it
may be possible to detect that the RTP packet in question is part of
a key exchange and not part of any data transfer process. However,
the firewalls responsible for gating media are typically not
inspecting the actual packets received, they are simply dropping them
on the floor until the gate is opened.
Policy policing, which is often related to media stream gating, can
also cause potential issues. For example, if elements such as a
deep-packet inspection element were not expecting in-band SRTP key
exchanges these packets may be suppressed according to local policy
for not conforming to expected traffic profiles (specifically, not
being an SRTP packet).
The impacts of these types of policy and gating related interactions
is currently left as an OPEN ISSUE.
4. Requirements
R1: Negotiation of SRTP keys MUST NOT cause the call setup to fail R1: Negotiation of SRTP keys MUST NOT cause the call setup to fail
in forked and retargeted calls where all end points are in forked and retargeted calls where all end points are
willing to use SRTP, unless the execution of the willing to use SRTP, unless the execution of the
authentication and key exchange protocol leads to a failure authentication and key exchange protocol leads to a failure
(e.g., an unsuccessful authentication attempt). (e.g., an unsuccessful authentication attempt).
R2: Even when some end points of a forked or retargeted call are R2: Even when some end points of a forked or retargeted call are
incapable of using SRTP, the key management protocol MUST incapable of using SRTP, the key management protocol MUST
allow the establishment of SRTP associations with SRTP-capable allow 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
skipping to change at page 9, line 36 skipping to change at page 12, line 41
because a phone call has not yet been established, ancillary because a phone call has not yet been established, ancillary
processing cycles can be utilized to perform the PK or DH processing cycles can be utilized to perform the PK or DH
operation; for example, in a PSTN gateway the DSP, which is operation; for example, in a PSTN gateway the DSP, which is
not yet involved with typical DSP operations, could be used to not yet involved with typical DSP operations, could be used to
perform the calculation, so as to avoid having the central perform the calculation, so as to avoid having the central
host processor perform the calculation. Some devices, such as host processor perform the calculation. Some devices, such as
handsets, and intelligent SIMs do not have such ancillary handsets, and intelligent SIMs do not have such ancillary
processing capability. processing capability.
R5: The media security key management protocol SHOULD avoid R5: The media security key management protocol SHOULD avoid
clipping media before SDP answer without requiring PRACK clipping media before SDP answer without requiring Security
[RFC3262]. Preconditions [I-D.ietf-mmusic-securityprecondition], as
Security Preconditions is not widely implemented and requires
significant signaling overhead.
R6: The media security key management protocol MUST provide R6: The media security key management protocol MUST provide
protection against passive attacks on the media path. protection against passive attacks on the media path.
R7: The media security key management protocol MUST provide R7: The media security key management protocol MUST provide
protection against passive attacks of a SIP proxy that is protection against passive attacks of a SIP proxy that is
legitimately routing SIP messages. legitimately routing SIP messages.
R8: The media security key management protocol MUST be able to R8: The media security key management protocol MUST be able to
support perfect forward secrecy (or PFS). The term PFS is the support perfect forward secrecy (PFS). The term PFS is the
property that disclosure of the long-term secret keying property that disclosure of the long-term secret keying
material that is used to derive an agreed ephemeral key does material that is used to derive an agreed ephemeral key does
not compromise the secrecy of agreed keys from earlier runs. not compromise the secrecy of agreed keys from earlier runs.
R9: The media security key management protocol MUST support R9: The media security key management protocol MUST support
negotiation of SRTP cipher suites without incurring per- negotiation of SRTP cipher suites without incurring per-
algorithm computational expense. This allows an offer to be algorithm computational expense. This allows an offer to be
built without incurring computational expense for each built without incurring computational expense for each
algorithm. algorithm.
skipping to change at page 10, line 47 skipping to change at page 14, line 8
this standard is available to private and commercial this standard is available to private and commercial
organizations."[cryptval] organizations."[cryptval]
Some commercial organizations, such as banks and defense Some commercial organizations, such as banks and defense
contractors, also require or prefer equipment which has contractors, also require or prefer equipment which has
validated by the FIPS-140 process. validated by the FIPS-140 process.
R14: The media security key management protocol SHOULD be able to R14: The media security key management protocol SHOULD be able to
associate the signaling exchange with the media traffic. associate the signaling exchange with the media traffic.
R15: 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 signed Diffie-Hellman key pairs. Calculating 20 DH secrets
and validating signatures can be a difficult task depending on and validating signatures can be a difficult task depending on
the device capabilities. Hence, in the case of forking, it is the device capabilities. Hence, in the case of forking, it is
not desirable to perform a DH or PK operation with every not desirable to perform a DH or PK operation with every
party, but rather only with the party that answers the call party, but rather only with the party that answers the call
(and incur some media clipping). To do this, the signaling (and incur some media clipping). To do this, the signaling
and media need to be associated so the calling party knows and media need to be associated so the calling party knows
which key management needs to be completed. This might be which key management needs to be completed. This might be
done by using the transport address indicated in the SDP, done by using the transport address indicated in the SDP,
although NATs can complicate this association. although NATs can complicate this association.
R14: The media security key management protocol SHOULD allow to Allowing such an association also allows the SDP offerer to
avoid performing CPU-consuming operations (e.g., DH or public
key operations) with attackers that have not seen the
signaling messages.
R15: The media security key management protocol SHOULD allow to
start with RTP and then upgrade to SRTP. start with RTP and then upgrade to SRTP.
R15: The media security key management protocol SHOULD NOT R16: The media security key management protocol SHOULD NOT
introduce new denial of service vulnerabilities. introduce new denial of service vulnerabilities.
R16: The media security key management protocol SHOULD require the R17: The media security key management protocol SHOULD require the
adversary to have access to the data as well as the signaling adversary to have access to the data as well as the signaling
path for a successful attack to be launched. An adversary path for a successful attack to be launched. An adversary
that is located only along the data or only along the that is located only along the data or only along the
signaling path MUST NOT be able to successfully mount an signaling path MUST NOT be able to successfully mount an
attack. A successful attack refers to the ability for the attack. A successful attack refers to the ability for the
adversary to obtain keying material to decrypt the SRTP adversary to obtain keying material to decrypt the SRTP
encrypted media traffic. encrypted media traffic.
R17: If two parties share an authentication infrastructure that has R18: If two parties share an authentication infrastructure that has
3rd parties signing certificates, they SHOULD be able to make 3rd parties signing certificates, they SHOULD be able to make
use of it. use of it.
R18: The media security key management protocol MUST provide R19: The media security key management protocol MUST provide
crypto-agility. crypto-agility.
R19: The media security key management protocol MUST protect cipher R20: The media security key management protocol MUST protect cipher
suite negotiation against downgrading attacks. suite negotiation against downgrading attacks.
R20: The media security key management protocol MUST allow a SIP R21: 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.
R21: The media security key management protocol SHOULD allow R22: The media security key management protocol SHOULD allow
establishing SRTP keying between different call signaling establishing SRTP keying between different call signaling
protocols (e.g., between Jabber, SIP, H.323, MGCP) protocols (e.g., between Jabber, SIP, H.323, MGCP)
R22: The media security key management protocol SHOULD support R23: The media security key management protocol SHOULD support
recording of decrypted media. recording of decrypted media.
Media recording may be realized by an intermediate nodes. An Media recording may be realized by an intermediate nodes. An
example for those intermediate nodes are devices, which could example for those intermediate nodes are devices, which could
be used in banking applications or for quality monitoring in be used in banking applications or for quality monitoring in
call centers. Here, it must be ensured, that the media call centers. Here, it must be ensured, that the media
security is ensured by the intermediate nodes on the security is ensured by the intermediate nodes on the
connections to the involved endpoints as originally connections to the involved endpoints as originally
negotiated. The endpoints need to be informed that there is negotiated. The endpoints need to be informed that there is
an intermediate device and need to cooperate. A solution an intermediate device and need to cooperate. A solution
approach for this is described in [I-D.wing-sipping-srtp-key]. approach for this is described in [I-D.wing-sipping-srtp-key].
R23: The media security key management protocol SHOULD NOT allow R24: The media security key management protocol SHOULD NOT allow
end users to determine whether their end-to-end interaction is end users to determine whether their end-to-end interaction is
subject to lawful interception. subject to lawful interception.
R24: The media security key management protocol MUST work when R25: The media security key management protocol MUST work when
there are intermediate nodes, terminating or processing media, there are intermediate nodes, terminating or processing media,
between the end points. between the end points.
R25: The media security key management protocol MUST consider R26: The media security key management protocol MUST consider
termination of media security in a PSTN gateway. termination of media security in a PSTN gateway.
A typical case of using media security is the one where two A typical case of using media security is the one where two
entities are having a VoIP conversation over IP capable entities are having a VoIP conversation over IP capable
networks. However, there are cases where the other end of the networks. However, there are cases where the other end of the
communication is not connected to an IP capable network. In communication is not connected to an IP capable network. In
this kind of setting, there needs to be some kind of gateway this kind of setting, there needs to be some kind of gateway
at the edge of the IP network which converts the VoIP at the edge of the IP network which converts the VoIP
conversation to format understood by the other network. An conversation to format understood by the other network. An
example of such gateway is a PSTN gateway sitting at the edge example of such gateway is a PSTN gateway sitting at the edge
skipping to change at page 13, line 49 skipping to change at page 17, line 20
Class III: Class III:
Active attack on the signaling and the data path necessary to Active attack on the signaling and the data path necessary to
reveal the content of the media traffic. reveal the content of the media traffic.
Class IV: Class IV:
Active attack is required and will be detected by the end points Active attack is required and will be detected by the end points
when adversary tampers with the messages. when adversary tampers with the messages.
For example, SDES falls into Class I since the adversary needs to For example, Security Descriptions falls into Class I since the
learn the SDES key by progressing a signaling message at a SIP proxy adversary needs to learn the Security Descriptions key by processing
(assuming that the adversary is in control of the SIP proxy). a signaling message at a SIP proxy (assuming that the adversary is in
Subsequent media traffic can be decrypted with the help of the control of the SIP proxy). Subsequent media traffic can be decrypted
learned key. with the help of the learned key.
As another example, DTLS-RTP falls into Class III when DTLS is used a As another example, DTLS-RTP falls into Class III when DTLS is used a
public key based ciphersuite with self-signed certificates and public key based ciphersuite with self-signed certificates and
without SIP Identity. An adversary would have to modify the without SIP Identity. An adversary would have to modify the
fingerprint that is sent along the signaling path and subsequently to fingerprint that is sent along the signaling path and subsequently to
modify the certificates carried in the DTLS handshake that travel modify the certificates carried in the DTLS handshake that travel
along the media path. along the media path.
An attack is not successful when SIP Identity is used, the adversary An attack is not successful when SIP Identity is used, the adversary
is not between the SIP UA and its Authentication Service (or at the is not between the SIP UA and its Authentication Service (or at the
skipping to change at page 14, line 33 skipping to change at page 18, line 7
This document lists requirements for securing media traffic. As This document lists requirements for securing media traffic. As
such, it addresses security throughout the document. such, it addresses security throughout the document.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the active participants of the RTPSEC The authors would like to thank the participants of the two RTPSEC
BoF and on the RTPSEC mailing list. The authors would furthermore BoFs and the members of the RTPSEC mailing list. Further thanks to
like to thank Wolfgang Buecker, Guenther Horn, Peter Howard, Hans- the following individuals for their specific suggestions which
Heinrich Grusdt, Srinath Thiruvengadam, Martin Euchner, Eric improved this document: Flemming Andreasen, Richard Barnes, Mark
Rescorla, Matt Lepinski, Dan York, Werner Dittmann, Richard Barnes, Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath Dondeti, John
Vesa Lehtovirta, Colin Perkins, Peter Schneider, and Christer Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer Holmberg,
Holmberg for their feedback to this document. We would like to Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic, Cullen
particularly thank Francois Audet for his work on the evaluation of Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David
various media security key exchange proposals. McGrew, David Oran, Colin Perkins, Eric Raymond, Peter Schneider,
Eric Rescorla, Srinath Thiruvengadam, Dave Ward, and Dan York.
Thanks also to Dragan Ignjatic (and our co-author, Steffen Fries) for
their excellent MIKEY modes [I-D.ietf-msec-mikey-applicability]
document, which formed the basis for the MIKEY comparisons.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-140-2] [FIPS-140-2]
NIST, "Security Requirements for Cryptographic Modules", NIST, "Security Requirements for Cryptographic Modules",
June 2005, <http://csrc.nist.gov/publications/fips/ June 2005, <http://csrc.nist.gov/publications/fips/
fips140-2/fips1402.pdf>. fips140-2/fips1402.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 15, line 27 skipping to change at page 18, line 47
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[cryptval] [cryptval]
NIST, "Cryptographic Module Validation Program", NIST, "Cryptographic Module Validation Program",
December 2006, December 2006,
<http://csrc.nist.gov/cryptval/140-2APP.htm>. <http://csrc.nist.gov/cryptval/140-2APP.htm>.
9.2. Informative References 9.2. Informative References
[I-D.barnes-sip-em-ps-req-sol] [I-D.barnes-sip-em-ps-req-sol]
Barnes, R. and M. Lepinski, "Early Media in SIP: Problem Barnes, R. and M. Lepinski, "Early Media in SIP: Problem
Statement, Requirements, and Analysis of Solutions", Statement, Requirements, and Analysis of Solutions",
draft-barnes-sip-em-ps-req-sol-00 (work in progress), draft-barnes-sip-em-ps-req-sol-00 (work in progress),
February 2007. February 2007.
[I-D.baugher-mmusic-sdp-dh]
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
in progress), February 2006.
[I-D.dondeti-msec-rtpsec-mikeyv2]
Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY,
revisited", draft-dondeti-msec-rtpsec-mikeyv2-01 (work in
progress), March 2007.
[I-D.fischl-sipping-media-dtls]
Fischl, J., "Datagram Transport Layer Security (DTLS)
Protocol for Protection of Media Traffic Established with
the Session Initiation Protocol",
draft-fischl-sipping-media-dtls-03 (work in progress),
July 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-18 (work in progress),
September 2007.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-06 (work in
progress), July 2007.
[I-D.ietf-mmusic-securityprecondition] [I-D.ietf-mmusic-securityprecondition]
Andreasen, F. and D. Wing, "Security Preconditions for Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams", Session Description Protocol (SDP) Media Streams",
draft-ietf-mmusic-securityprecondition-03 (work in draft-ietf-mmusic-securityprecondition-04 (work in
progress), October 2006. progress), July 2007.
[I-D.ietf-sip-connected-identity] [I-D.ietf-msec-mikey-applicability]
Elwell, J., "Connected Identity in the Session Initiation Fries, S. and D. Ignjatic, "On the applicability of
Protocol (SIP)", draft-ietf-sip-connected-identity-05 various MIKEY modes and extensions",
(work in progress), February 2007. draft-ietf-msec-mikey-applicability-06 (work in progress),
July 2007.
[I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress),
June 2007.
[I-D.ietf-sip-certs]
Jennings, C., "Certificate Management Service for The
Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-04 (work in progress), July 2007.
[I-D.jennings-sipping-multipart]
Wing, D. and C. Jennings, "Session Initiation Protocol
(SIP) Offer/Answer with Multipart Alternative",
draft-jennings-sipping-multipart-02 (work in progress),
March 2006.
[I-D.mahy-sipping-herfp-fix] [I-D.mahy-sipping-herfp-fix]
Mahy, R., "A Solution to the Heterogeneous Error Response Mahy, R., "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP) in the Session Initiation Forking Problem (HERFP) in the Session Initiation
Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in
progress), March 2006. progress), March 2006.
[I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
[I-D.mcgrew-tls-srtp]
Rescorla, E. and D. McGrew, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-mcgrew-tls-srtp-02 (work in progress), March 2007.
[I-D.peterson-sipping-retarget] [I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", Framework and Requirements",
draft-peterson-sipping-retarget-00 (work in progress), draft-peterson-sipping-retarget-00 (work in progress),
February 2005. February 2005.
[I-D.wing-rtpsec-keying-eval]
Audet, F. and D. Wing, "Evaluation of SRTP Keying with
SIP", draft-wing-rtpsec-keying-eval-02 (work in progress),
February 2007.
[I-D.wing-sipping-srtp-key] [I-D.wing-sipping-srtp-key]
Wing, D., "Disclosing Secure RTP (SRTP) Session Keys with Wing, D., "Disclosing Secure RTP (SRTP) Session Keys with
a SIP Event Package", draft-wing-sipping-srtp-key-00 (work a SIP Event Package", draft-wing-sipping-srtp-key-01 (work
in progress), February 2007. in progress), July 2007.
[I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
RTP", draft-zimmermann-avt-zrtp-04 (work in progress),
July 2007.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 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.
Appendix A. Out-of-Scope [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
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
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650,
September 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
Appendix A. Overview of Keying Mechanisms
Based on how the SRTP keys are exchanged, each SRTP key exchange
mechanism belongs to one general category:
signaling 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
path, and no signaling whatsoever is carried in the call
signaling path.
signaling and media path: Parts of the keying are carried in the
SRTP/SRTCP media path, and parts are carried in the call
signaling (SIP or SDP) path.
One of the significant benefits of SRTP over other end-to-end
encryption mechanisms, such as for example IPsec, is that SRTP is
bandwidth efficient and SRTP retains the header of RTP packets.
Bandwidth efficiency is vital for VoIP in many scenarios where access
bandwidth is limited or expensive, and retaining the RTP header is
important for troubleshooting packet loss, delay, and jitter.
Related to SRTP's characteristics is a goal that any SRTP keying
mechanism to also be efficient and not cause additional call setup
delay. Contributors to additional call setup delay include network
or database operations: retrieval of certificates and additional SIP
or media path messages, and computational overhead of establishing
keys or validating certificates.
When examining the choice between keying in the signaling path,
keying in the media path, or keying in both paths, it is important to
realize the media path is generally 'faster' than the SIP signaling
path. The SIP signaling path has computational elements involved
which parse and route SIP messages. The media path, on the other
hand, does not normally have computational elements involved, and
even when computational elements such as firewalls are involved, they
cause very little additional delay. Thus, the media path can be
useful for exchanging several messages to establish SRTP keys. A
disadvantage of keying over the media path is that interworking
different key exchange requires the interworking function be in the
media path, rather than just in the signaling path; in practice this
involvement is probably unavoidable anyway.
A.1. Signaling Path Keying Techniques
A.1.1. MIKEY-NULL
MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both
directions. The key is sent unencrypted in SDP, which means the SDP
must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-
end (e.g., by using S/MIME).
MIKEY-NULL requires one message from offerer to answerer (half a
round trip), and does not add additional media path messages.
A.1.2. MIKEY-PSK
MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints
share one common key. MIKEY-PSK has the offerer encrypt the SRTP
keys for both directions using this pre-shared key.
MIKEY-PSK requires one message from offerer to answerer (half a round
trip), and does not add additional media path messages.
A.1.3. MIKEY-RSA
MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both
directions using the intended answerer's public key, which is
obtained from a PKI.
MIKEY-RSA requires one message from offerer to answerer (half a round
trip), and does not add additional media path messages. MIKEY-RSA
requires the offerer to obtain the intended answerer's certificate.
A.1.4. MIKEY-RSA-R
MIKEY-RSA-R An additional mode of key distribution in MIKEY: MIKEY-
RSA-R [RFC4738] is essentially the same as MIKEY-RSA but reverses the
role of the offerer and the answerer with regards to providing the
keys. That is, the answerer encrypts the keys for both directions
using the offerer's public key. Both the offerer and answerer
validate each other's public keys using a PKI. MIKEY-RSA-R also
enables sending certificates in the MIKEY message.
MIKEY-RSA-R requires one message from offerer to answer, and one
message from answerer to offerer (full round trip), and does not add
additional media path messages. MIKEY-RSA-R requires the offerer
validate the answerer's certificate.
A.1.5. MIKEY-DHSIGN
In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key
from a Diffie-Hellman exchange. In order to prevent an active man-
in-the-middle the DH exchange itself is signed using each endpoint's
private key and the associated public keys are validated using a PKI.
MIKEY-DHSIGN requires one message from offerer to answerer, and one
message from answerer to offerer (full round trip), and does not add
additional media path messages. MIKEY-DHSIGN requires the offerer
and answerer to validate each other's certificates. MIKEY-DHSIGN
also enables sending the answerer's certificate in the MIKEY message.
A.1.6. MIKEY-DHHMAC
MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-
Hellman exchange, essentially combining aspects of MIKEY-PSK with
MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a PKI to
authenticate the Diffie-Hellman exchange.
MIKEY-DHHMAC requires one message from offerer to answerer, and one
message from answerer to offerer (full round trip), and does not add
additional media path messages.
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)
ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC
can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY-
DHSIGN (using a new DH-Group code), and also defines two new ECC-
based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES)
and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) .
For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and
MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group
code function exactly like MIKEY-DHSIGN. Therefore these ECC
mechanisms aren't discussed separately in this paper.
A.1.8. Security Descriptions with SIPS
Security Descriptions [RFC4568] has each side indicate the key it
will use for transmitting SRTP media, and the keys are sent in the
clear in SDP. Security Descriptions relies on hop-by-hop (TLS via
"SIPS:") encryption to protect the keys exchanged in signaling.
Security Descriptions requires one message from offerer to answerer,
and one message from answerer to offerer (full round trip), and does
not add additional media path messages.
A.1.9. Security Descriptions with S/MIME
This keying mechanism is identical to Appendix A.1.8, except that
rather than protecting the signaling with TLS, the entire SDP is
encrypted with S/MIME.
A.1.10. SDP-DH (expired)
SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie-
Hellman messages in the signaling path to establish session keys. To
protect against active man-in-the-middle attacks, the Diffie-Hellman
exchange needs to be protected with S/MIME, SIPS, or SIP-Identity
[RFC4474] and [RFC4474].
SDP-DH requires one message from offerer to answerer, and one message
from answerer to offerer (full round trip), and does not add
additional media path messages.
A.1.11. MIKEYv2 in SDP (expired)
MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to
MIKEYv1 and removes the time synchronization requirement. It
therefore now takes 2 round-trips to complete. In the first round
trip, the communicating parties learn each other's identities, agree
on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces
for replay protection. In the second round trip, they negotiate
unicast and/or group SRTP context for SRTP and/or SRTCP.
Furthemore, MIKEYv2 also defines an in-band negotiation mode as an
alternative to SDP (see Appendix A.3.3).
A.2. Media Path Keying Technique
A.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the
signaling path (although it's possible for endpoints to indicate
support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the
keys are exchanged entirely in the media path using a Diffie-Hellman
exchange. The advantage to this mechanism is that the signaling
channel is used only for call setup and the media channel is used to
establish an encrypted channel -- much like encryption devices on the
PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
by having each person read digits to the other person. Subsequent
sessions with the same ZRTP endpoint can be authenticated using the
stored hash of the previously negotiated key rather than voice
authentication.
ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2)
to establish the SRTP key, and 3 media path confirmation messages.
The first 4 are sent as RTP packets (using RTP header extensions),
and the last 3 are sent in conjunction with SRTP media packets (again
as SRTP header extensions). Note that unencrypted RTP is being
exchanged until the SRTP keys are established.
A.3. Signaling and Media Path Keying Techniques
A.3.1. EKT
EKT [I-D.mcgrew-srtp-ekt] relies on another SRTP key exchange
protocol, such as Security Descriptions or MIKEY, for bootstrapping.
In the initial phase, each member of a conference uses an SRTP key
exchange protocol to establish a common key encryption key (KEK).
Each member may use the KEK to securely transport its SRTP master key
and current SRTP rollover counter (ROC), via RTCP, to the other
participants in the session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP
message which contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent.
A.3.2. DTLS-SRTP
DTLS-SRTP [I-D.mcgrew-tls-srtp] exchanges public key fingerprints in
SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS
session over the media channel. The endpoints use the DTLS handshake
to agree on crypto suites and establish SRTP session keys. SRTP
packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round
trip), and, if the offerer wishes to correlate the SDP answer with
the endpoint, requires one message from answer to offerer (full round
trip). DTLS-SRTP uses 4 media path messages to establish the SRTP
key.
This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its
cipher suite, which is the mandatory-to-implement cipher suite in TLS
[RFC4346].
A.3.3. MIKEYv2 Inband (expired)
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band
negotiation mode as an alternative to SDP (see Appendix A.3.3). The
details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.).
Appendix B. Evaluation Criteria - SIP
This section considers how each keying mechanism interacts with SIP
features.
B.1. Secure Retargeting and Secure Forking
Retargeting and forking of signaling requests is described within
section Section 3.2. The following builds upon this description.
The following list compares the behavior of secure forking, answering
association, two-time pads, and secure retargeting for each keying
mechanism.
MIKEY-NULL Secure Forking: No, all AORs see offerer's and
answerer's keys. Answer is associated with media by the SSRC
in MIKEY. Additionally, a two-time pad occurs if two branches
choose the same 32-bit SSRC and transmit SRTP packets.
Secure Retargeting: No, all targets see offerer's and
answerer's keys. Suffers from retargeting identity problem.
MIKEY-PSK
Secure Forking: No, all AORs see offerer's and answerer's keys.
Answer is associated with media by the SSRC in MIKEY. Note
that all AORs must share the same pre-shared key in order for
forking to work at all with MIKEY-PSK. Additionally, a two-
time pad occurs if two branches choose the same 32-bit SSRC and
transmit SRTP packets.
Secure Retargeting: Not secure. For retargeting to work, the
final target must possess the correct PSK. As this is likely
in scenarios were the call is targeted to another device
belonging to the same user (forking), it is very unlikely that
other users will possess that PSK and be able to successfully
answer that call.
MIKEY-RSA
Secure Forking: No, all AORs see offerer's and answerer's keys.
Answer is associated with media by the SSRC in MIKEY. Note
that all AORs must share the same private key in order for
forking to work at all with MIKEY-RSA. Additionally, a two-
time pad occurs if two branches choose the same 32-bit SSRC and
transmit SRTP packets.
Secure Retargeting: No.
MIKEY-RSA-R
Secure Forking: Yes. Answer is associated with media by the
SSRC in MIKEY.
Secure Retargeting: Yes.
MIKEY-DHSIGN
Secure Forking: Yes, each forked endpoint negotiates unique
keys with the offerer for both directions. Answer is
associated with media by the SSRC in MIKEY.
Secure Retargeting: Yes, each target negotiates unique keys
with the offerer for both directions.
MIKEYv2 in SDP
The behavior will depend on which mode is picked.
MIKEY-DHHMAC
Secure Forking: Yes, each forked endpoint negotiates unique
keys with the offerer for both directions. Answer is
associated with media by the SSRC in MIKEY.
Secure Retargeting: Yes, each target negotiates unique keys
with the offerer for both directions. Note that for the keys
to be meaningful, it would require the PSK to be the same for
all the potential intermediaries, which would only happen
within a single domain.
Security Descriptions with SIPS
Secure Forking: No. Each forked endpoint sees the offerer's
key. Answer is not associated with media.
Secure Retargeting: No. Each target sees the offerer's key.
Security Descriptions with S/MIME
Secure Forking: No. Each forked endpoint sees the offerer's
key. Answer is not associated with media.
Secure Retargeting: No. Each target sees the offerer's key.
Suffers from retargeting identity problem.
SDP-DH
Secure Forking: Yes. Each forked endpoint calculates a unique
SRTP key. Answer is not associated with media.
Secure Retargeting: Yes. The final target calculates a unique
SRTP key.
ZRTP
Secure Forking: Yes. Each forked endpoint calculates a unique
SRTP key. As ZRTP isn't signaled in SDP, there is no
association of the answer with media.
Secure Retargeting: Yes. The final target calculates a unique
SRTP key.
EKT
Secure Forking: Inherited from the bootstrapping mechanism (the
specific MIKEY mode or Security Descriptions). Answer is
associated with media by the SPI in the EKT protocol. Answer
is associated with media by the SPI in the EKT protocol.
Secure Retargeting: Inherited from the bootstrapping mechanism
(the specific MIKEY mode or Security Descriptions).
DTLS-SRTP
Secure Forking: Yes. Each forked endpoint calculates a unique
SRTP key. Answer is associated with media by the certificate
fingerprint in signaling and certificate in the media path.
Secure Retargeting: Yes. The final target calculates a unique
SRTP key.
MIKEYv2 Inband
The behavior will depend on which mode is picked.
B.2. Clipping Media Before SDP Answer
Clipping media before receiving the signaling answer is described
within section Section 3.1. The following builds upon this
description.
Furthermore, the problem of clipping gets compounded when forking is
used. For example, if using a Diffie-Hellman keying technique with
security preconditions that forks to 20 endpoints, the call initiator
would get 20 provisional responses containing 20 signed Diffie-
Hellman half keys. Calculating 20 DH secrets and validating
signatures can be a difficult task depending on the device
capabilities.
The following list compares the behavior of clipping before SDP
answer for each keying mechanism.
MIKEY-NULL
Not clipped. The offerer provides the answerer's keys.
MIKEY-PSK
Not clipped. The offerer provides the answerer's keys.
MIKEY-RSA
Not clipped. The offerer provides the answerer's keys.
MIKEY-RSA-R
Clipped. The answer contains the answerer's encryption key.
MIKEY-DHSIGN
Clipped. The answer contains the answerer's Diffie-Hellman
response.
MIKEY-DHHMAC
Clipped. The answer contains the answerer's Diffie-Hellman
response.
MIKEYv2 in SDP
The behavior will depend on which mode is picked.
Security Descriptions with SIPS
Clipped. The answer contains the answerer's encryption key.
Security Descriptions with S/MIME
Clipped. The answer contains the answerer's encryption key.
SDP-DH
Clipped. The answer contains the answerer's Diffie-Hellman
response.
ZRTP
Not clipped because the session intially uses RTP. While RTP
is flowing, both ends negotiate SRTP keys in the media path and
then switch to using SRTP.
EKT
Not clipped, as long as the first RTCP packet (containing the
answerer's key) is not lost in transit. The answerer sends its
encryption key in RTCP, which arrives at the same time (or
before) the first SRTP packet encrypted with that key.
Note: RTCP needs to work, in the answerer-to-offerer
direction, before the offerer can decrypt SRTP media.
DTLS-SRTP
Not clipped. Keys are exchanged in the media path without
relying on the signaling path.
MIKEYv2 Inband
Not clipped. Keys are exchanged in the media path without
relying on the signaling path.
B.3. Centralized Keying
Centralized keying is described within section Section 3.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.
B.4. SSRC and ROC
In SRTP, a cryptographic context is defined as the SSRC, destination
network address, and destination transport port number. Whereas RTP,
a flow is defined as the destination network address and destination
transport port number. This results in a problem -- how to
communicate the SSRC so that the SSRC can be used for the
cryptographic context.
Two approaches have emerged for this communication. One, used by all
MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY
exchange. Another, used by Security Descriptions, is to use "late
bindng" -- that is, any new packet containing a previously-unseen
SSRC (which arrives at the same destination network address and
destination transport port number) will create a new cryptographic
context. Another approach, common amongst techniques with media-path
SRTP key establishment, is to require a handshake over that media
path before SRTP packets are sent. MIKEY's approach changes RTP's
SSRC collision detection behavior by requiring RTP to pre-establish
the SSRC values for each session.
Another related issue is that SRTP introduces a rollover counter
(ROC), which records how many times the SRTP sequence number has
rolled over. As the sequence number is used for SRTP's default
ciphers, it is important that all endpoints know the value of the
ROC. The ROC starts at 0 at the beginning of a session.
Some keying mechanisms cause a two-time pad to occur if two endpoints
of a forked call have an SSRC collision.
Note: A proposal has been made to send the ROC value on every Nth
SRTP packet[RFC4771]. This proposal has not yet been incorporated
into this document.
The following list examines handling of SSRC and ROC:
MIKEY-NULL
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
MIKEY-PSK
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
MIKEY-RSA
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
MIKEY-RSA-R
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
MIKEY-DHSIGN
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
MIKEY-DHHMAC
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
MIKEYv2 in SDP
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
Security Descriptions with SIPS
Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used.
Security Descriptions with S/MIME
Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used.
SDP-DH
Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used.
ZRTP
Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used.
EKT
The SSRC of the SRTCP packet containing an EKT update
corresponds to the SRTP master key and other parameters within
that packet.
DTLS-SRTP
Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used.
MIKEYv2 Inband
Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits.
Appendix C. Evaluation Criteria - Security
This section evaluates each keying mechanism on the basis of their
security properties.
C.1. Public Key Infrastructure
There are two aspects of PKI requirements -- one aspect is if PKI is
necessary in order for the mechanism to function at all, the other is
if PKI is used to authenticate a certificate. With interactive
communications it is desirable to avoid fetching certificates that
delay call setup; rather it is preferable to fetch or validate
certificates in such a way that call setup isn't delayed. For
example, a certificate can be validated while the phone is ringing or
can be validated while ring-back tones are being played or even while
the called party is answering the phone and saying "hello".
SRTP key exchange mechanisms that require a global PKI to operate are
gated on the deployment of a common PKI available to both endpoints.
This means that no media security is achievable until such a PKI
exists. For SIP, something like sip-certs [I-D.ietf-sip-certs] might
be used to obtain the certificate of a peer.
Note: Even if SIP CERTs was deployed, the retargeting problem
(Appendix B.1) would still prevent successful deployment of keying
techniques which require the offerer to obtain the actual target's
public key.
The following list compares the PKI requirements of each keying
mechanism, both if a PKI is required for the key exchange itself, and
if PKI is only used to authenticate the certificate supplied in
signaling.
MIKEY-NULL
PKI not used.
MIKEY-PSK
PKI not used; rather, all endpoints must have some way to
exchange per-endpoint or per-system pre-shared keys.
MIKEY-RSA
The offerer obtains the intended answerer's public key before
initiating the call. This public key is used to encrypt the
SRTP keys. There is no defined mechanism for the offerer to
obtain the answerer's public key, although [I-D.ietf-sip-certs]
might be viable in the future.
MIKEY-RSA-R
The offer contains the offerer's public key. The answerer uses
that public key to encrypt the SRTP keys that will be used by
the offerer and the answerer. A PKI is necessary to validate
the certificates.
MIKEY-DHSIGN
PKI is used to authenticate the public key that is included in
the MIKEY message, by walking the CA trust chain.
MIKEY-DHHMAC
PKI not used; rather, all endpoints must have some way to
exchange per-endpoint or per-system pre-shared keys.
MIKEYv2 in SDP
The behavior will depend on which mode is picked.
Security Descriptions with SIPS
PKI not used.
Security Descriptions with S/MIME
PKI is needed for S/MIME. The offerer must obtain the intended
target's public key and encrypt their SDP with that key. The
answerer must obtain the offerer's public key and encrypt their
SDP with that key.
SDP-DH
PKI not used.
ZRTP
PKI not used.
EKT
PKI not used by EKT itself, but might be used by the EKT
bootstrapping keying mechanism (such as certain MIKEY modes).
DTLS-SRTP
Remote party's certificate is sent in media path, and a
fingerprint of the same certificate is sent in the signaling
path.
MIKEYv2 Inband
The behavior will depend on which mode is picked.
C.2. Perfect Forward Secrecy
In the context of SRTP, Perfect Forward Secrecy is the property that
SRTP session keys that protected a previous session are not
compromised if the static keys belonging to the endpoints are
compromised. That is, if someone were to record your encrypted
session content and later acquires either party's private key, that
encrypted session content would be safe from decryption if your key
exchange mechanism had perfect forward secrecy.
The following list describes how each key exchange mechanism provides
PFS.
MIKEY-NULL
No PFS.
MIKEY-PSK
No PFS.
MIKEY-RSA
No PFS.
MIKEY-RSA-R
No PFS.
MIKEY-DHSIGN
PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHHMAC
PFS is provided with the Diffie-Hellman exchange.
MIKEYv2 in SDP
The behavior will depend on which mode is picked.
Security Descriptions with SIPS
No PFS.
Security Descriptions with S/MIME
No PFS.
SDP-DH
PFS is provided with the Diffie-Hellman exchange.
ZRTP
PFS is provided with the Diffie-Hellman exchange.
EKT
No PFS.
DTLS-SRTP
PFS is achieved if the negotiated cipher suite includes an
exponential or discrete-logarithmic key exchange (such as
Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]).
MIKEYv2 Inband
The behavior will depend on which mode is picked.
C.3. Best Effort Encryption
Note: With the ongoing efforts in SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions
reached in this section may no longer be accurate.
With best effort encryption, SRTP is used with endpoints that support
SRTP, otherwise RTP is used.
SIP needs a backwards-compatible best effort encryption in order for
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
support SRTP.
Consider the case of Bob, with a phone that only does RTP and a
voice mail system that supports SRTP and RTP. If Alice calls Bob
with an SRTP offer, Bob's RTP-only phone will reject the media
stream (with an empty "m=" line) because Bob's phone doesn't
understand SRTP (RTP/SAVP). Alice's phone will see this rejected
media stream and may terminate the entire call (BYE) and re-
initiate the call as RTP-only, or Alice's phone may decide to
continue with call setup with the SRTP-capable leg (the voice mail
system). If Alice's phone decided to re-initiate the call as RTP-
only, and Bob doesn't answer his phone, Alice will then leave
voice mail using only RTP, rather than SRTP as expected.
Currently, several techniques are commonly considered as candidates
to provide opportunistic encryption:
multipart/alternative
[I-D.jennings-sipping-multipart] describes how to form a
multipart/alternative body part in SIP. The significant issues
with this technique are (1) that multipart MIME is incompatible
with existing SIP proxies, firewalls, Session Border Controllers,
and endpoints and (2) when forking, the Heterogeneous Error
Response Forking Problem (HERFP) [I-D.mahy-sipping-herfp-fix]
causes problems if such non-multipart-capable endpoints were
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
With this technique, the endpoints signal their desire to do SRTP
by signaling RTP (RTP/AVP), and using an attribute ("a=") in the
SDP. This technique is entirely backwards compatible with non-
SRTP-aware endpoints, but doesn't use the RTP/SAVP protocol
registered by SRTP [RFC3711].
Probing
With this technique, the endpoints first establish an RTP session
using RTP (RTP/AVP). The endpoints send probe messages, over the
media path, to determine if the remote endpoint supports their
keying technique.
The following list compares the availability of best effort
encryption for each keying mechanism.
MIKEY-NULL
No best effort encryption.
MIKEY-PSK
No best effort encryption.
MIKEY-RSA
No best effort encryption.
MIKEY-RSA-R
No best effort encryption.
MIKEY-DHSIGN
No best effort encryption.
MIKEY-DHHMAC
No best effort encryption.
MIKEYv2 in SDP
No best effort encryption.
Security Descriptions with SIPS
No best effort encryption.
Security Descriptions with S/MIME
No best effort encryption.
SDP-DH
No best effort encryption.
ZRTP
Best effort encryption is done by probing (sending RTP messages
with header extensions) or by session attribute (see "a=zrtp",
defined in section 10 of [I-D.zimmermann-avt-zrtp]). Current
implementations of ZRTP use probing.
EKT
No best effort encryption.
DTLS-SRTP
No best effort encryption.
MIKEY Inband
No best effort encryption.
C.4. Upgrading Algorithms
It is necessary to allow upgrading SRTP encryption and hash
algorithms, as well as upgrading the cryptographic functions used for
the key exchange mechanism. With SIP's offer/answer model, this can
be computionally expensive because the offer needs to contain all
combinations of the key exchange mechanisms (all MIKEY modes,
Security Descriptions) and all SRTP cryptographic suites (AES-128,
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
expend CPU resources to build an offer containing all of this
information which becomes computationally prohibitive.
Thus, it is important to keep the offerer's CPU impact fixed so that
offering multiple new SRTP encryption and hash functions incurs no
additional expense.
The following list describes the CPU effort involved in using each
key exchange technique.
MIKEY-NULL
No significant computaional expense.
MIKEY-PSK
No significant computational expense.
MIKEY-RSA
For each offered SRTP crypto suite, the offerer has to perform
RSA operation to encrypt the TGK
MIKEY-RSA-R
For each offered SRTP crypto suite, the offerer has to perform
public key operation to sign the MIKEY message.
MIKEY-DHSIGN
For each offered SRTP crypto suite, the offerer has to perform
Diffie-Hellman operation, and a public key operation to sign
the Diffie-Hellman output.
MIKEY-DHHMAC
For each offered SRTP crypto suite, the offerer has to perform
Diffie-Hellman operation.
MIKEYv2 in SDP
The behavior will depend on which mode is picked.
Security Descriptions with SIPS
No significant computational expense.
Security Descriptions with S/MIME
S/MIME requires the offerer and the answerer to encrypt the SDP
with the other's public key, and to decrypt the received SDP
with their own private key.
SDP-DH
For each offered SRTP crypto suite, the offerer has to perform
a Diffie-Hellman operation.
ZRTP
The offerer has no additional computational expense at all, as
the offer contains no information about ZRTP or might contain
"a=zrtp".
EKT
The offerer's Computational expense depends entirely on the EKT
bootstrapping mechanism selected (one or more MIKEY modes or
Security Descriptions).
DTLS-SRTP
The offerer has no additional computational expense at all, as
the offer contains only a fingerprint of the certificate that
will be presented in the DTLS exchange.
MIKEYv2 Inband
The behavior will depend on which mode is picked.
Appendix D. Out-of-Scope
Discussions concluded that key management for shared-key encryption Discussions concluded that key management for shared-key encryption
of conferencing is outside the scope of this document. As the of conferencing is outside the scope of this document. As the
priority is point-to-point unicast SRTP session keying, resolving priority is point-to-point unicast SRTP session keying, resolving
shared-key SRTP session keying is deferred to later and left as an shared-key SRTP session keying is deferred to later and left as an
item for future investigations. item for future investigations.
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
skipping to change at page 18, line 5 skipping to change at page 43, line 32
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.com
Francois Audet
Nortel
4655 Great America Parkway
Santa Clara, CA 95054
USA
Email: audet@nortel.com
Brian Stucker
Nortel
2201 Lakeside
Richardson, TX 75082
USA
Email: bstucker@nortel.com
URI: http://www.linkedin.com/pub/bstucker
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 47 change blocks. 
103 lines changed or deleted 1313 lines changed or added

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