SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Active and Passive attacks



    So, how does all that argument translate into simple rules
    that tell people where DH-CHAP can be safely used?
    
    The counter-argument is that you haven't "raised the bar"
    in any of these examples unless you can show that the
    strawman active attacks are in fact the simplest active
    attacks that can be done.
    
    Propping up strawmen and shooting them down
    is a valid part of security discussion, especially when
    developing new protocols.  But it is usually more productive
    to have different people do the propping than the shooting.
    
    -- David
    
    At 06:36 AM 4/29/2002 -0400, Black_David@emc.com wrote:
    >Here's the promised message on active and passive
    >attacks - again, this is IMHO, and "not* posted
    >as a WG co-chair.  It's important for people other
    >than the security experts to be involved in this issue.
    >
    >-- Symmetry and Opportunity
    >
    >Passive monitoring/eavesdropping attacks are often
    >symmetric - if the attacker can see the traffic from
    >Alice to Bob, there's a good chance that s/he can
    >see the traffic in the reverse direction, at least
    >on LANs.  WANs are more complex, and asymmetric routes
    >do turn up in multi-provider scenarios (e.g., "hot-
    >potato" routing).  Note that this whole discussion
    >of symmetric vs. asymmetric vulnerability is assuming
    >that bidirectional authentication is an important case.
    >
    >In contrast, active attacks often have asymmetric
    >characteristics in that the attacker's location makes
    >one of the communicating parties more vulnerable.
    >The scenario discussed earlier of taking over a
    >router/network node that's actually on the communication
    >path strikes me as unusual in contrast to using a
    >node (esp. end-system) not on the communication path
    >to do the dirty work.  The result is often asymmetric
    >vulnerability - for example if the attack is based
    >on impersonation via a bogus ARP response, the attacker
    >has to be on the same LAN segment (incl. VLAN) as
    >the victim, and in many cases will only be able to
    >attack one of the two communicating parties in this
    >fashion.  The shrinking size of LAN segments (e.g.,
    >as layer 3 forwarding replaces Ethernet bridges)
    >suggests that the two communicating parties not being
    >on the same LAN is an important case (and limiting
    >this ARP vulnerability is another reason to reduce
    >the size of LAN segments).
    >
    >-- Combined Active/Passive Attacks
    >
    >A protocol that's vulnerable to a passive attack is
    >also vulnerable to some combined active/passive
    >attacks that can be considerably simpler than a fully
    >active attack.  For example, the attacker may have to
    >monitor a *lot* of iSCSI traffic for before seeing
    >a login.  This can be improved via a well-placed TCP RST
    >to drop the connection - if the Initiator policy is to
    >replace the connection in short order, the login traffic
    >will show up soon.  CHAP is vulnerable to this attack -
    >DH-CHAP is not, as it requires a full active impersonation
    >or man-in-the-middle attack that requires significantly
    >more iSCSI code/knowledge, and SRP is even better.
    >
    >-- Attack Detection
    >
    >If bidirectional authentication is in use, both the full
    >passive monitoring attack and the TCP RST active/passive
    >attack on CHAP cannot be detected by the iSCSI participants.
    >In contrast, an active impersonation or man-in-the middle
    >attack on DH-CHAP or SRP is detectable because the
    >attacker fails to authenticate when required to do so
    >(although a clueful attacker won't even try this on SRP,
    >as there's nothing to be gained, in contrast to DH-CHAP).
    >
    >Having provided three examples in which  prevention of
    >passive attacks can be valuable in "raising the bar" on an
    >attacker, even for a protocol that's vulnerable to
    >active attacks, I'll stop here and invite others to
    >comment.
    >
    >Thanks,
    >--David
    >
    >---------------------------------------------------
    >David L. Black, Senior Technologist
    >EMC Corporation, 42 South St., Hopkinton, MA  01748
    >+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    >black_david@emc.com         Cell: +1 (978) 394-7754
    >---------------------------------------------------
    
    


Home

Last updated: Tue Apr 30 15:18:25 2002
9894 messages in chronological order