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

Hi, Eric,

Eric Rescorla wrote:
...
>>> 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. 

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.

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

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

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

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.

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

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

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

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

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

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.

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

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.

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

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.

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

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.

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

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

Joe

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

Attachment: signature.asc