Message-ID: <3356669BBE90C448AD4645C843E2BF289B90AB@xbl.ma.emulex.com>
From: "Williams, Jim" <Jim.Williams@Emulex.com>
To: ips@ece.cmu.edu
Subject: RE: Question on iSCSI security
Date: Tue, 17 Jun 2003 10:44:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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?

> 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.

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.

> 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.

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.

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.

> 
> >                       "Williams, Jim"
> >                       <Jim.Williams@Emu        To:       
> >"'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> >                       lex.com>                 cc:
> >                       Sent by:                 Subject:  
> Question on iSCSI 
> >security
> >                       owner-ips@ece.cmu
> >                       .edu
> >
> >
> >                       12/06/03 21:50
> >
> >
> >
> >
> >
> >
> >
> >I am not up to speed on security and IPSec, so
> >there is probably a simple answer to this.  I
> >would be curious to know what it is.
> >
> >
> >Scenario:
> >
> >A is an unwitting initiator, B is a malicious
> >target, and C is a victim target.
> >
> >A attempts to log into B using IPSec.  B establishes
> >IPSec SA with C.  B is honest to IKE about its identity.
> >After establishing SA, B attempts to log into C, but
> >lies to the iSCSI layer and claims to be A.
> >B uses classic man-in-the-middle technique to get
> >A to respond to C's login challenge.  If this
> >works, then B has successfully logged into C
> >as A.
> >
> >There are a number of similar scenarios with the
> >common thread that the attacker is truthful about
> >his identity to the IPSec layer, but lies about
> >his identity to the iSCSI layer.
> >
> >These attacks are easily defeated if the iSCSI
> >layer cross checks remote end's identity with the
> >IPSec layer.  But it is not clear how this is done
> >and whether it will be done or is required to
> >be done.
> >
> >If the IPSec layer verifies that the IP address
> >INSIDE the tunnel really belongs to B, and iSCSI
> >verifies that the IP address it sees really belongs
> >to A, and the data consulted for the verification
> >is secure, then one of these checks should fail,
> >but this seems like a stretch.
> >
> >But perhaps I am missing something simple.
> >
> >
> >
> >
> >
> 
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
>