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

[Joe Touch <[e-mail]>]

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



Eric Rescorla wrote:
> At Fri, 19 Jun 2009 08:40:26 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Eric Rescorla wrote:
>> ...
>>>> If that's where we put that logic, what happens when we don't have a
>>>> KMP? How do we know that both ends will do the same thing with a set of
>>>> manually entered keys?
>>> It was my understanding that the consensus was that we were not 
>>> going to design a system that attempted to prevent user error.
>> Oh, absolutely, agreed.
>>
>> This is the kind of error where two ends install the keys correctly, but
>> internally the two implementations resolve overlap in different ways, so
>> keying fails.
>>
>>> Given that typographical errors in key entry seem far more likely
>>> than this kind of misconfiguration, if our intent is to prevent
>>> user error, then we should be attacking that first.
>> As above, this isn't a user error issue. This is a case where leaving
>> something to the implementer is what is causing the problem.
> 
> Then I don't understand what you're talking about.
> 
> The user installs two MKTs, one of which covers all ports and
> one of which covers port 521 (randomly chosen). Either of these
> MKTs is valid and either end can use either one to secure
> the connection independently. It doesn't matter what the
> prioritization schemes are on either end.

If we just require that each segment maps to exactly one MKT, then one
end can do this by:

	- first entered, first picked

The other end can do this by:

	- longest match

So both sides are complying with "match only one MKT", but users can
easily install keys on both ends that would still not work.

> If you're saying that the installation of a more specific MKT
> should not only take priority over but actually disable a
> less specific MKT for that port, then I think that's a pretty
> clear bug.

I'm saying that the way in which we resolve overlapping MKTs matters.

a) disallow entry of overlapping MKTs

	this means that valid MKTs for a connection might not
	be able to be entered if there are more general
	keys entered

	this also incurs computation during key entry (manual
	or otherwise); is there a standard efficient alg. for
	determining overlap? Note that we could be talking about
	masks, ranges, etc.

b) allow overlapping MKTs

	this means we need to indicate the resolution mechanism
	i.e., longest match, ordered match, etc.

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

iEYEARECAAYFAko7vC0ACgkQE5f5cImnZrsVWQCdEcynyPinkrPrUjI+UOxxoaD8
QLwAn2y+9mCmQ2yOO/QSC8ReglbQNx6J
=5OEU
-----END PGP SIGNATURE-----