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

Hi, Eric,

Some questions below. Overall, the specific issues you raise can be
addressed. The chairs can address the need for a rewrite.

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)

The text needs a few more passes and a few more eyes to catch the
ripples of the last revision.

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

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

> The basic unit of operation here is not the key-id but rather
> the master key, which comprises the following values (at least):
> 
>    - master_key
>    - send key_id
>    - receive key_id
>    - MAC algorithm

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.

> If you want to invent a new concept (e.g., security association)
> that holds all of these, that's fine I suppose. However, it's really
> confusing to use key-id here. I suspect this is a holdover from
> previous text.
> 
> In any case, I think the document would benefit from some explanatory
> text along the lines of the above.

Sure; see above, and let me know if that covers it.

> The second clarity point is the relationship between master keys and
> traffic keys is. I would think a diagram like the following might
> be in order:
> 
> 
> 
> 
>                  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)
- -- changes name of top set to 'master_tuple' (as per Section 5)
- -- adds the master key, which is the shared secret

          Master_tuple_A                     Master_tuple_B
          keyID 34                           keyID 22
          master_string = ABCDEF             master_string = 123456
          Algorithm = HMAC-SHA1              Algorithm = AES-CMACNow
                |                                  |
                |                                  |
    +------------------------+                     |
    |                        |                     |
    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
- - Recv_Other_key       - Recv_Other_key      - Recv_Other_key

> I realize this is imperfect since you could have two master keys, but
> it's the best I can do right now.

The diagram you show is only how connection keys are derived from master
tuples and connection info. Each connection has per-connection
parameters as described in section 6:

	current-key
	next-key
	send-ESN
	recv-ESN
	[one or more master-tuples]

I.e., it is in the per-connection parameters that multiple master key
tuples are indicated.

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

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

> DETAILED COMMENTS
> S 5.
>    2. A TCP option flag. When 0, this flag allows default operation, 
>       i.e., TCP options are included in the MAC calculation, with TCP-
>       AO's MAC field zeroed out.  When 1, all options (excluding TCP-AO) 
>       are excluded from all MAC calculations (skipped over, not simply 
>       zeroed). The option flag applies to TCP options in both directions 
>       (incoming and outgoing segments). 
> 
> This text has two problems. First, the whole concept of a default is
> meaningless here (I believe we agreed on this in e-mail, but I'm
> adding the comment to make sure). Second, since this flag has no
> wire encoding, it doesn't make any sense to discuss what 0 and 1
> mean.

We agreed; I missed it in the edits.

>       >> The set of TAPD master key tuples MAY change during a 
>       connection, but KeyIDs of those tuples MUST NOT overlap. I.e., 
>       tuple parameter changes MUST be accompanied by master key changes.
> 
> I think this is a little problematic because of concreteness about
> "master key". If I'm using master key "ABC" and I decide to change
> the MAC algorithm, I can still use "ABC". This is an argument for
> a higher level "security association" type construct, I suppose.

I need to scrub "master key" and correct it to refer to the master key
tuple in most places.

>           >> A TAPD implementation MUST support at least two KeyIDs per 
>           connection per direction, and MAY support up to 256. 
> 
> This is another example of confusion between master keys and key-ids.
> It's two master keys you need to be able to support.

It's two master key tuples we need to support; will fix.

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

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

>    NOTE: an open issue is whether to require actions when master keys 
>    are added to the TAPD. In particular, there is a suggestion to force 
>    new added keys to update current_key to the newly added value, and to 
>    set a timer or flag on previous current_key values. If a timer, the 
>    value is unclear (2*MSL isn't appropriate, because we don't know how 
>    long a key changeover may take, and we're not reacting to messages 
>    from the other side). If a flag, this would require that flagged 
>    entries could never be advertised as NextKeyID. 
> 
> 
> This is pretty unclear, but I don't think it's what people are recommending.
> Rahter that once a key is displaced, it should time out.

There were three different suggestions:

	1) when a key is displaced, a timeout is used to prevent a user
	from inadvertently removing it from the TAPD and thus losing
	reordered segments
		FWIW, that's in there already without a note because
		there was [some] consensus on the call

	2) when a key is displaced, it cannot be reactivated
	i.e., if the timer is ever set, never switch back
		this is possibly problematic because reordering
		can cause key lockout

	3) MKT are always preferred when they are added to the TAPD
	i.e., when adding MKT, update nextID for all active connections
		this is possibly problematic because it requires
		both sides to enter keys in the same order; it is
		equivalent to the following explicit user-level
		actions:
			- add MKT
			- update all active connections to use that
			  MKT as nextID

> S 6.
>    1. Current_key - the KeyID of the master key tuple currently used to 
>       authenticate outgoing segments, inserted in outgoing segments as 
> 
> It's not the KeyID that should be stored but rather the master key tuple.

Agreed - it's a pointer to the MKT.

>    3. A pair of Extended Sequence Numbers (ESNs). ESNs are used to 
>       prevent replay attacks, as described in Section 8.2. Each ESN is 
>       initialized to zero upon connection establishment. Its use in the 
>       MAC calculation is described in Section 7.1. 
> 
> The term "extended sequence number" is confusing here. The entire 
> 64-bit quantity is an ESN. If anything, this is a sequence number
> extension (SNE).

They're sequence number extension numbers, or sequence extension
numbers), i.e., SNENs or SENs, more specifically. I prefer SEN.

(though we could posit the remaining permutations, e.g.: ENS, NES and
NSE ;-)

>    Master key tuples are used, together with other parameters of a 
>    connection, to create traffic keys unique to each connection, as 
>    described in Section 7.2. These traffic keys can be cached after 
>    computation, and are typically stored in the TCB with the 
>    corresponding master key tuple information. They can be considered 
>    part of the per-connection parameters. 
> 
> Typically? We don't have enough implementations to talk about typical.

Will fix. they *can* be stored...

>  S7.1.
>    o  MAC_truncation - the number of bytes to truncate the output of the 
>       MAC to. This is indicated by the MAC algorithm, as specified in 
>       [ao-crypto]. 
> 
> I don't think it makes sense to talk about truncation here.
> The MACs produce a value that is crammed into the packet.
> If there's a separate spec that describes the MACs, it's not
> AO's business whether those MACs were produced by a truncation process.

That's missing from the companion doc, then. TCP-AO should then assume
that the MAC comes out at whatever length it comes out.

>    o  MAC - the fixed-length output of the MAC algorithm, given the 
>       parameters provided. If the MAC_alg output is smaller than the 
>       desired MAC_truncation, it is padded with trailing zeroes as 
>       needed. 
> 
> This padding seems extraordinarily unsafe. If this ever happens,
> something has gone badly wrong.

Given the update just above, this can be removed.

>    >> To allow a TCP-AO implementation to compute any implicit MAC 
>    algorithm padding required, the specification for each algorithm used 
>    with TCP-AO MUST specify the padding modulus for the algorithm, if 
>    one is required. 
> 
> S 7.2.
> I don't even know what a padding modulus is, but every MAC I know of
> does it's own padding.

That goes away too.

>    MAC algorithm indicates how to use the traffic key, e.g., as HMACs do 
>    in general [RFC2104][RFC2403]. The traffic key is derived from the 
> 
> s/in general//.

Will do.

>    ensures that connection keys generated for each direction are unique. 
> s/connection keys/traffic keys/

Will do.

>    o  Send_SYN_traffic_key - the traffic key used to authenticate 
>       outgoing SYNs. The source ISN known (the TCP connection's local 
>       ISN), and the destination (remote) ISN is unknown (and so the 
>       value 0 is used). 
> 
>    o  Receive_SYN_traffic_key - the traffic key used to authenticate 
>       incoming SYNs. The source ISN known (the TCP connection's remote 
>       ISN), and the destination (remote) ISN is unknown (and so the 
>       value 0 is used). 
> 
> You should probably mention that in most cases (except for simultaneous
> opens) only one of these is needed per side.

We define them, and mention that they can be cached, but there's clearly
no utility in either one after the TWHS is complete anyway. I don't see
a reason to get into details on whether both of these are used or not.

> S 7.3.
> Much of the text here is now overtaken by events.

I disagree. We still need to say we assume external mechanisms (manual
or automatic) negotiate the master key tuples. We can coordinate key
changover (as per section 8.1), but somebody needs to decide when to
insert the new keys on both ends or no change will ever occur. We aren't
robust to master key (string) mistypes - even after a connection starts,
and this needs to be noted.

> S 8.1.
>    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 
> 
> See above for my comments on this.

Will fix.

>    the sender to commence use of that new KeyID. This supported by using 
>    two key ID fields in the header: 
> 
>    o  KeyID 
> 
>    o  NextKeyID 
> 
> It's probably worth mentioning that these may (often will) be the same.
> A diagram here seems like it might be useful.

Will do.

> S 9.2.
>    >> A TAPD entry MAY underspecify the TCP connection for the LISTEN 
>    state. Such an entry MUST NOT be used for more than one connection 
>    progressing out of the LISTEN state.  
> 
> I don't see why this is a problem with the current system. On the 
> contrary, it would be quite attractive to simply set the listening
> socket with a single master key.

That is an artifact from before we had master tuples and unique traffic
keys, and should have been removed.

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

iEYEARECAAYFAknFWw4ACgkQE5f5cImnZrummQCg1TQWGR3m2lYjl+14Wu0zP5z+
xOwAoKLG1Z8UclxDTOVb3i4M1YTbU3tQ
=S0cJ
-----END PGP SIGNATURE-----