Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

Tero Kivinen <> Mon, 03 March 2014 15:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8AD31A021B for <>; Mon, 3 Mar 2014 07:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dxWJtHq70p_B for <>; Mon, 3 Mar 2014 07:54:05 -0800 (PST)
Received: from ( [IPv6:2001:1bc8:100d::2]) by (Postfix) with ESMTP id 0C6971A0217 for <>; Mon, 3 Mar 2014 07:54:04 -0800 (PST)
Received: from (localhost []) by (8.14.7/8.14.5) with ESMTP id s23FrwN7020857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Mar 2014 17:53:58 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.7/8.12.11) id s23Frwj8018301; Mon, 3 Mar 2014 17:53:58 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 3 Mar 2014 17:53:57 +0200
From: Tero Kivinen <>
To: "Valery Smyslov" <>
In-Reply-To: <9618756DDA9C407AB0DC06AC207FD394@buildpc>
References: <> <9618756DDA9C407AB0DC06AC207FD394@buildpc>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 13 min
X-Total-Time: 13 min
Cc: ipsec <>
Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Mar 2014 15:54:06 -0000

Valery Smyslov writes:
> The draft lists the following trasforms based on AES cipher:
> AES-128-CBC
> All these transforms, except for AES-XCBC-MAC-96,
> allows to be used with different key lengths - 128, 192 and 256 bits.
> It looks strange to me that, unlike the others, AES-128-CBC
> has key length explicitely specified in the draft. Why it differs in
> this respect from the others? What about AES-192-CBC and
> AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-)

Hmm... actually we should most like use the same names we use in the
IANA registry. For example we have 3 different types of AES-GCM:

18   AES-GCM with a 8 octet ICV    [RFC4106]   [RFC5282]
19   AES-GCM with a 12 octet ICV   [RFC4106]   [RFC5282]
20   AES-GCM with a 16 octet ICV   [RFC4106]   [RFC5282]

Which one of those is the one that is moved to SHOULD+? Should we just
pick one of them, and say that it is the one we prefer, or should all
implementations implement all of them? AES-CCM has similar thing, but
as they are moving to MAY it does not really matter.

And yes, I agree the AES-128-CBC should be changed to AES-CBC. In the
RFC4305 and RFC4835 we had text like "AES-CBC with 128-bit keys", but
as we now have more AES modes, we should probably just add text saying
that for 128-bit keys for AES is MUST.

Also for AES-GMAC we need to decide which of the ones we are saying is

9	AUTH_AES_128_GMAC	[RFC4543]
10 	AUTH_AES_192_GMAC 	[RFC4543]
11 	AUTH_AES_256_GMAC 	[RFC4543]

> I think the draft should either:
> - remove explicit key length from AES-128-CBC and make it just
> - add explicit key length to all other AES-based transforms (except for 

AES-XCBC-MAC-96 is always defined to be have 128-bit key. The key
length cannot be negotiated when using the authentication algorithm,
it can only be negotiated for the encryption keys. Thats why the
AUTH_AES_*_GMAC authentication algorithms are defined as 3 different

> - leave things as is, but explain why AES-CBC differs in this respect from 
> the others

I think that is bad idea.

I think the best is to say that in general with AES encryption (GCM,
CBC, CCM etc) we assume the key length is 128-bits. (i.e. the
MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is
also for 128-bit keys with x octect ICV).