----- Original Message -----
From: "Fred Baker" <fred(_at_)cisco(_dot_)com>
To: "Steven M. Bellovin" <smb(_at_)cs(_dot_)columbia(_dot_)edu>
Cc: "Iljitsch van Beijnum" <iljitsch(_at_)muada(_dot_)com>;
<iesg(_at_)ietf(_dot_)org>;
<ietf(_at_)ietf(_dot_)org>
Sent: Monday, October 02, 2006 3:20 PM
Subject: Re: Last Call: 'Key Change Strategies for TCP-MD5' to
InformationalRFC (draft-bellovin-keyroll2385)
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.
Fred -
I would suggest that a key in the list actually has two timestamps
(virtual or actual)
Depending on how the policy model defines 'virtual timestamps' - they by
that may need more actual data in the 'stamp' itself than a single signed or
secured point in time.
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).
You need one for the creation of the KEY too. You actually want three at
minimum and if the KEY is to be allowed a period of validity sometimes four
time stamps can be useful for specifying that range.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf