[Hipsec] Welcome to 5201-bis-02

[Robert Moskowitz <[e-mail]>]

Tobias Heer with my able assistance, has completed the lastest effort to 
move 5201 (and HIP!) to cryto agility and standards track.

Well I will say that Tobias did most of the writing, but I'll take the 
heat on where we went with the changes.  Tobias figured out how to add 
the crypto agility and avoid some downgrade attacks.  I spent time 
figuring out how to add ECDSA to the document and changes to KEYMAT.

There ARE a number of changes, we changed the version number.  HIP BEX 
still functions as in 5201, but we had to make the Hash negotiable, add 
ECDSA, and more Diffie-Hellman options (like ECDH).  This resulted in 
some interesting changes.

Tobias, Miika, and I have spent considerable time debating what crypto 
suites to include.  We are trying to balance agility and compactness. 
Should we drop SHA-1 like a hot potato and just specify SHA-256 and -384 
until SHA-3 comes out?  Or should SHA-1 still play and we downplay 
SHA_384?  Or is SHA-384 locked in to meet Suite-B needs?  Which ECDSA 
key sizes, P160, P256, and P384 seem to be the minimum (read why for 
P160).  And finally which AES modes (duo modes excluded for HIP 
payloads).  So please think on this and weigh in with your views.

First notice the change to the HIT.  We realized we need to encode a 
HIT_Suite_ID into the HIT.  Without this there were a number of 
complications and attack options.  But this cost us 4 bits from the 
hash.  We have a limited number of Suite ID slots and are concerned 
about how many we eat up right out the door.  Note that each hash eats 
TWO IDs, one for RSA/DSA and one for ECDSA (also HIP DEX will take one 
more).

The only change to the previous state machine is a transition from state 
I1-SENT to I1-SENT - the restart option. An Initiator is required to 
restart the HIP exchange if the Responder does not support the HIT Suite 
of the Initiator.  Note that I have made additional changes to the state 
machine in HIP DEX to add aggresive retransmission.  Take a read of that 
and we can discuss if BEX would benefit from this feature.

Next on the the puzzle.  Basically we made the size of I and J variable 
to the size of the keying needed.  Plus the hash is the one in the 
HIT_Suite_ID.

We have added a Diffie-Hellman list into I1.  Read the text on what is 
going on here.  More choices, hints needed, downgrade attacks to avoid.

HOST_ID parameter got reworked.  There is no ECDSA RDATA currently and 
the ID is limited to just NIST-ECDSA-256 and NIST-ECDSA-384.  We needed 
at least BrainpoolP160r1, and perhaps more.  So I changed even the 
handling of RSA and DSA to be ONLY the specifics from their DNSSEC RFCs. 
  Then I built up how ECDSA should be handled, using 
draft-mcgrew-fundamental-ecc-03.txt.

The HMAC parameters are renamed MAC, but in 5201 they are still using 
HMAC with the hash specified in the HIT-Suite_ID.

HIP_Transform has been replaced by HIP_Cipher.  The hash is locked down 
by the HIT_Suite_ID, so the only thing to negotiate is what cipher will 
be used for things like the ENCRYPTED parameter.

I redid KEYMAT to directly use RFC 5869.  The changes were slight, but 
it puts us using a new standard for hash-based KEYMAT.

IANA considerations has been increased.

We need some help with the Appendices;.B and C in particular.


Anyway, please start reading.  We will collect comments.  Those which 
are obvious we will incorporate in a -03 to publish just before the July 
12th cutoff date.  Others we will organize into discussion points for 
the 5201-bis reading gathering.