[IPsec] storm WG: Updating RFC 3723's IP Storage profile of IPsec

["Black, David" <[e-mail]>]

In connection with updating iSCSI, the storm WG is going to need to update
the IP Storage profile of IPsec in RFC 3723.  I'm sending this note to
the ipsecme WG now, as I think this is related to the discussion of
cryptographic algorithm requirements on Tuesday.

**IMPORTANT**: The RFC 3723 profile of IPsec differed from the cryptographic
algorithm requirements for IPsec v2 (24xx RFCs) on which RFC 3723 was based,
and I expect this to continue to be true for the update to RFC 3723 wrt the
new cryptographic algorithm requirements.

Chairs - I'd be willing to put up a slide or 2 on this at the meeting if you
think that would be useful.

-- RFC 3723

Here's what RFC 3723 had to say about cryptographic algorithms:

   To provide confidentiality with ESP, ESP with 3DES in CBC mode
   [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as
   described in [RFC3686], SHOULD be supported.  To provide data origin
   authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be
   supported, and AES in CBC MAC mode with XCBC extensions [RFC3566]
   SHOULD be supported.  DES in CBC mode SHOULD NOT be used due to its
   inherent weakness.  ESP with NULL encryption MUST be supported for
   authentication.

-- Data Integrity and Origin Authentication changes

The only proposed change for these algorithm requirements is to add:

     - Implementations that support IKEv2 [RFC5996] SHOULD also
       implement AES GMAC [RFC4543] 

-- Encryption Algorithm changes

This one's a bit more involved, because there are concerns with
both of the encryption algorithms for which RFC 3723 stated requirements.

(1) The MUST for 3DES-CBC has become questionable due to 3DES's
64 bit block size, i.e., the core cipher encrypts or decrypts 64 bits
at a time.

Things start to go awry cryptographically as one approaches the
birthday bound of 32GB (GigaBytes) of data encrypted under the
same key.  As a reminder, here are a couple of links:

http://www.ietf.org/mail-archive/web/ipsec/current/msg07997.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg08031.html

How far away to stay from that bound is a judgment call, but 32GB
or some fraction thereof is not a lot of data for iSCSI to move.

One could deal with this via rekeying, but the result will be
rather frequent rekeying if one decides to stay at least an order
of magnitude away on a multi-gigabit/sec link.

In contrast, AES has a 128 bit blocksize, and so its birthday
bound is astronomical (2^69 bytes if I have the math right).

AES CBC is the most common mandatory-to-implement mode for
interoperability.

(2) AES CTR was originally selected for its hardware friendliness
(e.g., it pipelines well), even though there was no hardware
friendly integrity MAC algorithm to go with it at the time.  AES GCM
is now the strongly preferred choice, as it provides encryption
and a MAC.

... Now comes the fun ...

Proposal (w/o RFC citations, all AES requirements are for 128 bit keys):

     - 3DES in CBC mode MAY be implemented (previously MUST)
     - AES in CBC mode MUST be implemented (previously implicitly MAY)
     - AES in Counter mode MAY be implemented (previously SHOULD)
     - Implementations that support IKEv2 SHOULD also
       implement AES GCM (new requirement)
     - DES MUST NOT be implemented or used (previously SHOULD NOT)
     - NULL encryption MUST be implemented (no change)

The intent is that these requirements are readily met by widely
available IPsec implementations.

Thanks,
--David (storm WG co-chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------