draft-ietf-hip-base-09.txt		draft-ietf-hip-base-10.txt
	Network Working Group R. Moskowitz		Network Working Group R. Moskowitz
	Internet-Draft ICSAlabs, a Division of TruSecure		Internet-Draft ICSAlabs, a Division of TruSecure
	Expires: April 4, 2008 Corporation		Expires: May 2, 2008 Corporation
	P. Nikander		P. Nikander
	P. Jokela (editor)		P. Jokela (editor)
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	T. Henderson		T. Henderson
	The Boeing Company		The Boeing Company
	October 2, 2007		October 30, 2007
	Host Identity Protocol		Host Identity Protocol
	draft-ietf-hip-base-09		draft-ietf-hip-base-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 4, 2008.		This Internet-Draft will expire on May 2, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This memo specifies the details of the Host Identity Protocol (HIP).		This memo specifies the details of the Host Identity Protocol (HIP).
	HIP allows consenting hosts to securely establish and maintain shared		HIP allows consenting hosts to securely establish and maintain shared
	IP-layer state, allowing separation of the identifier and locator		IP-layer state, allowing separation of the identifier and locator
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12		4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
	4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13		4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13
	4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14		4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14
	4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15		4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15
	4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16		4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16
	4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17		4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17
	4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17		4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17
	4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19		4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19
	4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 20		4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 20
	4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 20		4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 21
	4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 21		4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 22
	4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22		4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22
	4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29		4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29
	4.5. User Data Considerations . . . . . . . . . . . . . . . . 31		4.5. User Data Considerations . . . . . . . . . . . . . . . . 31
	4.5.1. TCP and UDP Pseudo-header Computation for User Data . 31		4.5.1. TCP and UDP Pseudo-header Computation for User Data . 31
	4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 31		4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 31
	4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 31		4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 31
	4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 31		4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 31
	4.6. Certificate Distribution . . . . . . . . . . . . . . . . 32		4.6. Certificate Distribution . . . . . . . . . . . . . . . . 32
	5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 33		5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 33
	5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 33		5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 33
	skipping to change at page 4, line 35		skipping to change at page 4, line 35
	6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 87		6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 87
	6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88		6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88
	6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88		6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88
	7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89		7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 90		8. Security Considerations . . . . . . . . . . . . . . . . . . . 90
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
	11.1. Normative References . . . . . . . . . . . . . . . . . . 96		11.1. Normative References . . . . . . . . . . . . . . . . . . 96
	11.2. Informative References . . . . . . . . . . . . . . . . . 97		11.2. Informative References . . . . . . . . . . . . . . . . . 97
	Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 99		Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 100
	Appendix B. Generating a Public Key Encoding from a HI . . . . . 101		Appendix B. Generating a Public Key Encoding from a HI . . . . . 102
	Appendix C. Example Checksums for HIP Packets . . . . . . . . . 102		Appendix C. Example Checksums for HIP Packets . . . . . . . . . 103
	C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 102		C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 103
	C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 102		C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 103
	C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 102		C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 103
	Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 104		Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 105
	Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 105		Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 106
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107
	Intellectual Property and Copyright Statements . . . . . . . . . 107		Intellectual Property and Copyright Statements . . . . . . . . . 108
	1. Introduction		1. Introduction
	This memo specifies the details of the Host Identity Protocol (HIP).		This memo specifies the details of the Host Identity Protocol (HIP).
	A high-level description of the protocol and the underlying		A high-level description of the protocol and the underlying
	architectural thinking is available in the separate HIP architecture		architectural thinking is available in the separate HIP architecture
	description [I-D.ietf-hip-arch]. Briefly, the HIP architecture		description [I-D.ietf-hip-arch]. Briefly, the HIP architecture
	proposes an alternative to the dual use of IP addresses as "locators"		proposes an alternative to the dual use of IP addresses as "locators"
	(routing labels) and "identifiers" (endpoint, or host, identifiers).		(routing labels) and "identifiers" (endpoint, or host, identifiers).
	In HIP, public cryptographic keys, of a public/private key pair, are		In HIP, public cryptographic keys, of a public/private key pair, are
	skipping to change at page 18, line 23		skipping to change at page 18, line 23
	o The actual locators may later change if an UPDATE message is used,		o The actual locators may later change if an UPDATE message is used,
	even if from the API perspective the session still appears to be		even if from the API perspective the session still appears to be
	between specific locators. The locator update is still secure,		between specific locators. The locator update is still secure,
	however, and the session is still between the same nodes.		however, and the session is still between the same nodes.
	o Different sessions between the same locators may result in		o Different sessions between the same locators may result in
	connections to different nodes, if the implementation no longer		connections to different nodes, if the implementation no longer
	remembers which identifier the peer had in another session. This		remembers which identifier the peer had in another session. This
	is possible when the peer's locator has changed for legitimate		is possible when the peer's locator has changed for legitimate
	reasons or when an attacker pretends to be a node that has the		reasons or when an attacker pretends to be a node that has the
	peer's locator.		peer's locator. Therefore, when using opportunistic mode, HIP
			MUST NOT place any expectation that the peer's HI returned in the
			R1 message matches any HI previously seen from that address.
	If the HIP implementation and application do not have the same		If the HIP implementation and application do not have the same
	understanding of what constitutes a session, this may even happen		understanding of what constitutes a session, this may even happen
	within the same session. For instance, an implementation may not		within the same session. For instance, an implementation may not
	know when HIP state can be purged for UDP based applications.		know when HIP state can be purged for UDP based applications.
			o As with all HIP exchanges, the handling of locator-based or
			interface-based policy is unclear for opportunistic mode HIP. An
			application may make a connection to a specific locator because
			the application has knowledge of the security properties along the
			network to that locator. If one of the nodes moves and the
			locators are updated, these security properties may not be
			maintained. Depending on the security policy of the application,
			this may be a problem. This is an area of ongoing study. As an
			example, there is work to create an API that applications can use
			to specify their security requirements in a similar context
			[I-D.ietf-btns-c-api].
	In addition, the following security considerations apply. The		In addition, the following security considerations apply. The
	generation counter mechanism will be less efficient in protecting		generation counter mechanism will be less efficient in protecting
	against replays of the R1 packet, given that the responder can choose		against replays of the R1 packet, given that the responder can choose
	a replay that uses any HI, not just the one given in the I1 packet.		a replay that uses any HI, not just the one given in the I1 packet.
	More importantly, the opportunistic exchange is vulnerable to man-in-		More importantly, the opportunistic exchange is vulnerable to man-in-
	the-middle attacks, because the initiator does not have any public		the-middle attacks, because the initiator does not have any public
	key information about the peer. To assess the impacts of this		key information about the peer. To assess the impacts of this
	vulnerability, we compare it to vulnerabilities in current, non-HIP		vulnerability, we compare it to vulnerabilities in current, non-HIP
	capable communications.		capable communications.
	skipping to change at page 97, line 23		skipping to change at page 97, line 23
	for Overlay Routable Cryptographic Hash Identifiers		for Overlay Routable Cryptographic Hash Identifiers
	(ORCHID)", RFC 4843, April 2007.		(ORCHID)", RFC 4843, April 2007.
	[I-D.ietf-radext-rfc2486bis]		[I-D.ietf-radext-rfc2486bis]
	Aboba, B., "The Network Access Identifier",		Aboba, B., "The Network Access Identifier",
	draft-ietf-radext-rfc2486bis-06 (work in progress),		draft-ietf-radext-rfc2486bis-06 (work in progress),
	July 2005.		July 2005.
	[I-D.ietf-hip-esp]		[I-D.ietf-hip-esp]
	Jokela, P., "Using ESP transport format with HIP",		Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-05 (work in progress), February 2007.		draft-ietf-hip-esp-06 (work in progress), June 2007.
	[FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.		[FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
	11.2. Informative References		11.2. Informative References
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
	skipping to change at page 98, line 16		skipping to change at page 98, line 16
	[I-D.henderson-hip-applications]		[I-D.henderson-hip-applications]
	Henderson, T. and P. Nikander, "Using HIP with Legacy		Henderson, T. and P. Nikander, "Using HIP with Legacy
	Applications", draft-henderson-hip-applications-03 (work		Applications", draft-henderson-hip-applications-03 (work
	in progress), May 2006.		in progress), May 2006.
	[I-D.ietf-hip-mm]		[I-D.ietf-hip-mm]
	Henderson, T., "End-Host Mobility and Multihoming with the		Henderson, T., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-05 (work in		Host Identity Protocol", draft-ietf-hip-mm-05 (work in
	progress), March 2007.		progress), March 2007.
			[I-D.ietf-btns-c-api]
			Komu, M., "IPsec Application Programming Interfaces",
			draft-ietf-btns-c-api-01 (work in progress), July 2007.
	[I-D.ietf-hip-dns]		[I-D.ietf-hip-dns]
	Nikander, P. and J. Laganier, "Host Identity Protocol		Nikander, P. and J. Laganier, "Host Identity Protocol
	(HIP) Domain Name System (DNS) Extensions",		(HIP) Domain Name System (DNS) Extensions",
	draft-ietf-hip-dns-09 (work in progress), April 2007.		draft-ietf-hip-dns-09 (work in progress), April 2007.
	[I-D.ietf-hip-rvs]		[I-D.ietf-hip-rvs]
	Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", draft-ietf-hip-rvs-05 (work in		Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
	progress), June 2006.		progress), June 2006.
End of changes. 10 change blocks.
	18 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/