draft-ietf-hip-base-08.txt   draft-ietf-hip-base-09.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: December 13, 2007 Corporation Expires: April 4, 2008 Corporation
P. Nikander P. Nikander
P. Jokela (editor) P. Jokela (editor)
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
June 11, 2007 October 2, 2007
Host Identity Protocol Host Identity Protocol
draft-ietf-hip-base-08 draft-ietf-hip-base-09
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 December 13, 2007. This Internet-Draft will expire on April 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
HIP allows consenting hosts to securely establish and maintain shared HIP allows consenting hosts to securely establish and maintain shared
IP-layer state, allowing separation of the identifier and locator IP-layer state, allowing separation of the identifier and locator
skipping to change at page 2, line 41 skipping to change at page 2, line 41
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10
3.2. Generating a HIT from a HI . . . . . . . . . . . . . . . 11 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.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17 4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 17
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 19
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 20
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 20
4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20 4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 21
4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 21 4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 22
4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 28 4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 29
4.5. User Data Considerations . . . . . . . . . . . . . . . . 30 4.5. User Data Considerations . . . . . . . . . . . . . . . . 31
4.5.1. TCP and UDP Pseudo-header Computation for User Data . 30 4.5.1. TCP and UDP Pseudo-header Computation for User Data . 31
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 30 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 31
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 30 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 31
4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 30 4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 31
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 31 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 32
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 32 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 32 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 33 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 34
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 34 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 35
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 35 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 36
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 37 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 38
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 39 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 40
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 40 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 41
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 42 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 43
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 43 5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 44
5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 44 5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 45
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 47 5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 48
5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 48 5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 49
5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 50 5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 51
5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 51 5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 52
5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 54 5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 55
5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 55 5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 56
5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 55 5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 56
5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 56 5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 57
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 56 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 57 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 58
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 58 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 59
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 60 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 61
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 61 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 62
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 62 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 63
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 63 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 64
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 63 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 64
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 64 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 65
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 64 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 65 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 66
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 65 Structure . . . . . . . . . . . . . . . . . . . . . . 66
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 66
5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65 5.4.4. Non-existing HIP Association . . . . . . . . . . . . 66
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 67
6.1. Processing Outgoing Application Data . . . . . . . . . . 66 6.1. Processing Outgoing Application Data . . . . . . . . . . 67
6.2. Processing Incoming Application Data . . . . . . . . . . 67 6.2. Processing Incoming Application Data . . . . . . . . . . 68
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 69
6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69 6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 70
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 70
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 71 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 72
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 73 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 74
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 75 6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 76
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 76 6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 77
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 76 Messages . . . . . . . . . . . . . . . . . . . . . . 77
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 76 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 77
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 78 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 79
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 78 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 79
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 78 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 79
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 80 6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 81
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 80 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 81
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 83 6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 84
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 83 6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 84
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 83 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 84
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 84 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 85
6.12.1. Handling a SEQ parameter in a received UPDATE 6.12.1. Handling a SEQ parameter in a received UPDATE
message . . . . . . . . . . . . . . . . . . . . . . . 85 message . . . . . . . . . . . . . . . . . . . . . . . 86
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 86 Packet . . . . . . . . . . . . . . . . . . . . . . . 87
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 86 6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 87
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 86 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 87
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 87 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 87 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 88 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89
8. Security Considerations . . . . . . . . . . . . . . . . . . . 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 90
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.1. Normative References . . . . . . . . . . . . . . . . . . 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 96
11.2. Informative References . . . . . . . . . . . . . . . . . 96 11.2. Informative References . . . . . . . . . . . . . . . . . 97
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 99
Appendix B. Generating a Public Key Encoding from a HI . . . . . 100 Appendix B. Generating a Public Key Encoding from a HI . . . . . 101
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 101 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 102
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 101 C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 102
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 101 C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 102
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 102
Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 103 Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 104
Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 104 Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
Intellectual Property and Copyright Statements . . . . . . . . . 106 Intellectual Property and Copyright Statements . . . . . . . . . 107
1. Introduction 1. Introduction
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
A high-level description of the protocol and the underlying A high-level description of the protocol and the underlying
architectural thinking is available in the separate HIP architecture architectural thinking is available in the separate HIP architecture
description [I-D.ietf-hip-arch]. Briefly, the HIP architecture description [I-D.ietf-hip-arch]. Briefly, the HIP architecture
proposes an alternative to the dual use of IP addresses as "locators" proposes an alternative to the dual use of IP addresses as "locators"
(routing labels) and "identifiers" (endpoint, or host, identifiers). (routing labels) and "identifiers" (endpoint, or host, identifiers).
In HIP, public cryptographic keys, of a public/private key pair, are In HIP, public cryptographic keys, of a public/private key pair, are
skipping to change at page 6, line 29 skipping to change at page 6, line 29
packet design helps to make HIP DoS resilient. The protocol packet design helps to make HIP DoS resilient. The protocol
exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and
authenticates the parties in the 3rd and 4th packets. Additionally, authenticates the parties in the 3rd and 4th packets. Additionally,
the Responder starts a puzzle exchange in the 2nd packet, with the the Responder starts a puzzle exchange in the 2nd packet, with the
Initiator completing it in the 3rd packet before the Responder stores Initiator completing it in the 3rd packet before the Responder stores
any state from the exchange. any state from the exchange.
The exchange can use the Diffie-Hellman output to encrypt the Host The exchange can use the Diffie-Hellman output to encrypt the Host
Identity of the Initiator in packet 3 (although Aura et al. [AUR03] Identity of the Initiator in packet 3 (although Aura et al. [AUR03]
notes that such operation may interfere with packet-inspecting notes that such operation may interfere with packet-inspecting
middleboxes), or the Host Identity may instead be sent unencrypted. middle-boxes), or the Host Identity may instead be sent unencrypted.
The Responder's Host Identity is not protected. It should be noted, The Responder's Host Identity is not protected. It should be noted,
however, that both the Initiator's and the Responder's HITs are however, that both the Initiator's and the Responder's HITs are
transported as such (in cleartext) in the packets, allowing an transported as such (in cleartext) in the packets, allowing an
eavesdropper with a priori knowledge about the parties to verify eavesdropper with a priori knowledge about the parties to verify
their identities. their identities.
Data packets start to flow after the 4th packet. The 3rd and 4th HIP Data packets start to flow after the 4th packet. The 3rd and 4th HIP
packets may carry a data payload in the future. However, the details packets may carry a data payload in the future. However, the details
of this are to be defined later as more implementation experience is of this are to be defined later as more implementation experience is
gained. gained.
skipping to change at page 17, line 47 skipping to change at page 17, line 47
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 4.1.6. HIP Opportunistic Mode
It is possible to initiate a HIP negotiation even if the responder's 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 HI (and HIT) is unknown. In this case the connection initializing I1
packet contains NULL (all zeros) as the destination HIT. This kind packet contains NULL (all zeros) as the destination HIT. This kind
of connection setup is called opportunistic mode. of connection setup is called opportunistic mode.
There are multiple security issues involved with opportunistic mode There are both security and API issues involved with the
that must be carefully addressed in the implementation. Such a set opportunistic mode.
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, Given that the responder's HI is not known by the initiator, there
and outlines the basic signalling mechanism to trigger it; i.e., send must be suitable API calls that allow the initiator to request,
an I1 with a NULL destination HIT, this document does not specify the directly or indirectly, the underlying kernel to initiate the HIP
details of the opportunistic mode. Especially, its security base exchange solely based on locators. The responder's HI will be
properties are not discussed beyond the warning above. However, the tentatively available in the R1 packet, and in an authenticated form
authors believe that using the opportunistic mode is no less secure once the R2 packet has been received and verified. Hence, it could
than communicating, without any cryptographic protection, over the be communicated to the application via new API mechanisms. However,
current Internet. It is expected that a separate document will with a backwards compatible API the application sees only the
describe the opportunistic mode in more detail, including its locators used for the initial contact. Depending on the desired
security properties. semantics of the API, this can raise the following issues:
o The actual locators may later change if an UPDATE message is used,
even if from the API perspective the session still appears to be
between specific locators. The locator update is still secure,
however, and the session is still between the same nodes.
o Different sessions between the same locators may result in
connections to different nodes, if the implementation no longer
remembers which identifier the peer had in another session. This
is possible when the peer's locator has changed for legitimate
reasons or when an attacker pretends to be a node that has the
peer's locator.
If the HIP implementation and application do not have the same
understanding of what constitutes a session, this may even happen
within the same session. For instance, an implementation may not
know when HIP state can be purged for UDP based applications.
In addition, the following security considerations apply. The
generation counter mechanism will be less efficient in protecting
against replays of the R1 packet, given that the responder can choose
a replay that uses any HI, not just the one given in the I1 packet.
More importantly, the opportunistic exchange is vulnerable to man-in-
the-middle attacks, because the initiator does not have any public
key information about the peer. To assess the impacts of this
vulnerability, we compare it to vulnerabilities in current, non-HIP
capable communications.
An attacker on the path between the two peers can insert itself as a
man-in the middle by providing its own identifier to the initiator
and then initiating another HIP session towards the responder. For
this to be possible, the initiator must employ opportunistic mode,
and the responder must be configured to accept a connection from any
HIP enabled node.
An attacker outside the path will be unable to do so, given that it
cannot respond to the messages in the base exchange.
These properties are characteristic also of communications in the
current Internet. A client contacting a server without employing
end-to-end security may find itself talking to the server via a man-
in-the-middle. Assuming again that the server is willing to talk to
anyone.
If end-to-end security is in place, then the worst that can happen in
both the opportunistic HIP and normal IP cases is denial-of-service;
an entity on the path can disrupt communications, but will be unable
to insert itself as a man-in-the-middle.
However, once the opportunistic exchange has successfully completed,
HIP provides integrity protection and confidentiality for the
communications, and can securely change the locators of the
endpoints.
As a result, it is believed that the HIP opportunistic mode is at
least as secure as current IP.
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 29, line 37 skipping to change at page 30, line 37
| | +--------------+ | | | | +--------------+ | |
| | | | | receive I2, send R2 | | | | | | | receive I2, send R2 | |
| | recv+------------+ | +------------------------+ | | | recv+------------+ | +------------------------+ |
| | CLOSE,| | | | | | CLOSE,| | | |
| | send| No packet sent| | | | | send| No packet sent| | |
| | CLOSE_ACK| /received for | timeout | | | | CLOSE_ACK| /received for | timeout | |
| | | UAL min, send | +---------+<-+ (UAL+MSL) | | | | | UAL min, send | +---------+<-+ (UAL+MSL) | |
| | | CLOSE +--->| CLOSING |--+ retransmit | | | | | CLOSE +--->| CLOSING |--+ retransmit | |
| | | +---------+ CLOSE | | | | | +---------+ CLOSE | |
+--|------------|----------------------+ | | | | | | +--|------------|----------------------+ | | | | | |
| +------------|------------------------+ | | +----------------+ | +------------|------------------------+ | | +----------------+ |
| | | +-----------+ +------------------|--+ | | +-----------+ +------------------|--+
| | +------------+ | receive CLOSE, CLOSE_ACK | | | +------------+ | receive CLOSE, CLOSE_ACK | |
| | | | send CLOSE_ACK received or | | | | | send CLOSE_ACK received or | |
| | | | timeout | | | | | timeout | |
| | | | (UAL+MSL) | | | | | (UAL+MSL) | |
| | v v | | | v v | |
| | +--------+ receive I2, send R2 | | | +--------+ receive I2, send R2 | |
| +------------------------| CLOSED |---------------------------+ | +------------------------| CLOSED |---------------------------+ |
+---------------------------+--------+ /----------------------+ +--------+ /----------------------+
Datagram to send, send I1 ^ | \-------/ timeout (UAL+2MSL), ^ | \-------/ timeout (UAL+2MSL),
+-+ move to UNASSOCIATED +-+ move to UNASSOCIATED
CLOSE received, send CLOSE_ACK CLOSE received, send CLOSE_ACK
4.5. User Data Considerations 4.5. User Data Considerations
4.5.1. TCP and UDP Pseudo-header Computation for User Data 4.5.1. TCP and UDP Pseudo-header Computation for User Data
When computing TCP and UDP checksums on user data packets that flow When computing TCP and UDP checksums on user data packets that flow
through sockets bound to HITs, the IPv6 pseudo-header format through sockets bound to HITs, the IPv6 pseudo-header format
[RFC2460] MUST be used, even if the actual addresses on the packet [RFC2460] MUST be used, even if the actual addresses on the packet
skipping to change at page 55, line 32 skipping to change at page 56, line 32
that the sender wants to get echoed back in the corresponding reply that the sender wants to get echoed back in the corresponding reply
packet. packet.
The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters
MAY be used for any purpose where a node wants to carry some state in MAY be used for any purpose where a node wants to carry some state in
a request packet and get it back in a response packet. The a request packet and get it back in a response packet. The
ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A
HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters
in HIP packets passing by. The sender has to create the Opaque field in HIP packets passing by. The sender has to create the Opaque field
so that it can later identify the corresponding so that it can later identify and remove the corresponding
ECHO_RESPONSE_UNSIGNED parameter. ECHO_RESPONSE_UNSIGNED parameter.
The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an
ECHO_RESPONSE_UNSIGNED parameter. ECHO_RESPONSE_UNSIGNED parameter.
5.2.19. ECHO_RESPONSE_SIGNED 5.2.19. ECHO_RESPONSE_SIGNED
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 64, line 20 skipping to change at page 65, line 20
IP ( HIP ( ECHO_REQUEST_SIGNED, HMAC, HIP_SIGNATURE ) ) IP ( HIP ( ECHO_REQUEST_SIGNED, HMAC, HIP_SIGNATURE ) )
Valid control bits: none Valid control bits: none
The sender MUST include an ECHO_REQUEST_SIGNED used to validate The sender MUST include an ECHO_REQUEST_SIGNED used to validate
CLOSE_ACK received in response, and both an HMAC and a signature CLOSE_ACK received in response, and both an HMAC and a signature
(calculated over the whole HIP envelope). (calculated over the whole HIP envelope).
The receiver peer MUST validate both the HMAC and the signature if it The receiver peer MUST validate both the HMAC and the signature if it
has a HIP association state, and MUST reply with a CLOSE_ACK has a HIP association state, and MUST reply with a CLOSE_ACK
containing an ECHO_REPLY_SIGNED corresponding to the received containing an ECHO_RESPONSE_SIGNED corresponding to the received
ECHO_REQUEST_SIGNED. ECHO_REQUEST_SIGNED.
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet
The HIP header values for the CLOSE_ACK packet: The HIP header values for the CLOSE_ACK packet:
Header: Header:
Packet Type = 19 Packet Type = 19
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Recipient's HIT DST HIT = Recipient's HIT
IP ( HIP ( ECHO_REPLY_SIGNED, HMAC, HIP_SIGNATURE ) ) IP ( HIP ( ECHO_RESPONSE_SIGNED, HMAC, HIP_SIGNATURE ) )
Valid control bits: none Valid control bits: none
The sender MUST include both an HMAC and signature (calculated over The sender MUST include both an HMAC and signature (calculated over
the whole HIP envelope). the whole HIP envelope).
The receiver peer MUST validate both the HMAC and the signature. The receiver peer MUST validate both the HMAC and the signature.
5.4. ICMP Messages 5.4. ICMP Messages
skipping to change at page 70, line 7 skipping to change at page 71, line 7
The scope of the calculation for HMAC and HMAC_2 is: The scope of the calculation for HMAC and HMAC_2 is:
HMAC: { HIP header | [ Parameters ] } HMAC: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters of the packet that is where Parameters include all HIP parameters of the packet that is
being calculated with Type values from 1 to (HMAC's Type value - 1) being calculated with Type values from 1 to (HMAC's Type value - 1)
and exclude parameters with Type values greater or equal to HMAC's and exclude parameters with Type values greater or equal to HMAC's
Type value. Type value.
During HMAC Calculation, the following applies: During HMAC calculation, the following applies:
o In HIP header, Checksum field is set to zero. o In HIP header, Checksum field is set to zero.
o In HIP header, the Header Length field value is calculated to the o In HIP header, the Header Length field value is calculated to the
beginning of the HMAC parameter. beginning of the HMAC parameter.
Parameter order is described in Section 5.2.1. Parameter order is described in Section 5.2.1.
HMAC_2: { HIP header | [ Parameters ] | HOST_ID } HMAC_2: { HIP header | [ Parameters ] | HOST_ID }
where Parameters include all HIP parameters for the packet that is where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HMAC_2's Type value - 1) being calculated with Type values from 1 to (HMAC_2's Type value - 1)
and exclude parameters with Type values greater or equal to HMAC_2's and exclude parameters with Type values greater or equal to HMAC_2's
Type value. Type value.
During HMAC calculation, the following applies: During HMAC_2 calculation, the following applies:
o In HIP header, Checksum field is set to zero. o In HIP header, Checksum field is set to zero.
o In HIP header, the Header Length field value is calculated to the o In HIP header, the Header Length field value is calculated to the
beginning of the HMAC_2 parameter and added with the length of the beginning of the HMAC_2 parameter and added with the length of the
concatenated HOST_ID parameter length. concatenated HOST_ID parameter length.
o HOST_ID parameter is exactly in the form it was received in the R1 o HOST_ID parameter is exactly in the form it was received in the R1
packet from the Responder. packet from the Responder.
skipping to change at page 82, line 15 skipping to change at page 83, line 15
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.
10. The encrypted HOST_ID decrypted by the Initiator encryption key 10. The encrypted HOST_ID decrypted by the Initiator encryption key
defined in Section 6.5. If the decrypted data is not a HOST_ID defined in Section 6.5. If the decrypted data is not a HOST_ID
parameter, the I2 packet is silently dropped. parameter, the I2 packet is silently dropped.
11. The implementation MUST also verify that the Initiator's HIT in 11. The implementation SHOULD also verify that the Initiator's HIT
the I2 corresponds to the Host Identity sent in the I2. in the I2 corresponds to the Host Identity sent in the I2.
(Note: some middle-boxes may not able to make this
verification.)
12. The system MUST verify the HMAC according to the procedures in 12. The system MUST verify the HMAC according to the procedures in
Section 5.2.9. Section 5.2.9.
13. The system MUST verify the HIP_SIGNATURE according to 13. The system MUST verify the HIP_SIGNATURE according to
Section 5.2.11 and Section 5.3.3. Section 5.2.11 and Section 5.3.3.
14. If the checks above are valid, then the system proceeds with 14. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and remains further I2 processing; otherwise, it discards the I2 and remains
in the same state. in the same state.
skipping to change at page 87, line 17 skipping to change at page 88, line 17
will trigger creating and establishing of a new HIP association, will trigger creating and establishing of a new HIP association,
starting with sending an I1. starting with sending an I1.
If there is no corresponding HIP association, the CLOSE packet is If there is no corresponding HIP association, the CLOSE packet is
dropped. dropped.
6.15. Processing CLOSE_ACK Packets 6.15. Processing CLOSE_ACK Packets
When a host receives a CLOSE_ACK message it verifies that it is in When a host receives a CLOSE_ACK message it verifies that it is in
CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
CLOSE (using the included ECHO_REPLY_SIGNED in response to the sent CLOSE (using the included ECHO_RESPONSE_SIGNED in response to the
ECHO_REQUEST_SIGNED). sent ECHO_REQUEST_SIGNED).
The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is
discarded when the state changes to UNASSOCIATED and, after that, the discarded when the state changes to UNASSOCIATED and, after that, the
host MAY respond with an ICMP Parameter Problem to an incoming CLOSE host MAY respond with an ICMP Parameter Problem to an incoming CLOSE
message (See Section 5.4.4). message (See Section 5.4.4).
6.16. Handling State Loss 6.16. Handling State Loss
In the case of system crash and unanticipated state loss, the system In the case of system crash and unanticipated state loss, the system
SHOULD delete the corresponding HIP state, including the keying SHOULD delete the corresponding HIP state, including the keying
skipping to change at page 90, line 48 skipping to change at page 91, line 48
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.
The HIP Opportunistic Mode concept has been introduced in this The HIP Opportunistic Mode concept has been introduced in this
document, but this document does not specify the details of such a document, but this document does not specify what the semantics of
connection set up (Section 4.1.6). There are certain security such connection set up are for applications. There are certain
concerns with opportunistic mode, and they must be addressed in a concerns with opportunistic mode, as discussed in Section 4.1.6.
separate document if such a mode will be used.
NOTIFY messages are used only for informational purposes and they are NOTIFY messages are used only for informational purposes and they are
unacknowledged. A HIP implementation cannot rely solely on the unacknowledged. A HIP implementation cannot rely solely on the
information received in a NOTIFY message because the packet may have information received in a NOTIFY message because the packet may have
been replayed. It SHOULD NOT change any state information based been replayed. It SHOULD NOT change any state information based
purely on a received NOTIFY message. 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
 End of changes. 21 change blocks. 
140 lines changed or deleted 195 lines changed or added

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