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/