draft-ietf-hip-rfc5201-bis-19.txt   draft-ietf-hip-rfc5201-bis-20.txt 
Network Working Group R. Moskowitz, Ed. Network Working Group R. Moskowitz, Ed.
Internet-Draft Verizon Internet-Draft Verizon
Obsoletes: 5201 (if approved) T. Heer Obsoletes: 5201 (if approved) T. Heer
Intended status: Standards Track Hirschmann Automation and Control Intended status: Standards Track Hirschmann Automation and Control
Expires: March 26, 2015 P. Jokela Expires: May 2, 2015 P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
University of Washington University of Washington
September 22, 2014 October 29, 2014
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-19 draft-ietf-hip-rfc5201-bis-20
Abstract Abstract
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). HIP allows consenting hosts to securely establish and (HIP). HIP allows consenting hosts to securely establish and
maintain shared IP-layer state, allowing separation of the identifier maintain shared IP-layer state, allowing separation of the identifier
and locator roles of IP addresses, thereby enabling continuity of and locator roles of IP addresses, thereby enabling continuity of
communications across IP address changes. HIP is based on a Diffie- communications across IP address changes. HIP is based on a Diffie-
Hellman key exchange, using public key identifiers from a new Host Hellman key exchange, using public key identifiers from a new Host
Identity namespace for mutual peer authentication. The protocol is Identity namespace for mutual peer authentication. The protocol is
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 26, 2015. This Internet-Draft will expire on May 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49
5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51
5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52
5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55
5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 57
5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 58 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 59
5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 59 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 60
5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 60 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 61
5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 62
5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 63 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 64
5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 67
5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 67 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 68
5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 68
5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 69
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 69 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 70
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 70 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 71
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 71
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 74
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 75 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 76
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 75 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 76
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 77
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 77 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 78
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 78
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 78 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 79
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 78 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 79
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 78 Structure . . . . . . . . . . . . . . . . . . . . . . 79
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 79
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 79 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 80
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 79 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 80
6.1. Processing Outgoing Application Data . . . . . . . . . . 79 6.1. Processing Outgoing Application Data . . . . . . . . . . 80
6.2. Processing Incoming Application Data . . . . . . . . . . 80 6.2. Processing Incoming Application Data . . . . . . . . . . 81
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 82
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 83 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 84
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 83 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 84
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 86
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 87 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 88
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 89 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 90
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 90 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 91
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 90 Messages . . . . . . . . . . . . . . . . . . . . . . 91
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 91 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 92
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 92 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 93
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 93
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 93 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 94
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 95 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 96
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 96
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 98 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 99
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 99 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 100
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 99 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 100
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 100 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 101
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . 101 Message . . . . . . . . . . . . . . . . . . . . . . 102
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 102 Packet . . . . . . . . . . . . . . . . . . . . . . . 103
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 102 6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 103
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 103 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 104
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 103 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 104
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 103 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 104
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 104 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 105
8. Security Considerations . . . . . . . . . . . . . . . . . . . 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 105
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 111 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 112
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 112 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 113
11.1. Changes from draft-ietf-hip-rfc5201-bis-18 . . . . . . . 112 11.1. Changes from draft-ietf-hip-rfc5201-bis-19 . . . . . . . 113
11.2. Changes from draft-ietf-hip-rfc5201-bis-17 . . . . . . . 112 11.2. Changes from draft-ietf-hip-rfc5201-bis-18 . . . . . . . 113
11.3. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 112 11.3. Changes from draft-ietf-hip-rfc5201-bis-17 . . . . . . . 113
11.4. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 113 11.4. Changes from draft-ietf-hip-rfc5201-bis-16 . . . . . . . 114
11.5. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 113 11.5. Changes from draft-ietf-hip-rfc5201-bis-15 . . . . . . . 114
11.6. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 113 11.6. Changes from draft-ietf-hip-rfc5201-bis-14 . . . . . . . 114
11.7. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 113 11.7. Changes from draft-ietf-hip-rfc5201-bis-13 . . . . . . . 114
11.8. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 113 11.8. Changes from draft-ietf-hip-rfc5201-bis-12 . . . . . . . 114
11.9. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 113 11.9. Changes from draft-ietf-hip-rfc5201-bis-11 . . . . . . . 114
11.10. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 113 11.10. Changes from draft-ietf-hip-rfc5201-bis-10 . . . . . . . 114
11.11. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 113 11.11. Changes from draft-ietf-hip-rfc5201-bis-09 . . . . . . . 115
11.12. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 114 11.12. Changes from draft-ietf-hip-rfc5201-bis-08 . . . . . . . 115
11.13. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 114 11.13. Changes from draft-ietf-hip-rfc5201-bis-07 . . . . . . . 115
11.14. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 114 11.14. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 115
11.15. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 115 11.15. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 115
11.16. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 116 11.16. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 116
11.17. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 117 11.17. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 117
11.18. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 117 11.18. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 118
11.19. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119 11.19. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 118
11.20. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 119 11.20. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 120
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 119 11.21. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . 120
12.1. Normative References . . . . . . . . . . . . . . . . . . 119 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 120
12.2. Informative References . . . . . . . . . . . . . . . . . 121 12.1. Normative References . . . . . . . . . . . . . . . . . . 120
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 124 12.2. Informative References . . . . . . . . . . . . . . . . . 122
Appendix B. Generating a Public Key Encoding from an HI . . 125 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 126
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 125 Appendix B. Generating a Public Key Encoding from an HI . . 127
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 126 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 127
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 126 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 128
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 127 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 128
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 127 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 129
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 127 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 129
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 129
1. Introduction 1. Introduction
This document specifies the details of the Host Identity Protocol This document specifies the details of the Host Identity Protocol
(HIP). A high-level description of the protocol and the underlying (HIP). 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-rfc4423-bis]. Briefly, the HIP description [I-D.ietf-hip-rfc4423-bis]. Briefly, the HIP
architecture proposes an alternative to the dual use of IP addresses architecture proposes an alternative to the dual use of IP addresses
as "locators" (routing labels) and "identifiers" (endpoint, or host, as "locators" (routing labels) and "identifiers" (endpoint, or host,
identifiers). In HIP, public cryptographic keys, of a public/private identifiers). In HIP, public cryptographic keys, of a public/private
skipping to change at page 9, line 24 skipping to change at page 9, line 24
Initiator: The host that initiates the BEX. This role is typically Initiator: The host that initiates the BEX. This role is typically
forgotten once the BEX is completed. forgotten once the BEX is completed.
Responder: The host that responds to the Initiator in the BEX. Responder: The host that responds to the Initiator in the BEX.
This role is typically forgotten once the BEX is completed. This role is typically forgotten once the BEX is completed.
Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for Responder's HIT Hash Algorithm (RHASH): The Hash algorithm used for
various hash calculations in this document. The algorithm is the various hash calculations in this document. The algorithm is the
same as is used to generate the Responder's HIT. The RHASH is the same as is used to generate the Responder's HIT. The RHASH is the
hash function defined by the HIT Suite of the Responder's HIT hash function defined by the HIT Suite of the Responder's HIT
(c.f. Appendix E). (c.f. Section 5.2.10).
Length of the Responder's HIT Hash Algorithm (RHASH_len): The Length of the Responder's HIT Hash Algorithm (RHASH_len): The
natural output length of RHASH in bits. natural output length of RHASH in bits.
Signed data: Data that is signed is protected by a digital Signed data: Data that is signed is protected by a digital
signature that was created by the sender of the data by using the signature that was created by the sender of the data by using the
private key of its HI. private key of its HI.
KDF: The Key Derivation Function (KDF) is used for deriving the KDF: The Key Derivation Function (KDF) is used for deriving the
symmetric keys from the Diffie-Hellman key exchange. symmetric keys from the Diffie-Hellman key exchange.
skipping to change at page 10, line 28 skipping to change at page 10, line 28
collision with a HIT that is in use. For details on the security collision with a HIT that is in use. For details on the security
properties of the HIT see [I-D.ietf-hip-rfc4423-bis]. properties of the HIT see [I-D.ietf-hip-rfc4423-bis].
The structure of the HIT is defined in [RFC7343]. The HIT is an The structure of the HIT is defined in [RFC7343]. The HIT is an
Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists
of three parts: first, an IANA assigned prefix to distinguish it from of three parts: first, an IANA assigned prefix to distinguish it from
other IPv6 addresses. Second, a four-bit encoding of the algorithms other IPv6 addresses. Second, a four-bit encoding of the algorithms
that were used for generating the HI and the hashed representation of that were used for generating the HI and the hashed representation of
HI. Third, a 96-bit hashed representation of the Host Identity. The HI. Third, a 96-bit hashed representation of the Host Identity. The
encoding of the ORCHID generation algorithm and the exact algorithm encoding of the ORCHID generation algorithm and the exact algorithm
for generating the hashed representation is specified in Appendix E. for generating the hashed representation is specified in Appendix E
and [RFC7343].
Carrying HIs and HITs in the header of user data packets would Carrying HIs and HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected that they increase the overhead of packets. Thus, it is not expected that they
are carried in every packet, but other methods are used to map the are carried in every packet, but other methods are used to map the
data packets to the corresponding HIs. In some cases, this makes it data packets to the corresponding HIs. In some cases, this makes it
possible to use HIP without any additional headers in the user data possible to use HIP without any additional headers in the user data
packets. For example, if ESP is used to protect data traffic, the packets. For example, if ESP is used to protect data traffic, the
Security Parameter Index (SPI) carried in the ESP header can be used Security Parameter Index (SPI) carried in the ESP header can be used
to map the encrypted data packet to the correct HIP association. to map the encrypted data packet to the correct HIP association.
skipping to change at page 11, line 25 skipping to change at page 11, line 27
3.2. Generating a HIT from an HI 3.2. Generating a HIT from an HI
The HIT MUST be generated according to the ORCHID generation method The HIT MUST be generated according to the ORCHID generation method
described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4 described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4
3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly
by the editor of this specification), and an input that encodes the by the editor of this specification), and an input that encodes the
Host Identity field (see Section 5.2.9) present in a HIP payload Host Identity field (see Section 5.2.9) present in a HIP payload
packet. The set of hash function, signature algorithm, and the packet. The set of hash function, signature algorithm, and the
algorithm used for generating the HIT from the HI depends on the HIT algorithm used for generating the HIT from the HI depends on the HIT
Suite (see Appendix E) and is indicated by the four bits of the Suite (see Section 5.2.10) and is indicated by the four bits of the
ORCHID Generation Algorithm (OGA) field in the ORCHID. Currently, ORCHID Generation Algorithm (OGA) field in the ORCHID. Currently,
truncated SHA-1, truncated SHA-384, and truncated SHA-256 truncated SHA-1, truncated SHA-384, and truncated SHA-256
[FIPS.180-2.2002] are defined as hashes for generating a HIT. [FIPS.180-2.2002] are defined as hashes for generating a HIT.
For identities that are either RSA, Digital Signature Algorithm (DSA) For identities that are either RSA, Digital Signature Algorithm (DSA)
[FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID
input consists of the public key encoding as specified for the Host input consists of the public key encoding as specified for the Host
Identity field of the HOST_ID parameter (see Section 5.2.9). This Identity field of the HOST_ID parameter (see Section 5.2.9). This
document defines four algorithm profiles: RSA, DSA, ECDSA, and document defines four algorithm profiles: RSA, DSA, ECDSA, and
ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low
skipping to change at page 56, line 22 skipping to change at page 56, line 22
| ID #n | Padding | | ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 715 Type 715
Length number of HIT Suite IDs Length number of HIT Suite IDs
ID identifies a HIT Suite ID supported by the host. ID identifies a HIT Suite ID supported by the host.
The list of IDs is ordered by preference of the The list of IDs is ordered by preference of the
host. Each HIT Suite ID is one octet long. The four host. Each HIT Suite ID is one octet long. The four
higher-order bits of the ID field correspond to the higher-order bits of the ID field correspond to the
HIT Suite ID in the ORCHID OGA field. The four HIT Suite ID in the ORCHID OGA field. The four
lower-order bits are reserved and set to 0 and lower-order bits are reserved and set to 0 by
ignored by the receiver. the sender. The reception of an ID with the
four lower-order bits not set to 0 SHOULD be
considered as an error that MAY result in a
NOTIFICATION of type UNSUPPORTED_HIT_SUITE.
The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of
signature algorithms as defined in Section 5.2.9 and hash functions. signature algorithms as defined in Section 5.2.9 and hash functions.
The ID field in the HIT_SUITE_LIST is defined as eight-bit field as The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
opposed to the four-bit HIT Suite ID and OGA field in the ORCHID. opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
This difference is a measure to accommodate larger HIT Suite IDs if This difference is a measure to accommodate larger HIT Suite IDs if
the 16 available values prove insufficient. In that case, one of the the 16 available values prove insufficient. In that case, one of the
16 values, zero, will be used to indicate that four additional bits 16 values, zero, will be used to indicate that four additional bits
of the ORCHID will be used to encode the HIT Suite ID. Hence, the of the ORCHID will be used to encode the HIT Suite ID. Hence, the
current four-bit HIT Suite-IDs only use the four higher order bits in current four-bit HIT Suite-IDs only use the four higher order bits in
the ID field. Future documents may define the use of the four lower- the ID field. Future documents may define the use of the four lower-
order bits in the ID field. order bits in the ID field.
The following HIT Suites ID are defined: The following HIT Suites ID are defined, and the relationship between
the four-bit ID value used in the OGA ID field, and the eight-bit
encoding within the HIT_SUITE_LIST ID field, is clarified:
HIT Suite ID HIT Suite Four-bit ID Eight-bit encoding
RESERVED 0 RESERVED 0 0x00
RSA,DSA/SHA-256 1 (REQUIRED) RSA,DSA/SHA-256 1 0x10 (REQUIRED)
ECDSA/SHA-384 2 (RECOMMENDED) ECDSA/SHA-384 2 0x20 (RECOMMENDED)
ECDSA_LOW/SHA-1 3 (RECOMMENDED) ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)
The following table provides more detail on the above HIT Suite
combinations. The input for each generation algorithm is the
encoding of the HI as defined in Section 3.2. The output is 96 bits
long and is directly used in the ORCHID.
+-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+-------+----------+--------------+------------+--------------------+
| 0 | | | | Reserved |
| 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI |
| | | | | hashed with |
| | | | | SHA-256, truncated |
| | | | | to 96 bits |
| 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed |
| | | | | with SHA-384, |
| | | | | truncated to 96 |
| | | | | bits |
| 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI |
| | | | | hashed with SHA-1, |
| | | | | truncated to 96 |
| | | | | bits |
+-------+----------+--------------+------------+--------------------+
Table 10: HIT Suites
The hash of the responder as defined in the HIT Suite determines the
HMAC to be used for the RHASH function. The HMACs currently defined
here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC-
SHA-1 [RFC2404].
5.2.11. TRANSPORT_FORMAT_LIST 5.2.11. TRANSPORT_FORMAT_LIST
The TRANSPORT_FORMAT_LIST parameter contains a list of the supported The TRANSPORT_FORMAT_LIST parameter contains a list of the supported
HIP transport formats (TFs) of the Responder. The Responder sends HIP transport formats (TFs) of the Responder. The Responder sends
the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based
on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable
transport format and includes the respective HIP transport format transport format and includes the respective HIP transport format
parameter in its response packet. parameter in its response packet.
skipping to change at page 69, line 9 skipping to change at page 70, line 9
wants to get echoed back. The opaque data is copied unmodified from wants to get echoed back. The opaque data is copied unmodified from
the corresponding echo request parameter. the corresponding echo request parameter.
The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used
for any purpose where a node wants to carry some state in a request for any purpose where a node wants to carry some state in a request
packet and get it back in a response packet. The packet and get it back in a response packet. The
ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE.
5.3. HIP Packets 5.3. HIP Packets
There are eight basic HIP packets (see Table 10). 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 are for closing a HIP association. Support notifications, and two are for closing a HIP association. Support
for NOTIFY packet type is optional, but support for all other HIP for NOTIFY packet type is optional, but support for all other HIP
packet types listed below is mandatory. packet types listed below is mandatory.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| Packet type | Packet name | | Packet type | Packet name |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| 1 | I1 - the HIP Initiator Packet | | 1 | I1 - the HIP Initiator Packet |
| | | | | |
skipping to change at page 69, line 36 skipping to change at page 70, line 36
| 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 | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment |
| | Packet | | | Packet |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 10: HIP packets and packet type values Table 11: HIP packets and packet type values
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 TLV-coded parameters. zero or more TLV-coded parameters.
In addition to the base packets, other packet types may be defined In addition to the base packets, other packet types may 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 the notation used in the operations. See Notation (Section 2.2) for the notation used in the operations.
skipping to change at page 108, line 18 skipping to change at page 109, line 18
HIT Suite ID HIT Suite ID
This specification creates a new registry for "HIT Suite ID". This specification creates a new registry for "HIT Suite ID".
This is different than the existing registry for "Suite ID" which This is different than the existing registry for "Suite ID" which
can be left unmodified for version 1 of the protocol ([RFC5201]). can be left unmodified for version 1 of the protocol ([RFC5201]).
The registry should be closed to new registrations. The registry should be closed to new registrations.
The four-bit HIT Suite ID uses the OGA field in the ORCHID to The four-bit HIT Suite ID uses the OGA field in the ORCHID to
express the type of the HIT. This document defines three HIT express the type of the HIT. This document defines three HIT
Suites (see Appendix E). Suites (see Section 5.2.10).
The HIT Suite ID is also carried in the four higher-order bits of The HIT Suite ID is also carried in the four higher-order bits of
the ID field in the HIT_SUITE_LIST parameter. The four lower- the ID field in the HIT_SUITE_LIST parameter. The four lower-
order bits are reserved for future extensions of the HIT Suite ID order bits are reserved for future extensions of the HIT Suite ID
space beyond 16 values. space beyond 16 values.
For the time being, the HIT Suite uses only four bits because For the time being, the HIT Suite uses only four bits because
these bits have to be carried in the HIT. Using more bits for the these bits have to be carried in the HIT. Using more bits for the
HIT Suite ID reduces the cryptographic strength of the HIT. HIT HIT Suite ID reduces the cryptographic strength of the HIT. HIT
Suite IDs must be allocated carefully to avoid namespace Suite IDs must be allocated carefully to avoid namespace
exhaustion. Moreover, deprecated IDs should be reused after an exhaustion. Moreover, deprecated IDs should be reused after an
appropriate time span. If 16 Suite IDs prove insufficient and appropriate time span. If 15 Suite IDs (the zero value is
more HIT Suite IDs are needed concurrently, more bits can be used initially reserved) prove to be insufficient and more HIT Suite
for the HIT Suite ID by using one HIT Suite ID (0) to indicate IDs are needed concurrently, more bits can be used for the HIT
that more bits should be used. The HIT_SUITE_LIST parameter Suite ID by using one HIT Suite ID (0) to indicate that more bits
already supports 8-bit HIT Suite IDs, should longer IDs be needed. should be used. The HIT_SUITE_LIST parameter already supports
Possible extensions of the HIT Suite ID space to accommodate eight 8-bit HIT Suite IDs, should longer IDs be needed. However, RFC
bits and new HIT Suite IDs are defined through IETF Review. 7343 [RFC7343] does not presently support such an extension, and
the rollover approach described in Appendix E is suggested to be
tried first. Possible extensions of the HIT Suite ID space to
accommodate eight bits and new HIT Suite IDs are defined through
IETF Review.
Requests to register reused values should include a note that the Requests to register reused values should include a note that the
value is being reused after a deprecation period, to ensure value is being reused after a deprecation period, to ensure
appropriate IETF review and approval. appropriate IETF review and approval.
Parameter Type Parameter Type
The 16-bit Type field in a HIP parameter describes the type of the The 16-bit Type field in a HIP parameter describes the type of the
parameter. It is defined in Section 5.2.1. The current values parameter. It is defined in Section 5.2.1. The current values
are defined in Sections 5.2.3 through 5.2.23. The existing are defined in Sections 5.2.3 through 5.2.23. The existing
skipping to change at page 112, line 24 skipping to change at page 113, line 24
changes were introduced through the working group process. Most changes were introduced through the working group process. Most
notably, the original document was split in two, one containing the notably, the original document was split in two, one containing the
base exchange and the other one defining how to use ESP. Some base exchange and the other one defining how to use ESP. Some
modifications to the protocol proposed by Aura, et al., [AUR03] were modifications to the protocol proposed by Aura, et al., [AUR03] were
added at a later stage. added at a later stage.
11. Changes from RFC 5201 11. Changes from RFC 5201
This section summarizes the changes made from [RFC5201]. This section summarizes the changes made from [RFC5201].
11.1. Changes from draft-ietf-hip-rfc5201-bis-18 11.1. Changes from draft-ietf-hip-rfc5201-bis-19
o Clarified encoding of HIT Suite ID in HIT_SUITE_LIST parameter.
Moved Table 11 from Appendix E forward to the HIT_SUITE_LIST
parameter section.
o Clarified the possible strategies for reusing HIT Suite ID values
or expanding the field, noting that RFC 7343 does not support HIT
Suite ID field expansion and that any such future changes are to
be defined through IETF Review.
11.2. Changes from draft-ietf-hip-rfc5201-bis-18
o Correct documentation prefix in Appendix C from 2001:D88/32 to o Correct documentation prefix in Appendix C from 2001:D88/32 to
2001:DB8/32, and update IPv6 checksum 2001:DB8/32, and update IPv6 checksum
o Correct documentation prefix reference from RFC 5747 to 5737 o Correct documentation prefix reference from RFC 5747 to 5737
o Clarified HIT generation in Appendix E o Clarified HIT generation in Appendix E
11.2. Changes from draft-ietf-hip-rfc5201-bis-17 11.3. Changes from draft-ietf-hip-rfc5201-bis-17
o Update ORCHID reference to newly published RFC 7343 o Update ORCHID reference to newly published RFC 7343
o Update example checksum section to RFC 7343 HIT prefix of o Update example checksum section to RFC 7343 HIT prefix of
2001:20::/28, and fix incorrect Header Length fields 2001:20::/28, and fix incorrect Header Length fields
o Update IANA considerations comment on legacy HIP_TRANSFORM o Update IANA considerations comment on legacy HIP_TRANSFORM
parameter naming parameter naming
o Add 2048-bit MODP DHE group as Group ID value 11. o Add 2048-bit MODP DHE group as Group ID value 11.
11.3. Changes from draft-ietf-hip-rfc5201-bis-16 11.4. Changes from draft-ietf-hip-rfc5201-bis-16
o Clarify that receipt of user data in state CLOSING (Table 7) o Clarify that receipt of user data in state CLOSING (Table 7)
results in transition to I1-SENT results in transition to I1-SENT
o Add academic reference for the first mention of the RSA algorithm o Add academic reference for the first mention of the RSA algorithm
o As part of comment resolution on use of NULL encryption, note that o As part of comment resolution on use of NULL encryption, note that
use of a NULL HIP CIPHER is only to be used when debugging and use of a NULL HIP CIPHER is only to be used when debugging and
testing the HIP protocol. This only pertains to the ENCRYPTED testing the HIP protocol. This only pertains to the ENCRYPTED
parameter, which is optional; in practice, if encryption is not parameter, which is optional; in practice, if encryption is not
desired, better to just not encrypt the Host ID. desired, better to just not encrypt the Host ID.
11.4. Changes from draft-ietf-hip-rfc5201-bis-15 11.5. Changes from draft-ietf-hip-rfc5201-bis-15
o Additional edits to IANA Considerations section based on initial o Additional edits to IANA Considerations section based on initial
IANA review. IANA review.
11.5. Changes from draft-ietf-hip-rfc5201-bis-14 11.6. Changes from draft-ietf-hip-rfc5201-bis-14
o Update source XML to comply with xmlrfcv2 version of the xml2rfc o Update source XML to comply with xmlrfcv2 version of the xml2rfc
tool, resulting in a few table formatting changes. tool, resulting in a few table formatting changes.
o Editorial and minor technical revisions based on IESG review. o Editorial and minor technical revisions based on IESG review.
o Significant revisions to IANA Considerations section based on o Significant revisions to IANA Considerations section based on
initial IANA review. initial IANA review.
11.6. Changes from draft-ietf-hip-rfc5201-bis-13 11.7. Changes from draft-ietf-hip-rfc5201-bis-13
o Update a few references and fix some editorial nits. o Update a few references and fix some editorial nits.
11.7. Changes from draft-ietf-hip-rfc5201-bis-12 11.8. Changes from draft-ietf-hip-rfc5201-bis-12
o Fix I-D nits. o Fix I-D nits.
11.8. Changes from draft-ietf-hip-rfc5201-bis-11 11.9. Changes from draft-ietf-hip-rfc5201-bis-11
o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix
incorrect section reference. incorrect section reference.
11.9. Changes from draft-ietf-hip-rfc5201-bis-10 11.10. Changes from draft-ietf-hip-rfc5201-bis-10
o Issue 39: Text clarifying R1 counter rollover and Initiator o Issue 39: Text clarifying R1 counter rollover and Initiator
response to unexpected reset of the counter. response to unexpected reset of the counter.
11.10. Changes from draft-ietf-hip-rfc5201-bis-09 11.11. Changes from draft-ietf-hip-rfc5201-bis-09
o Editorial changes based on working group last call. o Editorial changes based on working group last call.
11.11. Changes from draft-ietf-hip-rfc5201-bis-08 11.12. Changes from draft-ietf-hip-rfc5201-bis-08
o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to
REQUIRED status REQUIRED status
o Issue 35: limiting ECC cofactor to 1 o Issue 35: limiting ECC cofactor to 1
o Changed text regarding issue 33 reusing DH values o Changed text regarding issue 33 reusing DH values
o Fix tracker issue 32 on Domain Identifier normative text o Fix tracker issue 32 on Domain Identifier normative text
11.12. Changes from draft-ietf-hip-rfc5201-bis-07 11.13. Changes from draft-ietf-hip-rfc5201-bis-07
o Removed lingering references to SHA-1 as the mandatory hash o Removed lingering references to SHA-1 as the mandatory hash
algorithm (which was changed to SHA-256 in the -02 draft version). algorithm (which was changed to SHA-256 in the -02 draft version).
o For parameter type number changes, changed "IETF Review" to "IETF o For parameter type number changes, changed "IETF Review" to "IETF
Review or IESG Approval". Review or IESG Approval".
o Updated Appendix C checksum examples to conform to HIPv2 packets. o Updated Appendix C checksum examples to conform to HIPv2 packets.
11.13. Changes from draft-ietf-hip-rfc5201-bis-06 11.14. Changes from draft-ietf-hip-rfc5201-bis-06
o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains o Made echoing the R1_COUNTER in the I2 mandatory if the R1 contains
an R1_COUNTER. This required to make the R1 counter a critical an R1_COUNTER. This required to make the R1 counter a critical
parameter. Hence, the parameter type number of the R1_COUNTER parameter. Hence, the parameter type number of the R1_COUNTER
changed from 128 to 129. changed from 128 to 129.
o Made KDF dependent on DH Group to enable negotiation of the KDF. o Made KDF dependent on DH Group to enable negotiation of the KDF.
11.14. Changes from draft-ietf-hip-rfc5201-bis-05 11.15. Changes from draft-ietf-hip-rfc5201-bis-05
o Changed type number of DH_GROUP_LIST from 2151 to 511 because it o Changed type number of DH_GROUP_LIST from 2151 to 511 because it
was in the number space that is reserved for the HIP transport was in the number space that is reserved for the HIP transport
mode negotiations. mode negotiations.
o Added transport form type list parameter. Transport forms are now o Added transport form type list parameter. Transport forms are now
negotiated with this list instead of by their order in the HIP negotiated with this list instead of by their order in the HIP
packet. This allows to remove the exception of the transport packet. This allows to remove the exception of the transport
format parameters that were ordered by their preference instead of format parameters that were ordered by their preference instead of
by their type number. This should remove complexity from by their type number. This should remove complexity from
skipping to change at page 115, line 16 skipping to change at page 116, line 26
o Permit using Anonymous HI control in packets other than R1/I2. o Permit using Anonymous HI control in packets other than R1/I2.
o Fixed minor reference error (RFC2418, RFC2410). o Fixed minor reference error (RFC2418, RFC2410).
o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable
via the UI. via the UI.
o Editorial changes. o Editorial changes.
11.15. Changes from draft-ietf-hip-rfc5201-bis-04 11.16. Changes from draft-ietf-hip-rfc5201-bis-04
o Clarifications of the Security Considerations section. One DoS o Clarifications of the Security Considerations section. One DoS
defense mechanism was changed to be more effective and less prone defense mechanism was changed to be more effective and less prone
to misuse. to misuse.
o Minor clarifications of the state machine. o Minor clarifications of the state machine.
o Clarified text on HIP puzzle. o Clarified text on HIP puzzle.
o Added names and references for figures. o Added names and references for figures.
skipping to change at page 116, line 29 skipping to change at page 117, line 39
o Changed IETF Consensus to IETF Review or IESG Approval in IANA o Changed IETF Consensus to IETF Review or IESG Approval in IANA
section. section.
o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K
throughout the document. throughout the document.
o Updated references. o Updated references.
o Editorial changes. o Editorial changes.
11.16. Changes from draft-ietf-hip-rfc5201-bis-03 11.17. Changes from draft-ietf-hip-rfc5201-bis-03
o Editorial changes to improve clarity and readability. o Editorial changes to improve clarity and readability.
o Removed obsoleted (not applicable) attack from security o Removed obsoleted (not applicable) attack from security
consideration section. consideration section.
o Added a requirement that hosts MUST support processing of ACK o Added a requirement that hosts MUST support processing of ACK
parameters with several SEQ numbers even when they do not support parameters with several SEQ numbers even when they do not support
sending such parameters. sending such parameters.
skipping to change at page 117, line 18 skipping to change at page 118, line 26
o Clarified the use of HITs in opportunistic mode. o Clarified the use of HITs in opportunistic mode.
o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as
between SIGNATURE and SIGNATURE_2. between SIGNATURE and SIGNATURE_2.
o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to
RESPONDER_BUSY_PLEASE_RETRY. RESPONDER_BUSY_PLEASE_RETRY.
o Mentioned that there are multiple valid puzzle solutions. o Mentioned that there are multiple valid puzzle solutions.
11.17. Changes from draft-ietf-hip-rfc5201-bis-02 11.18. Changes from draft-ietf-hip-rfc5201-bis-02
o Added recommendation to not use puzzle #I twice for the same host o Added recommendation to not use puzzle #I twice for the same host
to avoid identical key material. to avoid identical key material.
o Revised state machine and added missing event handling. o Revised state machine and added missing event handling.
o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT
suites. suites.
o Revised parameter type numbers (corresponding to IANA allocations) o Revised parameter type numbers (corresponding to IANA allocations)
and added missing "free for experimentation" range to the and added missing "free for experimentation" range to the
description. description.
o Clarifying note on the use of the C bit in the parameter type o Clarifying note on the use of the C bit in the parameter type
numbers. numbers.
11.18. Changes from draft-ietf-hip-rfc5201-bis-01 11.19. Changes from draft-ietf-hip-rfc5201-bis-01
o Changed RHASH-len to RHASH_len to avoid confusion in calculations o Changed RHASH-len to RHASH_len to avoid confusion in calculations
(- could be minus) (- could be minus)
o Added RHASH_len to list of abbreviations o Added RHASH_len to list of abbreviations
o Fixed length of puzzle #I and #J to be 1*RHASH_len o Fixed length of puzzle #I and #J to be 1*RHASH_len
o Changed RHASH-len to RHASH_len to avoid confusion in calculations o Changed RHASH-len to RHASH_len to avoid confusion in calculations
(- could be minus) (- could be minus)
o Added RHASH_len to list of abbreviations o Added RHASH_len to list of abbreviations
o Fixed length of puzzle #I and #J to be 1*RHASH_len o Fixed length of puzzle #I and #J to be 1*RHASH_len
o Included HIT_SUITEs. o Included HIT_SUITEs.
o Added DH negotiation to I1 and R1. o Added DH negotiation to I1 and R1.
skipping to change at page 119, line 29 skipping to change at page 120, line 38
o Added text about new ORCHID structure to HIT overview. o Added text about new ORCHID structure to HIT overview.
o Moved Editor role to Robert Moskowitz. o Moved Editor role to Robert Moskowitz.
o Added SHA-256 to puzzle parameter. o Added SHA-256 to puzzle parameter.
o Generalized LTRUNC to be hash-function agnostic. o Generalized LTRUNC to be hash-function agnostic.
o Added text about RHASH depending on OGA. o Added text about RHASH depending on OGA.
11.19. Changes from draft-ietf-hip-rfc5201-bis-00 11.20. Changes from draft-ietf-hip-rfc5201-bis-00
o Added reasoning why BIS document is needed. o Added reasoning why BIS document is needed.
11.20. Contents of draft-ietf-hip-rfc5201-bis-00 11.21. Contents of draft-ietf-hip-rfc5201-bis-00
o RFC5201 was submitted as draft-RFC. o RFC5201 was submitted as draft-RFC.
12. References 12. References
12.1. Normative References 12.1. Normative References
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, Hash Standard", FIPS PUB 180-2, August 2002,
skipping to change at page 127, line 51 skipping to change at page 129, line 51
specific and is to be interpreted as defined below for all protocols specific and is to be interpreted as defined below for all protocols
that use the same context ID as HIP. HIP groups sets of valid that use the same context ID as HIP. HIP groups sets of valid
combinations of signature and hash algorithms into HIT Suites. These combinations of signature and hash algorithms into HIT Suites. These
HIT suites are addressed by an index, which is transmitted in the OGA HIT suites are addressed by an index, which is transmitted in the OGA
field of the ORCHID. field of the ORCHID.
The set of used HIT Suites will be extended to counter the progress The set of used HIT Suites will be extended to counter the progress
in computation capabilities and vulnerabilities in the employed in computation capabilities and vulnerabilities in the employed
algorithms. The intended use of the HIT Suites is to introduce a new algorithms. The intended use of the HIT Suites is to introduce a new
HIT Suite and phase out an old one before it becomes insecure. Since HIT Suite and phase out an old one before it becomes insecure. Since
the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID the 4-bit OGA field only permits 15 HIT Suites to be used at the same
0 is reserved) to be used in parallel, phased-out HIT Suites must be time (the HIT Suite with ID 0 is reserved), phased-out HIT Suites
reused at some point. In such a case, there will be a rollover of must be reused at some point. In such a case, there will be a
the HIT Suite ID and the next newly introduced HIT Suite will start rollover of the HIT Suite ID and the next newly introduced HIT Suite
with a lower HIT Suite index than the previously introduced one. The will start with a lower HIT Suite index than the previously
rollover effectively deprecates the reused HIT Suite. For a smooth introduced one. The rollover effectively deprecates the reused HIT
transition, the HIT Suite should be deprecated a considerable time Suite. For a smooth transition, the HIT Suite should be deprecated a
before the HIT Suite index is reused. considerable time before the HIT Suite index is reused.
Since the number of HIT Suites is tightly limited to 16, the HIT Since the number of HIT Suites is tightly limited to 16, the HIT
Suites must be assigned carefully. Hence, sets of suitable Suites must be assigned carefully. Hence, sets of suitable
algorithms are grouped in a HIT Suite. algorithms are grouped in a HIT Suite.
The HIT Suite of the Responder's HIT determines the RHASH and the The HIT Suite of the Responder's HIT determines the RHASH and the
hash function to be used for the HMAC in HIP packets as well as the hash function to be used for the HMAC in HIP packets as well as the
signature algorithm family used for generating the HI. The list of signature algorithm family used for generating the HI. The list of
HIT Suites is defined in Table 11. HIT Suites is defined in Table 10.
The following HIT Suites are defined for HIT generation. The input
for each generation algorithm is the encoding of the HI as defined in
Section 3.2. The output is 96 bits long and is directly used in the
ORCHID.
+-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+-------+----------+--------------+------------+--------------------+
| 0 | | | | Reserved |
| 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI |
| | | | | hashed with |
| | | | | SHA-256, truncated |
| | | | | to 96 bits |
| 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed |
| | | | | with SHA-384, |
| | | | | truncated to 96 |
| | | | | bits |
| 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI |
| | | | | hashed with SHA-1, |
| | | | | truncated to 96 |
| | | | | bits |
+-------+----------+--------------+------------+--------------------+
Table 11: HIT Suites
The hash of the responder as defined in the HIT Suite determines the
HMAC to be used for the HMAC parameter. The HMACs currently defined
here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC-
SHA-1 [RFC2404].
Authors' Addresses Authors' Addresses
Robert Moskowitz (editor) Robert Moskowitz (editor)
Verizon Telcom and Business Verizon Telcom and Business
1000 Bent Creek Blvd, Suite 200 1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA Mechanicsburg, PA
USA USA
EMail: robert.moskowitz@verizonbusiness.com EMail: robert.moskowitz@verizonbusiness.com
 End of changes. 44 change blocks. 
177 lines changed or deleted 199 lines changed or added

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