[hiprg] Putting HIP on a Diet

Robert Moskowitz <rgm@htt-consult.com> Mon, 17 May 2010 16:07 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 418213A6A8E for <hiprg@core3.amsl.com>; Mon, 17 May 2010 09:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.921
X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_95=3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id wZOyiLBeKUNI for <hiprg@core3.amsl.com>; Mon, 17 May 2010 09:07:05 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com []) by core3.amsl.com (Postfix) with ESMTP id 8DF913A6D5B for <hiprg@irtf.org>; Mon, 17 May 2010 09:03:42 -0700 (PDT)
Received: from localhost (unknown []) by klovia.htt-consult.com (Postfix) with ESMTP id A4FCC68D1B; Mon, 17 May 2010 15:57:00 +0000 (UTC)
Received: from klovia.htt-consult.com ([]) by localhost (klovia.htt-consult.com []) (amavisd-new, port 10024) with ESMTP id VN9bNCKqsyXo; Mon, 17 May 2010 11:56:51 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt []) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 227F068D1E; Mon, 17 May 2010 11:56:51 -0400 (EDT)
Message-ID: <4BF168C8.8070608@htt-consult.com>
Date: Mon, 17 May 2010 12:03:20 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: hipsec@ietf.org, hiprg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [hiprg] Putting HIP on a Diet
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2010 16:07:05 -0000

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.