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

From: "Bora Akyol" <[email-masked]>
Date: Wed, 1 Feb 2006 11:40:46 -0800

> 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.

DPD will kill the IKE SA if there is a temporary network disruption
while the key change is in progress.

Regardless, the IPSEC key turnover is more robust with respect to
synchronization when compared to TCP-MD5.

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Feb 2006 17:26:31 -0500

>while the key change is in progress.

Good point.

>synchronization when compared to TCP-MD5.

agreed.

Steve

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 02 Feb 2006 09:27:47 -0500

In message <[email-masked]
>while the key change is in progress.

That raises the issue of whether short-timeout DPD makes sense in this 
environment.  I suspect that it does not.  Routers don't change the IP 
address they use for BGP particularly often.  BGP peering associations 
come and go on a scale of weeks, not hours; you're unlikely to recover 
resources you need for another BGP-over-IPsec session.  And outages 
tend not to be permanent; they last until the fiber rangers drive off 
the predatory backhoes.

For that matter, the need for an SA operation to rekey is very 
different for BGP.  This is an authentication key, not a 
confidentiality key; it does an attacker no good to to recover a key 
after it's no longer in use.  

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.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Tony Li <[email-masked]>
Date: Thu, 02 Feb 2006 08:29:52 -0800

> 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.

Tony

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 02 Feb 2006 11:34:58 -0500

>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.

---

From: Brian Weis <[email-masked]>
Date: Mon, 06 Feb 2006 11:19:57 -0800

> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Still, it is true that there is increased risk during the occasional 
change of IKE pre-shared authentication key. There must exist a window 
during which two operational staffs agree to change the key and hope 
that a) they both change the key before the IKE SA lifetime is over, and 
b) that neither BGP router reboots. (The latter case will of course 
bring down the BGP session anyway, but if the IKE authentication keys 
don't match no subsequent BGP session can be setup.)

This is *far* less risky than use of RFC 2385. But a risk still exists, 
which is why I said earlier that the operators needed to evaluate the 
risk and decide whether they could live with it or not. (Thanks, Shane 
for sharing your view that the risk *would* be acceptable.)

Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Paul Jakma <[email-masked]>
Date: Mon, 6 Feb 2006 20:01:56 +0000 (GMT)

On Mon, 6 Feb 2006, Brian Weis wrote:

> Still, it is true that there is increased risk during the 
> occasional change of IKE pre-shared authentication key.

With IPSec and IKE the keys could well be public-key certificates 
valid for year(s)[1]. Expiry would be known *well* in advance and 
could be done well in advance as part of planned maintenance, without 
co-ordination.

Ie worrying about PSK updates is, imho, possibly short-sighted.

1. Some RIRs already operate as PKI cert. authorities. Whatever form 
of secure BGP is adopted likely will just further reinforce the need 
for RIRs to operate as in such a role.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Q:	What do Winnie the Pooh and John the Baptist have in common?
A:	The same middle name.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 07 Feb 2006 07:05:46 +1100

>during which two operational staffs agree to change the key and hope that 
>a) they both change the key before the IKE SA lifetime is over, and b) 
>that neither BGP router reboots. (The latter case will of course bring 
>down the BGP session anyway, but if the IKE authentication keys don't 
>match no subsequent BGP session can be setup.)

Could you clarify this last statement ?

i.e. Under what conditions would a subsequent BGP session start up?

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Feb 2006 10:49:09 -0500

At 8:01 PM +0000 2/6/06, Paul Jakma wrote:
>could be done well in advance as part of planned maintenance, 
>without co-ordination.

I'm all in favor of that approach, although it does imply the 
capability to process certs.

>for RIRs to operate as in such a role.

SIDR has a charter item that talks about certs being issued to for 
authorization and authentication in support of routing security. 
Certs issued by RIRs (and by ISPs), to attest to address space and AS 
number holdings are consistent with these charter items.

In discussions on the list, use of the cert extensions defined in RFC 
3779 was cited as a likely starting point for this infrastructure. 
This would provide an ISP with the ability to issue certs to its 
routers, identifying them as being affiliated with the AS number(s) 
of the ISP. That seems to be a reasonable basis for deciding whether 
a router is an appropriate peer. So, yes, I think we may head down a 
path that would provide certs suitable for use with IPsec in securing 
(e)BGP sessions.

Steve

---

From: Brian Weis <[email-masked]>
Date: Thu, 09 Feb 2006 21:01:25 -0800

Paul Jakma wrote:
>> change of IKE pre-shared authentication key.
> 
> 
> With IPSec and IKE the keys could well be public-key certificates valid 
> for year(s)[1]. Expiry would be known *well* in advance and could be 
> done well in advance as part of planned maintenance, without co-ordination.
> 

It's not being short-sighted, it's being pragmatic. You're absolutely 
correct about public-key certificates conveniently solving the key 
rollover problem. But to use public-key certificates exclusively, an ISP 
must agree to share a Certificate Authority with every one of its peers 
(i.e., competitors) as well as its customers.  And practically speaking, 
those CAs will need to be arranged in a PKI.

There is no such PKI today. (RIR CAs aren't building certificates for 
*routers*). As Steve Kent points out, there may in the future be a large 
PKI structure for routing which could provide router certificates. But 
large PKIs don't get put in place quickly. Pre-shared keys are are a 
necessity for some time to come.

Brian

> 1. Some RIRs already operate as PKI cert. authorities. Whatever form of 
> secure BGP is adopted likely will just further reinforce the need for 
> RIRs to operate as in such a role.
> 
> regards,

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Feb 2006 13:46:51 -0800

On Feb 9, 2006, at 9:01 PM, Brian Weis wrote:

> It's not being short-sighted, it's being pragmatic. You're  
> absolutely correct about public-key certificates conveniently  
> solving the key rollover problem. But to use public-key  
> certificates exclusively, an ISP must agree to share a Certificate  
> Authority with every one of its peers (i.e., competitors) as well  
> as its customers.  And practically speaking, those CAs will need to  
> be arranged in a PKI.
>
> There is no such PKI today. (RIR CAs aren't building certificates  
> for *routers*). As Steve Kent points out, there may in the future  
> be a large PKI structure for routing which could provide router  
> certificates. But large PKIs don't get put in place quickly. Pre- 
> shared keys are are a necessity for some time to come.

Pre-shared keys are much easier to deal with in many cases - if I  
turn up a new router it is much easier to just paste a pre-shared key  
into the config than to go to my CA, generate a key and cert request,  
sign the cert request, copy the new cert and key, etc. This is  
especially true for smaller, less technical companies - I think that  
you will find that the majority of IPSec deployed in smaller  
companies use pre-shared keys because of their ease of use.

Changing a pre-shared key (or a bunch of pre-shared keys) is also  
much easier than having to change all of your certs if the person  
running your CA leaves the company (or your CA gets compromised).

Don't get me wrong, I am not denying the increased security and (in  
most cases) increased ease of management of certificates, just that  
pre-shared keys have their place too.

Warren

>
> Brian
>
>> 1. Some RIRs already operate as PKI cert. authorities. Whatever  
>> form of secure BGP is adopted likely will just further reinforce  
>> the need for RIRs to operate as in such a role.
>> regards,
>
>
> -- 
> Brian Weis

--
Some people are like Slinkies......Not really good for anything but  
they still bring a smile to your face when you push them down the  
stairs.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 14 Feb 2006 06:33:00 +0000 (GMT)

On Thu, 9 Feb 2006, Brian Weis wrote:

> Authority with every one of its peers

Right.

> for *routers*).

Nor would they in the future, one strongly hopes.

> As Steve Kent points out, there may in the future 
> certificates. But large PKIs don't get put in place quickly.

Indeed. And despite the lack of any IDR security solution involving 
PKI, some RIRs still seem to be investigating it and either are 
experimenting with PKI infrastructure related directly to routing, or 
gaining operational PKI experience in other ways.

It's a question for the operational community more than anything, but 
I have a suspicion they'd welcome something better than statically 
keyed transport security. But:

> Pre-shared keys are are a necessity for some time to come.

Yes, agreed. And as already stated an IKE implementation can allow 
for PSK changeover too, with just a mild amount of care. Failing 
that, the care can still potentially be applied administratively.

IMHO we would do our "users" a huge favour to adopt IPSec as 
transport security for BGP, agreeing on a small set of required 
'profiles' (as someone suggested), and then deprecate TCP-MD5.

We'd gain for operators a wider choice in additional authentication 
methods, all far more manageable than shared-keys (e.g. RADIUS and 
GSS methods for within a single administrative domain, maybe even 
IXes).

It'd also allow the RIRs to figure out details of and gain 
operational PKI experience of cross-domain authentication while work 
in SIDR would be (presumably) ongoing. Which potentially could be 
useful to SIDR itself.

regards,
It's stuck in the Web.