--- 1/draft-ietf-hip-base-00.txt 2006-02-04 23:25:22.000000000 +0100 +++ 2/draft-ietf-hip-base-01.txt 2006-02-04 23:25:22.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group R. Moskowitz Internet-Draft ICSAlabs, a Division of TruSecure -Expires: December 10, 2004 Corporation +Expires: April 25, 2005 Corporation P. Nikander P. Jokela (editor) Ericsson Research NomadicLab T. Henderson The Boeing Company - June 11, 2004 + October 25, 2004 Host Identity Protocol - draft-ietf-hip-base-00 + draft-ietf-hip-base-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -27,21 +27,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 December 10, 2004. + This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. @@ -63,155 +63,156 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 A new name space and identifiers . . . . . . . . . . . . . 5 1.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . 7 3. Host Identifier (HI) and its representations . . . . . . . . 8 3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 3.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . 9 - 3.2 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 10 - 3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 10 - 4. Host Identity Protocol . . . . . . . . . . . . . . . . . . . 12 - 4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 12 - 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . 13 - 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . 15 - 4.1.3 HIP replay protection . . . . . . . . . . . . . . . . 16 - 4.2 TCP and UDP pseudo-header computation . . . . . . . . . . 17 - 4.3 Updating a HIP association . . . . . . . . . . . . . . . . 17 - 4.4 Error processing . . . . . . . . . . . . . . . . . . . . . 17 - 4.5 Bootstrap support . . . . . . . . . . . . . . . . . . . . 18 - 4.6 Certificate distribution . . . . . . . . . . . . . . . . . 18 - 4.7 Sending data on HIP packets . . . . . . . . . . . . . . . 18 - 5. HIP protocol overview . . . . . . . . . . . . . . . . . . . 19 - 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 19 - 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 20 - 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 20 - 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 21 - 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . 21 - 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . 21 - 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . 24 - 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 26 - 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 26 - 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . 27 - 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . 27 - 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 28 - 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . 29 - 6.2.2 Defining new parameters . . . . . . . . . . . . . . . 30 - 6.2.3 SPI . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 6.2.4 R1_COUNTER . . . . . . . . . . . . . . . . . . . . . . 32 - 6.2.5 PUZZLE . . . . . . . . . . . . . . . . . . . . . . . . 33 - 6.2.6 SOLUTION . . . . . . . . . . . . . . . . . . . . . . . 34 - 6.2.7 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . 34 - 6.2.8 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 35 - 6.2.9 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 36 - 6.2.10 HOST_ID . . . . . . . . . . . . . . . . . . . . . . 37 - 6.2.11 CERT . . . . . . . . . . . . . . . . . . . . . . . . 38 - 6.2.12 HMAC . . . . . . . . . . . . . . . . . . . . . . . . 39 - 6.2.13 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . 40 - 6.2.14 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . 40 - 6.2.15 NES . . . . . . . . . . . . . . . . . . . . . . . . 41 - 6.2.16 SEQ . . . . . . . . . . . . . . . . . . . . . . . . 42 - 6.2.17 ACK . . . . . . . . . . . . . . . . . . . . . . . . 42 - 6.2.18 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . 43 - 6.2.19 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 44 - 6.2.20 ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 47 - 6.2.21 ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . 47 - 6.3 ICMP messages . . . . . . . . . . . . . . . . . . . . . . 48 - 6.3.1 Invalid Version . . . . . . . . . . . . . . . . . . . 48 + 3.2 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 11 + 3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 11 + 4. Host Identity Protocol . . . . . . . . . . . . . . . . . . . 13 + 4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 13 + 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . 14 + 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . 17 + 4.1.3 HIP replay protection . . . . . . . . . . . . . . . . 18 + 4.2 TCP and UDP pseudo-header computation . . . . . . . . . . 19 + 4.3 Updating a HIP association . . . . . . . . . . . . . . . . 19 + 4.4 Error processing . . . . . . . . . . . . . . . . . . . . . 19 + 4.5 Certificate distribution . . . . . . . . . . . . . . . . . 19 + 4.6 Sending data on HIP packets . . . . . . . . . . . . . . . 20 + 5. HIP protocol overview . . . . . . . . . . . . . . . . . . . 21 + 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 21 + 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 22 + 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 22 + 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 23 + 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . 23 + 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . 23 + 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . 27 + 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 29 + 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . 30 + 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . 30 + 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 31 + 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . 32 + 6.2.2 Defining new parameters . . . . . . . . . . . . . . . 33 + 6.2.3 SPI . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 6.2.4 R1_COUNTER . . . . . . . . . . . . . . . . . . . . . . 35 + 6.2.5 PUZZLE . . . . . . . . . . . . . . . . . . . . . . . . 36 + 6.2.6 SOLUTION . . . . . . . . . . . . . . . . . . . . . . . 37 + 6.2.7 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . 38 + 6.2.8 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 39 + 6.2.9 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 39 + 6.2.10 HOST_ID . . . . . . . . . . . . . . . . . . . . . . 40 + 6.2.11 CERT . . . . . . . . . . . . . . . . . . . . . . . . 41 + 6.2.12 HMAC . . . . . . . . . . . . . . . . . . . . . . . . 42 + 6.2.13 HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 42 + 6.2.14 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . 43 + 6.2.15 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . 44 + 6.2.16 NES . . . . . . . . . . . . . . . . . . . . . . . . 44 + 6.2.17 SEQ . . . . . . . . . . . . . . . . . . . . . . . . 45 + 6.2.18 ACK . . . . . . . . . . . . . . . . . . . . . . . . 46 + 6.2.19 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . 47 + 6.2.20 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 48 + 6.2.21 ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 51 + 6.2.22 ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . 52 + 6.3 ICMP messages . . . . . . . . . . . . . . . . . . . . . . 52 + 6.3.1 Invalid Version . . . . . . . . . . . . . . . . . . . 52 6.3.2 Other problems with the HIP header and packet - structure . . . . . . . . . . . . . . . . . . . . . . 48 - 6.3.3 Unknown SPI . . . . . . . . . . . . . . . . . . . . . 48 - 6.3.4 Invalid Cookie Solution . . . . . . . . . . . . . . . 49 - 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . . 50 - 7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 50 - 7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 51 - 7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 52 - 7.4 R2 - the second HIP responder packet . . . . . . . . . . . 54 - 7.5 UPDATE - the HIP Update Packet . . . . . . . . . . . . . . 54 - 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 55 - 7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 56 - 7.8 NOTIFY - the HIP Notify Packet . . . . . . . . . . . . . . 56 - 7.9 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 57 - 8. Packet processing . . . . . . . . . . . . . . . . . . . . . 58 - 8.1 Processing outgoing application data . . . . . . . . . . . 58 - 8.2 Processing incoming application data . . . . . . . . . . . 59 - 8.3 HMAC and SIGNATURE calculation and verification . . . . . 60 - 8.3.1 HMAC calculation . . . . . . . . . . . . . . . . . . . 60 - 8.3.2 Signature calculation . . . . . . . . . . . . . . . . 60 - 8.4 Initiation of a HIP exchange . . . . . . . . . . . . . . . 61 - 8.4.1 Sending multiple I1s in parallel . . . . . . . . . . . 62 + structure . . . . . . . . . . . . . . . . . . . . . . 53 + 6.3.3 Unknown SPI . . . . . . . . . . . . . . . . . . . . . 53 + 6.3.4 Invalid Cookie Solution . . . . . . . . . . . . . . . 53 + 6.3.5 Non-existing HIP association . . . . . . . . . . . . . 53 + 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . . 54 + 7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 54 + 7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 55 + 7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 56 + 7.4 R2 - the second HIP responder packet . . . . . . . . . . . 58 + 7.5 CER - the HIP Certificate Packet . . . . . . . . . . . . . 58 + 7.6 UPDATE - the HIP Update Packet . . . . . . . . . . . . . . 59 + 7.7 NOTIFY - the HIP Notify Packet . . . . . . . . . . . . . . 60 + 7.8 CLOSE - the HIP association closing packet . . . . . . . . 60 + 7.9 CLOSE_ACK - the HIP closing acknowledgment packet . . . . 61 + 8. Packet processing . . . . . . . . . . . . . . . . . . . . . 62 + 8.1 Processing outgoing application data . . . . . . . . . . . 62 + 8.2 Processing incoming application data . . . . . . . . . . . 63 + 8.3 HMAC and SIGNATURE calculation and verification . . . . . 64 + 8.3.1 HMAC calculation . . . . . . . . . . . . . . . . . . . 64 + 8.3.2 Signature calculation . . . . . . . . . . . . . . . . 64 + 8.4 Initiation of a HIP exchange . . . . . . . . . . . . . . . 65 + 8.4.1 Sending multiple I1s in parallel . . . . . . . . . . . 66 8.4.2 Processing incoming ICMP Protocol Unreachable - messages . . . . . . . . . . . . . . . . . . . . . . . 62 - 8.5 Processing incoming I1 packets . . . . . . . . . . . . . . 62 - 8.5.1 R1 Management . . . . . . . . . . . . . . . . . . . . 63 - 8.5.2 Handling malformed messages . . . . . . . . . . . . . 63 - 8.6 Processing incoming R1 packets . . . . . . . . . . . . . . 64 - 8.6.1 Handling malformed messages . . . . . . . . . . . . . 65 - 8.7 Processing incoming I2 packets . . . . . . . . . . . . . . 66 - 8.7.1 Handling malformed messages . . . . . . . . . . . . . 67 - 8.8 Processing incoming R2 packets . . . . . . . . . . . . . . 67 - 8.9 Dropping HIP associations . . . . . . . . . . . . . . . . 68 - 8.10 Initiating rekeying . . . . . . . . . . . . . . . . . . 68 - 8.11 Processing UPDATE packets . . . . . . . . . . . . . . . 69 - 8.11.1 Processing an UPDATE packet in state ESTABLISHED . . 71 - 8.11.2 Processing an UPDATE packet in state REKEYING . . . 71 - 8.11.3 Leaving REKEYING state . . . . . . . . . . . . . . . 72 - 8.12 Processing BOS packets . . . . . . . . . . . . . . . . . 72 - 8.13 Processing CER packets . . . . . . . . . . . . . . . . . 72 - 8.14 Processing PAYLOAD packets . . . . . . . . . . . . . . . 72 - 8.15 Processing NOTIFY packets . . . . . . . . . . . . . . . 72 - 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . . 73 - 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . . 75 - 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . . 76 - 11.1 ESP Security Associations . . . . . . . . . . . . . . . 76 - 11.2 Updating ESP SAs during rekeying . . . . . . . . . . . . 76 - 11.3 Security Association Management . . . . . . . . . . . . 77 - 11.4 Security Parameter Index (SPI) . . . . . . . . . . . . . 77 - 11.5 Supported Transforms . . . . . . . . . . . . . . . . . . 77 - 11.6 Sequence Number . . . . . . . . . . . . . . . . . . . . 78 - 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 79 - 13. Security Considerations . . . . . . . . . . . . . . . . . . 80 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 82 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 83 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 - 16.1 Normative references . . . . . . . . . . . . . . . . . . . 84 - 16.2 Informative references . . . . . . . . . . . . . . . . . . 85 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 86 - A. API issues . . . . . . . . . . . . . . . . . . . . . . . . . 87 - B. Probabilities of HIT collisions . . . . . . . . . . . . . . 89 - C. Probabilities in the cookie calculation . . . . . . . . . . 90 - D. Using responder cookies . . . . . . . . . . . . . . . . . . 91 - E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . . 94 - F. Example checksums for HIP packets . . . . . . . . . . . . . 95 - F.1 IPv6 HIP example (I1) . . . . . . . . . . . . . . . . . . 95 - F.2 IPv4 HIP packet (I1) . . . . . . . . . . . . . . . . . . . 95 - F.3 TCP segment . . . . . . . . . . . . . . . . . . . . . . . 95 - G. 384-bit group . . . . . . . . . . . . . . . . . . . . . . . 97 - Intellectual Property and Copyright Statements . . . . . . . 98 + messages . . . . . . . . . . . . . . . . . . . . . . . 66 + 8.5 Processing incoming I1 packets . . . . . . . . . . . . . . 67 + 8.5.1 R1 Management . . . . . . . . . . . . . . . . . . . . 67 + 8.5.2 Handling malformed messages . . . . . . . . . . . . . 68 + 8.6 Processing incoming R1 packets . . . . . . . . . . . . . . 68 + 8.6.1 Handling malformed messages . . . . . . . . . . . . . 70 + 8.7 Processing incoming I2 packets . . . . . . . . . . . . . . 70 + 8.7.1 Handling malformed messages . . . . . . . . . . . . . 71 + 8.8 Processing incoming R2 packets . . . . . . . . . . . . . . 72 + 8.9 Dropping HIP associations . . . . . . . . . . . . . . . . 72 + 8.10 Initiating rekeying . . . . . . . . . . . . . . . . . . 72 + 8.11 Processing UPDATE packets . . . . . . . . . . . . . . . 74 + 8.11.1 Processing an UPDATE packet in state ESTABLISHED . . 75 + 8.11.2 Processing an UPDATE packet in state REKEYING . . . 75 + 8.11.3 Leaving REKEYING state . . . . . . . . . . . . . . . 76 + 8.12 Processing CER packets . . . . . . . . . . . . . . . . . 76 + 8.13 Processing NOTIFY packets . . . . . . . . . . . . . . . 76 + 8.14 Processing CLOSE packets . . . . . . . . . . . . . . . . 77 + 8.15 Processing CLOSE_ACK packets . . . . . . . . . . . . . . 77 + 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . . 78 + 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . . 80 + 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . . 81 + 11.1 ESP Security Associations . . . . . . . . . . . . . . . 81 + 11.2 Updating ESP SAs during rekeying . . . . . . . . . . . . 81 + 11.3 Security Association Management . . . . . . . . . . . . 82 + 11.4 Security Parameter Index (SPI) . . . . . . . . . . . . . 82 + 11.5 Supported Transforms . . . . . . . . . . . . . . . . . . 82 + 11.6 Sequence Number . . . . . . . . . . . . . . . . . . . . 83 + 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 84 + 13. Security Considerations . . . . . . . . . . . . . . . . . . 85 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 88 + 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 89 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 + 16.1 Normative references . . . . . . . . . . . . . . . . . . . 90 + 16.2 Informative references . . . . . . . . . . . . . . . . . . 91 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 92 + A. API issues . . . . . . . . . . . . . . . . . . . . . . . . . 93 + B. Probabilities of HIT collisions . . . . . . . . . . . . . . 95 + C. Probabilities in the cookie calculation . . . . . . . . . . 96 + D. Using responder cookies . . . . . . . . . . . . . . . . . . 97 + E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . . 100 + F. Example checksums for HIP packets . . . . . . . . . . . . . 101 + F.1 IPv6 HIP example (I1) . . . . . . . . . . . . . . . . . . 101 + F.2 IPv4 HIP packet (I1) . . . . . . . . . . . . . . . . . . . 101 + F.3 TCP segment . . . . . . . . . . . . . . . . . . . . . . . 101 + G. 384-bit group . . . . . . . . . . . . . . . . . . . . . . . 103 + Intellectual Property and Copyright Statements . . . . . . . 104 1. Introduction The Host Identity Protocol (HIP) provides a rapid exchange of Host Identities between two hosts. The exchange also establishes a pair IPsec Security Associations (SA), to be used with IPsec Encapsulated - Security Payload (ESP) [18]. The HIP protocol is designed to be + Security Payload (ESP) [19]. The HIP protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) attacks, and when used to enable ESP, provides DoS and MitM protection for upper layer protocols, such as TCP and UDP. 1.1 A new name space and identifiers The Host Identity Protocol introduces a new namespace, the Host Identity. The effects of this change are explained in the companion - document, the HIP architecture [20] specification. + document, the HIP architecture [21] specification. There are two main representations of the Host Identity, the full Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a public key and directly represents the Identity. Since there are different public key algorithms that can be used with different key lengths, the HI is not good for using as a packet identifier, or as a index into the various operational tables needed to support HIP. Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes the operational representation. It is 128 bits long and is used in the HIP payloads and to index the corresponding state in the end @@ -246,171 +247,214 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [5]. 3. Host Identifier (HI) and its representations A public key of an asymmetric key pair is used as the Host Identifier (HI). Correspondingly, the host itself is the entity that holds the private key from the key pair. See the HIP architecture - specification [20] for more details about the difference between an + specification [21] for more details about the difference between an identity and the corresponding identifier. - HIP implementations MUST support the Digital Signature Algorithm - (DSA) [13] public key algorithm; other algorithms MAY be supported. - DSA was chosen as the default algorithm due to its small signature - size. + HIP implementations MUST support the Rivest Shamir Adelman (RSA) [14] + public key algorithm, and SHOULD support the Digital Signature + Algorithm (DSA) [13] algorithm; other algorithms MAY be supported. A hash of the HI, the Host Identity Tag (HIT), is used in protocols to represent the Host Identity. The HIT is 128 bits long and has the following three key properties: i) it is the same length as an IPv6 address and can be used in address-sized fields in APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it is computationally hard to find a Host Identity key that matches the HIT), and iii) the probability of HIT collision between two hosts is very low. In many environments, 128 bits is still considered large. For example, currently used IPv4 based applications are constrained with - 32 bit address fields. Thus, a third representation, a 32 bit Local - Scope Identifier (LSI), may be needed. The LSI provides a - compression of the HIT with only a local scope so that it can be - carried efficiently in any application level packet and used in API - calls. LSIs do not have the same properties as HITs (i.e., they are - not self-certifying nor are they as unlikely to collide -- hence - their local scope), and consequently they must be used more - carefully. + 32-bit address fields. Another problem is that the cohabitation of + IPv6 and HIP might require some applications to differentiate an IPv6 + address from a HIT. Thus, a third representation, the Local Scope + Identifier (LSI), may be needed. There are two types of such LSIs: + 32 bits long IPv4-compatible one and 128 bits long IPv6-compatible + one. The LSI provides a compression of the HIT with only a local + scope so that it can be carried efficiently in any application level + packet and used in API calls. LSIs do not have the same properties + as HITs (i.e., they are not self-certifying nor are they as unlikely + to collide -- hence their local scope), and consequently they must be + used more carefully. Finally, HIs, HITs, and LSIs are not carried explicitly in the headers of user data packets. Instead, the IPsec Security Parameter Index (SPI) is used in data packets to index the right host context. The SPIs are selected during the HIP exchange. For user data packets, then, the combination of IPsec SPIs and IP addresses are used indirectly to identify the host context, thereby avoiding an additional explicit protocol header. 3.1 Host Identity Tag (HIT) The Host Identity Tag is a 128 bit value -- a hash of the Host Identifier. There are two advantages of using a hash over the actual Identity in protocols. Firstly, its fixed length makes for easier protocol coding and also better manages the packet size cost of this technology. Secondly, it presents a consistent format to the protocol whatever underlying identity technology is used. There are two types of HITs. HITs of the first type, called *type 1 - HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits - of the SHA-1 hash of the public key. HITs of the second type consist - of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA) - field, and only the last 64 bits come from a SHA-1 hash of the Host + HIT*, consist of 128 bits of the SHA-1 hash of the public key. HITs + of the second type consist of a Host Assigning Authority Field (HAA), + and only the last 64 bits come from a SHA-1 hash of the Host Identity. This latter format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in hierarchical directories, like the DNS. Another use of HAA is in policy controls, see Section 12. + As the type of a HIT cannot be determined by inspecting its contents, + the HIT type must be communicated by some external means. + + When comparing HITs for equality, it is RECOMMENDED that conforming + implementations ignore the TBD top most bits. This is to allow + better compatibility for legacy IPv6 applications; see Appendix A. + However, independent of how many bits are actually used for HIT + comparison, it is also RECOMMENDED that the final equality decision + is based on the public key and not the HIT, if possible. See also + Section 3.2 for related discussion. + This document fully specifies only type 1 HITs. HITs that consists - of the HAA field and the hash are specified in [23]. + of the HAA field and the hash are specified in [24]. Any conforming implementation MUST be able to deal with Type 1 HITs. When handling other than type 1 HITs, the implementation is RECOMMENDED to explicitly learn and record the binding between the Host Identifier and the HIT, as it may not be able to generate such HITs from the Host Identifiers. 3.1.1 Generating a HIT from a HI - The 126 or 64 hash bits in a HIT MUST be generated by taking the - least significant 126 or 64 bits of the SHA-1 [21] hash of the Host + The 128 or 64 hash bits in a HIT MUST be generated by taking the + least significant 128 or 64 bits of the SHA-1 [22] hash of the Host Identifier as it is represented in the Host Identity field in a HIP payload packet. - For Identities that are DSA public keys, the HIT is formed as - follows: - 1. The DSA public key is encoded as defined in RFC2536 [13] Section - 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the - data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, - where T is the size parameter as defined in RFC2536 [13]. The - size parameter T, affecting the field lengths, MUST be selected - as the minimum value that is long enough to accommodate P, G, and - Y. The fields MUST be encoded in network byte order, as defined - in RFC2536 [13]. - 2. A SHA-1 hash [21] is calculated over the encoded key. - 3. The least significant 126 or 64 bits of the hash result are used + For Identities that are either RSA or DSA public keys, the HIT is + formed as follows: + 1. The public key is encoded as specified in the corresponding + DNSSEC document, taking the algorithm specific portion of the + RDATA part of the KEY RR. There is currently only two defined + public key algorithms: RSA and DSA. Hence, either of the + following applies: + + The RSA public key is encoded as defined in RFC3110 [14] + Section 2, taking the exponent length (e_len), exponent (e) + and modulus (n) fields concatenated. The length of the + modulus (n) can be determined from the total HI length + (hi_len) and the preceding HI fields including the exponent + (e). Thus, the data to be hashed has the same length than the + HI (hi_len). The fields MUST be encoded in network byte order, + as defined in RFC3110 [14]. + The DSA public key is encoded as defined in RFC2536 [13] + Section 2, taking the fields T, Q, P, G, and Y, concatenated. + Thus, the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T + octets long, where T is the size parameter as defined in + RFC2536 [13]. The size parameter T, affecting the field + lengths, MUST be selected as the minimum value that is long + enough to accommodate P, G, and Y. The fields MUST be encoded + in network byte order, as defined in RFC2536 [13]. + 2. A SHA-1 hash [22] is calculated over the encoded key. + 3. The least significant 128 or 64 bits of the hash result are used to create the HIT, as defined above. - The following pseudo-code illustrates the process. The symbol := - denotes assignment; the symbol += denotes appending. The - pseudo-function encode_in_network_byte_order takes two parameters, an - integer (bignum) and a length in bytes, and returns the integer - encoded into a byte string of the given length. + The following pseudo-codes illustrates the process for both RSA and + DSA. The symbol := denotes assignment; the symbol += denotes + appending. The pseudo-function encode_in_network_byte_order takes + two parameters, an integer (bignum) and a length in bytes, and + returns the integer encoded into a byte string of the given length. - buffer := encode_in_network_byte_order ( DSA.T , 1 ) - buffer += encode_in_network_byte_order ( DSA.Q , 20 ) - buffer += encode_in_network_byte_order ( DSA.P , 64 + 8 * T ) - buffer += encode_in_network_byte_order ( DSA.G , 64 + 8 * T ) - buffer += encode_in_network_byte_order ( DSA.Y , 64 + 8 * T ) + switch ( HI.algorithm ) + { - digest := SHA-1 ( buffer ) + case RSA: + buffer := encode_in_network_byte_order ( HI.RSA.e_len, + ( HI.RSA.e_len > 255 ) ? 3 : 1 ) + buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) + buffer += encode_in_network_byte_order ( HI.RSA.n, HI.hi_len ) + break; - hit_126 := concatenate ( 01 , low_order_bits ( digest, 126 ) ) - hit_haa := concatenate ( 10 , HAA, low_order_bits ( digest, 64 ) ) + case DSA: + buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) + buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) + buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 8 * HI.DSA.T ) + buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 8 * HI.DSA.T ) + buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 8 * HI.DSA.T ) + break; + + } + + digest := SHA-1 ( buffer ) + hit_128 := low_order_bits ( digest, 128 ) + hit_haa := concatenate ( HAA, low_order_bits ( digest, 64 ) ) 3.2 Local Scope Identifier (LSI) - LSIs are 32-bit localized representations of a Host Identity. The - purpose of an LSI is to facilitate using Host Identities in existing - IPv4 based protocols and APIs. The LSI can be used anywhere in system - processes where IP addresses have traditionally been used, such as - IPv4 API calls and FTP PORT commands. + LSIs are 32 or 128 bits long localized representations of a Host + Identity. The purpose of an LSI is to facilitate using Host + Identities in existing IPv4 or IPv6 based protocols and APIs. The + LSI can be used anywhere in system processes where IP addresses have + traditionally been used, such as IPv4 and IPv6 API calls and FTP PORT + commands. - The LSIs MUST be allocated from the TBD subnet. That makes it easier - to differentiate between LSIs and IPv4 addresses at the API level. - By default, the low order 24 bits of an LSI are equal to the low - order 24 bits of the corresponding HIT. + The IPv4-compatible LSIs MUST be allocated from the TBD subnet and + the IPv6-compatible LSIs MUST be allocated from the TBD subnet. That + makes it easier to differentiate between LSIs and IP addresses at the + API level. By default, the low order 24 bits of an IPv4-compatible + LSI are equal to the low order 24 bits of the corresponding HIT, + while the low order TBD bits of an IPv6-compatible LSI are equal to + the low order TBD bits of the corresponding HIT. A host performing a HIP handshake may discover that the LSI formed from the peer's HIT collides with another LSI in use locally (i.e., - the lower 24 bits of two different HITs are the same). In that case, - the host MUST handle the LSI collision locally such that application - calls can be disambiguated. One possible means of doing so is to - perform a Host NAT function to locally convert a peer's LSI into a - different LSI value. This would require the host to ensure that LSI - bits on the wire (i.e., in the application data stream) are converted - back to match that host's LSI. Other alternatives for resolving LSI - collisions may be added in the future. + the lower 24 or TBD bits of two different HITs are the same). In + that case, the host MUST handle the LSI collision locally such that + application calls can be disambiguated. One possible means of doing + so is to perform a Host NAT function to locally convert a peer's LSI + into a different LSI value. This would require the host to ensure + that LSI bits on the wire (i.e., in the application data stream) are + converted back to match that host's LSI. Other alternatives for + resolving LSI collisions may be added in the future. 3.3 Security Parameter Index (SPI) SPIs are used in ESP to find the right security association for received packets. The ESP SPIs have added significance when used with HIP; they are a compressed representation of the HITs in every packet. Thus, SPIs MAY be used by intermediary systems in providing services like address mapping. Note that since the SPI has significance at the receiver, only the < DST, SPI >, where DST is a destination IP address, uniquely identifies the receiver HIT at every given point of time. The same SPI value may be used by several hosts. A single < DST, SPI > value may denote different hosts at different points of time, depending on which host is currently reachable at the DST. Each host selects for itself the SPI it wants to see in packets received from its peer. This allows it to select different SPIs for different peers. The SPI selection SHOULD be random; the rules of - Section 2.1 of the ESP specification [18] must be followed. A + Section 2.1 of the ESP specification [19] must be followed. A different SPI SHOULD be used for each HIP exchange with a particular host; this is to avoid a replay attack. Additionally, when a host rekeys, the SPI MUST be changed. Furthermore, if a host changes over to use a different IP address, it MAY change the SPI. One method for SPI creation that meets these criteria would be to - concatenate the HIT with a 32 bit random or sequential number, hash + concatenate the HIT with a 32-bit random or sequential number, hash this (using SHA1), and then use the high order 32 bits as the SPI. The selected SPI is communicated to the peer in the third (I2) and fourth (R2) packets of the base HIP exchange. Changes in SPI are signaled with NES parameters. 4. Host Identity Protocol The Host Identity Protocol is IP protocol TBD (number will be assigned by IANA). The HIP payload could be carried in every @@ -418,49 +462,76 @@ least 40 bytes), and ESP already has all of the functionality to maintain and protect state, the HIP payload is 'compressed' into an ESP payload after the HIP exchange. Thus in practice, HIP packets only occur in datagrams to establish or change HIP state. For testing purposes, the protocol number 99 is currently used. 4.1 HIP base exchange The base HIP exchange serves to manage the establishment of state - between an Initiator and a Responder. The Initiator first sends a - trigger packet, I1, to the Responder. The second packet, R1, starts - the actual exchange. It contains a puzzle, that is, a cryptographic - challenge that the Initiator must solve before continuing the - exchange. In its reply, I2, the Initiator must display the solution. - Without a correct solution, the I2 message is discarded. + between an Initiator and a Responder. During the exchange, an IPsec + Security Association is created between the hosts. The last three + packets of the exchange, R1, I2, and R2, constitute a standard + authenticated Diffie-Hellman key exchange for session key generation. - The last three packets of the exchange, R1, I2, and R2, constitute a - standard authenticated Diffie-Hellman key exchange. The base - exchange is illustrated below. + The Initiator first sends a trigger packet, I1, to the Responder. + The packet contains only the HIT of the Initiator and possibly the + HIT of the Responder, if it is known. + + The second packet, R1, starts the actual exchange. It contains a + puzzle, that is, a cryptographic challenge that the Initiator must + solve before continuing the exchange. In addition, it contains the + initial Diffie-Hellman parameters and a signature, covering part of + the message. Some fields are left outside the signature to support + pre-created R1s. + + In the I2 packet, the Initiator must display the solution to the + received puzzle. Without a correct solution, the I2 message is + discarded. The I2 also contains a Diffie-Hellman parameter that + carries needed information for the Responder. The packet is signed + by the sender. + + The R2 packet finalizes the 4-way handshake, containing the SPI value + of the Responder. The packet is signed. + + The base exchange is illustrated below. During this D-H procedure, + the hosts create an IPsec session key. Initiator Responder I1: trigger exchange --------------------------> select pre-computed R1 R1: puzzle, D-H, key, sig <------------------------- check sig remain stateless solve puzzle I2: solution, D-H, {key}, sig --------------------------> compute D-H check cookie check puzzle check sig R2: sig <-------------------------- check sig compute D-H + In R1, the signature covers the packet, after setting the Initiator + HIT, header checksum, and the PUZZLE parameter's Opaque and Random #I + fields temporarily to zero, and excluding any TLVs that follow the + signature. + + In I2, the signature covers the whole packet, excluding any TLVs that + follow the signature. + + In R2, the signature and the HMAC cover the whole envelope. + In this section we cover the overall design of the base exchange. The details are the subject of the rest of this memo. 4.1.1 HIP Cookie Mechanism The purpose of the HIP cookie mechanism is to protect the Responder from a number of denial-of-service threats. It allows the Responder to delay state creation until receiving I2. Furthermore, the puzzle included in the cookie allows the Responder to use a fairly cheap calculation to check that the Initiator is "sincere" in the sense @@ -489,61 +560,61 @@ impractical for the attacker to first exchange one I1/R1, and then generate a large number of spoofed I2s that seemingly come from different IP addresses or use different HITs. The method does not protect from an attacker that uses fixed IP addresses and HITs, though. Against such an attacker it is probably best to create a piece of local state, and remember that the puzzle check has previously failed. See Appendix D for one possible implementation. Note, however, that the implementations MUST NOT use the exact implementation given in the appendix, and SHOULD include sufficient randomness to the algorithm so that algorithm complexity attacks - become impossible [25]. + become impossible [26]. The Responder can set the difficulty for Initiator, based on its concern of trust of the Initiator. The Responder SHOULD use heuristics to determine when it is under a denial-of-service attack, and set the difficulty value K appropriately. The Responder starts the cookie exchange when it receives an I1. The Responder supplies a random number I, and requires the Initiator to find a number J. To select a proper J, the Initiator must create the concatenation of I, the HITs of the parties, and J, and take a SHA-1 hash over this concatenation. The lowest order K bits of the result MUST be zeros. To generate a proper number J, the Initiator will have to generate a number of Js until one produces the hash target of zero. The - Initiator SHOULD give up after trying 2^(K+2) times, and start over - the exchange. (See Appendix C.) The Responder needs to re-create - the concatenation of I, the HITs, and the provided J, and compute the - hash once to prove that the Initiator did its assigned task. + Initiator SHOULD give up after exceeding the puzzle lifetime received + in PUZZLE TLV. The Responder needs to re-create the concatenation of + I, the HITs, and the provided J, and compute the hash once to prove + that the Initiator did its assigned task. To prevent pre-computation attacks, the Responder MUST select the number I in such a way that the Initiator cannot guess it. Furthermore, the construction MUST allow the Responder to verify that the value was indeed selected by it and not by the Initiator. See Appendix D for an example on how to implement this. Using the Opaque data field in the ECHO_REQUEST, the Responder can include some data in R1 that the Initiator must copy unmodified in the corresponding I2 packet. The Responder can generate the Opaque data e.g. using the sent I, some secret and possibly other related data. Using this same secret, received I in I2 packet and possible other data, the Receiver can verify that it has itself sent the I to the Initiator. The Responder must change the secret periodically. It is RECOMMENDED that the Responder generates a new cookie and a new R1 once every few minutes. Furthermore, it is RECOMMENDED that the - Responder remembers an old cookie at least 60 seconds after it has - been deprecated. These time values allow a slower Initiator to solve - the cookie puzzle while limiting the usability that an old, solved - cookie has to an attacker. + Responder remembers an old cookie at least 2*lifetime seconds after + it has been deprecated. These time values allow a slower Initiator + to solve the cookie puzzle while limiting the usability that an old, + solved cookie has to an attacker. NOTE: The protocol developers explicitly considered whether R1 should include a timestamp in order to protect the Initiator from replay attacks. The decision was NOT to include a timestamp. In R1, the values I and K are sent in network byte order. Similarly, in I2 the values I and J are sent in network byte order. The SHA-1 hash is created by concatenating, in network byte order, the following data, in the following order: 64-bit random value I, in network byte order, as appearing in R1 @@ -685,58 +756,48 @@ multiple HIP parameters, for updating the HIP state between two peers. The UPDATE mechanism has the following properties: UPDATE messages carry a monotonically increasing sequence number and are explicitly acknowledged by the peer. Lost UPDATEs or acknowledgments may be recovered via retransmission. Multiple UPDATE messages may be outstanding. UPDATE is protected by both HMAC and HIP_SIGNATURE parameters, since processing UPDATE signatures alone is a potential DoS attack against intermediate systems. - The UPDATE packet is defined in Section 7.5. + The UPDATE packet is defined in Section 7.6. 4.4 Error processing HIP error processing behaviour depends on whether there exists an active HIP association or not. In general, if an HIP security association exists between the sender and receiver of a packet causing an error condition, the receiver SHOULD respond with a NOTIFY packet. On the other hand, if there are no existing HIP security associations between the sender and receiver, or the receiver cannot reasonably determine the identity of the sender, the receiver MAY respond with a suitable ICMP message; see Section 6.3 for more details. -4.5 Bootstrap support - - This memo defines an OPTIONAL HIP based bootstrap mechanism, intended - for ad hoc like environments; see Section 7.6. There is little - operational experience of the usability of this mechanism, and it may - be dropped or completely revised in some future protocol version. - -4.6 Certificate distribution +4.5 Certificate distribution HIP does not define how to use certificates. However, it does define a simple certificate transport mechanisms that MAY be used to implement certificate based security policies. The certificate payload is defined in Section 6.2.11, and the certificate packet in - Section 7.7. + Section 7.5. -4.7 Sending data on HIP packets +4.6 Sending data on HIP packets A future version of this document may define how to include ESP protected data on various HIP packets. However, currently the HIP header is a terminal header, and not followed by any other headers. - The OPTIONAL PAYLOAD packet (see Section 7.9) MAY be used to transfer - data. - 5. HIP protocol overview The following material is an overview of the HIP protocol operation. Section 8 describes the packet processing steps in more detail. A typical HIP packet flow is shown below, between an Initiator (I) and a Responder (R). It illustrates the exchange of four HIP packets (I1, R1, I2, and R2). I --> Directory: lookup R @@ -854,20 +915,22 @@ mobility and multihoming). 5.4.1 HIP States UNASSOCIATED State machine start I1-SENT Initiating HIP I2-SENT Waiting to finish HIP R2-SENT Waiting to finish HIP ESTABLISHED HIP SA established REKEYING HIP SA established, but UPDATE is outstanding for rekeying + CLOSING HIP SA closing, no data (ESP) can be sent + CLOSED HIP SA closed, no data (ESP) can be sent E-FAILED HIP exchange failed 5.4.2 HIP State Processes +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send requiring a new SA, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED @@ -867,24 +930,29 @@ +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send requiring a new SA, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at UNASSOCIATED + Receive ESP for unknown SA, optionally send ICMP as defined in Section 6.3 and stay at UNASSOCIATED + + Receive CLOSE, or UPDATE, optionally send ICMP Parameter + Problem and stay in UNASSOCIATED. + Receive ANYOTHER, drop and stay at UNASSOCIATED +---------+ | I1-SENT | Initiating HIP +---------+ Receive I1, send R1 and stay at I1-SENT Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at I1-SENT @@ -945,27 +1012,91 @@ if fail, stay at ESTABLISHED Receive R1, drop and stay at ESTABLISHED Receive R2, drop and stay at ESTABLISHED Receive ESP for SA, process and stay at ESTABLISHED Receive UPDATE, process if successful, send UPDATE in reply and go to REKEYING if failed, stay at ESTABLISHED Need rekey, send UPDATE and go to REKEYING + No packet sent/received during UAL minutes, send CLOSE and go to + CLOSING. + Receive CLOSE, process + if successful, send CLOSE_ACK and go to CLOSED + if failed, stay at ESTABLISHED + + +---------+ + | CLOSING | HIP association has not been used for UAL (Unused + +---------+ Association Lifetime) minutes. + + Datagram to send, requires the creation of another incarnation + of the HIP association, started by sending an I1, + and stay at CLOSING + + Receive I1, send R1 and stay at CLOSING + Receive I2, process + if successful, send R2 and go to R2-SENT + if fail, stay at CLOSING + + Receive R1, process + if successful, send I2 and go to I2-SENT + if fail, stay at CLOSING + + Receive CLOSE, process + if successful, send CLOSE_ACK, discard state and go to CLOSED + if failed, stay at CLOSING + Receive CLOSE_ACK, process + if successful, discard state and go to UNASSOCIATED + if failed, stay at CLOSING + + Receive ANYOTHER, drop and stay at CLOSING + + Timeout, increment timeout sum, reset timer + if timeout sum is less than UAL+MSL minutes, retransmit CLOSE + and stay at CLOSING + if timeout sum is greater than UAL+MSL minutes, go to + UNASSOCIATED + + +--------+ + | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary + +--------+ + + Datagram to send, requires the creation of another incarnation + of the HIP association, started by sending an I1, + and stay at CLOSED + + Receive I1, send R1 and stay at CLOSED + Receive I2, process + if successful, send R2 and go to R2-SENT + if fail, stay at CLOSED + + Receive R1, process + if successful, send I2 and go to I2-SENT + if fail, stay at CLOSED + + Receive CLOSE, process + if successful, send CLOSE_ACK, stay at CLOSED + if failed, stay at CLOSED + Receive CLOSE_ACK, process + if successful, discard state and go to UNASSOCIATED + if failed, stay at CLOSED + + Receive ANYOTHER, drop and stay at CLOSED + + Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED +----------+ | REKEYING | HIP SA established, rekey pending +----------+ Receive I1, send R1 and stay at REKEYING - Receive I2, process with cookie and possible Opaque data verification if successful, send R2, drop old SA and go to R2-SENT if fail, stay at REKEYING Receive R1, drop and stay at REKEYING Receive R2, drop and stay at REKEYING Receive ESP for SA, process and stay at REKEYING Receive UPDATE, process if successful completion of rekey, go to ESTABLISHED if failed, stay at REKEYING @@ -981,51 +1112,65 @@ Move to UNASSOCIATED after an implementation specific time. Re-negotiation is possible after moving to UNASSOCIATED state. 5.4.3 Simplified HIP State Diagram The following diagram shows the major state transitions. Transitions based on received packets implicitly assume that the packets are successfully authenticated or processed. The diagram assumes that UPDATE messages are being used for rekeying. - +-+ - | | I1 received, send R1 - v | - Datagram to send +--------------+ I2 received, send R2 - +---------------| UNASSOCIATED |---------------+ - | +--------------+ | - v | - +---------+ I2 received, send R2 | - | I1-SENT |---------------------------------------+ | - +---------+ | | - | +------------------------+ | | - | R1 received, | I2 received, send R2 | | | - v send I2 | v v v - +---------+ | +---------+ - | I2-SENT |------------+ | R2-SENT | - +---------+ +---------+ - | | ^ - | | | - | | | - | timeout, | | - | R2 received +--------------+ ESP | | - +-------------->| ESTABLISHED |<---------+ | - +--------------+ | - Update received/ | ^ | I2 | - Update triggered | | +---------------+ - +------------------+ | - | | - v | - +----------+ | - | REKEYING |---------------+ - +----------+ UPDATE acked and NES received + +-+ +------------------------------+ + I1 received, send R1 | | | | + | v v | + Datagram to send +--------------+ I2 received, send R2 | + +---------------| UNASSOCIATED |---------------+ | + | +--------------+ | | + v | | + +---------+ I2 received, send R2 | | + +---->| I1-SENT |---------------------------------------+ | | + | +---------+ | | | + | | +------------------------+ | | | + | | R1 received, | I2 received, send R2 | | | | + | v send I2 | v v v | + | +---------+ | +---------+ | + | +->| I2-SENT |------------+ | R2-SENT |<-----+ | + | | +---------+ +---------+ | | + | | | | | | + | | | | | | + | |receive | | | | + | |R1, send | timeout, | receive I2,| | + | |I2 |R2 received +--------------+ ESP | send R2| | + | | +----------->| ESTABLISHED |<---------+ | | + | | +--------------+ | | + | | Update received/ | ^ | | | | | + | | Update triggered | | | | +---------------------------+ | + | | +----------------+ | | | | | + | | | | | | No packet sent/received | | + | | v | | | for UAL min, send CLOSE | | + | | +----------+ | | | | | + | | | REKEYING |-------------+ | | +---------+<-+ timeout | | + | | +----------+ UPDATE acked | +--->| CLOSING |--+ (UAL+MSL) | | + | | and NES received | +---------+ retransmit | | + +--+----------------------------+---------+ | | | | CLOSE | | + | +----------------------------+-----------+ | | +----------------+ | + | | | +-----------+ +------------------+--+ + | | | | receive CLOSE, CLOSE_ACK | | + | | | | send CLOSE_ACK received or | | + | | v v timeout | | + | | +--------+ (UAL+MSL) | | + | +---------------------------| CLOSED |---------------------------+ | + +------------------------------+--------+------------------------------+ + Datagram to send ^ | timeout (UAL+2MSL), + +-+ move to UNASSOCIATED + CLOSE received, + send CLOSE_ACK 6. Packet formats 6.1 Payload format All HIP packets start with a fixed header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1081,30 +1226,37 @@ The HIT fields are always 128 bits (16 bytes) long. 6.1.1 HIP Controls The HIP control section transfers information about the structure of the packet and capabilities of the host. The following fields have been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | | | | | | | | | | | | | |C|A| + | SHT | DHT | | | | | | | | |C|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C - Certificate One or more certificate packets (CER) follows this - HIP packet (see Section 7.7). + HIP packet (see Section 7.5). A - Anonymous If this is set, the sender's HI in this packet is anonymous, i.e., one not listed in a directory. Anonymous HIs SHOULD NOT be stored. This control is set in packets R1 and/or I2. The peer receiving an anonymous HI may choose to refuse it by silently dropping the exchange. + SHT - Sender's HIT Type Currently the following values are specified: + 0 RESERVED + 1 Type 1 HIT + 2 Type 2 HIT + 3-6 UNASSIGNED + 7 RESERVED + DHT - Destination's HIT Type Using the same values as SHT. The rest of the fields are reserved for future use and MUST be set to zero on sent packets and ignored on received packets. 6.1.2 Checksum The checksum field is located at the same location within the header as the checksum field in UDP packets, enabling hardware assisted checksum generation and verification. Note that since the checksum covers the source and destination addresses in the IP header, it must be recomputed on HIP based NAT boxes. @@ -1168,20 +1320,24 @@ ECHO_REQUEST 1022 variable Opaque data to be echoed back; under signature ECHO_RESPONSE 1024 variable Opaque data echoed back; under signature HMAC 65245 20 HMAC based message authentication code, with key material from HIP_TRANSFORM + HMAC_2 65247 20 HMAC based message + authentication code, with + key material from HIP_TRANSFORM + HIP_SIGNATURE_2 65277 variable Signature of the R1 packet HIP_SIGNATURE 65279 variable Signature of the packet ECHO_REQUEST 65281 variable Opaque data to be echoed back ECHO_RESPONSE 65283 variable Opaque data echoed back; after signature 6.2.1 TLV format @@ -1324,63 +1481,69 @@ the R1, it MAY be echoed (including the Reserved field) by the Initiator in the I2. 6.2.5 PUZZLE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | K, 1 byte | Opaque, 3 bytes | + | K, 1 byte | Lifetime | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length 12 K K is the number of verified bits + Lifetime Puzzle lifetime 2^(value-32) seconds Opaque Data set by the Responder, indexing the puzzle Random #I random number - Random #I is represented as 64-bit integer, K as 8-bit integer, all - in network byte order. + Random #I is represented as 64-bit integer, K and Lifetime as 8-bit + integer, all in network byte order. The PUZZLE parameter contains the puzzle difficulty K and an 64-bit - puzzle random integer #I. A puzzle MAY be augmented by including an + puzzle random integer #I. Puzzle Lifetime indicates the time during + which the puzzle solution is valid and sets a time limit for + initiator which it should not exceed while trying to solve the + puzzle. The lifetime is indicated as power of 2 using formula + 2^(Lifetime-32) seconds. A puzzle MAY be augmented by including an ECHO_REQUEST parameter to an R1. The contents of the ECHO_REQUEST are then echoed back in ECHO_RESPONSE, allowing the Responder to use the included information as a part of puzzle processing. The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 parameter. 6.2.6 SOLUTION 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | K, 1 byte | Opaque, 3 bytes | + | K, 1 byte | Reserved | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle solution #J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 Length 20 K K is the number of verified bits + Reserved zero when sent, ignored when received Opaque Copied unmodified from the received PUZZLE TLV Random #I random number Puzzle solution #J random number Random #I, and Random #J are represented as 64-bit integers, K as 8-bit integer, all in network byte order. The SOLUTION parameter contains a solution to a puzzle. It also echoes back the random difficulty K, the Opaque field, and the puzzle @@ -1406,21 +1570,21 @@ Group Value Reserved 0 384-bit group 1 OAKLEY well known group 1 2 1536-bit MODP group 3 3072-bit MODP group 4 6144-bit MODP group 5 8192-bit MODP group 6 - The MODP Diffie-Hellman groups are defined in [17]. The OAKLEY group + The MODP Diffie-Hellman groups are defined in [18]. The OAKLEY group is defined in [9]. The OAKLEY well known group 5 is the same as the 1536-bit MODP group. A HIP implementation MUST support Group IDs 1 and 3. The 384-bit group can be used when lower security is enough (e.g. web surfing) and when the equipment is not powerful enough (e.g. some PDAs). Equipment powerful enough SHOULD implement also group ID 5. The 384-bit group is defined in Appendix G. To avoid unnecessary failures during the 4-way handshake, the rest of @@ -1439,25 +1603,25 @@ | Transform-ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 17 Length length in octets, excluding Type, Length, and padding Transform-ID Defines the HIP Suite to be used The Suite-IDs are identical to those defined in Section 6.2.9. There MUST NOT be more than six (6) HIP Suite-IDs in one HIP - transform TLV. The limited number of transforms sets the maximum size - of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one - of the mandatory Suite-IDs. + transform TLV. The limited number of transforms sets the maximum + size of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at + least one of the mandatory Suite-IDs. - Mandatory implementations: ENCR-3DES-CBC with HMAC-SHA1 and ENCR-NULL + Mandatory implementations: ENCR-AES-CBC with HMAC-SHA1 and ENCR-NULL with HMAC-SHA1. 6.2.9 ESP_TRANSFORM 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |E| Suite-ID #1 | @@ -1470,38 +1634,38 @@ Type 19 Length length in octets, excluding Type, Length, and padding E One if the ESP transform requires 64-bit sequence numbers (see Section 11.6 ) Reserved zero when sent, ignored when received Suite-ID defines the ESP Suite to be used - The following Suite-IDs are defined ([19],[22]): + The following Suite-IDs are defined ([20],[23]): Suite-ID Value RESERVED 0 ESP-AES-CBC with HMAC-SHA1 1 ESP-3DES-CBC with HMAC-SHA1 2 ESP-3DES-CBC with HMAC-MD5 3 ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-NULL with HMAC-SHA1 5 ESP-NULL with HMAC-MD5 6 There MUST NOT be more than six (6) ESP Suite-IDs in one ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least one of the mandatory Suite-IDs. - Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL + Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL with HMAC-SHA1. 6.2.10 HOST_ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HI Length |DI-type| DI Length | @@ -1515,29 +1679,28 @@ Type 35 Length length in octets, excluding Type, Length, and Padding DI-type type of the following Domain Identifier field DI Length length of the FQDN or NAI in octets N if set, the following FQDN/NAI field contains a NAI Host Identity actual host identity Domain Identifier the identifier of the sender - The Host Identity is represented in RFC2535 [12] format. The algorithms used in RDATA format are the following: Algorithms Values RESERVED 0 - DSA 3 [RFC2536] (REQUIRED) - RSA 5 [RFC3110] (OPTIONAL) + DSA 3 [RFC2536] (RECOMMENDED) + RSA 5 [RFC3110] (REQUIRED) The following DI-types have been defined: Type Value none included 0 FQDN 1 NAI 2 FQDN Fully Qualified Domain Name, in binary format. NAI Network Access Identifier, in binary format. The @@ -1573,21 +1736,21 @@ that it will receive from the sender, related to the R1 or I2. The Cert ID identifies the particular certificate and its order in the certificate chain. The numbering in Cert ID MUST go from 1 to Cert count. The following certificate types are defined: Cert format Type number X.509 v3 1 - The encoding format for X.509v3 certificate is defined in [14]. + The encoding format for X.509v3 certificate is defined in [15]. 6.2.12 HMAC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC | @@ -1602,21 +1765,40 @@ packet, excluding the HMAC parameter and any following HIP_SIGNATURE or HIP_SIGNATURE_2 parameters. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. The HMAC calculation and verification process is presented in Section 8.3.1 -6.2.13 HIP_SIGNATURE +6.2.13 HMAC_2 + + The TLV structure is the same as in Section 6.2.12. The fields are: + + Type 65247 + Length 20 + HMAC 160 low order bits of the HMAC computed over the HIP + packet, excluding the HMAC parameter and any + following HIP_SIGNATURE or HIP_SIGNATURE_2 + parameters and including an additional sender's + HOST_ID TLV during the HMAC calculation. The + checksum field MUST be set to zero and the HIP + header length in the HIP common header MUST be + calculated not to cover any excluded parameters when + the HMAC is calculated. + + The HMAC calculation and verification process is presented in Section + 8.3.1 + +6.2.14 HIP_SIGNATURE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIG alg | Signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1627,29 +1809,29 @@ Signature the signature is calculated over the HIP packet, excluding the HIP_SIGNATURE TLV field and any TLVs that follow the HIP_SIGNATURE TLV. The checksum field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated only to the beginning of the HIP_SIGNATURE TLV when the signature is calculated. The signature algorithms are defined in Section 6.2.10. The signature in the Signature field is encoded using the proper method - depending on the signature algorithm (e.g. in case of DSA, according - to [13]). + depending on the signature algorithm (e.g. according to [14] in case + of RSA, or according to [13] in case of DSA). The HIP_SIGNATURE calculation and verification process is presented in Section 8.3.2 -6.2.14 HIP_SIGNATURE_2 +6.2.15 HIP_SIGNATURE_2 - The TLV structure is the same as in Section 6.2.13. The fields are: + The TLV structure is the same as in Section 6.2.14. The fields are: Type 65277 (2^16-2^8-3) Length length in octets, excluding Type, Length, and Padding SIG alg Signature algorithm Signature the signature is calculated over the HIP R1 packet, excluding the HIP_SIGNATURE_2 TLV field and any TLVs that follow the HIP_SIGNATURE_2 TLV. Initiator's HIT, checksum field, and the Opaque and Random #I fields in the PUZZLE TLV MUST be set to zero while computing the HIP_SIGNATURE_2 signature. Further, the @@ -1658,21 +1840,21 @@ TLV when the signature is calculated. Zeroing the Initiator's HIT makes it possible to create R1 packets beforehand to minimize the effects of possible DoS attacks. Zeroing the I and Opaque fields allows these fields to be populated dynamically on precomputed R1s. Signature calculation and verification follows the process in Section 8.3.2. -6.2.15 NES +6.2.16 NES During the life of an SA established by HIP, one of the hosts may need to reset the Sequence Number to one (to prevent wrapping) and rekey. The reason for rekeying might be an approaching sequence number wrap in ESP, or a local policy on use of a key. Rekeying ends the current SAs and starts new ones on both peers. The NES parameter is carried in the HIP UPDATE packet. It is used to reset Security Associations. It introduces a new SPI to be used when sending data to the sender of the UPDATE packet. The keys for the @@ -1703,61 +1885,61 @@ a new Diffie-Hellman key. Old SPI Old SPI for data sent to the source address of this packet New SPI New SPI for data sent to the source address of this packet A host that receives an NES must reply shortly thereafter with an NES. Any middleboxes between the communicating hosts will learn the mappings from the pair of UPDATE messages. -6.2.16 SEQ +6.2.17 SEQ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Update ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 11 Length 4 Update ID 32-bit sequence number The Update ID is an unsigned quantity, initialized by a host to zero upon moving to ESTABLISHED state. The Update ID has scope within a single HIP association, and not across multiple associations or multiple hosts. The Update ID is incremented by one before each new UPDATE that is sent by the host (i.e., the first UPDATE packet originated by a host has an Update ID of 1). -6.2.17 ACK +6.2.18 ACK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | peer Update ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 13 Length variable (multiple of 4) peer Update ID 32-bit sequence number corresponding to the Update ID being acked. The ACK parameter includes one or more Update IDs that have been received from the peer. The Length field identifies the number of peer Update IDs that are present in the parameter. -6.2.18 ENCRYPTED +6.2.19 ENCRYPTED 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV / / / @@ -1784,40 +1966,40 @@ be easily parsed after decryption. Each of the TLVs to be encrypted, must be padded according to rules in Section 6.2.1 before encryption. If the encryption algorithm requires the length of the data to be encrypted to be a multiple of the cipher algorithm block size, thereby necessitating padding, and if the encryption algorithm does not specify the padding contents, then an implementation MUST append the TLV parameter that is to be encrypted with an additional padding, so that the length of the resulting cleartext is a multiple of the cipher block size length. Such a padding MUST be constructed as - specified in [18] Section 2.4. On the other hand, if the data to be + specified in [19] Section 2.4. On the other hand, if the data to be encrypted is already a multiple of the block size, or if the - encryption algorithm does specify padding as per [18] Section 2.4, + encryption algorithm does specify padding as per [19] Section 2.4, then such additional padding SHOULD NOT be added. The Length field in the inside, to be encrypted TLV does not include the padding. The Length field in the outside ENCRYPTED TLV is the length of the data after encryption (including the Reserved field, the IV field, and the output from the encryption process specified for that suite, but not any additional external padding). Note that the length of the cipher suite output may be smaller or larger than the length of the data to be encrypted, since the encryption process may compress the data or add additional padding to the data. The ENCRYPTED payload may contain additional external padding, if the result of encryption, the TLV header and the IV is not a multiple of 8 bytes. The contents of this external padding MUST follow the rules given in Section 6.2.1. -6.2.19 NOTIFY +6.2.20 NOTIFY The NOTIFY parameter is used to transmit informational data, such as error conditions and state transitions, to a HIP peer. A NOTIFY parameter may appear in the NOTIFY packet type. The use of the NOTIFY parameter in other packet types is for further study. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | @@ -1926,30 +2108,47 @@ The responder could not successfully decrypt the ENCRYPTED TLV. INVALID_HIT 40 Sent in response to a failure to validate the peer's HIT from the corresponding HI. BLOCKED_BY_POLICY 42 - The resonder is unwilling to set up an association + The responder is unwilling to set up an association for some policy reason (e.g. received HIT is NULL and policy does not allow opportunistic mode). + SERVER_BUSY_PLEASE_RETRY 44 + The responder is unwilling to set up an association + as it is suffering under some kind of overload and + has chosen to shed load by rejecting your request. + You may retry if you wish, however you MUST find + another (different) puzzle solution for any such + retries. Note that you may need to obtain a new + puzzle with a new I1/R1 exchange. + + I2_ACKNOWLEDGEMENT 46 + + The responder has received your I2 but had to queue + the I2 for processing. The puzzle was correctly solved + and the responder is willing to set up an association + but has currently a number of I2s in processing queue. + R2 will be sent after the I2 has been processed. + NOTIFY MESSAGES - STATUS TYPES Value ------------------------------ ----- (None defined at present) -6.2.20 ECHO_REQUEST +6.2.21 ECHO_REQUEST 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque data (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65281 or 1022 @@ -1961,21 +2160,21 @@ The ECHO_REQUEST parameter contains an opaque blob of data that the sender wants to get echoed back in the corresponding reply packet. The ECHO_REQUEST and ECHO_RESPONSE parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. The ECHO_REQUEST MAY be covered by the HMAC and SIGNATURE. This is dictated by the Type field selected for the parameter; Type 1022 ECHO_REQUEST is covered and Type 65281 is not. -6.2.21 ECHO_RESPONSE +6.2.22 ECHO_RESPONSE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque data (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65283 or 1024 @@ -2040,20 +2239,36 @@ beginning of the Puzzle solution #J field in the SOLUTION payload in the HIP message. If IPv4 is used, the implementation MAY respond with an ICMP packet with the type Parameter Problem, copying enough of bytes form the I2 message so that the SOLUTION parameter fits in to the ICMP message, the Pointer pointing to the beginning of the Puzzle solution #J field, as in the IPv6 case. Note, however, that the resulting ICMPv4 message exceeds the typical ICMPv4 message size as defined in [2]. +6.3.5 Non-existing HIP association + + If a HIP implementation receives a CLOSE, or UPDATE packet, or any + other packet whose handling requires an existing association, that + has either a Receiver or Sender HIT that does not match with any + existing HIP association, the implementation MAY respond, rate + limited, with an ICMP packet with the type Parameter Problem, the + Pointer pointing to the the beginning of the first HIT that does not + match. + + A host MUST NOT reply with such an ICMP if it receives any of the + following messages: I1, R2, I2, R2, CER, and NOTIFY. When + introducing new packet types, a specification SHOULD define the + appropriate rules for sending or not sending this kind of ICMP + replies. + 7. HIP Packets There are nine basic HIP packets. Four are for the base HIP exchange, one is for updating, one is a broadcast for use when there is no IP addressing (e.g., before DHCP exchange), one is used to send certificates, one for sending notifications, and one is for sending unencrypted data. Packets consist of the fixed header as described in Section 6.1, followed by the parameters. The parameter part, in turn, consists of @@ -2089,21 +2304,23 @@ IP ( HIP () ) The I1 packet contains only the fixed HIP header. Valid control bits: none The Initiator gets the Responder's HIT either from a DNS lookup of the Responder's FQDN, from some other repository, or from a local table. If the Initiator does not know the Responder's HIT, it may attempt opportunistic mode by using NULL (all zeros) as the - Responder's HIT. + Responder's HIT. If the Initiator send a NULL as the Responder's + HIT, it MUST be able to handle all MUST and SHOULD algorithms from + Section 3, which are currently RSA and DSA. Since this packet is so easy to spoof even if it were signed, no attempt is made to add to its generation or processing cost. Implementation MUST be able to handle a storm of received I1 packets, discarding those with common content that arrive within a small time delta. 7.2 R1 - the HIP responder packet @@ -2151,122 +2368,157 @@ The Diffie-Hellman value is ephemeral, but can be reused over a number of connections. In fact, as a defense against I1 storms, an implementation MAY use the same Diffie-Hellman value for a period of time, for example, 15 minutes. By using a small number of different Cookies for a given Diffie-Hellman value, the R1 packets can be pre-computed and delivered as quickly as I1 packets arrive. A scavenger process should clean up unused DHs and Cookies. The HIP_TRANSFORM contains the encryption and integrity algorithms supported by the Responder to protect the HI exchange, in the order - of preference. All implementations MUST support the 3DES [10] with + of preference. All implementations MUST support the AES [10] with HMAC-SHA-1-96 [6]. The ESP_TRANSFORM contains the ESP modes supported by the Responder, - in the order of preference. All implementations MUST support 3DES + in the order of preference. All implementations MUST support AES [10] with HMAC-SHA-1-96 [6]. The ECHO_REQUEST contains data that the sender wants to receive unmodified in the corresponding response packet in the ECHO_RESPONSE parameter. The ECHO_REQUEST can be either covered by the signature, or it can be left out from it. In the first case, the ECHO_REQUEST gets Type number 1022 and in the latter case 65281. The signature is calculated over the whole HIP envelope, after setting the initiator HIT, header checksum as well as the Opaque field and the Random #I in the PUZZLE parameter temporarily to zero, and excluding any TLVs that follow the signature, as described in - Section 6.2.14. This allows the Responder to use precomputed R1s. + Section 6.2.15. This allows the Responder to use precomputed R1s. The Initiator SHOULD validate this signature. It SHOULD check that the responder HI received matches with the one expected, if any. 7.3 I2 - the second HIP initiator packet The HIP header values for the I2 packet: Header: Type = 3 SRC HIT = Initiator's HIT DST HIT = Responder's HIT IP ( HIP ( SPI, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, [ ECHO_RESPONSE ,] + HMAC, HIP_SIGNATURE [, ECHO_RESPONSE] ) ) Valid control bits: C, A The HITs used MUST match the ones used previously. If the initiator HI is an anonymous one, the A control MUST be set. The Initiator MAY include an unmodified copy of the R1_COUNTER parameter received in the corresponding R1 packet into the I2 packet. The Solution contains the random # I from R1 and the computed # J. The low order K bits of the SHA-1(I | ... | J) MUST be zero. The Diffie-Hellman value is ephemeral. If precomputed, a scavenger process should clean up unused DHs. The HIP_TRANSFORM contains the encryption and integrity used to protect the HI exchange selected by the Initiator. All - implementations MUST support the 3DES transform [10]. + implementations MUST support the AES transform [10]. The Initiator's HI is encrypted using the HIP_TRANSFORM encryption algorithm. The keying material is derived from the Diffie-Hellman exchanged as defined in Section 9. The ESP_TRANSFORM contains the ESP mode selected by the Initiator. - All implementations MUST support 3DES [10] with HMAC-SHA-1-96 [6]. + All implementations MUST support AES [10] with HMAC-SHA-1-96 [6]. The ECHO_RESPONSE contains the the unmodified Opaque data copied from - the corresponding ECHO_REPLY packet. The ECHO_RESPONSE can be either + the corresponding ECHO_REQUEST TLV. The ECHO_RESPONSE can be either covered by the signature, or it can be left out from it. In the first case, the ECHO_RESPONSE gets Type number 1024 and in the latter case 65283. + The HMAC is calculated over whole HIP envelope, excluding any TLVs + after the HMAC, as described in Section 8.3.1. The Responder MUST + validate the HMAC. + The signature is calculated over whole HIP envelope, excluding any - TLVs after the HIP_SIGNATURE, as described in Section 6.2.13. The + TLVs after the HIP_SIGNATURE, as described in Section 6.2.14. The Responder MUST validate this signature. It MAY use either the HI in the packet or the HI acquired by some other means. 7.4 R2 - the second HIP responder packet The HIP header values for the R2 packet: Header: Packet Type = 4 SRC HIT = Responder's HIT DST HIT = Initiator's HIT - IP ( HIP ( SPI, HMAC, HIP_SIGNATURE ) ) + IP ( HIP ( SPI, HMAC_2, HIP_SIGNATURE ) ) Valid control bits: none - The HMAC and signature are calculated over whole HIP envelope. The - Initiator MUST validate both the HMAC and the signature. + The HMAC_2 is calculated over whole HIP envelope, with Responder's + HOST_ID TLV concatenated with the HIP envelope. The HOST_ID TLV is + removed after the HMAC calculation. The procedure is described in + 8.3.1. -7.5 UPDATE - the HIP Update Packet + The signature is calculated over whole HIP envelope. + + The Initiator MUST validate both the HMAC and the signature. + +7.5 CER - the HIP Certificate Packet + + The CER packet is OPTIONAL. + + The Optional CER packets over the Announcer's HI by a higher level + authority known to the Recipient is an alternative method for the + Recipient to trust the Announcer's HI (over DNSSEC or PKI). + + The HIP header values for CER packet: + + Header: + Packet Type = 5 + SRC HIT = Announcer's HIT + DST HIT = Recipient's HIT + + IP ( HIP ( i , HIP_SIGNATURE ) ) or + IP ( HIP ( ENCRYPTED { i }, HIP_SIGNATURE ) ) + + Valid control bits: None + + Certificates in the CER packet MAY be encrypted. The encryption + algorithm is provided in the HIP transform of the previous (R1 or I2) + packet. + +7.6 UPDATE - the HIP Update Packet Support for the UPDATE packet is MANDATORY. The HIP header values for the UPDATE packet: Header: - Packet Type = 5 + Packet Type = 6 SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( [NES, SEQ, ACK, DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) Valid control bits: None The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE parameters, and other optional parameters. @@ -2303,127 +2555,76 @@ In the case of rekeying (Section 8.10), the UPDATE packet MUST carry NES and MAY carry DIFFIE_HELLMAN parameter, unless the UPDATE is a bare ack. Intermediate systems that use the SPI will have to inspect HIP packets for a UPDATE packet. The packet is signed for the benefit of the intermediate systems. Since intermediate systems may need the new SPI values, the contents of this packet cannot be encrypted. -7.6 BOS - the HIP Bootstrap Packet - - The BOS packet is OPTIONAL. +7.7 NOTIFY - the HIP Notify Packet - In some situations, an Initiator may not be able to learn of a - Responder's information from DNS or another repository. Some examples - of this are DHCP and NetBIOS servers. Thus, a packet is needed to - provide information that would otherwise be gleaned from a - repository. This HIP packet is either self-signed in applications - like SoHo, or from a trust anchor in large private or public - deployments. This packet MAY be broadcasted in IPv4 or multicasted - to the all hosts multicast group in IPv6. The packet MUST NOT be - sent more often than once in every second. Implementations MAY - ignore received BOS packets. + The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to + provide information to a peer. Typically, NOTIFY is used to indicate + some type of protocol error or negotiation failure. - The HIP header values for the BOS packet: + The HIP header values for the NOTIFY packet: Header: Packet Type = 7 - SRC HIT = Announcer's HIT - DST HIT = NULL - - IP ( HIP ( HOST_ID, HIP_SIGNATURE ) ) - - The BOS packet may be followed by a CER packet if the HI is signed. - In this case, the C-bit in the control field MUST be set. If the BOS - packet is broadcasted or multicasted, the following CER packet(s) - MUST be broadcasted or multicasted to the same multicast group and - scope, respectively. + SRC HIT = Sender's HIT + DST HIT = Recipient's HIT, or zero if unknown - Valid control bits: C, A + IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) -7.7 CER - the HIP Certificate Packet + Valid control bits: None - The CER packet is OPTIONAL. + The NOTIFY packet is used to carry one or more NOTIFY parameters. - The Optional CER packets over the Announcer's HI by a higher level - authority known to the Recipient is an alternative method for the - Recipient to trust the Announcer's HI (over DNSSEC or PKI). +7.8 CLOSE - the HIP association closing packet - The HIP header values for CER packet: + The HIP header values for the CLOSE packet: Header: Packet Type = 8 - SRC HIT = Announcer's HIT + SRC HIT = Sender's HIT DST HIT = Recipient's HIT - IP ( HIP ( i , HIP_SIGNATURE ) ) or - - IP ( HIP ( ENCRYPTED { i }, HIP_SIGNATURE ) ) - - Valid control bits: None + IP ( HIP ( ECHO_REQUEST, HMAC, HIP_SIGNATURE ) ) + Valid control bits: none - Certificates in the CER packet MAY be encrypted. The encryption - algorithm is provided in the HIP transform of the previous (R1 or I2) - packet. + The sender MUST include an ECHO_REPLY used to validate CLOSE_ACK + received in response, and both an HMAC and a signature (calculated + over the whole HIP envelope). -7.8 NOTIFY - the HIP Notify Packet + The receiver peer MUST validate both the HMAC and the signature if it + has a HIP association state, and MUST reply with a CLOSE_ACK + containing an ECHO_REPLY corresponding to the received ECHO_REQUEST. - The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to - provide information to a peer. Typically, NOTIFY is used to indicate - some type of protocol error or negotiation failure. +7.9 CLOSE_ACK - the HIP closing acknowledgment packet - The HIP header values for the NOTIFY packet: + The HIP header values for the CLOSE_ACK packet: Header: Packet Type = 9 SRC HIT = Sender's HIT - DST HIT = Recipient's HIT, or zero if unknown - - IP ( HIP (i, [HOST_ID, ] HIP_SIGNATURE) ) - - Valid control bits: None - - The NOTIFY packet is used to carry one or more NOTIFY parameters. - -7.9 PAYLOAD - the HIP Payload Packet - - The PAYLOAD packet is OPTIONAL. - - The HIP header values for the PAYLOAD packet: - - Header: - Packet Type = 64 - SRC HIT = Sender's HIT DST HIT = Recipient's HIT - IP ( HIP ( ), payload ) - - Valid control bits: None + IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) - Payload Proto field in the Header MUST be set to correspond the - correct protocol number of the payload. + Valid control bits: none - The PAYLOAD packet is used to carry a non-ESP protected data. By - using the HIP header we ensure interoperability with NAT and other - middle boxes. + The sender MUST include both an HMAC and signature (calculated over + the whole HIP envelope). - Processing rules of the PAYLOAD packet are the following: - Receiving: If there is an existing HIP security association with the - given HITs, and the IP addresses match the IP addresses associated - with the HITs, pass the packet to the upper layer, tagged with - metadata indicating that the packet was NOT integrity or - confidentiality protected. - Sending: If the IPsec SPD defines BYPASS for a given destination - HIT, send it with the PAYLOAD packet. Otherwise use ESP as - specified in the SPD. + The receiver peer MUST validate both the HMAC and the signature. 8. Packet processing Each host is assumed to have a single HIP protocol implementation that manages the host's HIP associations and handles requests for new ones. Each HIP association is governed by a conceptual state machine, with states defined above in Section 5.4. The HIP implementation can simultaneously maintain HIP associations with more than one host. Furthermore, the HIP implementation may have more than one active HIP association with another host; in this case, HIP @@ -2444,21 +2645,21 @@ In a HIP host, an application can send application level data using HITs or LSIs as source and destination identifiers. The HITs and LSIs may be specified via a backwards compatible API (see Appendix A) or a completely new API. However, whenever there is such outgoing data, the stack has to protect the data with ESP, and send the resulting datagram using appropriate source and destination IP addresses. Here, we specify the processing rules only for the base case where both hosts have only single usable IP addresses; the multi-address multi-homing case will be specified separately. - If the IPv4 backward compatible APIs and therefore LSIs are + If the IPv4 or IPv6 backward compatible APIs and therefore LSIs are supported, it is assumed that the LSIs will be converted into proper HITs somewhere in the stack. The exact location of the conversion is an implementation specific issue and not discussed here. The following conceptual algorithm discusses only HITs, with the assumption that the LSI-to-HIT conversion takes place somewhere. The following steps define the conceptual processing rules for outgoing datagrams destined to a HIT. 1. If the datagram has a specified source address, it MUST be a HIT. If it is not, the implementation MAY replace the source address @@ -2472,21 +2673,21 @@ 3. If there no active HIP session with the given < source, destination > HIT pair, one must be created by running the base exchange. The implementation SHOULD queue at least one packet per HIP session to be formed, and it MAY queue more than one. 4. Once there is an active HIP session for the given < source, destination > HIT pair, the outgoing datagram is protected using the associated ESP security association. In a typical implementation, this will result in an transport mode ESP datagram that still has HITs in the place of IP addresses. 5. The HITs in the datagram are replaced with suitable IP addresses. - For IPv6, the rules defined in [15] SHOULD be followed. Note + For IPv6, the rules defined in [16] SHOULD be followed. Note that this HIT-to-IP-address conversion step MAY also be performed at some other point in the stack, e.g., before ESP processing. However, care must be taken to make sure that the right ESP SA is employed. 8.2 Processing incoming application data Incoming HIP datagrams arrive as ESP protected packets. In the usual case the receiving host has a corresponding ESP security association, identified by the SPI and destination IP address in the packet. @@ -2515,50 +2716,62 @@ datagram the right upper layer socket is based on the HITs (or LSIs). 8.3 HMAC and SIGNATURE calculation and verification The following subsections define the actions for processing HMAC, HIP_SIGNATURE and HIP_SIGNATURE_2 TLVs. 8.3.1 HMAC calculation - The HMAC TLV is defined in Section 6.2.12. HMAC calculation and - verification process: + The following process applies both to the HMAC and HMAC_2 TLVs. When + processing HMAC_2, the difference is that the HMAC calculation + includes pseudo HOST_ID field containing the Responder's information + as sent in the R1 packet earlier. + + The HMAC TLV is defined in Section 6.2.12 and HMAC_2 TLV in Section + 6.2.13. HMAC calculation and verification process: Packet sender: 1. Create the HIP packet, without the HMAC or any possible HIP_SIGNATURE or HIP_SIGNATURE_2 TLVs. - 2. Calculate the Length field in the HIP header. - 3. Compute the HMAC. - 4. Add the HMAC TLV to the packet and any HIP_SIGNATURE or + 2. In case of HMAC_2 calculation, add a HOST_ID (Responder) TLV to + the packet. + 3. Calculate the Length field in the HIP header. + 4. Compute the HMAC. + 5. In case of HMAC_2, remove the HOST_ID TLV from the packet. + 6. Add the HMAC TLV to the packet and any HIP_SIGNATURE or HIP_SIGNATURE_2 TLVs that may follow. - 5. Recalculate the Length field in the HIP header. + 7. Recalculate the Length field in the HIP header. Packet receiver: 1. Verify the HIP header Length field. - 2. Remove the HMAC TLV, and if the packet contains any HIP_SIGNATURE - or HIP_SIGNATURE_2 fields, remove them too, saving the contents - if they will be needed later. - 3. Recalculate the HIP packet length in the HIP header and clear the + 2. Remove the HMAC or HMAC_2 TLV, and if the packet contains any + HIP_SIGNATURE or HIP_SIGNATURE_2 fields, remove them too, saving + the contents if they will be needed later. + 3. In case of HMAC_2, build and add a HOST_ID TLV (with Responder + information) to the packet. + 4. Recalculate the HIP packet length in the HIP header and clear the Checksum field (set it to all zeros). - 4. Compute the HMAC and verify it against the received HMAC. + 5. Compute the HMAC and verify it against the received HMAC. + 6. In case of HMAC_2, remove the HOST_ID TLV from the packet before + further processing. 8.3.2 Signature calculation The following process applies both to the HIP_SIGNATURE and HIP_SIGNATURE_2 TLVs. When processing HIP_SIGNATURE_2, the only difference is that instead of HIP_SIGNATURE TLV, the HIP_SIGNATURE_2 TLV is used, and the Initiator's HIT and PUZZLE Opaque and Random #I fields are cleared (set to all zeros) before computing the signature. - The HIP_SIGNATURE TLV is defined in Section 6.2.13 and the - HIP_SIGNATURE_2 TLV in Section 6.2.14. + The HIP_SIGNATURE TLV is defined in Section 6.2.14 and the + HIP_SIGNATURE_2 TLV in Section 6.2.15. Signature calculation and verification process: Packet sender: 1. Create the HIP packet without the HIP_SIGNATURE TLV or any TLVs that follow the HIP_SIGNATURE TLV. 2. Calculate the Length field in the HIP header. 3. Compute the signature. 4. Add the HIP_SIGNATURE TLV to the packet. 5. Add any TLVs that follow the HIP_SIGNATURE TLV. @@ -2674,22 +2886,24 @@ responding to an I1 packet: 1. The responder MUST check that the responder HIT in the received I1 is either one of its own HITs, or NULL. 2. If the responder is in ESTABLISHED state, the responder MAY respond to this with an R1 packet, prepare to drop existing SAs and stay at ESTABLISHED state. 3. If the implementation chooses to respond to the I1 with and R1 packet, it creates a new R1 or selects a precomputed R1 according to the format described in Section 7.2. 4. The R1 MUST contain the received responder HIT, unless the - received HIT is NULL, in which case the Responder may freely - select among its HITs. + received HIT is NULL, in which case the Responder SHOULD select a + HIT that is constructed with the MUST algorithm in Section 3, + which is currently RSA. Other than that, selecting the HIT is a + local policy matter. 5. The responder sends the R1 to the source IP address of the I1 packet. 8.5.1 R1 Management All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time Delta T, which is implementation dependent. R1 information MUST not be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the responder. @@ -2702,22 +2916,22 @@ If an implementation receives a malformed I1 message, it SHOULD NOT respond with a NOTIFY message, as such practice could open up a potential denial-of-service danger. Instead, it MAY respond with an ICMP packet, as defined in Section 6.3. 8.6 Processing incoming R1 packets A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it is in state I1-SENT). If so, it SHOULD process the R1 as described below, send an I2, and go to - state I2-SENT, setting a timer to protect the I2. If the system is in - state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 + state I2-SENT, setting a timer to protect the I2. If the system is + in state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 generation counter; if so, it should drop its state due to processing the previous R1 and start over from state I1-SENT. If the system is in any other state with respect to that host, it SHOULD silently drop the R1. When sending multiple I1s, an initiator SHOULD wait for a small amount of time after the first R1 reception to allow possibly multiple R1s to arrive, and it SHOULD respond to an R1 among the set with the largest R1 generation counter. @@ -2729,48 +2943,45 @@ the HITs in the R1). If so, it should process the R1 as described below. 2. Otherwise, if the system is in any other state than I1-SENT or I2-SENT with respect to the HITs included in the R1, it SHOULD silently drop the R1 and remain in the current state. 3. If the HIP association state is I1-SENT or I2-SENT, the received Initiator's HIT MUST correspond to the HIT used in the original, I1 and the Responder's HIT MUST correspond to the one used, unless the I1 contained a NULL HIT. 4. The system SHOULD validate the R1 signature before applying - further packet processing, according to Section 6.2.14. + further packet processing, according to Section 6.2.15. 5. If the HIP association state is I1-SENT, and multiple valid R1s are present, the system SHOULD select from among the R1s with the largest R1 generation counter. 6. If the HIP association state is I2-SENT, the system MAY reenter state I1-SENT and process the received R1 if it has a larger R1 generation counter than the R1 responded to previously. + 7. The R1 packet may have the C bit set -- in this case, the system should anticipate the receipt of HIP CER packets that contain the host identity corresponding to the responder's HIT. 8. The R1 packet may have the A bit set -- in this case, the system MAY choose to refuse it by dropping the R1 and returning to state UNASSOCIATED. The system SHOULD consider dropping the R1 only if it used a NULL HIT in I1. If the A bit is set, the Responder's HIT is anonymous and should not be stored. - 9. The system SHOULD attempt to validate the HIT against the received Host Identity. 10. The system MUST store the received R1 generation counter for future reference. 11. The system attempts to solve the cookie puzzle in R1. The - system MUST terminate the search after a number of tries, the - minimum of the degree of difficulty specified by the K value or - an implementation- or policy-defined maximum retry count. It is - RECOMMENDED that the system does not try more than 2^(K+2) - times. If the cookie puzzle is not successfully solved, the - implementation may either resend I1 within the retry bounds or - abandon the HIP exchange. + system MUST terminate the search after exceeding the remaining + lifetime of the puzzle. If the cookie puzzle is not + successfully solved, the implementation may either resend I1 + within the retry bounds or abandon the HIP exchange. 12. The system computes standard Diffie-Hellman keying material according to the public value and Group ID provided in the DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material Kij is used for key extraction as specified in Section 9. If the received Diffie-Hellman Group ID is not supported, the implementation may either resend I1 within the retry bounds or abandon the HIP exchange. 13. The system selects the HIP transform and ESP transform from the choices presented in the R1 packet and uses the selected values subsequently when generating and using encryption keys, and when @@ -2844,47 +3055,49 @@ on the public value and Group ID in the DIFFIE_HELLMAN parameter. This key is used to derive the HIP and ESP association keys, as described in Section 9. If the Diffie-Hellman Group ID is unsupported, the I2 packet is silently dropped. 8. The encrypted HOST_ID decrypted by the Initiator encryption key defined in Section 9. If the decrypted data is not an HOST_ID parameter, the I2 packet is silently dropped. 9. The implementation SHOULD also verify that the Initiator's HIT in the I2 corresponds to the Host Identity sent in the I2. - 10. The system MUST verify the HIP_SIGNATURE according to Section - 6.2.13 and Section 7.3. - 11. If the checks above are valid, then the system proceeds with + 10. The system MUST verify the HMAC according to the procedures in + Section 6.2.12. + 11. The system MUST verify the HIP_SIGNATURE according to Section + 6.2.14 and Section 7.3. + 12. If the checks above are valid, then the system proceeds with further I2 processing; otherwise, it discards the I2 and remains in the same state. - 12. The I2 packet may have the C bit set -- in this case, the system + 13. The I2 packet may have the C bit set -- in this case, the system should anticipate the receipt of HIP CER packets that contain the host identity corresponding to the responder's HIT. - 13. The I2 packet may have the A bit set -- in this case, the system + 14. The I2 packet may have the A bit set -- in this case, the system MAY choose to refuse it by dropping the I2 and returning to state UNASSOCIATED. If the A bit is set, the Initiator's HIT is anonymous and should not be stored. - 14. The SPI field is parsed to obtain the SPI that will be used for + 15. The SPI field is parsed to obtain the SPI that will be used for the Security Association outbound from the Responder and inbound to the Initiator. - 15. The system prepares and creates both incoming and outgoing ESP + 16. The system prepares and creates both incoming and outgoing ESP security associations. - 16. The system initialized the remaining variables in the associated + 17. The system initialized the remaining variables in the associated state, including Update ID counters. - 17. Upon successful processing of an I2 in states UNASSOCIATED, + 18. Upon successful processing of an I2 in states UNASSOCIATED, I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state machine transitions to state ESTABLISHED. - 18. Upon successful processing of an I2 in state ESTABLISHED/ + 19. Upon successful processing of an I2 in state ESTABLISHED/ REKEYING, the old Security Association is dropped and a new one is installed, an R2 is sent, and the state machine transitions to R2-SENT, dropping any possibly ongoing rekeying attempt. - 19. Upon transitioning to R2-SENT, start a timer. Leave R2-SENT if + 20. Upon transitioning to R2-SENT, start a timer. Leave R2-SENT if either the timer expires (allowing for maximal retransmission of I2s), some data has been received on the incoming SA, or an UPDATE packet has been received (or some other packet that indicates that the peer has moved to ESTABLISHED). 8.7.1 Handling malformed messages If an implementation receives a malformed I2 message, the behaviour SHOULD depend on how much checks the message has already passed. If the puzzle solution in the message has already been checked, the @@ -2896,24 +3109,24 @@ An R2 received in states UNASSOCIATED, I1-SENT, ESTABLISHED, or REKEYING results in the R2 being dropped and the state machine staying in the same state. If an R2 is received in state I2-SENT, it SHOULD be processed. The following steps define the conceptual processing rules for incoming R2 packet: 1. The system MUST verify that the HITs in use correspond to the HITs that were received in R1. - 2. The system MUST verify the HMAC according to the procedures in - Section 6.2.12. + 2. The system MUST verify the HMAC_2 according to the procedures in + Section 6.2.13. 3. The system MUST verify the HIP signature according to the - procedures in Section 6.2.13. + procedures in Section 6.2.14. 4. If any of the checks above fail, there is a high probability of an ongoing man-in-the-middle or other security attack. The system SHOULD act accordingly, based on its local policy. 5. If the system is in any other state than I2-SENT, the R2 is silently dropped. 6. The SPI field is parsed to obtain the SPI that will be used for the ESP Security Association inbound to the Responder. The system uses this SPI to create or activate the outgoing ESP security association used to send packets to the peer. 7. Upon successful processing of the R2, the state machine moves to @@ -2989,25 +3202,28 @@ (with higher Update IDs) while in state REKEYING, unless it is restarting the rekeying process. 8.11 Processing UPDATE packets When a system receives an UPDATE packet, its processing depends on the state of the HIP association and the presence of and values of the SEQ and ACK parameters. An UPDATE MUST be processed if the following conditions hold (note: UPDATEs may also be processed when additional conditions hold, as specified in other drafts): - 1. The state of the HIP association is ESTABLISHED or REKEYING, and + 1. If there is no corresponding HIP association, the implementation + MAY reply with an ICMP Parameter Problem, as specified in Section + 6.3.5. + 2. The state of the HIP association is ESTABLISHED or REKEYING, and both the SEQ and NES parameters are present in the UPDATE. This is the case for which the peer host is in the process of rekeying. - 2. The state of the HIP association is REKEYING and an ACK (of + 3. The state of the HIP association is REKEYING and an ACK (of outstanding Update ID) is in the UPDATE. This case usually corresponds to the peer completing the rekeying process first. If the above conditions hold, the following steps define the conceptual processing rules for handling a received UPDATE packet: 1. If the SEQ parameter is present, and the Update ID in the received SEQ is smaller than the stored Update ID for the host, the packet MUST BE dropped. 2. If the SEQ parameter is present, and the Update ID in the received SEQ is equal to the stored Update ID for the host, the @@ -3063,29 +3280,29 @@ 5. The system sends the UPDATE packet and transitions to state REKEYING. The system stores any received NES and DIFFIE_HELLMAN parameters. At this point, it only needs to receive an ACK of its current Update ID to finish rekeying. 8.11.2 Processing an UPDATE packet in state REKEYING The following steps define the conceptual processing rules responding handling a received reply UPDATE packet: 1. If the packet contains a SEQ and NES parameters, then the system - generates a new UPDATE packet with an ACK of the peer's Update ID - as received in the SEQ parameter. Additionally, if the UPDATE - packet contained an ACK of the outstanding Update ID, or if the - ACK of the UPDATE packet that contained the NES has already been + sends a new UPDATE packet with an ACK of the peer's Update ID as + received in the SEQ parameter. Additionally, if the UPDATE packet + contained an ACK of the outstanding Update ID, or if the ACK of + the UPDATE packet that contained the NES has already been received, the system stores the received NES and (optional) DIFFIE_HELLMAN parameters and finishes the rekeying procedure as described in Section 8.11.3. If the ACK of the outstanding Update ID has not been received, stay in state REKEYING after storing - the recived NES and (optional) DIFFIE_HELLMAN. + the received NES and (optional) DIFFIE_HELLMAN. 2. If the packet contains an ACK parameter that ACKs the outstanding Update ID, and the system has previously received a NES from the peer, the system finishes the rekeying procedure as described in Section 8.11.3. If the system is still waiting for the peer's NES parameter (to arrive in subsequent UPDATE message), the system stays in state REKEYING. 8.11.3 Leaving REKEYING state A system leaves REKEYING state when it has received both a NES from @@ -3106,39 +3323,61 @@ value from the UPDATE. The SPI for the incoming SA was generated when NES was sent. The order of the keys retrieved from the KEYMAT during rekeying process is similar to that described in Section 9. Note, that only IPsec ESP keys are retrieved during rekeying process, not the HIP keys. 4. The system cancels any timers protecting the UPDATE and transitions to ESTABLISHED. 5. The system starts to send to the new outgoing SA and prepares to start receiving data on the new incoming SA. -8.12 Processing BOS packets - - Processing BOS packets is OPTIONAL, and currently undefined. - -8.13 Processing CER packets +8.12 Processing CER packets Processing CER packets is OPTIONAL, and currently undefined. -8.14 Processing PAYLOAD packets - - Processing PAYLOAD packets is OPTIONAL, and currently undefined. - -8.15 Processing NOTIFY packets +8.13 Processing NOTIFY packets Processing NOTIFY packets is OPTIONAL. If processed, any errors noted by the NOTIFY parameter SHOULD be taken into account by the HIP state machine (e.g., by terminating a HIP handshake), and the error SHOULD be logged. +8.14 Processing CLOSE packets + + When the host receives a CLOSE message it responds with a CLOSE_ACK + message and moves to CLOSED state. (The authenticity of the CLOSE + message is verified using both HMAC and SIGNATURE). This processing + applies whether or not the HIP association state is CLOSING in order + to handle CLOSE messages from both ends crossing in flight. + + The HIP association is not discarded before the host moves from the + UNASSOCIATED state. + + Once the closing process has started, any need to send data packets + will trigger creating and establishing of a new HIP association, + starting with sending an I1. + + If there is no corresponding HIP association, the implementation MAY + reply to a CLOSE with an ICMP Parameter Problem, as specified in + Section 6.3.5. + +8.15 Processing CLOSE_ACK packets + + When a host receives a CLOSE_ACK message it verifies that it is in + CLOSING or CLOSED state and that the CLOSE_ACK was in response to the + CLOSE (using the included ECHO_REPLY in response to the sent + ECHO_REQUEST). + + The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is + discarded when the state changes to UNASSOCIATED and, after that, + NOTIFY is sent as a response to a CLOSE message. + 9. HIP KEYMAT HIP keying material is derived from the Diffie-Hellman Kij produced during the base HIP exchange. The Initiator has Kij during the creation of the I2 packet, and the Responder has Kij once it receives the I2 packet. This is why I2 can already contain encrypted information. The KEYMAT is derived by feeding Kij and the HITs into the following operation; the | operation denotes concatenation. @@ -3174,21 +3413,21 @@ HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets SA-gl ESP encryption key for HOST_g's outgoing traffic SA-gl ESP authentication key for HOST_g's outgoing traffic SA-lg ESP encryption key for HOST_l's outgoing traffic SA-lg ESP authentication key for HOST_l's outgoing traffic The number of bits drawn for a given algorithm is the "natural" size of the keys. For the mandatory algorithms, the following sizes apply: - 3DES 192 bits + AES 128 bits SHA-1 160 bits NULL 0 bits The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using UPDATE will only draw the four ESP keys from KEYMAT. Section 8.11 describes the rules for reusing or regenerating KEYMAT based on the UPDATE exchange. 10. HIP Fragmentation Support @@ -3209,21 +3448,21 @@ does not bring any value to HIP in the IPv4 world. HIP aware NAT systems MUST perform any IPv4 reassembly/fragmentation. All HIP implementations MUST employ a reassembly algorithm that is sufficiently resistant against DoS attacks. 11. ESP with HIP HIP is designed to be used in end-to-end fashion. The IPsec mode used with HIP is the BEET mode (A Bound End-to-End mode for ESP) - [26]. The BEET mode provides some features from both IPsec tunnel + [27]. The BEET mode provides some features from both IPsec tunnel and transport modes. The HIP uses HITs and LSIs as the "inner" addresses and IP addresses as "outer" addresses like IP addresses are used in the tunnel mode. Instead of tunneling packets between hosts, a conversion between inner and outer addresses is made at end-hosts and the inner address is never sent in the wire after the initial HIP negotiation. BEET provides IPsec transport mode syntax (no inner headers) with limited tunnel mode semantics (fixed logical inner addresses - the HITs - and changeable outer IP addresses). Since HIP does not negotiate any lifetimes, all lifetimes are local @@ -3237,23 +3476,23 @@ Each HIP association is linked with two ESP SAs, one incoming and one outgoing. The Initiator's incoming SA corresponds with the Responder's outgoing one. The initiator defines the SPI for this association, as defined in Section 3.3. This SA is called SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the Responder's incoming SA corresponds with the Initiator's outgoing SA and is called SA-IR, with the SPI-IR. The Initiator creates SA-RI as a part of R1 processing, before - sending out the I2, as explained in Section 8.6. The keys are derived - from KEYMAT, as defined in Section 9. The Responder creates SA-RI as - a part of I2 processing, see Section 8.7. + sending out the I2, as explained in Section 8.6. The keys are + derived from KEYMAT, as defined in Section 9. The Responder creates + SA-RI as a part of I2 processing, see Section 8.7. The Responder creates SA-IR as a part of I2 processing, before sending out R2, see Step 17 in Section 8.7. The Initiator creates SA-IR when processing R2, see Step 7 in Section 8.8. 11.2 Updating ESP SAs during rekeying After the initial 4-way handshake and SA establishment, both hosts are in state ESTABLISHED. There are no longer Initiator and Responder roles and the association is symmetric. In this @@ -3292,43 +3531,43 @@ The SPIs in ESP provide a simple compression of the HIP data from all packets after the HIP exchange. This does require a per HIT- pair Security Association (and SPI), and a decrease of policy granularity over other Key Management Protocols like IKE. When a host rekeys, it gets a new SPI from its partner. 11.5 Supported Transforms - All HIP implementations MUST support 3DES [10] and HMAC-SHA-1-96 [6]. + All HIP implementations MUST support AES [10] and HMAC-SHA-1-96 [6]. If the Initiator does not support any of the transforms offered by - the Responder in the R1 HIP packet, it MUST use 3DES and - HMAC-SHA-1-96 and state so in the I2 HIP packet. + the Responder in the R1 HIP packet, it MUST use AES and HMAC-SHA-1-96 + and state so in the I2 HIP packet. - In addition to 3DES, all implementations MUST implement the ESP NULL + In addition to AES, all implementations MUST implement the ESP NULL encryption and authentication algorithms. These algorithms are provided mainly for debugging purposes, and SHOULD NOT be used in production environments. The default configuration in implementations MUST be to reject NULL encryption or authentication. 11.6 Sequence Number The Sequence Number field is MANDATORY in ESP. Anti-replay protection MUST be used in an ESP SA established with HIP. This means that each host MUST rekey before its sequence number reaches 2^32, or if extended sequence numbers are used, 2^64. Note that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman key can be changed, that of the rekeying host. However, if one host rekeys, the other host SHOULD rekey as well. - In some instances, a 32 bit sequence number is inadequate. In the + In some instances, a 32-bit sequence number is inadequate. In the ESP_TRANSFORM parameter, a peer MAY require that a 64 bit sequence number be used. In this case the higher 32 bits are NOT included in the ESP header, but are simply kept local to both peers. 64 bit sequence numbers must only be used for ciphers that will not be open to cryptanalysis as a result. AES is one such cipher. 12. HIP Policies There are a number of variables that will influence the HIP exchanges that each host must support. All HIP implementations MUST support @@ -3402,23 +3641,30 @@ K while under attack. On the downside, valid I2s might get dropped too. A third form of DoS attack is emulating the restart of state after a reboot of one of the partners. A host restarting would send an I1 to a peer, which would respond with an R1 even if it were in state ESTABLISHED. If the I1 were spoofed, the resulting R1 would be received unexpectedly by the spoofed host and would be dropped, as in the first case above. - A fourth form of DoS attack is emulating the end of state. HIP has - no end of state packet. It relies on a local policy timer to end - state. + A fourth form of DoS attack is emulating the end of state. HIP + relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly + signals the end of a state. Because both CLOSE and CLOSE_ACK + messages contain an HMAC, an outsider cannot close a connection. The + presence of an additional SIGNATURE allows middle-boxes to inspect + these messages and discard the associated state (for e.g., + firewalling, SPI-based NATing, etc.). However, the optional behavior + of replying to CLOSE with an ICMP Parameter Problem packet (as + described in Section 6.3.5), might allow an IP spoofer sending CLOSE + messages to launch reflection attacks. A fifth form of DoS attack is replaying R1s to cause the initiator to solve stale puzzles and become out of synchronization with the responder. The R1 generation counter is a monotonically increasing counter designed to protect against this attack, as described in section Section 4.1.3. Man-in-the-middle attacks are difficult to defend against, without third-party authentication. A skillful MitM could easily handle all parts of HIP; but HIP indirectly provides the following protection @@ -3426,20 +3672,27 @@ DNS zone, a certificate, or through some other secure means, the Initiator can use this to validate the R1 HIP packet. Likewise, if the Initiator's HI is in a secure DNS zone, a trusted certificate, or otherwise securely available, the Responder can retrieve it after it gets the I2 HIP packet and validate that. However, since an Initiator may choose to use an anonymous HI, it knowingly risks a MitM attack. The Responder may choose not to accept a HIP exchange with an anonymous Initiator. + If an initiator wants to use opportunistic mode, it is vulnerable to + man-in-the-middle attacks. Furthermore, the available HI types are + limited to the MUST implement algorithms, as per Section 3. Hence, + if a future specification deprecates the current MUST implement + algorithm(s) and replaces it (them) with some new one(s), backward + compatibility cannot be preserved. + Since not all hosts will ever support HIP, ICMP 'Destination Protocol Unreachable' are to be expected and present a DoS attack. Against an Initiator, the attack would look like the Responder does not support HIP, but shortly after receiving the ICMP message, the Initiator would receive a valid R1 HIP packet. Thus to protect from this attack, an Initiator should not react to an ICMP message until a reasonable delta time to get the real Responder's R1 HIP packet. A similar attack against the Responder is more involved. First an ICMP message is expected if the I1 was a DoS attack and the real owner of the spoofed IP address does not support HIP. The Responder SHOULD @@ -3527,63 +3780,66 @@ [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [12] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [13] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. - [14] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 + [14] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [15] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. - [15] Draves, R., "Default Address Selection for Internet Protocol + [16] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. - [16] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + [17] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. - [17] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + [18] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. - [18] Kent, S., "IP Encapsulating Security Payload (ESP)", + [19] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. - [19] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + [20] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. - [20] Moskowitz, R., "Host Identity Protocol Architecture", + [21] Moskowitz, R., "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-03 (work in progress), May 2003. - [21] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. + [22] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 16.2 Informative references - [22] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", + [23] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk-04 (work in progress), July 2002. - [23] Moskowitz, R. and P. Nikander, "Using Domain Name System (DNS) + [24] Moskowitz, R. and P. Nikander, "Using Domain Name System (DNS) with Host Identity Protocol (HIP)", draft-nikander-hip-dns-00 (to be issued) (work in progress), June 2003. - [24] Nikander, P., "SPI assisted NAT traversal (SPINAT) with Host + [25] Nikander, P., "SPI assisted NAT traversal (SPINAT) with Host Identity Protocol (HIP)", draft-nikander-hip-nat-00 (to be issued) (work in progress), June 2003. - [25] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic + [26] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic Complexity Attacks", in Proceedings of Usenix Security Symposium 2003, Washington, DC., August 2003. - [26] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", + [27] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-00 (expired) (work in progress), Oct 2003. Authors' Addresses Robert Moskowitz ICSAlabs, a Division of TruSecure Corporation 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA @@ -3660,20 +3916,39 @@ later time, then another host acquires the old IP address, and the system again receives a request to connect to that IP address, in which case it is ambiguous whether the application wants to connect to the host previously at that IP address or the new host at that address). If HIP is used to support an application, the application data stream may contain either IP addresses or LSIs or HITs in place of the IP addresses. + Historically, the first two bits of a HIT were used to differentiate + between Type 1, Type 2, and IPv6 address formats. This was changed + in October 2004, when the Working Group decided that all (currently + defined) HITs are 128-bit long. Hence, a Type 1 HIT consists of 128 + bits of the SHA-1 hash of the public key, and a Type 2 HIT consists + of a 64-bits long HAA field, followed by a 64-bits of the SHA-1 hash. + [The format of the HAA field is left undefined in this document.] + + In this document, we additionally define an internal IPv6-compatible + LSI representation format, to be used within the legacy + IPv6-compatible API (e.g., socket over AF_INET6). The format of + these IPv6-compatible LSIs is designed to avoid the most commonly + occurring IPv6 addresses in RFC3596 [9]. An IPv6-compatible LSI + representation of a HIT can be easily computed by replacing the first + TBDth bits of the HIT by the TBD bits long prefix "0xTBD". + Accordingly, this specification also RECOMMENDS that conforming + implementations ignore the TBD prefix bits when comparing HITs for + equality; see Section 3.1. + Appendix B. Probabilities of HIT collisions The birthday paradox sets a bound for the expectation of collisions. It is based on the square root of the number of values. A 64-bit hash, then, would put the chances of a collision at 50-50 with 2^32 hosts (4 billion). A 1% chance of collision would occur in a population of 640M and a .001% collision chance in a 20M population. A 128 bit hash will have the same .001% collision chance in a 9x10^16 population. @@ -3707,22 +3982,21 @@ k->inf lim (1 - 2^-k)^(2^(k+3)) = 0.000335 k->inf Thus, if hash functions were random functions, we would need about 2^(K+3) iterations to make sure that the probability of a failure is less than 1% (actually less than 0.04%). Now, since my perhaps flawed understanding of hash functions is that they are "flatter" than random functions, 2^(K+3) is probably an overkill. OTOH, the - currently suggested 2^K is clearly too little. The draft has been - changed to read 2^(K+2). + currently suggested 2^K is clearly too little. Appendix D. Using responder cookies As mentioned in Section 4.1.1, the Responder may delay state creation and still reject most spoofed I2s by using a number of pre-calculated R1s and a local selection function. This appendix defines one possible implementation in detail. The purpose of this appendix is to give the implementors an idea on how to implement the mechanism. The method described in this appendix SHOULD NOT be used in any real implementation. If the implementation is based on this appendix, it @@ -3895,21 +4169,21 @@ Appendix G. 384-bit group This 384-bit group is defined only to be used with HIP. NOTE: The security level of this group is very low! The encryption may be broken in a very short time, even real-time. It should be used only when the host is not powerful enough (e.g. some PDAs) and when security requirements are low (e.g. during normal web surfing). This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 } - Its hexadeciaml value is: + Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF The generator is: 2. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to