RE: Question on iSCSI security

["Julian Satran" <Julian_Satran@il.ibm.com>]

Jim,

More than addresses are needed to get through IPsec establishment.
IKE provides (complicated but not proven insecure untill now) ways of 
authenticating the two parties and have them establish a Security 
Associations and the required keys.

The assumptions is that Administrators do it and you have anyhow to trust 
your OS (and its administrator - the can change your memory!). You are no 
required to trust the other end.

The fact that a standard API does not exist is not necessarily a weakness 
of the protocol but rather a weakness of the organization that generated 
it and its unwillingness to "impose at leas the existence of an API" on 
powerful OS players. That is a serious impediment for application builders 
but not necessarily a security weakness.

Julo



"Williams, Jim" <Jim.Williams@Emulex.com> 
Sent by: owner-ips@ece.cmu.edu
22/07/2003 23:08

To
ips@ece.cmu.edu
cc

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.