Re: Question on iSCSI security

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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.

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".

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.



>                       "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