Re: [tcpm] question about TCP-AO and rekeying

[Joe Touch <[e-mail]>]

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



Eric Rescorla wrote:
> At Sat, 06 Jun 2009 11:46:11 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi, all,
>>
>> One open issue remaining is how to express what was formerly a database
>> with a particular structure (TAPD, previously TSAD) in ways that impact
>> rekeying and possibly future master key management protocols. We decided
>> at the last meeting in SFO to do as follows:
>>
>> 	- require that each segment match only one key
>> 		- segments for established connections must match
>> 		only one connection key
>> 		- segments for new connections (SYNs) must match
>> 		only one master key
>>
>> Connection keys never overlap; there would never be two connection keys
>> with the same keyID and socket pair. The open issue focuses on master
>> keys, which would more likely be specified with wildcards, masks, or
>> ranges, esp. for remote port numbers, but also potentially for addresses
>> or local port numbers. This issue is particularly relevant for rekeying
>> - - adding new master keys that would result in new connection keys being
>> derived for existing connections - and how an endpoint would be able to
>> ensure uniqueness as above.
>>
>> Do we need additional constraints to ensure that master key descriptions
>> never overlap?
>>
>> As review, the previous description of keys as a database also implied,
>> by its structure, constraints on wildcards/masks/ranges. Each TAPD entry
>> was:
>>
>>     a socket pair descriptor
>>         which may include wildcards or masks
>>
>>     one or more MKTs, each of which includes:
>>         sendID
>>         recvID
>>         crypto info:
>>             master key
>>             MAC info
>>             KDF info
>>
>> The TAPD was defined so that a segment matched at most one socket pair
>> descriptor, and that MKTs within that descriptor had distinct sendIDs
>> and recvIDs.
>>
>> If we remove that data structure, it would most obviously be replaced
>> with MKTs with their own socket descriptors, i.e.:
>>
>>     MKT
>>         socket pair descriptor (may include wildcards/masks)
>>         sendID
>>         recvID
>>         crypto info
>>
>> The question that remains is whether MKTs that match a segment all have
>> identical socket pair descriptors, even down to their
>> wildcards/ranges/masks (which was previously required). If
>> not, then how do we ensure that MKTs don't interfere?
> 
> I don't understand why this is a problem. The invariant that
> the system needs to enforce is that for any given packet 
> there be at most one valid MKT with a given key-id, right?

KeyID doesn't come into play for outgoing packets, so we can ignore that.

However, the invariant is twofold:

	a) for a given packet, only one MKT applies

	b) for two endpoints with multiple MKTs,
	the *same* MKT applies.

The second invariant requires that either:

	a) no two MKTs have patterns that overlap

	b) MKTs are ordered identically on the two endpoints

If two endpoints solve this differently, a KMP could try to install the
same keys on the two ends and fail, either because one side would refuse
a new key (as overlapping), or because the two sides vary in how they
order the keys.

> There are a number of ways to enforce this, including:
> 
> 1. Having some kind of database.
> 2. Tying MKTs to sockets directly at the time of instantiation
>    (including half-open sockets).

We need to ensure that both sides pick the same MKT. That needs to
happen at connection establishment (could be during socket
instantiation), but ALSO needs to happen for re-keying, FWIW. That
doesn't change the nature of the problem.

>> If we throw our hands up and say this is "implementation detail", then
>> IMO we could be hobbling any KMP, since there would be no common data
>> for the KMP to coordinate.
> 
> I don't see this. Obviously, any KMP will need some model for
> how it thinks about keys and any particular implementation of
> a KMP will need to interact with the system on which it is
> implemented in order to match that model to the system's
> implementation, but I don't see how that's a problem. It's
> not like we're defining a C API for the KMP implementations
> to call.

If we don't specify some level of commonality, we can't expect to ever
define such an API.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko3ogIACgkQE5f5cImnZrtDoACgqfBUxsXk52jQsNa4AiDeXdOm
KCIAoLphIibqh3KVm2cm6QIsZTOn2bvS
=JuFx
-----END PGP SIGNATURE-----