Subject: [Hipsec] Base draft issues

From: Petri Jokela <[email-masked]>
Date: Thu, 19 Oct 2006 13:26:48 +0300

Hi,

I have received a bunch of comments related to the base draft (thanks to 
Joseph, Pekka S. and Eric) and I have tried to clarify and fix things in the 
draft. In addition to the ones listed below, I have fixed some typos.

The pre-release of 07 draft is available at

http://hip4inter.net/drafts.php

draft-ietf-hip-base-07-pre191006.*

Also diff from 06 is available.

BR, Petri

1. Puzzle description, conflicting "keep state" statements.

The text in 4.1.1. allows keeping state of failed puzzle solutions, but
appendix A says "SHOULD NOT".

- fixed 4.1.1. "algorithm" -> "algorithmic" (typo from the reference)
- Appendix 2: modified the text so that it allows also keeping state. I'm
not sure, however, if the original SHOULD NOT referred to the particular
way to implement or not.

2. 384-bit D-H group

"The weakness of this group is discussed in the appendix, it should
probably also be discussed or at least referenced in the security
considerations.  If this group can really be broken in real-time then I
would question whether it should be a MUST to support."

- modification in 5.2.6
- added a paragraph in Security Considerations

3. ECHO_REQUEST / RESPONSE

There are now two different ECHO_REQUEST and ECHO_RESPONSE parameters,
depending on if they are signed or not.

- multiple modifications on the draft. Please see if they are acceptable.
I made change so that if the request is signed, it should be replied with
response that is signed. If the request is unsigned, it is responded with
unsigned ECHO_RESPONSE.

4. HIP_SIGNATURE_2

"The HIP signature 2 does not cover the puzzle sent from the responder to
the initiator.  I am not quite comfortable with this yet.  I can't think
of a problem associated with this off hand but it hasn't sunk in yet.

It is only a SHOULD for the initiator to verify the signature, in what
cases is it acceptable not to verify the signature?"

- After a discussion, a clarification is added to 4.1.1. related to
the unsigned puzzle.

- I haven't added anything related to the second part of the comment,
possibly the SHOULD should be clarified, i.e. under what circumstances
the host can skip the signature verification.

5. Signature algorithms

"The value RSA actually refers to RSA/SHA1 so it probably should indicate
this in the name since it is possible to use RSA with a different hash. "

- I have made modifications related to this. Are they ok?

6. HI Lifetime

"The HI lifetime is not really discuss except for a statement that if the
(optional) RI counter wraps then the HI MUST be replaced.  This seems a
bit odd since the RI counter is optional and is not necessarily
guaranteed to be maintained in all cases. If there is a concern with HI
lifetime then it should be described elsewhere in the document.   If a
host changes a key unexpectedly it could create difficulties.  For
example one way of mitigating some MITM risk is to use the SSH style
"leap of faith" to create a local HI database (perhaps this is discussed
in opportunistic HIP). "

- after a discussion I modified 4.1.4. slightly (R1 counter SHOULD NOT
roll over), but I am not sure if this is enough.

7. 5.2.2. conflict

"In bullet 3 its states the "... By default, sending of such a new
critical parameters SHOULD be off... "  then it says the management
interface MUST allow vanilla standards-only mode as a default
configuration setting, and MAY allow new critical payloads to be
configured on (and off)"

It seems they should either both be MUSTS or both be SHOULDS.  I think I
would prefer that it say something like "Implementations operating in a
mode adhering to this standard MUST disable the sending of new critical
parameters." "

- Text modified in 5.2.2. bullet 3.

8. Introduction: security association management

"I do not think this paragraph is entirely clear about the role of HIP
wrt. IKE.  Does this mean that as "base protocol lacks the details for SA
management..." that IKE must be used on conjuntion with HIP to manage the
SAs?  Or that if additional SA management features are deemed necessary, IKE
must be used in addition to HIP?  I suspect you mean the latter, but the
language should be more explicit on this."

- I modified the sentence at the end of 1.2

9. Clarification needed: protocol number 253 assigned for what purpose.

- I modified the first paragraph in "IANA Considerations". I hope
it is clearer now.

10. Question about definition of "small amount of time".

- clarification in 4.1.4. The clarifying definition is not very
accurate, but gives maybe a hint what the small amount of time could be.

11. comment about the "increasing order" in 5.2.1

- added a sentence to the first paragraph in 5.2.1. Ok?

12. Padding in parameter length

- removed last sentence of third paragraph in 5.2.1

13. Wrong IP addresse in Appendix C.

"I don't think I found in 5.1.1 or elsewhere any specification why you
used IPv4-compatible IPv6 format here.  Is that a pseudo-header
representation of an IPv4 address?  If so, it should probably be a
mapped address (::ffff:a.b.c.d) instead as the compatible address has
been deprecated and was used in tunneling. "

- Added a clarification that the purpose of the v6 address format is to
get the same output using either v4 or v6 implementations. This is only
for testing purposes.

14. Intro: "other documents"

"Which "other documents"?  It might help if this was set
up as a bullet list with specific references for each of
the bullets."

- I modified the Introduction section to contain references to the
mentioned docs.

15. NOTIFY parameter and NOTIFY packet

- The parameter name was changed to NOTIFICATION.

List of issues that I do not necessarily require immediate actions or
that I haven't modified:

16. Risk with using the same D-H value and random puzzle

"The security consideration section indicates there is a risk in using
the same D-H value and random puzzle, but it does not describe what the
risk is.  This makes it difficult to balance with the tradeoff
described. "

- I haven't made any modifications related to this. Any input for this?

17. Sigma

"The draft claims to be based on the SIGMA exchange.  While it is similar
there are some differences.  In particular the signature on the
responder's exponential is not required to be validated. I think it
looks OK since the last MAC is signed by the responder, but it would
probably be good to have another set of eyes look at it. "

-- 
Petri Jokela				e-mail: [email-masked]
Research Scientist			phone:  +358 9 299 2413
Ericsson Research, NomadicLab		mobile: +358 44 299 2413

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec