Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD toSHOULD+

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

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