On 8/1/2011 5:37 PM, David A. McGrew wrote:
On Aug 1, 2011, at 1:19 PM, Joe Touch wrote:
On 8/1/2011 10:25 AM, David A. McGrew wrote:
...
But we lose all
TCP header MACing - e.g., someone can RST our connection. TCP AO
suggests that MACing TCP headers is important so crypto protocols
should
do that (hence why we live in the transport layer).
True, but why not design tcpcrypt so that it make use of TCP-AO? That
seems like an approach that would work with the separation outlined
above.
TCP-AO could easily support a mode where the TCP body was encrypted,
e.g., where the encryption algorithm were defined to use the
connection context (TCP header, IP pseudoheader) as context.
It occurs to me that one of the downsides of having authentication via
TCP-AO and encryption via TCPcrypt would be that authenticated
encryption (AEAD) could not be used.
You would not want to cross the streams and use both options AFAICT.
I had been planning on working that into the experimental TCP-AO NAT
doc, since it could be as useful as the NAT variant.
That won't help initialize the keys, as would be needed before the SYN
arrives for TCP-AO. That sort of in-band keying was excluded from
TCP-AO to keep the SYN header size down.
Can TCP-AO possibly be used in a situation where the key is established
after the initial message exchange, but there is no key available to
both endpoints in the first exchange?
No; the assumption in TCP-AO is that a key exists during the initial
exchange and AO is required. Keys can be changed later.
It would be trivial to set this up as a null key to start with if your
goal is as you describe, though.
> If so, is there a strong security
requirement that militates against doing that?
Generally yes; it prevents AO from protecting you from SYN attacks.
You'd also need to change AO so that (depending on a flag set at both
endpoints) you change the key after the SYN or not (e.g., increment the
keyID or somesuch).
It would be undesirable
to have an endpoint set up a session (without authentication) then
immediately have to tear it down (because when authentication was turned
on, it became apparent that an active attacker had created or modified
the messages). But perhaps if the "damage" is well contained and quickly
discovered, it would be OK?
I don't know if this would be considered OK. I'd say it'd be easier to
separate it into two steps, as hinted above:
1) an updated AO spec that allows a flag (on a master key, e.g.)
that requires the keyID to be incremented after the SYN
and that the first key can be null optionally
2) allow null keys (to enable the first part)
Null keys would expose the endpoint during the period they're used, on
ports they're used. If the period were small (the SYN), then you could
limit the damage AFAICT, but I'm not sure whether this would be
considered sufficient or useful.
Joe
