Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

["Adam Langley" <[e-mail]>]

2008/7/14  <[e-mail]>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>        Title           : The TCP Authentication Option
>        Author(s)       : J. Touch, et al.
>        Filename        : draft-ietf-tcpm-tcp-auth-opt-01.txt

Going by the changes section:

> requiring an algorithm for nonce introduction based on ISNs"
...
> The presence of TCP's pair of
>   Initial Sequence Numbers presents a nonce that may be useful in that
>   case. Such a nonce could be computed as the concatenation of the ISNs
>   (initiator, responder), and the socket pair (addresses, ports):

>   o  Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r

I'd like to step back and review this for a moment:

We have a couple of reasons for wanting to define an nonce:

Reason 1: Without a monotonic counter, a MAC is open to replay
attacks. I'm not sure how serious this is. Certainly you can elicit
different behaviour from stacks by replaying, say, an ACK very
quickly. This is undesirable, but it might be acceptable. More
troubling is the possibility of exploiting sequence number rollover to
inject a valid packet from 2^32 bytes in the past into the current
stream. A monotonic nonce would mean that we could reject replays.

Reason 2: Some MAC functions require an nonce as an input and their
security depends on the nonce never being reused for any other message
with the same key. Consider a connection where all the
application-level data transfer is one way and a packet, seq number n,
is lost by the network. Here, it's very possible that an ACK for n-1
is transmitted, followed by an ACK for n-1 with a SACK option. Now
we've transmitted two different messages with the same nonce. Any
nonce based only the sequence numbers has this problem unless we
disable/don't include SACK. Also, if we are only including 32-bits of
seq, then we trivially repeat every 2^32 bytes.

The suggested nonce scheme, above, thus doesn't suffice for reason 2.
However, since the ISNs and pseudoheader are already included in the
MAC's input, it doesn't do anything for reason 1 either. I don't
believe adding in the IP ID would help either.

Option 1: don't define an nonce, accept the reply-attack implications
and disallow MACs which require strong nonces

Option 2: define a 64-bit message counter in each direction, include
the bottom n-bits in the AO option and allow some small amount of
reordering. Reject duplicate messages. This solves reasons 1 and 2 but
requires extra option data and extra state.

Option 3: use the seq number as the bottom 32-bits of a 64-bit
sequence. It solves replay attacks after 2^32 bytes, but not some
other replay attacks. It doesn't solve reason 2. It involves extra
state. However, if options are not included in the message, then this
*does* solve reason 2 I suspect. I'd want some wiser minds to confirm
this however.

Option 2 is the cryptographically strong solution. Consider the
options in a packet:
  10 bytes of timestamp option
  18 bytes of AO (96-bit MAC + 2 bytes of option header + key id + nonce)
  12 bytes remaining (enough for one SACK block)

If the key id was only a bit, then we have 31 low bits of message
counter. That's acceptable I think. It would require a packet loss
burst of 3^30 packets to de-sync the hosts (which implies a window of
> 1 TB @ 1500 MTU). It's really cramming things, however and the
storing the counter-space holes to allow for reordering might become
expensive if the reorder window is large.

So, although I like option 2, any of them would be ok. But I think the
current wording in the spec needs to be clearer about which we're
choosing.

> Clarify NAT interaction

I do believe that some method of getting through common NATs (other
than wrapping the packets in a tunnel) is needed. There was my
previous suggestion of making pseudo-header inclusion optional and
having userspace specify a 20-byte bit mask, which is applied to the
TCP header (I'll concede that it's a painful 20-bytes of extra state).
Alternatively, the common case can be specified with a single bit to
remove the pseudo-header and port numbers from the MAC's input.


AGL

-- 
Adam Langley [e-mail] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm