Subject: Re: Storage Security (was Re: NetBSD iSCSI HOWTOs)
To: Bill Studenmund <wrstuden@netbsd.org>
From: Daniel Carosone <dan@geek.com.au>
List: current-users
Date: 03/02/2006 19:03:52
--LMmSgwdUwKH/sMG1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 01, 2006 at 09:52:13PM -0800, Bill Studenmund wrote:
> Ok, I'd like to run with this discussion as you bring up some good points=
=20
> that need OS support to handle. Specifically OS support that NetBSD and=
=20
> most other OSs lack.
>=20
> Do we actually have socket controls necessary for the target to check if=
=20
> there is IPsec?

Sure we do: inetd can use it, but not much else does that I'm aware of.

> To be honest, the administration is the bad part. Not only are there=20
> issues with what parts a given OS supports, but also what administrators=
=20
> understand. Also, getting all of this into an appliance's GUI is not=20
> simple.

[aside] I'm less fussed about the GUI, personally.  If we're at the
point where it can be put in a GUI reasonably well, most of the
serious problems have been resolved and all that remains is the
GUI-making.

> Oh! Be careful! You just wandered into the realm of channel bindings! Or=
=20
> at least partly into it.

Heh, I just knew you'd say that :) Channel bindings might be one
approach, but other binding styles might also be usefule/able.

> I think channel bindings are what's needed. It doesn't matter what IPsec=
=20
> identities are used, as long as both ends agree on what they are.

And as long as you can use that identity in iSCSI configuration - as
one example, listing an IPsec-authenticated client name at a dynamic
IP address in the target's config.  As I said later, though, for a
strong host that placed littel reliance on the storage system, this
would mostly be useful to prevent attackers overwriting all your
blocks.

> So I don't think _that_ attack is there.

Fair enough, if people read the standards and the "don't to that"
stuff, although I think the chances of muppets doing the same-key
thing anyway are high enough for it to still be a concern - whoever's
fault the silly config might be.

--
Dan.



--LMmSgwdUwKH/sMG1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEBqboEAVxvV4N66cRAnuDAKCgNjo02CsUvnn7DflG7w77qd46lwCfYMEK
kQIOIxQMTkoHAy35t61w6i0=
=pvXb
-----END PGP SIGNATURE-----

--LMmSgwdUwKH/sMG1--