ietf
[Top] [All Lists]

Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)

2006-10-02 15:30:32
From my perspective, this draft sounds a lot like what Ran and I wrote for RIP key rollover a long time ago, but it is stated in simpler language. I like it from that perspective, and would suggest that it be generalized away from being specific to TCP-MD5, and made available to any such procedure (including IPSEC and others) that might include it by reference.

I would suggest that a key in the list actually has two timestamps (virtual or actual) associated with it - a point in time where the sender should start using it, and a point in time at which the key should be deleted from the list (eg neither send nor accept). The biggest problem I see in the algorithm as stated is that only one key is ever in use - when the sender starts sending the new key, it stops using the old key, and if the other guy hasn't been configured with it yet (as Iljitsch supposes) the connection immediately goes plop. What one wants to happen is more like the following.

Consider two systems interconnected by some protocol - an IPSEC SA, TCP, whatever. Let's call them Alice and Bob, and assume that all statements made about Alice and Bob are true of Bob and Alice - basic commutivity.

Alice has a list of keys consisting of some number of tuples - a key, a start date/time, and a delete date/time. Alice considers a key in the list to be "active" if its start time is in the past and its "delete" time is in the future. Bob has a similar list. In implementation, Alice may have one master list or separate lists per authorized peer - not my problem.

Whenever Alice sends a message (a TCP segment, a datagram within a IPSEC SA, whatever) to Bob, she sends the message as many times as necessary to use all active keys. In other words, if there are two active keys and she is using them for TCP, she sends the same TCP segment twice, once signed with one key and again signed with the other. One hopes that in the general case there is only one active key, and during a roll-over interval, there are two.

When Bob receives such messages, he checks them against all keys deemed to be active, and discards those that he doesn't accept.

In the general case, there is only one active key and they agree on it, so things work. During key rollover, there is presumably a period during which only Alice believes that there are two active keys, a period in which only Bob believes there are two active keys, and a period during which both Alice and Bob believe that there are two keys active. While Alice believes that there are two keys active, she will duplicate every relevant messages she sends. For the purposes to which we put TCP-MD5, one would expect that this should not be a heavy load, in either computation or bandwidth. Following your MRU algorithm, Bob's workload increases while both believe that there are two active keys, but that goes away when Alice stops sending using the old key.

An optimization could be done in Alice - if Alice believes that there are two active keys and is sending with both the new and the old, and accepts a message using the new key from Bob, she could decide that she no longer needs to send using the old. Stated more generally (N active keys, one of which is "old"), should Bob start using (and therefore Alice start receiving from Bob) an active key other than old key, Alice stops sending using the N-1 other keys and only uses the new key that Bob "selected".

I think the "delete" timer addresses the security issues ("what if Bob never gets it sorted out - should we still trust him?"). The duplicate traffic during the inevitable rollover period in which the two disagree on state addresses the operational issues that Iljitsch raised ("what if Alice starts sending at a time that Bob is unable or unwilling to receive using the new key - I don't want to lose connectivity through a misconfiguration"). The proposed optimization is unnecessary but attractive, especially if one is asking "but what about the duplicate traffic - isn't that a problem?". Traffic duplication can in this way be limited to a few messages in the immediate vicinity of the key rollover event, ideally within an RTT. Imagine both Alice and Bob decided a new key was active simultaneously - to the microsecond. I should think that the next time one of them sent a TCP segment, he/she would send two, the Ack would go back using the new key, and it would be over. More realistically, the duplicate traffic might last for a few seconds, perhaps a few minutes, or (Iljitsch's time zone question) an hour. But one could configure an overlap period of 12 hours, and know that it would be contained to as small an interval as possible.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf