Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure]

[Eric Rescorla <[e-mail]>]

Eric Rescorla wrote:
...
> > The most serious problem is the confusion in the text between
> > three concepts:
> >
> > - Master Keys
> > - Key-Ids
> > - Traffic keys
>
> We can clean up specific cases you can point us to, however the primary
> components are:
>
> 	master key tuples
> 		which are uniquely specified by a TCP socket pair
> 		together with a KeyID; a keyID alone is insufficient
>
> 	traffic keys
> 		which are derived from master key tuples and
> 		instantiated connection information (i.e., from the
> 		TCP TCB)

Fine, but this version of the document repeatedly uses "key-id"
as synechdoche for both of these concepts, which is extraordinarily
confusing. A key-id is a label that points to another object.


> > As an example, S 8.1 reads:
> >
> >    At any given time, a single TCP connection may have multiple KeyIDs
> >    specified for each segment direction (incoming, outgoing). TCP-AO
> >    provides a mechanism to indicate when a new KeyID is ready, to allow
> >
> > It's not that you have multiple key-ids.
>
> In each direction, there can be more than one KeyID inside the TCP
> segment header - at least that's what the ext is supposed to say.

OK, well, I don't think that's what it says, and if so it's even
more confusing. An endpoint may have up to 256 master key tuples
(MKT) specified for each connection. It uses one and advertises
up to one more, but it is quite possible it would accept all 256.

> > Indeed, if we're using
> > keys with different outgoing and incoming key-ids, you will *always*
> > have multiple key-ids. Rather, it's that you have multiple
> > master keys.
>
> Multiple keyIDs within a single connection means multiple master key
> tuples; the text can indicate that as well. That doesn't mean we don't
> have multiple keyIDs, though.

Yes, but that's a representational issue, not a conceptual issue.
Again, it's a mistake to use "key-id" to stand for MKT.


> The basic unit is the master key tuple, as per section 5:
>
> 	master key - i.e., the key string
> 	keyID
> 	MAC algorhtm
>
> Whenever the keyID appears in a segment (sent or received), that tuple
> is used to validate the contents. As per the most recent coordination,
> keyIDs are bidirectional, so there is no send or receive difference.

It was not my understanding that we agreed that key-ids were bidirectional.
Rather, I believe we agreed that MKTs were bidirectional and that
there was a separate key-id in each direction, to address Russ's
concern.


> >                  Master_Key_A                          Master_Key_B
> >                  - Send_Key_Id = 1                     - Send_Key_Id = 5
> >                  - Recv_Key_Id = 2                     - Recv_Key_Id = 6
> >                  - Algorithm = HMAC-SHA1               - Algorithm = AES-CMAC
> >                         |                                       |
> >                         |                                       |
> >        +----------------+-----------------+                     |
> >        |                                  |                     |
> >        v                                  v                     v
> >   Connection 1                        Connection 2          Connection 3
> >   - Send_SYN_key                     - Send_SYN_key        - Send_SYN_key
> >   - Recv_SYN_key                     - Recv_SYN_key        - Recv_SYN_key
> >   - Send_Other_key                   - Send_Other_key      - Send_Other_key
> >   - Send_Other_key                   - Send_Other_key      - Send_Other_key
>
> I like that diagram; here's an update as follows:
> - -- only one KeyID (bidirectional)

As noted above, I think this is not correct.


> - -- changes name of top set to 'master_tuple' (as per Section 5)
> - -- adds the master key, which is the shared secret

Sure.


> > As I've indicated previously, I find the TSAD/TAPD concept incredibly
> > unhelpful. There may well be implementations for which it is natural,
> > but I don't consider it the natural one, and making it in effect a
> > mandatory feature of the protocol seems like an undue burden on
> > implementors. I appreciate that this has been in the document since
> > day one, but if you go back to my review of -00 a year ago, I raised
> > exactly the same concern and we have never taken the discussion to
> > closure or had a consensus call, so I don't consider this in any
> > respect a settled issue. If there are those who feel it's important to
> > keep this design, I would ask the chairs to make this topic an
> > explicit agenda item and I would like agenda time to present an
> > alternative design.
>
> I've explained this in detail to Gregory, but I'm not sure if all of our
> discussion ended up in the text. Here's my recollection of that:
>
> Regardless of what happens outside TCP, when a new connection starts
> (initiating or responding), TCP needs to know whether TCP-AO is required
> or not. We need some way to describe policy for uninstantiated
> connections, and a way to tie that policy to keying material. That's
> what the TAPD is, and why it was thus renamed.

This may or may not be true, but it doesn't follow that we need a
TAPD. As I indicated in a previous message, an alternative design
is to simply attach policy information to an individual *socket*
at the time it's instantiated:

- Sockets instantiated in LISTEN mode would get a list of potential
  remote addresses and MKTs (one could think of this as a mini-TAPD if
  one wanted).
- Sockets instantiated with CONNECT would get a list of MKTs.

If a packet is received for a connection in neither state it would
be assumed that AO did not apply.

My point is *not* that this is necessarily a superior implementation,
but that it's up to the implementor how to do things and that the
TSAD/TAPD concept is over-prescriptive (and confusing). All that
is required of the implementation is that it be unambiguous which
policy is to be applied.



> I'll let the chairs address your concerns about a consensus call.

OK. Chairs: I strongly object to this material remaining as-is without
live WG discussion. How would you like to handle it?


> >    >> When a TAPD entry matches a new connection, TCP-AO is required.
> >    This is true regardless of whether there are any master key tuples
> >    present.
> >
> > Even if we accept the TAPD construct, this is too much requirement
> > on the implementation. Why can't I have a TPAD entry that means
> > "don't do AO".
>
> That's what the text implies. I.e., a TAPD entry without any master key
> tuples is equivalent to one that says "don't do AO". it doesn't make
> sense to have master key tuples and say "don't do AO" at the same time.
>
> I can clarify this if useful, but I thought it was clear enough as-is.
> Can others comment?

But that is not in fact what the later text says, Rather, 9.5 (ii)
says:

          ii. If there is a TAPD entry with zero master key tuples,
               silently discard the segment and cease further TCP
               processing.


> >    For a particular endpoint (i.e., IP address) there would be exactly
> >    one TAPD that is consulted by all pending connections, the same way
> >    that there is only one table of TCBs (a database can support multiple
> >    endpoints, but an endpoint is represented in only one database).
> >    Multiple databases could be used to support virtual hosts, i.e.,
> >    groups of interfaces.
> >
> > Again, TMI. This is one implementation, but there are sensible
> > implementations with multiple TAPDs.
>
> How ever many TAPDs an implementation has, they must act as if they were
> a single TAPD. Otherwise, I could have this:
>
> 	TAPD 1			TAPD 2
>
> 	SRCIP=*,DSTIP=10.0.0.1	SRCIP=192.168.1.1,DSTIP=*
> 	-> MKT ID=23		-> MKT ID=54
>
> Which one wins?

I agree that it needs to be unambigous what packet processing
needs to be applied. But you're specifying one implementation.

-Ekr