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

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2009 18:36:44 -0700

$Id: draft-ietf-tcpm-tcp-auth-opt-04-rev.txt,v 1.1 2009/03/20 00:18:59 ekr Exp $

I've just given this document a complete readthrough. Comments 
below.

GENERAL COMMENTS
Now that I read the document end to end, I find it to be extremely
hard to follow. I don't know if it's always been like that and
I'm just noticing it as the technical issues come into focus or
if it's the result of multiple technical revisions, but in any
case, IMO some significant editorial work is needed.

The most serious problem is the confusion in the text between
three concepts:

- Master Keys
- Key-Ids
- Traffic keys

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

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

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.

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 realize this is imperfect since you could have two master keys, but
it's the best I can do right now.

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.

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.

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

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

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

   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.

   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.

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.

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

   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.

 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.

   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.

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

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

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

   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.

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

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.

   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.

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.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Sat, 21 Mar 2009 14:24:30 -0700

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

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.

> 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

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 master key, which comprises the following values (at least):

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.

> text along the lines of the above.

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

>                  - Algorithm = HMAC-SHA1               - Algorithm = AES-CMAC

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

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

> explicit agenda item and I would like agenda time to present an

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.

> wire encoding, it doesn't make any sense to discuss what 0 and 1

We agreed; I missed it in the edits.

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

> It's two master keys you need to be able to support.

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

> on the implementation. Why can't I have a TPAD entry that means 

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?

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

> 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

> It's not the KeyID that should be stored but rather the master key tuple.

Agreed - it's a pointer to the MKT.

> 64-bit quantity is an ESN. If anything, this is a sequence number

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 ;-)

> Typically? We don't have enough implementations to talk about typical.

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

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

> something has gone badly wrong.

Given the update just above, this can be removed.

> I don't even know what a padding modulus is, but every MAC I know of

That goes away too.

>    in general [RFC2104][RFC2403]. The traffic key is derived from the 

Will do.

> s/connection keys/traffic keys/

Will do.

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

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

> See above for my comments on this.

Will fix.

> A diagram here seems like it might be useful.

Will do.

> 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