Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Feb 2006 14:19:13 -0500

At 10:39 AM -0800 1/30/06, Brian Weis wrote:
>Merike Kaeo wrote:
>>While it is true that pre-shared key roll-over is the same problem 
>>as changing the MD-5 keys used in today's non-IPsec authentication 
>>implementations,  IPsec works a bit differently.  The pre-shared 
>>key is used to originally authenticate the communicating peers 
>>(i.e. the Diffie-Hellman exchange) which then results in a shared 
>>secret.  This shared secret is then used to derive the actual key 
>>used for the MD-5 or SHA-1 authentication used in IPsec.  These 
>>authentication keys are refreshed based on a defined lifetime, 
>>which is the so-called 'automated' key rollover.
>
>The real roll-over problem is that an IPsec system can have only one 
>valid IPsec pre-shared key for each peer, and if the two peers 
>disagree on the value of the current key at any point in time the 
>connection will fail.

The pre-shared key in IPsec (really IKE) is for authentication of an 
IKE SA. The key used to protect traffic (integrity and 
confidentiality) is the result of a ephemeral DH exchange, and is 
thus unique per SA. Also, multiple SAs between a pair of peers is 
supported. If the IKE authentication key is changed at one peer 
during the life of an SA, that does not affect the extent SA. Given 
this more detailed characterization of keying for IPsec, I'm not sure 
what aspects of IPsec keying you were alluding to above.

>What Merike describes above shows that that once authentication 
>completes, there is usually a few hours before it gets used again. 
>Under ordinary circumstances, this gives the operations staffs of 
>the two peers a period of a few hours to synchronize changing the 
>key. But if one peer unexpectedly has a need to re-authenticate when 
>only one side has installed the new key, they won't be able to bring 
>up the BGP session just as in the case when keyed-MD5 authentication 
>keys are different.

AH, this is what you were trying to say! Yes, if one peer changes an 
IKE authentication key AND the other end has not changed to that key, 
AND if the SA needs to be replaced, then creation of the new SA would 
fail. But, you have not described examples of circumstances that 
would trigger the need to create a new SA. If one uses the MD5 
option, as soon as the key is changed at either end, that would seem 
to kill the existing TCP connection, which requires much more careful 
sync of key changes compared to IPsec use. Certainly one needs to be 
careful to avoid an auth key change near the time that an SA would 
timeout, based on the SA lifetime parameters.

>Whether or not this level of risk is acceptable to operators is 
>unknown to me, but in any case it has to be considered.
>
>Brian

Given the different use of the IKE auth key, vs. the traffic keys, 
one also needs to ask what frequency of auth key change is 
appropriate.

Steve

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

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 2 Feb 2006 09:45:09 -0800

With IKEv1, you could rekey the IKE SA without rekeying the IPSEC SAs or
vice versa.

IKEv2 coupled the two together, but I think rekeying the parent SA (IKE)
without
rekeying the children remains possible.

IPSEC SAs are the ones that protect the BGP traffic.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, February 02, 2006 8:35 AM
> To: Tony Li
> Cc: Bora Akyol; [email-masked]
> Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please
> 
> In message <[email-masked]>, Tony Li writes:
> >> My suggestion is to turn off DPD and have a session key lifetime 
> >> measured in days or possibly a small number of weeks, to 
> permit easy 
> >> synchronization of changes to long-term secrets.
> >
> >
> >I'm an IPsec novice, so please pardon the naive question: would this 
> >permit keys to change without breaking the TCP connection?  
> IMHO, this 
> >is an absolute requirement, as we have enough BGP flap out 
> there already.
> >
> 
> If properly implemented, it would.  In fact, it's a major 
> advantage of IPsec over TCP-MD5.  The IPsec header includes 
> an "SPI" -- security parameter index -- that identifies 
> (among other things) the actual key used to protect the 
> packet.  During rekeying (which doesn't need to be too 
> frequent in any event, as I mentioned) more than one SPI is 
> accepted by the receiver; thus, both old and new keys can be accepted.
>