North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: key change for TCP-MD5

  • From: Iljitsch van Beijnum
  • Date: Thu Jun 22 17:45:17 2006 
On 22-jun-2006, at 23:17, Steven M. Bellovin wrote:
Why not correct the protocol deficiency by introducing a new option that
includes a KeyID? Wouldn't that approach provide a more comprehensive
solution to the problem?


That's a much better long-term strategy, though the exact mechanism
still

has to be defined. But it's literally years before that will be
usable,

especially because both ends of a connection need to be upgraded
before it

delivers any benefits.



If you want benefits when only one end is upgraded, your mechanism
for concurrent keys could be used like this:



- the upgraded side installs the new key

- the upgraded side keeps using the old key

- the non-upgraded side installs the new key

- the upgraded side detects that the other side uses the new key and
switches over itself

- the old key is removed from the upgraded side



This way, it all goes down when the non-upgraded side installs the
key: they can immediately see the problem if there is some kind of
issue with the key (for instance someone entered it incorrectly).



It still makes sense to add stuff that allows both ends to manage the
key rollover when they're both upgraded, since in that case something
like the above won't work. I think something like this would work well:



- announce key rollover capability at session connect

- when a new key is configured, send a hash of it to the other side

- other side doesn't have the key yet so says "reject"

- other side is also configured with the new key, sends a hash

- first side sees hashes match, starts sending with the new key and
says "accept"



Bonus points: when no key is configured, one of the routers generates
one at session start and sends it over in the clear. This protects
equally well against session reset attacks as a preconfigured key,
but obviously it can be sniffed by someone with access to the
infrastructure.




We both agree that key change is (a) necessary, and (b) very difficult
with 2385.




How often do you think keys should change? I've never had anyone ask
to change keys for about 50 session-years.