Subject: iSCSI Security mechanisms

From: [email-masked]
Date: Thu, 31 May 2001 15:14:11 -0400

At the risk of exciting this nest of hornets, here's
a summary of the current WG rough consensus on iSCSI
security requirements for implementations.  I'm doing
this both because I've received some off-line indications
of confusion and because the Nashua minutes aren't
as clear about this as they could be:

- In-band iSCSI authentication
	SRP - REQUIRED
	all other mechanisms - OPTIONAL

- Cryptographic communication integrity (these are
	all IPSec components):
	ESP with null encryption - REQUIRED
	ESP with non-null encryption - OPTIONAL
	AH - OPTIONAL
	IKE - OPTIONAL

I would note that anyone considering encryption
ought to be working on/with AES, not just 3DES.

This leaves open the issue of where the key(s) for
ESP come from.  IKE is OPTIONAL, and use of SRP to
supply keys for ESP is NOT REQUIRED (not even
specified - I need to find the time to work on
writing this up).  This leaves pre-shared keys as
the minimum mechanism, and hence I believe that
a suitably secured administrative interface to
supply pre-shared keys to ESP will have to be
REQUIRED for interoperability even if a dynamic
keying mechanism like IKE is implemented.

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: Bernard Aboba <[email-masked]>
Date: Thu, 31 May 2001 17:12:30 -0700 (PDT)

> keying mechanism like IKE is implemented.
Let me make sure I understand this:

a. You use SRP (which derives a key) only for authentication, but then
throw the derived keying material away. 

b. You then use IPSEC manual keying, along with an unspecified
transform, and key distribution mechanism. 

Note that what is described above is not really pre-shared secrets,
because those are used to authenticate DH in order to derive keying
material. Since you're not using derived keying material, we're really
talking about manual keying. 

I would suggest that the above manages to combine the computational
demands of IKE (and then some, since SRP is slower than ordinary DH)
the administrative headaches of manual keying and the interoperability
problems of specifying nothing. 

Ancient proverb: "The first step in removing yourself from a deep hole is
to stop digging." 

If you're going to do SRP for authentication, you might as well add in key
derivation, and negotiation of things like ciphersuites, prime
modulus/generator groups, etc. so you can use it for IPSEC keying. 
A rather small spec could accomplish this IF we decide it is necessary.

If don't want to use the SRP keying material, you might as well use a
slimmed down version of IKE (say, aggressive mode only) to address the
code size concern.