key change for TCP-MD5

On Thu, 22 Jun 2006 13:18:35 -0400, Ron Bonica
<rbonicajuniper.net> wrote:

> Steve,
> 
> In Section 1 of your draft, you say:
> 
>    "The proper solution involves some sort of key
management protocol.
>    Apart from the complexity of such things, RFC 2385
was not written
>    with key changes in mind.  In particular, there is
no KeyID field in
>    the option, which means that even a key management
protocol would run
>    into the same problem.
> 
>    Fortunately, a heuristic permits key change despite
this protocol
>    deficiency."
> 
> 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.  That is especially problematic for
the interISP
case.

We both agree that key change is (a) necessary, and (b) very
difficult
with 2385.  The longer-term issue is where
"there" his, and that's what
your draft addresses; my draft is about how to get from
"here" to "there".

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

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.