Re: [Hipsec] Building the first list of to Standards changes

[Andrew McGregor <[e-mail]>]

On 31/07/2009, at 9:33 PM, Robert Moskowitz wrote:

> Andrew McGregor wrote:
>> Whole lot of responses inline...
>>
>> On 31/07/2009, at 10:46 AM, Robert Moskowitz wrote:
>>
>>> OK we have met and agreed to go out and succeed.
>>>
>>> In light of that, lets get our work items in order and someone set  
>>> up the tracking of who is working on what and what it is its status.
>>>
>>> Crypto Agility
>>> Add HI PK algorithms
>>
>> We use DNS formats for these, and so far the only RFCs published  
>> are RSA and DSA. There is a draft for ECC, there may be others.  
>> Code points are allocated by standards action. So this cannot  
>> progress until the DNS formats do.
>>
>>> Add HI hashes
>>
>> 5201 defines the RHASH which is used for all hash operations in the  
>> protocol to be the same as the hash used for ORCHIDS, see below.
>
> I would also want CBC-MAC, as hardware that implements CCM has CBC- 
> MAC. There is lots of wireless hardware that implements CCM...
>
> And there are those that will expect SHA-256.

For completeness, RIPEMD-160 and WHIRLPOOL?

CBC-MAC can't be used as a general hash function.  So, we can define a  
way to use CBC-MAC or CCM+ instead of HMAC, but we'll still need a  
hash at the same time for HIT generation and cookies.

>>> Add ESP cipher suites
>>
>> Straightforward, do you have a list of candidates?
>
> CCM, as this is in wireless hardware. GCM as this is in highspeed  
> wired hardware. Or those are the claims...

CCM and CCM+ since it's the latter in 802.15 hardware.

>>> Multiple HIs per host
>>> Multiple HITs per HI
>>
>> I think these can be done already. Current implementations may not  
>> support multiple HIs per host, but I see no reason in the protocol  
>> why this can not be done. Multiple HITs per HI can happen given  
>> that hash agility is per context; therefore the ORCHIDS  
>> corresponding to different hashes are astronomically unlikely to  
>> collide. Local policy dictates if any particular HIT is acceptable.
>>
>> However, the IESG note at the beginning of 5201 has this to say:
>>
>> This document doesn't currently define support for parameterized
>> (randomized) hashing in signatures, support for negotiation of a key
>> derivation function, or support for combined encryption modes.
>>
>> The first point will require a lot of thought, although the packet  
>> formats should be straightforward.
>
> OK. This is an important one I left off. Would the hash used for  
> making the HIT be the hash used in the HIP sigs? Or is this YAP to  
> add to things like HIP options and DNS RR?

Actually, I've done some more reading.  HIP refers to RFC 4034  
(Resource Records for the DNS Security Extensions) for signature  
formats.  Any future DNSSEC formats are similarly applicable.  There  
are no drafts specifying hashed variants for DNSSEC.  So, as DNSSEC  
adds algorithms, so can HIP.

>> The second point could be covered by redefining the DIFFIE_HELLMAN  
>> group id parameter to be an (algorithm, group) suite ID... this  
>> would even be backward compatible by reusing the existing values  
>> with the same processing definition. The third is merely more suite- 
>> ids for those modes.
>
> So would we have a list of key derivations and this is just one more  
> parameter?

No, it's expanding the definition of an existing codepoint space; all  
the existing codepoints are regarded as specifying standard DH key  
negotiation with some group, new ones have to specify a key  
negotiation algorithm as well as its necessary group (or whatever)  
parameter.

BTW, the combined encryption modes is yet more codepoints, with the  
minor complication that the HMAC TLV calculation definition should  
include specifying the use of the encryption algorithm's 'additional  
data' as an HMAC, rather than using the RHASH.  This amounts to  
replacing 'HIP-gl or HIP-lg integrity key retrieved from KEYMAT' in  
section 6.4 of RFC 5201 with something like 'HIP-gl or HIP-lg  
integrity key retrieved from KEYMAT, except that if the encryption  
algorithm in use is also to be used for message authentication, use  
the encryption key instead'.  Also I guess that HMAC should be renamed  
MAC everywhere.

>>> ESP operation with HIP
>>> Explain Binding Transport Mode End to End without creating a new  
>>> ESP mode
>>
>> This amounts to a wording change in 5202, all the text is already  
>> there. BEET is a recommended implementation detail for 5202 ESP  
>> processing and does not change the wire format or semantics, so  
>> there should be no problem here.
>>
>>> AH operation with HIP
>>>
>>> Compressing Transport checksums
>>> New HIP option?
>>
>> I'm not sure what you're suggesting. Compressing suites could be  
>> defined for ESP. Or are you suggesting compressing the HIP packets  
>> themselves?
>
> If you are going to allow for removal of the TCP and UDP checksums,  
> both parties would need to agree they are going to do this.

So, I suggest using suite-IDs for this; responder indicates prepared  
to use those suites, initiator can as usual take it or leave it.