< draft-tschofenig-hiprg-host-identities-02.txt		draft-tschofenig-hiprg-host-identities-03.txt >
	HIPRG H. Tschofenig		HIPRG H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: January 19, 2006 J. Ott		Expires: September 7, 2006 J. Ott
	Universitaet Bremen		Helsinki University of Technology
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia U.
	T. Henderson		T. Henderson
	The Boeing Company		The Boeing Company
	G. Camarillo		G. Camarillo
	Ericsson		Ericsson
	July 18, 2005		March 6, 2006
	Interaction between SIP and HIP		Interaction between SIP and HIP
	draft-tschofenig-hiprg-host-identities-02.txt		draft-tschofenig-hiprg-host-identities-03.txt
	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 41 ¶		skipping to change at page 1, line 41 ¶
	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 January 19, 2006.		This Internet-Draft will expire on September 7, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document investigates the interworking between the Session		This document investigates the interworking between the Session
	Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and		Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and
	the benefits that may arise from their combined operation.		the benefits that may arise from their combined operation.
	The aspect of exchanging Host Identities (or Host Identity Tags) in		The aspect of exchanging Host Identities (or Host Identity Tags) in
	SIP/SDP for later usage with the Host Identity Protocol Protocol		SIP/SDP for later usage with the Host Identity Protocol Protocol
	(HIP) is described in more detail as an example of this interworking.		(HIP) is described in more detail as an example of this interworking.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Exchanging Host Identities with SIP . . . . . . . . . . . . . 7		3. Exchanging Host Identities with SIP . . . . . . . . . . . . . 7
	3.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2 SDP Extension . . . . . . . . . . . . . . . . . . . . . . 8		3.2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . 8
	3.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 19		4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20		4.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21		4.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		4.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		4.4. Single-sided Verification . . . . . . . . . . . . . . . . 20
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 23		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	8.2 Informative References . . . . . . . . . . . . . . . . . . 23		6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . 27		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
			9.2. Informative References . . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
			Intellectual Property and Copyright Statements . . . . . . . . . . 31
	1. Introduction		1. Introduction
	SIP [1] enables a pair of user agents to establish and maintain		SIP [1] enables a pair of user agents to establish and maintain
	sessions. The communication typically involves SIP proxies before		sessions. The communication typically involves SIP proxies before
	prior to communication between the end points taking place. As part		prior to communication between the end points taking place. As part
	of the initial exchange, a number of parameters are exchanged.		of the initial exchange, a number of parameters are exchanged.
	Certain of these parameters are relevant to security. Examples of		Certain of these parameters are relevant to security. Examples of
	such parameters are keying material and other cryptographic		such parameters are keying material and other cryptographic
	information that is used in order to establish a security association		information that is used in order to establish a security association
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	as described in Section 3.		as described in Section 3.
	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 RFC 2119 [5].		document are to be interpreted as described in RFC 2119 [5].
	3. Exchanging Host Identities with SIP		3. Exchanging Host Identities with SIP
	3.1 Concept		3.1. Concept
	In order to provide security between two HIP end hosts beyond		In order to provide security between two HIP end hosts beyond
	opportunistic encryption it is necessary to securely retrieve the		opportunistic encryption it is necessary to securely retrieve the
	Host Identities. A number of mechanisms can be used including		Host Identities. A number of mechanisms can be used including
	directories (such as DNS) or more advanced concepts for example based		directories (such as DNS) or more advanced concepts for example based
	on Distributed Hash Tables typically used in peer-to-peer networks.		on Distributed Hash Tables typically used in peer-to-peer networks.
	This document suggests to exchange the Host Identities (or Host		This document suggests to exchange the Host Identities (or Host
	Identity Tags) as part of the initial SIP exchange inside the SDP		Identity Tags) as part of the initial SIP exchange inside the SDP
	payload. As such, the Host Identities can also be bound to the user		payload. As such, the Host Identities can also be bound to the user
	identities - a concept not used in HIP.		identities - a concept not used in HIP.
	The figure below illustrates the main idea:		Figure 1 illustrates the main idea:
	+-----------+ +-----------+		+-----------+ +-----------+
	HI/HIT |SIP | HI/HIT |SIP | HI/HIT		HI/HIT |SIP | HI/HIT |SIP | HI/HIT
	+------>|Proxy |<---------->|Proxy |<------+		+------>|Proxy |<---------->|Proxy |<------+
	| |Server X | TLS |Server Y | |		| |Server X | TLS |Server Y | |
	| +-----------+ +-----------+ |		| +-----------+ (+auth.id.)+-----------+ |
	| |		| |
	| TLS or TLS or |		| TLS or TLS or |
	| SIP Digest SIP Digest |		| SIP Digest SIP Digest |
	| |		| (+auth.id.) |
	| |		| |
	v v		v v
	+-----------+ SIP and HIP +-----------+		+-----------+ SIP and HIP +-----------+
	|SIP | <---------------------------------> |SIP |		|SIP | <---------------------------------> |SIP |
	|User Agent | RTP |User Agent |		|User Agent | RTP |User Agent |
	|Alice | <=================================> |Bob |		|Alice | <=================================> |Bob |
	+-----------+ +-----------+		+-----------+ +-----------+
	Legend:		Legend:
	<--->: Signaling Traffic		<--->: Signaling Traffic
	<===>: Data Traffic		<===>: Data Traffic
	Figure 1: SIP Trapezoid		Figure 1: SIP Trapezoid
	The initial SIP signaling messages between Alice and Bob often take		The initial SIP signaling messages between Alice and Bob often take
	place via the proxy servers. This exchange may be protected with TLS		place via the proxy servers. This exchange may be protected with TLS
	(between SIP proxies but also between SIP UAs and SIP proxies) or		(between SIP proxies but also between SIP UAs and SIP proxies) or
	with SIP digest authentication between SIP UAs and the outbound		with SIP digest authentication between SIP UAs and the outbound
	proxy. Furthermore, SIP end-to-end security mechanisms are also		proxy. Further SIP security mechanisms should be used in combination
	available with S/MIME.		with this proposal. The security consideration section, see
			Section 4, provides a discussion about the possible approaches to
			secure the Host Identity Tag and to relate it ongoing session.
	This allows two hosts to securely exchange keys even if there are		This allows two hosts to securely exchange keys even if there are
	only domain-level public and private keys, as well as secure		only domain-level public and private keys, as well as secure
	associations within a domain, thus avoiding the need for a global		associations within a domain, thus avoiding the need for a global
	user-level PKI.		user-level PKI.
	This initial message exchange is used to exchange Host Identities		This initial message exchange is used to exchange Host Identities
	between the end points within the SDP payload.		between the end points within the SDP payload.
	Subsequently, when both user agents Alice and Bob communicate		Subsequently, when both user agents Alice and Bob communicate
	skipping to change at page 8, line 32 ¶		skipping to change at page 8, line 34 ¶
	support.		support.
	The security of this approach relies on two properties:		The security of this approach relies on two properties:
	The signaling messages and the data traffic traverse a different		The signaling messages and the data traffic traverse a different
	path. Hence, an adversary needs to be located where it is able to		path. Hence, an adversary needs to be located where it is able to
	see both, the signaling and the the data traffic.		see both, the signaling and the the data traffic.
	The signaling traffic is often protected.		The signaling traffic is often protected.
	3.2 SDP Extension		3.2. SDP Extension
	This document proposes to enhance the SDP [6] 'k' or 'a' parameter.		This document proposes to enhance the SDP [6] 'k' or 'a' parameter.
	The 'k' parameter has the following structure:		The 'k' parameter has the following structure:
	k=<method>:<encryption key>		k=<method>:<encryption key>
	This document defines two new method fields:		This document defines two new method fields:
	k=host-identity:<HIP Host Identity>		k=host-identity:<HIP Host Identity>
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	the mechanisms from [6]/ [7] would be preferred.		the mechanisms from [6]/ [7] would be preferred.
	SDP only deals with media streams and does not have a notion of		SDP only deals with media streams and does not have a notion of
	user or main device in the background. Hence, the SIP HI(T) may		user or main device in the background. Hence, the SIP HI(T) may
	need to go into SIP signaling (rather than be carried in SDP).		need to go into SIP signaling (rather than be carried in SDP).
	Logically, this appears to belong to the 'Contact:' header which		Logically, this appears to belong to the 'Contact:' header which
	may be conveyed protected in an S/MIME body (signed and		may be conveyed protected in an S/MIME body (signed and
	encrypted).		encrypted).
	3.3 Example		3.3. Example
	This example contains the full details of the example session setup		This example contains the full details of the example session setup
	taken from Section 4 of [1]. The message flow is shown in Figure 1		taken from Section 4 of [1]. The message flow is shown in Figure 1
	of [1] and resembles the architecture shown in Figure 1. Note that		of [1] and resembles the architecture shown in Figure 1. Note that
	these flows show the minimum required set of header fields; some		these flows show the minimum required set of header fields; some
	other header fields such as Allow and Supported would normally be		other header fields such as Allow and Supported would normally be
	present.		present.
	In our example Alice uses the following Host Identity Tag		In our example Alice uses the following Host Identity Tag
	(7214148E0433AFE2FA2D48003D31172E) and Bob uses		(7214148E0433AFE2FA2D48003D31172E) and Bob uses
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 7 ¶
	Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG		Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG
	As a result of this exchange, two IPsec SAs (one for each direction)		As a result of this exchange, two IPsec SAs (one for each direction)
	is established. RTP media traffic can be exchanged between the two		is established. RTP media traffic can be exchanged between the two
	end hosts, Alice and Bob, protected by IPsec. If end host mobility		end hosts, Alice and Bob, protected by IPsec. If end host mobility
	takes place then a HIP readdressing exchange takes place which is not		takes place then a HIP readdressing exchange takes place which is not
	detected at the upper layer by UDP/RTP or SIP.		detected at the upper layer by UDP/RTP or SIP.
	4. Security Considerations		4. Security Considerations
	The security considerations currently deal with the proposal of		The standard HIP strategy for authenticating the communicating
	exchanging Host Identities within SIP. A future version of this		parties is to give the Initiator and the Responder a Host Identity
	document will investigate security considerations that address other		and to assure the authenticity of the Host Identity via external
	parts of the interworking as well.		mechanisms, such as DNSSEC (if the Host Identities are stored in the
			DNS). The Initiator then verifies the Host Identity and checks its
			validity. The complexity of ensuring that the Host Identity has not
			been tampered with is pushed to DNS (and DNSSEC), as the only
			mechanism specified for ensuring that the public key is genuine. The
			infrastructure provided for SIP can provide a similar, but more
			deployment friendly, functionality when combined with already
			available SIP security mechanisms.
	This proposal is closely aligned towards the usage of the 'k'		The design described in this document is intended to leverage the
	parameter in SDP [8]. As a difference, an asymmetric key is		authenticity of the signaling channel (while not requiring
			confidentiality). As long as each side of the connection can verify
			the integrity of the SDP INVITE then the HIP base exchange handshake
			cannot be hijacked via a man-in-the-middle attack. This integrity
			protection is easily provided by the caller to the callee via the SIP
			Identity [23] mechanism. However, it is less straightforward for the
			responder.
			Ideally Alice would want to know that Bob's SDP had not been tampered
			with and who it was from so that Alice's User Agent could indicate to
			Alice that there was a secure phone call to Bob. This is known as the
			SIP Response Identity problem and is still a topic of ongoing work in
			the SIP community. When a solution to the SIP Response Identity
			problem is finalized, it SHOULD be used here. In the meantime there
			are several approaches that can be used to mitigate this problem: Use
			UPDATE, Use SIPS, Use S/MIME, and do nothing. Each one is discussed
			here followed by the security implications of that approach.
			4.1. UPDATE
			In this approach, Bob sends an answer, then immediately follows up
			with an UPDATE that includes the Host Identity Tag and uses the SIP
			Identity mechanism to assert that the message is from Bob's. The
			downside of this approach is that it requires the extra round trip of
			the UPDATE. However, it is simple and secure even when the proxies
			are not trusted.
			4.2. SIPS
			In this approach, the signaling is protected by TLS from hop to hop.
			As long as all proxies are trusted, this provides integrity for the
			Host Identity Tag. It does not provide a strong assertion of who
			Alice is communicating with. However, as much as the target domain
			can be trusted to correctly populate the From header field value,
			Alice can use that. The security issue with this approach is that if
			one of the Proxies wished to mount a man-in-the-middle attack, it
			could convince Alice that she was talking to Bob when really the
			media was flowing through a man in the middle media relay. However,
			this attack could not convince Bob that he was taking to Alice.
			4.3. S/MIME
			RFC 3261 [1] defines a S/MIME security mechanism for SIP that could
			be used to sign that the fingerprint was from Bob. This would be
			secure. However, so far there have been no deployments of S/MIME for
			SIP.
			4.4. Single-sided Verification
			In this approach, no integrity is provided for the fingerprint from
			Bob to Alice. In this approach, an attacker that was on the
			signaling path could tamper with the fingerprint and insert
			themselves as a man-in-the-middle on the media. Alice would know
			that she had a secure call with someone but would not know if it was
			with Bob or a man-in-the-middle. Bob would know that an attack was
			happening. The fact that one side can detect this attack means that
			in most cases where Alice and Bob both wish the communications to be
			encrypted there is not a problem. Keep in mind that in any of the
			possible approaches Bob could always reveal the media that was
			received to anyone. We are making the assumption that Bob also wants
			secure communications. In this do nothing case, Bob knows the media
			has not been tampered with or intercepted by a third party and that
			it is from Alice. Alice knows that she is talking to someone and
			that whoever that is has probably checked that the media is not being
			intercepted or tampered with. This approach is certainly less than
			ideal but very usable for many situations. An alternative available
			to Alice and Bob is to use human speech to verified each others'
			identity then verify each others' Host Identity Tags also using human
			speech. Assuming that it is difficult to impersonate another's
			speech and seamlessly modify the audio contents of a call, this
			approach is relatively safe. On the other hand, SIP is not only used
			for voice communication.
			Note that this proposal is closely aligned towards the usage of the
			'k' parameter in SDP [8]. As a difference, an asymmetric key is
	exchanged unlike the proposals illustrated in Section 6 of [8].		exchanged unlike the proposals illustrated in Section 6 of [8].
	Section 5.12 of [22] is relevant for this discussion.		Section 5.12 of [22] is relevant for this discussion.
	If an adversary aims to impersonate one of the SIP UAs in the
	subsequent HIP exchange then it is necessary to replace the Host
	Identity/Host Identity Tag exchanged in the SIP/SDP messages.
	Please note that this approach is in a certain sense a re-		Please note that this approach is in a certain sense a re-
	instantiation of the Purpose-Built-Key (PBK) idea (see [23]). With		instantiation of the Purpose-Built-Key (PBK) idea (see [24]). With
	PBK a hash of a public key is sent from node A to node B. If there		PBK a hash of a public key is sent from node A to node B. If there
	was no adversary between A and B at that time to modify the		was no adversary between A and B at that time to modify the
	transmitted hash value then subsequent communication interactions		transmitted hash value then subsequent communication interactions
	which use the public key are secure. This proposal reuses the same		which use the public key are secure. This proposal reuses the same
	idea but focuses on the interworking between different protocols. In		idea but focuses on the interworking between different protocols. In
	fact it would be possible to use the same approach to exchange the		fact it would be possible to use the same approach to exchange the
	hash of an S/MIME certificate which can later be used in subsequent		hash of an S/MIME certificate which can later be used in subsequent
	SIP signaling message exchanges.		SIP signaling message exchanges.
	If Host Identities for HIP can be retrieved using a different, more		5. IANA Considerations
	secure method then the Host Identities exchanged with SIP/SDP MUST
	NOT be used.
	5. Open Issues
	The authors came accross a number of open issues while thinking about
	this topic:
	o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute
	Host Identities. This approach is particularly interesting, if
	Host Identities are subject to frequent change. As such, it would
	resemble the proposal provided with SIPPING-CERT [24]. Thereby
	the user agent would be allowed to upload its own Host Identity to
	the Credential Server. Other user agents would use the SUBSCRIBE
	method to retrieve Host Identities of a particular user. With the
	help of the NOTIFY message it is possible to learn about a changed
	Host Identity (e.g., a revoked HI). It is for further study
	whether this is more useful than the already described proposal.
	o Is an IANA registration for the method field required?
	o Is it possible to carry more than one Host Identity/Host Identity		[Editor's Note: A future version of this document will provide a
	Tag in the SDP payload by listing more than one 'k' parameter?		discussion about IANA considerations.]
	o Further investigations are required with regard to the mobility		6. Open Issues
	functionality provided by HIP and the potential benefits for end-
	to-end signaling using SIP, RTP etc. between the SIP UAs.
	o Middlebox traversal functionality discussed in the context of HIP		A list of open issues can be found at:
	(such as STUN, TURN, ICE) could potentially be replaced by the HIP		http://www.tschofenig.com:8080/sip-hip/
	middlebox traversal functionality.
	6. Contributors		7. Contributors
	We would like to thank Vesa Torvinen for his contributions to the		We would like to thank Vesa Torvinen for his contributions to the
	initial version of this document.		initial version of this document.
	7. Acknowledgments		8. Acknowledgments
	The authors would like to thank Steffen Fries, Aarthi Nagarajan,		The authors would like to thank Steffen Fries, Aarthi Nagarajan,
	Murugaraj Shanmugam, Franz Muenz, Jochen Grimminger and Joachim Kross		Murugaraj Shanmugam, Franz Muenz, Jochen Grimminger and Joachim Kross
	for their feedback.		for their feedback.
	8. References		The content of the security consideration section is based on DTLS-
			SIP.
	8.1 Normative References		9. References
			9.1. Normative References
	[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[2] Moskowitz, R., "Host Identity Protocol Architecture",		[2] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	draft-ietf-hip-arch-02 (work in progress), January 2005.		Architecture", draft-ietf-hip-arch-03 (work in progress),
			August 2005.
	[3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03		[3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05
	(work in progress), June 2005.		(work in progress), March 2006.
	[4] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility		[4] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
	using SIP, ACM MC2R", , July 2000.		using SIP, ACM MC2R", , July 2000.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	[6] Andreasen, F., "Session Description Protocol Security		[6] Andreasen, F., "Session Description Protocol Security
	Descriptions for Media Streams",		Descriptions for Media Streams",
	draft-ietf-mmusic-sdescriptions-11 (work in progress),		draft-ietf-mmusic-sdescriptions-12 (work in progress),
	June 2005.		September 2005.
	[7] Arkko, J., "Key Management Extensions for Session Description		[7] Arkko, J., "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-15 (work in progress), June 2005.		draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005.
	[8] Handley, M. and V. Jacobson, "SDP: Session Description		[8] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	8.2 Informative References		9.2. Informative References
	[9] Sparks, R., "The Session Initiation Protocol (SIP) Refer		[9] Sparks, R., "The Session Initiation Protocol (SIP) Refer
	Method", RFC 3515, April 2003.		Method", RFC 3515, April 2003.
	[10] Shacham, R., "Session Initiation Protocol (SIP) Session		[10] Shacham, R., "Session Initiation Protocol (SIP) Session
	Mobility", draft-shacham-sipping-session-mobility-01 (work in		Mobility", draft-shacham-sipping-session-mobility-01 (work in
	progress), July 2005.		progress), July 2005.
	[11] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[11] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", draft-ietf-hip-rvs-03 (work in		Rendezvous Extension", draft-ietf-hip-rvs-04 (work in
	progress), July 2005.		progress), October 2005.
	[12] Nikander, P., "Host Identity Indirection Infrastructure (Hi3)",		[12] Nikander, P., "Host Identity Indirection Infrastructure (Hi3)",
	draft-nikander-hiprg-hi3-00 (work in progress), June 2004.		draft-nikander-hiprg-hi3-00 (work in progress), June 2004.
	[13] Rosenberg, J., "Simple Traversal of UDP Through Network Address		[13] Rosenberg, J., "Simple Traversal of UDP Through Network Address
	Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-01		Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02
	(work in progress), February 2005.		(work in progress), July 2005.
	[14] Rosenberg, J., "Traversal Using Relay NAT (TURN)",		[14] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
	draft-rosenberg-midcom-turn-07 (work in progress),		draft-rosenberg-midcom-turn-08 (work in progress),
	February 2005.		September 2005.
	[15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol		[15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
	(NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),		(NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress),
	May 2005.		February 2006.
	[16] Stiemerling, M., "Middlebox Traversal Issues of Host Identity		[16] Stiemerling, M., "Middlebox Traversal Issues of Host Identity
	Protocol (HIP) Communication", draft-stiemerling-hip-nat-05		Protocol (HIP) Communication", draft-stiemerling-hip-nat-05
	(work in progress), July 2005.		(work in progress), July 2005.
	[17] Tschofenig, H., "NAT and Firewall Traversal for HIP",		[17] Tschofenig, H. and M. Shanmugam, "Traversing HIP-aware NATs and
	draft-tschofenig-hiprg-hip-natfw-traversal-01 (work in		Firewalls: Problem Statement and Requirements",
	progress), February 2005.		draft-tschofenig-hiprg-hip-natfw-traversal-03 (work in
			progress), October 2005.
	[18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A		[18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
	Methodology for Network Address Translator (NAT) Traversal for		Methodology for Network Address Translator (NAT) Traversal for
	Multimedia Session Establishment Protocols",		Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in
	draft-ietf-mmusic-ice-04 (work in progress), February 2005.		progress), October 2005.
	[19] Jokela, P., "Using ESP transport format with HIP",		[19] Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-00 (work in progress), July 2005.		draft-ietf-hip-esp-02 (work in progress), March 2006.
	[20] Tschofenig, H., "Using SRTP transport format with HIP",		[20] Tschofenig, H., "Using SRTP transport format with HIP",
	draft-tschofenig-hiprg-hip-srtp-00 (work in progress),		draft-tschofenig-hiprg-hip-srtp-01 (work in progress),
	July 2005.		October 2005.
	[21] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.		[21] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
	Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,		Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
	August 2004.		August 2004.
	[22] Handley, M., "SDP: Session Description Protocol",		[22] Handley, M., "SDP: Session Description Protocol",
	draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005.		draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
	[23] Bradner, S., Mankin, A., and J. Schiller, "A Framework for		[23] Peterson, J. and C. Jennings, "Enhancements for Authenticated
			Identity Management in the Session Initiation Protocol (SIP)",
			draft-ietf-sip-identity-06 (work in progress), October 2005.
			[24] Bradner, S., Mankin, A., and J. Schiller, "A Framework for
	Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in		Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in
	progress), June 2003.		progress), June 2003.
	[24] Jennings, C. and J. Peterson, "Certificate Management Service		[25] Jennings, C. and J. Peterson, "Certificate Management Service
	for The Session Initiation Protocol (SIP)",		for The Session Initiation Protocol (SIP)",
	draft-ietf-sipping-certs-01 (work in progress), February 2005.		draft-ietf-sipping-certs-02 (work in progress), July 2005.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Joerg Ott		Joerg Ott
	Universitaet Bremen		Helsinki University of Technology
	Bibliothekstr. 1		Otakaari 5A
	Bremen 28359		Espoo FI-02150
	Germany		Finland
	Email: jo@tzi.org		Email: jo@netlab.hut.fi
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	USA		USA
	Phone: +1 212 939 7042		Phone: +1 212 939 7042
	Email: schulzrinne@cs.columbia.edu		Email: schulzrinne@cs.columbia.edu
	skipping to change at page 27, line 41 ¶		skipping to change at page 31, line 41 ¶
	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.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). 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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 46 change blocks.
	103 lines changed or deleted		173 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/