< 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 47 ¶		skipping to change at page 14, line 47 ¶
	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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/