headers
Eric Rescorla | 1 Jan 2008 03:06

Re: TCP-AO MAC algorithms

At Tue, 18 Dec 2007 16:23:51 -0800,
Brian Weis wrote:
> 
> Greetings,
> 
> The TCPM WG seeks advice from SAAG on which MACs to include as  
> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- 
> auth-opt-00). 

I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC
4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why
TCP-AO should have stricter MTI requirements than we have for
our dedicated security protocols?

> Two MACs with differing internal constructions are  
> desired.

I don't understand this either. Most modern MACs are constructed from
two pieces:

- An underlying cryptographic function
- A composition operation

Thus, for instance, HMAC-SHA1 is constructed by using the HMAC
composition operation with SHA-1. In general, the security properties
of the composition operations are well understood (often with some
kind of reduction proof) where the security properties of the
underlying function are unproven. So, while it might make sense
to have two different base cryptographic functions (e.g.,
SHA-1 and SHA-256), it's not at all clear that it's of that
(Continue reading)

Permalink | Reply | 4 comments |
headers
Sean Shuo Shen | 2 Jan 2008 05:41
Favicon

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 2 Jan 2008 07:01
Picon
Favicon

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


Sean Shuo Shen wrote:
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Shuo Shen | 2 Jan 2008 09:49
Favicon

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


>>>> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
mcgrew | 2 Jan 2008 16:06
Picon
Favicon

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

Hi Sean,

Thanks for your comments, more inline:

On 12/27/07 11:00 PM, "Sean Shuo Shen" <sshen <at> huawei.com> wrote:

> Dear David,
> I read the draft-irtf-cfrg-fast-mac-requirements and believe the draft gives
> good security and efficiency description for TCP AO MAC. I have a few
> thoughts according the following issues in the draft:
> 
> 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.

Agreed, it is true that in some cases the nonce need not be carried
explicitly along with the MAC value, but instead can be reconstructed by the
receiver using other information.  It is also possible to use "Partially
Implicit Nonces", in the terms of Section 3.2.1 of draft-mcgrew-auth-enc,
which trades off nonce size against protocol robustness.  Perhaps this is
worth investigating for TCP-AO, though I still think that nonceless MACs
should be favored because of their simplicity.

However, the implicit nonce idea does nothing to address the fact that
nonce-based algorithms are undesirable whenever it is difficult to ensure
nonce coordination, i.e. when key management is absent.

> Even if nonce requires randomness,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 2 Jan 2008 16:29
Picon
Favicon

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


Sean Shuo Shen wrote:
>>>>> 1. interface:
...
>> 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. 

I presume you're looking for a nonce that would be unique per unique
segment. It would be preferable to insert either that nonce or an index
thereto in the MAC itself, than to make assumptions of the uniqueness of
any fields of the TCP segment or a hash that would be derived from them.

Joe
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Kent | 2 Jan 2008 16:37
Picon

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

Anoher issue to keep in mind is that a nonce-less MAC avoids the FIPS 
evaluation problems that would arise from attempts to make use of the 
TCP sequence number as an input to the nonce generation process.

Steve
Permalink | Reply | 0 comments |
headers
Joe Touch | 2 Jan 2008 17:27
Picon
Favicon

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


Joe Touch wrote:
> 
> Sean Shuo Shen wrote:
>>>>>> 1. interface:
> ...
>>> 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. 
> 
> I presume you're looking for a nonce that would be unique per unique
> segment. It would be preferable to insert either that nonce or an index
> thereto in the MAC itself, than to make assumptions of the uniqueness of
> any fields of the TCP segment or a hash that would be derived from them.
> 
> Joe

FWIW, it might be possible for TCP to retransmit a segment with the same
offset and size but with different options. In particular, if the user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Shuo Shen | 4 Jan 2008 02:32
Favicon

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

Hi David,

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

>Agreed, it is true that in some cases the nonce need not be carried
>explicitly along with the MAC value, but instead can be reconstructed by
the
>receiver using other information.  It is also possible to use "Partially
>Implicit Nonces", in the terms of Section 3.2.1 of draft-mcgrew-auth-enc,
>which trades off nonce size against protocol robustness.  Perhaps this is
>worth investigating for TCP-AO, though I still think that nonceless MACs
>should be favored because of their simplicity.
>However, the implicit nonce idea does nothing to address the fact that
>nonce-based algorithms are undesirable whenever it is difficult to ensure
>nonce coordination, i.e. when key management is absent.

If a nonce is used for MAC and requires a key, I think it's reasonable to
let the nonce key updated together with the hash key, similar as some other
security schemes in which encryption keys and integrity protection keys are
generated/renewed synchronously. Though the key management solution for TCP
AO is not proposed yet, adding nonce key generation/distribution together
with hash key won't affect much on overall performance. 

>> Even if nonce requires randomness,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Shuo Shen | 4 Jan 2008 02:59
Favicon

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

Hi Joe, 
>> I presume you're looking for a nonce that would be unique per unique
>> segment. It would be preferable to insert either that nonce or an index
>> thereto in the MAC itself, than to make assumptions of the uniqueness of
>> any fields of the TCP segment or a hash that would be derived from them.

Yes, I am discussing the possibility that unique nonce are generated by both
sides without carrying extra info in MAC. Inserting an index (like a
counter) or even the nonce itself certainly can make life easier, if we
don't care the extra bytes together with the MAC.

>FWIW, it might be possible for TCP to retransmit a segment with the same
>offset and size but with different options. In particular, if the user
>sets an option between a segment's initial transmission and subsequent
>retransmission, this could occur. I'm checking to see if this could also
>occur with TCP flags (e.g., FIN if a user closes a connection while data
>is outstanding).

>For these reasons, and because of the potential to constrain the
>evolution of TCP, I would urge the MAC computation to treat the
>non-zeroed TCP header and pseudoheader fields as opaque.

I also believe some other bits in TCP header might be different even if the
TCP is retransmitting the same segment. But all of these changes can easily
be included in the PRF input when the nonce is calculated (it won't be heavy
work compared with the calculation of MAC) to make sure different nonces are
used when the authenticated content changes. 

Regards
(Continue reading)

Permalink | Reply | 0 comments |

Gmane