Subject: [Hipsec] A list of important HIPv2 changes for implementors

From: Tobias Heer <[email-masked]>
Date: Tue, 17 Apr 2012 16:07:17 +0200

Hello,

currently there are at least two efforts to create HIPv2 that I know of.
I believe compiling a list of implementation changes that need to be done
in order to transform a HIPv1 into a HIPv2 implementation might be useful.
I'll try to make this list as complete as I can. Please feel free to
respond to this e-mail to add more changes. I also tried to keep this
short and concise. Please respond if you don't understand what I mean.

The items on this list are often related. I tried not to bundle related
things to avoid oversimplification - as a result some things pop up twice
in the list.

This list is not intended as complete guide but it should serve to make a
implementor's life a bit easier by highlighting important changes. It is
intended to be something like a checklist but it cannot be used as sole
basis for upgrading an HIPv1 implementation. This list assumes that the
reader is familiar with RFC5201 and the -bis document.

--------------------------------------------------------------------

 1) HIP Version Number:
    dual implementations should use the version numbers to distinguish
    HIPv1 and HIPv2 packets.

--------------------------------------------------------------------

 2) Signature and Hash Algorithms:
    HIPv2 supports more options than HIPv1 support for these
    algorithms is required. Also the default algorithms are
    different. Check sections 5.2.7-5.2.11 for new algorithms.

--------------------------------------------------------------------

 3) Host Identity Tag structure:
    The new structure has a number of bits for identifying the
    employed algorithms. These bits need to be parsed and the HI
    verification algorithms must be chosen accordingly. Also, when
    creating a HIT, the right bits must be set according to the
    employed Algorithms.

--------------------------------------------------------------------

 4) DH negotiation starts in I1 already:
    The Initiator transmits its supported DH groups in the I1. This
    means that the I1 now carries a parameter. This parameter must be
    set, parsed, and used for selecting an appropriate DH group. See
    section 4.3.3.

--------------------------------------------------------------------

 5) DH negotiations:
    HIPv2 does not assume that all hosts support all DH groups and
    algorithms. Therefore this can now be negotiated. The Initiator sets
    the supported group and the responder responds with its selected group
    and selection. There are sanity checks that need to be performed in
    order to safeguard against replay attacks (See sections 4.3.3 and
    4.3.4 and 4.1.6 and 4.1.7). There is a new paremeter: DH_GROUP_LIST
    and the DIFFIE_HELLMAN parameter changed and has new options. Also,
    there is a restart option if the DH group selection of the Responder
    does not match the lists of the peers. The selection of the algorithm
    is solely based on the lists and is very strict. Sloppy selection or
    missing lists result in incompatibilities and security issues.

--------------------------------------------------------------------

 6) Aborting BEX: 
    HIP hosts can now abort the BEX if they suspect an attacker. The
    necessary conditions are described in 4.1.6. This may affect the
    state machines of the implementations because simply
    re-establishing the BEX won't suffice in the face of an attacker.

--------------------------------------------------------------------

 7) The DH negotiations require protection against downgrade attacks.
    This also affects the state machines because the BEX must be
    restarted if an attack is suspected (See Section 4.1.7). HIPv2
    state machines must implement this restart procedure.

--------------------------------------------------------------------

 8) The tabular state machine states and transitions of HIPv2 are
    more complete than those of HIPv1. You may want to check if your
    HIPv1 implementation actually implements all states and state
    transitions. There is a new transition from I1-SENT to I1-SENT in
    case no algorithm is supported.

--------------------------------------------------------------------

 9) The KDF is not static any more but is defined by the DH Group.
    The employed KDF should not be hard-coded any more.

--------------------------------------------------------------------

10) There are a number of parameters that are new or have changed:

    HIP_PUZZLE: Stayed as it was but the puzzle is now solved and
    checked with RHASH. This means that the #i and #j length are now
    aligned with the length of RHASH.

    DH_GROUP_LIST: New parameter.

    DIFFIE_HELLMAN: It can only contain a singe DH group now. The
    groups and IDs have changed and the mandatory support hash
    changed. 512-bit RSA was replaced by 160-bit ECDSA. The group ID
    also defines the KDF now.

    HIP CIPHER: This was HIP_TRANSFORM and was refined to be more
    useful. It has a new parameter number, too.

    HOST_ID: The format has changed and there is a new field for the
    algorithm. There is also a specification of the expected ECC
    format. There are new algorithms and new mandatory support for
    some.

    HIT_SUITE_LIST: New parameter.

    TRANSPORT_FORMAT_LIST: HIPv1 used a special parameter range for
    expressing preferences regarding the selected transport formats.
    This required to ignore the ascending order of the parameters in
    the BEX packets for these special parameters. This made
    implementations somewhat complex because special case handling was
    necessary. HIPv2 uses lists to express preferences and uses this
    method for the transport-related parameters as well. Compare the
    end of Sections 5.2 in RFC5201 and HIPv2. This is a new parameter
    that replaces the special case handling of parameter numbers. 

    HIP_MAC: This was the HMAC parameter. It was renamed to better
    reflect its function. It uses RHASH now (not hard-coded SHA-1).

    HIP_MAC2: This was the HMAC_2 parameter. It was renamed to better
    reflect its function.

    HIP_SIGNATURE: The format has changed slightly. There are more
    bits for the signature algorithm now.

    NOTIFY: Some codes were renamed. New code: 20

    R1_COUNTER: New type number.

--------------------------------------------------------------------

11) R1 counter is mandatory:
    Support for the R1 counter is mandatory now. It MUST be echoed
    now if it is present in an R1. It has a new type number now to
    reflect that change.

--------------------------------------------------------------------

12) Improved UPDATE handling:
    UPDATES MUST contain either SEQ or/and ACK now. Otherwise it is
    invalid. Hosts MUST be able to process packets with several SEQs
    now.

--------------------------------------------------------------------

13) Updated packet handling rules:
    The description of the packet handling in Section 6.6-6.16 has
    been revised to match the new procedures. I suggest to double check
    this description with the behaviors of the implementation carefully.
    This is the place where errors are quite likely.

--------------------------------------------------------------------

14) Treating multiply received R1s:
    The procedures for handling multiple received R1s have been
    revised (Section 6.8).

--------------------------------------------------------------------

15) Updated security considerations:
    The security considerations have been revised in regard to DoS
    attacks. It is recommended to compare the threats mentioned here
    to the countermeasures of the implementation.

--------------------------------------------------------------------

16) Handling of the #I field in the puzzle:
    The same puzzle #I should not be sent to the same Initiator twice
    to avoid creating identical key material twice.

--------------------------------------------------------------------

17) Please read the changelog:
    It is a good idea to read the changelogs at the end of the current
    HIPv2 document carefully (Section 11). I know its boring but it
    mentions all changes and is more complete than this list.

That's it for now. Please reply to this mail if more changes come to your
mind. I hope this helps.

Tobias

-- Dr. Tobias Heer, Postdoctoral Researcher Chair of Communication
and Distributed Systems - comsys RWTH Aachen University, Germany tel:
+49 241 80 207 76 web:
http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog:
http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id:
AEECA5BF