Re: [Hipsec] [hiprg] Putting HIP on a Diet

Hi Bob,

I squint towards this definition and evolution direction for HIP:

"HIP a class of protocols built on a Host Identity, each bring a slightly 
different set of security claims and risks and a slightly different 
domain of use."

This might make HIP more OPEN for many aspect.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : gao.yang2@zte.com.cn
===================================

Robert Moskowitz <rgm@htt-consult.com> 
发件人:  hiprg-bounces@irtf.org
2010-05-18 00:03

收件人
hipsec@ietf.org, hiprg@irtf.org
抄送

主题
[hiprg] Putting HIP on a Diet

I am posting this update to both mailing lists.  Eventhough I started 
all of this and am now working hard to rev HIP for Standards Track, I 
still will follow establish procedures on evolving HIP.

To that end, we are all fairly well aware that sensor vendors chafe at 
how much crypto cruft we load into a Key Management System like HIP and 
go about taking things out without really looking at the basis of why we 
do things as they are.  Back during IETF 77 I committed to developing a 
slimmer HIP.  A HIP Diet EXchange (DEX).  To this end I reviewed all we 
have done and why and what the options are.  A few key points have come 
out:

The cost of Diffie-Hellman.

Diffie-Hellman, even the Elliptic Curve version, is an important 
component in HIP, but it forces the use of HMAC to extract a uniformly 
distributed key.  Other areas where HMAC are used COULD use CMAC (though 
need to work out a new puzzle mechanism, see below).  The alternative to 
Diffie-Hellman is a key wrap by a RSA/ECC key, like in TLS.   The 
Initiator CAN do this in I2, but it is HARD to get a key from the 
Responder in 4 packets.  Putting an encrypted key in R2 would mean that 
the MAC in I2 is different than R2 (one possiblity) or if the encrypted 
key is in R1, then there are flooding attack concerns.  All things to 
work out to pull D-H from a Dietetic HIP.

Also, by definition, SIGMA compliance is built on Diffie-Helman. 
Perfect Forward Secrecy is build on Diffie-Hellman we would have to 
'approximate' SIGMA with PK key wrapping; the same with PFS.

The cost of HMAC.

As I mentioned above, Diffie-Hellman currently requires HMAC.  Otherwise 
HMAC use in both the puzzle and the HIP_MAC COULD be replaced with CMAC.

The cost of hashing.

Whew, HIP is built on hashing.  What security claims do we really need 
for the HIT?  Collision Avoidance enough?  Could some compress function 
be used in place of SHA for HIT generation?  Switching to CMAC over HMAC 
addresses the other uses of hashing.

In summary.

What is HIP?  Is HIP the exchange we have now have and only that?  Or is 
HIP a class of protocols built on a Host Identity, each bring a slightly 
different set of security claims and risks and a slightly different 
domain of use?  I am willing leaving my comfort zone with BEX and am 
defining DEX:  HIP Diet EXchange:

A compress function that generates a HIT from an ECDSA Host Identity 
(160, 224, and possibly 256 bits large).
CMAC for macing functions and key expansion.
Public Key secret wrapping for key distribution.

If anyone wants to help on the details, let me know.  I need a new 
puzzle using CMAC.  I need a compress function for HIT generation.  The 
goal is a full draft before the IETF 78 cutoff date and hopefully a good 
start by the end of this month.  Work will be done in HIPrg if it does 
not fit in HIPsec, but this will really be pushed towards the IEEE 
802.15 community.

Thank you for listening to my ramblings.  If you have addtional 
thoughts, share them here or privately with me.

_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.