Re: [storm] iSCSI consolidated draft: IPsec topics

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

Having seen no objection to this, I think we have WG rough
consensus for all three of these IPsec items:

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

However the next steps from here are different for each item:

-- a) Required key lengths

Mallikarjun should go ahead and add the appropriate text to the iSCSI
consolidated draft to say that 128 bit AES keys are REQUIRED, and
other key lengths are OPTIONAL.

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

We will need to update 3723 and *everything* that references it -
iSER turned out to be the forcing function here, as it requires
the RFC 3723 IPsec profile to be updated for both iSCSI and the
iWARP (rddp) protocols, otherwise the result for iSER over iWARP
is bizarre (two different IPsec profiles).

In 20/20 hindsight (e.g., I wish I'd thought of this over the holidays
at the end of last year), I now think the "right thing" to do here is to
write a separate draft that contains the IPsec updates to 3723, and anything
else that needs to be changed there.  That'll help people who just want
to understand the IPsec changes, and it'll cut down the list of RFCs
that the consolidated iSCSI RFC updates, as RFC 3723 is cited by 19 RFCs:

	http://www.arkko.com/tools/allstats/citations-rfc3723.html

That can't be done yet, because ...

-- c) Encryption Algorithm requirements

I need to take these to the ipsecme WG mailing list and meeting this week
in Orlando to get them checked by the experts on this. Stay tuned ...

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Black, David
> Sent: Tuesday, January 01, 2013 8:13 PM
> To: [e-mail]
> Subject: [storm] iSCSI consolidated draft: IPsec topics
> Importance: High
> 
> <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]
> ----------------------------------------------------
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm