--- 1/draft-ietf-hip-base-09.txt 2007-10-30 14:12:06.000000000 +0100 +++ 2/draft-ietf-hip-base-10.txt 2007-10-30 14:12:06.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group R. Moskowitz Internet-Draft ICSAlabs, a Division of TruSecure -Expires: April 4, 2008 Corporation +Expires: May 2, 2008 Corporation P. Nikander P. Jokela (editor) Ericsson Research NomadicLab T. Henderson The Boeing Company - October 2, 2007 + October 30, 2007 Host Identity Protocol - draft-ietf-hip-base-09 + draft-ietf-hip-base-10 Status of this Memo By submitting this Internet-Draft, each 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,21 +28,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The IETF Trust (2007). Abstract This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator @@ -72,22 +72,22 @@ 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14 4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17 4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 20 - 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 20 - 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 21 + 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 21 + 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 22 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29 4.5. User Data Considerations . . . . . . . . . . . . . . . . 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.3. Transport Formats . . . . . . . . . . . . . . . . . . 31 4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 31 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 32 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 33 @@ -160,30 +160,30 @@ 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 87 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.2. Informative References . . . . . . . . . . . . . . . . . 97 - Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 99 - Appendix B. Generating a Public Key Encoding from a HI . . . . . 101 - Appendix C. Example Checksums for HIP Packets . . . . . . . . . 102 - C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 102 - C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 102 - C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 102 - Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 104 - Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 105 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 - Intellectual Property and Copyright Statements . . . . . . . . . 107 + Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 100 + Appendix B. Generating a Public Key Encoding from a HI . . . . . 102 + Appendix C. Example Checksums for HIP Packets . . . . . . . . . 103 + C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 103 + C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 103 + C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 103 + Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 105 + Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 106 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107 + Intellectual Property and Copyright Statements . . . . . . . . . 108 1. Introduction This memo specifies the details of the Host Identity Protocol (HIP). A high-level description of the protocol and the underlying architectural thinking is available in the separate HIP architecture description [I-D.ietf-hip-arch]. Briefly, the HIP architecture proposes an alternative to the dual use of IP addresses as "locators" (routing labels) and "identifiers" (endpoint, or host, identifiers). In HIP, public cryptographic keys, of a public/private key pair, are @@ -729,27 +729,41 @@ 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 between specific locators. The locator update is still secure, however, and the session is still between the same nodes. o Different sessions between the same locators may result in connections to different nodes, if the implementation no longer remembers which identifier the peer had in another session. This is possible when the peer's locator has changed for legitimate 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 understanding of what constitutes a session, this may even happen within the same session. For instance, an implementation may not 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 generation counter mechanism will be less efficient in protecting 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. More importantly, the opportunistic exchange is vulnerable to man-in- the-middle attacks, because the initiator does not have any public key information about the peer. To assess the impacts of this vulnerability, we compare it to vulnerabilities in current, non-HIP capable communications. @@ -4107,21 +4122,21 @@ for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. [I-D.ietf-radext-rfc2486bis] Aboba, B., "The Network Access Identifier", draft-ietf-radext-rfc2486bis-06 (work in progress), July 2005. [I-D.ietf-hip-esp] 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. 11.2. Informative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. @@ -4149,20 +4164,24 @@ [I-D.henderson-hip-applications] Henderson, T. and P. Nikander, "Using HIP with Legacy Applications", draft-henderson-hip-applications-03 (work in progress), May 2006. [I-D.ietf-hip-mm] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-05 (work in 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] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-ietf-hip-dns-09 (work in progress), April 2007. [I-D.ietf-hip-rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-05 (work in progress), June 2006.