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

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

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, while the length of BGP
part (that part that will change) will be ranged from 19 to 4096 bytes. Thus
difference of packets is not small. Please let me know if there are good
ways to use incrementality in BGP or other scenarios.

Thank you and happy new year to all!
Regards,

Sean

-----Original Message-----
From: mcgrew [mailto:mcgrew@cisco.com] 
Sent: Thursday, December 20, 2007 11:50 PM
To: Brian Weis
Cc: saag@mit.edu; cfrg@ietf.org
Subject: [Cfrg] Re: [saag] TCP-AO MAC algorithms

Hi Brian,

I've cross-posted to CFRG to tie the TCP Auth work in with
draft-irtf-cfrg-fast-mac-requirements draft.

On 12/18/07 4:23 PM, "Brian Weis" <bew@cisco.com> 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). Two MACs with differing internal constructions are
> desired.

I assume that the reason for having two mandatory-to-implement MACs is to
ensure algorithm agility.

> 
> In my opinion, it is also important that MACs defined by an Internet
> standard as required to be implemented be based on NIST-approved
> algorithms and modes, and also be generally available in both
> software and cryptographic hardware.
> 
> The following two MACs are reasonable recommendations that taken
> together easily meet the above criteria: HMAC-SHA-1 and AES-CMAC. I
> propose that these be the algorithms provided to the TCPM WG.
> 
> Brian

Sounds like reasonable choices to me.

It would be good to have a MAC that performs exceptionally well in software,
along the lines of what we've targeted in
draft-irtf-cfrg-fast-mac-requirements, but if the choice of MACs has to be
made *today*, there may not be a suitable candidate that has been
sufficiently specified and/or reviewed.  I expect that MACs that will be
more suitable for use in TCP Authentication will be developed (candidates
include [1] and [2]).  I trust that there is a path for the adoption of new
MACs in TCP Auth.  

Probably the biggest open question is the length of the MAC.  The CMAC
specification states that lengths 64 bits and higher are acceptable, but
that smaller values "shall only be used in conjunction
with a careful analysis of the risks" [1].  It would be good to do this
analysis for TCP Auth, of course, but it is encouraging that AES-128-CMAC
could be used with a 64-bit tag and still meet the conformance goals that
you outlined. 

Best regards, 

David

[1] J. Black and M. Cochran, "MAC Reforgeability",
http://eprint.iacr.org/2006/095

[2] D.J. Bernstein, "Polynomial evaluation and message authentication",
http://cr.yp.to/antiforgery/pema-20071022.pdf

[3] M. Dworkin, NIST Special Publication 800-38B, "Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Authentication"
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg