[tcpm] Guidance on selection of MAC algorithms for TCP-AO

Joe Touch <touch@ISI.EDU> Tue, 18 November 2008 19:48 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id BD8473A6B17; Tue, 18 Nov 2008 11:48:50 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 9ABF928C115 for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 11:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id ieUITsYcctEf for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 11:48:48 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu []) by core3.amsl.com (Postfix) with ESMTP id 873C028C0D8 for <tcpm@ietf.org>; Tue, 18 Nov 2008 11:48:48 -0800 (PST)
Received: from [] ([]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAIJmZCE024574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2008 11:48:38 -0800 (PST)
Message-ID: <49231C13.10303@isi.edu>
Date: Tue, 18 Nov 2008 11:48:35 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080914)
MIME-Version: 1.0
To: tcpm Extensions WG <tcpm@ietf.org>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: pasi.eronen@nokia.com, Russ Housley <housley@vigilsec.com>, Tim Polk <tim.polk@nist.gov>
Subject: [tcpm] Guidance on selection of MAC algorithms for TCP-AO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hash: SHA1

The following is posted on behalf of Tim Polk since it did not appear on
the list as intended (he may not be a subscriber).

Please CC this message in replies to include Tim, Russ, and Pasi on any


- ----

From: Tim Polk <tim.polk@nist.gov>
Date: Tue, 18 Nov 2008 17:13:07 -0000
To: <tcpm@ietf.org>
Cc: Russ Housley <housley@vigilsec.com>, Pasi Eronen
Lars Eggert <lars.eggert@nokia.com>
Subject: Guidance on selection of MAC algorithms for TCP-AO

TCP-AO needs to make two decisions with respect to MAC algorithms:
select algorithms for the current specification; and establish
criteria for specification of MAC algorithms in the future.  To be
honest, there are numerous MAC algorithms that could satisfy TCP-AO's
security requirements.  Pragmatic issues like performance and current
code bases need to be factored in as well.

The two most attractive options for generating the MAC are AES 128 in
the cipher-based message authentication code (CMAC) mode and the
SHA-1 Hash-based Message Authentication Code (HMAC).   Both options
provide a high level of security and efficiency.  The AES 128 CMAC is
potentially more efficient, particularly in hardware, but SHA-1 HMAC
is more widely used in Internet protocols and in most cases could be
supported with little or no additional code.

Another aspect of the algorithm selection is whether the tags should
be truncated.  CMAC-AES-128 produces a 128 bit MAC, and HMAC SHA-1
produces a 160 bit result.  The MAC can be truncated to 96 bits
provide a reasonable tradeoff between security and message size.  So,
the algorithms that were in draft-bonica are entirely reasonable
choices: AES-128-CMAC-96 and HMAC-SHA-1-96.  For interoperability,
the working group needs to either specify one MAC algorithm as a MUST
and the other as a SHOULD, or specify MUST implement for both

Note that the security issues driving the migration from SHA-1 to
SHA-256 for digital signatures do not apply here.  The security
strength of SHA-1 HMACs should be sufficient for the foreseeable
future.  In addition, when the tags are truncated to 96 bits it is
debatable if there is any increase in the security.

Since this document provides cryptographic agility, it is also
important to establish requirements for future MAC algorithms.  The
TCPM WG should restrict any future MAC algorithms for this
specification to ones that can protect at least 2**48 messages with a
probability that a collision will occur of less than one in a billion.

Tim Polk, Pasi Eronen, and Russ Housley
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

tcpm mailing list