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

[Robert Moskowitz <[e-mail]>]

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.


>
>> 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...

>
>>
>> HIT and LSI formats
>> Standardize on ORCHIDs
>> Context per HI Hash?
>
> Yes, RFC 4843 specifies that we use CGA Extension Type Tags registered 
> by IANA for contexts, and 5201 specifies that it be one per hash. The 
> only value allocated for hip is bound to SHA-1 by 5201. We can 
> allocate more.

Exactly.

>
>> IP address range for LSIs
>
> The v6 ORCHID range is currently reserved until 2014, this may be 
> changed by standards action. v4 needs thought and either standards or 
> IANA action.

127.n.0.0/16 And what is n? Let IANA tell us or recommend something? e.g. 64

>
>>
>> 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?

>
> 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?

>
>>
>> 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.

>
>>
>> HIP registries (DNS, DHT, LDAP, etc.)
>> What information is stored in each
>> For DNS
>> HIs, HITs, HI hashes, lifetime via TTL
>> ESP ciphers?
>> RR from IANA
>
> I suggest updating 5205 along the lines of 
> draft-ponomarev-hip-dns-locators and draft-ponomarev-hip-hit2ip. This 
> will require some DNS expert attention to get the details right. I 
> think that's sufficient for DNS.
>
> The Boeing SMA implementation in OpenHIP has an LDAP schema, I have 
> not looked at the detail.
>
>>
>> OK. This is a start. Others should add/expand, and someone needs to 
>> be the 'owner' of the list. 

-- 


The Greatest Oak

Was once a little Nut

That held its ground.