[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+
RE: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to = SHOULD+
Although I have seen discussions of using AES for a = PRF function on
the IPSec mailing list, I am unaware of a formal = definition that is
documented in a draft. = draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no
mention of a prf function, as far as I can tell. If = PRF_AES128_CBC
is to be either a SHOULD or a SHOULD+, then someone = first needs to
define it somewhere. Would one of the proposers of = this algorithm please
provide a draft?
David Blaker, VP System Engineering
From: Paul Hoffman / VPNC [<3d.htm>mailto:email@example.com]<= /FONT>
Sent: Tuesday, June 03, 2003 7:35 PM
Subject: Promoting PRF_AES128_CBC and = AUTH_AES_XCBC_96 from SHOULD to
Greetings again. draft-ietf-ipsec-algorithms lists = the following
4.1.4. IKEv2 Transform Type 2 Algorithms
Transfer Type 2 Algorithms are pseudo-random = functions used to generate
random values when needed.
= Name Number Defined In Status
= RESERVED 0
= PRF_HMAC_MD5 = 1 = [RFC2104] MAY
= PRF_HMAC_SHA1 = 2 = [RFC2104] MUST
= PRF_HMAC_TIGER = 3 = [RFC2104] MAY
= PRF_AES128_CBC = 4 [CIPH-AES] = SHOULD
It lists the following for integrity = algorithms:
4.1.5. IKEv2 Transform Type 3 Algorithms
Transfer Type 3 Algorithms are Integrity algorithms = used to protect
data against tampering.
= Name Number = Defined In Status
= NONE 0
= AUTH_HMAC_MD5_96 = 1 = [RFC2403] MAY
= AUTH_HMAC_SHA1_96 = 2 = [RFC2404] MUST
= AUTH_DES_MAC = 3 = ; = ; MAY
= AUTH_KPDK_MD5 = 4 = [RFC1826] MAY
= AUTH_AES_XCBC_96 = 5 = ; = ; SHOULD
Some implementers have said that they would like to = use
PRF_AES128_CBC and AUTH_AES_XCBC_96 when they use = AES for encryption
in constrained hardware. Basically, why implement = PRF_HMAC_SHA1 and
AUTH_HMAC_SHA1_96 when PRF_AES128_CBC is good enough = and it will
clearly take less silicon. I followed this logic = when I specified
PRF_AES128_CBC and AUTH_AES_XCBC_96 in the VPN-2 UI = suite.
I propose that PRF_AES128_CBC be listed as SHOULD+ = instead of SHOULD
so that implementers know that they should be = implementing it soon.
Otherwise, I should change the VPN-2 UI suite to use = PRF_HMAC_SHA1
Does anyone object to raising these two uses of AES = to SHOULD+?
--Paul Hoffman, Director