SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST



    Title: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST
    Jonathan,
     
    So, is the existing text ok, or do you want something changed?
     
    I don't think I see any harm
    in using a negative authentication cache when iSNS is operated
    securely, although, as Bernard noted, it's not necessary.
     
    Thanks,
    --David
    -----Original Message-----
    From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
    Sent: Monday, July 01, 2002 6:55 PM
    To: 'Black_David@emc.com'
    Cc: ips@ece.cmu.edu
    Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

    That helps to clarify it. I don't think that the draft should require an administrative interface.

    Jonathan

    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Monday, July 01, 2002 3:36 PM
    To: jtrostle@corp.iready.com
    Cc: ips@ece.cmu.edu
    Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
    Jul y 1 at 8am EST


    > When a target ends up in the negative authentication cache, does
    > that imply that the initiator will not contact the target while
    > it's in the cache, or does  it imply that the initiator can contact
    > the target but should not use IPsec (if IPsec failed)? Or shouldn't
    > use app level security if app level security failed?

    The first - initiator will not contact the target while it's in the
    cache under the assumption that authentication will just fail again.
    As Bernard wrote, this protects against a denial of service attack
    where a rogue iSNS server in league with a rogue iSCSI target causes
    an initiator to repeatedly waste its time trying to talk to the target.

    Would it help to require an administrative interface to clear entries
    from the negative cache or the entire cache?

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

    -----Original Message-----
    From: Jonathan Trostle [mailto:jtrostle@corp.iready.com]
    Sent: Monday, July 01, 2002 6:17 PM
    To: 'Bernard Aboba'
    Cc: 'ips@ece.cmu.edu'
    Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
    1 at 8am EST




    When a target ends up in the negative authentication cache, does that imply
    that the initiator will not contact the target while it's in the cache, or
    does  it imply that the initiator can contact the target but should not use
    IPsec (if IPsec failed)? Or shouldn't use app level security if app level
    security failed?
    Jonathan
    -----Original Message-----
    From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
    Sent: Saturday, June 29, 2002 10:42 PM
    To: jtrostle@corp.iready.com; ips@ece.cmu.edu
    Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
    July 1 at 8am EST


    >One comment/question on the security draft below:
    >
    >p. 23: "Where iSNS is used without security, IP block storage protocol
    >implementations MUST support a negative cache for authentication
    >failures."
    >
    >Is it worth pointing out that when iSNS is used with security, then a
    >negative cache MUST NOT be used? An attacker can cause authentication >to
    >fail through a DoS attack which could result in an entry being >added to
    >the negative cache.
    There are two orthogonal issues here -- one is iSNS security, the other is
    IPS protocol security. If iSNS is not secured, then a peer might receive and

    accept an iSNS packet from a rogue iSNS server. However, if the IPS session
    is subsequently secured, and mutually authenticated, the endpoint specified
    in the bogus discovery message will fail to authenticate. The argument is
    that this should result in a negative cache entry within the iSNS
    implementation, so as to prevent continual attempts to authenticate to bogus

    peers.
    If iSNS is secured, then presumably this would preclude a rogue iSNS server,

    and the negative cache is unnecessary.
    Do you have an issue with the negative cache in general, or just its use
    where iSNS is secured?





    _________________________________________________________________
    Send and receive Hotmail on your mobile device: http://mobile.msn.com



Home

Last updated: Mon Jul 01 20:18:42 2002
11060 messages in chronological order