Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-19
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7401.
|
|
|---|---|---|---|
| Authors | Robert Moskowitz , Tobias Heer , Petri Jokela , Thomas R. Henderson | ||
| Last updated | 2014-09-26 (Latest revision 2014-09-22) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-14)
by Tom Taylor
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Gonzalo Camarillo | ||
| Shepherd write-up | Show Last changed 2014-03-20 | ||
| IESG | IESG state | Became RFC 7401 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Ted Lemon | ||
| Send notices to | hip-chairs@tools.ietf.org, draft-ietf-hip-rfc5201-bis@tools.ietf.org | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions |
draft-ietf-hip-rfc5201-bis-19
6. The system MUST check that the Initiator HIT Suite is contained
in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the
Initiator's HIT Suite is supported by the Responder). If the
HIT Suite is supported by the Responder, the system proceeds
normally. Otherwise, the system MAY stay in state I1-sent and
restart the BEX by sending a new I1 packet with an Initiator HIT
that is supported by the Responder and hence is contained in the
HIT_SUITE_LIST in the R1 packet. The system MAY abort the BEX
if no suitable source HIT is available. The system SHOULD wait
for an acceptable time span to allow further R1 packets with
higher R1 generation counters or different HIT and HIT Suites to
arrive before restarting or aborting the BEX.
7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN
parameter in the R1 matches the first DH Suite ID in the
Responder's DH_GROUP_LIST in the R1 packet that was also
contained in the Initiator's DH_GROUP_LIST in the I1 packet. If
the DH Group ID of the DIFFIE_HELLMAN parameter does not express
the Responder's best choice, the Initiator can conclude that the
DH_GROUP_LIST in the I1 packet was adversely modified. In such
case, the Initiator MAY send a new I1 packet, however, it SHOULD
NOT change its preference in the DH_GROUP_LIST in the new I1
packet. Alternatively, the Initiator MAY abort the HIP base
exchange.
8. If the HIP association state is I2-SENT, the system MAY re-enter
state I1-SENT and process the received R1 packet if it has a
larger R1 generation counter than the R1 packet responded to
previously.
9. The R1 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the R1 packet and returning
to state UNASSOCIATED. The system SHOULD consider dropping the
R1 packet only if it used a NULL HIT in I1 packet. If the A bit
is set, the Responder's HIT is anonymous and SHOULD NOT be
stored permanently.
10. The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host Identity to
construct a HIT and verify that it matches the Sender's HIT.
11. The system MUST store the received R1 generation counter for
future reference.
12. The system attempts to solve the puzzle in the R1 packet. The
system MUST terminate the search after exceeding the remaining
lifetime of the puzzle. If the puzzle is not successfully
Moskowitz, et al. Expires March 26, 2015 [Page 94]
Internet-Draft HIPv2 September 2014
solved, the implementation MAY either resend the I1 packet
within the retry bounds or abandon the HIP base exchange.
13. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the
DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material
Kij is used for key extraction as specified in Section 6.5.
14. The system selects the HIP_CIPHER ID from the choices presented
in the R1 packet and uses the selected values subsequently when
generating and using encryption keys, and when sending the I2
packet. If the proposed alternatives are not acceptable to the
system, it may either resend an I1 within the retry bounds or
abandon the HIP base exchange.
15. The system chooses one suitable transport format from the
TRANSPORT_FORMAT_LIST and includes the respective transport
format parameter in the subsequent I2 packet.
16. The system initializes the remaining variables in the associated
state, including Update ID counters.
17. The system prepares and sends an I2 packet, as described in
Section 5.3.3.
18. The system SHOULD start a timer whose timeout value SHOULD be
larger than the worst-case anticipated RTT, and MUST increment a
trial counter associated with the I2 packet. The sender SHOULD
retransmit the I2 packet upon a timeout and restart the timer,
up to a maximum of I2_RETRIES_MAX tries.
19. If the system is in state I1-SENT, it SHALL transition to state
I2-SENT. If the system is in any other state, it remains in the
current state.
6.8.1. Handling of Malformed Messages
If an implementation receives a malformed R1 message, it MUST
silently drop the packet. Sending a NOTIFY or ICMP would not help,
as the sender of the R1 packet typically doesn't have any state. An
implementation SHOULD wait for some more time for a possibly well-
formed R1, after which it MAY try again by sending a new I1 packet.
6.9. Processing Incoming I2 Packets
Upon receipt of an I2 packet, the system MAY perform initial checks
to determine whether the I2 packet corresponds to a recent R1 packet
that has been sent out, if the Responder keeps such state. For
Moskowitz, et al. Expires March 26, 2015 [Page 95]
Internet-Draft HIPv2 September 2014
example, the sender could check whether the I2 packet is from an
address or HIT for which the Responder has recently received an I1.
The R1 packet may have had Opaque data included that was echoed back
in the I2 packet. If the I2 packet is considered to be suspect, it
MAY be silently discarded by the system.
Otherwise, the HIP implementation SHOULD process the I2 packet. This
includes validation of the puzzle solution, generating the Diffie-
Hellman key, possibly decrypting the Initiator's Host Identity,
verifying the signature, creating state, and finally sending an R2
packet.
The following steps define the conceptual processing rules for
responding to an I2 packet:
1. The system MAY perform checks to verify that the I2 packet
corresponds to a recently sent R1 packet. Such checks are
implementation dependent. See Appendix A for a description of
an example implementation.
2. The system MUST check that the Responder's HIT corresponds to
one of its own HITs and MUST drop the packet otherwise.
3. The system MUST further check that the Initiator's HIT Suite is
supported. The Responder SHOULD silently drop I2 packets with
unsupported Initiator HITs.
4. If the system's state machine is in the R2-SENT state, the
system MAY check if the newly received I2 packet is similar to
the one that triggered moving to R2-SENT. If so, it MAY
retransmit a previously sent R2 packet, reset the R2-SENT timer,
and the state machine stays in R2-SENT.
5. If the system's state machine is in the I2-SENT state, the
system MUST make a comparison between its local and sender's
HITs (similarly as in Section 6.5). If the local HIT is smaller
than the sender's HIT, it should drop the I2 packet, use the
peer Diffie-Hellman key and nonce #I from the R1 packet received
earlier, and get the local Diffie-Hellman key and nonce #J from
the I2 packet sent to the peer earlier. Otherwise, the system
should process the received I2 packet and drop any previously
derived Diffie-Hellman keying material Kij it might have formed
upon sending the I2 packet previously. The peer Diffie-Hellman
key and the nonce #J are taken from the just arrived I2 packet.
The local Diffie-Hellman key and the nonce I are the ones that
were sent earlier in the R1 packet.
Moskowitz, et al. Expires March 26, 2015 [Page 96]
Internet-Draft HIPv2 September 2014
6. If the system's state machine is in the I1-SENT state, and the
HITs in the I2 packet match those used in the previously sent I1
packet, the system uses this received I2 packet as the basis for
the HIP association it was trying to form, and stops
retransmitting I1 packets (provided that the I2 packet passes
the additional checks below).
7. If the system's state machine is in any other state than
R2-SENT, the system SHOULD check that the echoed R1 generation
counter in the I2 packet is within the acceptable range if the
counter is included. Implementations MUST accept puzzles from
the current generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly received I2
packet is outside the accepted range, the I2 packet is stale
(and perhaps replayed) and SHOULD be dropped.
8. The system MUST validate the solution to the puzzle by computing
the hash described in Section 5.3.3 using the same RHASH
algorithm.
9. The I2 packet MUST have a single value in the HIP_CIPHER
parameter, which MUST match one of the values offered to the
Initiator in the R1 packet.
10. The system must derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the DIFFIE_HELLMAN
parameter. This key is used to derive the HIP association keys,
as described in Section 6.5. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped.
11. The encrypted HOST_ID is decrypted by the Initiator's encryption
key defined in Section 6.5. If the decrypted data is not a
HOST_ID parameter, the I2 packet is silently dropped.
12. The implementation SHOULD also verify that the Initiator's HIT
in the I2 packet corresponds to the Host Identity sent in the I2
packet. (Note: some middleboxes may not able to make this
verification.)
13. The system MUST process the TRANSPORT_FORMAT_LIST parameter.
Other documents specifying transport formats (e.g.
[I-D.ietf-hip-rfc5202-bis]) contain specifications for handling
any specific transport selected.
14. The system MUST verify the HIP_MAC according to the procedures
in Section 5.2.12.
Moskowitz, et al. Expires March 26, 2015 [Page 97]
Internet-Draft HIPv2 September 2014
15. The system MUST verify the HIP_SIGNATURE according to
Section 5.2.14 and Section 5.3.3.
16. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and its
state machine remains in the same state.
17. The I2 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the I2 and the state machine
returns to state UNASSOCIATED. If the A bit is set, the
Initiator's HIT is anonymous and should not be stored
permanently.
18. The system initializes the remaining variables in the associated
state, including Update ID counters.
19. Upon successful processing of an I2 message when the system's
state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or
R2-SENT, an R2 packet is sent and the system's state machine
transitions to state R2-SENT.
20. Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP association
is dropped and a new one is installed, an R2 packet is sent, and
the system's state machine transitions to R2-SENT.
21. Upon the system's state machine transitioning to R2-SENT, the
system starts a timer. The state machine transitions to
ESTABLISHED if some data has been received on the incoming HIP
association, or an UPDATE packet has been received (or some
other packet that indicates that the peer system's state machine
has moved to ESTABLISHED). If the timer expires (allowing for
maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED.
6.9.1. Handling of Malformed Messages
If an implementation receives a malformed I2 message, the behavior
SHOULD depend on how many checks the message has already passed. If
the puzzle solution in the message has already been checked, the
implementation SHOULD report the error by responding with a NOTIFY
packet. Otherwise, the implementation MAY respond with an ICMP
message as defined in Section 5.4.
Moskowitz, et al. Expires March 26, 2015 [Page 98]
Internet-Draft HIPv2 September 2014
6.10. Processing of Incoming R2 Packets
An R2 packet received in states UNASSOCIATED, I1-SENT, or ESTABLISHED
results in the R2 packet being dropped and the state machine staying
in the same state. If an R2 packet is received in state I2-SENT, it
MUST be processed.
The following steps define the conceptual processing rules for an
incoming R2 packet:
1. If the system is in any other state than I2-SENT, the R2 packet
is silently dropped.
2. The system MUST verify that the HITs in use correspond to the
HITs that were received in the R1 packet that caused the
transition to the I1-SENT state.
3. The system MUST verify the HIP_MAC_2 according to the procedures
in Section 5.2.13.
4. The system MUST verify the HIP signature according to the
procedures in Section 5.2.14.
5. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy.
6. Upon successful processing of the R2 packet, the state machine
transitions to state ESTABLISHED.
6.11. Sending UPDATE Packets
A host sends an UPDATE packet when it intends to update some
information related to a HIP association. There are a number of
possible scenarios when this can occur, e.g., mobility management and
rekeying of an existing ESP Security Association. The following
paragraphs define the conceptual rules for sending an UPDATE packet
to the peer. Additional steps can be defined in other documents
where the UPDATE packet is used.
The sequence of UPDATE messages is indicated by their SEQ parameter.
Before sending an UPDATE message, the system first determines whether
there are any outstanding UPDATE messages that may conflict with the
new UPDATE message under consideration. When multiple UPDATEs are
outstanding (not yet acknowledged), the sender must assume that such
UPDATEs may be processed in an arbitrary order by the receiver.
Therefore, any new UPDATEs that depend on a previous outstanding
UPDATE being successfully received and acknowledged MUST be postponed
Moskowitz, et al. Expires March 26, 2015 [Page 99]
Internet-Draft HIPv2 September 2014
until reception of the necessary ACK(s) occurs. One way to prevent
any conflicts is to only allow one outstanding UPDATE at a time.
However, allowing multiple UPDATEs may improve the performance of
mobility and multihoming protocols.
The following steps define the conceptual processing rules for
sending UPDATE packets.
1. The first UPDATE packet is sent with Update ID of zero.
Otherwise, the system increments its own Update ID value by one
before continuing the steps below.
2. The system creates an UPDATE packet that contains a SEQ parameter
with the current value of Update ID. The UPDATE packet MAY also
include zero or more ACKs of the peer's Update ID(s) from
previously received UPDATE SEQ parameter(s)
3. The system sends the created UPDATE packet and starts an UPDATE
timer. The default value for the timer is 2 * RTT estimate. If
multiple UPDATEs are outstanding, multiple timers are in effect.
4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE
can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be
exponentially backed off for subsequent retransmissions. If no
acknowledgment is received from the peer after UPDATE_RETRY_MAX
times, the HIP association is considered to be broken and the
state machine SHOULD move from state ESTABLISHED to state CLOSING
as depicted in Section 4.4.4. The UPDATE timer is cancelled upon
receiving an ACK from the peer that acknowledges receipt of the
UPDATE.
6.12. Receiving UPDATE Packets
When a system receives an UPDATE packet, its processing depends on
the state of the HIP association and the presence and values of the
SEQ and ACK parameters. Typically, an UPDATE message also carries
optional parameters whose handling is defined in separate documents.
For each association, a host stores the peer's next expected in-
sequence Update ID ("peer Update ID"). Initially, this value is
zero. Update ID comparisons of "less than" and "greater than" are
performed with respect to a circular sequence number space. Hence, a
wrap around after 2^32 updates has to be expected and MUST be handled
accordingly.
The sender MAY send multiple outstanding UPDATE messages. These
messages are processed in the order in which they are received at the
receiver (i.e., no re-sequencing is performed). When processing
Moskowitz, et al. Expires March 26, 2015 [Page 100]
Internet-Draft HIPv2 September 2014
UPDATEs out-of-order, the receiver MUST keep track of which UPDATEs
were previously processed, so that duplicates or retransmissions are
ACKed and not reprocessed. A receiver MAY choose to define a receive
window of Update IDs that it is willing to process at any given time,
and discard received UPDATEs falling outside of that window.
The following steps define the conceptual processing rules for
receiving UPDATE packets.
1. If there is no corresponding HIP association, the implementation
MAY reply with an ICMP Parameter Problem, as specified in
Section 5.4.4.
2. If the association is in the ESTABLISHED state and the SEQ (but
not ACK) parameter is present, the UPDATE is processed and
replied to as described in Section 6.12.1.
3. If the association is in the ESTABLISHED state and the ACK (but
not SEQ) parameter is present, the UPDATE is processed as
described in Section 6.12.2.
4. If the association is in the ESTABLISHED state and there is both
an ACK and SEQ in the UPDATE, the ACK is first processed as
described in Section 6.12.2, and then the rest of the UPDATE is
processed as described in Section 6.12.1.
6.12.1. Handling a SEQ Parameter in a Received UPDATE Message
The following steps define the conceptual processing rules for
handling a SEQ parameter in a received UPDATE packet.
1. If the Update ID in the received SEQ is not the next in the
sequence of Update IDs and is greater than the receiver's window
for new UPDATEs, the packet MUST be dropped.
2. If the Update ID in the received SEQ corresponds to an UPDATE
that has recently been processed, the packet is treated as a
retransmission. The HIP_MAC verification (next step) MUST NOT be
skipped. (A byte-by-byte comparison of the received and a stored
packet would be acceptable, though.) It is recommended that a
host caches UPDATE packets sent with ACKs to avoid the cost of
generating a new ACK packet to respond to a replayed UPDATE. The
system MUST acknowledge, again, such (apparent) UPDATE message
retransmissions but SHOULD also consider rate-limiting such
retransmission responses to guard against replay attacks.
3. The system MUST verify the HIP_MAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped.
Moskowitz, et al. Expires March 26, 2015 [Page 101]
Internet-Draft HIPv2 September 2014
4. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error
message logged.
5. If a new SEQ parameter is being processed, the parameters in the
UPDATE are then processed. The system MUST record the Update ID
in the received SEQ parameter, for replay protection.
6. An UPDATE acknowledgment packet with ACK parameter is prepared
and sent to the peer. This ACK parameter MAY be included in a
separate UPDATE or piggybacked in an UPDATE with SEQ parameter,
as described in Section 5.3.5. The ACK parameter MAY acknowledge
more than one of the peer's Update IDs.
6.12.2. Handling an ACK Parameter in a Received UPDATE Packet
The following steps define the conceptual processing rules for
handling an ACK parameter in a received UPDATE packet.
1. The sequence number reported in the ACK must match with an UPDATE
packet sent earlier that has not already been acknowledged. If
no match is found or if the ACK does not acknowledge a new
UPDATE, the packet MUST either be dropped if no SEQ parameter is
present, or the processing steps in Section 6.12.1 are followed.
2. The system MUST verify the HIP_MAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped.
3. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error
message logged.
4. The corresponding UPDATE timer is stopped (see Section 6.11) so
that the now acknowledged UPDATE is no longer retransmitted. If
multiple UPDATEs are acknowledged, multiple timers are stopped.
6.13. Processing of NOTIFY Packets
Processing of NOTIFY packets is OPTIONAL. If processed, any errors
in a received NOTIFICATION parameter SHOULD be logged. Received
errors MUST be considered only as informational, and the receiver
SHOULD NOT change its HIP state (see Section 4.4.2) purely based on
the received NOTIFY message.
Moskowitz, et al. Expires March 26, 2015 [Page 102]
Internet-Draft HIPv2 September 2014
6.14. Processing CLOSE Packets
When the host receives a CLOSE message, it responds with a CLOSE_ACK
message and moves to CLOSED state. (The authenticity of the CLOSE
message is verified using both HIP_MAC and SIGNATURE). This
processing applies whether or not the HIP association state is
CLOSING in order to handle simultaneous CLOSE messages from both ends
that cross in flight.
The HIP association is not discarded before the host moves to the
UNASSOCIATED state.
Once the closing process has started, any new need to send data
packets triggers creating and establishing of a new HIP association,
starting with sending of an I1 packet.
If there is no corresponding HIP association, the CLOSE packet is
dropped.
6.15. Processing CLOSE_ACK Packets
When a host receives a CLOSE_ACK message, it verifies that it is in
CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by
comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to
the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet).
The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for
verification. The state is discarded when the state changes to
UNASSOCIATED and, after that, the host MAY respond with an ICMP
Parameter Problem to an incoming CLOSE message (see Section 5.4.4).
6.16. Handling State Loss
In the case of a system crash and unanticipated state loss, the
system SHOULD delete the corresponding HIP state, including the
keying material. That is, the state SHOULD NOT be stored in long-
term storage. If the implementation does drop the state (as
RECOMMENDED), it MUST also drop the peer's R1 generation counter
value, unless a local policy explicitly defines that the value of
that particular host is stored. An implementation MUST NOT store a
peer's R1 generation counters by default, but storing R1 generation
counter values, if done, MUST be configured by explicit HITs.
Moskowitz, et al. Expires March 26, 2015 [Page 103]
Internet-Draft HIPv2 September 2014
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 is decided by local
policy and depends on the privacy requirements of the Initiator.
The value of #K used in the HIP R1 must be chosen with care. Too
high numbers of #K will exclude clients with weak CPUs because these
devices cannot solve the puzzle within reasonable 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 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 an 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 protocol 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
Moskowitz, et al. Expires March 26, 2015 [Page 104]
Internet-Draft HIPv2 September 2014
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 an 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 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 to 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
Moskowitz, et al. Expires March 26, 2015 [Page 105]
Internet-Draft HIPv2 September 2014
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 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 (for e.g., 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
Moskowitz, et al. Expires March 26, 2015 [Page 106]
Internet-Draft HIPv2 September 2014
Responder does not support HIP, but shortly after receiving the ICMP
message, the Initiator would receive a valid R1 HIP packet. Thus, to
protect from 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 a 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 should be 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"
should be changed from [RFC5201] to this specification.
The following changes to the "Host Identity Protocol (HIP)
Parameters" registries are requested. In many cases, the changes
required involve 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" should be 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.
Moskowitz, et al. Expires March 26, 2015 [Page 107]
Internet-Draft HIPv2 September 2014
All existing values referring to [RFC5201] should be updated to
refer to this specification. Other values should be 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 should be closed to new registrations.
The four-bit HIT Suite ID uses the OGA field in the ORCHID to
express the type of the HIT. This document defines three HIT
Suites (see Appendix E).
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 16 Suite IDs prove 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.
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
registry for "Parameter Type" should be updated as follows.
A new value (129) for R1_COUNTER should be introduced, with a
reference to this specification, and the existing value (128) for
R1_COUNTER left in place with a reference to [RFC5201]. This
documents the change in value that has occurred in version 2 of
Moskowitz, et al. Expires March 26, 2015 [Page 108]
Internet-Draft HIPv2 September 2014
this protocol. For clarity, we recommend that the name for the
value 128 be changed from "R1_COUNTER" to "R1_Counter (v1 only)".
A new value (579) for a new Parameter Type HIP_CIPHER should be
added, with reference to this specification. This Parameter Type
functionally replaces the HIP_TRANSFORM Parameter Type (value 577)
which can be left in the table with existing reference to
[RFC5201]. For clarity, we recommend that the name for the value
577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)".
A new value (715) for a new Parameter Type HIT_SUITE_LIST should
be added, with reference to this specification.
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
should be added, with reference to this specification.
The name of the HMAC Parameter Type (value 61505) should be
changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value
61569) should be changed to HIP_MAC_2. The reference should be
changed to this specification.
All other Parameter Types that reference [RFC5201] should be
updated to refer to this specification, and Parameter Types that
reference other RFCs should be unchanged.
Regarding the range assignments, the Type codes 32768 through
49151 (not 49141) should be Reserved for Private Use. Where the
existing ranges state "First Come First Served with Specification
Required", this should be changed to "Specification Required".
The Type codes 32768 through 49151 are reserved for
experimentation. 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.
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 should be 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
Moskowitz, et al. Expires March 26, 2015 [Page 109]
Internet-Draft HIPv2 September 2014
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 either from
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] should be 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 either from
the reserved or unassigned space are assigned through IETF Review.
ECC Curve Label
When the HI Algorithm values in a HOST_ID parameter is 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 sub-registries 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,
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 should be updated as follows.
The range from 1-50 can remain as "IETF Review". The range from
51-8191 should be marked as "Specification Required". Values
8192-16383 can remain as "Reserved for Private Use". Values
16385-40959 should be marked as "Specification Required". Values
40960-65535 can remain as "Reserved for Private Use".
Moskowitz, et al. Expires March 26, 2015 [Page 110]
Internet-Draft HIPv2 September 2014
The following updates to the values should be made to the existing
registry. All existing values referring to [RFC5201] should be
updated to refer to this specification.
INVALID_HIP_TRANSFORM_CHOSEN should be renamed to
INVALID_HIP_CIPHER_CHOSEN with the same value (17).
A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be
added.
HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same
value (28).
SERVER_BUSY_PLEASE_RETRY should be renamed to
RESPONDER_BUSY_PLEASE_RETRY with the same value (44).
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.
Moskowitz, et al. Expires March 26, 2015 [Page 111]
Internet-Draft HIPv2 September 2014
In the usual IETF fashion, a large number of people have contributed
to the actual text or ideas. The list of these people include Jeff
Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew
McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik
Petander, Michael Richardson, Rene Hummen, Tim Shepard, Jorma Wall,
Xin Gu, 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., [AUR03] were
added at a later stage.
11. Changes from RFC 5201
This section summarizes the changes made from [RFC5201].
11.1. Changes from draft-ietf-hip-rfc5201-bis-18
o Correct documentation prefix in Appendix C from 2001:D88/32 to
2001:DB8/32, and update IPv6 checksum
o Correct documentation prefix reference from RFC 5747 to 5737
o Clarified HIT generation in Appendix E
11.2. Changes from draft-ietf-hip-rfc5201-bis-17
o Update ORCHID reference to newly published RFC 7343
o Update example checksum section to RFC 7343 HIT prefix of
2001:20::/28, and fix incorrect Header Length fields
o Update IANA considerations comment on legacy HIP_TRANSFORM
parameter naming
o Add 2048-bit MODP DHE group as Group ID value 11.
11.3. Changes from draft-ietf-hip-rfc5201-bis-16
o Clarify that receipt of user data in state CLOSING (Table 7)
results in transition to I1-SENT
o Add academic reference for the first mention of the RSA algorithm
Moskowitz, et al. Expires March 26, 2015 [Page 112]
Internet-Draft HIPv2 September 2014
o As part of comment resolution on use of NULL encryption, note that
use of a NULL HIP CIPHER is only to be used when debugging and
testing the HIP protocol. This only pertains to the ENCRYPTED
parameter, which is optional; in practice, if encryption is not
desired, better to just not encrypt the Host ID.
11.4. Changes from draft-ietf-hip-rfc5201-bis-15
o Additional edits to IANA Considerations section based on initial
IANA review.
11.5. Changes from draft-ietf-hip-rfc5201-bis-14
o Update source XML to comply with xmlrfcv2 version of the xml2rfc
tool, resulting in a few table formatting changes.
o Editorial and minor technical revisions based on IESG review.
o Significant revisions to IANA Considerations section based on
initial IANA review.
11.6. Changes from draft-ietf-hip-rfc5201-bis-13
o Update a few references and fix some editorial nits.
11.7. Changes from draft-ietf-hip-rfc5201-bis-12
o Fix I-D nits.
11.8. Changes from draft-ietf-hip-rfc5201-bis-11
o Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix
incorrect section reference.
11.9. Changes from draft-ietf-hip-rfc5201-bis-10
o Issue 39: Text clarifying R1 counter rollover and Initiator
response to unexpected reset of the counter.
11.10. Changes from draft-ietf-hip-rfc5201-bis-09
o Editorial changes based on working group last call.
11.11. Changes from draft-ietf-hip-rfc5201-bis-08
o Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA to
REQUIRED status
Moskowitz, et al. Expires March 26, 2015 [Page 113]
Internet-Draft HIPv2 September 2014
o Issue 35: limiting ECC cofactor to 1
o Changed text regarding issue 33 reusing DH values
o Fix tracker issue 32 on Domain Identifier normative text
11.12. Changes from draft-ietf-hip-rfc5201-bis-07
o Removed lingering references to SHA-1 as the mandatory hash
algorithm (which was changed to SHA-256 in the -02 draft version).
o For parameter type number changes, changed "IETF Review" to "IETF
Review or IESG Approval".
o Updated Appendix C checksum examples to conform to HIPv2 packets.
11.13. 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.14. Changes from draft-ietf-hip-rfc5201-bis-05
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
mode negotiations.
o Added transport form type list parameter. Transport forms are now
negotiated with this list instead of by their order in the HIP
packet. This allows to remove the exception of the transport
format parameters that were ordered by their preference instead of
by their type number. This should remove complexity from
implementations.
o Clarify that in HIP signature processing, the restored checksum
and length fields have been rendered invalid by the previous
steps.
o Clarify behavior for when UPDATE does not contain SEQ or ACQ
(disallow this).
o For namespace changes, changed "IETF Review" to "IETF Review or
IESG Approval".
Moskowitz, et al. Expires March 26, 2015 [Page 114]
Internet-Draft HIPv2 September 2014
o Addressed IESG comment about ignoring packet IP addresses.
o Permit using Anonymous HI control in packets other than R1/I2.
o Fixed minor reference error (RFC2418, RFC2410).
o Deleted comment that NULL-ENCRYPTION SHOULD NOT be configurable
via the UI.
o Editorial changes.
11.15. Changes from draft-ietf-hip-rfc5201-bis-04
o Clarifications of the Security Considerations section. One DoS
defense mechanism was changed to be more effective and less prone
to misuse.
o Minor clarifications of the state machine.
o Clarified text on HIP puzzle.
o Added names and references for figures.
o Extended the definitions section.
o Added a reference to the HIP Version 1 certificate document.
o Added Initiator, Responder, HIP association, and signed data to
the definitions section.
o Changed parameter figure for PUZZLE and SOLUTION to use
RHASH_len/8 instead of n-byte.
o Replaced occurrences of lowercase 'not' in SHOULD NOT.
o Changed text to reflect the fact that several
ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and
several ECHO_RESPONSE parameters may be present in an I2.
o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in
CLOSE_ACK.
o Changed wording from HMAC to HIP_MAC in Section 5.3.8.
o Reflected fact that the UPDATE packet MAY include zero or more
ACKs.
o Added BEX to Definitions section.
Moskowitz, et al. Expires March 26, 2015 [Page 115]
Internet-Draft HIPv2 September 2014
o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to
achieve alignment with the HOST_ID parameters.
o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always
contains ONE update ID. ACK may acknowledge SEVERAL update IDs.
o Added wording that several NOTIFY parameters may be present in a
HIP packet.
o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also
lifted the restriction that only one ECHO_RESPONSE_UNSIGNED
parameter MUST be present in each HIP packet. This did contradict
the definition of the ECHO_RESPONSE_UNSIGNED parameter.
o Changed IETF Consensus to IETF Review or IESG Approval in IANA
section.
o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K
throughout the document.
o Updated references.
o Editorial changes.
11.16. Changes from draft-ietf-hip-rfc5201-bis-03
o Editorial changes to improve clarity and readability.
o Removed obsoleted (not applicable) attack from security
consideration section.
o Added a requirement that hosts MUST support processing of ACK
parameters with several SEQ numbers even when they do not support
sending such parameters.
o Removed note on memory bound puzzles. The use of memory bound
puzzles was reconsidered but no convincing arguments for inclusion
in this document have been made on the list.
o Changed references to reference the new bis documents.
o Specified the ECC curves and the hashes used for these.
o Specified representation of ECC curves in the HI.
o Added text on the dependency between RHASH and HMAC.
Moskowitz, et al. Expires March 26, 2015 [Page 116]
Internet-Draft HIPv2 September 2014
o Rephrased part of the security considerations to make them
clearer.
o Clarified the use of HITs in opportunistic mode.
o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as
between SIGNATURE and SIGNATURE_2.
o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to
RESPONDER_BUSY_PLEASE_RETRY.
o Mentioned that there are multiple valid puzzle solutions.
11.17. Changes from draft-ietf-hip-rfc5201-bis-02
o Added recommendation to not use puzzle #I twice for the same host
to avoid identical key material.
o Revised state machine and added missing event handling.
o Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate unsupported HIT
suites.
o Revised parameter type numbers (corresponding to IANA allocations)
and added missing "free for experimentation" range to the
description.
o Clarifying note on the use of the C bit in the parameter type
numbers.
11.18. Changes from draft-ietf-hip-rfc5201-bis-01
o Changed RHASH-len to RHASH_len to avoid confusion in calculations
(- could be minus)
o Added RHASH_len to list of abbreviations
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
(- could be minus)
o Added RHASH_len to list of abbreviations
o Fixed length of puzzle #I and #J to be 1*RHASH_len
o Included HIT_SUITEs.
Moskowitz, et al. Expires March 26, 2015 [Page 117]
Internet-Draft HIPv2 September 2014
o Added DH negotiation to I1 and R1.
o Added DH_LIST parameter.
o Added text for DH Group negotiation.
o Removed second DH public value from DH parameter.
o Added ECC to HI generation.
o Added Responder HIT selection to opportunistic mode.
o Added ECDSA HI text and references (not complete yet).
o Added separate section on aborting BEX.
o Added separate section on downgrade attack prevention.
o Added text about DH Group selection for use cases without I1.
o Removed type range allocation for parameters related to HIP
transform types.
o New type range allocation for parameters that are only covered by
a signature if a signature is present (Applies to DH_GROUP_LIST).
o Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it -
hashes are determined by RHASH.
o The length of #I and #J for the puzzle now depends on RHASH.
o New keymat generation.
o Puzzle seed and solution now use RHASH and have variable length.
o Moved timing definitions closer to state machine.
o Simplified text regarding puzzle lifetime.
o Clarified the description of the use of #I in the puzzle
o Removed "Opportunistic mode" description from general definitions.
o More consistency across the old RFC5201 text. Aligned
capitalization and abbreviations.
o Extended protocol overview to include restart option.
Moskowitz, et al. Expires March 26, 2015 [Page 118]
Internet-Draft HIPv2 September 2014
o Extended state machine to include restart option because of
unsupported Algorithms.
o Replaced SHA-1 with SHA-256 for required implementation.
o Added OGA list parameter (715) for detecting the Responder's set
of OGAs.
o Added Appendix on ORCHID use in HITs.
o Added truncated SHA-256 option for HITs.
o Added truncated SHA-1 option for HITs.
o Added text about new ORCHID structure to HIT overview.
o Moved Editor role to Robert Moskowitz.
o Added SHA-256 to puzzle parameter.
o Generalized LTRUNC to be hash-function agnostic.
o Added text about RHASH depending on OGA.
11.19. Changes from draft-ietf-hip-rfc5201-bis-00
o Added reasoning why BIS document is needed.
11.20. Contents of draft-ietf-hip-rfc5201-bis-00
o RFC5201 was submitted as draft-RFC.
12. References
12.1. Normative References
[FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[I-D.ietf-hip-rfc5202-bis]
Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip-
rfc5202-bis-05 (work in progress), November 2013.
Moskowitz, et al. Expires March 26, 2015 [Page 119]
Internet-Draft HIPv2 September 2014
[NIST.800-131A.2011]
National Institute of Standards and Technology,
"Transitions: Recommendation for Transitioning the Use of
Cryptographic Algorithms and Key Lengths", NIST 800-131A,
January 2011.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
Moskowitz, et al. Expires March 26, 2015 [Page 120]
Internet-Draft HIPv2 September 2014
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[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.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, January 2007.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702, October
2009.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, September 2014.
12.2. Informative References
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
HIP Base Exchange Protocol", in Proceedings of 10th
Australasian Conference on Information Security and
Privacy, July 2003.
[CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via
Algorithmic Complexity Attacks", in Proceedings of Usenix
Security Symposium 2003, Washington, DC., August 2003.
[DIF76] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory
vol. IT-22, number 6, pages 644-654, Nov 1976.
[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>.
Moskowitz, et al. Expires March 26, 2015 [Page 121]
Internet-Draft HIPv2 September 2014
[FIPS186-3]
U.S. Department of Commerce/National Institute of
Standards and Technology, "FIPS PUB 186-3: Digital
Signature Standard (DSS).", June 2009.
[I-D.ietf-hip-rfc4423-bis]
Moskowitz, R., "Host Identity Protocol Architecture",
draft-ietf-hip-rfc4423-bis-05 (work in progress),
September 2012.
[I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work
in progress), September 2012.
[I-D.ietf-hip-rfc5205-bis]
Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", draft-ietf-hip-rfc5205-bis-02
(work in progress), September 2012.
[I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-06
(work in progress), July 2013.
[KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
protection for UDP-based protocols", ACM Conference on
Computer and Communications Security , Oct 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.
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/
MIME", RFC 2785, March 2000.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
Moskowitz, et al. Expires March 26, 2015 [Page 122]
Internet-Draft HIPv2 September 2014
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338,
September 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June
2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 6253, May 2011.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013.
[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 , 2000, <http://www.secg.org/>.
Moskowitz, et al. Expires March 26, 2015 [Page 123]
Internet-Draft HIPv2 September 2014
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 on 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 that 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.
Moskowitz, et al. Expires March 26, 2015 [Page 124]
Internet-Draft HIPv2 September 2014
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.
Moskowitz, et al. Expires March 26, 2015 [Page 125]
Internet-Draft HIPv2 September 2014
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,8
C.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
Moskowitz, et al. Expires March 26, 2015 [Page 126]
Internet-Draft HIPv2 September 2014
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 0x0000
Appendix D. ECDH and ECDSA 160 Bit Groups
The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits
symmetric strength. Once this was 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 is 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
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 field only permits 15 HIT Suites (the HIT Suite with ID
Moskowitz, et al. Expires March 26, 2015 [Page 127]
Internet-Draft HIPv2 September 2014
0 is reserved) to be used in parallel, 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 11.
The following HIT Suites are defined for HIT generation. The input
for each generation algorithm is the encoding of the HI as defined in
Section 3.2. The output is 96 bits long and is directly used in the
ORCHID.
+-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+-------+----------+--------------+------------+--------------------+
| 0 | | | | Reserved |
| 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI |
| | | | | hashed with |
| | | | | SHA-256, truncated |
| | | | | to 96 bits |
| 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed |
| | | | | with SHA-384, |
| | | | | truncated to 96 |
| | | | | bits |
| 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI |
| | | | | hashed with SHA-1, |
| | | | | truncated to 96 |
| | | | | bits |
+-------+----------+--------------+------------+--------------------+
Table 11: HIT Suites
The hash of the responder as defined in the HIT Suite determines the
HMAC to be used for the HMAC parameter. The HMACs currently defined
here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC-
SHA-1 [RFC2404].
Moskowitz, et al. Expires March 26, 2015 [Page 128]
Internet-Draft HIPv2 September 2014
Authors' Addresses
Robert Moskowitz (editor)
Verizon Telcom and Business
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
EMail: robert.moskowitz@verizonbusiness.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
USA
EMail: tomhend@u.washington.edu
Moskowitz, et al. Expires March 26, 2015 [Page 129]