iSCSI Security rough consensus

[Black_David@emc.com]

The rest of the Nashua minutes will be coming, but
this item is important enough to post on the list now.

The rough consensus on "mandatory to implement" iSCSI
security in the Nashua meeting was that the following
two items will be REQUIRED (mandatory to implement):

- ESP (part of IPSec) with NULL encryption.  This provides
	cryptographic integrity, and authentication, depending
	on how its keys are managed.  The rest of
	IPSec (e.g., IKE and AH) will be OPTIONAL.
- SRP for in-band authentication.  The remaining in-band
	authentication algorithms in the current iSCSI draft
	will be OPTIONAL.

There was also rough consensus in the meeting to pursue
a direction of using SRP to generate the keys for ESP,
and I asked whether there were problems
with the fact that such an approach would not permit
solutions that use an IPSec security gateway external
to an iSCSI implementation.

While there were no answers in the meeting,
I've gotten some strong "Yes, there are problems"
responses off line, and between them and the fact that
there are a bunch of details to work out in exactly
how to use SRP to key ESP, I would propose
that the security requirements be just the two
bullets above (i.e., ESP with NULL encryption and
SRP are REQUIRED).  This allows external gateways,
and keying of ESP with IKE or pre-shared keys,
and is consistent with the bulk of the discussion
in the meeting.

Although the approach of using SRP to key ESP has
a lot of promise, making it a requirement in advance
of a draft providing details that can be checked
by other security experts seems premature ... and
now I have to go help get that draft written
in my "copious spare time" ;-).  Once that draft
is in hand, we can make a concrete decision about
requiring that mechanism.

Also, the integrity hash and signature algorithm
that MUST be implemented for ESP w/Null Encryption
still need to be designated -- in consultation with
the security area and security experts (e.g., Ted
Ts'o, ipsec WG co-chair, who was at the Nashua
meeting) the hope is to bring a recommendation to the
WG in the near future.  A complicating factor is that
new hash algorithms are being introduced as a
consequence of the new AES/Rijndael cipher.  Requiring
such a new algorithm (e.g., as opposed to the current
SHA-1 or MD5) was discussed as a desirable direction
in the meeting, but there are a bunch of details
that need to be checked (e.g., state of IETF use
and standardization of those algorithms).

Comments to the list, especially if anyone disagrees
with the proposed requirements stated above.  Specific
input from security-knowledgeable folks on algorithm
selection should probably be sent directly to me, as
the IPS list is not the best forum for that purpose.

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