Subject: Re: NetBSD iSCSI HOWTOs
To: Alistair Crooks <agc@pkgsrc.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 02/28/2006 08:40:18
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2006 at 08:44:57AM +0000, Alistair Crooks wrote:
> On Mon, Feb 27, 2006 at 08:39:34PM -0800, Bill Studenmund wrote:
> > You can't use samba to authenticate users using iSCSI. 1) there's no=20
> > defined auth method, and 2) iSCSI initiators aren't samba users. :-)
>=20
> It's always been a regret of mine that the people responsible for
> security in the iSCSI RFC just didn't understand the question.
>=20
> There's an excellent overview of the complete lack of any sort of
> security whatsoever in RFC 3720 in:
>=20
> 	http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-Dwivedi-update.=
pdf
>=20
> 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.

That's actually clean design. Rather than roll its own security system,=20
iSCSI uses IPsec. As noted in the RFC, IPsec is a MUST implement. Given=20
that IPsec is there, why would it be a good idea for iSCSI to implement=20
its own security schemes?

As to gaining access, the same holds true for your FC array. iSCSI, FC,=20
SAS, and SPI are transports, so they can't handle the at-rest issue.

> > The canonical way to restrict access to an iSCSI target is to use CHAP.
>=20
> Restricting access is one thing - protecting your data is another.
>=20
> iSCSI is only part of the equation - OSD goes the whole way, but the
> iSCSI proponents seem to have overlooked all of this.

Given that a number of the big names on the iSCSI list are big names on=20
the OSD list, I do not think they have overlooked things. I think the=20
solution just has to happen at a different level.

If you want to secure data at rest, you want either OSD or SBC-2's new=20
security stuff.

Take care,

Bill

--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEBHzyWz+3JHUci9cRAqULAJwI9MiMWYhaTJdKCO+mMazIg8mIUwCdHEkE
PYHwMt57FfV8DbiAJubKWOI=
=vfwb
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--