RE: Question on iSCSI security

[wrstuden@wasabisystems.com]

On Tue, 17 Jun 2003, Williams, Jim wrote:

> Bernard,
>
> Thanks for replying.
>
> Bernard Aboba wrote:
> > The attack you describe requires that:
> >
> > a) No authorization check occurs. Authorization
> > checks prevent man-in-the-middle attacks because
> > a potential man-in-the-middle needs to be
> > authorized to act in both roles.  Just because
> > a host can successfully authenticate with IKE
> > does not mean that it is authorized to
> > act as an iSCSI initiator or target.  For example,
> > my laptop has an IKE certificate on it --
> > am I authorized to bring up my machine on the corpnet as an
> > iSCSI Target? Of course not. Without authorization
> > checks any host with appropriate IKE
> > credentials can act as an iSCSI Target. Given this,
> > man-in-the-middle may be the least of your problems.
>
> This sounds good.  Verifying that "B" is a valid target
> is clearly better than nothing, but not as good as
> verifying that it's in fact "C".
>
> But I am not clear on how and at what layer these
> authorization checks are done.  Can you provide
> any references to RFCs or other specs that would
> help me out?

Huh? Look at the Auth MIB, which contains the info on credentials.

> > b) Tunnel mode is negotiated without filters.  If
> > "any to any" is negotiated, then the explicit
> > intent is to allow hosts other than the host
> > that brought up the tunnel to use it.  If that's
> > not what is desired, then it's probably better to
> > negotiate the tunnel mode SA "from me to you".
>
> Sounds like a good start, but there are two important
> pieces missing.  First, iSCSI must verify that
> that the IP address it sees on a connection corresponds
> to the end point to which it thinks it is connected.
> Not difficult conceptually, but I suspect most
> iSCSI implementations will not do this unless
> specifically required by ips security standards.

?? What do you mean other than getpeername(2)?

> Second it implies a secure DNS.  How does C
> verify that the IP address 123.45.67.89 in
> fact belongs A?  A DNS corrupted by B
> could simply claim that 123.45.67.89 is A's IP
> address, when in fact it belongs to B.
> No doubt the technology exists to do secure
> DNS, but it seems desirable to avoid
> having to depend on this for end to end
> security, since DNS is much more distributed
> with more points of vulnerability.

I'm sorry, what does DNS have to do with this? You can static-configure
IPs if you want.

> > c) iSCSI/IKE authorization cross-check. Even if
> > filters are negotiated, and even if a host is
> > authorized to act as an iSCSI initiator, it
> > may not be authorized to act as an iSCSI initiator
> > with a particular  iSCSI identity. So
> > it may be necessary to cross-check the iSCSI
> > identity against the IKE identity, and ensure
> > that they are appropriate for use with
> > each other.
>
> This sounds right!  A cross check prevents
> any such man-in-the-middle attack.  Without
> such a cross check, it is not clear that
> such an attack can be prevented.
>
> IPSec prevents man-in-the-middle attacks by
> insuring that the remote end of a connection
> is in fact who it claims to be, with no-one
> else in between.  But without a cross check,
> how can IPSec or iSCSI verify that the remote
> end is who iSCSI thinks it is?  There is
> no way to insure that iSCSI thinks the
> endpoint is who IPSec thinks it is.

But you can't easily do that for a number of reasons. First off, it's
perfectly fine for the two to differ. Nothing in the spec says you must
configure end-to-end IPsec. Implement, yes, use no. Say you're talking to
a host behind a security box which is doing the IPsec. Your IPsec will be
with that box, not the iSCSI other end.

Second, the IPsec folks haven't developed an API to find out what IPsec is
in use on a connection. They haven't even got an API good enough to find
out if there's _any_ IPsec on a connection. I've asked, repeatedly. :-)

So even if you were to take the time to build up a mapping of what IPsec
IDs were appropriate for an iSCSI id, there is no standardized way to get
the info you'd need.

> Anyway, what I am ultimately aiming for is
> a definition of what the interface between
> the iSCSI layer and the underlying IPSec layer
> should look like.  I would hope that the
> requirements here would be fully spelled
> out in the iSCSI security draft.  As an
> iSCSI implementer, I would like to the
> extent possible to avoid becoming a
> security expert.  I would like as much
> as possible spelled out in the
> security drafts.

It's not there. A number of pieces are missing.

> I also expect that storage network
> administrators will be mixed at best
> in terms of their expertise in security.
> For iSCSI deployment to become consistently
> and reasonably secure will require that
> the hard work be done at the standards
> definition level, and not left to
> implementers and administrators.

IPsec security policy can be very complicated. You're essentially talking
about puting knowledge of all that complexity in iSCSI.

I think the best way to extend this would be some sort of extention of the
AUTH MIB, to add IPsec requirements to Auth entries.

Take care,

Bill