Subject: [Gen-art] Re: Gen-ART HIP drafts (base and esp) review

From: Petri Jokela <[email-masked]>
Date: Wed, 20 Dec 2006 11:14:26 +0200

Hello David,

thanks for the review! I have made some editions to the drafts and 
include the most important changes below.

Current versions of both drafts (marked with pre191206) are available at

http://hip4inter.net/drafts.php

with diffs to previous versions.

BR, Petri

[email-masked] wrote:
> <draft-ietf-hip-base-06.txt>
> 
> Section 5.1.3 indicates a reliance of HIP on IP fragmentation.  IP
> fragmentation is becoming increasingly troublesome, so this will
> be a problem in practice.  The corresponding reliance on IP
> fragmentation for IKE is a known cause of problems with certificates,
> as the size of some certificates is a common cause of IP fragmentation
> with UDP/IP.  At a minimum, this section should carry a strong
> recommendation that the separately-specified HIP support for
> certificates support Hash & URL certificate formats in order to
> avoid certificate sizes that will cause IP fragmentation.  Certificates
> are a major cause of IP fragmentation in IKE, particularly when chains
> are involved.

I added a paragraph, similar to the one in IKE:

    Because certificate chains can cause the packet to be fragmented and
    fragmentation can open implementation to denial of service attacks
    [37], it is strongly recommended that the separate document
    specifying the certificate usage in HIP Base Exchange defines the
    usage of "Hash and URL" formats rather than including certificates in
    exchanges.  With this, most problems related to DoS attacks with
    fragmentation can be avoided.

> The text in Section 5.3.2 on Diffie-Hellman value reuse could use
> some clarification.  The underlying issue is that the HIP exchange
> does not use  the nonces that IKE and IKEv2 use, which makes DH
> value reuse significantly more dangerous.  The current text says
> that DH values SHOULD not be reused unless the system is under attack
> (I1 storms), in which case they MAY be reused.  This appears to drop
> the level of security in response to an attack, which may not be the
> best course of action.  I don't want to say that HIP ought to use
> IKE-like nonces, but this text appears to need some more thought.
> 
> Section 5.3.3 doesn't discuss DH value reuse.  It should.

We discussed this and decided to add a note about the issue and a strong 
recommendation that in the future versions of HIP this is revisited:

    Re-using D-H value can open security holes.  When future
    versions of HIP are specified, it is strongly recommended
    that these possible security issues are investigated.

> Section 5.3.6 and Section 6.13 need more precision on the sorts of
> "state information changes" that SHOULD NOT be made as a consequence
> of receiving a NOTIFY packet.

The text is unclear and it should refer to changes in HIP State machine, 
not to other state information. The text has been clarified.

> Section 6.5 needs to specify how to calculate the Diffie-Hellman
> Kij value.

Clarification in the text: the Kij is the value is the shared secret 
received as a result of D-H.

> <draft-ietf-hip-esp-04.txt>
> 
> Nit: Section 3.3.5, change "AES" to "AES-CBC" in two places.
> There are AES modes other than CBC defined for use with ESP.

Ok!

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 20 Dec 2006 14:56:17 +0200

Petri,

> We discussed this and decided to add a note about the issue and a  
> strong recommendation that in the future versions of HIP this is  
> revisited:
>

I'd rather say

"Re-using public Diffie-Hellman keys has known security issues.  If a  
future version of this protocol is considered, we strongly recommend  
that these issues are re-considered with due diligence.  Especially,  
the current design allows hosts to become potentially more vulnerable  
to a low-probability problem during attacks than what they are if no  
attack is taking place may; whether this is acceptable or not should  
be reconsidered in the light of experimentation experiences."

or something like that.

What you now write gives the feeling that we say "this is broken.  go  
fix it next time."  while we want to say "what we now do has known  
limitations.  next time, consider if it is worth fixing, based on  
your experience."

--Pekka

---

From: [email-masked]
Date: Wed, 20 Dec 2006 10:13:07 -0500

Pekka and Petri,

In the proposed changes, I don't see a response to this concern:

> >> The current text says
> >> best course of action.

Thanks,
--David

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Wednesday, December 20, 2006 7:56 AM
> To: Petri Jokela
> Cc: Black, David; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: Gen-ART HIP drafts (base and esp) review
> 
> Petri,
>

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 20 Dec 2006 18:59:03 +0200

David,

We tried to address that with Petri's original by proposal:

>> Re-using public Diffie-Hellman keys has known security issues.  If  
>> a future version of this protocol is considered, we strongly  
>> recommend  that these issues are re-considered with due  
>> diligence.  Especially,
>> the current design allows hosts to become potentially more  
>> vulnerable to a low-probability problem during attacks than what  
>> they are if no attack is taking place may; whether this is  
>> acceptable or not should be reconsidered in the light of  
>> experimentation experiences.

Perhaps that should textually bound more strongly to the I1 storm issue?

--Pekka

---

From: [email-masked]
Date: Wed, 20 Dec 2006 15:18:15 -0500

Pekka,

I think this is still essentially saying:
- SHOULD NOT reuse D-H values because doing so is a security
	risk.  (Aside: the risk isn't stated, but I think it's	
	primarily replay, and it should be stated), *but*
- MAY reuse D-H values when under attack.
I'm still looking for a design justification for the "MAY".

If the justification is that denial of service attacks are worse
than replay attacks, then I'm concerned about the replay attacker
who starts with a denial of service attack in order to open up
the window for the replay attack to succeed, which would run
counter to your "low-probability problem during attacks"
assertion.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> >> vulnerable

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 21 Dec 2006 10:22:24 +0200

David,

Just as a reminder of the background, this is the existing text:

   The Diffie-Hellman value is ephemeral, and one value SHOULD be used
   only for one connection.  Once the Responder has received a valid
   response to an R1 packet, that Diffie-Hellman value SHOULD be
   deprecated.  Because it is possible that the Responder has sent the
   same Diffie-Hellman value to different hosts simultaneously in
   corresponding R1 packets also those responses should be accepted.
   However, as a defense against I1 storms, an implementation MAY use
   the same Diffie-Hellman value for a period of time, for example, 15
   minutes.  By using a small number of different puzzles for a given
   Diffie-Hellman value, the R1 packets can be pre-computed and
   delivered as quickly as I1 packets arrive.  A scavenger process
   should clean up unused DHs and puzzles.

I think part of the confusion is in the "MAY use".  If we replace that
with "MAY propose, and re-use if not avoidable,", that will probably
remove some of the contention.

Then, I'd suggest the following text to be added:

   Re-using Diffie-Hellman public keys opens up the potential security
   risks of more than one Initiators ending up with the same keying
   material (due to faulty random number generators), and more than one
   Initiators using the same Responder public key half, thereby leading
   to potentially easier cryptographic attacks and the risk of not  
having
   perfect forward security.

   However, these risks involved in re-using the same key are  
statistical;
   that is, authors are not aware of any mechanism that would allow
   manipulation of the protocol so that the risk of the re-use of a any
   given Responder Diffie-Hellman public key would differ from the base
   probability.  Consequently, it is RECOMMENDED that implementations
   avoid re-using the same D-H key with multiple Initiators, but
   because the risk is considered statistical and not known to be
   manipulatable, the implementations MAY re-use a key in order to ease
   resource constraint implementations and to increase the probability
   of successful communication with legitimate clients even under an
   I1 storm.  In particular, when it is too expensive to generate enough
   of pre-computed R1 packets to supply each potential Initiator with
   a different Diffie-Hellman key, the Responder MAY send the same
   Diffie-Hellman key to several Initiators, thereby creating the
   possibility of multiple legitimate Initiators ending up using the
   same Responder-side public key.  However, as soon as the Responder
   knows that it will use a particular Diffie-Hellman key, it SHOULD  
stop
   offering it.  This design is aimed to allow resource-constrained
   Responders to offer services under I1 storms and to simultaneously
   make the probability of Diffie-Hellman key re-use both
   statistical and as low as possible.

   If a future version of this protocol is considered, we strongly
   recommend that these issues shall be studied again.  Especially,
   the current design allows hosts to become potentially more vulnerable
   to a statistical, low-probability problem during I1 storm attacks  
than
   what they are if no attack is taking place; whether this is
   acceptable or not should be reconsidered in the light of
   any new experience gained.

Ok?

--Pekka

---

From: [email-masked]
Date: Thu, 21 Dec 2006 12:10:51 -0500

Much better - this contains the explanation of the security
risks/threats involved.  Thanks, --David 

> Sent: Thursday, December 21, 2006 3:22 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Re: Gen-ART HIP drafts (base and esp) review
> 
> David,
> 
> >>>>>> the level of security in response to an attack, which 
> may not be
> >>> the
> >>>>>> best course of action.
> >>>
> >>> Thanks,
> >>> --David
> >>>