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.
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? If so, is there a
strong security requirement that militates against doing that? 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?
David
Joe
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
