Subject: iSCSI IPsec-Related Algorithm Proposal

From: "Herbert, Howard C" <[email-masked]>
Date: Fri, 29 Jun 2001 16:47:19 -0700

David:

Progress on completing the iSCSI draft RFCs is extending past the
development deadlines necessary to allow 2002 product teams to complete
their designs.  One open issue relates to selecting the specific IPsec ESP
integrity (mandatory to implement) and confidentiality (optional to
implement) algorithms for use with iSCSI.  Members of the working group have
been focused until now on algorithms that would scale to 10 Gbit/sec.  Even
though progress has been made at identifying promising candidate algorithms
(AES-based PMAC Mode for integrity and AES-based Counter Mode for
confidentiality - see http://csrc.nist.gov/encryption/modes/), this work
will not be completed in time for inclusion in 2002 products.

As a result, I would like to propose to the iSCSI Working Group a two-phase
strategy for selecting the specific IPsec ESP integrity and confidentiality
algorithms for use with iSCSI.  Since almost all 2002 products will be using
1 Gbit/sec interfaces, phase one products would standardize on already
approved IPsec ESP algorithms that can be scaled to 1 Gbit/sec and phase two
products (i.e., 2003) would standardize on algorithms that can be scaled to
10 Gbit/sec.

Specifically, phase one products would use AES CBC MAC mode as the integrity
algorithm and AES CBC mode as the confidentiality algorithm.  This proposal
means vendors only have to implement a single base-algorithm with slight
mode variations in order to have a complete 1 Gbit solution (integrity and
confidentiality).  Adopting AES in phase one also establishes a foundation
upon which to build phase two solutions (different modes of operation on the
same base algorithm).

While this proposal only addresses a small part of the total "iSCSI
security" problem.  It would allow silicon vendors to finalize a critical
part of their 2002 designs.
 
Thanks

Howard C. Herbert

Product Architect
Intel Corporation
LAN Access Division
Phone: 480-554-3116

---

From: [email-masked]
Date: Fri, 29 Jun 2001 20:24:54 -0400

> upon which to build phase two solutions (different modes of operation on
the

What would you recommend as reference specifications for these algorithms,
and specifically their use with ESP?  There are no RFCs specifying this,
and I haven't seen an Internet-Draft on the MAC (there is one on use of 
AES for confidentiality).  My personal preference would be for something
AES-based (perhaps using one of the new SHA hashes in an HMAC instead
of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES.

Meanwhile, we have another issue.  As of the outcome of the Nashua meeting,
the minimum (MUST implement) requirement for keying ESP was manual keying.
That's not going to be sufficient because there will be situations in which
iSCSI
causes ESP's 32-bit sequence number to roll over, creating a vulnerability
to
replay attacks.  This is going to require specification of a MUST implement
rekeying algorithm.  IKE or a subset is one possibility, and working out the
details of SRP-based keying (and rekeying) of ESP is another.  A somewhat
drafty draft on the latter may appear prior to London assuming that I can
find
the "copious spare time" to get it written.

Comments?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 30 Jun 2001 19:12:43 +0300

I think security issues go beyond the rekeying and I doubt that manual
keying is an
acceptable solution (not even as a starter) as it creates a management
nightmare even in moderately
sized installations and is barely supported in host systems (manually
inserting keys AND SPIs).

Howard is has a good point about schedules. and he is also pointing us
towards
a solution - select a minimum subset and get fast in place a keying
mechanism that is both well understood and accepted.

Julo

[email-masked] on 30-06-2001 03:24:54

Please respond to [email-masked]

To:   [email-masked], [email-masked]
cc:
Subject:  RE: iSCSI IPsec-Related Algorithm Proposal

rekeying algorithm.  IKE or a subset is one possibility, and working out

Comments?

Thanks,
--David

---

From: [email-masked]
Date: Sat, 30 Jun 2001 19:12:43 +0300

Julo

Comments?

Thanks,
--David