[Sidr] Transport security

[Iljitsch van Beijnum <[e-mail]>]

On 3-jul-2006, at 23:56, Geoff Huston wrote:

>  3) Transport Security

>     Rekeying the TCP MD5 Option (Steve Bellovin)            20 minutes

>     "Key Change Strategies for TCP-MD5"
>     draft-bellovin-keyroll2385-00.txt
>     http://www.ietf.org/internet-drafts/draft-bellovin- 
> keyroll2385-00.txt

>     A New TCP Authentication Option (Ron Bonica)            20 minutes

>     "Authentication for TCP-based Routing and Management Protocols"
>     draft-bonica-tcp-auth-04.txt
>     http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt

>     Key Selection for TCP Authentication (Brian Weiss)      20 minutes

>     "Automated key selection extension for the TCP Authentication  
> Option"
>     draft-weis-tcp-auth-auto-ks-01.txt
>     http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto- 
> ks-01.txt

Three new drafts trying to improve on RFC 2385! There are some good  
ideas in there, but I see major problems.

draft-bonica-tcp-auth-04.txt:

    However, TCP implementations MAY omit TCP Options from the MAC
    calculation.  When implementation do so, they MUST set the T-bit in
    the TCP Enhanced Authentication Option.  See Section 9 of this
    document for details.

Huh? Why would this be necessary or useful? Seems to me this only  
adds unnecessary complexity.

Using identifiers to identify MAC keys seems like a good idea, but it  
doesn't preclude two sides from entering different keys, and it only  
adds more stuff that must be agreed upon. To avoid these problems, I  
suggest using a hash of the key as the key id. Such a hash would be  
too long to include in a TCP option, but I don't think this is too  
much of a problem: rather than include the key id in every segment,  
implementations can agree on the key that's used in-band.

draft-weis-tcp-auth-auto-ks-01.txt:

This draft can use some more spelling and grammar checking. I also  
find the draft hard to follow. I'm not sure whether this is because  
of my relative unfamiliarity with the matters discussed, the frequent  
references to things defined elsewhere or because of poor organization.

    Using an additional four TCP option bytes for a sequence number
    dedicated to the MAC option is required in order to satisfy the
    cryptographic requirement of unique nonces.  No other value in a TCP
    packet is guaranteed to be unique.  At first glance, the TCP  
Sequence
    Number would appear to be suitable.  However, the TCP Sequence  
Number
    can wrap, after which it increments back through the same sequence
    number space.

Yes, after transmitting 4 GB worth of data... TCP already has a  
window system that makes sure only part of the sequence space is  
acceptable at any given time so it would be relatively simple to look  
at the TCP sequence number as a 64 bit or even longer value and keep  
the upper bits in sync with the other side when the lower 32 bits  
wrap with no need to actually transmit the upper bits.

Is it worth all this complexity to avoid having to use the same  
actual MAC key for prolonged periods but rather use different MAC  
keys based on the same underlying key? In my not cryptographically  
trained opinion this is only the case when the MAC algorithm is  
significantly weaker than the encryption algorithm used to exchange  
new MAC keys. And _that_ should only be necessary when the encryption  
algorithm can't be used to generate a MAC or uses too much processing  
time.

draft-bellovin-keyroll2385-00.txt:

I have a big problem the notion of blindly switching to a new key at  
a predetermined time. If one side is unable to enter the key before  
that time, or one side enters the key incorrectly, the session will  
break at the moment that the switch to the new key happens. Since  
this happens some time _after_ both sides (are supposed to) have  
entered the new key, operators aren't actively monitoring the session  
at that moment, so there will be a delay before the problem can be  
corrected.

I suggedsted this alternative approach on the north american network  
operators mailinglist:

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 (by adding a new BGP message  
to coordinate all of this in-band), 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"

Finally, as someone who works with BGP with MD5 passwords in  
practice, I can tell you that operators in general don't even think  
about changing keys. Yes, coordinating changing a key on both sides  
at the same time is a pain, but coordinating changing a key PERIOD is  
almost as big a pain because even ASes that aren't very big can  
easily have 100 peers or more and only the middle sized ones are easy  
to work with, the smaller ones barely have a clue and the larger ones  
have huge bureaucratic NOCs where it's hard to find the right person.  
And of course everything stretches across timezones and there are  
often language barriers. Exchanging the key securely is also a big  
problem. Making key rollover easier isn't going to change all that  
much here, and there is no perception of immediacy anyway.

_______________________________________________
Sidr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sidr