RE: [saag] [Cfrg] Re: TCP-AO MAC algorithms

[Sean Shuo Shen <[e-mail]>]

Hi, Joe

>> 
>> 1. interface:
>> I agree that MAC interface without a nonce may make implementation
easier.
>> But nonce may not expand the size of MAC because it can be generated by
both
>> sides of a TCP connection. For example, the nonce in UMAC can simply be a
>> counter from 0 to a certain upper bound. Even if nonce requires
randomness,
>> a PRFed value of a counter or sequence number (I remember Joe Touch
>> mentioned in Vancouver that key generation of TCP AO should not use any
>> bytes of TCP packets, but I think nonce should be ok.) can provide
>> randomness. Noticing the good performance of MACs like UMAC, maybe we
should
>> keep the door open to MACs with nonce.

>The TCP fields must not be used as a nonce for the MAC; although they do
>change, the ways they change are not ensured to be predictable (e.g.,
>TCP can validly send overlapping segments). As such, a per-packet nonce
>would need to be sent in the TCP option field, and there is insufficient
>space to do that on a per-packet basis (which is why there is no such
>field in TCP-AO).

I think I may need to clarify what I said: if a random nonce is needed for
TCP MAC, a PRFed value of sequence number provides randomness, for example:
nonce=F_K2(seq num), K2 is the key for the pseudo random function F. K2 is
different from the hash function key K1. (Actually, in UMAC, the nonce
itself does not require randomness at all, the nonce processing part of UMAC
already create randomness). The distribution/rekeying of K2 will be done
together with K1. 
I don't get why you hope sequence number be predictable here. Both sides
will know the sequence number from the TCP header and calculate the
nonce=F_K2(seq num), they are not predicting either the sequence number or
the nonce.

>> 2. incremental MAC
>> I understand the use of incrementality for virus protection but can not
see
>> the benefit of incrementality for TCP AO, at least in the BGP situation.
In
>> tcpm-tcp-auth-op, the MAC is computed over "TCP pseudo header + TCP
header +
>> TCP data", the first two parts (totally about 32 bytes or more for ipv4,
60
>> bytes or more for ipv6) are fixed for a connection, 

>The TCP sequence number varies during a connection, but it can wrap
>around. It's entirely possible to have two segments that have the same
>sequence number at different times in a connection, however. This is why
>we probably need to explicitly require that the connection key change
>whenever the sequence number rolls over (through the ISN).

Does this have anything to do with incrementality of MAC?  
The connection key (hash function key) should change whenever the sequence
number rolls over, so does the key for pseudorandom function, actually,
that's exactly what UMAC requires. The distribution/rekeying of PRF key
should be done together with the hash function key and it won't require much
work from future TCP-AO key management scheme (by the way, anything
available yet? ). 


Sean



_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg