draft-ietf-hip-rfc5201-bis-06.txt   draft-ietf-hip-rfc5201-bis-07.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 RWTH Aachen University, Intended status: Standards Track RWTH Aachen University,
Expires: January 10, 2012 Communication and Distributed Expires: May 3, 2012 Communication and Distributed
Systems Group Systems Group
P. Jokela P. Jokela
Ericsson Research NomadicLab Ericsson Research NomadicLab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
July 9, 2011 October 31, 2011
Host Identity Protocol Version 2 (HIPv2) Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-06 draft-ietf-hip-rfc5201-bis-07
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 SIGMA- communications across IP address changes. HIP is based on a SIGMA-
compliant Diffie-Hellman key exchange, using public key identifiers compliant Diffie-Hellman key exchange, using public key identifiers
from a new Host Identity namespace for mutual peer authentication. from a new Host Identity namespace for mutual peer authentication.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
another suitable security protocol, such as the Encapsulated Security another suitable security protocol, such as the Encapsulated Security
Payload (ESP), it provides integrity protection and optional Payload (ESP), it provides integrity protection and optional
encryption for upper-layer protocols, such as TCP and UDP. encryption for upper-layer protocols, such as TCP and UDP.
This document obsoletes RFC 5201 and addresses the concerns raised by This document obsoletes RFC 5201 and addresses the concerns raised by
the IESG, particularly that of crypto agility. It also incorporates the IESG, particularly that of crypto agility. It also incorporates
lessons learned from the implementations of RFC 5201. lessons learned from the implementations of RFC 5201.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on May 3, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 8 skipping to change at page 2, line 50
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 8
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 10
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 11
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 13
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 15
4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15 4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 15
4.1.3. Authenticated Diffie-Hellman Protocol with DH 4.1.3. Authenticated Diffie-Hellman Protocol with DH
Group Negotiation . . . . . . . . . . . . . . . . . . 17 Group Negotiation . . . . . . . . . . . . . . . . . . 17
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18 4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 18
4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19 4.1.5. Refusing a HIP Base Exchange . . . . . . . . . . . . 19
4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20 4.1.6. Aborting a HIP Base Exchange . . . . . . . . . . . . 20
4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20 4.1.7. HIP Downgrade Protection . . . . . . . . . . . . . . 20
4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21 4.1.8. HIP Opportunistic Mode . . . . . . . . . . . . . . . 21
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24 4.2. Updating a HIP Association . . . . . . . . . . . . . . . 24
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 24 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 25
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 25 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 26
4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26 4.4.1. State Machine Terminology . . . . . . . . . . . . . . 26
4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27 4.4.2. HIP States . . . . . . . . . . . . . . . . . . . . . 27
4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27 4.4.3. HIP State Processes . . . . . . . . . . . . . . . . . 27
4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 34 4.4.4. Simplified HIP State Diagram . . . . . . . . . . . . 35
4.5. User Data Considerations . . . . . . . . . . . . . . . . 36 4.5. User Data Considerations . . . . . . . . . . . . . . . . 37
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 36 4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 37
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 36 4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 37
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 36 4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 37
4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 36 4.5.4. Reboot, Timeout, and Restart of HIP . . . . . . . . . 37
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 37 4.6. Certificate Distribution . . . . . . . . . . . . . . . . 38
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 37 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 37 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 38
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 38 5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 39 5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 40
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 39 5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 40
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 40 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 41
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 44
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 45 5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 46
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 46 5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 47
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 48 5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 49
5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 49 5.2.6. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 50
5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 50 5.2.7. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 51
5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 51 5.2.8. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 52
5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 52 5.2.9. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 54 5.2.10. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 55
5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 55 5.2.11. TRANSPORT_FORMAT_LIST . . . . . . . . . . . . . . . . 56
5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.12. HIP_MAC . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 56 5.2.13. HIP_MAC_2 . . . . . . . . . . . . . . . . . . . . . . 57
5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 57 5.2.14. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 58
5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 58 5.2.15. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 59
5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.16. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.17. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 60 5.2.18. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 61
5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 61 5.2.19. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 62
5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 65 5.2.20. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 66
5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 65 5.2.21. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 66
5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 66 5.2.22. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 67
5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 67 5.2.23. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 68
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 67 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 68 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 69
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 69 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 70
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 72 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 73
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 73 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 74
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 73 5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 74
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 75 5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 76
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 75 5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 76
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 76 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 77
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 76 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 77
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 76 5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 77
5.4.2. Other Problems with the HIP Header and Packet 5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 76 Structure . . . . . . . . . . . . . . . . . . . . . . 77
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 77 5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 78
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 77 5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 78
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 77 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 78
6.1. Processing Outgoing Application Data . . . . . . . . . . 78 6.1. Processing Outgoing Application Data . . . . . . . . . . 79
6.2. Processing Incoming Application Data . . . . . . . . . . 79 6.2. Processing Incoming Application Data . . . . . . . . . . 80
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 80 6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 81
6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 81 6.4. HIP_MAC and SIGNATURE Calculation and Verification . . . 82
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 81 6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 82
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 84 6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 85
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 86 6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 87
6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 87 6.6. Initiation of a HIP Base Exchange . . . . . . . . . . . . 88
6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 88 6.6.1. Sending Multiple I1 Packets in Parallel . . . . . . . 89
6.6.2. Processing Incoming ICMP Protocol Unreachable 6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 88 Messages . . . . . . . . . . . . . . . . . . . . . . 89
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 89 6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 90
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 90 6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 91
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 90 6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 92
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 91 6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 92
6.8.1. Handling of Malformed Messages . . . . . . . . . . . 93 6.8.1. Handling of Malformed Messages . . . . . . . . . . . 94
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 93 6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 95
6.9.1. Handling of Malformed Messages . . . . . . . . . . . 96 6.9.1. Handling of Malformed Messages . . . . . . . . . . . 97
6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 96 6.10. Processing of Incoming R2 Packets . . . . . . . . . . . . 97
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 97 6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 98
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 98 6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 99
6.12.1. Handling a SEQ Parameter in a Received UPDATE 6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 99 Message . . . . . . . . . . . . . . . . . . . . . . . 100
6.12.2. Handling an ACK Parameter in a Received UPDATE 6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 100 Packet . . . . . . . . . . . . . . . . . . . . . . . 101
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 101
6.13. Processing of NOTIFY Packets . . . . . . . . . . . . . . 100 6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 101
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 100 6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 102
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 101 6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 102
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 101 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 102
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 103
8. Security Considerations . . . . . . . . . . . . . . . . . . . 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 108
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 107 11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 109
11. Changes from RFC 5201 . . . . . . . . . . . . . . . . . . . . 108 11.1. Changes from draft-ietf-hip-rfc5201-bis-06 . . . . . . . 109
11.1. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 108 11.2. Changes from draft-ietf-hip-rfc5201-bis-05 . . . . . . . 109
11.2. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 109 11.3. Changes from draft-ietf-hip-rfc5201-bis-04 . . . . . . . 110
11.3. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 110 11.4. Changes from draft-ietf-hip-rfc5201-bis-03 . . . . . . . 111
11.4. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 111 11.5. Changes from draft-ietf-hip-rfc5201-bis-02 . . . . . . . 112
11.5. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 111 11.6. Changes from draft-ietf-hip-rfc5201-bis-01 . . . . . . . 112
11.6. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 113 11.7. Changes from draft-ietf-hip-rfc5201-bis-00 . . . . . . . 114
11.7. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 113 11.8. Contents of draft-ietf-hip-rfc5201-bis-00 . . . . . . . . 114
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
12.1. Normative References . . . . . . . . . . . . . . . . . . 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 114
12.2. Informative References . . . . . . . . . . . . . . . . . 116 12.2. Informative References . . . . . . . . . . . . . . . . . 117
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 118 Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 119
Appendix B. Generating a Public Key Encoding from an HI . . . . 119 Appendix B. Generating a Public Key Encoding from an HI . . . . 120
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 119 Appendix C. Example Checksums for HIP Packets . . . . . . . . . 121
C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 120 C.1. IPv6 HIP Example (I1 packet) . . . . . . . . . . . . . . 121
C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 120 C.2. IPv4 HIP Packet (I1 packet) . . . . . . . . . . . . . . . 121
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 120 C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 121
Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 121 Appendix D. ECDH and ECDSA 160 Bit Groups . . . . . . . . . . . 122
Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 121 Appendix E. HIT Suites and HIT Generation . . . . . . . . . . . 122
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 10, line 12 skipping to change at page 10, line 12
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. Appendix E).
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
symmetric keys from the Diffie-Hellman key exchange.
KEYMAT: The keying material derived from the Diffie-Hellman key KEYMAT: The keying material derived from the Diffie-Hellman key
exchange. Symmetric keys for encryption and integrity protection exchange by using the KDF. Symmetric keys for encryption and
of HIP control and payload packets are drawn from this keying integrity protection of HIP control and payload packets are drawn
material. from this keying material.
3. Host Identity (HI) and its Structure 3. Host Identity (HI) and its Structure
In this section, the properties of the Host Identity and Host In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is defined. Identity Tag are discussed, and the exact format for them is defined.
In HIP, the public key of an asymmetric key pair is used as the Host In HIP, the public key of an asymmetric key pair is used as the Host
Identity (HI). Correspondingly, the host itself is defined as the Identity (HI). Correspondingly, the host itself is defined as the
entity that holds the private key of the key pair. See the HIP entity that holds the private key of the key pair. See the HIP
architecture specification [I-D.ietf-hip-rfc4423-bis] for more architecture specification [I-D.ietf-hip-rfc4423-bis] for more
details on the difference between an identity and the corresponding details on the difference between an identity and the corresponding
skipping to change at page 13, line 30 skipping to change at page 13, line 33
party can become the Initiator in future communications. party can become the Initiator in future communications.
The HIP base exchange serves to manage the establishment of state The HIP base exchange serves to manage the establishment of state
between an Initiator and a Responder. The first packet, I1, between an Initiator and a Responder. The first packet, I1,
initiates the exchange, and the last three packets, R1, I2, and R2, initiates the exchange, and the last three packets, R1, I2, and R2,
constitute an authenticated Diffie-Hellman [DIF76] key exchange for constitute an authenticated Diffie-Hellman [DIF76] key exchange for
session-key generation. In the first two packets, the hosts agree on session-key generation. In the first two packets, the hosts agree on
a set of cryptographic identifiers and algorithms that are then used a set of cryptographic identifiers and algorithms that are then used
in and after the exchange. During the Diffie-Hellman key exchange, a in and after the exchange. During the Diffie-Hellman key exchange, a
piece of keying material is generated. The HIP association keys are piece of keying material is generated. The HIP association keys are
drawn from this keying material. If other cryptographic keys are drawn from this keying material by using a Key Derivation Function
needed, e.g., to be used with ESP, they are expected to be drawn from (KDF). If other cryptographic keys are needed, e.g., to be used with
the same keying material. ESP, they are expected to be drawn from the same keying material by
using the KDF.
The Initiator first sends a trigger packet, I1, to the Responder. The Initiator first sends a trigger packet, I1, to the Responder.
The packet contains the HIT of the Initiator and possibly the HIT of The packet contains the HIT of the Initiator and possibly the HIT of
the Responder, if it is known. Moreover, the I1 packet initializes the Responder, if it is known. Moreover, the I1 packet initializes
the negotiation of the Diffie-Hellman group that is used for the negotiation of the Diffie-Hellman group that is used for
generating the keying material. Therefore, the I1 packet contains a generating the keying material. Therefore, the I1 packet contains a
list of Diffie Hellman Group IDs supported by the Initiator. Note list of Diffie Hellman Group IDs supported by the Initiator. Note
that in some cases it may be possible to replace this trigger packet that in some cases it may be possible to replace this trigger packet
by some other form of a trigger, in which case the protocol starts by some other form of a trigger, in which case the protocol starts
with the Responder sending the R1 packet. In such cases, another with the Responder sending the R1 packet. In such cases, another
skipping to change at page 28, line 4 skipping to change at page 28, line 25
| Receive I2, process | If successful, send R2 and go to R2-SENT | | Receive I2, process | If successful, send R2 and go to R2-SENT |
| | | | | |
| | If fail, stay at UNASSOCIATED | | | If fail, stay at UNASSOCIATED |
| | | | | |
| Receive user data | Optionally send ICMP as defined in | | Receive user data | Optionally send ICMP as defined in |
| for an unknown HIP | Section 5.4 and stay at UNASSOCIATED | | for an unknown HIP | Section 5.4 and stay at UNASSOCIATED |
| association | | | association | |
| | | | | |
| Receive CLOSE | Optionally send ICMP Parameter Problem and | | Receive CLOSE | Optionally send ICMP Parameter Problem and |
| | stay at UNASSOCIATED | | | stay at UNASSOCIATED |
| | |
| Receive ANYOTHER | Drop and stay at UNASSOCIATED | | Receive ANYOTHER | Drop and stay at UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 2: UNASSOCIATED - Start state Table 2: UNASSOCIATED - Start state
System behavior in state I1-SENT, Table 3. System behavior in state I1-SENT, Table 3.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
skipping to change at page 32, line 38 skipping to change at page 33, line 38
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive CLOSE_ACK, | If successful, discard state and go to | | Receive CLOSE_ACK, | If successful, discard state and go to |
| process | UNASSOCIATED | | process | UNASSOCIATED |
| | | | | |
| | If fail, stay at CLOSING | | | If fail, stay at CLOSING |
| | | | | |
| Receive ANYOTHER | Drop and stay at CLOSING | | Receive ANYOTHER | Drop and stay at CLOSING |
| | | | | |
| Timeout | Increment timeout sum and reset timer. If | | Timeout | Increment timeout sum and reset timer. If |
| | timeout sum is less than UAL+MSL minutes, | | | timeout sum is less than UAL+MSL minutes, |
| | retransmit CLOSE and stay at CLOSING | | | retransmit CLOSE and stay at CLOSING |
| | | | | |
| | If timeout sum is greater than UAL+MSL | | | If timeout sum is greater than UAL+MSL |
| | minutes, go to UNASSOCIATED | | | minutes, go to UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 7: CLOSING - HIP association has not been used for UAL minutes Table 7: CLOSING - HIP association has not been used for UAL minutes
System behavior in state CLOSED, Table 8. System behavior in state CLOSED, Table 8.
skipping to change at page 33, line 47 skipping to change at page 34, line 47
| Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED | | Timeout (UAL+2MSL) | Discard state, and go to UNASSOCIATED |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary Table 8: CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary
System behavior in state E-FAILED, Table 9. System behavior in state E-FAILED, Table 9.
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Trigger | Action | | Trigger | Action |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Wait for | Go to UNASSOCIATED. Re-negotiation is | | Wait for | Go to UNASSOCIATED. Re-negotiation is |
| implementation-specific | possible after moving to UNASSOCIATED | | implementation-specific | possible after moving to UNASSOCIATED |
| time | state. | | time | state. |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
Table 9: E-FAILED - HIP failed to establish association with peer Table 9: E-FAILED - HIP failed to establish association with peer
4.4.4. Simplified HIP State Diagram 4.4.4. Simplified HIP State Diagram
The following diagram (Figure 2) shows the major state transitions. The following diagram (Figure 2) shows the major state transitions.
Transitions based on received packets implicitly assume that the Transitions based on received packets implicitly assume that the
packets are successfully authenticated or processed. packets are successfully authenticated or processed.
skipping to change at page 41, line 8 skipping to change at page 42, line 8
behavior. behavior.
In HIP packets, HIP parameters are ordered according to their numeric In HIP packets, HIP parameters are ordered according to their numeric
type number and encoded in TLV format. type number and encoded in TLV format.
The following parameter types are currently defined. The following parameter types are currently defined.
+------------------------+-------+-----------+----------------------+ +------------------------+-------+-----------+----------------------+
| TLV | Type | Length | Data | | TLV | Type | Length | Data |
+------------------------+-------+-----------+----------------------+ +------------------------+-------+-----------+----------------------+
| R1_COUNTER | 128 | 12 | Puzzle generation | | R1_COUNTER | 129 | 12 | Puzzle generation |
| | | | counter | | | | | counter |
| | | | | | | | | |
| PUZZLE | 257 | 12 | K and Random #I | | PUZZLE | 257 | 12 | K and Random #I |
| | | | | | | | | |
| SOLUTION | 321 | 20 | K, Random #I and | | SOLUTION | 321 | 20 | K, Random #I and |
| | | | puzzle solution J | | | | | puzzle solution J |
| | | | | | | | | |
| SEQ | 385 | 4 | UPDATE packet ID | | SEQ | 385 | 4 | UPDATE packet ID |
| | | | number | | | | | number |
| | | | | | | | | |
skipping to change at page 42, line 27 skipping to change at page 43, line 27
| | | numbers | | | | | numbers | |
| | | | | | | | | |
| HIP_MAC | 61505 | variable | HMAC-based message | | HIP_MAC | 61505 | variable | HMAC-based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT | | | | | from KEYMAT |
| | | | | | | | | |
| HIP_MAC_2 | 61569 | variable | HMAC based message | | HIP_MAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, | | | | | authentication code, |
| | | | with key material | | | | | with key material |
| | | | from KEYMAT. Unlike | | | | | from KEYMAT. Unlike |
| | | | HIP_MAC, the HOST_ID | | | | | HIP_MAC, the HOST_ID |
| | | | parameter is | | | | | parameter is |
| | | | included in | | | | | included in |
| | | | HIP_MAC_2 | | | | | HIP_MAC_2 |
| | | | calculation. | | | | | calculation. |
| | | | | | | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
| | | | packet | | | | | packet |
| | | | | | | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the | | HIP_SIGNATURE | 61697 | variable | Signature of the |
skipping to change at page 43, line 22 skipping to change at page 44, line 22
| | | | | |
| 1024 - 2047 | Reserved | | 1024 - 2047 | Reserved |
| | | | | |
| 2048 - 4095 | Parameters related to HIP transport formats | | 2048 - 4095 | Parameters related to HIP transport formats |
| | | | | |
| 4096 - 8191 | Signed parameters allocated through specification | | 4096 - 8191 | Signed parameters allocated through specification |
| | documents | | | documents |
| | | | | |
| 8192 - 32767 | Reserved | | 8192 - 32767 | Reserved |
| | | | | |
| 32768 - 49151 | Free for experimentation. Signed parameters. | | 32768 - 49151 | Free for experimentation. Signed parameters. |
| | | | | |
| 41952 - 61439 | Reserved | | 41952 - 61439 | Reserved |
| | | | | |
| 61440 - 64443 | Signatures and (signed) MACs | | 61440 - 64443 | Signatures and (signed) MACs |
| | | | | |
| 62464 - 63487 | Parameters that are neither signed nor MACed | | 62464 - 63487 | Parameters that are neither signed nor MACed |
| | | | | |
| 63488 - 64511 | Rendezvous and relaying | | 63488 - 64511 | Rendezvous and relaying |
| | | | | |
| 64512 - 65023 | Parameters that are neither signed nor MACed | | 64512 - 65023 | Parameters that are neither signed nor MACed |
skipping to change at page 46, line 18 skipping to change at page 47, line 18
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, 4 bytes | | Reserved, 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R1 generation counter, 8 bytes | | R1 generation counter, 8 bytes |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 128 Type 129
Length 12 Length 12
R1 generation R1 generation
counter The current generation of valid puzzles counter The current generation of valid puzzles
The R1_COUNTER parameter contains a 64-bit unsigned integer in The R1_COUNTER parameter contains a 64-bit unsigned integer in
network-byte order, indicating the current generation of valid network-byte order, indicating the current generation of valid
puzzles. The sender SHOULD increment this counter periodically. It puzzles. The sender SHOULD increment this counter periodically. It
is RECOMMENDED that the counter value is incremented at least as is RECOMMENDED that the counter value is incremented at least as
often as old PUZZLE values are deprecated so that SOLUTIONs to them often as old PUZZLE values are deprecated so that SOLUTIONs to them
are no longer accepted. are no longer accepted.
The R1_COUNTER parameter is optional. It SHOULD be included in the Support for the R1_COUNTER parameter is mandatory. It SHOULD be
R1 (in which case, it is covered by the signature), and if present in included in the R1 (in which case, it is covered by the signature),
the R1, it MAY be echoed (including the Reserved field verbatim) by and if present in the R1, it MUST be echoed (including the Reserved
the Initiator in the I2 packet. field verbatim) by the Initiator in the I2 packet.
5.2.4. PUZZLE 5.2.4. PUZZLE
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Lifetime | Opaque, 2 bytes | | #K, 1 byte | Lifetime | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 50, line 22 skipping to change at page 51, line 22
| Group ID | Public Value Length | Public Value / | Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 513 Type 513
Length length in octets, excluding Type, Length, and Length length in octets, excluding Type, Length, and
Padding Padding
Group ID defines values for p and g Group ID defines values for p and g as well as the KDF
Public Value length of the following Public Value in octets Public Value length of the following Public Value in octets
Length Length
Public Value the sender's public Diffie-Hellman key Public Value the sender's public Diffie-Hellman key
The following Group IDs have been defined: The following Group IDs have been defined:
Group Value Group KDF Value
Reserved 0 Reserved 0
DEPRECATED 1 DEPRECATED 1
DEPRECATED 2 DEPRECATED 2
1536-bit MODP group 3 [RFC3526] 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3
3072-bit MODP group 4 [RFC3526] 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4
DEPRECATED 5 DEPRECATED 5
DEPRECATED 6 DEPRECATED 6
NIST P-256 7 [RFC5903] NIST P-256 [RFC5903] HKDF [RFC5869] 7
NIST P-384 8 [RFC5903] NIST P-384 [RFC5903] HKDF [RFC5869] 8
NIST P-521 9 [RFC5903] NIST P-521 [RFC5903] HKDF [RFC5869] 9
SECP160R1 10 [SECG] SECP160R1 [SECG] HKDF [RFC5869] 10
The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH
groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7 groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7
is covered in Appendix D. is covered in Appendix D.
The Group ID also defines the key derivation function that is to be
used for deriving the symmstric keys for the HMAC and symmetric
encryption from the keying material from the Diffie Hellman key
exchange (see Section 6.5).
A HIP implementation MUST implement Group ID 3. The 160-bit A HIP implementation MUST implement Group ID 3. The 160-bit
SECP160R1 group can be used when lower security is enough (e.g., web SECP160R1 group can be used when lower security is enough (e.g., web
surfing) and when the equipment is not powerful enough (e.g., some surfing) and when the equipment is not powerful enough (e.g., some
PDAs). Implementations SHOULD implement Group IDs 4 and 8. PDAs). Implementations SHOULD implement Group IDs 4 and 8.
To avoid unnecessary failures during the base exchange, the rest of To avoid unnecessary failures during the base exchange, the rest of
the groups SHOULD be implemented in hosts where resources are the groups SHOULD be implemented in hosts where resources are
adequate. adequate.
5.2.8. HIP_CIPHER 5.2.8. HIP_CIPHER
skipping to change at page 72, line 33 skipping to change at page 73, line 33
HIP_MAC, HIP_MAC,
HIP_SIGNATURE HIP_SIGNATURE
<, ECHO_RESPONSE_UNSIGNED>i ) ) <, ECHO_RESPONSE_UNSIGNED>i ) )
Valid control bits: A Valid control bits: A
The HITs used MUST match the ones used in the R1. The HITs used MUST match the ones used in the R1.
If the Initiator's HI is an anonymous one, the A control MUST be set. If the Initiator's HI is an anonymous one, the A control MUST be set.
The Initiator MAY include an unmodified copy of the R1_COUNTER If present in the I1 packet, the Initiator MUST include an unmodified
parameter received in the corresponding R1 packet into the I2 packet. copy of the R1_COUNTER parameter received in the corresponding R1
packet into the I2 packet.
The Solution contains the Random #I from R1 and the computed #J. The The Solution contains the Random #I from R1 and the computed #J. The
low-order #K bits of the RHASH(I | ... | J) MUST be zero. low-order #K bits of the RHASH(I | ... | J) MUST be zero.
The Diffie-Hellman value is ephemeral. If precomputed, a scavenger The Diffie-Hellman value is ephemeral. If precomputed, a scavenger
process should clean up unused Diffie-Hellman values. The Responder process should clean up unused Diffie-Hellman values. The Responder
MAY re-use Diffie-Hellman values under some conditions as specified MAY re-use Diffie-Hellman values under some conditions as specified
in Section 5.3.2. in Section 5.3.2.
The HIP_CIPHER contains the single encryption transform selected by The HIP_CIPHER contains the single encryption transform selected by
skipping to change at page 86, line 13 skipping to change at page 87, line 13
packet or one received by some other means. packet or one received by some other means.
6.5. HIP KEYMAT Generation 6.5. HIP KEYMAT Generation
HIP keying material is derived from the Diffie-Hellman session key, HIP keying material is derived from the Diffie-Hellman session key,
Kij, produced during the HIP base exchange (see Section 4.1.3). The Kij, produced during the HIP base exchange (see Section 4.1.3). The
Initiator has Kij during the creation of the I2 packet, and the Initiator has Kij during the creation of the I2 packet, and the
Responder has Kij once it receives the I2 packet. This is why I2 can Responder has Kij once it receives the I2 packet. This is why I2 can
already contain encrypted information. already contain encrypted information.
The KEYMAT is derived by feeding Kij into a Hash-based Key Derivation The KEYMAT is derived by feeding Kij into the key derivation function
Function (HKDF) [RFC5869] using the RHASH hash function. defined by the DH Group ID. Currently the only key derivation
function defied in this document is the Hash-based Key Derivation
Function (HKDF) [RFC5869] using the RHASH hash function. Other
documents may define new DH Group IDs and corresponding key
distribution functions.
In the following we provide the details for deriving the keying
material using HKDF.
where where
info = sort(HIT-I | HIT-R) info = sort(HIT-I | HIT-R)
salt = #I | #J salt = #I | #J
Sort(HIT-I | HIT-R) is defined as the network byte order Sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte interpreted as positive (unsigned) 128-bit integers in network byte
skipping to change at page 108, line 18 skipping to change at page 109, line 18
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-05 11.1. Changes from draft-ietf-hip-rfc5201-bis-06
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
parameter. Hence, the parameter type number of the R1_COUNTER
changed from 128 to 129.
o Made KDF dependent on DH Group to enable negotiation of the KDF.
11.2. 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 109, line 5 skipping to change at page 110, line 14
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.2. Changes from draft-ietf-hip-rfc5201-bis-04 11.3. 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 110, line 20 skipping to change at page 111, line 29
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.3. Changes from draft-ietf-hip-rfc5201-bis-03 11.4. 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 111, line 7 skipping to change at page 112, line 18
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.4. Changes from draft-ietf-hip-rfc5201-bis-02 11.5. 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.5. Changes from draft-ietf-hip-rfc5201-bis-01 11.6. 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)
skipping to change at page 113, line 19 skipping to change at page 114, line 29
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.6. Changes from draft-ietf-hip-rfc5201-bis-00 11.7. 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.7. Contents of draft-ietf-hip-rfc5201-bis-00 11.8. 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] National Institute of Standards and [FIPS.180-2.2002] National Institute of Standards and
Technology, "Secure Hash Standard", Technology, "Secure Hash Standard",
FIPS PUB 180-2, August 2002, <http:// FIPS PUB 180-2, August 2002, <http://
 End of changes. 37 change blocks. 
159 lines changed or deleted 180 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/