Subject: Re: NetBSD iSCSI HOWTOs
To: Alistair Crooks <agc@pkgsrc.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 02/28/2006 23:19:50
--V88s5gaDVPzZ0KCq
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:
> > On Mon, Feb 27, 2006 at 05:48:25PM +1000, Ray Phillips wrote:
> 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.

Oh, this talk. I've seen it before, and while he does highlight some good=
=20
points, he does talk a lot. His use of "iQN" was, uhm, silly.

I see two problems with the talk:

1) He recommends vendors implement Kerberos. The problem is that the=20
kerberos in the iSCSI RFC is dead; it will never happen. :-(

2) He describes an attack where an initiator uses a second connection to=20
get the target to generate the response needed to authenticate. I see two=
=20
issues with this:

a) initiators and targets aren't supposed to use the same passwords (nor=20
the same CHAP names), thus the response shouldn't work.

b) I don't think any target actually will do mutual before the initiator=20
has done it. If it will, then we need to close that hole in the spec. :-)

Take care,

Bill

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

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

iD8DBQFEBUsWWz+3JHUci9cRAvVdAJ98EXOhXJdeYk/dgT4iDjHg/vVYjACeJoox
0OeZ5ty/mVH+DbV3a+Aunz0=
=3Z2K
-----END PGP SIGNATURE-----

--V88s5gaDVPzZ0KCq--