RFC 7401
Host Identity Protocol Version 2 (HIPv2)
Pages: 128
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Part 5 of 5 – Pages 106 to 128
7. HIP Policies
There are a number of variables that will influence the HIP base exchanges that each host must support. All HIP implementations MUST support more than one simultaneous HI, at least one of which SHOULD be reserved for anonymous usage. Although anonymous HIs will be rarely used as Responders' HIs, they will be common for Initiators. Support for more than two HIs is RECOMMENDED. Initiators MAY use a different HI for different Responders to provide basic privacy. Whether such private HIs are used repeatedly with the same Responder, and how long these HIs are used, are decided by local policy and depend on the privacy requirements of the Initiator. The value of #K used in the HIP R1 must be chosen with care. Values of #K that are too high will exclude clients with weak CPUs because these devices cannot solve the puzzle within a reasonable amount of time. #K should only be raised if a Responder is under high load, i.e., it cannot process all incoming HIP handshakes any more. If a Responder is not under high load, #K SHOULD be 0. Responders that only respond to selected Initiators require an Access Control List (ACL), representing for which hosts they accept HIP base exchanges, and the preferred transport format and local lifetimes. Wildcarding SHOULD be supported for such ACLs, and also for Responders that offer public or anonymous services.8. Security Considerations
HIP is designed to provide secure authentication of hosts. HIP also attempts to limit the exposure of the host to various denial-of- service and man-in-the-middle (MitM) attacks. In doing so, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual. Denial-of-service attacks often take advantage of asymmetries in the cost of starting an association. One example of such asymmetry is the need of a Responder to store local state while a malicious Initiator can stay stateless. HIP makes no attempt to increase the cost of the start of state at the Initiator, but makes an effort to reduce the cost for the Responder. This is accomplished by having the Responder start the 3-way exchange instead of the Initiator, making the HIP exchange 4 packets long. In doing this, the first packet from the Responder, R1, becomes a 'stock' packet that the Responder MAY use many times, until some Initiator has provided a valid response to such an R1 packet. During an I1 packet storm, the host may reuse the same DH value also, even if some Initiator has
provided a valid response using that particular DH value. However, such behavior is discouraged and should be avoided. Using the same Diffie-Hellman values and random puzzle #I value has some risks. This risk needs to be balanced against a potential storm of HIP I1 packets. This shifting of the start of state cost to the Initiator in creating the I2 HIP packet presents another DoS attack. The attacker can spoof the I1 packet, and the Responder sends out the R1 HIP packet. This could conceivably tie up the 'Initiator' with evaluating the R1 HIP packet, and creating the I2 packet. The defense against this attack is to simply ignore any R1 packet where a corresponding I1 packet was not sent (as defined in Section 6.8, step 1). The R1 packet is considerably larger than the I1 packet. This asymmetry can be exploited in a reflection attack. A malicious attacker could spoof the IP address of a victim and send a flood of I1 messages to a powerful Responder. For each small I1 packet, the Responder would send a larger R1 packet to the victim. The difference in packet sizes can further amplify a flooding attack against the victim. To avoid such reflection attacks, the Responder SHOULD rate-limit the sending of R1 packets in general or SHOULD rate-limit the sending of R1 packets to a specific IP address. Floods of forged I2 packets form a second kind of DoS attack. Once the attacking Initiator has solved the puzzle, it can send packets with spoofed IP source addresses with either an invalid HIP signature or invalid encrypted HIP payload (in the ENCRYPTED parameter). This would take resources in the Responder's part to reach the point to discover that the I2 packet cannot be completely processed. The defense against this attack is that after N bad I2 packets with the same puzzle solution, the Responder would discard any I2 packets that contain the given solution. This will shut down the attack. The attacker would have to request another R1 packet and use that to launch a new attack. The Responder could increase the value of #K while under attack. Keeping a list of solutions from malformed packets requires that the Responder keeps state for these malformed I2 packets. This state has to be kept until the R1 counter is increased. As malformed packets are generally filtered by their checksum before signature verification, only solutions in packets that are forged to pass the checksum and puzzle are put into the blacklist. In addition, a valid puzzle is required before a new list entry is created. Hence, attackers that intend to flood the blacklist must solve puzzles first.
A third form of DoS attack is emulating the restart of state after a reboot of one of the peers. A restarting host would send an I1 packet to the peers, which would respond with an R1 packet even if it were in the ESTABLISHED state. If the I1 packet were spoofed, the resulting R1 packet would be received unexpectedly by the spoofed host and would be dropped, as in the first case above. A fourth form of DoS attack is emulating the closing of the HIP association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to explicitly signal the end of a HIP association. Because both CLOSE and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a connection. The presence of an additional SIGNATURE allows middleboxes to inspect these messages and discard the associated state (e.g., for firewalling, SPI-based NATing, etc.). However, the optional behavior of replying to CLOSE with an ICMP Parameter Problem packet (as described in Section 5.4.4) might allow an attacker spoofing the source IP address to send CLOSE messages to launch reflection attacks. A fifth form of DoS attack is replaying R1s to cause the Initiator to solve stale puzzles and become out of synchronization with the Responder. The R1 generation counter is a monotonically increasing counter designed to protect against this attack, as described in Section 4.1.4. Man-in-the-middle attacks are difficult to defend against, without third-party authentication. A skillful MitM could easily handle all parts of HIP, but HIP indirectly provides the following protection from a MitM attack. If the Responder's HI is retrieved from a signed DNS zone, a certificate, or through some other secure means, the Initiator can use this to validate the R1 HIP packet. Likewise, if the Initiator's HI is in a secure DNS zone, a trusted certificate, or otherwise securely available, the Responder can retrieve the HI (after having got the I2 HIP packet) and verify that the HI indeed can be trusted. The HIP "opportunistic mode" concept has been introduced in this document, but this document does not specify what the semantics of such a connection setup are for applications. There are certain concerns with opportunistic mode, as discussed in Section 4.1.8. NOTIFY messages are used only for informational purposes, and they are unacknowledged. A HIP implementation cannot rely solely on the information received in a NOTIFY message because the packet may have been replayed. An implementation SHOULD NOT change any state information purely based on a received NOTIFY message.
Since not all hosts will ever support HIP, ICMP 'Destination Protocol Unreachable' messages are to be expected and may be used for a DoS attack. Against an Initiator, the attack would look like the Responder does not support HIP, but shortly after receiving the ICMP message, the Initiator would receive a valid R1 HIP packet. Thus, to protect against this attack, an Initiator SHOULD NOT react to an ICMP message until a reasonable delta time to get the real Responder's R1 HIP packet. A similar attack against the Responder is more involved. Normally, if an I1 message received by a Responder was a bogus one sent by an attacker, the Responder may receive an ICMP message from the IP address the R1 message was sent to. However, a sophisticated attacker can try to take advantage of such behavior and try to break up the HIP base exchange by sending such an ICMP message to the Responder before the Initiator has a chance to send a valid I2 message. Hence, the Responder SHOULD NOT act on such an ICMP message. Especially, it SHOULD NOT remove any minimal state created when it sent the R1 HIP packet (if it did create one), but wait for either a valid I2 HIP packet or the natural timeout (that is, if R1 packets are tracked at all). Likewise, the Initiator SHOULD ignore any ICMP message while waiting for an R2 HIP packet, and SHOULD delete any pending state only after a natural timeout.9. IANA Considerations
IANA has reserved protocol number 139 for the Host Identity Protocol and included it in the "IPv6 Extension Header Types" registry [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The reference in both of these registries has been updated from [RFC5201] to this specification. The reference to the 128-bit value under the CGA Message Type namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" has been changed from [RFC5201] to this specification. The following changes to the "Host Identity Protocol (HIP) Parameters" have been made. In many cases, the changes involved updating the reference from [RFC5201] to this specification, but there are some differences as outlined below. Allocation terminology is defined in [RFC5226]; any existing references to "IETF Consensus" can be replaced with "IETF Review" as per [RFC5226].
HIP Version
This document adds the value "2" to the existing registry. The
value of "1" has been left with a reference to [RFC5201].
Packet Type
The 7-bit Packet Type field in a HIP protocol packet describes the
type of a HIP protocol message. It is defined in Section 5.1.
All existing values referring to [RFC5201] have been updated to
refer to this specification. Other values have been left
unchanged.
HIT Suite ID
This specification creates a new registry for "HIT Suite ID".
This is different than the existing registry for "Suite ID", which
can be left unmodified for version 1 of the protocol ([RFC5201]).
The registry has been closed to new registrations.
The four-bit HIT Suite ID uses the OGA ID field in the ORCHID to
express the type of the HIT. This document defines three HIT
Suites (see Section 5.2.10).
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-order bits are reserved for future extensions of the HIT
Suite ID space beyond 16 values.
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
HIT Suite ID reduces the cryptographic strength of the HIT. HIT
Suite IDs must be allocated carefully to avoid namespace
exhaustion. Moreover, deprecated IDs should be reused after an
appropriate time span. If 15 Suite IDs (the zero value is
initially reserved) prove to be insufficient and more HIT Suite
IDs are needed concurrently, more bits can be used for the HIT
Suite ID by using one HIT Suite ID (0) to indicate that more bits
should be used. The HIT_SUITE_LIST parameter already supports
8-bit HIT Suite IDs, should longer IDs be needed. However,
RFC 7343 [RFC7343] does not presently support such an extension.
We suggest trying the rollover approach described in Appendix E
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
value is being reused after a deprecation period, to ensure
appropriate IETF review and approval.
Parameter Type
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
are defined in Sections 5.2.3 through 5.2.23. The existing
"Parameter Types" registry has been updated as follows.
A new value (129) for R1_COUNTER has been introduced, with a
reference to this specification, and the existing value (128) for
R1_COUNTER has been left in place with a reference to [RFC5201].
This documents the change in value that has occurred in version 2
of this protocol. For clarity, the name for the value 128 has
been changed from "R1_COUNTER" to "R1_Counter (v1 only)".
A new value (579) for a new Parameter Type HIP_CIPHER has been
added, with reference to this specification. This Parameter Type
functionally replaces the HIP_TRANSFORM Parameter Type
(value 577), which has been left in the table with the existing
reference to [RFC5201]. For clarity, the name for the
value 577 has been changed from "HIP_TRANSFORM" to
"HIP_TRANSFORM (v1 only)".
A new value (715) for a new Parameter Type HIT_SUITE_LIST has been
added, with reference to this specification.
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
has been added, with reference to this specification.
The name of the HMAC Parameter Type (value 61505) has been changed
to HIP_MAC. The name of the HMAC_2 Parameter Type (value 61569)
has been changed to HIP_MAC_2. The reference has been changed to
this specification.
All other Parameter Types that reference [RFC5201] have been
updated to refer to this specification, and Parameter Types that
reference other RFCs are unchanged.
The Type codes 32768 through 49151 (not 49141: a value corrected
from a previous version of this table) have been Reserved for
Private Use. Implementors SHOULD select types in a random fashion
from this range, thereby reducing the probability of collisions.
A method employing genuine randomness (such as flipping a coin)
SHOULD be used.
Where the existing ranges once stated "First Come First Served
with Specification Required", this has been changed to
"Specification Required".
Group ID
The eight-bit Group ID values appear in the DIFFIE_HELLMAN
parameter and the DH_GROUP_LIST parameter and are defined in
Section 5.2.7. This registry has been updated based on the new
values specified in Section 5.2.7; values noted as being
DEPRECATED can be left in the table with reference to [RFC5201].
New values are assigned through IETF Review.
HIP Cipher ID
The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined
in Section 5.2.8. This is a new registry. New values from either
the reserved or unassigned space are assigned through IETF Review.
DI-Type
The four-bit DI-Type values in a HOST_ID parameter are defined in
Section 5.2.9. New values are assigned through IETF Review. All
existing values referring to [RFC5201] have been updated to refer
to this specification.
HI Algorithm
The 16-bit Algorithm values in a HOST_ID parameter are defined in
Section 5.2.9. This is a new registry. New values from either
the reserved or unassigned space are assigned through IETF Review.
ECC Curve Label
When the HI Algorithm values in a HOST_ID parameter are defined to
the values of either "ECDSA" or "ECDSA_LOW", a new registry is
needed to maintain the values for the ECC Curve Label as defined
in Section 5.2.9. This might be handled by specifying two
algorithm-specific subregistries named "ECDSA Curve Label" and
"ECDSA_LOW Curve Label". New values are to be assigned through
IETF Review.
Notify Message Type
The 16-bit Notify Message Type values in a NOTIFICATION parameter
are defined in Section 5.2.19.
Notify Message Type values 1-10 are used for informing about
errors in packet structures, values 11-20 for informing about
problems in parameters containing cryptographic related material,
and values 21-30 for informing about problems in authentication or
packet integrity verification. Parameter numbers above 30 can be
used for informing about other types of errors or events.
The existing registration procedures have been updated as follows.
The range from 1-50 can remain as "IETF Review". The range from
51-8191 has been marked as "Specification Required". Values
8192-16383 remain as "Reserved for Private Use". Values
16384-40959 have been marked as "Specification Required". Values
40960-65535 remain as "Reserved for Private Use".
The following updates to the values have been made to the existing
registry. All existing values referring to [RFC5201] have been
updated to refer to this specification.
INVALID_HIP_TRANSFORM_CHOSEN has been renamed to
INVALID_HIP_CIPHER_CHOSEN with the same value (17).
A new value of 20 for the type UNSUPPORTED_HIT_SUITE has been
added.
HMAC_FAILED has been renamed to HIP_MAC_FAILED with the same
value (28).
SERVER_BUSY_PLEASE_RETRY has been renamed to
RESPONDER_BUSY_PLEASE_RETRY with the same value (44).
10. Differences from RFC 5201
This section summarizes the technical changes made from [RFC5201].
This section is informational, intended to help implementors of the
previous protocol version. If any text in this section contradicts
text in other portions of this specification, the text found outside
of this section should be considered normative.
This document specifies the HIP Version 2 protocol, which is not
interoperable with the HIP Version 1 protocol specified in [RFC5201].
The main technical changes are the inclusion of additional
cryptographic agility features, and an update of the mandatory and
optional algorithms, including Elliptic Curve support via the
Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) algorithms. The mandatory cryptographic algorithm implementations have been updated, such as replacing HMAC-SHA-1 with HMAC-SHA-256 and the RSA/SHA-1 signature algorithm with RSASSA-PSS, and adding ECDSA to RSA as mandatory public key types. This version of HIP is also aligned with the ORCHID revision [RFC7343]. The following changes have been made to the protocol operation. o Section 4.1.3 describes the new process for Diffie-Hellman group negotiation, an aspect of cryptographic agility. The Initiator may express a preference for the choice of a DH group in the I1 packet and may suggest multiple possible choices. The Responder replies with a preference based on local policy and the options provided by the Initiator. The Initiator may restart the base exchange if the option chosen by the Responder is unsuitable (unsupported algorithms). o Another aspect of cryptographic agility that has been added is the ability to use different cryptographic hash functions to generate the HIT. The Responder's HIT hash algorithm (RHASH) terminology was introduced to support this. In addition, HIT Suites have been introduced to group the set of cryptographic algorithms used together for public key signature, hash function, and hash truncation. The use of HIT Suites constrains the combinatorial possibilities of algorithm selection for different functions. HIT Suite IDs are related to the ORCHID OGA ID field ([RFC7343]). o The puzzle mechanism has been slightly changed, in that the #I parameter depends on the HIT hash function (RHASH) selected, and the specification now advises against reusing the same #I value to the same Initiator; more details are provided in Sections 4.1.2 and 5.2.4). o Section 4.1.4 was extended to cover details about R1 generation counter rollover or reset. o Section 4.1.6 was added to describe procedures for aborting a HIP base exchange. o Section 4.1.7 provides guidance on avoiding downgrade attacks on the cryptographic algorithms. o Section 4.1.8 on opportunistic mode has been updated to account for cryptographic agility by adding HIT selection procedures.
o The HIP KEYMAT generation has been updated as described in
Section 6.5 to make the key derivation function a negotiable
aspect of the protocol.
o Packet processing for the I1, R1, and I2 packets has been updated
to account for new parameter processing.
o This specification adds a requirement that hosts MUST support
processing of ACK parameters with several SEQ sequence numbers
even when they do not support sending such parameters.
o This document now clarifies that several ECHO_REQUEST_UNSIGNED
parameters may be present in an R1 and that several ECHO_RESPONSE
parameters may be present in an I2.
o Procedures for responding to version mismatches with an ICMP
Parameter Problem have been added.
o The security considerations section (Section 8) has been updated
to remove possible attacks no longer considered applicable.
o The use of the Anonymous bit for making the sender's Host Identity
anonymous is now supported in packets other than the R1 and I2.
o Support for the use of a NULL HIP CIPHER is explicitly limited to
debugging and testing HIP and is no longer a mandatory algorithm
to support.
The following changes have been made to the parameter types and
encodings (Section 5.2).
o Four new parameter types have been added: DH_GROUP_LIST,
HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST.
o Two parameter types have been renamed: HMAC has been renamed to
HIP_MAC, and HMAC2 has been renamed to HIP_MAC_2.
o One parameter type is deprecated: HIP_TRANSFORM. Functionally, it
has been replaced by the HIP_CIPHER but with slightly different
semantics (hashes have been removed and are now determined by
RHASH).
o The TRANSPORT_FORMAT_LIST parameter allows transports to be
negotiated with the list instead of by their order in the
HIP packet.
o The type code for the R1_COUNTER has been changed from 128 to 129
to reflect that it is now considered a Critical parameter and must
be echoed when present in R1.
o The PUZZLE and SOLUTION parameter lengths are now variable and
dependent on the RHASH length.
o The Diffie-Hellman Group IDs supported have been updated.
o The HOST_ID parameter now requires specification of an Algorithm.
o The NOTIFICATION parameter supports new Notify Message Type
values.
o The HIP_SIGNATURE algorithm field has been changed from 8 bits to
16 bits to achieve alignment with the HOST_ID parameters.
o The specification clarifies that the SEQ parameter always contains
one update ID but that the ACK parameter may acknowledge several
update IDs.
o The restriction that only one ECHO_RESPONSE_UNSIGNED parameter
must be present in each HIP packet has been removed.
o The document creates a new type range allocation for parameters
that are only covered by a signature if a signature is present and
applies it to the newly created DH_GROUP_LIST parameter.
o The document clarifies that several NOTIFY parameters may be
present in a packet.
The following changes have been made to the packet contents
(Section 5.3).
o The I1 packet now carries the Initiator's DH_GROUP_LIST.
o The R1 packet now carries the HIP_CIPHER, HIT_SUITE_LIST,
DH_GROUP_LIST, and TRANSPORT_FORMAT_LIST parameters.
o The I2 packet now carries the HIP_CIPHER and TRANSPORT_FORMAT_LIST
parameters.
o This document clarifies that UPDATE packets that do not contain
either a SEQ or ACK parameter are invalid.
11. References
11.1. Normative References
[FIPS.180-4.2012] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>. [NIST.800-131A.2011] National Institute of Standards and Technology, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST SP 800-131A, January 2011, <http://csrc.nist.gov/ publications/nistpubs/800-131A/sp800-131A.pdf>. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980, <http://www.rfc-editor.org/info/rfc768>. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <http://www.rfc-editor.org/ info/rfc793>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998, <http://www.rfc-editor.org/info/rfc2404>. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998, <http://www.rfc-editor.org/info/rfc2410>. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999, <http://www.rfc-editor.org/info/rfc2536>.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003, <http://www.rfc-editor.org/ info/rfc3526>. [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003, <http://www.rfc-editor.org/info/rfc3602>. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/ info/rfc3972>. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005, <http://www.rfc-editor.org/ info/rfc4034>. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005, <http://www.rfc-editor.org/info/rfc4282>. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007, <http://www.rfc-editor.org/ info/rfc4754>. [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>. [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009, <http://www.rfc-editor.org/info/rfc5702>. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, September 2014, <http://www.rfc-editor.org/info/rfc7343>. [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, April 2015, <http://www.rfc-editor.org/info/rfc7402>.11.2. Informative References
[AUR05] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP Base Exchange Protocol", in Proceedings of the 10th Australasian Conference on Information Security and Privacy, July 2005. [CRO03] Crosby, S. and D. Wallach, "Denial of Service via Algorithmic Complexity Attacks", in Proceedings of the 12th USENIX Security Symposium, Washington, D.C., August 2003. [DIF76] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory Volume IT-22, Number 6, pages 644-654, November 1976. [FIPS.186-4.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>. [FIPS.197.2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>. [HIP-ARCH] Moskowitz, R., Ed., and M. Komu, "Host Identity Protocol Architecture", Work in Progress, draft-ietf-hip-rfc4423-bis-09, October 2014. [HIP-DNS-EXT] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Work in Progress, draft-ietf-hip-rfc5205-bis-06, January 2015.
[HIP-HOST-MOB] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", Work in Progress, draft-ietf-hip-rfc5206-bis-08, January 2015. [HIP-REND-EXT] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", Work in Progress, draft-ietf-hip-rfc5204-bis-05, December 2014. [KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS protection for UDP-based protocols", in Proceedings of the 10th ACM Conference on Computer and Communications Security, October 2003. [KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols", in Proceedings of CRYPTO 2003, pages 400-425, August 2003. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981, <http://www.rfc-editor.org/ info/rfc792>. [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000, <http://www.rfc-editor.org/info/rfc2785>. [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004, <http://www.rfc-editor.org/info/rfc3849>. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008, <http://www.rfc-editor.org/info/rfc5201>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008, <http://www.rfc-editor.org/info/rfc5338>. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>. [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010, <http://www.rfc-editor.org/info/rfc5903>. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>. [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011, <http://www.rfc-editor.org/info/rfc6253>. [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>. [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM 21 (2), pp. 120-126, February 1978. [SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2 Version 2.0, January 2010, <http://www.secg.org/>.
Appendix A. Using Responder Puzzles
As mentioned in Section 4.1.1, the Responder may delay state creation and still reject most spoofed I2 packets by using a number of pre-calculated R1 packets and a local selection function. This appendix defines one possible implementation in detail. The purpose of this appendix is to give the implementors an idea of how to implement the mechanism. If the implementation is based on this appendix, it MAY contain some local modification that makes an attacker's task harder. The Responder creates a secret value S, that it regenerates periodically. The Responder needs to remember the two latest values of S. Each time the S is regenerated, the R1 generation counter value is incremented by one. The Responder generates a pre-signed R1 packet. The signature for pre-generated R1s must be recalculated when the Diffie-Hellman key is recomputed or when the R1_COUNTER value changes due to S value regeneration. When the Initiator sends the I1 packet for initializing a connection, the Responder receives the HIT and IP address from the packet, and generates an #I value for the puzzle. The #I value is set to the pre-signed R1 packet. #I value calculation: #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n) where n = RHASH_len The RHASH algorithm is the same as is used to generate the Responder's HIT value. From an incoming I2 packet, the Responder receives the required information to validate the puzzle: HITs, IP addresses, and the information of the used S value from the R1_COUNTER. Using these values, the Responder can regenerate the #I, and verify it against the #I received in the I2 packet. If the #I values match, it can verify the solution using #I, #J, and difficulty #K. If the #I values do not match, the I2 is dropped. puzzle_check: V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K ) if V != 0, drop the packet If the puzzle solution is correct, the #I and #J values are stored for later use. They are used as input material when keying material is generated.
Keeping state about failed puzzle solutions depends on the implementation. Although it is possible for the Responder not to keep any state information, it still may do so to protect itself against certain attacks (see Section 4.1.1).Appendix B. Generating a Public Key Encoding from an HI
The following pseudo-code illustrates the process to generate a public key encoding from an HI for both RSA and DSA. The symbol ":=" denotes assignment; the symbol "+=" denotes appending. The pseudo-function "encode_in_network_byte_order" takes two parameters, an integer (bignum) and a length in bytes, and returns the integer encoded into a byte string of the given length. switch ( HI.algorithm ) { case RSA: buffer := encode_in_network_byte_order ( HI.RSA.e_len, ( HI.RSA.e_len > 255 ) ? 3 : 1 ) buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len ) buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len ) break; case DSA: buffer := encode_in_network_byte_order ( HI.DSA.T , 1 ) buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 ) buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 8 * HI.DSA.T ) buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 8 * HI.DSA.T ) buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 8 * HI.DSA.T ) break; }Appendix C. Example Checksums for HIP Packets
The HIP checksum for HIP packets is specified in Section 5.1.1. Checksums for TCP and UDP packets running over HIP-enabled security associations are specified in Section 4.5.1. The examples below use [RFC3849] and [RFC5737] addresses, and HITs with the prefix of 2001:20 followed by zeros, followed by a decimal 1 or 2, respectively.
The following example is defined only for testing the checksum calculation.C.1. IPv6 HIP Example (I1 Packet)
Source Address: 2001:db8::1 Destination Address: 2001:db8::2 Upper-Layer Packet Length: 48 0x30 Next Header: 139 0x8b Payload Protocol: 59 0x3b Header Length: 5 0x5 Packet Type: 1 0x1 Version: 2 0x2 Reserved: 1 0x1 Control: 0 0x0 Checksum: 6750 0x1a5e Sender's HIT: 2001:20::1 Receiver's HIT: 2001:20::2 DH_GROUP_LIST type: 511 0x1ff DH_GROUP_LIST length: 3 0x3 DH_GROUP_LIST Group IDs: 3,4,8C.2. IPv4 HIP Packet (I1 Packet)
The IPv4 checksum value for the example I1 packet is shown below. Source Address: 192.0.2.1 Destination Address: 192.0.2.2 Upper-Layer Packet Length: 48 0x30 Next Header: 139 0x8b Payload Protocol: 59 0x3b Header Length: 5 0x5 Packet Type: 1 0x1 Version: 2 0x2 Reserved: 1 0x1 Control: 0 0x0 Checksum: 61902 0xf1ce Sender's HIT: 2001:20::1 Receiver's HIT: 2001:20::2 DH_GROUP_LIST type: 511 0x1ff DH_GROUP_LIST length: 3 0x3 DH_GROUP_LIST Group IDs: 3,4,8
C.3. TCP Segment
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets use the IPv6 pseudo header format [RFC2460], with the HITs used in place of the IPv6 addresses. Sender's HIT: 2001:20::1 Receiver's HIT: 2001:20::2 Upper-Layer Packet Length: 20 0x14 Next Header: 6 0x06 Source port: 65500 0xffdc Destination port: 22 0x0016 Sequence number: 1 0x00000001 Acknowledgment number: 0 0x00000000 Data offset: 5 0x5 Flags: SYN 0x02 Window size: 65535 0xffff Checksum: 28586 0x6faa Urgent pointer: 0 0x0000Appendix D. ECDH and ECDSA 160-Bit Groups
The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits symmetric strength. This was once considered appropriate for one year of security. Today, these groups should be used only when the host is not powerful enough (e.g., some embedded devices) and when security requirements are low (e.g., long-term confidentiality is not required).Appendix E. HIT Suites and HIT Generation
The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA), and a hash that includes the Host Identity and a context ID. The OGA is an index pointing to the specific algorithm by which the public key and the 96-bit hashed encoding are generated. The OGA is protocol 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 combinations of signature and hash algorithms into HIT Suites. These HIT Suites are addressed by an index, which is transmitted in the OGA ID field of the ORCHID. The set of used HIT Suites will be extended to counter the progress in computation capabilities and vulnerabilities in the employed 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 the 4-bit OGA ID field only permits 15 HIT Suites to be used at the same time (the HIT Suite with ID 0 is reserved), phased-out HIT
Suites must be reused at some point. In such a case, there will be a rollover of the HIT Suite ID and the next newly introduced HIT Suite will start with a lower HIT Suite index than the previously introduced one. The rollover effectively deprecates the reused HIT Suite. For a smooth transition, the HIT Suite should be deprecated a considerable time before the HIT Suite index is reused. Since the number of HIT Suites is tightly limited to 16, the HIT Suites must be assigned carefully. Hence, sets of suitable algorithms are grouped in a HIT Suite. 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 signature algorithm family used for generating the HI. The list of HIT Suites is defined in Table 10.
Acknowledgments
The drive to create HIP came to being after attending the MALLOC meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman really gave the original author, Bob Moskowitz, the assist to get HIP beyond 5 paragraphs of ideas. It has matured considerably since the early versions thanks to extensive input from IETFers. Most importantly, its design goals are articulated and are different from other efforts in this direction. Particular mention goes to the members of the NameSpace Research Group of the IRTF. Noel Chiappa provided valuable input at early stages of discussions about identifier handling and Keith Moore the impetus to provide resolvability. Steve Deering provided encouragement to keep working, as a solid proposal can act as a proof of ideas for a research group. Many others contributed; extensive security tips were provided by Steve Bellovin. Rob Austein kept the DNS parts on track. Paul Kocher taught Bob Moskowitz how to make the puzzle exchange expensive for the Initiator to respond, but easy for the Responder to validate. Bill Sommerfeld supplied the Birthday concept, which later evolved into the R1 generation counter, to simplify reboot management. Erik Nordmark supplied the CLOSE-mechanism for closing connections. Rodney Thayer and Hugh Daniels provided extensive feedback. In the early times of this document, John Gilmore kept Bob Moskowitz challenged to provide something of value. During the later stages of this document, when the editing baton was transferred to Pekka Nikander, the input from the early implementors was invaluable. Without having actual implementations, this document would not be on the level it is now. In the usual IETF fashion, a large number of people have contributed to the actual text or ideas. The list of these people includes Jeff Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Xin Gu, Rene Hummen, Miika Komu, Mika Kousa, Julien Laganier, Andrew McGregor, Jan Melen, Henrik Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka Ylitalo. Our apologies to anyone whose name is missing. Once the HIP Working Group was founded in early 2004, a number of changes were introduced through the working group process. Most notably, the original document was split in two, one containing the base exchange and the other one defining how to use ESP. Some modifications to the protocol proposed by Aura, et al. [AUR05] were added at a later stage.
Authors' Addresses
Robert Moskowitz (editor) HTT Consulting Oak Park, MI United States EMail: rgm@labs.htt-consult.com Tobias Heer Hirschmann Automation and Control Stuttgarter Strasse 45-51 Neckartenzlingen 72654 Germany EMail: tobias.heer@belden.com Petri Jokela Ericsson Research NomadicLab Jorvas FIN-02420 Finland Phone: +358 9 299 1 EMail: petri.jokela@nomadiclab.com Thomas R. Henderson University of Washington Campus Box 352500 Seattle, WA United States EMail: tomhend@u.washington.edu