Re: [Hipsec] comments on new HIP draft

Thanks very much for this writeup. It helps me a lot. More specific comments below. If I don't comment on something, that indicates that I (mostly) agree and don't see any reason to say anything specific upon that at this time. I may come back when I reach that far in my editing.

Henderson, Thomas R wrote:
> - reference [8] (RFC 2536) should be RFC 2535 instead... the "flags,

There seems to be disagreement whether to use RFC2535 or not. Derek opposes RFC2535, and I tend to agree with him. Thus, we need to think about this more. I will try to send another mail on this later today.

OTOH, everybody seems to be happy with RFC2536 public key format. Thus, we will use at least that (instead of just DSA.Y).

Current consensus: RFC2536 will be used for DSA keys, but it is currently open whether this will be wrapped into RFC2535 envelope or not. This applies both to HIT calculation and HOST_ID payload, I guess.

> Sec 3.2. Local Scope Identity

This is definitely a question that requires more thoughts. There is already a separate thread. I would propose that we continue discussing on that thread about this.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

> 3.3 Security Parameter Index
>
> - It is not clear where the requirement for a random SPI comes from.

I think we have to ask Bob about this.

> 4.2 HIP Cookie Exchange

I stared writing a long messages about this yesterday , but I haven't been able to finalize and send it yet. Will do soon.

> Section 6.3 Supported transforms

I think that ESP-NULL should be MUST to implement but SHOULD NOT to accept in a negotation. MUST implement to make interoperability testing easier, and there *are* people that think that encryption costs too much. SHOULD NOT use since it is insecure :-)

> Section 7.3 HIP Keymat

Actually you MUST NOT use Kij in the keymat. If you do, an attacker can cryptanalyze the sessions where you use the key first, and thereby get Kij, and with that all of the rest of the keys. If you begin with K1, cryptanalyzing it doesn't help in revealing the other keys.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

Thus, KEYMAT = K1 | K2 | ...

Other than that, I think the keymat proposal is fine.

--Pekka