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

[Brian Weis <[e-mail]>]

Hi Joe,

On Jan 29, 2009, at 4:24 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Brian Weis wrote:
> ...
>> Joe mentioned a third approach. Summarizing the discussion, rather  
>> than
>> "probe" with segments that the TCP stack would already send, his
>> approach would add a signal to TCP segments noting that a new  
>> master key
>> was available. This helps a peer implementation make the decision to
>> move to a new key (i.e., the problem we're trying to solve) without
>> actually using the new key. This can break the deadlock without the
>> actual use of the new key.
>>
>> I favor this approach, but not the mechanism. Joe's idea consumes one
>> extra KeyID value for each real KeyID. The example given was to  
>> allocate
>> both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the  
>> presence of a
>> new key comes by moving to KeyID 6. But overloading KeyIDs is not  
>> ideal
>> -- in particular, recall that KeyID values are chosen by some  
>> external
>> entity (e.g., a human or some automated key management system). I'm
>> really not confident that a human will always appreciate that they  
>> can
>> only configure "odd" KeyID values, for example. Furthermore, in  
>> order to
>> guarantee interoperability I believe that this would have to be
>> described in TCP-AO. We would want to avoid different implementations
>> have different conventions, and not be able to set the same  
>> KeyIDs! This
>> could be a fair amount of addition to TCP-AO.
>>
>> A better approach is to steal a bit from the KeyID field, and give it
>> the meaning "I have a new KeyID".
>
> The problem with this sort of bit is that we would need to know  
> when it
> is set and when it is clearable; this requires coordinating state
> between the endpoints.

Each TCP peer sets the bit independently, at such time as a new KeyID  
is provided to the local system that matches policy for an existing  
TCP session. I.e., the manual key management logic or automated key  
management system.

The station clears the bit when it begins transmitting with a new  
KeyID. It begins transmitting with the new KeyID because it observes  
the peer using the new KeyID (as described earlier in this thread).

> The flag has meaning only in the context of a particular keyID,  
> which is
> why it is equivalent to using a new keyID value. Further, using keyIDs
> allows the user/KMS/etc to have a variety of ways to pick new keys.
> E.g., if there are one of two possible future keys:
>
> 	key A = keyID 9
> 	key A = keyID 10
> 	key A = keyID 11
>
> 	keyB = keyID 12
> 	keyB = keyID 13
>
> Use keyID=9 for the 'old key' with no new changes pending. Use  
> keyID=11
> to signal use of key B, and use keyID=12 to signal use of keyID=13.
> There are other things that keyIDs can be used to coordinate - and  
> this
> is exactly why it's not useful to carve bits out for specific meaning.
> The meaning should be determined by the user/KMS.

Recall that TCP-AO is meant for BGP and LDP. Neither one needs much  
more than an "old key" and "new key" per peer. Going to the extent  
you describe here is way overkill. I know you don't like defining  
bits in a header, but sometimes they solve a simple problem in a  
straightforward way.

If there's really an application that needs what you describe above,  
it will be complicated enough that it will need automated KMS, and  
that KMS can instruct TCP-AO exactly which key it wants to be used  
using a local mechanism.

Brian

> Joe
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmCSLUACgkQE5f5cImnZrs4QwCfdOq2iH4mXHVxlTmQETSBdLQD
> leEAn0GNipkeF66Et5lmaswnZ3+fQPTs
> =yjNn
> -----END PGP SIGNATURE-----

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm