draft-ietf-sip-media-security-requirements-07.txt   draft-ietf-sip-media-security-requirements-08.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: December 4, 2008 Siemens AG Expires: May 3, 2009 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
June 2, 2008 October 30, 2008
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-07 draft-ietf-sip-media-security-requirements-08
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 December 4, 2008. This Internet-Draft will expire on May 3, 2009.
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 and Requirements Considerations . . . . . . . . 8 4. Call Scenarios and Requirements Considerations . . . . . . . . 8
4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8 4.1. Clipping Media Before Signaling Answer . . . . . . . . . . 8
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 9 4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 9
4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. PSTN gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12 4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 13
4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13 4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 14
4.8. Interworking with Other Signaling Protocols . . . . . . . 14 4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14 4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 15
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15 5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 17 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 17
5.3. Requirements Outside of the Key Management Protocol . . . 19 5.3. Requirements Outside of the Key Management Protocol . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24 Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25 A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25 A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25 A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25 A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 26
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 25 A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 26
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26 A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26 A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26 A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 27
A.1.8. Security Descriptions with SIPS . . . . . . . . . . . 26 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 . . . . . . . . . . 27
A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 27 A.1.10. SDP-DH (expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 27 A.1.11. MIKEYv2 in SDP (expired) . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27 A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 28
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28 A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28 A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 29
A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 29 A.3.3. MIKEYv2 Inband (expired) . . . . . . . . . . . . . . . 29
A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29 A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29 A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
A.4.2. Clipping Media Before SDP Answer . . . . . . . . . . . 31 A.4.2. Clipping Media Before SDP Answer . . . . . . . . . . . 32
A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33 A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 34
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35 A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 36
A.5.1. Distribution and Validation of Persistent Public A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 35 Keys and Certificates . . . . . . . . . . . . . . . . 36
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38 A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39 A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 40
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40 A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 41
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42 Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 43
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 42 B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 43
Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44 Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The work on media security started when the Session Initiation The work on media security started when the Session Initiation
Protocol (SIP) was still in its infancy. With the increased SIP Protocol (SIP) was still in its infancy. With the increased SIP
deployment and the availability of new SIP extensions and related deployment and the availability of new SIP extensions and related
protocols, the need for end-to-end security was re-evaluated. The protocols, the need for end-to-end security was re-evaluated. The
procedure of re-evaluating prior protocol work and design decisions procedure of re-evaluating prior protocol work and design decisions
is not an uncommon strategy and, to some extent, considered necessary is not an uncommon strategy and, to some extent, considered necessary
to ensure that the developed protocols indeed meet the previously to ensure that the developed protocols indeed meet the previously
skipping to change at page 4, line 42 skipping to change at page 4, line 42
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the document are to be interpreted as described in [RFC2119], with the
important qualification that, unless otherwise stated, these terms important qualification that, unless otherwise stated, these terms
apply to the design of the media security key management protocol, apply to the design of the media security key management protocol,
not its implementation or application. not its implementation or application.
Furthermore, the terminology described in SIP ([RFC3261]) regarding
functions and components are used throughout the document
Additionally, the following items are used in this document: Additionally, the following items are used in this document:
AOR (Address-of-Record): A SIP or SIPS URI that points to a domain AOR (Address-of-Record): A SIP or SIPS URI that points to a domain
with a location service that can map the URI to another URI where with a location service that can map the URI to another URI where
the user might be available. Typically, the location service is the user might be available. Typically, the location service is
populated through registrations. An AOR is frequently thought of populated through registrations. An AOR is frequently thought of
as the "public address" of the user. as the "public address" of the user.
SSRC: The 32-bit value that defines the synchronization source, used SSRC: The 32-bit value that defines the synchronization source, used
in RTP. These are generally unique, but collisions can occur. in RTP. These are generally unique, but collisions can occur.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
there must be a way to use the protocol so that an active attack is there must be a way to use the protocol so that an active attack is
required against both the signaling and media paths, and so that such required against both the signaling and media paths, and so that such
attacks are detectable by the endpoints. attacks are detectable by the endpoints.
4. Call Scenarios and Requirements Considerations 4. Call Scenarios and Requirements Considerations
The following subsections describe call scenarios that pose the most The following subsections describe call scenarios that pose the most
challenge to the key management system for media data in cooperation challenge to the key management system for media data in cooperation
with SIP signaling. with SIP signaling.
Throughout the subsections requirements are stated by using the
nomenclature R- to state an explicit requirement. All of the stated
requirements are explanied in detail in section Section 5. The
requirements in section Section 5 are listed according their
association to the key management protocol, to attack scenarios, and
requirements which can be met inside the key management protocol or
outside of the key management protocol.
4.1. Clipping Media Before Signaling Answer 4.1. Clipping Media Before Signaling Answer
The discussion in this section relates to requirement R-AVOID- The discussion in this section relates to requirement R-AVOID-
CLIPPING and R-ALLOW-RTP. CLIPPING and R-ALLOW-RTP.
Per the SDP Offer/Answer Model [RFC3264], Per the SDP Offer/Answer Model [RFC3264],
"Once the offerer has sent the offer, it MUST be prepared to "Once the offerer has sent the offer, it MUST be prepared to
receive media for any recvonly streams described by that offer. receive media for any recvonly streams described by that offer.
It MUST be prepared to send and receive media for any sendrecv It MUST be prepared to send and receive media for any sendrecv
skipping to change at page 15, line 32 skipping to change at page 16, line 7
MUST NOT learn the SRTP keys (in either direction) used by the MUST NOT learn the SRTP keys (in either direction) used by the
answering endpoint. answering endpoint.
R-DISTINCT: R-DISTINCT:
The media security key management protocol MUST be capable of The media security key management protocol MUST be capable of
creating distinct, independent cryptographic contexts for each creating distinct, independent cryptographic contexts for each
endpoint in a forked session. endpoint in a forked session.
R-HERFP: R-HERFP:
The media security key management protocol MUST function The media security key management protocol MUST function
securely even in the presence of HERFP behavior. securely even in the presence of HERFP behavior, i.e., the
rejection of key information does not reach the sender.
Performance considerations: Performance considerations:
R-REUSE: R-REUSE:
The media security key management protocol MAY support the re- The media security key management protocol MAY support the re-
use of a previously established security context. use of a previously established security context.
Note: re-use of the security context does not imply re- Note: re-use of the security context does not imply re-
use of RTP parameters (e.g., payload type or SSRC). use of RTP parameters (e.g., payload type or SSRC).
skipping to change at page 20, line 10 skipping to change at page 20, line 29
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgements 8. Acknowledgements
For contributions to the requirements portion of this document, the For contributions to the requirements portion of this document, the
authors would like to thank the active participants of the RTPSEC BoF authors would like to thank the active participants of the RTPSEC BoF
and on the RTPSEC mailing list, and a special thanks to Steffen Fries and on the RTPSEC mailing list, and a special thanks to Steffen Fries
and Dragan Ignjatic for their excellent MIKEY comparison document and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197]
[I-D.ietf-msec-mikey-applicability]. document.
The authors would furthermore like to thank the following people for The authors would furthermore like to thank the following people for
their review, suggestions, and comments: Flemming Andreasen, Richard their review, suggestions, and comments: Flemming Andreasen, Richard
Barnes, Richard Barnes, Mark Baugher, Wolfgang Buecker, Werner Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath
Dittmann, Lakshminath Dondeti, John Elwell, Martin Euchner, Steffen Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer
Fries, Hans-Heinrich Grusdt, Christer Holmberg, Guenther Horn, Peter Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic,
Howard, Leo Huang, Dragan Ignjatic, Cullen Jennings, Alan Johnston, Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David
Vesa Lehtovirta, Matt Lepinski, David McGrew, David Oran, Colin McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter
Perkins, Eric Raymond, Eric Rescorla, Peter Schneider, Srinath Schneider, Srinath Thiruvengadam, Dave Ward, Dan York, and Phil
Thiruvengadam, Dave Ward, Dan York, and Phil Zimmermann. Zimmermann.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-140-2] [FIPS-140-2]
NIST, "Security Requirements for Cryptographic Modules", NIST, "Security Requirements for Cryptographic Modules",
June 2005, <http://csrc.nist.gov/publications/fips/ June 2005, <http://csrc.nist.gov/publications/fips/
fips140-2/fips1402.pdf>. fips140-2/fips1402.pdf>.
skipping to change at page 21, line 36 skipping to change at page 22, line 9
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-02 (work in progress), draft-ietf-avt-dtls-srtp-06 (work in progress),
February 2008. October 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
the Media Path", the Media Path",
draft-ietf-mmusic-media-path-middleboxes-00 (work in draft-ietf-mmusic-media-path-middleboxes-01 (work in
progress), January 2008. progress), July 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), December 2007. progress), July 2008.
[I-D.ietf-msec-mikey-applicability]
Fries, S. and D. Ignjatic, "On the applicability of
various MIKEY modes and extensions",
draft-ietf-msec-mikey-applicability-09 (work in progress),
March 2008.
[I-D.ietf-msec-mikey-ecc] [I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY", Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress), draft-ietf-msec-mikey-ecc-03 (work in progress),
June 2007. June 2007.
[I-D.ietf-sip-certs] [I-D.ietf-sip-certs]
Jennings, C. and J. Fischl, "Certificate Management Jennings, C. and J. Fischl, "Certificate Management
Service for The Session Initiation Protocol (SIP)", Service for The Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-06 (work in progress), April 2008. draft-ietf-sip-certs-06 (work in progress), April 2008.
skipping to change at page 23, line 8 skipping to change at page 23, line 22
[I-D.wing-sipping-srtp-key] [I-D.wing-sipping-srtp-key]
Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
Johnston, "Secure Media Recording and Transcoding with the Johnston, "Secure Media Recording and Transcoding with the
Session Initiation Protocol", Session Initiation Protocol",
draft-wing-sipping-srtp-key-03 (work in progress), draft-wing-sipping-srtp-key-03 (work in progress),
February 2008. February 2008.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP", Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-06 (work in progress), draft-zimmermann-avt-zrtp-10 (work in progress),
March 2008. October 2008.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures", for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[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 13 skipping to change at page 24, line 28
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol (SDP) Media Streams", Session Description Protocol (SDP) Media Streams",
RFC 5027, October 2007. RFC 5027, October 2007.
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of
Various Multimedia Internet KEYing (MIKEY) Modes and
Extensions", RFC 5197, June 2008.
Appendix A. Overview and Evaluation of Existing Keying Mechanisms Appendix A. Overview and Evaluation of Existing Keying Mechanisms
Based on how the SRTP keys are exchanged, each SRTP key exchange Based on how the SRTP keys are exchanged, each SRTP key exchange
mechanism belongs to one general category: mechanism belongs to one general category:
signaling path: signaling path:
All the keying is carried in the call signaling (SIP or SDP) All the keying is carried in the call signaling (SIP or SDP)
path. path.
media path: media path:
skipping to change at page 33, line 43 skipping to change at page 34, line 16
In SRTP, a cryptographic context is defined as the SSRC, destination In SRTP, a cryptographic context is defined as the SSRC, destination
network address, and destination transport port number. Whereas RTP, network address, and destination transport port number. Whereas RTP,
a flow is defined as the destination network address and destination a flow is defined as the destination network address and destination
transport port number. This results in a problem -- how to transport port number. This results in a problem -- how to
communicate the SSRC so that the SSRC can be used for the communicate the SSRC so that the SSRC can be used for the
cryptographic context. cryptographic context.
Two approaches have emerged for this communication. One, used by all Two approaches have emerged for this communication. One, used by all
MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY
exchange. Another, used by Security Descriptions, is to use "late exchange. Another, used by Security Descriptions, is to apply "late
bindng" -- that is, any new packet containing a previously-unseen bindng" -- that is, any new packet containing a previously-unseen
SSRC (which arrives at the same destination network address and SSRC (which arrives at the same destination network address and
destination transport port number) will create a new cryptographic destination transport port number) will create a new cryptographic
context. Another approach, common amongst techniques with media-path context. Another approach, common amongst techniques with media-path
SRTP key establishment, is to require a handshake over that media SRTP key establishment, is to require a handshake over that media
path before SRTP packets are sent. MIKEY's approach changes RTP's path before SRTP packets are sent. MIKEY's approach changes RTP's
SSRC collision detection behavior by requiring RTP to pre-establish SSRC collision detection behavior by requiring RTP to pre-establish
the SSRC values for each session. the SSRC values for each session.
Another related issue is that SRTP introduces a rollover counter Another related issue is that SRTP introduces a rollover counter
 End of changes. 28 change blocks. 
52 lines changed or deleted 62 lines changed or added

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