Hi, Eric, Eric Rescorla wrote: ...
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.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 thoseare.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.
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...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.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 eachparameter 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 contentsof 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 themincreases 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
Attachment:
signature.asc
Description: OpenPGP digital signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.