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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

I'll kick off discussion on this point on the list.

IMO, this mechanism is not viable for TCP-AO; it requires generating
(and consuming) TCP segments that a native TCP would not generate. I was
under the assumption that our design space was as close to TCP MD5 as
possible, i.e., augment existing segments with a new option, but neither
generate nor consume new segments.

The goal appears to be synchronization of the use of new keys. It seems
like this can be achieved operationally, e.g., as follows:

	both sides start with master key A

	both sides insert master key A with KeyID=5

	both sides connect as expected

To enable a rapid synchronization of the next key:

	both sides also reinsert master key A with KeyID=6

At this point, either KeyID=5 or KeyID=6 will work, but both sides use
KeyID=5 (by configuration).

Now let's assume we want to add a new key for that connection, but also
to coordinate its use.

	both sides receive master key B (out-of-band)

	both sides insert master key B with KeyID=7

Either side, upon inserting master key B, starts using KeyID=6. Note
that there is no loss of packets, because 6 was there back when 5 was.

Both sides monitor the keys being received; when keyid=6 is received,
then they can start using KeyID=7.

I.e., this can be done entirely with an external KMS local to each
endpoint, without requiring the KMS's to communicate. I.e., this is
automated, but doesn't require a protocol.

To some extent, this restores some of the intent of Bonica's "K" bit,
but there's no need for an explicit bit, and there's no limit to how
quickly the keyID changes happen (i.e., no need to sync when the bit
needs to be cleared or for how long).

We can put this into the doc, but IMO, it's not necessary at all. It's
completely isolated to the KMS anyway. I had already updated the API to
be able to return samples of the received KeyIDs, FWIW...

Joe

Gregory M. Lebovitz wrote:
> 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 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl/fdsACgkQE5f5cImnZrtW8wCgv7w7hbUsemoVuIMbUzjKqft8
h7gAoJd0qWqDxMceS+geMpxvMC4bbOjn
=vRME
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm