Subject: Re: Storage Security (was Re: NetBSD iSCSI HOWTOs)
To: Bill Studenmund <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 03/02/2006 21:08:46
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 02, 2006 at 07:03:52PM +1100, Daniel Carosone wrote:
> 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 poin=
> > that need OS support to handle. Specifically OS support that NetBSD and=
> > most other OSs lack.
> > Do we actually have socket controls necessary for the target to check i=
> > there is IPsec?
> Sure we do: inetd can use it, but not much else does that I'm aware of.
Hmmm. Ok. I'll look into it more.
> > 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 administrator=
> > 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
Well, given that iSCSI targets get appraised based on their GUI, if you=20
want IPsec widely-adopted, you should think a bit more. :-)
> > Oh! Be careful! You just wandered into the realm of channel bindings! O=
> > 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.
Maybe. One advantage though of channel bindings is that they are=20
independnet of the application's identities. Thus you don't have to teach=
every app about every IPsec identity form.
> > I think channel bindings are what's needed. It doesn't matter what IPse=
> > 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
Well, the thing is that the iSCSI spec doesn't describe an inter-operable=
way to identify IPsec identities wrapping the protection on a socket as a=
basis for iSCIS authentication. :-)
> > 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.
Well, part of it is due to how the security methods are supposed to be set=
up. So an automated test should notice the issue. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----