[storm] iSCSI consolidated draft: IPsec topics

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

<WG Chair hat OFF>

This email is sent as the shepherd for the iSCSI consolidated draft.

Three issues have arisen around the iSCSI consolidated draft's
IPsec provisions.  In rough order from simpler to more complex,
they are:

a) Need to specify required key lengths
b) Scope of update to RFC 3723 (IP Storage Security)
c) Encryption Algorithm requirements

I don't think the first two are controversial, but the third one
may be.

-- a) Required key lengths

There are a bunch of requirements (MUST or SHOULD) for AES algorithm
implementation that don't specify a key length.

Proposal: The requirements apply to 128 bit keys.  Longer key lengths
(192 bits, 256 bits) are MAY requirements and hence don't need to be
stated.

-- b) Scope of IPsec update to RFC 3723 (IP Storage Security)

RFC 3723's IPsec profile was used by a number of protocols beyond iSCSI,
including FCIP, iFCP and the RDDP (iWarp) protocols.  The effects of
the update to that profile aren't obvious.

Proposal: List all the RFCs that pick up this update in the consolidated
iSCSI draft's "Updates" header and add some text to the Security
Considerations section to explain this.

-- c) Encryption Algorithm requirements

Here's what's currently in the consolidated iSCSI draft:

     - 3DES in CBC mode MUST be implemented [RFC2451].
     - AES in Counter mode SHOULD be implemented [RFC3686].
     - Implementations that support IKEv2 [RFC5996] SHOULD also
       implement AES GCM [RFC4106]

Aside from adding the 128 bit key size requirement, there are a
couple of other concerns:

(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.  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)

This would be accompanied by text that explains the birthday bound
effect of 3DES's 64 bit blocksize, and suggests that implementations
desiring hardware efficiency look to AES GCM rather than AES Counter.

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

------------------

Please comment.  I'll probably assume that a) key size and b) RFC 3723
IPsec update scope are ok in the absence of objection, but I definitely
want to see some discussion of c) encryption algorithm requirements.

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