SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Question on iSCSI security


    • To: ips@ece.cmu.edu
    • Subject: RE: Question on iSCSI security
    • From: "Williams, Jim" <Jim.Williams@Emulex.com>
    • Date: Tue, 22 Jul 2003 16:08:41 -0400
    • Content-Type: text/plain;charset="iso-8859-1"
    • Delivered-To: ips-outgoing@sos.ece.cmu.edu
    • Delivered-To: ips-outgoing@ece.cmu.edu
    • Delivered-To: ips@sos.ece.cmu.edu
    • Delivered-To: ips@ece.cmu.edu
    • Sender: owner-ips@ece.cmu.edu

    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.
    
    
    


Home

Last updated: Tue Aug 05 12:46:10 2003
12771 messages in chronological order