Subject: [saag] Comments on draft-ietf-tcpm-tcp-auth-opt-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Mar 2008 19:33:04 -0400

I started writing comments on this and after I'd spent about 
2 hours writing background material, I decided to cram it 
into an I-D. Until it appears on the I-D directory, you
can find it at:

https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth-arch.txt

Anyway, review follows:

$Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 ekr Exp $

GENERAL COMMENTS
I'm not convinced it's necessary to have a new key for each
connection. This is primarily useful to prevent inter-connection
cut-and-paste attacks, and it's not clear how serious those
are. I think it's particularly problematic to levy this
requirement without providing some mechanism for arranging
that, since that basically implies having some automatic
mechanism for establishing fresh per-connection keys, which
doesn't currently exist. That makes this mechanism distinctly
less useful than RFC 2385.

I don't think this API, specification of the TSAD, etc., is
particularly helpful. IPsec needed the concept of an association
database because packets corresponding to multiple associations
got similar treatment. However, TCP has an explicit notion
of connection so it would be far more convenient to simply
refer to keys as tied to connections, and then have a set
of rules for mapping which connections get which keys.

Even if some TSAD-type abstraction is useful, I don't think
it's appropriate to define things like the size of each
parameter in the TSAD as opposed to on the wire, or to
describe the default values of various parameters as in
S 3. For instance:

         iii. Key length. A byte indicating the length of the 
               connection key in bytes.  

Those are internal implementation issues. Certainly, I might
want to use a native int in my implementation. Why should
this document tell me otherwise?

TECHNICAL COMMENTS
S 1.1.
I don't see a lot of value in pre-specifying two MAC algorithms
as MTI. There's no reason to believe one isn't plenty, as used
in other protocols.

S 2.2.
This thing with the key-id being present if the MAC is odd,
but absent if it's even strikes me as being overly clever.
Let's just burn an octet on key-id and leave it at that.

S 3.
               >> At least one direction (inbound/outbound) SHOULD have 
               a non-NONE MAC in practice, but this MUST NOT be strictly 
               required by an implementation.  

1. This seems like a bad idea. It's very hard to analyze the security
properties of a connection when only one side is protected. To take
one case that is obviously bad, if you're worried about DoS attacks
and you use TCP-AO, then forging packets in either direction can
bring it down. I would reverse this and require MACs in both directions.

2. Even if we stipulate that this might be an OK idea, it's not
appropriate to require implementations to support it.

S 4.1.
   >> New TSAD entries MUST be checked against a table of previously 
   used TSAD entries, and key reuse MUST be prohibited. 

Huh? So, I have to keep a list of every TSAD entry ever and check
against the table. Seems better to just to do this by construction.

S 4.3.
   >> TCP segments with TCP-AO but not matching TSAD entries MUST be 
   silently accepted; this is required for equivalent function with TCPs 
   not implementing TCP-AO.  

I don't see this. Can you explain?

   >> Silent discard events SHOULD be signaled to the user as a warning, 
   and silent accept events MAY be signaled to the user as a warning. 

I don't really understand what a warning means here? syslog? 

S 5.
   Implementations are encouraged to keep keys in a suitably private 
   area. Users of TCP-AO are encouraged to use different keys for 
   inbound and outbound MACs on a given TCP connection. 

Some discussion of why different keys are good or bad would help
here. As far as I can tell, reflection attacks aren't an issue
as long as the host/port quartet is incuded in the header.

S 5.1.
   o  Number of bytes to be sent/received (two bytes); this is used on 
      the send side to trigger bytecount-based KeyID changes, and on the 
      receive side only for statistics or length-sensitive KeyID 
      selection. 

Please explain the cryptographic rationale for why you would want to
do bytecount based key changes.

S 9.
   TCP-AO does not expose the MAC algorithm used to authenticate a 
   particular connection; that information is kept in the TSAD at the 
   endpoints, and is not indicated in the header. 

This seems to be of extremely marginal security benefit. There
are likely to be <5 algorithms in use. So, searching all of them
increases the effective key size by <3 bits. 

EDITORIAL COMMENTS
S 1.
   there have been escalating attacks on the algorithm itself [Be05] 
   [Bu06].  TCP MD5 also lacks both key management and algorithm 

These citations should be to the original papers, not the summaries
(not that I mind you citing Steve's and my paper...)

o
S 2.2.
Figure 2 is kind of hard to read since the length of the kind
field is 16 bits, but kinds are 8 bits, rigth?

S 3.
   Note that the connection key is not included here; we expect that the 
   MAC algorithm will indicate how to use the key, e.g., as HMACs do in 
s/HMACs do/HMAC does/

   TCP-AO by default includes the TCP options because these options are 
   intended to be end-to-end and some are required for proper TCP 
   operation (e.g., SACK, timestamp, large windows). Middleboxes that 

I dpn't understand what "by default" means here. This needs to be
configured on both sides, right? So, this is just a UI issue.

S 5.
   the default case. Segments carry only enough context to identify the 
   security association [RFC4301][RFC4306]. In TCP-AO, this context is 

I'm not sure what security association means here. You're not using IKE,
right?

S 9.
   TCP-AO does not expose the MAC algorithm used to authenticate a 
   particular connection; that information is kept in the TSAD at the 
   endpoints, and is not indicated in the header. 

I may not be enough of a TCP wonk, but what's a connection ID?

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Mar 2008 18:29:52 -0700

Eric,

Thanks for the detailed comments.

Some responses based on the text below.
I'll comment on the ID separately...

Also, I would expect that most of these issues would be useful to 
discuss further in TCPM if you're available. Otherwise, we could meet 
separately...

Joe

Eric Rescorla wrote:
> are. 

It's there primarily to prevent packets from an old version of a 
connection from being used on a new connection, i.e., replay attacks 
between a connection and its successor using the same port pair.

I.e., IMO it's a MUST within a port pair for some period of time (the 
cache check), and a SHOULD (for general security reasons) between port 
pairs. The SHOULD can be dropped if (IMO) SAAG doesn't consider reusing 
keys for different datasets an issue.

> I think it's particularly problematic to levy this

It does imply that for systems that re-establish connections frequently 
either a a fresh key generation system is available, or a fairly long 
list is preloaded.

> of rules for mapping which connections get which keys.

That's exactly what the TSAD is (or at least is supposed to be). It 
might be useful to discuss this offline to figure out what the 
disconnect is...

> parameter in the TSAD as opposed to on the wire, 

The TSAD API needs to be specified in detail because the key management 
solution needs to rely on that information.

> or to

Again, it's to allow another party - the key management solution - to 
load the TSAD.

> Let's just burn an octet on key-id and leave it at that.

That would be discussed in TCPM further. The primary utility is for 
short connections where the key isn't expected to need to rollover, and 
where TCP option bytes are in extreme scarcity, esp. because single byte 
can end up adding 4 overall, due to alignment issues.

If that's not useful, we can decide to make the key-id always present.

> bring it down. I would reverse this and require MACs in both directions.

For BGP, this is important. For servers, it's not necessarily feasible - 
clients may authenticate the server, but the converse may not 
necessarily be true. Yes, this allows attacks in one direction to 
succeed, but it also isn't clear that both directions are equally 
vulnerable, is it?

> appropriate to require implementations to support it.

I'm not sure I understand this; if we say that connections MAY have 
unidirectional auth, then it seems like the implementation MUST support 
that capability.

> against the table. Seems better to just to do this by construction.

I'm not sure what "by construction" means, but that's certainly better 
if possible. Can you suggest text or explain this off-line?

> I don't see this. Can you explain?

TCP-AO is just a signature. If you don't have enough information to 
invalidate the signature, you don't have enough reason to drop a segment.

The expected use case is that an endsystem will authenticate only a 
subset of its connections; for those connections, it would install keys 
- even if random ones - to "lock" those ports down. It's simpler to do 
that than to lock everything by default and open things up explictly, 
IMO, but we can default in either direction if necessary.

Consider the case of a system that does not implement TCP-AO. TCP 
ignores options it doesn't understand, so the connection will work fine. 
Now you install TCP-AO, but don't load any keys. The intent is that an 
un-keyed connection is the same as TCP without TCP-AO.

> I don't really understand what a warning means here? syslog?

That's one way. Others accumulate the info in a variable that apps can 
check, e.g., via the socket interface.

> as long as the host/port quartet is incuded in the header.

Sure. The goal is the general one of avoiding rekeying symmetric data 
with the same key. It's not based on a specific kind of attack.

> do bytecount based key changes.

That part of the API is strawman; we expect to need to count either 
messages or bytes or both. If message counts are more useful, then we 
can change to that.

> increases the effective key size by <3 bits. 

The other reason to not include it is space; it's not needed, since it's 
effectively bound to the active key anyway.

> EDITORIAL COMMENTS

Fixed separately....

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 07:53:57 -0400

At Mon, 10 Mar 2008 18:29:52 -0700,
> discuss further in TCPM if you're available. Otherwise, we could meet 

I do plan to try to attend TCPM.

> between a connection and its successor using the same port pair.

Right, that's what I mean by "inter-connection cut and paste attacks".
I'd like to see some analysis of how serious they are. 

> either a a fresh key generation system is available, or a fairly long 

Right, so absent the definition of such a mechanism, this is less
useful than 2385.

> might be useful to discuss this offline to figure out what the 

Perhaps. I think expressing it as a database isn't particularly
helpful. There are structures associated with the connection
and it's most useful (IMO) to think of this data as attached
to them, just as (for instance) the current window or sequence
number is.

> Again, it's to allow another party - the key management solution - to 

I really don't see this. The other party presumably has some set of
API calls/IPC/whatever, that it talks to. It's not our job to
specify the interface between those to, other than the contents
of the elements. 

> necessarily be true.

I don't see why it's not feasible. They share a key, so there's
no reason not to have mutual auth.

> Yes, this allows attacks in one direction to 

I don't see this. The relevant attack here is to bring down the
connection. An RST in either direction will accomplish that.
Thus, ISTM that packets need to be authenticated in both
directions.

> unidirectional auth, then it seems like the implementation MUST support 

I don't see that that's true. For instance, TLS stacks MAY support
RC4, but we don't require them to support RC4.

> if possible. Can you suggest text or explain this off-line?

I mean that if you randomly generate keys for the TSAD with an
appropriate algorithm then there is no reasonable chance that there
will be a collision.

> messages or bytes or both. If message counts are more useful, then we 

I don't see that you need to count either. 

> effectively bound to the active key anyway.

That's totally reasonable. I'm not saying it has to be included, just that
I don't see not including it as a significant security benefit.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2008 05:32:13 -0700

Hi, Eric,

Eric Rescorla wrote:
...
> I'd like to see some analysis of how serious they are. 

They would be obvious opportunities for on-path attackers. As per my 
other reply this AM, using the ISN in the hash might avoid this issue 
entirely.

> Right, so absent the definition of such a mechanism, this is less

Absolutely. We agree that an auto key mechanism is critical; we feel 
that, like IPsec, it's not integral.

> to them, just as (for instance) the current window or sequence

Agreed, and that information is deliberately not accessible. Expression 
of the info as a dbase is equivalent to how TCP describes a "control 
block". The important issue is the info in each entry, and the index by 
which they're differentiated.

> specify the interface between those to, other than the contents

That's basically all we do - contents, order, and size of each element 
in each direction.

> no reason not to have mutual auth.

There are cases I can think of - akin to well-known CAs used by web 
browsers used over wireless channels (see below).

> connection. An RST in either direction will accomplish that.

The question is whether a RST in either direction is as easy to inject. 
There are media with dedicated uplinks and shared downlinks for which 
this is the case, e.g., some wireless nets.

Note that this is all just my playing devils' advocate about whether 
this is needed; if we agree that we should always require bidirectional 
auth, then it's a trivial patch to the doc to do so.

> RC4, but we don't require them to support RC4.

I understand now. I am thinking of this as a required feature; again, if 
the TCPM WG and/or SAAG thinks this is either MUST NOT or MAY, then it's 
an easy change.

> appropriate algorithm then there is no reasonable chance that there

That requires the TSAD only ever be loaded by an automatic key manager, 
AND that only one such manager ever exist. We don't want to require 
either for all implementations, thus the TSAD must enforce whatever is 
needed in this regard.

Again, the other email of this AM might suggest a simpler way out using 
ISNs in the hash.

> I don't see that you need to count either. 

I recalled this; it's for sequence number rollover. There are TCP 
connections that send more than 2^32 bytes. We MUST rollover keys when 
that happens, and we do not want to tie the key system to internal TCP 
state.

> I don't see not including it as a significant security benefit.

It's not significant, agreed. We might omit that from the doc as a 
result if others agree.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 08:46:31 -0400

Information is getting spread over two threads here, so I will be repeating
myself a bit.

At Tue, 11 Mar 2008 05:32:13 -0700,
> which they're differentiated.

I think we're going to have to disagree on this one.

> That's basically all we do - contents, order, and size of each element 

Well "contents" != "contents, order, and size" and I haven't heard
a clear demonstration that "order and size" are required".

> browsers used over wireless channels (see below).

Well, I think any case in which you have public key is fundamentally
different: shared keys imply an opportunity for utual authentication.

> either for all implementations, thus the TSAD must enforce whatever is 

No, I don't agree with this. Rather, implementors must ensure that 
they don't duplicate entry. If they have two management processes,
they need to somehow coordinate (or use independent algorithms).
That does not mean that the TSAD needs to verify that. Note that
verifying it means retaining records of every key. That seems
impractical.

> that happens, and we do not want to tie the key system to internal TCP 

See my previous note for how to do this without rollover using 
ESNs.

-Ekr