Subject: [Hipsec] HIP base draft 01 - preliminary version 3

From: [email-masked] (Petri Jokela)
Date: Fri Oct 22 03:51:01 2004

Hello everyone,

I uploaded base draft 01 pre3 version to our server. Thanks to Julien 
for his efforts on these editions. The deadline for submitting 01 draft 
is on Monday, so I will make last editions before the deadline and after 
that submit the 01 version. (Sorry, it was not purpose to generate work 
for you for the weekend, but... :-)

http://hip4inter.net/drafts.php

Some comments:

- New state picture.

- HIP packet numbering changed (payload, bos removed and close, 
close_ack added)

- One paragraph added in Security Considerations.

Issue #44: SIGMA

An additional HMAC in I2 and changed HMAC in R2. The HMAC in R2 covers, 
in addition to the packet, the HOST_ID of the Responder. I changed this 
type now to HMAC_2.

Are the changes ok, or are there errors:
	o SIGMA vs. current HIP
	o packet definitions
	o packet handling
	o ...

Issue #47: DSA/RSA

The RSA is now defined as MUST, DSA as RECOMMENDED.

Issue #46: HIT 126 vs. 128 bits

Text edited.

Issue #48: PAYLOAD + BOS

PAYLOAD and BOS packets were removed from the draft (as proposed by 
Pekka). Left for future drafts. Any comments on this?

Text still missing / open things:

1) There was discussion about the D-H usage. Shall we edit the base spec 
text related to this?

Base spec (Miika 11.10):
   "The Diffie-Hellman value is ephemeral, but can be reused over a
    number of connections.  In fact, as a defense against I1 storms, an
    implementation MAY use the same Diffie-Hellman value for a period of
    time, for example, 15 minutes."

Pekka in one of his mails (11.10.2004):

"Well, my understanding has been that you shouldn't reuse
your DH-key, ever.  (Maybe the docs don't say that.)"

2) Random value: text still to be added to base spec

Yogesh (20.9.2004)

o  In the draft it's important to say that the responder should keep
    the random value r for at least 2*MSL  (and possibly longer) from the
    last time it sent message 2. In case Message 3 arrives after 2*MSL,
    and no random number r can be found, it should be dropped and an ICMP
    message should be sent. If the Initiator receives an ICMP after
    sending message-3, it should not assume that the responder sent
    the message, and should not close that session. An Initiator
    MAY however start with a new parallel I1 with a new nonce value.

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 25 09:50:01 2004

Some comments on base-01-pre3.  I'm late, I know, and these
probably won't make it to -01, but maybe then to -02.

--Pekka

More substantial:

-  Rename the REKEYING state into a more generic one, like UPDATE 
pending
    or UPDATING or something?

-  HMAC_2 description must be fixed.  Here is my initial proposal

     160 low order bits of the HMAC computed over a given
     set of data, which includes some data that is NOT in
     the packet that carries this payload.  The exact contents
     is defined case-by-case; see the relevant packet description.

-  The HMAC_2 calculation in 7.4 is too vague.  It needs to have
    a picture of what to hash etc.

-  We need a proper IANA Considerations section.

-  Remove Appendix E.  This needs to be a separate specification.

More editorial:

-  Section 5.4 seems to be slightly out of date.  The state machine
    has grown into fairly complex, contrary to the claims in this 
section.

-  In 5.4.2, there is strange cross reference to Sec 6.3 in the HTML 
version
-  Same for 6.2.9.

An idea: would it be better to move to a table presentation, or to 
include
an appendix that gives a table with states as rows and incoming 
messsages
as columns.  There are now nine packets and nine states, so the table
has 81 cells altogether.  However, in many cases the response is 
identical
for a number of messages or number of states, and therefore quite a 
number
of the cells actual merge.

-  In 5.4.3 (state diagram), remove the phrase "and NES received", as it
    does not need to be there.  That makes UPDATE more generic update
    mechanism, not NES specific.

-  the cases where the arcs cross each other are closing, as
    the diagram uses the same symbol for crossing arcs (+) and
    arc turns/joins.  I think a crossing arc should be just
    a vertical bar, giving the visual image that the horisontal
    arc goes beneath the vertical one.

-  In 6.2.7, I think that the sentence "The OAKLEY well known group
    5 is the same as the 1536-bit MODP group." is no longer needed
    and confusing

-  In order not the have to rewrite all "Valid Control Bits"
    text in Section 7, it may be better to make SHT and RHT not
    to be part of Controls?  Or just update the various places
    in Section 7.

-  Move 8.12 (CER) after 8.8 (R2)
-  Move 8.9 (dropping) before 8.14 (CLOSE), and update it accordingly
    currently the text is not in line with the close mechanism