draft-ietf-mmusic-kmgmt-ext-13.txt		draft-ietf-mmusic-kmgmt-ext-14.txt
	Internet Engineering Task Force J. Arkko		Internet Engineering Task Force J. Arkko
	MMUSIC Working Group E. Carrara		MMUSIC Working Group E. Carrara
	INTERNET-DRAFT F. Lindholm		INTERNET-DRAFT F. Lindholm
	Expires: August 2005 M. Naslund		Expires: September 2005 M. Naslund
	K. Norrman		K. Norrman
	Ericsson		Ericsson
	February 2005		Mars 2005
	Key Management Extensions for Session Description		Key Management Extensions for Session Description
	Protocol (SDP) and Real Time Streaming Protocol (RTSP)		Protocol (SDP) and Real Time Streaming Protocol (RTSP)
	<draft-ietf-mmusic-kmgmt-ext-13.txt>		<draft-ietf-mmusic-kmgmt-ext-14.txt>
	Status of this memo		Status of this memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am (we are) aware have been		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	disclosed, and any of which I (we) become aware will be disclosed, in		author represents that any applicable patent or other IPR claims of
	accordance with RFC 3668 (BCP 79).		which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
	By submitting this Internet-Draft, I accept the provisions of Section		RFC 3668.
	3 of RFC 3667 (BCP 78).
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 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/lid-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 September 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document defines general extensions for SDP and RTSP to carry		This document defines general extensions for SDP and RTSP to carry
	messages, as specified by a key management protocol, in order to		messages, as specified by a key management protocol, in order to
	secure the media. These extensions are presented as a framework, to		secure the media. These extensions are presented as a framework, to
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	General guidelines are also given on how the framework should be used		General guidelines are also given on how the framework should be used
	together with SIP and RTSP. The usage with the MIKEY key management		together with SIP and RTSP. The usage with the MIKEY key management
	protocol is also defined.		protocol is also defined.
	TABLE OF CONTENTS		TABLE OF CONTENTS
	1. Introduction.....................................................3		1. Introduction.....................................................3
	1.1. Notational Conventions.........................................4		1.1. Notational Conventions.........................................4
	2. Extensions to SDP and RTSP.......................................4		2. Extensions to SDP and RTSP.......................................4
	2.1. SDP Extensions.................................................5		2.1. SDP Extensions.................................................5
	2.2. RTSP Extensions................................................5		2.2. RTSP Extensions................................................6
	3. Usage with SDP, SIP, RTSP, and SAP...............................6		3. Usage with SDP, SIP, RTSP, and SAP...............................6
	3.1. Use of SDP.....................................................7		3.1. Use of SDP.....................................................7
	3.1.1 General processing............................................7		3.1.1 General processing............................................7
	3.1.2 Use of SDP with offer/answer and SIP..........................9		3.1.2 Use of SDP with offer/answer and SIP..........................9
	3.1.3 Use of SDP with SAP..........................................11		3.1.3 Use of SDP with SAP..........................................12
	3.1.4 Bidding-down attack prevention...............................12		3.1.4 Bidding-down attack prevention...............................12
	3.2. RTSP usage....................................................13		3.2. RTSP usage....................................................13
	4. Example scenarios...............................................15		4. Example scenarios...............................................15
	5. Adding further Key management protocols.........................19		5. Adding further Key management protocols.........................19
	6. Integration of MIKEY............................................20		6. Integration of MIKEY............................................20
	6.1 MIKEY Interface................................................21		6.1 MIKEY Interface................................................21
	7. Security Considerations.........................................21		7. Security Considerations.........................................22
	8. IANA Considerations.............................................23		8. IANA Considerations.............................................23
	8.1. SDP Attribute Registration....................................23		8.1. SDP Attribute Registration....................................23
	8.2. RTSP Registration.............................................23		8.2. RTSP Registration.............................................24
	8.3. Protocol Identifier Registration..............................24		8.3. Protocol Identifier Registration..............................24
	9. Acknowledgments.................................................25		9. Acknowledgments.................................................25
	10. Author's Addresses.............................................25		10. Author's Addresses.............................................25
	11. References.....................................................25		11. References.....................................................26
	11.1. Normative References.........................................25		11.1. Normative References.........................................26
	11.2. Informative References.......................................26		11.2. Informative References.......................................26
	1. Introduction		1. Introduction
	[RFC Editor remark] All instances of RFC xxxx should be replaced		[RFC Editor remark] All instances of RFC xxxx should be replaced
	with the RFC number of this document, when published.		with the RFC number of this document, when published.
	There has recently been work to define a security profile for the		There has recently been work to define a security profile for the
	protection of real-time applications running over RTP, [SRTP].		protection of real-time applications running over RTP, [SRTP].
	However, a security protocol needs a key management solution to		However, a security protocol needs a key management solution to
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	Currently in SDP [SDPnew], there exists one field to transport keys,		Currently in SDP [SDPnew], there exists one field to transport keys,
	the "k=" field. However, this is not enough for a key management		the "k=" field. However, this is not enough for a key management
	protocol as there are many more parameters that need to be		protocol as there are many more parameters that need to be
	transported, and the "k=" field is not extensible. The approach used		transported, and the "k=" field is not extensible. The approach used
	is to extend the SDP description through a number of attributes that		is to extend the SDP description through a number of attributes that
	transport the key management offer/answer and also to associate it		transport the key management offer/answer and also to associate it
	with the media sessions. SIP uses the offer/answer model [OAM]		with the media sessions. SIP uses the offer/answer model [OAM]
	whereby extensions to SDP will be enough. However, RTSP [RTSP] does		whereby extensions to SDP will be enough. However, RTSP [RTSP] does
	not use the offer/answer model with SDP, so a new RTSP header is		not use the offer/answer model with SDP, so a new RTSP header is
	introduced to convey key management data.		introduced to convey key management data. [SDES] uses the approach of
			extending SDP, to carry the security parameters for the media
			streams. However, the mechanism defined in [SDES] requires end-to-end
			protection of the SDP by some security protocol such as S/MIME, in
			order to get end-to-end protection. The solution described here
			focuses only on the end-to-end protection of key management
			parameters and as a consequence does not require external end-to-end
			protection means. It is important to note though, and we stress this
			again, that only the key management parameters are protected.
	The document also defines the use of the described framework together		The document also defines the use of the described framework together
	with the key management protocol Multimedia Internet KEYing (MIKEY)		with the key management protocol Multimedia Internet KEYing (MIKEY)
	[MIKEY].		[MIKEY].
	1.1. Notational Conventions		1.1. Notational Conventions
	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].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 4, line 40		skipping to change at page 4, line 48
	For both SDP and RTSP, the general method of adding the key		For both SDP and RTSP, the general method of adding the key
	management protocol is to introduce new attributes, one identifier to		management protocol is to introduce new attributes, one identifier to
	identify the specific key management protocol, and one data field		identify the specific key management protocol, and one data field
	where the key management protocol data is placed. The key management		where the key management protocol data is placed. The key management
	protocol data contains the necessary information to establish the		protocol data contains the necessary information to establish the
	security protocol, e.g., keys and cryptographic parameters. All		security protocol, e.g., keys and cryptographic parameters. All
	parameters and keys are protected by the key management protocol.		parameters and keys are protected by the key management protocol.
	The key management data SHALL be base64 [RFC3548] encoded and comply		The key management data SHALL be base64 [RFC3548] encoded and comply
	with the base64 grammar as defined in [SDPnew]. The key management		with the base64 grammar as defined in [SDPnew]. The key management
	protocol identifier, KMID, is defined as below in Augmented Backus-		protocol identifier, KMPID, is defined as below in Augmented Backus-
	Naur Form grammar (ABNF) [RFC2234].		Naur Form grammar (ABNF) [RFC2234].
	KMID = 1*(ALPHA / DIGIT)		KMPID = 1*(ALPHA / DIGIT)
			Values for the identifier, KMPID, are registered and defined in
	Values for the identifier, KMID, are registered and defined in		accordance to Section 8. Note that the KMPID is case sensitive and it
	accordance to Section 8. Note that the KMID is case sensitive and it
	is RECOMMENDED that values registered are lower case letters.		is RECOMMENDED that values registered are lower case letters.
	2.1. SDP Extensions		2.1. SDP Extensions
	This section provides an ABNF grammar (as used in [SDPnew]) for the		This section provides an ABNF grammar (as used in [SDPnew]) for the
	key management extensions to SDP.		key management extensions to SDP.
	Note that the new definitions are compliant with the definition of an		Note that the new definitions are compliant with the definition of an
	attribute field, i.e.		attribute field, i.e.
	attribute = (att-field ":" att-value) | att-field		attribute = (att-field ":" att-value) | att-field
	The ABNF for the key management extensions (conforming to the att-		The ABNF for the key management extensions (conforming to the att-
	field and att-value) are as follow:		field and att-value) are as follow:
	key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value		key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value
	key-mgmt-att-field = "key-mgmt"		key-mgmt-att-field = "key-mgmt"
	key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data		key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data
	prtcl-id = KMID		prtcl-id = KMPID
	; e.g. "mikey"		; e.g. "mikey"
	keymgmt-data = base64		keymgmt-data = base64
	SP = 0x20		SP = 0x20
	where KMID is as defined in Section 2 of this memo, base64 is as		where KMPID is as defined in Section 2 of this memo, base64 is as
	defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined		defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined
	for KMID in Section 8.		for KMPID in Section 8.
	The attribute MAY be used at session level, media level, or at both		The attribute MAY be used at session level, media level, or at both
	levels. An attribute defined at media level overrides an attribute		levels. An attribute defined at media level overrides an attribute
	defined at session level. In other words, if the media level		defined at session level. In other words, if the media level
	attribute is present, the session level attribute MUST be ignored for		attribute is present, the session level attribute MUST be ignored for
	this media. Section 3.1 describes in detail how the attributes are		this media. Section 3.1 describes in detail how the attributes are
	used and how the SDP is handled in different usage scenarios. The		used and how the SDP is handled in different usage scenarios. The
	choice of the level depends for example on the particular key		choice of the level depends for example on the particular key
	management protocol. Some protocols may not be able to derive enough		management protocol. Some protocols may not be able to derive enough
	key material for all the sessions; furthermore, possibly a different		key material for all the sessions; furthermore, possibly a different
	skipping to change at page 6, line 4		skipping to change at page 6, line 11
	protocols, such as MIKEY, have instead those capabilities (as it can		protocols, such as MIKEY, have instead those capabilities (as it can
	express multiple security policies and derive multiple keys), so it		express multiple security policies and derive multiple keys), so it
	may use the session level.		may use the session level.
	2.2. RTSP Extensions		2.2. RTSP Extensions
	To support the key management attributes, the following RTSP header		To support the key management attributes, the following RTSP header
	is defined:		is defined:
	KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)		KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)
	key-mgmt-spec = "prot" "=" KMID ";" ["uri" "=" <"> rtsp_URL <"> ";"]
			key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" <"> rtsp_URL <"> ";"]
	"data" "=" base64		"data" "=" base64
	where KMID is as defined in Section 2 of this memo, "base64" as		where KMPID is as defined in Section 2 of this memo, "base64" as
	defined in [SDPnew], and "rtsp_URL" as defined in [RTSP].		defined in [SDPnew], and "rtsp_URL" as defined in [RTSP].
	The "uri" parameter identifies the context for which the key		The "uri" parameter identifies the context for which the key
	management data applies, and the RTSP URI SHALL match a (session or		management data applies, and the RTSP URI SHALL match a (session or
	media) URI present in the description of the session. If the RTSP		media) URI present in the description of the session. If the RTSP
	aggregated control URI is included it indicates that the key		aggregated control URI is included it indicates that the key
	management message is on session level (and similarly the RTSP media		management message is on session level (and similarly the RTSP media
	control URI, that it applies to the media level). If no "uri"		control URI, that it applies to the media level). If no "uri"
	parameter is present in a key-mgmt-spec the specification applies to		parameter is present in a key-mgmt-spec the specification applies to
	the context identified by the RTSP request URI.		the context identified by the RTSP request URI.
	skipping to change at page 6, line 48		skipping to change at page 7, line 8
	3. Usage with SDP, SIP, RTSP, and SAP		3. Usage with SDP, SIP, RTSP, and SAP
	This section gives rules and recommendations of how/when to include		This section gives rules and recommendations of how/when to include
	the defined key management attribute when SIP and/or RTSP are used		the defined key management attribute when SIP and/or RTSP are used
	together with SDP.		together with SDP.
	When a key management protocol is integrated with SIP/SDP and RTSP,		When a key management protocol is integrated with SIP/SDP and RTSP,
	the following general requirements are placed on the key management:		the following general requirements are placed on the key management:
	* It MUST be possible to execute the key management protocol in at		* At the current time, it MUST be possible to execute the key
	most one request-response message exchange.		management protocol in at most one request-response message
			exchange. Future relaxation of this requirement is possible but
			would introduce significant complexity for implementations
			supporting multi-roundtrip mechanisms.
	* It MUST be possible from the SIP/SDP and RTSP application, using		* It MUST be possible from the SIP/SDP and RTSP application, using
	the key management API, to receive key management data, and		the key management API, to receive key management data, and
	information of whether a message is accepted or not.		information of whether a message is accepted or not.
	The content of the key management messages depends on the key		The content of the key management messages depends on the key
	management protocol that is used. However, the content of such key		management protocol that is used. However, the content of such key
	management messages might be expected to be roughly as follow: the		management messages might be expected to be roughly as follow: the
	key management Initiator (e.g. the offerer) includes the key		key management Initiator (e.g. the offerer) includes the key
	management data in a first message, containing the media description		management data in a first message, containing the media description
	skipping to change at page 11, line 39		skipping to change at page 11, line 48
	answerer SHOULD send a "488 Not Acceptable Here" message, including		answerer SHOULD send a "488 Not Acceptable Here" message, including
	one or more Warning headers (at least a 306). The offerer MUST then		one or more Warning headers (at least a 306). The offerer MUST then
	abort the session.		abort the session.
	Note that, in multicast scenarios, unlike unicast, there is only a		Note that, in multicast scenarios, unlike unicast, there is only a
	single view of the stream [OAM], hence there MUST be a uniform		single view of the stream [OAM], hence there MUST be a uniform
	agreement of the security parameters.		agreement of the security parameters.
	After the offer is issued, the offerer SHOULD be prepared to receive		After the offer is issued, the offerer SHOULD be prepared to receive
	media, as the media may arrive prior to the answer. However, this		media, as the media may arrive prior to the answer. However, this
	brings issues, as the offer does not know yet the answererÆs choice		brings issues, as the offer does not know yet the answerer's choice
	in terms of e.g. algorithms, nor possibly the key is know. This can		in terms of e.g. algorithms, nor possibly the key is know. This can
	cause delay or clipping can occur; if this is unacceptable, the		cause delay or clipping can occur; if this is unacceptable, the
	offerer SHOULD use mechanisms outside the scope of this document,		offerer SHOULD use mechanisms outside the scope of this document,
	e.g. the security precondition for SIP [SPREC].		e.g. the security precondition for SIP [SPREC].
	3.1.3 Use of SDP with SAP		3.1.3 Use of SDP with SAP
	There are cases where SDP is used without conforming to the		There are cases where SDP is used without conforming to the
	offer/answer model; instead it is a one-way SDP distribution (i.e.		offer/answer model; instead it is a one-way SDP distribution (i.e.
	without back channel), such as when used with SAP and HTTP.		without back channel), such as when used with SAP and HTTP.
	skipping to change at page 12, line 35		skipping to change at page 12, line 45
	that still MUST authenticate its own protocol identifier.		that still MUST authenticate its own protocol identifier.
	The list of protocol identifiers MUST then be given to each of the		The list of protocol identifiers MUST then be given to each of the
	selected (offered) key management protocols by the application with		selected (offered) key management protocols by the application with
	";" separated identifiers. All the offered protocol identifiers MUST		";" separated identifiers. All the offered protocol identifiers MUST
	be included, in the same order as they appear in the corresponding		be included, in the same order as they appear in the corresponding
	SDP description.		SDP description.
	The protocol list can formally be described as		The protocol list can formally be described as
	prtcl-list = KMID *(";" KMID)		prtcl-list = KMPID *(";" KMPID)
	where KMID is as defined in Section 2.		where KMPID is as defined in Section 2.
	For example, if the offered protocols are MIKEY and two yet-to-be-		For example, if the offered protocols are MIKEY and two yet-to-be-
	invented protocols KEYP1, KEYP2, the SDP is:		invented protocols KEYP1, KEYP2, the SDP is:
	v=0		v=0
	o=alice 2891092738 2891092738 IN IP4 lost.example.com		o=alice 2891092738 2891092738 IN IP4 lost.example.com
	s=Secret discussion		s=Secret discussion
	t=0 0		t=0 0
	c=IN IP4 lost.example.com		c=IN IP4 lost.example.com
	a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...		a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
	skipping to change at page 20, line 27		skipping to change at page 20, line 35
	Today, the MIKEY protocol [MIKEY] has adopted the key management		Today, the MIKEY protocol [MIKEY] has adopted the key management
	extensions to work together with SIP and RTSP (see Section 6). Other		extensions to work together with SIP and RTSP (see Section 6). Other
	protocols MAY use the described attribute and header, e.g. Kerberos		protocols MAY use the described attribute and header, e.g. Kerberos
	[KERB], however this is subject to future standardization.		[KERB], however this is subject to future standardization.
	6. Integration of MIKEY		6. Integration of MIKEY
	[MIKEY] describes a key management protocol for real-time		[MIKEY] describes a key management protocol for real-time
	applications (both for peer-to-peer communication and group		applications (both for peer-to-peer communication and group
	communication). MIKEY can be integrated within SDP and RTSP,		communication). MIKEY carries the security parameters needed for
	following the rules and guidelines described in this document.		setting up the security protocol (e.g., SRTP) protecting the media
			stream. MIKEY can be integrated within SDP and RTSP, following the
			rules and guidelines described in this document.
	MIKEY satisfies the requirements described in Section 3. The MIKEY		MIKEY satisfies the requirements described in Section 3. The MIKEY
	message is formed as defined in [MIKEY], then passed from MIKEY to		message is formed as defined in [MIKEY], then passed from MIKEY to
	the SDP application that base64 encodes it, and encapsulates it in		the SDP application that base64 encodes it, and encapsulates it in
	the keymgmt-data attribute. The examples in Section 4 use MIKEY,		the keymgmt-data attribute. The examples in Section 4 use MIKEY,
	where the semantic of the exchange is also briefly explained.		where the semantic of the exchange is also briefly explained.
	The key management protocol identifier (KMID) to be used as the		The key management protocol identifier (KMPID) to be used as the
	protocol identifier SHALL be "mikey" and is registered at IANA, see		protocol identifier SHALL be "mikey" and is registered at IANA, see
	in detail Section 8.		in detail Section 8.
	The information that the key management needs from SDP and RTSP, and		The information that the key management needs from SDP and RTSP, and
	vice versa, follows Section 3. To avoid bidding-down attacks, the		vice versa, follows Section 3. To avoid bidding-down attacks, the
	directives in Section 3.1.4 are followed. The list of protocol		directives in Section 3.1.4 are followed. The list of protocol
	identifiers is authenticated within MIKEY by placing the list in a		identifiers is authenticated within MIKEY by placing the list in a
	General Extension Payload (of type "SDP IDs", [MIKEY]), which then		General Extension Payload (of type "SDP IDs", [MIKEY]), which then
	automatically will be integrity protected/signed. The receiver SHALL		automatically will be integrity protected/signed. The receiver SHALL
	then match the list in the General Extension Payload with the list		then match the list in the General Extension Payload with the list
	skipping to change at page 22, line 16		skipping to change at page 22, line 26
	intermediate proxies to have access to part of the SIP message, and		intermediate proxies to have access to part of the SIP message, and
	sometimes also to the SDP description (c.f. [E2M]), although end-to-		sometimes also to the SDP description (c.f. [E2M]), although end-to-
	end confidentiality can hide bodies from intermediaries. General		end confidentiality can hide bodies from intermediaries. General
	security considerations for the session setup can be found in SDP		security considerations for the session setup can be found in SDP
	[SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this		[SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this
	memo is useful when the session setup is not protected in an end-to-		memo is useful when the session setup is not protected in an end-to-
	end fashion, but the media streams needs to be end-to-end protected,		end fashion, but the media streams needs to be end-to-end protected,
	hence the security parameters (such as keys) are not wanted revealed		hence the security parameters (such as keys) are not wanted revealed
	to nor manipulated by intermediaries.		to nor manipulated by intermediaries.
	The security will also depend on the encapsulated level of security		The security will also depend on the level of security the key
	the key management protocol offers. It follows that, under the		management protocol offers. It follows that, under the assumption
	assumption that the key management schemes are secure, the SDP can be		that the key management schemes are secure, the SDP can be passed
	passed along unencrypted without affecting the key management as		along unencrypted without affecting the key management as such, and
	such, and the media streams will still be secure even if some		the media streams will still be secure even if some attackers gained
	attackers gained knowledge of the SDP contents. Further security		knowledge of the SDP contents. Further security considerations can be
	considerations can be found for each key management protocol (for		found for each key management protocol (for MIKEY these can be found
	MIKEY these can be found in [MIKEY]). However, if the SDP messages		in [MIKEY]). However, if the SDP messages are not sent integrity
	are not sent integrity protected between the parties, it is possible		protected between the parties, it is possible for an active attacker
	for an active attacker to change attributes without being detected.		to change attributes without being detected. As the key management
	As the key management protocol may (indirectly) rely on some of the		protocol may (indirectly) rely on some of the session information
	session information from SDP (e.g., address information), an attack		from SDP (e.g., address information), an attack on SDP may have
	on SDP may have indirect consequences on the key management. Even if		indirect consequences on the key management. Even if the key
	the key management protocol does not rely on parameters of SDP and		management protocol does not rely on parameters of SDP and will not
	will not be affected by manipulation of these, different DoS attacks		be affected by manipulation of these, different DoS attacks aimed at
	aimed at SDP may lead to undesired interruption in the setup. See		SDP may lead to undesired interruption in the setup. See also the
	also the attacks described at the end of this section.		attacks described at the end of this section.
			The only integrity protected attribute of the media stream is, in the
			framework proposed here, the set of key management protocols. It is
			for instance possible to (1) swap key management offers across SDP
			messages, or, (2) inject a previous key management offer into a new
			SDP message. Making the (necessary) assumption that all involved key
			management protocols are secure, the second attack will be detected
			by replay protection mechanisms of the key management protocol(s).
			Making the further assumption that, according to normal best current
			practice, the production of each key management offer is done with
			independent (pseudo)random choices (for session keys and other
			parameters), the first attack will either be detected in the
			Responder's (now incorrect) verification reply message (if such is
			used), or, be a pure DoS attack, resulting in Initiator and Responder
			using different keys.
			It is RECOMMENDED for the identity at the SPD level to be the one
			authenticated at the key management protocol level. This might
			however need to keep into consideration privacy aspects, which are
			out of scope for this famework.
	The use of multiple key management protocols in the same offer may		The use of multiple key management protocols in the same offer may
	open up the possibility of a bidding-down attack, as specified in		open up the possibility of a bidding-down attack, as specified in
	Section 3.1.4. To exclude such possibility, the authentication of the		Section 3.1.4. To exclude such possibility, the authentication of the
	protocol identifier list is used. Note though, that the security		protocol identifier list is used. Note though, that the security
	level of the authenticated protocol identifier will be as high (or		level of the authenticated protocol identifier will be as high (or
	low), as the "weakest" protocol. Therefore, it is discouraged to		low), as the "weakest" protocol. Therefore, the offer MUST NOT
	offer protocols with too different security levels.		contain any security protocols (or configurations thereof) weaker
			than permitted by local security policy.
	Note that it is impossible to assure the authenticity of a declined		Note that it is impossible to assure the authenticity of a declined
	offer, since even if it comes from the true respondent, the fact that		offer, since even if it comes from the true respondent, the fact that
	the answerer declines the offer usually means that he does not		the answerer declines the offer usually means that he does not
	support the protocol(s) offered, and consequently cannot be expected		support the protocol(s) offered, and consequently cannot be expected
	to authenticate the response either. This means that if the Initiator		to authenticate the response either. This means that if the Initiator
	is unsure of which protocol(s) the Responder supports, we RECOMMEND		is unsure of which protocol(s) the Responder supports, we RECOMMEND
	that the Initiator offers all acceptable protocols in a single offer.		that the Initiator offers all acceptable protocols in a single offer.
	If not, this opens up the possibility for a "man-in-the-middle"		If not, this opens up the possibility for a "man-in-the-middle"
	(MITM) to affect the outcome of the eventually agreed upon protocol,		(MITM) to affect the outcome of the eventually agreed upon protocol,
	skipping to change at page 23, line 21		skipping to change at page 23, line 51
	to the local policy to decide the behavior in the case that the		to the local policy to decide the behavior in the case that the
	response declines any security (therefore there is impossibility of		response declines any security (therefore there is impossibility of
	authenticating it). If for example the local policy requires a secure		authenticating it). If for example the local policy requires a secure
	communication and cannot accept an unsecured one, then the session		communication and cannot accept an unsecured one, then the session
	setup SHALL be aborted.		setup SHALL be aborted.
	8. IANA Considerations		8. IANA Considerations
	8.1. SDP Attribute Registration		8.1. SDP Attribute Registration
	A new SDP attribute needs to be registered for the purpose of key		The IANA is hereby requested to create a new subregistry for the
	management protocol integration with SDP.		purpose of key management protocol integration with SDP.
	Contact: Fredrik Lindholm
	mailto: fredrik.lindholm@ericsson.com
	tel: +46 8 58531705
	SDP Attribute Field ("att-field"):		SDP Attribute Field ("att-field"):
	Name: key-mgmt-att-field		Name: key-mgmt-att-field
	Long form: key management protocol attribute field		Long form: key management protocol attribute field
	Type of name: att-field		Type of name: att-field
	Type of attribute: Media and session level		Type of attribute: Media and session level
	Purpose: See RFC xxxx, Section 2.		Purpose: See RFC xxxx, Section 2.
	Reference: RFC xxxx, Section 2.1		Reference: RFC xxxx, Section 2.1
	Values: See RFC xxxx, Section 2.1 and 8.3.		Values: See RFC xxxx, Section 2.1 and 8.3.
	8.2. RTSP Registration		8.2. RTSP Registration
	A new RTSP Header needs to be registered for the purpose of key		The IANA is hereby requested to create a new subregistry for the
	management protocol integration with RTSP.		purpose of key management protocol integration with RTSP.
	Following the guidelines of [RTSP], the registration is defined as		Following the guidelines of [RTSP], the registration is defined as
	follows:		follows:
	Header name: keymgmt		Header name: keymgmt
	Header syntax: see RFC xxxx, Section 2.2		Header syntax: see RFC xxxx, Section 2.2
	Intended usage: see RFC xxxx, Section 2.2		Intended usage: see RFC xxxx, Section 2.2
	Proxy treatment: Proxies SHALL NOT add, change, or delete the		Proxy treatment: Proxies SHALL NOT add, change, or delete the
	header. The proxy does not need to read this		header. The proxy does not need to read this
	header.		header.
	skipping to change at page 24, line 4		skipping to change at page 24, line 30
	Following the guidelines of [RTSP], the registration is defined as		Following the guidelines of [RTSP], the registration is defined as
	follows:		follows:
	Header name: keymgmt		Header name: keymgmt
	Header syntax: see RFC xxxx, Section 2.2		Header syntax: see RFC xxxx, Section 2.2
	Intended usage: see RFC xxxx, Section 2.2		Intended usage: see RFC xxxx, Section 2.2
	Proxy treatment: Proxies SHALL NOT add, change, or delete the		Proxy treatment: Proxies SHALL NOT add, change, or delete the
	header. The proxy does not need to read this		header. The proxy does not need to read this
	header.		header.
	Purpose: see RFC xxxx, Section 2		Purpose: see RFC xxxx, Section 2
	The RTSP Status-Code "463" [RFC xxxx], with the default string "Key		The RTSP Status-Code "463" [RFC xxxx], with the default string "Key
	management failure", needs to be registered.		management failure", needs to be registered.
	8.3. Protocol Identifier Registration		8.3. Protocol Identifier Registration
	This document defines one new name space, the "SDP/RTSP key		This document defines one new name space, the "SDP/RTSP key
	management protocol identifier", associated with the protocol		management protocol identifier", associated with the protocol
	identifier, KMID, defined in Section 2 to be used with the above		identifier, KMPID, defined in Section 2 to be used with the above
	registered attributes in SDP and RTSP.		registered attributes in SDP and RTSP.
	A new registry needs to be set up for the KMID parameter, with the		The IANA is hereby requested to create a new subregistry for the
	following registration created initially: "mikey".		KMPID parameter, with the following registration created initially:
			"mikey".
	Contact: Fredrik Lindholm
	mailto: fredrik.lindholm@ericsson.com
	tel: +46 8 58531705
	Value name: mikey		Value name: mikey
	Long name: Multimedia Internet KEYing		Long name: Multimedia Internet KEYing
	Purpose: Usage of MIKEY with the key-mgmt-att-field		Purpose: Usage of MIKEY with the key-mgmt-att-field
	attribute and the keymgmt RTSP header		attribute and the keymgmt RTSP header
	Reference: Section 7 in RFC 3830		Reference: Section 7 in RFC 3830
	Note that this registration implies that the protocol identifier,		Note that this registration implies that the protocol identifier,
	KMID, name space will be shared between SDP and RTSP.		KMPID, name space will be shared between SDP and RTSP.
	Further values may be registered according to the "Specification		Further values may be registered according to the "Specification
	Required" policy as defined in [RFC2434]. Each new registration needs		Required" policy as defined in [RFC2434]. Each new registration needs
	to indicate the parameter name, and register it within IANA. Note		to indicate the parameter name, and register it within IANA. Note
	that the parameter name is case sensitive and it is RECOMMENDED that		that the parameter name is case sensitive and it is RECOMMENDED that
	the name to be in lower case letters. For each new registration, it		the name to be in lower case letters. For each new registration, it
	is mandatory that a permanent, stable, and publicly accessible		is mandatory that a permanent, stable, and publicly accessible
	document exists that specifies the semantics of the registered		document exists that specifies the semantics of the registered
	parameter and the requested details of interaction between the key		parameter and the requested details of interaction between the key
	management protocol and SDP, as specified in RFC xxxx.		management protocol and SDP, as specified in RFC xxxx.
	New values MUST be register with IANA. Registrations SHALL include		New values MUST be register with IANA. Registrations SHALL include
	the following information:		the following information:
	* Contact: the contact name and email address		* Contact: the contact name and email address
	* Value name: the name of the value being registered (which MUST		* Value name: the name of the value being registered (which MUST
	comply with the KMID as defined in Section 2)		comply with the KMPID as defined in Section 2)
	* Long Name: long-form name in English		* Long Name: long-form name in English
	* Purpose: short explanation of the purpose of the registered name.		* Purpose: short explanation of the purpose of the registered name.
	* Reference: a reference to the specification (e.g. RFC number)		* Reference: a reference to the specification (e.g. RFC number)
	providing the usage guidelines in accordance to Section 5 (and		providing the usage guidelines in accordance to Section 5 (and
	also complying to the specified requirements).		also complying to the specified requirements).
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank Francois Audet, Rolf Blom, Johan		The authors would like to thank Francois Audet, Rolf Blom, Johan
	Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries,		Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries,
	skipping to change at page 25, line 20		skipping to change at page 25, line 42
	Perkins and Magnus Westerlund, who contributed in many sections.		Perkins and Magnus Westerlund, who contributed in many sections.
	10. Author's Addresses		10. Author's Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	02420 Jorvas Phone: +358 40 5079256		02420 Jorvas Phone: +358 40 5079256
	Finland Email: jari.arkko@ericsson.com		Finland Email: jari.arkko@ericsson.com
	Elisabetta Carrara		Elisabetta Carrara
	Ericsson Research		Ericsson
	SE-16480 Stockholm Phone: +46 8 50877040		SE-16480 Stockholm Phone: +46 8 50877040
	Sweden EMail: elisabetta.carrara@ericsson.com		Sweden EMail: elisabetta.carrara@ericsson.com
	Fredrik Lindholm		Fredrik Lindholm
	Ericsson Research		Ericsson
	SE-16480 Stockholm Phone: +46 8 58531705		SE-16480 Stockholm Phone: +46 8 58531705
	Sweden EMail: fredrik.lindholm@ericsson.com		Sweden EMail: fredrik.lindholm@ericsson.com
	Mats Naslund		Mats Naslund
	Ericsson Research		Ericsson Research
	SE-16480 Stockholm Phone: +46 8 58533739		SE-16480 Stockholm Phone: +46 8 58533739
	Sweden EMail: mats.naslund@ericsson.com		Sweden EMail: mats.naslund@ericsson.com
	Karl Norrman		Karl Norrman
	Ericsson Research		Ericsson Research
	skipping to change at page 26, line 33		skipping to change at page 27, line 8
	[E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the		[E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the
	Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono-		Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono-
	sipping-end2middle-security-03.		sipping-end2middle-security-03.
	[KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication		[KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication
	Service (V5)", IETF, RFC 1510.		Service (V5)", IETF, RFC 1510.
	[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions		[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
	(S/MIME) Version 3.1 Message Specification", IETF, RFC 3851.		(S/MIME) Version 3.1 Message Specification", IETF, RFC 3851.
			[SDES] Andreasen, F., Baugher, M., Wing, D., "Session Description
			Protocol Security Descriptions for Media Streams", work in progress,
			February 2005.
	[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,		[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman,
	K., "The Secure Real-time Transport Protocol", IETF, RFC 3711.		K., "The Secure Real-time Transport Protocol", IETF, RFC 3711.
	[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security		[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security
	Preconditions for Session Description Protocol Media Streams", work		Preconditions for Session Description Protocol Media Streams", work
	in progress, February 2004.		in progress, February 2004.
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at ietf-
			ipr@ietf.org.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2004). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Disclaimer of Validity		Disclaimer of Validity
	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
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	This Internet-Draft expires in August 2005.		This Internet-Draft expires in September 2005.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/