draft-ietf-sip-media-security-requirements-06.txt   draft-ietf-sip-media-security-requirements-07.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: November 13, 2008 Siemens AG Expires: December 4, 2008 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
May 12, 2008 June 2, 2008
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-06 draft-ietf-sip-media-security-requirements-07
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 November 13, 2008. This Internet-Draft will expire on December 4, 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.
skipping to change at page 14, line 46 skipping to change at page 14, line 46
4.9. Certificates 4.9. Certificates
The discussion in this section relates to R-CERTS. The discussion in this section relates to R-CERTS.
On the Internet and on some private networks, validating another On the Internet and on some private networks, validating another
peer's certificate is often done through a trust anchor -- a list of peer's certificate is often done through a trust anchor -- a list of
Certificate Authorities that are trusted. It can be difficult or Certificate Authorities that are trusted. It can be difficult or
expensive for a peer to obtain these certificates. In all cases, expensive for a peer to obtain these certificates. In all cases,
both parties to the call would need to trust the same trust anchor both parties to the call would need to trust the same trust anchor
(i.e., "certificate authority"). For these reasons, it is important (i.e., "certificate authority"). For these reasons, it is important
that authentication mechanisms that utilize trust anchors not rely that the media plane key management protocol offer a mechanism that
exclusively on such Certificate Authority-issued certificates, but to allows end-users who have no prior association to authenticate to
also allow self-signed certificates. By allowing the use of such each other without acquiring credentials from a third party trust
self-signed certificates, an out-of-band mechanism (e.g., manual point. Note that this does not rule out mechanisms in which servers
configuration) can be used to trust a peer's certificate. have certificates and attest to the identities of end-users.
5. Requirements 5. Requirements
This section is divided into several parts: requirements specific to This section is divided into several parts: requirements specific to
the key management protocol (Section 5.1), attack scenarios the key management protocol (Section 5.1), attack scenarios
(Section 5.2), and requirements which can be met inside the key (Section 5.2), and requirements 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 17, line 22 skipping to change at page 17, line 22
R-PFS: R-PFS:
The media security key management protocol MUST be able to The media security key management protocol MUST be able to
support perfect forward secrecy. support perfect forward secrecy.
R-COMPUTE: R-COMPUTE:
The media security key management protocol MUST support The media security key management protocol MUST support
offering additional SRTP cipher suites without incurring offering additional SRTP cipher suites without incurring
significant computational expense. significant computational expense.
R-CERTS: R-CERTS:
The media security key management protocol MUST NOT require The key management protocol MUST NOT require that end-users
using a trust anchor to validate credentials (e.g., a obtain credentials (certificates or private keys) from a third-
certificate) or to obtain credentials (e.g., a private key) party trust anchor.
used in the protocol.
R-FIPS: R-FIPS:
The media security key management protocol SHOULD use The media security key management protocol SHOULD use
algorithms that allow FIPS 140-2 [FIPS-140-2] certification. algorithms that allow FIPS 140-2 [FIPS-140-2] certification.
The United States Government can only purchase and use crypto The United States Government can only purchase and use crypto
implementations that have been validated by the FIPS-140 implementations that have been validated by the FIPS-140
[FIPS-140-2] process: [FIPS-140-2] process:
"The FIPS-140 standard is applicable to all Federal "The FIPS-140 standard is applicable to all Federal
 End of changes. 6 change blocks. 
13 lines changed or deleted 12 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/