IP Security Maintenance and Extensions (ipsecme)

Tero Kivinen | 4 Apr 2006 14:22

IKEv1 Security Considerations

Russ Housley writes:
> RFC 2409 says:
> 
>     Repeated re-keying using Quick Mode can consume the entropy of the
>     Diffie-Hellman shared secret. Implementors should take note of this
>     fact and set a limit on Quick Mode Exchanges between exponentiations.
>     This memo does not prescribe such a limit.
> 
> What limit do implementors impose?

Usually none.

There are quite a many people who do not really agree on that text. I
do not think entropy really get consumed, but of course the value of
breaking that one Diffie-Hellman increases when more and more keying
material is derived from it.

In most implementations IKE SAs do have lifetime that is around few
hours (from 4-8 hours or so), and using gigabit link with 3DES means
you need to rekey avery few minutes, which would mean that you would
be doing around 50 quick mode exchanges before the IKE SA expires.
The 50 unknown keying materials generated from the same Diffie-Hellman
secret, should yet give any way to crack that Diffie-Hellman itself. 
--

-- 
kivinen <at> safenet-inc.com

headers

Dan Harkins | 13 May 2006 09:22

Re: IKEv1 Security Considerations

  Hi Tero,

  I can't really say I'm too happy with the term "consumed entropy"
either but there is a reason you want to rekey the IKE SA after a
certain number of Quick Mode rekeys.

  You're right that the value of breaking the Diffie-Hellman secret
increases when more keys are derived from it. It also increases when the
information being protected by those keys is high. Regardless though,
you want to rekey the IKE SA after a certain number of Quick Mode
rekeys. Can you articulate a reason why that does not use the words
"consumed" and "entropy"?

  Dan.

> Russ Housley writes:
>> RFC 2409 says:
>>
>>     Repeated re-keying using Quick Mode can consume the entropy of the
>>     Diffie-Hellman shared secret. Implementors should take note of this
>>     fact and set a limit on Quick Mode Exchanges between
>> exponentiations.
>>     This memo does not prescribe such a limit.
>>
>> What limit do implementors impose?
>
> Usually none.
>
> There are quite a many people who do not really agree on that text. I

(Continue reading)

headers

Russ Housley | 4 Apr 2006 17:35

Re: IKEv1 Security Considerations

I agree with your words, but it is probably not worth the effort to 
update this paragraph.

Russ

At 08:22 AM 4/4/2006, Tero Kivinen wrote:
>Russ Housley writes:
> > RFC 2409 says:
> >
> >     Repeated re-keying using Quick Mode can consume the entropy of the
> >     Diffie-Hellman shared secret. Implementors should take note of this
> >     fact and set a limit on Quick Mode Exchanges between exponentiations.
> >     This memo does not prescribe such a limit.
> >
> > What limit do implementors impose?
>
>Usually none.
>
>There are quite a many people who do not really agree on that text. I
>do not think entropy really get consumed, but of course the value of
>breaking that one Diffie-Hellman increases when more and more keying
>material is derived from it.
>
>In most implementations IKE SAs do have lifetime that is around few
>hours (from 4-8 hours or so), and using gigabit link with 3DES means
>you need to rekey avery few minutes, which would mean that you would
>be doing around 50 quick mode exchanges before the IKE SA expires.
>The 50 unknown keying materials generated from the same Diffie-Hellman
>secret, should yet give any way to crack that Diffie-Hellman itself.
>--

(Continue reading)

headers

Derrell Piper | 5 Apr 2006 23:58

Re: IKEv1 Security Considerations

I can't imagine it could be.  I mean, it's completely dependent on  
the size of your pipe.  What would be the right answer for a 1.5Mb  
branch office isn't right for a gigabit ISP.  Practically speaking,  
expiring your IKE SAs every 4-8 hours is a reasonable built-in  
default, which is what most vendors are doing and nearly every  
implementation also lets you configure that limit anyway.  So I don't  
see that there's a problem we need to solve by amending the RFC even  
if we could agree on what that number should be...  

Derrell

On Apr 4, 2006, at 8:35 AM, Russ Housley wrote:

> I agree with your words, but it is probably not worth the effort to  
> update this paragraph.