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
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
