RE: Question on iSCSI security

[Black_David@emc.com]

Jim,

The countermeasures to this attack have to involve the
connection from "A" to "T" and noticing that "A" isn't
"I".  The first step is that "A" has to present an IKE
credential to "T".  This stops random outside "A"s, as
they won't have an IKE credential that "T" will find
acceptable, and "A" cannot impersonate "I" via IKE
to "T" (and if "T" is doing something lax like
accepting arbitrary self-signed certificates, the
faulty component is the security administrator ...).

If one is concerned about this threat, the IPsec SAs
ought to be set up with filters - one would clearly
want to filter on the IP address, and also the TCP
Port if "T" is offering services other than iSCSI
(TCP port filtering is not mandatory in IPsec, but using
it here separates the iSCSI services from other services).
The result is that "A" has to be an authorized iSCSI
user of "T".  So, what we're talking about is a man-in-the-
middle attack among authorized iSCSI users of "T", as
opposed to some arbitrary attacker.  There are environments
where this sort of risk is deemed acceptable, but that
doesn't excuse it in all cases.  Stopping this requires
paying attention to "A"s IP address - "T" has to check
that the IP address from which "I"s identity was presented
is wrong.  The iSCSI Auth MIB (draft-ietf-ips-auth-mib-04.txt)
contains support for making this authorization check,
although you're correct that implementation of this
check is not required.

Thanks,
--David

> -----Original Message-----
> From: Williams, Jim [mailto:Jim.Williams@Emulex.com] 
> Sent: Tuesday, July 22, 2003 4:09 PM
> To: ips@ece.cmu.edu
> Subject: RE: Question on iSCSI security
> 
> 
> I would like to follow up on this thread.
> 
> 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.
> 
> I don't believe this is true.  I will elaborate further
> below.
> 
> > b) Tunnel mode is negotiated without filters.
> 
> True for the description as stated, but not
> true in general for attacks of this type.
> 
> > c) iSCSI/IKE authorization cross-check.
> 
> Interesting idea.  But I am concerned this is not 
> documented anywhere, and not supported by standard
> IPSec APIs.  Bill summarized this as follows.
> 
> wrstuden wrote:
> > 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. :-)
> 
> To state again the type of scenario I am concerned about:
> 
> Suppose initiator "I" wants to talk to target "T".  But
> "I" is confused about "T's" IP address, and mistakenly
> uses attacker "A's" IP address.  This could happen by
> using non-secure name resolution, or stale name resolution
> if IP addresses are dynamic.
> 
> Because of where IPSec is layered, all it knows is the
> IP address to which the connection is destined, so
> it correctly sets up a secure connection to "A".
> "A" then simply sets up its own connection to "T"
> and forwards all data received from "I" to "T", and
> all responses back.
> 
> At this point "I" logs into "T" and both "I" and "T"
> are happy with the resulting iSCSI authentication.  But
> "A" has the opportunity to see and modify all data
> on the way by, so the connection is clearly insecure.
> 
> This type of attack can be prevented by insuring
> that "I" always has the correct IP address for "T".
> But in practice this may difficult given the reality
> of the way networks are administered.
> 
> Likewise if "T" as part of the iSCSI authentication
> checks the source IP address, and verifies that it
> in fact belongs to "I", and if the IPSec tunnel filters
> are set correctly, then the attack would be 
> caught.  But I don't believe that iSCSI authentication
> requires this check (am I wrong?)  Also, such a 
> check requires "T" correctly resolves or knows "I's"
> IP address.
> 
> All these problems may go away if target IP addresses
> are always hard coded and available from a secure 
> discovery server.  But again I am not aware of 
> a requirement for this (am I wrong?)
> 
> Overall, I am concerned that there are too many 
> security loose ends left as an exercise for the
> implementer or administrator.  The result
> may be that IPSec gives a false sense of security
> for storage over physically insecure networks.
> 
>