iSCSI Security rough consensus

[biran@il.ibm.com]

Just wanted to add that SRP with usage of its shared key for
ESP will be added as additional authentication method that
can be negotiated in the Login phase (maybe "SRP_WITH_ESP_KEYING").
I.e., SRP is mandatory to implement, SRP_WITH_ESP_KEYING is optional
as the rest of the authentication methods.

A very delicate issue that needs work in this SRP_WITH_ESP_KEYING
'method' is the synchronization of the ESP startup on both sides.
The intention is to keep the same TCP connection on which the Login
(and SRP exchange) occurred, and just turn on ESP to protect it,
from that 'sync point'.

If this works out OK, we can similarly use the shared key generated
by other optional authentication methods (i.e., define
KERB5_WITH_ESP_KEYING, SPKM_WITH_ESP_KEYING). For administrators
who want to use these methods, it may save the overhead of manual ESP
keying (assuming they buy minimal-compliant iSCSI, that is, without
IKE/certs).

  Regards,
    Ofer



Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253

---------------------- Forwarded by Ofer Biran/Haifa/IBM on 05/03/2001
11:01 AM ---------------------------

Black_David@emc.com on 05/03/2001 06:53:36 AM

Please respond to Black_David@emc.com

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI Security rough consensus




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