Subject: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and its use with IPsec' to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 15 Dec 2005 19:43:41 -0800

The IESG has received a request from an individual submitter to consider the
following document:

- 'The AES-CMAC-96 Algorithm and its use with IPsec '
    <draft-songlee-aes-cmac-96-03.txt> as a Proposed Standard

This document makes a normative reference to
draft-songlee-aes-cmac-03.txt, which is being considered for publication
as an Informational RFC.  While this normative reference could probably
be avoided, easy access to the CMAC algorithm description is desirable.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-01-12.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-96-03.txt

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Dec 2005 13:44:49 +0200

>     <draft-songlee-aes-cmac-96-03.txt> as a Proposed Standard

The IANA considerations section of this draft uses AES-CMAC-PRF-128
(probably cut & paste from PRF document), when it should use
AUTH_AES_CMAC_96 (or similar). To fix this change:

8. IANA Consideration
 
   IANA should allocate a value for IKEv2 Transform Type 3 (Integrity 
   Algorithm) to the AES-CMAC-PRF-128 algorithm when this document is
   published.

to

8. IANA Consideration
 
   IANA should allocate a value for IKEv2 Transform Type 3 (Integrity
   Algorithm) to the AUTH_AES_CMAC_96 algorithm when this document is
   published.
-- 
[email-masked]

---

From: [email-masked]
Date: Tue, 20 Dec 2005 17:53:06 +0200

If you want to negotiate the use of AES-CMAC-96 with IKEv1, you
also need numbers for AH Transform Identifier and ESP Authentication
Algorithm.

Other comments:

Overall comment: I'm not quite sure what's the value of having two
different specifications (800-38B and draft-songlee-aes-cmac) for the
same algorithm, especially since they don't contain the same text, use
different notations for describing the algorithm, etc.  I'd suggest
just having a reference to the NIST spec, and save effort for
everyone...

Section 1: "CMAC [NIST-CMAC] is a keyed hash function": IMHO not 
exactly the best terminology (the rest of the document uses 
Message Authentication Code, which is better)

Section 4: "The result of truncation should be taken in most
significant bits first order." Ok, this is a lowercase "should"
instead of a SHOULD, but something like "is" would be more
precise.

References: [XCBC] and [OMAC1] are never cited in the text (and
they're probably not normative). Probably [AH] should be normative.

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Tero Kivinen
> Sent: 16 December, 2005 13:45
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: IPsec WG; [email-masked]
> Subject: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and 
> its use withIPsec' to Proposed Standard
> 
> The IESG writes: