SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution



    Title: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution
    I have also spoken to a few people with far more IPsec experience than I.
    From the dazed expressions and dropped jaws, the sense I get is that
    dynamic switching to more relaxed SAs is, how shall I put this, not typical
    behavior?  Legal, yes. Interoperably implementable, probably.  Ugly, not a doubt.
     
    I too would be far happier if we separated out the decision-bits again,
    and let the end users decide
        a) to allow their iSCSI implementations to authenticate each other securely,
        b) to provide privacy and/or enhanced integrity to the data sessions
    as independent options.
     
    It's bad enough to be appearing to legislate user behavior with a
    "SHALL USE", but worse if it appears to be an arbitrary mandate
    from above.  I think the appropriate course here is to put in the
    strong wording re selection of CHAP secrets, referencing the
    available literature re potential exploits of dictionary keys.  
    Separately, recommend IPsec use for session privacy,
    integrity, and identification verification, where appropriate
    to the user's needs.
     
    Just my opinion....
     
    - milan
     
     
     -----Original Message-----
    From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
    Sent: Wednesday, May 22, 2002 6:59 PM
    To: Black_David@emc.com
    Cc: Merhar, Milan; ips@ece.cmu.edu
    Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution

    On Wed, 22 May 2002 Black_David@emc.com wrote:

    > Responding to Milan's concern, let me know if I get any of the
    > paraphrasing wrong:
    >
    > [Milan Merhar]: It looks like the requirement for ESP to protect a CHAP
    >       exchange with a weak secret requires the entire resulting iSCSI
    >       session to be encrypted and use ESP integrity.
    >
    > Close enough; I think it's just that connection and only integrity.
    > The encryption can probably be removed by negotiating a new SA that
    > doesn't encrypt and deleting the old one, but that still requires
    > ESP integrity.  Just deleting the SA doesn't work reliably because
    > it could easily result in black-holing packets.  IKE has no way to
    > check whether the other side will accept unprotected packets for
    > this TCP connection, and if it won't, then deletion of the SA
    > results in the packets being discarded.

    Could we have a more complete example of this (SA changing in mid-stride)?
    From talking with some IPsec implementers, it can be done. We just will
    need to note a number of details to make sure we have it right.

    One thing that will be needed is for us to be able to set policy on a
    per-socket basis, and for us to be able to examine the policy in place on
    a socket. That way a target can verify that a login is covered by
    sufficiently-secure policy, and the initiator (and target) can adjust
    policy (to relax it).

    There is of course the question of what to do if the other side doesn't
    want to relax policy. :-)

    A few other implementation notes. 1) some IPsec implementations will
    continue using an older SA (the with-privacy one) for a while. 2) we need
    to have the initiator make sure it's using strong policy when it does the
    CHAP phase - otherwise if it is logging back into a target and happens to
    use a port number that it used before, the old (weaker) SA might still be
    there.

    I would prefer the key randomness be a MUST, so we can avoid this. While
    rather doable, it will add more to the implementation complexity.

    Take care,

    Bill



Home

Last updated: Thu May 23 12:18:27 2002
10243 messages in chronological order