Subject: [Hipsec] additional comments on latest RFC5201-bis draft

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 9 Sep 2013 04:50:22 +0000

Last week I published a new version of RFC5201-bis:
http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13

This was mainly to address ID-nits and prepare the draft for the next stage of the review process.  However, I also received a number of comments from Anders Brandt (cc'ed) on the version-12 draft.  The purely editorial ones were included in version-13, but I decided to post a few for review on the list.

In the interest of expediency, I'd like to suggest that we aim for resolving all of these within the next two weeks.

1)  Section 4.1, the statement is made:

"As a result, it is believed that the HIP opportunistic mode is at least as secure as current IP."

Anders questioned what this statement means.  Further clarifications are needed here.

2) Section 5.1

"Since all HIP headers MUST contain the sender's and receiver's HIT fields, the minimum value for this field is 4, and conversely, the maximum length of the HIP parameters filed is (255*8-32 = 2008 bytes."

Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs clarification or reference to the discussion on HIP fragmentation in Section 5.1.3.

3) Section 5.3.2

"If the Responder uses the same DH keypair for multiple handshakes.  It must take care to avoid small subgroup attacks [RFC2785]."  These sentences are marked by Anders, perhaps for grammatical reasons (they should at least be combined).

4) Section 6.7.1, R1 Management

Anders asks whether it is allowed to make an initiator-only device, if there is a MUST in this section to be able to produce R1s.  I do not believe that the current protocol allows one to make an initiator-only device; perhaps this could be clarified.

- Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 09 Sep 2013 13:47:15 -0400

> Anders asks whether it is allowed to make an initiator-only device, if there is a MUST in this section to be able to produce R1s.  I do not believe that the current protocol allows one to make an i…

I can think of two reasons that R1 should be supported in all devices:

Loss of state. If a device receives a datagram protected with a HIP SPI, 
but lacks that SPI, perhaps this is due to loss of state by that device 
(post reboot condition). Sending an I1 to the other party is the way to 
recover state. Of course we allow for a receiver of an I1 to turn around 
and send an I1 itself, forcing the R1 generation back on the party that 
loss state.

Rekey. Key exhaustion MAY be addressed by an UPDATE or reruning HIP 
exchange. Thus either party could force the exchange.

Just some quick thoughts.

---

From: Miika Komu <[email-masked]>
Date: Tue, 10 Sep 2013 10:56:02 +0300

Hi,

> Anders questioned what this statement means.  Further clarifications are needed here.

I would just suggest combining this sentence with the previous 
paragraph. Alternatively, this could perhaps be rephrased as:

As a result, opportunistic mode in HIP offers a "better than nothing" 
security model. Initially, a base exchange authenticated in the 
opportunistic mode involves a leap of faith subject man-in-the-middle 
attacks, but subsequent datagrams related to the same HIP association 
cannot be compromised by a new man-in-the-middle attack. Thus, it can be 
stated that opportunistic mode in HIP is at least as secure as 
unprotected IP-based communications.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Sep 2013 15:59:29 -0400

On 09/10/2013 03:56 AM, Miika Komu wrote:
>> This was mainly to address ID-nits and prepare the draft for the next 
>> stage of the review process. However, I also received a number of 
>> comments from Anders Brandt (cc'ed) on the version-12 draft. The 
>> purely editorial ones were included in version-13, but I decided to 
>> post a few for review on the list.
>>
>> In the interest of expediency, I'd like to suggest that we aim for 
>> resolving all of these within the next two weeks.
>>
> cannot be compromised by a new man-in-the-middle attack. Thus, it can 
> be stated that opportunistic mode in HIP is at least as secure as 

+10000 :)

I really like this way of putting it. The MITM has one chance only and 
then must ALWAYS be in the middle. So maybe something else is needed 
that if the MITM "steps away", the attack is exposed after the fact?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 26 Sep 2013 20:45:11 +0000

I'll try to wrap up the inputs and post a revision over the weekend, if no further comments.  Please see inline below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henderson, Thomas R
> Sent: Sunday, September 08, 2013 9:50 PM
> To: HIP
> Cc: [email-masked]'
> Subject: [Hipsec] additional comments on latest RFC5201-bis draft
> 

I propose to address this with the union of Miika and Robert's comments:

As a result, opportunistic mode in HIP offers a "better than nothing" 
security model. Initially, a base exchange authenticated in the opportunistic mode involves a leap of faith subject to man-in-the-middle attacks, but subsequent datagrams related to the same HIP association cannot be compromised by a new man-in-the-middle attack, and further, if the man-in-the-middle moves away from the path of the active association, the attack would be exposed after the fact. Thus, it can be stated that opportunistic mode in HIP is at least as secure as unprotected IP-based communications.

> 
> 2) Section 5.1
> 
> "Since all HIP headers MUST contain the sender's and receiver's HIT
> fields, the minimum value for this field is 4, and conversely, the
> maximum length of the HIP parameters filed is (255*8-32 = 2008 bytes."
> 
> Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs
> clarification or reference to the discussion on HIP fragmentation in
> Section 5.1.3.

I propose to add a reference here to the later section on fragmentation requirements.

> 
> 3) Section 5.3.2
> 
> "If the Responder uses the same DH keypair for multiple handshakes.  It
> must take care to avoid small subgroup attacks [RFC2785]."  These
> sentences are marked by Anders, perhaps for grammatical reasons (they
> should at least be combined).

I will just repair the grammatical error (make into one sentence), since no other comments were received.

> Anders asks whether it is allowed to make an initiator-only device, if
> there is a MUST in this section to be able to produce R1s.  I do not
> believe that the current protocol allows one to make an initiator-only
> device; perhaps this could be clarified.
> 

My view is in line with Robert's on this, so I propose:

Old text:

All compliant implementations MUST be able to produce R1 packets.

New text:

All compliant implementations MUST be able to produce R1 packets; even if a device is configured by policy to only initiate associations, it must be able to process I1s in case of recovery from loss of state or key exhaustion.