Subject: RE: iSCSI IPsec-Related Algorithm Proposal

From: "Herbert, Howard C" <[email-masked]>
Date: Mon, 2 Jul 2001 11:22:23 -0700

David:

I will find out if anyone is writing a AES CBC MAC draft over in the IPsec
WG.  If no one has started, then I will sign up to producing one.

Also, Steve Kent's sequence number proposal DID NOT change the format on the
wire (at least that is what he says on slide #3).

I think we are going to have to come to terms with folks who want to use IKE
in this application.  The functionality already exists in the major host OSs
and HBA vendors are going to want to take advantage of that fact (one less
thing to add).  Maybe the trick here is to define a subset of the IKE
functionality that limits the impact to target vendors.  If we can do so,
would you consider making IKE mandatory to implement?

Howard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 02, 2001 10:56 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI IPsec-Related Algorithm Proposal

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

I'd suggest writing a draft on the use of the AES CBC MAC
with ESP and starting it through the IPsec WG, as I think
that would have to come out as an RFC at the same time as
iSCSI in order for iSCSI to use it.  Such a draft will also
be necessary to get an ISAKMP value allocated for the MAC,
which will be needed independent of whether iSCSI uses IKE.

Absent such a draft, we may be left with no choice but to use
one of the SHAs (or MD5).  FWIW, there are chip vendors who
are claiming the ability to do SHA-1 at multi-gigabit speeds,
so I don't think scaling to 1Gbit/sec is a showstopper.  OTOH
I would agree that whether any of the SHA algorithms can be
effectively scaled to 10 Gbit/sec in the near future is
an open issue.

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

I'm familiar with Steve's presentation, as I was in the
room in San Diego when he gave it.  What he described
is a worthy goal, but is not compatible on the wire with
current ESP.  If iSCSI were to depend on this, iSCSI would be
likely to get caught in a security document hairball/tarball
behind a whole pile of potentially pending revisions to
IPsec (e.g., iSCSI will depend on an ESP rev that depends
on "son of IKE").  I don't recommend this if the goal is
to get a stable iSCSI document completed in a timely fashion.

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

Writing drafts that will become the "missing RFCs" is a
better approach, and (as indicated above) I would stay
away from any basic revisions to ESP.

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: [email-masked]
Date: Mon, 2 Jul 2001 14:43:49 -0400

Howard,

> WG.  If no one has started, then I will sign up to producing one.

Thank you.

> wire (at least that is what he says on slide #3).

True, BUT ... it does change the data over which the authentication (MAC)
algorithm is run (two bullets above on the same slide) - the 16 bits that
aren't
on the wire are included in the authentication/integrity check.  Before
anyone
draws the wrong conclusion, Steve also proposed that this behavior be
negotiable on a per-SA basis for backwards compatibility.  This change
really
needs to be made via a modification to RFC 2406 (the basic ESP RFC), hence
the concern about the security document hairball/tarball.  OTOH, I was just
involved in the new ECN RFC (coming soon from the RFC Editor) which
managed to "update" RFC 2401 (IPsec architecture) without getting hung
up, so this sort of modification isn't completely out of the question.

> would you consider making IKE mandatory to implement?

It's up to the WG, but I have no fundamental problem with
an IKE subset ... and I've been independently pursuing a
set of volunteers to work on such a subset - want to join
the party?

Thanks,
--David

---

From: "Herbert, Howard C" <[email-masked]>
Date: Mon, 2 Jul 2001 11:58:09 -0700

Points on the hairball/tarball noted - things are sticky enough already.

For the IKE subteam - Sure, sign me up.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 02, 2001 11:44 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI IPsec-Related Algorithm Proposal

Howard,

Thank you.

Thanks,
--David

---

From: [email-masked]
Date: Mon, 2 Jul 2001 13:56:02 -0400

not
December

Thanks,
--David

---

From: "Herbert, Howard C" <[email-masked]>
Date: Mon, 2 Jul 2001 14:45:21 -0700

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:[email-masked]]
Sent: Monday, July 02, 2001 11:51 AM
To: Herbert, Howard C; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]On Behalf Of
Herbert, Howard C
Sent: Monday, July 02, 2001 9:49 AM
To: [email-masked]'; [email-masked]
Subject: RE: iSCSI IPsec-Related Algorithm Proposal

David:

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

Howard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 29, 2001 5:25 PM
To: [email-masked]; [email-masked]
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