[Hipsec] rfc5201-bis-04 review

[Ari Keranen <[e-mail]>]

Hi,

I reviewed part of the -04 draft (version dated Jan 27th), and here's some comments, questions, and suggestions. 


Since we are specifying the version 2 of the protocol, should we say that in the title and abstract?


1.  Introduction

   As a result, all cryptographic protocols need to be agile.
   That is, it should be a part of the protocol to switch from one
   cryptographic primitive to another, and reasonable effort should be
   done to support a reasonable set of mainstream algorithms.

s/to switch/to be able to switch/

Instead of "reasonable effort should be done [...]" one could say something like: "[...] it is important to support a reasonable set of mainstream algorithms to cater for different use cases and allow moving away from algorithms that are later discovered to be vulnerable".


1.1.  A New Namespace and Identifiers

   The HI is a
   public key and directly represents the Identity.

s/Identity/identity of a host/


   Since there are
   different public key algorithms that can be used with different key
   lengths, the HI is unsuitable for use as a packet identifier

s/HI is unsuitable/HI, as such, is unsuitable/


   Consequently, a hash of the HI, the Host
   Identity Tag (HIT), is the operational representation.

s/is/is used as/


1.2.  The HIP Base Exchange (BEX)

   It
   should be noted, however, that both the Initiator's and the
   Responder's HITs are transported as such (in cleartext) in the
   packets, allowing an eavesdropper with a priori knowledge about the
   parties to identify them by their HITs.  Hence, encrypting the HI of
   any party does not provide privacy against such attacker.

This text goes fairly deep into a specific attack and could better fit to the Security Considerations section than in the introduction.


   Data packets start to flow after the 4th packet.  The 3rd and 4th HIP
   packets may carry a data payload in the future.  However, the details
   of this may be defined later.

s/may be defined later/are not defined for the time being/


   Thus, HIP is not a
   complete replacement for IKE.

This begs for a question "why would I use HIP instead of IKE". Perhaps a section (to appendix?) on HIP's relationship to IKE (and a reference to that section here) would be helpful.


2.3.  Definitions

All the definitions repeat the "defined word" in the beginning; that's a bit redundant. That is, instead of:

   HIP Base Exchange (BEX)  The HIP Base Exchange is the handshake for
      establishing a new HIP association.

One could say:

   HIP Base Exchange (BEX): the handshake for
      establishing a new HIP association


Could also add "Initiator", "Responder", "HIP association" and "signed" to the definitions.


3.  Host Identity (HI) and its Structure

   HIP implementations MUST support the Rivest Shamir Adelman (RSA)
   [RFC3110] public key algorithm, and SHOULD support the Digital
   Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
   Digital Signature Algorithm (ECDSA) defined in Section 5.2.8. 

Must support [...] for generating the Host Identity, as defined in [...]


   Other
   algorithms MAY be supported.

s/Other/Additional/


3.1.  Host Identity Tag (HIT)

This section repeats quite a bit the material in the previous section. Maybe some of the text related to HITs in the previous section could be removed and discussed only here.


   This document extends [RFC5201] with measures to support crypto
   agility.

s/extends [RFC5201]/extends the original, experimental HIP specification [RFC5201]/ or "HIP v1" or something.


3.2.  Generating a HIT from an HI

   The HIT MUST be generated according to the ORCHID generation method
   described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of
   0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA

Should one say something about the byte order of the value?


4.1.  Creating a HIP Association

   By definition, the system initiating a HIP exchange is the Initiator,
   and the peer is the Responder.  This distinction is forgotten once
   the base exchange completes, and either party can become the
   Initiator in future communications.

Would one call a host making a HIP transaction (say, UPDATE) during an active HIP association an Initiator? The text seems to imply that, but at least I would not have used that term in that case. 

Also, there are cases where one may need to remember the distinction after the BEX (e.g., with NAT traversal the Initiator becomes the active ICE agent; and I vaguely remember discussing some time ago some other use case too..), so I would say, e.g., that the "distinction is typically forgotten [...]".


   The R2 packet acknowledges the receipt of the I2 packet and completes
   the base exchange.  The packet is signed by the Responder.

s/The packet/The R2 packet/


   The base exchange is illustrated below

The figure should be numbered (,center-aligned), and referenced with the number. Bit surprisingly, none of the figures in the draft are numbered.


4.1.1.  HIP Puzzle Mechanism

   The puzzle mechanism has been explicitly designed to give space for
   various implementation options.  First, it allows a Responder
   implementation to completely delay session-specific state creation
   until a valid I2 packet is received.  In such a case, a correctly
   formatted I2 packet can be rejected immediately once the Responder
   has checked its validity by computing only one hash function.

Why is a correctly formatted I2 rejected? Because of incorrect solution?


   Second, the design also allows a Responder implementation to keep
   state about received I1 packets, and match the received I2 packets
   against the state, thereby allowing the implementation to avoid the
   computational cost of the hash function. 

It's not clear what this means (how one avoids the cost by matching).


4.1.2.  Puzzle Exchange

   [...] the Receiver can verify that it has itself sent the I to the

s/Receiver/Responder/


   NOTE: The protocol developers explicitly considered whether a memory
   bound function should be used for the puzzle instead of a CPU-bound
   function.  The decision was not to use memory-bound functions.

A few words of rationale for not using memory-bound functions would be nice.


4.1.3.  Authenticated Diffie-Hellman Protocol with DH Group Negotiation

   However, since it is precomputed and therefore does not cover
   association-specific information in the I1 packet [...]

s/it is/the signature is/ or /the R1 is/ ?


   The Initiator continues the BEX only
   if the Group ID of the public DH value of the Responder intersects
   the preferences of both Initiator and Responder. 

s/intersects the preferences of/is the most preferred of the IDs supported by/


   Otherwise, the
   communication is subject of a downgrade attack and the Initiator MUST
   either restart the key exchange with a new I1 packet or abort the key
   exchange.

s/key exchange/base exchange/g


   The signature of the I2
   message covers all signed parameters of the packet without exceptions
   as in the R1.

Saying "all signed parameters are signed" sounds a bit redundant. And what would be an exception to this rule?


4.1.4.  HIP Replay Protection

   The scope of the
   counter MAY be system-wide but SHOULD be applied per Host Identity,
   if there is more than one local host identity.

What "applied per Host Identity" means is not clear. Could be "every HI must have its own counter" or "every HI must use the same counter and increase it at every usage".


   Implementations MUST accept puzzles from the current
   generation and MAY accept puzzles from earlier generations.

Could give some recommendation on how many earlier generations SHOULD be accepted (otherwise one may conclude that any earlier is always OK).


   When
   sending multiple I1 packets, an Initiator SHOULD wait for a small
   amount of time (a reasonable time may be 2 * expected RTT) after the
   first R1 reception to allow possibly multiple R1s to arrive

s/multiple I1 packets/multiple I1 packets to the same host/


4.1.5.  Refusing a HIP Exchange

   A HIP-aware host may choose not to accept a HIP exchange.  If the
   host's policy is to only be an Initiator, it should begin its own HIP
   exchange.  A host MAY choose to have such a policy since only the
   privacy of the Initiator's HI is protected in the exchange.  It
   should be noted that such behavior can introduce the risk of a race
   condition if each host's policy is to only be an Initiator, at which
   point the HIP exchange will fail.

s/HIP Exchange/HIP Base Exchange/g (title and text) -- unless this applies to some other exchanges too? Same with Section 4.1.6.

Also, should there be some mechanism to detect and prevent the race situation continuing forever?


4.1.7.  HIP Downgrade Protection

   In a downgrade attack, an attacker manipulates the packets of an
   Initiator and/or a Responder to unnoticeably influence the result of
   the cryptographic negotiations in the BEX to its favor.

s/an attacker manipulates/an attacker attempts to unnoticeably manipulate/
(and remove the 2nd unnoticeably)


   In contrast to the first version of HIP [RFC5201], this version
   begins the negotiation of the DH Groups already in the first BEX
   packet, the I1.

s/this version/the version 2 of HIP defined in this document/


   If the choice of the DH Group in the
   R1 packet does not equal to the best match of the two lists (the
   highest priority of the Responder that is present in the Initiator's
   DH list), 

s/highest priority/highest priority DH ID/


4.1.8.  HIP Opportunistic Mode

   Since the Responder's HIT Suite is not determined by the
   destination HIT of the I1 packet, the Responder can freely select a
   HIT of any HIT Suite.

s/is not determined/in the opportunistic mode is not determined/


   the Initiator MAY restart the
   BEX with an I1 packet with a source HIT that is contained in the list
   of the Responder's HIT Suites in the R1 packet.

s/is contained in/is compatible with one of the Suite IDs in/


4.4.3.  HIP State Processes

   | Receive I2, process | If successful, send R2 and go to R2-SENT    |

What does "process" mean here? (same in the other tables) Should that be "receive and process"? And what is the difference compared to triggers without "process" (e.g., with receiving I1s and in Table 6)?


  | Receive ANYOTHER    | Drop and stay at UNASSOCIATED               |

"ANYOTHER" is not defined. Could just say "Receive something else" or define ANYOTHER somewhere (say, change 4.4.1 into "State Machine Terminology" and have ANYOTHER there).


Table 3 (I1-SENT)

   | Receive I1          | If the local HIT is smaller than the peer   |
   |                     | HIT, drop I1 and stay at I1-SENT            |

s/Receive I1/Receive I1 from the peer/
Or maybe could explain before the table that "Receive X" means here receiving from a peer one is setting up a HIP SA with -- or does it?

Could also add a reference to the Section 6.5 on how to compare HITs


Table 5: R2-SENT - Waiting to finish HIP
and
Table 6: ESTABLISHED - HIP association established

What to do if some other HIP message arrives? Probably with message types not specified in this document that's extension-specific, but could mention it somewhere here. Also, Table 5 doesn't have CLOSE_ACK.


Table 7: CLOSING - HIP association has not been used for UAL minutes

   | Timeout, increment  | If timeout sum is less than UAL+MSL         |
   | timeout sum, reset  | minutes, retransmit CLOSE and stay at       |
   | timer               | CLOSING                                     |

This trigger's definition is not particularly clear.


4.5.1.  TCP and UDP Pseudo-Header Computation for User Data

   When computing TCP and UDP checksums on user data packets that flow
   through sockets bound to HITs, the IPv6 pseudo-header format
   [RFC2460] MUST be used, even if the actual addresses on the packet
   are IPv4 addresses.

s/on the packet/on the IP header of the packet/


4.5.2.  Sending Data on HIP Packets

   A future version of this document may define how to include user data
   in various HIP packets.  However, currently the HIP header is a
   terminal header, and not followed by any other headers.

Do we plan to do this in a future version of *this* document or would that be better left for some other document?


4.6.  Certificate Distribution

   This document does not define how to use certificates or how to
   transfer them between hosts.  These functions are expected to be
   defined in a future specification.

Informational reference to the CERT draft could be appropriate.


I'll send additional nits off-list.


Cheers,
Ari