[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 CyberGuard Corporation -----Original Message----- From: Paul Hoffman / VPNC [<3d.htm>mailto:paul.hoffman@vpnc.org]<= /FONT> Sent: Tuesday, June 03, 2003 7:35 PM To: ipsec@lists.tislabs.com Subject: Promoting PRF_AES128_CBC and = AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Greetings again. draft-ietf-ipsec-algorithms lists = the following pseudo-random functions: 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 and AUTH_HMAC_SHA1_96. Does anyone object to raising these two uses of AES = to SHOULD+? --Paul Hoffman, Director --VPN Consortium