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 algorithmsWe 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 hashes5201 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 suitesStraightforward, 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 HII 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 HIPExplain Binding Transport Mode End to End without creating a new ESP modeThis 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.