< draft-tschofenig-hiprg-host-identities-00.txt		draft-tschofenig-hiprg-host-identities-01.txt >
	HIPRG H. Tschofenig		HIPRG H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: April 18, 2005 V. Torvinen		Expires: April 4, 2005 J. Ott
	Ericsson
	J. Ott
	Universitaet Bremen		Universitaet Bremen
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia U.
	T. Henderson		T. Henderson
	The Boeing Company		The Boeing Company
	G. Camarillo		G. Camarillo
	Ericsson		Ericsson
	October 18, 2004		October 2004
	Exchanging Host Identities in SIP		Exchanging Host Identities in SIP
	draft-tschofenig-hiprg-host-identities-00.txt		draft-tschofenig-hiprg-host-identities-01.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 aware have been disclosed,		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any 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 become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		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 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 April 18, 2005.		This Internet-Draft will expire on April 4, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document proposes to exchange Host Identities (or Host Identity		This document proposes to exchange Host Identities (or Host Identity
	Tags) in SIP/SDP for later usage in the Host Identity Protocol		Tags) in SIP/SDP for later usage in the Host Identity Protocol
	Protocol (HIP) between the SIP user agents. As such, it is a first		Protocol (HIP) between the SIP user agents. As such, it is a first
	step in investigating the interaction between SIP and HIP and mainly		step in investigating the interaction between SIP and HIP and mainly
	a discussion document.		a discussion document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . . . 6		2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 16		4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17		5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.2 Informative References . . . . . . . . . . . . . . . . . . . 19		8.1 Normative References . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20		8.2 Informative References . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
			Intellectual Property and Copyright Statements . . . . . . . . 24
	1. Introduction		1. Introduction
	SIP [1] allows to establish and maintain sessions between two user		SIP [1] allows to establish and maintain sessions between two user
	agents. The communication typically involves SIP proxies before		agents. The communication typically involves SIP proxies before
	direct communication between the end points takes place. As part of		direct communication between the end points takes place. As part of
	the initial communication exchange a number of parameters are		the initial communication exchange a number of parameters are
	exchanged including security relevant parameters, such as keying		exchanged including security relevant parameters, such as keying
	material and cryptographic information to establish a security		material and cryptographic information to establish a security
	association for subsequent data traffic protection.		association for subsequent data traffic protection.
	HIP (see [2] and [3]) creates an architecture with a new,		HIP (see [2] and [3]) creates an architecture with a new,
	cryptographic namespace and a new layer between the network and the		cryptographic namespace and a new layer between the network and the
	transport layer to shield applications from the impact of		transport layer to shield applications from the impact of multi-
	multi-homing, readdressing and mobility. A protocol, the Host		homing, readdressing and mobility. A protocol, the Host Identity
	Identity Protocol, is used to establish state at the two end hosts.		Protocol, is used to establish state at the two end hosts. This
	This state includes the establishment of IPsec SAs.		state includes the establishment of IPsec SAs.
	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
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	+-----------+ 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. Furthermore, SIP end-to-end security mechanisms are also
	available with S/MIME.		available with S/MIME.
	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
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	If the SIP communication does not involve third parties (i.e., SIP		If the SIP communication does not involve third parties (i.e., SIP
	proxies) and is therefore executed directly between the two SIP UAs		proxies) and is therefore executed directly between the two SIP UAs
	then it is not useful to exchange Host Identities in the SDP payloads		then it is not useful to exchange Host Identities in the SDP payloads
	since the HIP exchange already took place before the first SIP		since the HIP exchange already took place before the first SIP
	message can be exchanged between the two peers. Still HIP might		message can be exchanged between the two peers. Still HIP might
	provide some advantages for the end-to-end communication, such as		provide some advantages for the end-to-end communication, such as
	providing security at the lower layer and mobility and multi-homing		providing security at the lower layer and mobility and multi-homing
	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.
	2. SDP Extension		2. SDP Extension
	This document proposes to enhance the SDP [4] 'k' parameter.		This document proposes to enhance the SDP [4] 'k' parameter.
	This parameter has the following structure: k=<method><encryption		This parameter has the following structure: k=<method><encryption
	key>. This document defines two new method fields:		key>. This document defines two new method fields:
	k=host-identity:<HIP Host Identity>		k=host-identity:<HIP Host Identity>
	k=host-identity-tag:<hash of the public key>		k=host-identity-tag:<hash of the public key>
	Both, the Host Identity and the Host Identity Tag are defined in [3].		Both, the Host Identity and the Host Identity Tag are defined in [3].
	The Host Identity contains the public key and a number of		The Host Identity contains the public key and a number of
	cryptographic parameters (such as used algorithms and Diffie-Hellmann		cryptographic parameters (such as used algorithms and Diffie-Hellmann
	public parameters). The Host Identity is base64 encoded.		public parameters). The Host Identity is base64 encoded.
	FOR DISCUSSION:		FOR DISCUSSION:
	The usage of the k parameter as defined in [5] is deprecated. [4]		The usage of the k parameter as defined in [5] is deprecated. [4]
	is more appropriate but like 'k=', they come with the caveat that		is more appropriate but like 'k=', they come with the caveat that
	they require a secured e2e signaling path (or SDP is S/MIME		they require a secured e2e signaling path (or SDP is S/MIME
	protected). One alternative is the usage of MIKEY for the		protected). One alternative is the usage of MIKEY for the
	exchange as defined in [6].		exchange as defined in [6].
	Furthermore, and probably more important, it is important to said		Furthermore, and probably more important, it is important to said
	what the Host Identity is supposed to be used with. They may help		what the Host Identity is supposed to be used with. They may help
	avoiding re-INVITEs when underlying IP addresses change to update		avoiding re-INVITEs when underlying IP addresses change to update
	the 'Contact:' address as well as the addresses in the 'c=' lines		the 'Contact:' address as well as the addresses in the 'c=' lines
	for the various media.		for the various media.
	skipping to change at page 16, line 16 ¶		skipping to change at page 17, line 16 ¶
	This proposal is closely aligned towards the usage of the 'k'		This proposal is closely aligned towards the usage of the 'k'
	parameter in SDP [5]. As a difference, an asymmetric key is		parameter in SDP [5]. As a difference, an asymmetric key is
	exchanged unlike the proposals illustrated in Section 6 of [5].		exchanged unlike the proposals illustrated in Section 6 of [5].
	Section 5.12 of [8] is relevant for this discussion.		Section 5.12 of [8] is relevant for this discussion.
	If an adversary aims to impersonate one of the SIP UAs in the		If an adversary aims to impersonate one of the SIP UAs in the
	subsequent HIP exchange then it is necessary to replace the Host		subsequent HIP exchange then it is necessary to replace the Host
	Identity/Host Identity Tag exchanged in the SIP/SDP messages.		Identity/Host Identity Tag exchanged in the SIP/SDP messages.
	Please note that this approach is in a certain sense a		Please note that this approach is in a certain sense a re-
	re-instantiation of the Purpose-Built-Key (PBK) idea (see [9]). With		instantiation of the Purpose-Built-Key (PBK) idea (see [9]). 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		If Host Identities for HIP can be retrieved using a different, more
	secure method then the Host Identities exchanged with SIP/SDP MUST		secure method then the Host Identities exchanged with SIP/SDP MUST
	skipping to change at page 17, line 19 ¶		skipping to change at page 18, line 20 ¶
	o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute		o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute
	Host Identities. This approach is particularly interesting, if		Host Identities. This approach is particularly interesting, if
	Host Identities are subject to frequent change. As such, it would		Host Identities are subject to frequent change. As such, it would
	resemble the proposal provided with SIPPING-CERT [10]. Thereby		resemble the proposal provided with SIPPING-CERT [10]. Thereby
	the user agent would be allowed to upload its own Host Identity to		the user agent would be allowed to upload its own Host Identity to
	the Credential Server. Other user agents would use the SUBSCRIBE		the Credential Server. Other user agents would use the SUBSCRIBE
	method to retrieve Host Identities of a particular user. With the		method to retrieve Host Identities of a particular user. With the
	help of the NOTIFY message it is possible to learn about a changed		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		Host Identity (e.g., a revoked HI). It is for further study
	whether this is more useful than the already described proposal.		whether this is more useful than the already described proposal.
	o Is an IANA registration for the method field required?		o Is an IANA registration for the method field required?
	o Is it possible to carry more than one Host Identity/Host Identity		o Is it possible to carry more than one Host Identity/Host Identity
	Tag in the SDP payload by listing more than one 'k' parameter?		Tag in the SDP payload by listing more than one 'k' parameter?
	o Further investigations are required with regard to the mobility		o Further investigations are required with regard to the mobility
	functionality provided by HIP and the potential benefits for		functionality provided by HIP and the potential benefits for end-
	end-to-end signaling using SIP, RTP etc. between the SIP UAs.		to-end signaling using SIP, RTP etc. between the SIP UAs.
	o Middlebox traversal functionality discussed in the context of HIP		o Middlebox traversal functionality discussed in the context of HIP
	(such as STUN, TURN, ICE) could potentially be replaced by the HIP		(such as STUN, TURN, ICE) could potentially be replaced by the HIP
	middlebox traversal functionality.		middlebox traversal functionality.
	6. Acknowledgments		6. Contributors
			We would like to thank Vesa Torvinen for his contributions to the
			initial version of this document.
			7. 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.
	7. References		8. References
	7.1 Normative References		8.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., "Host Identity Protocol Architecture",
	draft-moskowitz-hip-arch-06 (work in progress), June 2004.		draft-moskowitz-hip-arch-06 (work in progress), June 2004.
	[3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00		[3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00
	(work in progress), June 2004.		(work in progress), June 2004.
	[4] Andreasen, F., Baugher, M. and D. Wing, "Session Description		[4] Andreasen, F., Baugher, M., and D. Wing, "Session Description
	Protocol Security Descriptions for Media Streams",		Protocol Security Descriptions for Media Streams",
	draft-ietf-mmusic-sdescriptions-07 (work in progress), July		draft-ietf-mmusic-sdescriptions-07 (work in progress),
	2004.		July 2004.
	[5] Handley, M. and V. Jacobson, "SDP: Session Description		[5] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[6] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K.		[6] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
	Norrman, "Key Management Extensions for Session Description		Norrman, "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-11 (work in progress), April 2004.		draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004.
	[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	7.2 Informative References		8.2 Informative References
	[8] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session		[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in		Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in
	progress), September 2004.		progress), September 2004.
	[9] Bradner, S., Mankin, A. and J. Schiller, "A Framework for		[9] 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.
	[10] Jennings, C., "Certificate Management Service for SIP",		[10] Jennings, C., "Certificate Management Service for SIP",
	draft-jennings-sipping-certs-04 (work in progress), July 2004.		draft-jennings-sipping-certs-04 (work in progress), July 2004.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bavaria 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Vesa Torvinen
	Ericsson
	Joukahaisenkatu 1
	Turku 20520
	Finland
	EMail: vesa.torvinen@ericsson.com
	Joerg Ott		Joerg Ott
	Universitaet Bremen		Universitaet Bremen
	Bibliothekstr. 1		Bibliothekstr. 1
	Bremen 28359		Bremen 28359
	Germany		Germany
	EMail: jo@tzi.org		Email: jo@tzi.org
	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
	URI: http://www.cs.columbia.edu/~hgs		URI: http://www.cs.columbia.edu/~hgs
	Thomas R. Henderson		Thomas R. Henderson
	The Boeing Company		The Boeing Company
	P.O. Box 3707		P.O. Box 3707
	Seattle, WA		Seattle, WA
	USA		USA
	EMail: thomas.r.henderson@boeing.com		Email: thomas.r.henderson@boeing.com
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: Gonzalo.Camarillo@ericsson.com		Email: Gonzalo.Camarillo@ericsson.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 36 change blocks.
	57 lines changed or deleted		63 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/