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

On Thu, Mar 02, 2006 at 11:59:40AM +1100, Daniel Carosone wrote:
>=20
> The problem with iSCSI from my perspective, as is often the case with
> things that rely on a loose layering of various (individually good)
> components, is that the configuration and administration are harder
> than they should be, and that the assurance that things are working as
> intended (if users actually get that far).
>=20
> If the standard mandates that iSCSI implementations include IPsec
> implementations as well, and vendors sell one without the other,
> that's a clear issue and problem, and those vendors deserve all the
> business they don't get as a result.  Leave them aside and lets
> restrict ourselves to offerings that include the full complement of
> iSCSI and IPsec mecahnisms.

Sounds reasonable. Also, aggressive IPsec support will generate customer=20
demand and thus motivate implementations to follow along.

> As an illustration (not a criticism of our current target).  I can
> configure the netbsd target to respond to iscsi requests. I can
> configure whatever the host O/S running the target to use IPsec for
> that traffic.  I can configure whatever client OS / HBA is running the
> initiator to also use IPsec.  Hopefully it all works at that point,
> and I don't give up before I get there. However, even then, there's
> little assurance that this is working, because there are very loose
> bindings between the app and IPsec: I can't configure the target
> serving up the data to use the relevant socket controls to check that
> the traffic actually was IPsec encrypted, let alone use any of the
> other information from the SA for stronger restrictions on access by
> (say) authenticated hostname.

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.

Do we actually have socket controls necessary for the target to check if=20
there is IPsec?

In all honesty, I think we want socket-level SPDs, not host-level.

As an aside, I think it'd help if the target implemented more of the AUTH=
=20
MIB. In it, there are entities called auths (which other MIBs tie to iSCSI=
=20
nodes). Auths can access nodes. Wasabi has coined the term, "Self-auths",=
=20
which are auths used to supply credentials for mutual authentication=20
(something the other specs left out).

Auths can contain multiple credentials, such as "None" or CHAP. Auths can=
=20
be restricted based on address range and/or entity name. For a target,=20
that would be the initiator name.

Thus you could create an auth that initiator X could use over the=20
closed-access-fully-switched SAN and another auth that could be used from=
=20
anywhere.

> This is true of a lot of applications with IPsec, made worse because
> every platform and OS has its own way to configure IPsec policy.  The
> problem isn't relying on the IPsec transport as much as it is on the
> administration.

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.

> It's fine for iSCSI (and other applications) to defer to IPsec
> transport, rather than duplicate implementation, as Thor described.
> But it's inadequate for them to just ignore transport security
> entirely and make it SEP by relying on IPsec without at least defining
> some useful interface bindings between the two (because it almost
> guarantees people won't use it, or will use it incorrectly).

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

I would LOVE more channel bindings support. I actually have a mostly-done=
=20
I-D on how to extend iSCSI authentication to use channel bindings. The=20
main issues have been product delivery requirements and also that the=20
channel binding stuff doesn't seem to have come together (or I haven't=20
found it).

> iSCSI has several forms of names already, but no form where the name
> can be assured by a corresponding ipsec SA.  I understand that IPsec
> is not used for iSCSI authentication, but the inability to have any
> kind of correlation between the two limits the usefulness of both.

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.

One thing that would sure help would be a flag like Solaris supposedly has=
=20
where in, upon renegotiation of an SA which is protecting a TCP socket,=20
the same identities must be used to renegotiate as performed the original=
=20
negotiation. Otherwise the socket gets killed. This could require=20
socket-level SPDs.

> > What exactly is wrong with CHAP?
>=20
> For one, the reflection/oracle attack described.  For two, the fact
> that it has no persistence with the session beyond TCP, leaving the
> following protocol session vulnerable to hijacking.

I'm not 100% sure the reflection attack actually works. 1) it depends on a=
=20
target performing mutual before primary authentication. I'm not sure if=20
they actually do. 2) It assumes that the passwords are the same. They MUST=
=20
NOT be, by the following text:

   Any CHAP secret used for initiator authentication MUST NOT be
   configured for authentication of any target, and any CHAP secret used
   for target authentication MUST NOT be configured for authentication
   of any initiator.

It's in section 8.2.1, page 102.

Actually, I was reading the text more, and 8.2. states:

   Section 11 iSCSI Security Text Keys and Authentication Methods
   defines several authentication methods and the exact steps that must
   be followed in each of them, including the iSCSI-text-keys and their
   allowed values in each step.

It then goes on to say that if you get the steps wrong, the other side=20
stops the login.

The CHAP login sequence has the target answering mutual auth (sending its=
=20
CHAP_N and CHAP_R) in the step AFTER the initiator finishes its auth. Thus=
=20
you should (MUST actually) never get mutual auth info out of the target=20
before the initiator has completed CHAP.

So I don't think _that_ attack is there.

Yes, CHAP doesn't prevent hijacking, but it's not supposed to. :-)

> Say I have an iSCSI target, serving different LUNs to different
> initiators. They shouldn't see eachother's LUNs, but each can attempt
> to hijack the other's iSCSI sessions, even inside the IPsec i have
> carefully set up with each. It's all to loose and haphazard to be
> really worth doing, let alone provide much assurance.

I think this is a good reason for socket-level policy. Then the SA for on=
=20
esocket explicitly limits packets to coming from the other end. I think=20
then that initiators couldn't bash each others' connections.

[snip]

> In storage, end-to-end security shouldn't be between host and disk; it
> should be between write and read, from the host via the disk and back
> again.=20

True. :-)

Take care,

Bill

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

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

iD8DBQFEBogNWz+3JHUci9cRAjf7AJ9LtwhT5G6KHJq2QIdSfEgRDl1yAACgilnK
2gnOyZ9f2deEUPPFkYlj4PY=
=Utg8
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--