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

[Joe Touch <[e-mail]>]

Hi, Adam,

Adam Langley wrote:
> 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. 

The nonce is for generating per-session keys, not for per-packet 
operations. Per packet uniqueness is discussed in the replay section of 
the Security Considerations, and is governed primarily by the TCP 
sequence number, and the strong suggestion (elsewhere) to change the key 
every 2^31 bytes if uniqueness is a concern.

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

We can't add in the IP ID as a rule; this mechanism needs to work for 
IPv6 - which, when not source fragmented, has no such ID (see also my 
other I-D deprecating IPv4 ID uniqueness for related reasons).

This is, as noted above, only to ensure session key uniqueness. It 
removes the need to check for key reuse.

----

As to per-packet uniqueness...

> 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 4 is what we currently suggest, which is:
use the 32-bit sequence number as the per-packet nonce, and encourage 
rekeying every 2^31 bytes or so.

This is preferable to the above because:
	- it avoids the need for additional state in TCP that
	can be hard to manage when retransmissions straddle
	rollover (i.e., state changes not already inside TCP);
	this state is complex whether it's the top part of a
	counter or a new counter

	- it avoids the space a full new counter would consume
	in the option

	- it still provides a nonce (I don't see how to "disallow"
	MACs that require a nonce. I don't know what a "strong"
	nonce is, though - nonce just means unique. If 'strong'
	means 'random', that's different (i.e., entropy inducer,
	vs. just unique).

Finally, if none of that is sufficient and users need true nonces, then 
other protocols might be preferable (e.g., IPsec); this isn't intended 
to be a complete solution for all situations.

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

I prefer including the expected addrs and port numbers for the following 
reason:

1. TCP-AO needs to know what the addr/port pair is at the receiver 
behind the NAT anyway in order to match keys to connections

2. if the addr/port pair at the dest is known, it could be coordinated 
with the source and the source can include those values when computing 
the MAC

i.e., if you have enough information to make keying work properly, you 
have enough to compute a valid received MAC that includes the addrs and 
ports, and thus validates that info when a message is received.

Joe

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