RE: iSCSI IPsec-Related Algorithm Proposal

["Herbert, Howard C" <howard.c.herbert@intel.com>]

No issue that SHA-1/3DES can be scaled to 1 Gbit.

I am just trying to avoid creating legacy implementations that will not
scale to 10 Gbit that I then have to keep around for backward compatibility
with the original 1 Gbit implementations (i.e., I only want to have to put
"one" algorithm into hardware not "three").

Howard

-----Original Message-----
From: Joseph Tardo [mailto:jtardo@broadcom.com]
Sent: Monday, July 02, 2001 11:51 AM
To: Herbert, Howard C; Black_David@emc.com; ips@ece.cmu.edu
Subject: RE: iSCSI IPsec-Related Algorithm Proposal


Howard:

These proposals have been discussed in the IPsec WG but not much progress
has actually been made. It remains to be seen what happens in London, but
"quick alignment" is perhaps optimistic.

To adopt AES and longer sequence numbers for iSCSI means potentially holding
up the RFC until IPsec completes its part. Interlocking standards even
within the security WG itself created undesirably long delays in the past.
It also severely limits implementation options until interoperable products
supporting these features become available.

On another note, I would also take issue with your assertion that SHA-1
would be impractical at Gigabit and beyond but AES in 128-bit block CBC
feedback mode MAC would work. This has not been the case as far as I have
seen. Do you have anything to substantiate this?  Gigabit 3DES+HMAC products
are available today.

By the way, sequence space exhaustion is only one motivation for re-keying.

--Joe

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Herbert, Howard C
Sent: Monday, July 02, 2001 9:49 AM
To: 'Black_David@emc.com'; ips@ece.cmu.edu
Subject: RE: iSCSI IPsec-Related Algorithm Proposal


David:

CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17).
These standards used DES as the algorithm.  We just need to substitute AES
for DES.  Another excellent reference can be found in section 9.5.1 in
"Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone.
Use of any other algorithms (e.g., one of the new SHAs) raises concerns
about being able to scale to 1Gbit/sec.

On the second issue, even if you specify a re-keying algorithm that does not
solve your problem.  You must also extend the size of the sequence number
field itself so that you are not having to re-key as often.  At the December
2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering
AES CBC MAC and sequence number rollover (see attached presentation).  If
the sequence number space were increased to per Steve's proposal, that may
also make "manual" re-key viable for the short term (i.e., 2002 products).

I would expect that we could achieve quick alignment with the IPsec WG on
these issues, have the IPsec WG generate any missing RFCs (if they are not
already doing so), and reference them in our specification.

Howard



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, June 29, 2001 5:25 PM
To: howard.c.herbert@intel.com; ips@ece.cmu.edu
Subject: RE: iSCSI IPsec-Related Algorithm Proposal


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

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
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------