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

[Eric Rescorla <[e-mail]>]

At Fri, 19 Jun 2009 09:26:22 -0700,
Joe Touch wrote:
> 
> -----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.


OK, I fear we're talking past each other.

My claim is that the system must enforce the following invariant:

* There must be only one MKT defined that matches any given set
  of parameters: (s-ip, d-ip, s-port, s-port, key-id).

This includes wildcards and ranges.

Therefore there is never any ambiguity about which MKT a given
packet is associated with. The only ambiguity is which MKTs
an outgoing packet might be protected with, because of priority.
However, those MKTs will always have distinct key-ids so there
is no confusion.

I believe that that corresponds to your choice (a). However,
I don't see either of the issues you raise as problems:

- If you have a more general MKT that matches a connection,
  you can enter a new MKT that is more specific. It merely
  must have a new key-id. This is just a generalization of
  how you update keys with the same level of specificity.

- I'm not concerned about the computational cost at key 
  entry. Checking whether a new MKT has overlap with an
  existing MKT is a linear process in the number of 
  existing MKTs [*]. It's certainly not going to be a 
  problem with the number of keys you can plausibly manually
  enter. I agree that it would be nice if the KMP prevented
  this intentionally, rather than having a check at 
  installation time. 

In any case, I don't really see how we can get away from
doing this kind of checking. Let's say for the sake of
argument that we *never* allowed ranges. I.e., all 
MKTs had to be fully specified or be a wildcard. Even
then you'd need to do a table lookup to verify that
no two MKTs exactly matched each other including key-id.

-Ekr


[*] At worst. You can actually do much better using good
data structures.