Subject: [Hipsec] Use of hash in HIP, and making changes

From: Robert Moskowitz <[email-masked]>
Date: Tue, 08 Dec 2009 10:54:10 -0500

This is only looking at 5201:

SHA1 (or SHA-1, lack of text consistancy) is used for the following 
purposes:

HIT generation.  This uses the second pre-image resistance hash requirement.

HIP-TRANSFORMs, as part of an HMAC.

HMAC, as in the HMAC HIP Parameters (and I think also NOTIFY and ECHO?).

HIP_SIGNATURE, when using RSA/SHA1.

HIP KEYMAT, the RHASH is  SHA1

PUZZLE, RHASH again.

============================================

So I have two meta questions:

So we need hashes, can a MAC provide the needed functions?

Can we simplify the code base.  For example, GMAC makes claims to meet 
the same security goals as HMAC without the underlying hash.  So if you 
are implementing GCM for your ESP and HIP transforms, you get GMAC along 
with it and can use it where you would use HMAC and supposedly even a 
MAC?  Hmm, I wonder if I got that right.  More document reading....

============================================

So I think the biggest barrier to dropping hashes for switching to MACs 
is HIP_SIGNATURE.  We are supposedly using PKIX functions here and I 
don't recall reading anywhere of a MAC alternative.  So in fact we are 
limited to what is handed to use from the PK community.  Breaking new 
ground is not so good of a thought?

An alternative to HMAC makes sense.  My reading of NIST modes shows 
two:  CMAC and GMAC.  CMAC is an evolution of CBC-MAC and GMAC is a 
'reduction?' of GCM.  There are some security concerns about GMAC on the 
NIST resource, but they seem 'avoidable' here.

There are viable alternatives to HMAC's use of a hash as in CMAC and 
GMAC.  I might think that both KEYMAT and PUZZLE could be based on them 
instead of RHASH.  But that still leaves the HIT and HIP_SIG, and I 
don't see them being replaced by anything other than another hash.  This 
means SHA-256 until 2012Q4.

Any other views on this?