draft-ietf-sip-media-security-requirements-03.txt   draft-ietf-sip-media-security-requirements-04.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: August 27, 2008 Siemens AG Expires: September 21, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
February 24, 2008 March 20, 2008
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-03 draft-ietf-sip-media-security-requirements-04
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 August 27, 2008. This Internet-Draft will expire on September 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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. Shared Key Conferencing . . . . . . . . . . . . . . . . . 11
4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Recording . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Call Setup Performance . . . . . . . . . . . . . . . . . . 14 4.6. Call Setup Performance . . . . . . . . . . . . . . . . . . 14
4.7. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 15
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15 5.1. Key Management Protocol Requirements . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Overview and Evaluation of Existing Keying Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24 Mechanisms . . . . . . . . . . . . . . . . . . . . . 25
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 24 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 26
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 26
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 26
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 26
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 26 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 26
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 27
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 27
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 27
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 27 A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 27
A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 27 A.1.9. Security Descriptions with S/MIME . . . . . . . . . . 28
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 27 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 28
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 27 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 28
A.1.12. Evaluation Criteria - SIP . . . . . . . . . . . . . . 28 A.1.12. Evaluation Criteria - SIP . . . . . . . . . . . . . . 28
A.1.13. Evaluation Criteria - Security . . . . . . . . . . . . 36 A.1.13. Evaluation Criteria - Security . . . . . . . . . . . . 37
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 43 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 44
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 43 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 43 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 44
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 43 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 44 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 45
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 44 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 45
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 44 Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 45
Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44 Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . . . . 49
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 8, line 44 skipping to change at page 8, line 44
across all SIP proxies, implement Security Preconditions [RFC5027], across all SIP proxies, implement Security Preconditions [RFC5027],
or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer or the both ends implement ICE [I-D.ietf-mmusic-ice] and the answerer
implements the reliable provisional response mechanism described in implements the reliable provisional response mechanism described in
ICE. Unfortunately, there is not wide deployment of any of these ICE. Unfortunately, there is not wide deployment of any of these
techniques and there is industry reluctance to require these techniques and there is industry reluctance to require these
techniques to avoid the problems described in this section. techniques to avoid the problems described in this section.
Note that the receipt of an SDP answer is not always sufficient to Note that the receipt of an SDP answer is not always sufficient to
allow media to be played to the offerer. Sometimes, the offerer must allow media to be played to the offerer. Sometimes, the offerer must
send media in order to open up firewall holes or NAT bindings before send media in order to open up firewall holes or NAT bindings before
media can be received. In this case, even a solution that makes the media can be received (for details see
key available before the SDP answer arrives will not help. [I-D.ietf-mmusic-media-path-middleboxes]). In this case, even a
solution that makes the key available before the SDP answer arrives
will not help.
Fixes to early media (i.e., the media that arrives at the SDP offerer Fixes to early media (i.e., the media that arrives at the SDP offerer
before the SDP answer arrives) might make the requirements to become before the SDP answer arrives) might make the requirements to become
obsolete, but at the time of writing no progress has been obsolete, but at the time of writing no progress has been
accomplished. accomplished.
4.2. Retargeting and Forking 4.2. Retargeting and Forking
The discussion in this section relates to requirements R-FORK- The discussion in this section relates to requirements R-FORK-
RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE. RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
same (multi-unicast) RTP session same (multi-unicast) RTP session
If there are multiple inbound sessions and multiple outbound sessions If there are multiple inbound sessions and multiple outbound sessions
(scenarios a and b), then every keying mechanism behaves as if the (scenarios a and b), then every keying mechanism behaves as if the
mixer were an end point and can set up a point-to-point secure mixer were an end point and can set up a point-to-point secure
session between the participant and the mixer. This is the simplest session between the participant and the mixer. This is the simplest
situation, but is computationally wasteful, since SRTP processing has situation, but is computationally wasteful, since SRTP processing has
to be done independently for each participant. The use of multiple to be done independently for each participant. The use of multiple
inbound sessions (scenario a) doesn't waste computational resources, inbound sessions (scenario a) doesn't waste computational resources,
though it does consume additional cryptographic context on the mixer though it does consume additional cryptographic context on the mixer
for each participant and has the advantage of non-repudiation of the for each participant and has the advantage of data origin
originator of the incoming stream. authentication.
To support a single outbound session (scenario d), the mixer has to To support a single outbound session (scenario d), the mixer has to
dictate its encryption key to the participants. Some keying dictate its encryption key to the participants. Some keying
mechanisms allow the transmitter to determine its own key, and others mechanisms allow the transmitter to determine its own key, and others
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. 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.4. 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
skipping to change at page 15, line 23 skipping to change at page 15, line 29
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
The discussion in this section relates to the requirement R-ALLOW-
RTP.
Legitimate RTP media can be sent to an endpoint for announcements,
colorful ringback tones (e.g., music), advertising, or normal call
progress tones. The RTP may be received before an associated SDP
answer. For details on various scenarios, see
[I-D.stucker-sipping-early-media-coping].
While receiving such RTP exposes the calling party to a risk of
receiving malicious RTP from an attacker, SRTP endpoints will need to
receive and play out RTP media in order to be compatible with
deployed systems that send RTP to calling parties.
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 19, line 7 skipping to change at page 19, line 29
R-SIG-MEDIA: R-SIG-MEDIA:
The media security key management protocol MUST have a mode in The media security key management protocol MUST have a mode in
which it defends itself from an attacker that is solely on the which it defends itself from an attacker that is solely on the
media path and from an attacker that is solely on the signaling media path and from an attacker that is solely on the signaling
path. A successful attack refers to the ability for the path. A successful attack refers to the ability for the
adversary to obtain keying material to decrypt the SRTP adversary to obtain keying material to decrypt the SRTP
encrypted media traffic. encrypted media traffic.
R-ID-BINDING: R-ID-BINDING:
The media security key management protocol MUST use identifiers The media security key management protocol MUST enable the
for endpoints that allow a domain to create signatures over media security keys to be cryptographically bound to an
those identifiers and the From address. identity of the endpoint.
This allows domains to deploy SIP Identity [RFC4474]. This allows domains to deploy SIP Identity [RFC4474].
R-ACT-ACT: R-ACT-ACT:
The media security key management protocol MUST support a mode The media security key management protocol MUST support a mode
of operation that provides active-signaling-active-media-detect of operation that provides active-signaling-active-media-detect
robustness, and MAY support modes of operation that provide robustness, and MAY support modes of operation that provide
lower levels of robustness (as described in Section 3). lower levels of robustness (as described in Section 3).
Failing to meet R-ACT-ACT indicates the protocol can not Failing to meet R-ACT-ACT indicates the protocol can not
skipping to change at page 20, line 5 skipping to change at page 20, line 26
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.4.
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
to be received by the calling party until SRTP has been
negotiated with the answerer, after which SRTP is preferred
over RTP.
6. Security Considerations 6. Security Considerations
This document lists requirements for securing media traffic. As This document lists requirements for securing media traffic. As
such, it addresses security throughout the document. such, it addresses security throughout the document.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 21, line 48 skipping to change at page 22, line 28
Fischl, J., "Datagram Transport Layer Security (DTLS) Fischl, J., "Datagram Transport Layer Security (DTLS)
Protocol for Protection of Media Traffic Established with Protocol for Protection of Media Traffic Established with
the Session Initiation Protocol", the Session Initiation Protocol",
draft-fischl-sipping-media-dtls-03 (work in progress), draft-fischl-sipping-media-dtls-03 (work in progress),
July 2007. July 2007.
[I-D.ietf-avt-dtls-srtp] [I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-01 (work in progress), draft-ietf-avt-dtls-srtp-02 (work in progress),
November 2007. February 2008.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-media-path-middleboxes] [I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along Interactions for Signaling Protocol Communication along
skipping to change at page 23, line 6 skipping to change at page 23, line 33
[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] [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]
Stucker, B., "Coping with Early Media in the Session
Initiation Protocol (SIP)",
draft-stucker-sipping-early-media-coping-03 (work in
progress), October 2006.
[I-D.wing-sipping-srtp-key] [I-D.wing-sipping-srtp-key]
Wing, D., Audet, F., Fries, S., and H. Tschofenig, Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
"Disclosing Secure RTP (SRTP) Session Keys with a SIP Johnston, "Secure Media Recording and Transcoding with the
Event Package", draft-wing-sipping-srtp-key-02 (work in Session Initiation Protocol",
progress), November 2007. draft-wing-sipping-srtp-key-03 (work in progress),
February 2008.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
RTP", draft-zimmermann-avt-zrtp-04 (work in progress), Path Key Agreement for Secure RTP",
July 2007. draft-zimmermann-avt-zrtp-06 (work in progress),
March 2008.
[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. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 24, line 29 skipping to change at page 25, line 15
[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:
A.1. Signaling Path Keying Techniques
signaling path: All the keying is carried in the call signaling signaling path: All the keying is carried in the call signaling
(SIP or SDP) path. (SIP or SDP) path.
media path: All the keying is carried in the SRTP/SRTCP media media path: All the keying is carried in the SRTP/SRTCP media
path, and no signaling whatsoever is carried in the call path, and no signaling whatsoever is carried in the call
signaling path. signaling path.
signaling and media path: Parts of the keying are carried in the signaling and media path: Parts of the keying are carried in the
SRTP/SRTCP media path, and parts are carried in the call SRTP/SRTCP media path, and parts are carried in the call
signaling (SIP or SDP) path. signaling (SIP or SDP) path.
skipping to change at page 25, line 24 skipping to change at page 26, line 9
which parse and route SIP messages. The media path, on the other which parse and route SIP messages. The media path, on the other
hand, does not normally have computational elements involved, and hand, does not normally have computational elements involved, and
even when computational elements such as firewalls are involved, they even when computational elements such as firewalls are involved, they
cause very little additional delay. Thus, the media path can be cause very little additional delay. Thus, the media path can be
useful for exchanging several messages to establish SRTP keys. A useful for exchanging several messages to establish SRTP keys. A
disadvantage of keying over the media path is that interworking disadvantage of keying over the media path is that interworking
different key exchange requires the interworking function be in the different key exchange requires the interworking function be in the
media path, rather than just in the signaling path; in practice this media path, rather than just in the signaling path; in practice this
involvement is probably unavoidable anyway. involvement is probably unavoidable anyway.
A.1. Signaling Path Keying Techniques
A.1.1. MIKEY-NULL A.1.1. MIKEY-NULL
MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both
directions. The key is sent unencrypted in SDP, which means the SDP directions. The key is sent unencrypted in SDP, which means the SDP
must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to- must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-
end (e.g., by using S/MIME). end (e.g., by using S/MIME).
MIKEY-NULL requires one message from offerer to answerer (half a MIKEY-NULL requires one message from offerer to answerer (half a
round trip), and does not add additional media path messages. round trip), and does not add additional media path messages.
skipping to change at page 27, line 32 skipping to change at page 28, line 20
This keying mechanism is identical to Appendix A.1.8, except that This keying mechanism is identical to Appendix A.1.8, except that
rather than protecting the signaling with TLS, the entire SDP is rather than protecting the signaling with TLS, the entire SDP is
encrypted with S/MIME. encrypted with S/MIME.
A.1.10. SDP-DH (expired) A.1.10. SDP-DH (expired)
SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie- SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie-
Hellman messages in the signaling path to establish session keys. To Hellman messages in the signaling path to establish session keys. To
protect against active man-in-the-middle attacks, the Diffie-Hellman protect against active man-in-the-middle attacks, the Diffie-Hellman
exchange needs to be protected with S/MIME, SIPS, or SIP-Identity exchange needs to be protected with S/MIME, SIPS, or SIP Identity
[RFC4474] and [RFC4474]. [RFC4474] and SIP Conected Identity [RFC4916].
SDP-DH requires one message from offerer to answerer, and one message SDP-DH requires one message from offerer to answerer, and one message
from answerer to offerer (full round trip), and does not add from answerer to offerer (full round trip), and does not add
additional media path messages. additional media path messages.
A.1.11. MIKEYv2 in SDP (expired) A.1.11. MIKEYv2 in SDP (expired)
MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to
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
skipping to change at page 39, line 6 skipping to change at page 39, line 47
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
PFS. PFS.
MIKEY-NULL MIKEY-NULL
No PFS. Not applicable; MIKEY-NULL does not have a long-term secret.
MIKEY-PSK MIKEY-PSK
No PFS. No PFS.
MIKEY-RSA MIKEY-RSA
No PFS. No PFS.
MIKEY-RSA-R MIKEY-RSA-R
No PFS. No PFS.
MIKEY-DHSIGN MIKEY-DHSIGN
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
MIKEY-DHHMAC MIKEY-DHHMAC
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
MIKEYv2 in SDP MIKEYv2 in SDP
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
Security Descriptions with SIPS Security Descriptions with SIPS
No PFS. Not applicable; Security Descriptions does not have a long-term
secret.
Security Descriptions with S/MIME Security Descriptions with S/MIME
No PFS. Not applicable; Security Descriptions does not have a long-term
secret.
SDP-DH SDP-DH
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
ZRTP ZRTP
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
EKT EKT
No PFS. No PFS.
skipping to change at page 45, line 36 skipping to change at page 46, line 36
R10 R-RTP-VALID R10 R-RTP-VALID
R11 (folded into R4; was reuse previous session) R11 (folded into R4; was reuse previous session)
R12 R-CERTS R12 R-CERTS
R13 R-FIPS R13 R-FIPS
R14 R-ASSOC R14 R-ASSOC
R15 (deleted; was ability to upgrade from RTP to SRTP, but R15 R-ALLOW-RTP
requirement was unclear on what it meant)
R16 R-DOS R16 R-DOS
R17 R-SIG-MEDIA R17 R-SIG-MEDIA
R18 R-EXISTING R18 R-EXISTING
R19 R-AGILITY R19 R-AGILITY
R20 R-DOWNGRADE R20 R-DOWNGRADE
R21 R-NEGOTIATE
R21 R-NEGOTIATE
R23 R-OTHER-SIGNALING R23 R-OTHER-SIGNALING
R23 R-RECORDING (R23 was duplicated in previous versions of the R23 R-RECORDING (R23 was duplicated in previous versions of the
document) document)
R24 (deleted; was lawful intercept) R24 (deleted; was lawful intercept)
R25 R-TRANSCODER R25 R-TRANSCODER
R26 R-PSTN R26 R-PSTN
skipping to change at page 48, line 47 skipping to change at page 49, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
This document was produced using xml2rfc v1.33pre8 (of This document was produced using xml2rfc v1.33 (of
http://xml.resource.org/) from a source in RFC-2629 XML format. http://xml.resource.org/) from a source in RFC-2629 XML format.
 End of changes. 32 change blocks. 
59 lines changed or deleted 97 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/