Re: Security Use Requirements

[Sean Quinlan <seanq@bell-labs.com>]

Black_David@emc.com wrote:
> 
> Before I launch into the latest response to Josh, I want to
> summarize the high level point I'm trying to make:
> 
>         It isn't enough to just point to existing security mechanisms and
>         say "use these".  It's necessary to say how to use them with
>         the protocol and what other assumptions must be true in order
>         to achieve the desired security properties - some of these
>         assumptions will be requirements on other components/protocols
>         in the environment.
> 

This has been an interesting thread to read.  I could not resist adding a
few comments of my own.

Many posts ago, there was mention of three levels of security for iSCSI
        
	1: none
	2: iSCSI authentication
	3: tls or IPsec

these level seems to correspond to what is in the version 3 draft.

The trend in the current discussion seems to be that security must be implemented.
Correct me if I am wrong, but I am under the impression that fibre channel currently
is used at level 1 (although there is CRC).  I was also under the impression that
one of the main motivations of iSCSI was the belief that ethernet would win over
Fibre Channel as a network technology and hence the desire to send SCSI over ethernet.
Assuming this is the case, it would appear that there is a ready market for devices
that have no security and are attached by dedicated ethernet based SAN.  I would assume
that if iSCSI ever becomes the interface to disk drives then the no security option
would be popular for such devices with the assumption that the drives are combined
within boxes that have security implemented at the outer level.  I doubt that drive
manufacturers would be very keen to implement IPsec in their devices...

the current draft of iSCSI describes a rather large selection of authentication options
for both login and per PDU.  When reading the text I get the impression that iSCSI
will support both login and data authentication, but the draft is missing many details
I would expect - for example what is the key to use for hmac-md5-96.  The impression
I get from the posts is that iSCSI will NOT support data authentication because it
is considered too hard to get security right.  I agree that getting security correct is tough,
but data authentication is well understood and not very tough at all.  All the
difficulty is in the session authentication and session key generation - which it
appears iSCSI will support.  In my opinion, iSCSI would be better off with fewer
session authentication methods - perhaps just SRP - and with a well defined
data authentication method.  I know people on this list disagree.. but with a little
work I think iSCSI could achieve a high level of data integrity without the
complexity of tls or IPsec.  Assuming iSCSI will support session authentication, the
work required to include data authentication is relatively small.  A small aside...
at least in software and on modern CPUs, hmac-md5-96 and CRC32 take about the
same amount of time to compute.

Obviously, iSCSI should be able to take advantage of security methods such as TLS and IPsec.
I would suggest that iSCSI would be better off if it left all use of public keys to
such protocols and avoid using them in iSCSI authentication.  Perhaps the same can be said for
all encryption.  On the other hand, I think people need to be aware that TLS and
IPSEC/IKE are rather massive entities themselves - As a point of reference, OpenSSL - a
free version of TLS is over 140K lines of C - by comparison, all of Berkeley TCP/IP is 40K.
Just dealing with X509 certificates is a nightmare itself 		http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
I know you can use TLS and IPsec without buying into the whole Certificate Authority/
Revocation List mess, but then you need to describe what you are planning to use as an alternative.
I suspect if iSCSI mandates that iSCSI implementations must also implement IPsec, their
will be a lot of products that punt by stating an IPsec gateway must be used...

just my two cents...