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

[Eric Rescorla <[e-mail]>]

$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