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

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

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

>I'm not at all clear on hashing a single 32-bit number to generate a
>useful nonce. If you're using it to index a nonce generate by some other
>means, perhaps - but that assumes some other source of randomness is
>used to create a sequence of nonces (K2, above). In that case, K2 would
>need to be managed and updated when the seqnum rolls over as well.

In the example: nonce=F_K2(seq num). The randomness comes from the K2, seq
num is used to let PRF gives different pseudo random integers each time. And
as I said above, K2 does need be managed and updated just as the hash
function key does. 
( Similarly, in crypto algorithms like PRF_HMAC_SHA1 or the nonce processing
part of UMAC, the randomness comes from the key, not from some input
counter, non-secret pad or strings.)
 
>However, there is no rule that the seqnum is used only once until
>rollover. TCP can retransmit a segment, and the retransmitted segment
>can be longer or shorter than the original transmission. For this
>reason, I don't believe seqnum is useful as a nonce, or to derive a
>nonce, for crypto purposes.

Thank you for pointing out the situation when a seq num is used again before
rollover. Since both sides of a tcp connection know the header length of TCP
and IP headers, also know the total length of the IP datagram, they can
calculate the length of the segment that TCP transmitted. Therefore the
nonce can be calculated as: nonce=F_K2(seq num, segment length), where
segment length=ip_total_length - 4 * tcp_header_length - 4 *
ip_header_length. In case TCP retransmit a segment (same starting byte) with
different size, a different nonce will be generated. The nonce will be same
only when the exact same segment is retransmitted. 


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

>It's not clear why UMAC then needs to treat the nonce field differently
>from the rest of the segment - unless the nonce itself is ensured
>nonrepeated for that key set. If that's the case, then, as noted above,
>seqnum isn't a viable source of that nonce.

Yes, the nonce can be ensured nonrepeated as described above.

Sean




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