RE: iSCSI Security rough consensus

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

I do not understand what a requirement for SRP to
generate keys for ESP/IPSec would add to security,
especially if IPSec and iSCSI are implemented on the
same box.  Could you summarize why this recommendation
was made?  (unfortunately, I missed this part of the
meeting to catch a plane)

Thanks,
Josh

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, May 02, 2001 8:54 PM
> To: ips@ece.cmu.edu
> 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
> ---------------------------------------------------
>