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

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=
ts=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 i=
f=20
> > there is IPsec?
>=20
> 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=
s=20
> > understand. Also, getting all of this into an appliance's GUI is not=20
> > simple.
>=20
> [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.

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=
r=20
> > at least partly into it.
>=20
> 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=
=20
every app about every IPsec identity form.

> > I think channel bindings are what's needed. It doesn't matter what IPse=
c=20
> > identities are used, as long as both ends agree on what they are.
>=20
> 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.

Well, the thing is that the iSCSI spec doesn't describe an inter-operable=
=20
way to identify IPsec identities wrapping the protection on a socket as a=
=20
basis for iSCIS authentication. :-)

> > So I don't think _that_ attack is there.
>=20
> 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=
=20
up. So an automated test should notice the issue. :-)

Take care,

Bill

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

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

iD8DBQFEB89eWz+3JHUci9cRAhBDAKCJFcgW8ymyRrjXoNM7vuKFpSkgjQCeJQMT
61jQ2onhMq18x0euP/xqTbo=
=IoiM
-----END PGP SIGNATURE-----

--sHrvAb52M6C8blB9--