< draft-ietf-hip-base-05.txt   draft-ietf-hip-base-06.txt >
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft ICSAlabs, a Division of TruSecure Internet-Draft ICSAlabs, a Division of TruSecure
Expires: September 3, 2006 Corporation Expires: December 17, 2006 Corporation
P. Nikander P. Nikander
P. Jokela (editor) P. Jokela (editor)
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
March 2, 2006 June 15, 2006
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-base-05 draft-ietf-hip-base-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2006. This Internet-Draft will expire on December 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
HIP allows consenting hosts to securely establish and maintain shared HIP allows consenting hosts to securely establish and maintain shared
IP-layer state, allowing separation of the identifier and locator IP-layer state, allowing separation of the identifier and locator
skipping to change at page 2, line 19 skipping to change at page 2, line 19
middle (MitM) attacks, and when used together with another suitable middle (MitM) attacks, and when used together with another suitable
security protocol, such as Encapsulated Security Payload (ESP), it security protocol, such as Encapsulated Security Payload (ESP), it
provides integrity protection and optional encryption for upper layer provides integrity protection and optional encryption for upper layer
protocols, suchs as TCP and UDP. Discussion related to this document protocols, suchs as TCP and UDP. Discussion related to this document
is going on at the IETF HIP Working Group mailing list. is going on at the IETF HIP Working Group mailing list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5 1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5
1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 6 1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 6
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
3. Host Identifier (HI) and its Representations . . . . . . . . 9 3. Host Identifier (HI) and its Representations . . . . . . . . 10
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 10 3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 13
4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14 4.1.2. Puzzle exchange . . . . . . . . . . . . . . . . . . . 14
4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15 4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 15
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 16
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17 4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 17
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 17 4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19
4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20
4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 20 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 21
4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 27 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 28
4.5. User Data Considerations . . . . . . . . . . . . . . . . 29 4.5. User Data Considerations . . . . . . . . . . . . . . . . 30
4.5.1. TCP and UDP Pseudo-header Computation for User Data . 29 4.5.1. TCP and UDP Pseudo-header Computation for User Data . 30
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 29 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 30
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 29 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 30
4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 29 4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 30
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 30 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 31
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 31 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 32
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 32 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 33
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 32 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 33
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 33 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 34
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 33 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 34
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 35 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 36
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 36 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 37
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 37 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 38
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 39 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 40
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 40 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 41
5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 41 5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 42
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 44 5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 45
5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 45 5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 46
5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 47 5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 48
5.2.16. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.16. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.17. ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 51 5.2.17. ECHO_REQUEST . . . . . . . . . . . . . . . . . . . . 52
5.2.18. ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . . 52 5.2.18. ECHO_RESPONSE . . . . . . . . . . . . . . . . . . . . 53
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 52 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 53 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 54
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 54 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 55
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 55 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 56
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 57 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 58
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 57 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 58
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 58 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 59
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 59 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 60
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 59 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 60
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 59 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 60
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 60 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 61
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 60 Structure . . . . . . . . . . . . . . . . . . . . . . 61
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 60 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 61
5.4.4. Non-existing HIP Association . . . . . . . . . . . . 60 5.4.4. Non-existing HIP Association . . . . . . . . . . . . 61
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 62 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 63
6.1. Processing Outgoing Application Data . . . . . . . . . . 62 6.1. Processing Outgoing Application Data . . . . . . . . . . 63
6.2. Processing Incoming Application Data . . . . . . . . . . 63 6.2. Processing Incoming Application Data . . . . . . . . . . 64
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 64 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 65
6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 65 6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 66
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 65 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 66
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 66 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 67
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 67 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 68
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 68 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 69
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 69 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 70
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 70 Messages . . . . . . . . . . . . . . . . . . . . . . 71
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 70
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 71 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 71
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 71 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 72
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 71 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 72
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 73 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 72
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 74 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 75
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 76 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 75
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 76 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 77
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 77 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 77
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 78 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 78
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 79
6.12.1. Handling a SEQ parameter in a received UPDATE 6.12.1. Handling a SEQ parameter in a received UPDATE
message . . . . . . . . . . . . . . . . . . . . . . . 78 message . . . . . . . . . . . . . . . . . . . . . . . 80
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 79 Packet . . . . . . . . . . . . . . . . . . . . . . . 80
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 80 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 81
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 80 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 81
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 80 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 81
6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 80 6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 81
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 81 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 83
8. Security Considerations . . . . . . . . . . . . . . . . . . . 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.1. Normative References . . . . . . . . . . . . . . . . . . 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 93
11.2. Informative References . . . . . . . . . . . . . . . . . 92 11.2. Informative References . . . . . . . . . . . . . . . . . 94
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 94 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 96
Appendix B. Generating a HIT from a HI . . . . . . . . . . . . . 95 Appendix B. Generating a Public Key Encoding from a HI . . . . . 97
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 96 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 98
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 96 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 98
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 96 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 98
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 96 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 98
Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 98 Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101
Intellectual Property and Copyright Statements . . . . . . . . . 100 Intellectual Property and Copyright Statements . . . . . . . . . 102
1. Introduction 1. Introduction
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
A high-level description of the protocol and the underlying A high-level description of the protocol and the underlying
architectural thinking is available in the separate HIP architecture architectural thinking is available in the separate HIP architecture
description [26]. Briefly, the HIP architecture proposes an description [26]. Briefly, the HIP architecture proposes an
alternative to the dual use of IP addresses as "locators" (routing alternative to the dual use of IP addresses as "locators" (routing
labels) and "identifiers" (endpoint, or host, identifiers). In HIP, labels) and "identifiers" (endpoint, or host, identifiers). In HIP,
public cryptographic keys, of a public/private key pair, are used as public cryptographic keys, of a public/private key pair, are used as
Host Identifiers, to which higher ayer protocols are bound instead of Host Identifiers, to which higher layer protocols are bound instead
an IP address. By using public keys (and their representations) as of an IP address. By using public keys (and their representations)
host identifiers, dynamic changes to IP address sets can be directly as host identifiers, dynamic changes to IP address sets can be
authenticated between hosts and if desired, strong authentication directly authenticated between hosts and if desired, strong
between hosts at the TCP/IP stack level can be obtained. authentication between hosts at the TCP/IP stack level can be
obtained.
This memo specifies the base HIP protocol ("base exchange") used This memo specifies the base HIP protocol ("base exchange") used
between hosts to establish an IP-layer communications context, called between hosts to establish an IP-layer communications context, called
HIP association, prior to communications. It also defines a packet HIP association, prior to communications. It also defines a packet
format and procedures for updating an active HIP association. Other format and procedures for updating an active HIP association. Other
elements of the HIP architecture are specified in other documents, elements of the HIP architecture are specified in other documents,
including how HIP can be combined with a variant of the Encapsulating including how HIP can be combined with a variant of the Encapsulating
Security Payload (ESP) for integrity protection and optional Security Payload (ESP) for integrity protection and optional
encryption, mobility and multi-homing extensions to HIP, extensions encryption, mobility and multi-homing extensions to HIP, extensions
to the Domain Name System (DNS) for storing Host Identities there, to the Domain Name System (DNS) for storing Host Identities there,
skipping to change at page 8, line 5 skipping to change at page 9, line 5
expected to spend in the network. expected to spend in the network.
Exchange Complete (EC): Time that the host spends at the R2-SENT Exchange Complete (EC): Time that the host spends at the R2-SENT
before it moves to ESTABLISHED state. The time is n * I2 before it moves to ESTABLISHED state. The time is n * I2
retransmission timeout, where n ~ I2_RETRIES_MAX. retransmission timeout, where n ~ I2_RETRIES_MAX.
HIT Hash Algorithm: hash algorithm used to generate a Host Identity HIT Hash Algorithm: hash algorithm used to generate a Host Identity
Tag (HIT) from the Host Identity public key. Currently SHA-1 [25] Tag (HIT) from the Host Identity public key. Currently SHA-1 [25]
is used. is used.
Puzzle Hash Algorithm (PHASH): hash algorithm used to calculate the Responder's HIT Hash Algorithm (RHASH): hash algorithm used for
puzzle hash. The algorithm is the same as is used to generate the various hash calculations in this document. The algorithm is the
Responder's HIT. same as is used to generate the Responder's HIT. RHASH can be
determined by inspecting the Prefix of the ORCHID (HIT). The
Prefix value has a one-to-one mapping to a hash function.
Opportunistic mode: HIP base exchange where the Responder's HIT is Opportunistic mode: HIP base exchange where the Responder's HIT is
not a priori known to the Initiator. not a priori known to the Initiator.
3. Host Identifier (HI) and its Representations 3. Host Identifier (HI) and its Representations
In this section, the properties of the Host Identifier and Host In this section, the properties of the Host Identifier and Host
Identifier Tag are discussed, and the exact format for them is Identifier Tag are discussed, and the exact format for them is
defined. In HIP, public key of an asymmetric key pair is used as the defined. In HIP, public key of an asymmetric key pair is used as the
Host Identifier (HI). Correspondingly, the host itself is defined as Host Identifier (HI). Correspondingly, the host itself is defined as
skipping to change at page 9, line 47 skipping to change at page 10, line 47
3.1. Host Identity Tag (HIT) 3.1. Host Identity Tag (HIT)
The Host Identity Tag is a 128 bits long value -- a hashed encoding The Host Identity Tag is a 128 bits long value -- a hashed encoding
of the Host Identifier. There are two advantages of using a hashed of the Host Identifier. There are two advantages of using a hashed
encoding over the actual Host Identity public key in protocols. encoding over the actual Host Identity public key in protocols.
Firstly, its fixed length makes for easier protocol coding and also Firstly, its fixed length makes for easier protocol coding and also
better manages the packet size cost of this technology. Secondly, it better manages the packet size cost of this technology. Secondly, it
presents a consistent format to the protocol whatever underlying presents a consistent format to the protocol whatever underlying
identity technology is used. identity technology is used.
"A Non-Routable IPv6 Prefix for Keyed Hash Identifiers" [22] has been "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
specified to store 128-bit hash based identifier called Keyed Hash (ORCHID)" [22] has been specified to store 128-bit hash based
Identifier (KHI) under an 8-bit prefix, proposed to be allocated from identifier called Overlay Routable Cryptographic Hash Identifiers
the IPv6 address block 1000::/4. The Host Identity Tag is a KHI (ORCHID) under an 28-bit prefix, proposed to be allocated from the
valid for the Context ID [22] value for HIP, 0xF0EF F02F BFF4 3D0F IPv6 address block as defined in [22]. The Host Identity Tag is a
E793 0C3C 6E61 74EA (The tag value has been generated randomly by the type of ORCHID, based on a SHA1 hash of the host identity (Section 2
editor of this specification.) The following figure shows, for of [22].
informal purposes only, the format of a HIT specified by [22], and
used in this document:
1
0 2
0 1 2 3 4 5 6 7 8 ... 7
+-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix | Hash |
+-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix (8 bits) - Fixed prefix, TBD (0x11, TO BE DISCUSSED), as
defined per [22].
Encoding (120 bits) - Encoding of the public key and KHI context
identifier as defined per [22].
Additional values for the prefix (including different hash
algorithms, or other information) may be defined in the future. A
host may receive a HIT for which it does not understand the prefix.
In such a case, it will not be able to check the mapping between HI
and HIT.
3.2. Generating a HIT from a HI 3.2. Generating a HIT from a HI
The HIT MUST be generated according to the KHI generation method The HIT MUST be generated according to the ORCHID generation method
described in [22] using a context ID value of 0xF0EF F02F BFF4 3D0F described in [22] using a context ID value of 0xF0EF F02F BFF4 3D0F
E793 0C3C 6E61 74EA, and an input encoding the Host Identity field E793 0C3C 6E61 74EA (this tag value has been generated randomly by
(see Section 5.2.8) present in a HIP payload packet. the editor of this specification), and an input encoding the Host
Identity field (see Section 5.2.8) present in a HIP payload packet.
For Identities that are either RSA or DSA public keys, this input For Identities that are either RSA or DSA public keys, this input
consists of the public key encoding as specified in the corresponding consists of the public key encoding as specified in the corresponding
DNSSEC document, taking the algorithm specific portion of the RDATA DNSSEC document, taking the algorithm specific portion of the RDATA
part of the KEY RR. There is currently only two defined public key part of the KEY RR. There is currently only two defined public key
algorithms: RSA and DSA. Hence, either of the following applies: algorithms: RSA and DSA. Hence, either of the following applies:
The RSA public key is encoded as defined in RFC3110 [15] Section The RSA public key is encoded as defined in RFC3110 [15] Section
2, taking the exponent length (e_len), exponent (e) and modulus 2, taking the exponent length (e_len), exponent (e) and modulus
(n) fields concatenated. The length (n_len) of the modulus (n) (n) fields concatenated. The length (n_len) of the modulus (n)
skipping to change at page 14, line 45 skipping to change at page 14, line 45
The Responder can set the puzzle difficulty for Initiator, based on The Responder can set the puzzle difficulty for Initiator, based on
its level of trust of the Initiator. The Responder SHOULD use its level of trust of the Initiator. The Responder SHOULD use
heuristics to determine when it is under a denial-of-service attack, heuristics to determine when it is under a denial-of-service attack,
and set the puzzle difficulty value K appropriately; see below. and set the puzzle difficulty value K appropriately; see below.
4.1.2. Puzzle exchange 4.1.2. Puzzle exchange
The Responder starts the puzzle exchange when it receives an I1. The The Responder starts the puzzle exchange when it receives an I1. The
Responder supplies a random number I, and requires the Initiator to 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 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 concatenation of I, the HITs of the parties, and J, and take a hash
hash over this concatenation. The lowest order K bits of the result over this concatenation using RHASH algorithm. The lowest order K
MUST be zeros. The value K sets the difficulty of the puzzle. bits of the result MUST be zeros. The value K sets the difficulty of
the puzzle.
To generate a proper number J, the Initiator will have to generate a 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 number of Js until one produces the hash target of zero. The
Initiator SHOULD give up after exceeding the puzzle lifetime in the Initiator SHOULD give up after exceeding the puzzle lifetime in the
PUZZLE parameter (Section 5.2.4). The Responder needs to re-create PUZZLE parameter (Section 5.2.4). The Responder needs to re-create
the concatenation of I, the HITs, and the provided J, and compute the the concatenation of I, the HITs, and the provided J, and compute the
hash once to prove that the Initiator did its assigned task. hash once to prove that the Initiator did its assigned task.
To prevent pre-computation attacks, the Responder MUST select the To prevent pre-computation attacks, the Responder MUST select the
number I in such a way that the Initiator cannot guess it. number I in such a way that the Initiator cannot guess it.
skipping to change at page 15, line 44 skipping to change at page 15, line 45
bound function should be used for the puzzle instead of a CPU bound bound function should be used for the puzzle instead of a CPU bound
function. The decision was not to use memory bound functions. At function. The decision was not to use memory bound functions. At
the time of the decision the idea of memory bound functions was the time of the decision the idea of memory bound functions was
relatively new and their IPR status were unknown. Once there is more relatively new and their IPR status were unknown. Once there is more
experience about memory bound functions and once their IPR status is experience about memory bound functions and once their IPR status is
better known, it may be reasonable to reconsider this decision. better known, it may be reasonable to reconsider this decision.
4.1.3. Authenticated Diffie-Hellman Protocol 4.1.3. Authenticated Diffie-Hellman Protocol
The packets R1, I2, and R2 implement a standard authenticated Diffie- The packets R1, I2, and R2 implement a standard authenticated Diffie-
Hellman exchange. The Responder sends its public Diffie-Hellman key Hellman exchange. The Responder sends one or two public Diffie-
and its public authentication key, i.e., its host identity, in R1. Hellman keys and its public authentication key, i.e., its host
The signature in R1 allows the Initiator to verify that the R1 has identity, in R1. The signature in R1 allows the Initiator to verify
been once generated by the Responder. However, since it is that the R1 has been once generated by the Responder. However, since
precomputed and therefore does not cover all of the packet, it does it is precomputed and therefore does not cover all of the packet, it
not protect from replay attacks. does not protect from replay attacks.
When the Initiator receives an R1, it computes the Diffie-Hellman When the Initiator receives an R1, it gets one or two public Diffie-
session key. It creates a HIP association using keying material from Hellman values from the Responder. If there are two values, it
the session key (see Section 6.5), and may use the association to selects the value corresponding to the strongest supported Group ID.
encrypt its public authentication key, i.e., host identity. The and computes the Diffie-Hellman session key. It creates a HIP
resulting I2 contains the Initiator's Diffie-Hellman key and its association using keying material from the session key (see
(optionally encrypted) public authentication key. The signature in Section 6.5), and may use the association to encrypt its public
I2 covers all of the packet. authentication key, i.e., host identity. The resulting I2 contains
the Initiator's Diffie-Hellman key and its (optionally encrypted)
public authentication key. The signature in I2 covers all of the
packet.
The Responder extracts the Initiator Diffie-Hellman public key from The Responder extracts the Initiator Diffie-Hellman public key from
the I2, computes the Diffie-Hellman session key, creates a the I2, computes the Diffie-Hellman session key, creates a
corresponding HIP association, and decrypts the Initiator's public corresponding HIP association, and decrypts the Initiator's public
authentication key. It can then verify the signature using the authentication key. It can then verify the signature using the
authentication key. authentication key.
The final message, R2, is needed to protect the Initiator from replay The final message, R2, is needed to protect the Initiator from replay
attacks. attacks.
skipping to change at page 17, line 33 skipping to change at page 17, line 38
Initiator HI is protected in the exchange. There is a risk of a race Initiator HI is protected in the exchange. There is a risk of a race
condition if each host's policy is to only be an Initiator, at which condition if each host's policy is to only be an Initiator, at which
point the HIP exchange will fail. point the HIP exchange will fail.
If the host's policy does not permit it to enter into a HIP exchange If the host's policy does not permit it to enter into a HIP exchange
with the Initiator, it should send an ICMP 'Destination Unreachable, with the Initiator, it should send an ICMP 'Destination Unreachable,
Administratively Prohibited' message. A more complex HIP packet is Administratively Prohibited' message. A more complex HIP packet is
not used here as it actually opens up more potential DoS attacks than not used here as it actually opens up more potential DoS attacks than
a simple ICMP message. a simple ICMP message.
4.1.6. HIP Opportunistic Mode
It is possible to initiate a HIP negotiation even if the responder's
HI (and HIT) is unknown. In this case the connection initializing I1
packet contains NULL (all zeros) as the destination HIT. This kind
of connection setup is called opportunistic mode.
There are multiple security issues involved with opportunistic mode
that must be carefully addressed in the implementation. Such a set
up is vulnerable to, e.g., man-in-the-middle attacks, because the
initializing node does not have any public key information about the
peer.
While this document defines the concept of the opportunistic mode,
and outlines the basic signalling mechanism to trigger it; i.e., send
an I1 with a NULL destination HIT, this document does not specify the
details of the opportunistic mode. Especially, its security
properties are not discussed beyond the warning above. It is
expected that a separate document will describe the opportunistic
mode in more detail, including its security properties.
4.2. Updating a HIP Association 4.2. Updating a HIP Association
A HIP association between two hosts may need to be updated over time. A HIP association between two hosts may need to be updated over time.
Examples include the need to rekey expiring user data security Examples include the need to rekey expiring user data security
associations, add new security associations, or change IP addresses associations, add new security associations, or change IP addresses
associated with hosts. The UPDATE packet is used for those and other associated with hosts. The UPDATE packet is used for those and other
similar purposes. This document only specifies the UPDATE packet similar purposes. This document only specifies the UPDATE packet
format and basic processing rules, with mandatory parameters. The format and basic processing rules, with mandatory parameters. The
actual usage is defined in separate specifications. actual usage is defined in separate specifications.
skipping to change at page 18, line 20 skipping to change at page 18, line 44
acknowledgment parameter that echoes an individual sequence number acknowledgment parameter that echoes an individual sequence number
received from the peer. A single UPDATE packet may contain both a received from the peer. A single UPDATE packet may contain both a
sequence number and one or more acknowledgment numbers (i.e., sequence number and one or more acknowledgment numbers (i.e.,
piggybacked acknowledgment(s) for the peer's UPDATE). piggybacked acknowledgment(s) for the peer's UPDATE).
The UPDATE packet is defined in Section 5.3.5. The UPDATE packet is defined in Section 5.3.5.
4.3. Error Processing 4.3. Error Processing
HIP error processing behavior depends on whether there exists an HIP error processing behavior depends on whether there exists an
active HIP association or not. In general, if an HIP association active HIP association or not. In general, if a HIP association
exists between the sender and receiver of a packet causing an error exists between the sender and receiver of a packet causing an error
condition, the receiver SHOULD respond with a NOTIFY packet. On the condition, the receiver SHOULD respond with a NOTIFY packet. On the
other hand, if there are no existing HIP associations between the other hand, if there are no existing HIP associations between the
sender and receiver, or the receiver cannot reasonably determine the sender and receiver, or the receiver cannot reasonably determine the
identity of the sender, the receiver MAY respond with a suitable ICMP identity of the sender, the receiver MAY respond with a suitable ICMP
message; see Section 5.4 for more details. message; see Section 5.4 for more details.
The HIP protocol and state machine is designed to recover from one of The HIP protocol and state machine is designed to recover from one of
the parties crashing and losing its state. The following scenarios the parties crashing and losing its state. The following scenarios
describe the main use cases covered by the design. describe the main use cases covered by the design.
skipping to change at page 18, line 47 skipping to change at page 19, line 24
The system with data to send has no state with the receiver, but The system with data to send has no state with the receiver, but
the receiver has a residual HIP association. the receiver has a residual HIP association.
The system with data to send is the Initiator. The Initiator The system with data to send is the Initiator. The Initiator
acts as in no prior state, sending I1 and getting R1. When the acts as in no prior state, sending I1 and getting R1. When the
Responder receives a valid I2, the old association is Responder receives a valid I2, the old association is
'discovered' and deleted, and the new association is 'discovered' and deleted, and the new association is
established. established.
The system with data to send has an HIP association, but the The system with data to send has a HIP association, but the
receiver does not. receiver does not.
The system sends data on the outbound user data security The system sends data on the outbound user data security
association. The receiver 'detects' the situation when it association. The receiver 'detects' the situation when it
receives a user data packet that it cannot match to any HIP receives a user data packet that it cannot match to any HIP
association. The receiving host MUST discard this packet. association. The receiving host MUST discard this packet.
Optionally, the receiving host MAY send an ICMP packet with the Optionally, the receiving host MAY send an ICMP packet with the
Parameter Problem type to inform about non-existing HIP Parameter Problem type to inform about non-existing HIP
association (see Section 5.4), and it MAY initiate a new HIP association (see Section 5.4), and it MAY initiate a new HIP
negotiation. However, responding with these optional negotiation. However, responding with these optional
skipping to change at page 33, line 38 skipping to change at page 34, line 38
generation may not be needed. If a host expects to send HIP packets generation may not be needed. If a host expects to send HIP packets
that are larger than the minimum IPv6 MTU, it MUST implement fragment that are larger than the minimum IPv6 MTU, it MUST implement fragment
generation even for IPv6. generation even for IPv6.
In IPv4 networks, HIP packets may encounter low MTUs along their In IPv4 networks, HIP packets may encounter low MTUs along their
routed path. Since HIP does not provide a mechanism to use multiple routed path. Since HIP does not provide a mechanism to use multiple
IP datagrams for a single HIP packet, support for path MTU discovery IP datagrams for a single HIP packet, support for path MTU discovery
does not bring any value to HIP in IPv4 networks. HIP-aware NAT does not bring any value to HIP in IPv4 networks. HIP-aware NAT
devices MUST perform any IPv4 reassembly/fragmentation. devices MUST perform any IPv4 reassembly/fragmentation.
All HIP implementations MUST employ a reassembly algorithm that is All HIP implementations have to be careful while employing a
sufficiently resistant to DoS attacks. reassembly algorithm so that the algorithm is sufficiently resistant
to DoS attacks.
5.2. HIP Parameters 5.2. HIP Parameters
The HIP Parameters are used to carry the public key associated with The HIP Parameters are used to carry the public key associated with
the sender's HIT, together with related security and other the sender's HIT, together with related security and other
information. They consist of ordered parameters, encoded in TLV information. They consist of ordered parameters, encoded in TLV
format. format.
The following parameter types are currently defined. The following parameter types are currently defined.
skipping to change at page 34, line 43 skipping to change at page 35, line 43
| | | | document. | | | | | document. |
| | | | | | | | | |
| NOTIFY | 832 | variable | Informational data | | NOTIFY | 832 | variable | Informational data |
| | | | | | | | | |
| ECHO_REQUEST | 897 | variable | Opaque data to be echoed | | ECHO_REQUEST | 897 | variable | Opaque data to be echoed |
| | | | back; under signature | | | | | back; under signature |
| | | | | | | | | |
| ECHO_RESPONSE | 961 | variable | Opaque data echoed back; | | ECHO_RESPONSE | 961 | variable | Opaque data echoed back; |
| | | | under signature | | | | | under signature |
| | | | | | | | | |
| HMAC | 61505 | 20 | HMAC based message | | HMAC | 61505 | variable | HMAC based message |
| | | | authentication code, with | | | | | authentication code, with |
| | | | key material from | | | | | key material from |
| | | | HIP_TRANSFORM | | | | | HIP_TRANSFORM |
| | | | | | | | | |
| HMAC_2 | 61569 | 20 | HMAC based message | | HMAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, with | | | | | authentication code, with |
| | | | key material from | | | | | key material from |
| | | | HIP_TRANSFORM | | | | | HIP_TRANSFORM |
| | | | | | | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 packet | | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 packet |
| | | | | | | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the packet | | HIP_SIGNATURE | 61697 | variable | Signature of the packet |
| | | | | | | | | |
| ECHO_REQUEST | 63661 | variable | Opaque data to be echoed | | ECHO_REQUEST | 63661 | variable | Opaque data to be echoed |
| | | | back; after signature | | | | | back; after signature |
skipping to change at page 40, line 12 skipping to change at page 41, line 12
echoes back the random difficulty K, the Opaque field, and the puzzle echoes back the random difficulty K, the Opaque field, and the puzzle
integer #I. integer #I.
5.2.6. DIFFIE_HELLMAN 5.2.6. DIFFIE_HELLMAN
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value / | Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | padding | / | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 513 Type 513
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
padding padding
Group ID defines values for p and g Group ID defines values for p and g
Public Value length of the following Public Value in octets
Length
Public Value the sender's public Diffie-Hellman key Public Value the sender's public Diffie-Hellman key
The following Group IDs have been defined: The following Group IDs have been defined:
Group Value Group Value
Reserved 0 Reserved 0
384-bit group 1 384-bit group 1
OAKLEY well known group 1 2 OAKLEY well known group 1 2
1536-bit MODP group 3 1536-bit MODP group 3
3072-bit MODP group 4 3072-bit MODP group 4
6144-bit MODP group 5 6144-bit MODP group 5
8192-bit MODP group 6 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 [17]. The OAKLEY group
is defined in [8]. The OAKLEY well known group 5 is the same as the is defined in [8].
1536-bit MODP group.
The sender can include at most two different Diffie-Hellman public
values in the DIFFIE_HELLMAN parameter. This gives the possibility
e.g. for a server to provide a weaker encryption possibility for a
PDA host that is not powerful enough. It is RECOMMENDED that the
Initiator, receiving more than one public values selects the stronger
one, if it supports it.
A HIP implementation MUST support Group IDs 1 and 3. The 384-bit 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) 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). and when the equipment is not powerful enough (e.g. some PDAs).
Equipment powerful enough SHOULD implement also group ID 5. The 384- Equipment powerful enough SHOULD implement also group ID 5. The 384-
bit group is defined in Appendix D. bit group is defined in Appendix D.
To avoid unnecessary failures during the base exchange, the rest of To avoid unnecessary failures during the base exchange, the rest of
the groups SHOULD be implemented in hosts where resources are the groups SHOULD be implemented in hosts where resources are
adequate. adequate.
5.2.7. HIP_TRANSFORM 5.2.7. HIP_TRANSFORM
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform-ID #1 | Transform-ID #2 | | Suite-ID #1 | Suite-ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform-ID #n | Padding | | Suite-ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 577 Type 577
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
padding padding
Transform-ID Defines the HIP Suite to be used Suite-ID Defines the HIP Suite to be used
The following Suite-IDs are defined ([21],[10]): The following Suite-IDs are defined ([21],[10]):
Suite-ID Value Suite-ID Value
RESERVED 0 RESERVED 0
AES-CBC with HMAC-SHA1 1 AES-CBC with HMAC-SHA1 1
3DES-CBC with HMAC-SHA1 2 3DES-CBC with HMAC-SHA1 2
3DES-CBC with HMAC-MD5 3 3DES-CBC with HMAC-MD5 3
BLOWFISH-CBC with HMAC-SHA1 4 BLOWFISH-CBC with HMAC-SHA1 4
NULL-ENCRYPT with HMAC-SHA1 5 NULL-ENCRYPT with HMAC-SHA1 5
NULL-ENCRYPT with HMAC-MD5 6 NULL-ENCRYPT with HMAC-MD5 6
There MUST NOT be more than six (6) HIP Suite-IDs in one HIP The sender of a HIP transform parameter MUST make sure that there are
transform parameter. The limited number of transforms sets the no more than six (6) HIP Suite-IDs in one HIP transform parameter.
maximum size of HIP_TRANSFORM parameter. The HIP_TRANSFORM parameter Conversely, a recipient MUST be prepared to handle received transport
MUST contain at least one of the mandatory Suite-IDs. parameters that contain more than six Suite-IDs. The limited number
of transforms sets the maximum size of HIP_TRANSFORM parameter. As
the default configuration, the HIP_TRANSFORM parameter MUST contain
at least one of the mandatory Suite-IDs. There MAY be a
configuration option that allows the administrator to override this
default.
The Responder lists supported and desired Suite-IDs in order of The Responder lists supported and desired Suite-IDs in order of
preference in the R1, up to the maximum of six Suite-IDs. In the I2, preference in the R1, up to the maximum of six Suite-IDs. The
the Initiator MUST choose and insert only one of the corresponding Initiator MUST choose only one of the corresponding Suite-IDs. That
Suite-IDs that will be used for generating the I2. Suite-ID will be used for generating the I2.
Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION
with HMAC-SHA1. with HMAC-SHA1.
5.2.8. HOST_ID 5.2.8. HOST_ID
0 1 2 3 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 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 | | Type | Length |
skipping to change at page 42, line 48 skipping to change at page 44, line 12
The following DI-types have been defined: The following DI-types have been defined:
Type Value Type Value
none included 0 none included 0
FQDN 1 FQDN 1
NAI 2 NAI 2
FQDN Fully Qualified Domain Name, in binary format. FQDN Fully Qualified Domain Name, in binary format.
NAI Network Access Identifier NAI Network Access Identifier
[23]
The format for the FQDN is defined in RFC1035 [3] Section 3.1. The format for the FQDN is defined in RFC1035 [3] Section 3.1. The
format for Network Access Identifier is defined in [23]
If there is no Domain Identifier, i.e. the DI-type field is zero, If there is no Domain Identifier, i.e. the DI-type field is zero,
also the DI Length field is set to zero. also the DI Length field is set to zero.
5.2.9. HMAC 5.2.9. HMAC
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC | | HMAC |
| | / /
| | / +-------------------------------+
| | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 61505 Type 61505
Length 20 Length length in octets, excluding Type, Length, and
HMAC 160 low order bits of the HMAC computed over the Padding
HIP packet, excluding the HMAC parameter and any HMAC HMAC computed over the HIP packet, excluding the
following parameters, such as HIP_SIGNATURE, HMAC parameter and any following parameters, such
HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE. as HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST,
The checksum field MUST be set to zero or ECHO_RESPONSE. The checksum field MUST be set
and the HIP header length in the HIP common header to zero and the HIP header length in the HIP common
MUST be calculated not to cover any excluded header MUST be calculated not to cover any excluded
parameters when the HMAC is calculated. parameters when the HMAC is calculated. The size
of the HMAC is the natural size of the hash
computation output depending on the used hash
function.
The HMAC calculation and verification process is presented in The HMAC calculation and verification process is presented in
Section 6.4.1 Section 6.4.1
5.2.10. HMAC_2 5.2.10. HMAC_2
The parameter structure is the same as in Section 5.2.9. The fields The parameter structure is the same as in Section 5.2.9. The fields
are: are:
Type 61569 Type 61569
Length 20 Length length in octets, excluding Type, Length, and
HMAC 160 low order bits of the HMAC computed over the Padding
HIP packet, excluding the HMAC parameter and any HMAC HMAC computed over the HIP packet, excluding the
following parameters such as HIP_SIGNATURE, HMAC parameter and any following parameters such
HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE, as HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST,
and including an additional sender's or ECHO_RESPONSE, and including an additional
HOST_ID parameter during the HMAC calculation. The sender's HOST_ID parameter during the HMAC
checksum field MUST be set to zero and the HIP calculation. The checksum field MUST be set to
header length in the HIP common header MUST be zero and the HIP header length in the HIP common
calculated not to cover any excluded parameters header MUST be calculated not to cover any
when the HMAC is calculated. excluded parameters when the HMAC is calculated.
The size of the HMAC is the natural size of the
hash computation output depending on the used hash
function.
The HMAC calculation and verification process is presented in The HMAC calculation and verification process is presented in
Section 6.4.1 Section 6.4.1
5.2.11. HIP_SIGNATURE 5.2.11. HIP_SIGNATURE
0 1 2 3 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 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 | | Type | Length |
skipping to change at page 53, line 5 skipping to change at page 54, line 5
covered by the HMAC and SIGNATURE. This is dictated by the Type covered by the HMAC and SIGNATURE. This is dictated by the Type
field selected for the parameter; Type 961 ECHO_RESPONSE is covered field selected for the parameter; Type 961 ECHO_RESPONSE is covered
and Type 63425 is not. and Type 63425 is not.
5.3. HIP Packets 5.3. HIP Packets
There are eight basic HIP packets (see Table 11). Four are for the There are eight basic HIP packets (see Table 11). Four are for the
HIP base exchange, one is for updating, one is for sending HIP base exchange, one is for updating, one is for sending
notifications, and two for closing a HIP association. notifications, and two for closing a HIP association.
+-------------+---------------------------------------------------+ +------------------+------------------------------------------------+
| Packet type | Packet name | | Packet type | Packet name |
+-------------+---------------------------------------------------+ +------------------+------------------------------------------------+
| 1 | I1 - the HIP Initiator Packet | | 1 | I1 - the HIP Initiator Packet |
| | | | | |
| 2 | R1 - the HIP Responder Packet | | 2 | R1 - the HIP Responder Packet |
| | | | | |
| 3 | I2 - the Second HIP Initiator Packet | | 3 | I2 - the Second HIP Initiator Packet |
| | | | | |
| 4 | R2 - the Second HIP Responder Packet | | 4 | R2 - the Second HIP Responder Packet |
| | | | | |
| 16 | UPDATE - the HIP Update Packet | | 16 | UPDATE - the HIP Update Packet |
| | | | | |
| 17 | NOTIFY - the HIP Notify Packet | | 17 | NOTIFY - the HIP Notify Packet |
| | | | | |
| 18 | CLOSE - the HIP Association Closing Packet | | 18 | CLOSE - the HIP Association Closing Packet |
| | | | | |
| 19 | CLOSE_ACK - the HIP Closing Acknowledgment Packet | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment |
+-------------+---------------------------------------------------+ | | Packet |
+------------------+------------------------------------------------+
Table 11: HIP packets and packet type numbers Table 11: HIP packets and packet type numbers
Packets consist of the fixed header as described in Section 5.1, Packets consist of the fixed header as described in Section 5.1,
followed by the parameters. The parameter part, in turn, consists of followed by the parameters. The parameter part, in turn, consists of
zero or more parameter coded parameters. zero or more TLV coded parameters.
In addition to the base packets, other packets types will be defined In addition to the base packets, other packets types will be defined
later in separate specifications. For example, support for mobility later in separate specifications. For example, support for mobility
and multi-homing is not included in this specification. and multi-homing is not included in this specification.
See Notation (Section 2.2) for used operations. See Notation (Section 2.2) for used operations.
In the future, an OPTIONAL upper layer payload MAY follow the HIP In the future, an OPTIONAL upper layer payload MAY follow the HIP
header. The Next Header field in the header indicates if there is header. The Next Header field in the header indicates if there is
additional data following the HIP header. The HIP packet, however, additional data following the HIP header. The HIP packet, however,
skipping to change at page 54, line 13 skipping to change at page 55, line 15
IP ( HIP () ) IP ( HIP () )
The I1 packet contains only the fixed HIP header. The I1 packet contains only the fixed HIP header.
Valid control bits: none Valid control bits: none
The Initiator gets the Responder's HIT either from a DNS lookup of 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 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 table. If the Initiator does not know the Responder's HIT, it may
attempt opportunistic mode by using NULL (all zeros) as the attempt opportunistic mode by using NULL (all zeros) as the
Responder's HIT. If the Initiator sends a NULL as the Responder's Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.6)).
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 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. attempt is made to add to its generation or processing cost.
Implementations MUST be able to handle a storm of received I1 Implementations MUST be able to handle a storm of received I1
packets, discarding those with common content that arrive within a packets, discarding those with common content that arrive within a
small time delta. small time delta.
5.3.2. R1 - the HIP Responder Packet 5.3.2. R1 - the HIP Responder Packet
skipping to change at page 54, line 49 skipping to change at page 55, line 49
HIP_SIGNATURE_2 ) HIP_SIGNATURE_2 )
[, ECHO_REQUEST ]) [, ECHO_REQUEST ])
Valid control bits: A Valid control bits: A
If the Responder HI is an anonymous one, the A control MUST be set. If the Responder HI is an anonymous one, the A control MUST be set.
The Initiator HIT MUST match the one received in I1. If the The Initiator HIT MUST match the one received in I1. If the
Responder has multiple HIs, the Responder HIT used MUST match Responder has multiple HIs, the Responder HIT used MUST match
Initiator's request. If the Initiator used opportunistic mode, the Initiator's request. If the Initiator used opportunistic mode, the
Responder may select freely among its HIs. Responder may select freely among its HIs. See also "HIP
Opportunistic Mode" (Section 4.1.6)).
The R1 generation counter is used to determine the currently valid The R1 generation counter is used to determine the currently valid
generation of puzzles. The value is increased periodically, and it generation of puzzles. The value is increased periodically, and it
is RECOMMENDED that it is increased at least as often as solutions to is RECOMMENDED that it is increased at least as often as solutions to
old puzzles are no longer accepted. old puzzles are no longer accepted.
The Puzzle contains a random #I and the difficulty K. The difficulty The Puzzle contains a random #I and the difficulty K. The difficulty
K is the number of bits that the Initiator must get zero in the K is the number of bits that the Initiator must get zero in the
puzzle. The random #I is not covered by the signature and must be puzzle. The random #I is not covered by the signature and must be
zeroed during the signature calculation, allowing the sender to zeroed during the signature calculation, allowing the sender to
select and set the #I into a pre-computed R1 just prior sending it to select and set the #I into a pre-computed R1 just prior sending it to
the peer. the peer.
The Diffie-Hellman value is ephemeral, but can be reused over a The Diffie-Hellman value is ephemeral, and one value SHOULD be used
number of connections. In fact, as a defense against I1 storms, an only for one connection. Once the Responder has received a valid
implementation MAY use the same Diffie-Hellman value for a period of response to an R1 packet, that Diffie-Hellman value SHOULD be
time, for example, 15 minutes. By using a small number of different deprecated. Because it is possible that the Responder has sent the
puzzles for a given Diffie-Hellman value, the R1 packets can be pre- same Diffie-Hellman value to different hosts simultaneously in
computed and delivered as quickly as I1 packets arrive. A scavenger corresponding R1 packets also those responses should be accepted.
process should clean up unused DHs and puzzles. However, 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 puzzles 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 puzzles.
The HIP_TRANSFORM contains the encryption and integrity algorithms The HIP_TRANSFORM contains the encryption and integrity algorithms
supported by the Responder to protect the HI exchange, in the order supported by the Responder to protect the HI exchange, in the order
of preference. All implementations MUST support the AES [18] with of preference. All implementations MUST support the AES [18] with
HMAC-SHA-1-96 [6]. HMAC-SHA-1-96 [6].
The ECHO_REQUEST contains data that the sender wants to receive The ECHO_REQUEST contains data that the sender wants to receive
unmodified in the corresponding response packet in the ECHO_RESPONSE unmodified in the corresponding response packet in the ECHO_RESPONSE
parameter. The ECHO_REQUEST can be either covered by the signature, 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 or it can be left out from it. In the first case, the ECHO_REQUEST
skipping to change at page 56, line 30 skipping to change at page 57, line 30
Valid control bits: A Valid control bits: A
The HITs used MUST match the ones used previously. The HITs used MUST match the ones used previously.
If the Initiator HI is an anonymous one, the A control MUST be set. 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 The Initiator MAY include an unmodified copy of the R1_COUNTER
parameter received in the corresponding R1 packet into the I2 packet. parameter received in the corresponding R1 packet into the I2 packet.
The Solution contains the random # I from R1 and the computed # J. The Solution contains the random # I from R1 and the computed # J.
The low order K bits of the PHASH(I | ... | J) MUST be zero. The low order K bits of the RHASH(I | ... | J) MUST be zero.
The Diffie-Hellman value is ephemeral. If precomputed, a scavenger The Diffie-Hellman value is ephemeral. If precomputed, a scavenger
process should clean up unused DHs. process should clean up unused DHs.
The HIP_TRANSFORM contains the single encryption and integrity The HIP_TRANSFORM contains the single encryption and integrity
transform selected by the Initiator, that will be used to protect the transform selected by the Initiator, that will be used to protect the
HI exchange. The chosen transform MUST correspond to one offered by HI exchange. The chosen transform MUST correspond to one offered by
the Responder in the R1. All implementations MUST support the AES the Responder in the R1. All implementations MUST support the AES
transform [18]. transform [18].
skipping to change at page 58, line 41 skipping to change at page 59, line 41
UPDATEs MAY be retransmitted without incrementing SEQ. If the same UPDATEs MAY be retransmitted without incrementing SEQ. If the same
subset of parameters is included in multiple UPDATEs with different subset of parameters is included in multiple UPDATEs with different
SEQs, the host MUST ensure that receiver processing of the parameters SEQs, the host MUST ensure that receiver processing of the parameters
multiple times will not result in a protocol error. multiple times will not result in a protocol error.
5.3.6. NOTIFY - the HIP Notify Packet 5.3.6. NOTIFY - the HIP Notify Packet
The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to
provide information to a peer. Typically, NOTIFY is used to indicate provide information to a peer. Typically, NOTIFY is used to indicate
some type of protocol error or negotiation failure. NOTIFY packets some type of protocol error or negotiation failure. NOTIFY packets
are unacknowledged. are unacknowledged. The receiver can handle the packet only as
informational, and SHOULD NOT make any state information changes
based purely on a received NOTIFY packet.
The HIP header values for the NOTIFY packet: The HIP header values for the NOTIFY packet:
Header: Header:
Packet Type = 17 Packet Type = 17
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Recipient's HIT, or zero if unknown DST HIT = Recipient's HIT, or zero if unknown
IP ( HIP (<NOTIFY>i, [HOST_ID, ] HIP_SIGNATURE) ) IP ( HIP (<NOTIFY>i, [HOST_ID, ] HIP_SIGNATURE) )
skipping to change at page 64, line 10 skipping to change at page 65, line 10
in the stack. in the stack.
4. The datagram is delivered to the upper layer. Demultiplexing the 4. The datagram is delivered to the upper layer. Demultiplexing the
datagram the right upper layer socket is based on the HITs. datagram the right upper layer socket is based on the HITs.
6.3. Solving the Puzzle 6.3. Solving the Puzzle
This subsection describes the puzzle solving details. This subsection describes the puzzle solving details.
In R1, the values I and K are sent in network byte order. Similarly, 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 in I2 the values I and J are sent in network byte order. The hash is
hash is created by concatenating, in network byte order, the created by concatenating, in network byte order, the following data,
following data, in the following order: in the following order and using the RHASH algorithm:
64-bit random value I, in network byte order, as appearing in R1 64-bit random value I, in network byte order, as appearing in R1
and I2. and I2.
128-bit Initiator HIT, in network byte order, as appearing in the 128-bit Initiator HIT, in network byte order, as appearing in the
HIP Payload in R1 and I2. HIP Payload in R1 and I2.
128-bit Responder HIT, in network byte order, as appearing in the 128-bit Responder HIT, in network byte order, as appearing in the
HIP Payload in R1 and I2. HIP Payload in R1 and I2.
64-bit random value J, in network byte order, as appearing in I2. 64-bit random value J, in network byte order, as appearing in I2.
In order to be a valid response puzzle, the K low-order bits of the In order to be a valid response puzzle, the K low-order bits of the
resulting PHASH digest must be zero. resulting RHASH digest must be zero.
Notes: Notes:
i) The length of the data to be hashed is 48 bytes. i) The length of the data to be hashed is 48 bytes.
ii) All the data in the hash input MUST be in network byte order. ii) All the data in the hash input MUST be in network byte order.
iii) The order of the Initiator and Responder HITs are different iii) The order of the Initiator and Responder HITs are different
in the R1 and I2 packets, see Section 5.1. Care must be taken to in the R1 and I2 packets, see Section 5.1. Care must be taken to
copy the values in right order to the hash input. copy the values in right order to the hash input.
skipping to change at page 65, line 8 skipping to change at page 66, line 8
Responder: Responder:
Selects a suitable cached R1. Selects a suitable cached R1.
Generates a random number I. Generates a random number I.
Sends I and K in an R1. Sends I and K in an R1.
Saves I and K for a Delta time. Saves I and K for a Delta time.
Initiator: Initiator:
Generates repeated attempts to solve the puzzle until a matching J Generates repeated attempts to solve the puzzle until a matching J
is found: is found:
Ltrunc( PHASH( I | HIT-I | HIT-R | J ), K ) == 0 Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K ) == 0
Sends I and J in an I2. Sends I and J in an I2.
Responder: Responder:
Verifies that the received I is a saved one. Verifies that the received I is a saved one.
Finds the right K based on I. Finds the right K based on I.
Computes V := Ltrunc( PHASH( I | HIT-I | HIT-R | J ), K ) Computes V := Ltrunc( RHASH( I | HIT-I | HIT-R | J ), K )
Rejects if V != 0 Rejects if V != 0
Accept if V == 0 Accept if V == 0
6.4. HMAC and SIGNATURE Calculation and Verification 6.4. HMAC and SIGNATURE Calculation and Verification
The following subsections define the actions for processing HMAC, The following subsections define the actions for processing HMAC,
HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. HIP_SIGNATURE and HIP_SIGNATURE_2 parameters.
6.4.1. HMAC Calculation 6.4.1. HMAC Calculation
skipping to change at page 67, line 46 skipping to change at page 68, line 46
creation of the I2 packet, and the Responder has Kij once it receives creation of the I2 packet, and the Responder has Kij once it receives
the I2 packet. This is why I2 can already contain encrypted the I2 packet. This is why I2 can already contain encrypted
information. information.
The KEYMAT is derived by feeding Kij and the HITs into the following The KEYMAT is derived by feeding Kij and the HITs into the following
operation; the | operation denotes concatenation. operation; the | operation denotes concatenation.
KEYMAT = K1 | K2 | K3 | ... KEYMAT = K1 | K2 | K3 | ...
where where
K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | I | J | 0x01 ) K1 = RHASH( Kij | sort(HIT-I | HIT-R) | I | J | 0x01 )
K2 = SHA-1( Kij | K1 | 0x02 ) K2 = RHASH( Kij | K1 | 0x02 )
K3 = SHA-1( Kij | K2 | 0x03 ) K3 = RHASH( Kij | K2 | 0x03 )
... ...
K255 = SHA-1( Kij | K254 | 0xff ) K255 = RHASH( Kij | K254 | 0xff )
K256 = SHA-1( Kij | K255 | 0x00 ) K256 = RHASH( Kij | K255 | 0x00 )
etc. etc.
Sort(HIT-I | HIT-R) is defined as the network byte order Sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte interpreted as positive (unsigned) 128-bit integers in network byte
order. order.
I and J values are from the puzzle and its solution that were I and J values are from the puzzle and its solution that were
exchanged in R1 and I2 messages when this HIP association was set up. exchanged in R1 and I2 messages when this HIP association was set up.
skipping to change at page 68, line 43 skipping to change at page 69, line 43
The number of bits drawn for a given algorithm is the "natural" size The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes of the keys. For the mandatory algorithms, the following sizes
apply: apply:
AES 128 bits AES 128 bits
SHA-1 160 bits SHA-1 160 bits
NULL 0 bits NULL 0 bits
If other key sizes are used, they must be treated as different
encryption algorithms and defined separtely.
6.6. Initiation of a HIP Exchange 6.6. Initiation of a HIP Exchange
An implementation may originate a HIP exchange to another host based An implementation may originate a HIP exchange to another host based
on a local policy decision, usually triggered by an application on a local policy decision, usually triggered by an application
datagram, in much the same way that an IPsec IKE key exchange can datagram, in much the same way that an IPsec IKE key exchange can
dynamically create a Security Association. Alternatively, a system dynamically create a Security Association. Alternatively, a system
may initiate a HIP exchange if it has rebooted or timed out, or may initiate a HIP exchange if it has rebooted or timed out, or
otherwise lost its HIP state, as described in Section 4.5.4. otherwise lost its HIP state, as described in Section 4.5.4.
The implementation prepares an I1 packet and sends it to the IP The implementation prepares an I1 packet and sends it to the IP
skipping to change at page 69, line 17 skipping to change at page 70, line 20
selection of which host identity to use, if a host has more than one selection of which host identity to use, if a host has more than one
to choose from, is typically a policy decision. to choose from, is typically a policy decision.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
initiating a HIP exchange: initiating a HIP exchange:
1. The Initiator gets the Responder's HIT and one or more addresses 1. The Initiator gets the Responder's HIT and one or more addresses
either from a DNS lookup of the Responder's FQDN, from some other either from a DNS lookup of the Responder's FQDN, from some other
repository, or from a local table. If the Initiator does not repository, or from a local table. If the Initiator does not
know the Responder's HIT, it may attempt opportunistic mode by know the Responder's HIT, it may attempt opportunistic mode by
using NULL (all zeros) as the Responder's HIT. using NULL (all zeros) as the Responder's HIT. See also "HIP
Opportunistic Mode" (Section 4.1.6).
2. The Initiator sends an I1 to one of the Responder's addresses. 2. The Initiator sends an I1 to one of the Responder's addresses.
The selection of which address to use is a local policy decision. The selection of which address to use is a local policy decision.
3. Upon sending an I1, the sender shall transition to state I1-SENT, 3. Upon sending an I1, the sender shall transition to state I1-SENT,
start a timer whose timeout value should be larger than the start a timer whose timeout value should be larger than the
worst-case anticipated RTT, and shall increment a timeout counter worst-case anticipated RTT, and shall increment a timeout counter
associated with the I1. associated with the I1.
4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the
skipping to change at page 70, line 8 skipping to change at page 71, line 11
duplicate R1's. duplicate R1's.
The Initiator SHOULD then select the initial preferred destination The Initiator SHOULD then select the initial preferred destination
address using the source address of the selected received R1, and use address using the source address of the selected received R1, and use
the preferred address as a source address for the I2. Processing the preferred address as a source address for the I2. Processing
rules for received R1s are discussed in Section 6.8. rules for received R1s are discussed in Section 6.8.
6.6.2. Processing Incoming ICMP Protocol Unreachable Messages 6.6.2. Processing Incoming ICMP Protocol Unreachable Messages
A host may receive an ICMP Destination Protocol Unreachable message A host may receive an ICMP Destination Protocol Unreachable message
as a response to sending an HIP I1 packet. Such a packet may be an as a response to sending a HIP I1 packet. Such a packet may be an
indication that the peer does not support HIP, or it may be an indication that the peer does not support HIP, or it may be an
attempt to launch an attack by making the Initiator believe that the attempt to launch an attack by making the Initiator believe that the
Responder does not support HIP. Responder does not support HIP.
When a system receives an ICMP Destination Protocol Unreachable When a system receives an ICMP Destination Protocol Unreachable
message while it is waiting for an R1, it MUST NOT terminate the message while it is waiting for an R1, it MUST NOT terminate the
wait. It MAY continue as if it had not received the ICMP message, wait. It MAY continue as if it had not received the ICMP message,
and send a few more I1s. Alternatively, it MAY take the ICMP message and send a few more I1s. Alternatively, it MAY take the ICMP message
as a hint that the peer most probably does not support HIP, and as a hint that the peer most probably does not support HIP, and
return to state UNASSOCIATED earlier than otherwise. However, at return to state UNASSOCIATED earlier than otherwise. However, at
skipping to change at page 71, line 6 skipping to change at page 72, line 10
responding to an I1 packet: responding to an I1 packet:
1. The Responder MUST check that the Responder HIT in the received 1. The Responder MUST check that the Responder HIT in the received
I1 is either one of its own HITs, or NULL. I1 is either one of its own HITs, or NULL.
2. If the Responder is in ESTABLISHED state, the Responder MAY 2. If the Responder is in ESTABLISHED state, the Responder MAY
respond to this with an R1 packet, prepare to drop existing SAs respond to this with an R1 packet, prepare to drop existing SAs
and stay at ESTABLISHED state. and stay at ESTABLISHED state.
3. If the Responder is in I1-SENT state, it must make a comparison 3. If the Responder is in I1-SENT state, it must make a comparison
between the sender's HIT and its own HIT. If the sender's HIT is between the sender's HIT and its own (i.e., the receiver's) HIT.
greater than its own HIT, it should drop the I1 and stay at I1- If the sender's HIT is greater than its own HIT, it should drop
SENT. If the sender's HIT is smaller than its own HIT, it should the I1 and stay at I1-SENT. If the sender's HIT is smaller than
send R1 and stay at I1-SENT. The HIT comparison goes similarly its own HIT, it should send R1 and stay at I1-SENT. The HIT
as in Section 6.5. comparison goes similarly as in Section 6.5.
4. If the implementation chooses to respond to the I1 with an R1 4. If the implementation chooses to respond to the I1 with an R1
packet, it creates a new R1 or selects a precomputed R1 according packet, it creates a new R1 or selects a precomputed R1 according
to the format described in Section 5.3.2. to the format described in Section 5.3.2.
5. The R1 MUST contain the received Responder HIT, unless the 5. The R1 MUST contain the received Responder HIT, unless the
received HIT is NULL, in which case the Responder SHOULD select a received HIT is NULL, in which case the Responder SHOULD select a
HIT that is constructed with the MUST algorithm in Section 3, HIT that is constructed with the MUST algorithm in Section 3,
which is currently RSA. Other than that, selecting the HIT is a which is currently RSA. Other than that, selecting the HIT is a
local policy matter. local policy matter.
6. The Responder sends the R1 to the source IP address of the I1 6. The Responder sends the R1 to the source IP address of the I1
packet. packet.
6.7.1. R1 Management 6.7.1. R1 Management
All compliant implementations MUST produce R1 packets. An R1 packet All compliant implementations MUST produce R1 packets. An R1 packet
MAY be precomputed. An R1 packet MAY be reused for time Delta T, MAY be precomputed. An R1 packet MAY be reused for time Delta T,
which is implementation dependent. R1 information MUST not be which is implementation dependent, and SHOULD be deprecated and not
discarded until Delta S after T. Time S is the delay needed for the used once a valid response I2 packet has been received from an
last I2 to arrive back to the Responder. Initiator. During I1 message storm, an R1 packet may be re-used
beyond this limit. 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.
An implementation MAY keep state about received I1s and match the An implementation MAY keep state about received I1s and match the
received I2s against the state, as discussed in Section 4.1.1. received I2s against the state, as discussed in Section 4.1.1.
6.7.2. Handling Malformed Messages 6.7.2. Handling Malformed Messages
If an implementation receives a malformed I1 message, it SHOULD NOT If an implementation receives a malformed I1 message, it SHOULD NOT
respond with a NOTIFY message, as such practice could open up a respond with a NOTIFY message, as such practice could open up a
potential denial-of-service danger. Instead, it MAY respond with an potential denial-of-service danger. Instead, it MAY respond with an
ICMP packet, as defined in Section 5.4. ICMP packet, as defined in Section 5.4.
skipping to change at page 72, line 17 skipping to change at page 73, line 24
amount of time after the first R1 reception to allow possibly 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 multiple R1s to arrive, and it SHOULD respond to an R1 among the set
with the largest R1 generation counter. with the largest R1 generation counter.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an R1 packet: responding to an R1 packet:
1. A system receiving an R1 MUST first check to see if it has sent 1. 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 has a HIP an I1 to the originator of the R1 (i.e., it has a HIP
association that is in state I1-SENT and that is associated with association that is in state I1-SENT and that is associated with
the HITs in the R1. IP addresses in the received R1 packet the HITs in the R1). Unless the I1 was sent in opportunistic
SHOULD be ignored and the match SHOULD be based on HITs only). mode (see also "HIP Opportunistic Mode" (Section 4.1.6) ), IP
If so, it should process the R1 as described below. Note that addresses in the received R1 packet SHOULD be ignored and the
when the connection was initialized in opportunistic mode, HITs match SHOULD be based on HITs only. If a match exists, the
cannot be used, but the Initiator must rely on the Responder's system should process the R1 as described below.
IP address in the received R1 packet.
2. Otherwise, if the system is in any other state than I1-SENT or 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 I2-SENT with respect to the HITs included in the R1, it SHOULD
silently drop the R1 and remain in the current state. silently drop the R1 and remain in the current state.
3. If the HIP association state is I1-SENT or I2-SENT, the received 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, Initiator's HIT MUST correspond to the HIT used in the original,
I1 and the Responder's HIT MUST correspond to the one used, I1 and the Responder's HIT MUST correspond to the one used,
unless the I1 contained a NULL HIT. unless the I1 contained a NULL HIT.
skipping to change at page 72, line 51 skipping to change at page 74, line 9
state I1-SENT and process the received R1 if it has a larger R1 state I1-SENT and process the received R1 if it has a larger R1
generation counter than the R1 responded to previously. generation counter than the R1 responded to previously.
7. The R1 packet may have the A bit set -- in this case, the system 7. 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 MAY choose to refuse it by dropping the R1 and returning to
state UNASSOCIATED. The system SHOULD consider dropping the R1 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 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. Responder's HIT is anonymous and should not be stored.
8. The system SHOULD attempt to validate the HIT against the 8. The system SHOULD attempt to validate the HIT against the
received Host Identity. received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT.
9. The system MUST store the received R1 generation counter for 9. The system MUST store the received R1 generation counter for
future reference. future reference.
10. The system attempts to solve the puzzle in R1. The system MUST 10. The system attempts to solve the puzzle in R1. The system MUST
terminate the search after exceeding the remaining lifetime of terminate the search after exceeding the remaining lifetime of
the puzzle. If the puzzle is not successfully solved, the the puzzle. If the puzzle is not successfully solved, the
implementation may either resend I1 within the retry bounds or implementation may either resend I1 within the retry bounds or
abandon the HIP exchange. abandon the HIP exchange.
skipping to change at page 74, line 39 skipping to change at page 75, line 47
one of its own HITs. one of its own HITs.
3. If the system is in the R2-SENT state, it MAY check if the newly 3. If the system is in the R2-SENT state, it MAY check if the newly
received I2 is similar to the one that triggered moving to R2- received I2 is similar to the one that triggered moving to R2-
SENT. If so, it MAY retransmit a previously sent R2, reset the SENT. If so, it MAY retransmit a previously sent R2, reset the
R2-SENT timer, and stay in R2-SENT. R2-SENT timer, and stay in R2-SENT.
4. If the system is in the I2-SENT state, it makes a comparison 4. If the system is in the I2-SENT state, it makes a comparison
between its local and sender's HITs (similarly as in between its local and sender's HITs (similarly as in
Section 6.5). If the local HIT is smaller than the sender's Section 6.5). If the local HIT is smaller than the sender's
HIT, it should drop the I2 packet. Otherwise, the system should HIT, it should drop the I2 packet, use peer Diffie-Hellman key
process the received I2 packet. and nonce I from the R1 packet received earlier, and get the
local Diffie-Hellman key and nonce J from the I2 packet sent to
the peer ealier. Otherwise, the system should process the
received I2 packet and drop any previously derived Diffie-
Hellman keying material Kij it might have formed upon sending
the I2 previously. The peer Diffie-Hellman key and nonce J are
taken from the just arrived I2 and local Diffie-Hellman key and
nonce I are the ones that it sent earlier in the R1 packet.
5. To avoid the possibility to end up with different session keys 5. If the system is in the I1-SENT state, and the HITs in the I2
due to symmetric operation of the peer nodes, the Diffie-Hellman match those used in the previously sent I1, the system uses this
key, I, and J selection is also based on the HIT comparison. If received I2 as the basis for the HIP assocation it was trying to
the local HIT is smaller than the peer HIT, the system uses peer form, and stops retransmitting I1 (provided that the I2 passes
Diffie-Hellman key and nonce I from the R1 packet received the below additional checks).
earlier. The local Diffie-Hellman key and nonce J are taken
from the I2 packet sent to the peer earlier. Otherwise, it uses
peer Diffie-Hellman key and nonce J from the just arrived I2.
The local Diffie-Hellman key and nonce I are the ones that it
sent ealier in the R1 packet.
6. If the system is in any other state than R2-SENT, it SHOULD 6. If the system is in any other state than R2-SENT, it SHOULD
check that the echoed R1 generation counter in I2 is within the check that the echoed R1 generation counter in I2 is within the
acceptable range. Implementations MUST accept puzzles from the acceptable range. Implementations MUST accept puzzles from the
current generation and MAY accept puzzles from earlier current generation and MAY accept puzzles from earlier
generations. If the newly received I2 is outside the accepted generations. If the newly received I2 is outside the accepted
range, the I2 is stale (perhaps replayed) and SHOULD be dropped. range, the I2 is stale (perhaps replayed) and SHOULD be dropped.
7. The system MUST validate the solution to the puzzle by computing 7. The system MUST validate the solution to the puzzle by computing
the hash described in Section 5.3.3 using the same hash the hash described in Section 5.3.3 using the same RHASH
algorithm used to generate the Responder's HIT. algorithm.
8. The I2 MUST have a single value in the HIP_TRANSFORM parameter, 8. The I2 MUST have a single value in the HIP_TRANSFORM parameter,
which MUST match one of the values offered to the Initiator in which MUST match one of the values offered to the Initiator in
the R1 packet. the R1 packet.
9. The system must derive Diffie-Hellman keying material Kij based 9. The system must derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the DIFFIE_HELLMAN on the public value and Group ID in the DIFFIE_HELLMAN
parameter. This key is used to derive the HIP association keys, parameter. This key is used to derive the HIP association keys,
as described in Section 6.5. If the Diffie-Hellman Group ID is as described in Section 6.5. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped. unsupported, the I2 packet is silently dropped.
skipping to change at page 80, line 7 skipping to change at page 81, line 13
verification fails, the packet SHOULD be dropped and an error verification fails, the packet SHOULD be dropped and an error
message logged. message logged.
4. The corresponding UPDATE timer is stopped (see Section 6.11) so 4. The corresponding UPDATE timer is stopped (see Section 6.11) so
that the now acknowledged UPDATE is no longer retransmitted. If that the now acknowledged UPDATE is no longer retransmitted. If
multiple UPDATEs are newly acknowledged, multiple timers are multiple UPDATEs are newly acknowledged, multiple timers are
stopped. stopped.
6.13. Processing NOTIFY Packets 6.13. Processing NOTIFY Packets
Processing NOTIFY packets is OPTIONAL. If processed, any errors Processing NOTIFY packets is OPTIONAL. If processed, any errors in a
noted by the NOTIFY parameter SHOULD be taken into account by the HIP received NOTIFY parameter SHOULD be logged. Received errors MUST be
state machine (e.g., by terminating a HIP handshake), and the error considered only as informational and the receiver SHOULD NOT change
SHOULD be logged. state information purely based on the received NOTIFY message.
6.14. Processing CLOSE Packets 6.14. Processing CLOSE Packets
When the host receives a CLOSE message it responds with a CLOSE_ACK 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 and moves to CLOSED state. (The authenticity of the CLOSE
message is verified using both HMAC and SIGNATURE). This processing message is verified using both HMAC and SIGNATURE). This processing
applies whether or not the HIP association state is CLOSING in order applies whether or not the HIP association state is CLOSING in order
to handle CLOSE messages from both ends crossing in flight. to handle CLOSE messages from both ends crossing in flight.
The HIP association is not discarded before the host moves from the The HIP association is not discarded before the host moves from the
skipping to change at page 82, line 21 skipping to change at page 84, line 21
could be more damaging to a host's ability to conduct business as could be more damaging to a host's ability to conduct business as
usual. usual.
Denial-of-service attacks take advantage of the cost of start of Denial-of-service attacks take advantage of the cost of start of
state for a protocol on the Responder compared to the 'cheapness' on state for a protocol on the Responder compared to the 'cheapness' on
the Initiator. HIP makes no attempt to increase the cost of the the Initiator. HIP makes no attempt to increase the cost of the
start of state on the Initiator, but makes an effort to reduce the start of state on the Initiator, but makes an effort to reduce the
cost to the Responder. This is done by having the Responder start cost to the Responder. This is done by having the Responder start
the 3-way exchange instead of the Initiator, making the HIP protocol the 3-way exchange instead of the Initiator, making the HIP protocol
4 packets long. In doing this, packet 2 becomes a 'stock' packet 4 packets long. In doing this, packet 2 becomes a 'stock' packet
that the Responder MAY use many times. The duration of use is a that the Responder MAY use many times, until some Initiator has
paranoia versus throughput concern. Using the same Diffie-Hellman provided a valid response to such and R1 packet. During an I1 storm
values and random puzzle #I has some risk. This risk needs to be the host may re-use the same D-H value also beyond that point. Using
balanced against a potential storm of HIP I1 packets. the same Diffie-Hellman values and random puzzle #I value has some
risks. This risk needs to be balanced against a potential storm of
HIP I1 packets.
This shifting of the start of state cost to the Initiator in creating This shifting of the start of state cost to the Initiator in creating
the I2 HIP packet, presents another DoS attack. The attacker spoofs the I2 HIP packet, presents another DoS attack. The attacker spoofs
the I1 HIP packet and the Responder sends out the R1 HIP packet. the I1 HIP packet and the Responder sends out the R1 HIP packet.
This could conceivably tie up the 'Initiator' with evaluating the R1 This could conceivably tie up the 'Initiator' with evaluating the R1
HIP packet, and creating the I2 HIP packet. The defense against this HIP packet, and creating the I2 HIP packet. The defense against this
attack is to simply ignore any R1 packet where a corresponding I1 was attack is to simply ignore any R1 packet where a corresponding I1 was
not sent. not sent.
A second form of DoS attack arrives in the I2 HIP packet. Once the A second form of DoS attack arrives in the I2 HIP packet. Once the
skipping to change at page 83, line 36 skipping to change at page 85, line 37
DNS zone, a certificate, or through some other secure means, the DNS zone, a certificate, or through some other secure means, the
Initiator can use this to validate the R1 HIP packet. Initiator can use this to validate the R1 HIP packet.
Likewise, if the Initiator's HI is in a secure DNS zone, a trusted Likewise, if the Initiator's HI is in a secure DNS zone, a trusted
certificate, or otherwise securely available, the Responder can certificate, or otherwise securely available, the Responder can
retrieve it after it gets the I2 HIP packet and validate that. retrieve it after it gets the I2 HIP packet and validate that.
However, since an Initiator may choose to use an anonymous HI, it However, since an Initiator may choose to use an anonymous HI, it
knowingly risks a MitM attack. The Responder may choose not to knowingly risks a MitM attack. The Responder may choose not to
accept a HIP exchange with an anonymous Initiator. accept a HIP exchange with an anonymous Initiator.
If an Initiator wants to use opportunistic mode, it is vulnerable to The HIP Opportunistic Mode concept has been introduced in this
man-in-the-middle attacks. Furthermore, the available HI types are document, but this document does not specify the details of such a
limited to the MUST implement algorithms, as per Section 3. Hence, connection set up (Section 4.1.6). There are certain security
if a future specification deprecates the current MUST implement concerns with opportunistic mode, and they must be addressed in a
algorithm(s) and replaces it (them) with some new one(s), backward separate document if such a mode will be used.
compatibility cannot be preserved.
NOTIFY messages are used only for informational purposes and they are
unacknowledged. A HIP implementation cannot rely solely on the
information received in a NOTIFY message because the packet may have
been replayed. It SHOULD NOT change any state information based
purely on a received NOTIFY message.
Since not all hosts will ever support HIP, ICMP 'Destination Protocol Since not all hosts will ever support HIP, ICMP 'Destination Protocol
Unreachable' are to be expected and present a DoS attack. Against an Unreachable' are to be expected and present a DoS attack. Against an
Initiator, the attack would look like the Responder does not support Initiator, the attack would look like the Responder does not support
HIP, but shortly after receiving the ICMP message, the Initiator HIP, but shortly after receiving the ICMP message, the Initiator
would receive a valid R1 HIP packet. Thus to protect from this would receive a valid R1 HIP packet. Thus to protect from this
attack, an Initiator should not react to an ICMP message until a 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 reasonable delta time to get the real Responder's R1 HIP packet. A
similar attack against the Responder is more involved. First an ICMP 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 message is expected if the I1 was a DoS attack and the real owner of
skipping to change at page 92, line 24 skipping to change at page 94, line 24
[18] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [18] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003. Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[19] Narten, T., "Assigning Experimental and Testing Numbers [19] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[20] Aura, T., "Cryptographically Generated Addresses (CGA)", [20] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[21] Schiller, J., "Cryptographic Algorithms for use in the Internet [21] Schiller, J., "Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
(work in progress), April 2004.
[22] Nikander, P., "A Non-Routable IPv6 Prefix for Keyed Hash [22] Nikander, P., "An IPv6 Prefix for Overlay Routable
Identifiers (KHI)", draft-laganier-ipv6-khi-00 (work in Cryptographic Hash Identifiers (ORCHID)",
progress), September 2005. draft-laganier-ipv6-khi-01 (work in progress), March 2006.
[23] Aboba, B., "The Network Access Identifier", [23] Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-06 (work in progress), July 2005. draft-ietf-radext-rfc2486bis-06 (work in progress), July 2005.
[24] Jokela, P., "Using ESP transport format with HIP", [24] Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-01 (work in progress), October 2005. draft-ietf-hip-esp-02 (work in progress), March 2006.
[25] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. [25] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
11.2. Informative References 11.2. Informative References
[26] Moskowitz, R. and P. Nikander, "Host Identity Protocol [26] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress), Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005. August 2005.
[27] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim [27] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-03 (work in progress), protocol", draft-ietf-shim6-proto-05 (work in progress),
December 2005. May 2006.
[28] Henderson, T. and P. Nikander, "Using HIP with Legacy [28] Henderson, T. and P. Nikander, "Using HIP with Legacy
Applications", draft-henderson-hip-applications-01 (work in Applications", draft-henderson-hip-applications-03 (work in
progress), July 2005. progress), May 2006.
[29] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP [29] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP
Base Exchange Protocol", in Proceedings of 10th Australasian Base Exchange Protocol", in Proceedings of 10th Australasian
Conference on Information Security and Privacy, July 2003. Conference on Information Security and Privacy, July 2003.
[30] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to [30] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and Its Use in the IKE-Protocols", Authenticated Diffie-Hellman and Its Use in the IKE-Protocols",
in Proceedings of CRYPTO 2003, pages 400-425, August 2003. in Proceedings of CRYPTO 2003, pages 400-425, August 2003.
[31] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic [31] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic
skipping to change at page 94, line 31 skipping to change at page 96, line 31
pre-generated R1s must be recalculated when the Diffie-Hellman key is pre-generated R1s must be recalculated when the Diffie-Hellman key is
recomputed or when the R1_COUNTER value changes due to S value recomputed or when the R1_COUNTER value changes due to S value
regeneration. regeneration.
When the Initiator sends the I1 packet for initializing a connection, When the Initiator sends the I1 packet for initializing a connection,
the Responder gets the HIT and IP address from the packet, and the Responder gets the HIT and IP address from the packet, and
generates an I-value for the puzzle. The I value is set to the pre- generates an I-value for the puzzle. The I value is set to the pre-
signed R1 packet. signed R1 packet.
I value calculation: I value calculation:
I = Ltrunc( PHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), 64) I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), 64)
The PHASH algorithm is the same that is used to generate the The RHASH algorithm is the same that is used to generate the
Responder's HIT value. Responder's HIT value.
From an incoming I2 packet, the Responder gets the required From an incoming I2 packet, the Responder gets the required
information to validate the puzzle: HITs, IP addresses, and the information to validate the puzzle: HITs, IP addresses, and the
information of the used S value from the R1_COUNTER. Using these information of the used S value from the R1_COUNTER. Using these
values, the Responder can regenerate the I, and verify it against the values, the Responder can regenerate the I, and verify it against the
I received in the I2 packet. If the I values match, it can verify I received in the I2 packet. If the I values match, it can verify
the solution using I, J, and difficulty K. If the I values do not the solution using I, J, and difficulty K. If the I values do not
match, the I2 is dropped. match, the I2 is dropped.
puzzle_check: puzzle_check:
V := Ltrunc( PHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), K ) V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), K )
if V != 0, drop the packet if V != 0, drop the packet
If the puzzle solution is correct, the I and J values are stored for If the puzzle solution is correct, the I and J values are stored for
later use. They are used as input material when keying material is later use. They are used as input material when keying material is
generated. generated.
The Responder SHOULD NOT keep state about failed puzzle solutions. The Responder SHOULD NOT keep state about failed puzzle solutions.
Appendix B. Generating a HIT from a HI Appendix B. Generating a Public Key Encoding from a HI
The following pseudo-codes illustrate the process to generate a The following pseudo-codes illustrate the process to generate a
public key encoding from a HI for both RSA and DSA. public key encoding from a HI for both RSA and DSA.
The symbol := denotes assignment; the symbol += denotes appending. The symbol := denotes assignment; the symbol += denotes appending.
The pseudo-function encode_in_network_byte_order takes two The pseudo-function encode_in_network_byte_order takes two
parameters, an integer (bignum) and a length in bytes, and returns parameters, an integer (bignum) and a length in bytes, and returns
the integer encoded into a byte string of the given length. the integer encoded into a byte string of the given length.
switch ( HI.algorithm ) switch ( HI.algorithm )
 End of changes. 74 change blocks. 
305 lines changed or deleted 363 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/