|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Question on iSCSI securityI 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.
Home Last updated: Tue Aug 05 12:46:10 2003 12771 messages in chronological order |