Re: [Hipsec] Status of our milestones

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Tobias Heer
> Sent: Thursday, September 01, 2011 12:35 AM
> To: HIP
> Subject: Re: [Hipsec] Status of our milestones
> 
> Hello,
> 
> after having put my major personal roadblock aside, I'd like to get
> back to RFC5201-bis and get the last issues resolved.
> 
> There are still some (few) open issues we need to address. Not all of
> them can be addressed without any discussion.
> Therefore I'd like to ask for some opinions here. All tickets can be
> found in the ticket system.
> 
> I'll start with two of the easier ones:
> 
> Ticket 22: R1_COUNTER inclusion in I2
> -------------------------------------
> http://trac.tools.ietf.org/wg/hip/trac/ticket/22
> 
> RFC 5201 makes it optional to echo the R1 counter in the !I2!. However,
> when its
> optional, its hard to implement because you have to account for the
> case that
> the counter is present or missing in the I2. Skipping the counter all
> together
> is not an option because the Initiator uses it to sort out old R1s - so
> we need
> it in the R1. Alternatively, we could leave it out of the !I2! and the
> Responder
> could encode the required generation information into the R1
> ECHO_REQUEST. It
> would get back the information in any case because the ECHO_RESPONSE in
> the !I2! is a MUST.
> However, we'd have some redundancy with the R1_COUNTER in the R1 then
> (which we
> can't remove because of the reasons stated above).
> 
> My conclusion: I'd make it a MUST. Any comments on this?
> 
> Ticket 27: IESG: allow negotiation of KDF
> -----------------------------------------
> The IESG commented that the key distribution function should be
> negotiable. We
> defined a new and better KDF. Are we done now?  I guess not. We have
> two
> options. Tie the KDF to the Diffie Hellman Group and negotiate it
> together with
> the DH group in the DH group list (my preferred option) OR negotiate it
> separately. As I view it, changing the KDF should only happen a) if
> something
> goes horribly wrong and the current KDF becomes insecure or b) if you
> want to
> change the scenario in which you want to apply HIP radically (e.g., if
> you move
> towards embedded systems). I think both cases will not demand high
> flexibility
> in the choice of the KDF (you don't pick another KDF just because you
> can).
> Moreover, we still have plenty of available DH_GROUP IDs left. I would
> opt for
> making the KDF exchangeable but to fix it to the DH group ID.
> 
> Any objections?
> 
> 
> I'm looking forward to your feedback.
> 

I agree with your proposed resolutions.

- Tom