--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 01, 2006 at 07:22:01AM +0000, Alistair Crooks wrote:
> 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.

Alistair, what exactly do you want? You seem to be upset, but I'm not=20
seeing any issues that can be changed.

Yes, iSCSI is clear text. That's by design. Some users have dedicated LANs=
=20
for iSCSI traffic; they duplicated the FC model. Such a configuration is=20
the recommended best-practice from Microsoft.

Other users don't really care.

Yes, IPsec implementation has been slow, but it is happening. And it will=
=20
continue to happen.

> 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.
>=20
> 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.=20

What exactly is wrong with CHAP?

The one issue I can see is that it uses MD5. However SHA1 is usable as=20
more vendors implement it. Since David Black was the person who got SHA1=20
added, I don't think other SHAs will be a problem.

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

Uhm, IPsec is not used as an authentication method in iSCSI. It's used for=
=20
privacy. Authentication happens in-band and uses the other methods you=20
mention.

> 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.=20
> 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.=20
> If they can get access to the iSCSI target, they get access to ALL
> data.
>=20
> 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'm still unclear on your point. If you'd asked anyone in the iSCSI=20
working group about this (and they were awake), they'd have said the same=
=20
things.

iSCSI isn't supposed to do everything itself. The IETF has tried that,=20
and, as Thor noted, isn't happy with it. By using IPsec, iSCSI leverages=20
the security work of a number of other working groups, and will be better-=
=20
off in the end.

Take care,

Bill

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEBiTZWz+3JHUci9cRAmCjAKCMeCpmzWV/9wZCimGKWlc7Rc+FcwCbBcLO
EyO8kFjNFc/htzeVh9Pk/ek=
=ULF9
-----END PGP SIGNATURE-----

--FCuugMFkClbJLl1L--