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

[Joe Touch <[e-mail]>]

-----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.

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.

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-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm