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

[Eric Rescorla <[e-mail]>]

At Mon, 10 Mar 2008 18:29:52 -0700,
Joe Touch wrote:
> 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...

I do plan to try to attend TCPM.

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

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. 


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

Right, so absent the definition of such a mechanism, this is less
useful than 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.
> 
> 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...

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.


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

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. 

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

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 
> succeed, but it also isn't clear that both directions are equally 
> vulnerable, is it?

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.


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

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


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

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.

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

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

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

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
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm