Subject: [Hipsec] HIP CIpher -- AES-CTR

From: Robert Moskowitz <[email-masked]>
Date: Fri, 18 Nov 2011 15:20:58 -0500

What is HIP_CIPHER?

This is the cipher used to encrypt a HIP parameter (that calls for 
encrypting).  No HIP Parameter authentication is used, encrypted 
parameters are protected with any of the various HIP_MAC parameters.

HIP_CIPHER AES-CBC

This is quite a reasonable cipher to use.  The IV is defined variously.  
However...

802.11 and 802.15 interfaces have AES-CCM built into them.  It was 
pointed out to me, that for HIP-DEX, I had added the need for the AES 
decrypt in software because I was using AES_CBC for the HIP_CIPHER.  So 
I am changing HIP-DEX to specify AES-CTR.

I am bringing this to everyone's attention so we can get agreement on 
the construct of the counter

AND

Perhaps it should be added to 5201-bis as well...

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

No on to defining the counter.  We will reference RFC 3686 for the 
counter block format.  We need a 32 bit nonce and a 64 bit IV and then 
there will be a 32 bit block counter (quite an overkill for the size and 
number of encrypted parameter blocks, but stay consistant).

It is my proposal that R1_Counter be used for the IV and the puzzle I 
and J be used for the nonce (low order 32 bits as they are larger than 
32bits).  Or 'just' use I and J, their lower 96bits.

This brings into focus that we need to specify that I and J can never be 
equal (it just could happen, it can work if k=0).  We use I and J as 
nonces in few areas.  They need to be unique.  I think we missed being 
explicit on this test.

Using R1_Counter turns it from a SHOULD to a MUST if HIP_CIPHER = AES-CTR.

But does the update frequency of the puzzle and its potential reuse 
introduce a potential weakness.  The responder would be using the same 
counter space in different HIP exchanges.  As long as these are with 
different initiators, this is not a problem as the DH derived keys would 
be different.  In HIP-BEX with ephemeral DH, we are still 'safe'?  But 
HIP-DEX with static ECDH, we could never use the same puzzle between two 
HP-DEX peers.

An alternative would be to still use I and J for the IV, but to include 
a 32bit nonce with the encrypt block that MUST be fresh with each block.

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

Two questions:

For HIP-DEX: how to construct the Counter Block.

For HIP-BEX: is AES-CTR worth adding?