On Tue, Feb 28, 2006 at 07:58:21AM -0500, Thor Lancelot Simon wrote:
> On Tue, Feb 28, 2006 at 08:44:57AM +0000, Alistair Crooks wrote:
> > 
> > In particular, iSCSI doesn't offer any security worth even mention of
> > the word.  You *have* to use IPsec or a VPN to transfer the iSCSI
> > traffic.  This is your data that you have to protect, and anyone who
> > can gain access to your iSCSI target has access to *all* your data.
> 
> iSCSI people were very active in the IPsec working groups (in particular,
> they were among the earliest to agitate for transforms with larger block
> sizes, to allow static keying of ESP sessions that would transfer
> gigabytes or even terabytes of data).  I'm not sure what better solution
> than IPsec one might expect to find, for this application, really.
> 
> The profusion of application-layer encryption and authentication solutions
> needs to stop.  Really, it needed to stop some time ago.  When everyone
> designs his own cryptographic protocol "to meet the needs of his
> application" all you really get are dozens of similar protocols each with
> its own design flaws and implementation bugs.  I'm sure there are ways
> in which the design of iSCSI could have paid more attention to security
> but I for one am quite glad that it does not include yet another hand-
> rolled cryptographic protocol. :-/

RFC 3720 abrogates most of the responsibility for security, leaving
iSCSI as a cleartext protocol, with minor hooks in it for SRP,
Kerberos and CHAP.

iSCSI was/is being touted as the remote storage protocol of choice,
rightly or wrongly - people want low-cost appliances in the home
which attach to their LAN, and are just bit-holders.

This has all left the iSCSI proponents with a slight bit of egg on
their faces, trying to talk up CHAP as an authentication mechanism. 
The attempt to wedge Kerberos into existing infrastructure is an
interesting one, and not one I'd like to propose to CIOs.  SRP has no
takeup anywhere that I can see.  So we're left with IPsec, which, as
you note elsewhere, isn't available on a lot of platforms, and, even
if it was, is difficult to cram into the smaller appliances which
need to proliferate for iSCSI to win long-term.

FC usually doesn't run into any of these problems, since people who
have deployed FC usually have the money to buy dark fibre across town. 
So there is almost always a physical barrier providing protection for
Fibre Channel.  Since iSCSI (and iFCP and FCIP) uses existing IP
infrastructure, we now have to provide a bit more security than was
there before.  However, the level of the iSCSI protocol is such that,
if you can get access to the target, you can have access to all the
data.  It rather puts the buffer overflow kiddies to shame, going to
all that trouble to gain root access by infiltrating some webserver. 
If they can get access to the iSCSI target, they get access to ALL
data.

So iSCSI either needs lower-level security - a bump in the wire, or
IPsec, or some kind of VPN - or higher-level security - Kerberos,
or a VPN.

I don't think that the minor hooks in iSCSI are nearly enough.

Regards,
Alistair