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

[Joe Touch <[e-mail]>]

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



Eric Rescorla wrote:
> 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.

Agreed. Let's agree on what to fix (I think we have) and scrub the doc
on that point.

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

Will fix.

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

Yes. Will fix.

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

Russ can clarify. First, let's clarify some terms:

key-id = a digit in [0..255] that, together with a connection's socket
pair (as per RFC793, i.e., srcIP, dstIP, srcport, dstport) indicates a
single MKT.

key-id field = the value in the TCP-AO option

key-id fields are unidirectional - they indicate the key-id used to
authenticate that TCP segment

key-ids are bidirectional - they indicate (with the socket pair) a MKT
that can be used in either direction

However, there is no utility in referring to the same MKT with different
key-id values for the different directions of a single connection.

Russ - can you clarify if that's what you were requesting?

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

A system may want to force TCP-AO (or allow non-TCP-AO) on connections
it is not yet ready to listen to (e.g., before any communications
process starts).

> 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 agree that it's up to the implementer. IMO, it's useful to explain the
behavior in terms of a central dbase - any implementation that is
equivalent is fine. Do we need to say that more directly?

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

Ahhh. Thanks. We need to change the text to allow for two variants:

	1) TAPD without a key that MUST be TCP-AO'd (i.e., before
	a key is available)

	2) TAPD to allow non-TCP-AO

I can fix the text accordingly.

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

I'm trying to say that an implementation must act like a system with one
TSAD (and can say that explicitly). A database is a property of
relationships between sets of data (i.e., <socketpair, keyID> values and
MKTs). Databases can be implemented in various ways, so long as that
relationship is preserved. We rely on that relationship for correct
operation, though.

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

iEYEARECAAYFAknHns8ACgkQE5f5cImnZruKIQCdHi0nUBMsYwdaekjiRcnxZ9YZ
2DkAoOmtBJeDhDj2levO92ts0hxNrBH+
=ozcN
-----END PGP SIGNATURE-----