Re: [tcpm] TCP-AO: Text for New_Key Process

Folks,
resend...

Neither I nor Joe have received ANY feedback on this New_Key process. 
Can people pls do a quick review and reply to me, Joe, and list with 
comments? Joe is trying to get a next version out.

Many thanks,
Gregory.

At 01:18 AM 12/19/2008, Gregory M. Lebovitz wrote:
>Hey Joe, and all.
>Below is pasted my first crack at the text for the New_Key Process. 
>All input welcome.
>Gregory
>
>==New_Key Process:
>
>[Suggest you place text about new_key at the end of section 6 in -02]
>
>One big difference between TCP-AO and TCP MD5 is that TCP-AO allows 
>for the change of a TSAD entry -- and thus the corresponding change 
>of a conn_key -- during a connection, without having to drop the 
>connection. This allows for an HMAC algorithm or TSAD_key change 
>without a connection loss. This behavior is very beneficial for the 
>optimal operation of applications with long lived connections, such 
>as BGP. The process of moving from one key to another is called "New_Key".
>
>X.1  New_Key Design Goals
>The following are the design goals of the New_Key process:
>
>  - Both sides will move to the new TSAD entry as fast as possible, 
> assuming both peers are configured with the new TSAD entry at 
> (almost) the same time. This provides the security benefit of being 
> able to move immediately off a key believed to be compromised to a 
> newly defined key.
>
>  - Support a potentially long time lag between when each peer is 
> configured with the new TSAD entry. This time could be as long as 
> two or three weeks, depending on maintenance processes and change 
> windows for both sides.
>
>  - Impact the operation and performance of the application using 
> TCP as little as possible. Cause zero, or very little, application 
> data loss or delay.
>
>  - Modify the TCP stack itself as little as possible.
>
>  - Ensure that neither side transitions completely to the new TSAD 
> entry prematurely, before the other peer has the new TSAD entry and 
> is ready to use the new TSAD entry.
>
>  - Ensure that neither side erases an old TSAD entry prematurely. 
> Implementations will hold both the old and new TSAD entries in 
> memory long enough to employ the new TSAD entry as soon as 
> possible, while still being able to properly process any straggler, 
> out-of-order segments that might arrive having been processed with 
> the old TSAD entry, even after the new TSAD entry is already in use 
> by both sides.
>
>  - Avoid moving to the use of a new TSAD entry prematurely, 
> i.e.  before the other peer is prepared to use the new TSAD entry.
>
>
>X.2 Use Cases Supported
>There are two main cases that New_Key must address. The first is the 
>case where a new TSAD entry (KeyID, MAC type, key length, TSAD_key; 
>see section 6) is configured onto both peers during a connection's 
>life. The TSAD entry may have arrived into the peers' states either 
>by manual configuration, or by some automated key management 
>exchange. Regardless the method, a new TSAD entry is installed into 
>each peers' respective state while the previous TSAD entry is already in use.
>
>[NOTE:  There is an assumption being made here that at some point in 
>the future, when a key management protocol has been defined for 
>TCP-AO, that mechanism will leverage the conn_key derivation 
>mechanism described here in TCP-AO. This means that instead of 
>negotiating ISN's and conn_keys directly, the key management 
>protocol will simply negotiate a TSAD entry, and TCP-AO will use 
>that TSAD entry according to this specification to derive its conn_keys.]
>
>The second use case involves a chain of pre-configured TSAD entries. 
>In this case, the two sides choose and exchange out-of-band a series 
>of TSAD entries to be used over time. Each TSAD entry will also have 
>the time at which the key will begin to be actually used to 
>authenticate segments, and how long the key is to be used. This 
>information is all exchanged out-of-band, and then configured into 
>each device respectively. The chains may be quite long, like 64 or 
>128 entries. The TSAD entries, the order of use, and start times, 
>must all match on both sides. The TSAD entries are then used in 
>sequential order. In this use case, the new TSAD entry is known on 
>both sides well ahead of the actual New_Key event. The key chain 
>mechanism provides a way to limit the lifetime of a particular key's 
>use on the wire. Limiting a key's lifetime protects against a 
>successful brute force guessing attack. The idea is that the 
>connection has already moved on to a new TSAD entry by the time the 
>attacker, who has been working offline to guess the key, succeeds. 
>Key chains do not protect against the termination of an employee who 
>had access to the TSAD entries. In such a case, the entire key chain 
>is assumed to be compromised, and a whole new key chain SHOULD be 
>put into use. The concept of key chains, their benefits and 
>limitations are discussed more thoroughly in the Security 
>Considerations section.
>
>
>X.2 New_Key State Machine
>
>There are three states in the New_Key state machine: SINGLE-TSAD, 
>PROBING, and TSAD-OVERLAP. The states are shown below in Figure X.
>
>X.2.1 SINGLE-TSAD
>
>The SINGLE-TSAD state is the beginning and ending state of the 
>New_Key process. It is the state in which there is one and only one 
>TSAD entry actively in use for both sending and receiving segments. 
>When a new TCP connection using TCP-AO first begins, the New_Key 
>process is initialized to the SINGLE-TSAD state.
>
>For the purpose of this explanation, the starting TSAD used in 
>SINGLE-TSAD state will be called "TSAD-X". The new TSAD entry 
>activated will be referred to as TSAD-Y.
>
> From SINGLE-TSAD it is only possible to move to PROBING state. The 
> move from SINGLE-TSAD to PROBING occurs when a new TSAD entry, 
> TSAD-Y, becomes active. According to the use cases described above, 
> a TSAD-Y becomes active when one of the following events occurs:
>
>   o  It is manually entered and activated on the device for an 
> existing connection
>   o  It is received into state as a result of a key management 
> protocol negotiation
>   o  It is the next TSAD entry in a chain, and it's start time 
> equals the current
>      time
>
>It is most common to transition into SINGLE-TSAD state from either a 
>new connection initialization, or from the TSAD-OVERLAP state (as 
>described in section X.2.3). There also exists one condition under 
>which the state may transition to SINGLE-TSAD from PROBING. This is 
>described at the end of section X.2.2 PROBING.
>
>
>                     +---------------+
>                     |               |
>                     |  SINGLE-TSAD  |
>                     |               |
>                     +------/*-------+
>                          //  \\
>      New TSAD-Y          //      \\
>     Entry Activated  //          \\      Deactivate
>                    //              \\    previous TSAD-X
>                  //                  \\  entry
>                //                      \\
>              //                          \\
>      +-----//-----+                   +----\-----------+
>      |            |                   |                |
>      |  PROBING   +-------------------+  TSAD-OVERLAP  |
>      |            |                   |                |
>      +------------+                   +----------------+
>                       Receive Packet
>                      Processed with
>                       TSAD-Y entry
>
>
>                       Figure X.
>                       New_Key State Machine
>
>
>X.2.2 PROBING
>
>The PROBING state is the second state. The goal of the PROBING state 
>is for a host A, "Alice", to signal to its peer, host B, "Bob", that 
>Alice has TSAD-Y installed and active, and is ready to use it. If 
>Bob does not have TSAD-Y then any segments sent by Alice with 
>TSAD-Y's KeyID will be discarded. Discarded segments may cause 
>retransmission and delays in the application processing. So Alice 
>wants to avoid sending application data with TSAD-Y before she is 
>certain Bob has TSAD-Y. Once Alice has TSAD-Y activated she cannot 
>yet be certain that Bob also has TSAD-Y installed and activated for 
>the following reasons:
>
>   o  Bob's administrator may not have gotten around to installing TSAD-Y yet
>   o  If using a key chain, the clocks on the two devices may be out 
> of sync such
>      that start time for Alice is not the same absolute time as 
> start time for Bob
>
>Therefore, Alice will send a probe segment, processed using the 
>TSAD-Y, to signal to Bob that she is ready to begin using TSAD-Y. 
>She will repeat this probe periodically. (The specifics of this 
>probing mechanism are described below in Section X.3.) Before Bob 
>has TSAD-Y he will not be able to process these probes, and he will 
>discard them.
>
>Once Bob has installed and activated TSAD-Y, Bob will himself 
>transition from SINGLE-TSAD to PROBING state. Bob will then send a 
>probe processed with TSAD-Y to Alice. Further, Bob will be able to 
>successfully process Alice's next probe sent using TSAD-Y.
>
>Once Alice has successfully received and processed a segment from 
>Bob that was sent using TSAD-Y, she transitions immediately to 
>TSAD-OVERLAP state. The time spent in PROBING state may be very 
>short, especially if Bob has already activated TSAD-Y and has just 
>sent a probe. Alice may not have even sent a probe yet. That's okay. 
>Once Alice successfully processes a segment from Bob using TSAD-Y 
>she knows (a) that she has the correct TSAD-Y, that (b) Bob has the 
>correct TSAD-Y, and (c) they are both prepared to begin sending and 
>receiving all following segments with TSAD-Y.
>
>It is only possible to move into PROBING from the SINGLE-TSAD state, 
>as described above in X.2.1. PROBING is distinct from SINGLE-TSAD in 
>that now there exists a second active TSAD, TSAD-Y, along with 
>TSAD-X. In PROBING, only probe segments are sent using TSAD-Y. All 
>other segments are sent using TSAD-X. Most segments received will be 
>processed using TSAD-X. Once the first received segment is 
>successfully processed using TSAD-Y, the state transitions to TSAD-OVERLAP.
>
>TSAD-OVERLAP is the most probable state that will be entered when 
>exiting PROBING.
>
>However, under one unlikely condition the state will transition from 
>PROBING to SINGLE-TSAD. In the case where:
>
>   o  a life-time has been configured for TSAD-X, AND,
>   o  that life-time expires while in PROBING state, AND,
>   o  TSAD-Y is still active, AND,
>   o  no other TSAD has yet been activated, THEN,
>   o  the only active TSAD remaining is TSAD-Y.
>
>Even though Alice has not yet successfully received TSAD-Y segments 
>from Bob, if a life-time is exceeded, the expired TSAD MUST be 
>de-activated in order to follow the configured security policy. This 
>would force the state back to SINGLE-TSAD state, with TSAD-Y being 
>the only activated TSAD entry. This condition -- where TSAD-X 
>expired before segments were received processed by TSAD-Y -- SHOULD 
>be logged, and the administrator alerted. Assuming the security 
>policy mandates the use of TCP-AO on this connection, segments MUST 
>be sent processed with TSAD-Y. Received segments MAY continue to be 
>processed with TSAD-X. However, if Bob does not activate TSAD-Y, 
>then the TCP connection will soon timeout, because Bob will discard 
>the TSAD-Y processed segments he receives.
>
>X.2.3 TSAD-OVERLAP
>
>The TSAD-OVERLAP state is the third state. Like PROBING, both the 
>old TSAD-X and the new TSAD-Y are both activated. The main 
>distinction between PROBING and TSAD-OVERLAP is that in TSAD-OVERLAP 
>the new TSAD, TSAD-Y, is the only one used for sending all segments. 
>In this state, TSAD-X is used only for processing received segments 
>that may arrive with TSAD-X's KeyID. Such straggler segments may 
>arrive because they were sent out onto the wire before the 
>transition from PROBING to TSAD-OVERLAP occurred, and are just now arriving.
>
>Once the state transitions to TSAD-OVERLAP, a counter is initialized 
>to 512. The counter decrements once per second, so TSAD-X will 
>overlap TSAD-Y for just under nine minutes. Upon reaching zero, the 
>prior TSAD, TSAD-X is de-activated. At this point the entire TSAD-X 
>entry, including its conn_keys, MAY be deleted from state. The 
>TSAD-OVERLAP counter MAY be configurable on various implementations.
>
>[Author's Thought: I have no idea if this is the best way to do this 
>timer. I chose seconds because that is how TCP does it's exponential 
>back-off timer for retransmission, the max of which is ~9 minutes, 
>from what I read in Stevens, Ch 21.  TCP gurus are welcome to refine 
>the overlap timer mechanism based on practical experience]
>
>Once TSAD-X is deactivated, the state transitions to SINGLE-TSAD. At 
>this point, TSAD-Y is the one and only active TSAD entry for both 
>sending and receiving segments.
>
>
>X.3 Probe Mechanism
>
>This section specifies the probe mechanism used in PROBING state 
>(section X.2.2).
>
>The probe is a single TCP segment sent with:
>
>   o  the TCP-AO option using TSAD-Y, AND
>   o  any other tcp options present (per section 3.2, point 4), AND
>   o  with no TCP data, AND
>   o  marked with a sequence number unmistakably smaller than the currently
>      appropriate sequence number. Precisely, where the current 
> sequence number that would otherwise be used is "S", and the probe 
> segment's sequence number is "P", P is 1024 less than S, or
>
>           P = S - 1024
>
>   [Question 1: TCP guru's, is 1024 the best number?]
>
>   [Question 2: given the empty TCP data, will we need to add 
> padding here to meet the minimum 64 byte IP packet size?]
>
>The probe is crafted so that no real application data will be lost 
>if the probe fails. This protects the performance of the application 
>being authenticated in TCP. The probe is transmitted with an old, 
>stale sequence number so that if the receiver, Bob, is unable to 
>process the probe, and discards it, there will be no perceived skip 
>in the proper sequence flow, and no retransmission required.
>
>Alice starts a standard exponential back-off timer for transmitting 
>the next probe(s). If no segment has been received with TSAD-Y, then 
>the next probe is sent 1.5 seconds later. After this the timeout 
>value is doubled for each following probe, with an upper limit of 64 
>seconds; i.e. at 3, 6, 12, 24, 48, 64, 64, 64, etc. seconds apart. 
>If at any point a segment is received that was crafted using TSAD-Y, 
>then the timer is terminated, and state is transitioned to TSAD-OVERLAP.
>
>Bob receives the probe segment, and responds in one of two ways.
>
>   (1)  IF Bob has NOT activated TSAD-Y, THEN
>
>        Bob will not recognize the KeyID in the probe segment, and 
> will silently discard the segment. Since the segment has a stale 
> sequence number, absolutely no interruption occurs to the application flow.
>
>   (2)  IF Bob HAS activated TSAD-Y, THEN
>
>        Bob will recognize the KeyID in the probe, and process the 
> segment using TSAD-Y. Assume this is the first segment received 
> with TSAD-Y; when the authentication verification processes 
> correctly Bob will state transition to TSAD-OVERLAP state. 
> Henceforth Bob will transmit all segments using only TSAD-Y. Bob's 
> TCP stack then parses the segment and reads the stale sequence 
> number. TCP responds naturally with an ACK. That ACK will naturally 
> contain the sequence number of the last received data segment prior 
> to the segment with the stale sequence number, the probe. That ACK 
> is processed using TSAD-Y, and transmitted. Thus, zero interruption 
> to the normal application flow occurs as a result of the probe segment.
>
>Once Alice receives either (a) a TSAD-Y processed ACK to her probe, 
>or (b) a TSAD-Y processed probe from Bob, she transitions to TSAD-OVERLAP.
>
>
>+++++++++++++++++++++++
>IETF-related email from
>Gregory M. Lebovitz
>Juniper Networks
>g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m