Subject: RE: Open Questions on iSCSI 07 security

From: [email-masked]
Date: Fri, 17 Aug 2001 17:53:09 -0400

For SRP, check the associated text key definitions in the -07 draft.
The one issue I know of is that the current specification allows
arbitrary groups, and we probably need to select a few for which
support is REQUIRED.

Algorithms for confidentiality and integrity, along with selection
of a keying/rekeying approach are on the Orange County agenda.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 17, 2001 5:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Open Questions on iSCSI 07 security
> 
> 
> I have been reading the iSCSI security in the drafts s (06, 
> 07) and David's paper on the iSCSI security issues. I have a 
> few questions that seem to (me to) remain unaswered. If they 
> are already answered, I'd welcome the answers; if not - I 
> suggest we include these in the discussions on 8/28th at Irvine.
> 
> AUTHENTICATION: The 06 level states authentication is a MUST 
> and the 07 level states that SRP is a MUST. But the SRP RFC 
> does not provide sufficient details on formats and protocols 
> that will be needed to allow 
> interoperability among different implementation.
> 
> A related development is the SLAP protocol from Brocade that 
> uses PKI for authentication and possibly other use. Any 
> suggestions on converging the two approaches for 
> authenticating storage devices: iSCSI or otherwise.
> 
> DATA INTEGRITY: This is a MUST in 06 level. But no algorithm 
> has been identified. The draft does state that IPSec can be 
> used here - and IPSec requires use of HMAC-MD5 and HMAC-SHA 
> 1, and a few optional. It'd perhaps be better to state in the 
> iSCSI standard the specific chosen algorithms for iSCSI Data 
> Integrity. 
> 
> CONFIDENTIALITY: I agree with David that we must specify the 
> algorithm, whther that's OPT or a MUST.
> And what about key exchange (IKE, D-H etc.)? Also, IPSec, as 
> far as I can tell, not yet blessed AES - perhaps we should 
> address this.
> 
> Thanks, Vijay
>