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

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

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

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.

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

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

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

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

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

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

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

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.

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

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?

> 2. Even if we stipulate that this might be an OK idea, it's not
> 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.

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

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

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

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.

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

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

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

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.

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

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.

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

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

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

Attachment: signature.asc