SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Login authentication SRP/CHAP



    Ok,
    We have MUST implement IPsec
    We have MUST implement SRP
    why don't we remove SRP as a MUST implement and go with CHAP, or another
    authentication protocol that doesn't have the IP problems that SRP has.  I
    still haven't gotten a clean licensing statement from Stanford that I am
    comfortable with, and there was quite a bit of Zero Sum Proof of knowledge
    exchanges going on in Orange County about other IP involved with SRP.
    
    Again, SRP isn't needed, we have a secure link underneath the application,
    it will cost implementors an unknown amount of money to licence it, and it
    may infringe on other unknown patents... This isn't a good thing to base a
    standard on.
    
    Now I am not saying that you MUST NOT implement SRP, just move the
    requirement from MUST implement and I am happy.
    
    Bill
    +========+=========+=========+=========+=========+=========+=========+
    Bill Strahm     Software Development is a race between Programmers
    Member of the   trying to build bigger and better idiot proof software
    Technical Staff and the Universe trying to produce bigger and better
    bill@sanera.net idiots.
    (503) 601-0263  So far the Universe is winning --- Rich Cook
    
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Friday, October 19, 2001 8:45 AM
    To: Bill Strahm
    Cc: IPS Reflector (E-mail)
    Subject: RE: iSCSI: Login authentication SRP/CHAP
    
    
    
    Bill,
    This was all discussed in Irvine, we need to move on to things which will
    help us close the Spec.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com
    
    
    "Bill Strahm" <bill@Sanera.net> on 10/19/2001 08:35:59 AM
    
    To:   John Hufferd/San Jose/IBM@IBMUS
    cc:   "IPS Reflector \(E-mail\)" <ips@ece.cmu.edu>
    Subject:  RE: iSCSI: Login authentication SRP/CHAP
    
    
    
    But it is Required to implement, so the link has as much security as the
    administrator requires for the situation.  So if IPsec is not being used it
    is because a) the administrator doesn't care about wire security b) the
    administrator doesn't have anything that needs to be protected c) the
    administrator doesn't have the resources to protect it.  So for those
    reasons I don't buy the argument in your first paragraph...
    
    The rest is just strict ACL... For you do not need SRP to provide identity
    information, I could just as easily send username="Bill" password="foo"
    over
    the wire and it will provide the same functionality (all SRP does is
    prevent
    you from having to send Bill and foo over the wire directly at the cost of
    a
    lot of mathematics.  And with a link that is administratively configured to
    be adequately secure, I don't see the problem with it.
    
    I do not understand why you are requiring IPsec/IKE, but refusing to
    consider a much simpler to configure/support TLS.  It sounds like many of
    the problems that you are having that are requiring you to go with a
    protocol that has unknown IP rights, and licensing behind it could be
    easily
    solved by changing the security from IPsec to TLS, but that is my opinion.
    
    I think the problem is that people are trying to solve way too many
    problems, assume that IPsec has adiquate link security and go from there.
    If IPsec is not capable of securing the link, then remove the solution and
    replace it with a technology that can secure the link...
    
    Bill
    +========+=========+=========+=========+=========+=========+=========+
    Bill Strahm     Software Development is a race between Programmers
    Member of the   trying to build bigger and better idiot proof software
    Technical Staff and the Universe trying to produce bigger and better
    bill@sanera.net idiots.
    (503) 601-0263  So far the Universe is winning --- Rich Cook
    
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Friday, October 19, 2001 1:54 AM
    To: Bill Strahm
    Cc: IPS Reflector (E-mail)
    Subject: RE: iSCSI: Login authentication SRP/CHAP
    
    
    
    Bill,
    IPSec is optional to use!  So you can not assume that you have a Secure
    connection.  And even if you use IPSec, you can not be sure that Privacy
    (encryption) is being used.  So for these reasons alone you need to have an
    iSCSI method of Authentication.
    
    Next, the lower levels only know that the link is OK to be use for
    something.  It does not know that it is iSCSI that is using the link, and
    if it did it does not have access to the iSCSI ACLs.  Nor does iSCSI know
    what is handled at the lower levels so it must do its own ACL processing.
    
    Even if the link is secure (perhaps even encrypted) and iSCSI
    Authentication finds out that you are user "Bill", that does not say that
    you have the right to get at All resources.  "Bill" will be authorized to
    operate from certain iSCSI Initiator Nodes, and those nodes will only be
    permitted to see certain approprate LUs.  These are all iSCSI functions NOT
    TCP or IPSec.
    
    Your suggestion to use TLS, was fully discussed in Irvine, and that issue
    is now behind us.
    
    
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com
    
    
    "Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 10/17/2001 02:19:38 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   "IPS Reflector \(E-mail\)" <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI: Login authentication SRP/CHAP
    
    
    
    Just to bring up a cynical point.  Why do we need SRP anyway... after all I
    am running over a required secure channel, so there should be no problem
    with just sending a user ID/Passphrase over the secure channel.  This will
    prevent a LOT of interoperability problems, extra code required to
    implement
    additional security algorithms, etc.
    
    This makes my implementation much simpler, I can seperate
    login/authentication parameters (currently SRP) vs. setting up a secure
    channel (IPsec).  If we go the Application level secure authentication
    method, I would rather we replace the security layer with TLS rather than
    IPsec, so we get authentication/security all in one place rather than
    scattered around lower layer protocols, application protocols...
    
    Bill Strahm
    +========+=========+=========+=========+=========+=========+=========+
    Bill Strahm     Software Development is a race between Programmers
    Member of the   trying to build bigger and better idiot proof software
    Technical Staff and the Universe trying to produce bigger and better
    bill@sanera.net idiots.
    (503) 601-0263  So far the Universe is winning --- Rich Cook
    
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Michael Schoberg
    Sent: Wednesday, October 17, 2001 12:53 PM
    To: IPS Reflector (E-mail)
    Subject: iSCSI: Login authentication SRP/CHAP
    
    
    I'm having some problems figuring out the exact implementation for the
    login
    authentication protocols being proposed.  Is anyone else having similar
    issues answering these questions:
    
    What is the hashing algorithm that will be used for SRP authentication
    (SHA-1, MD5, HMAC-SHA1)?
    
    The SRP negotiation passes the following information (T->I):
    
    SRP_s = SRP salt
    SRP_N = (SRP n value - Large prime number.  All computations are performed
    modulo n)
    SRP_g = Primitive root modulo of n
    
    By passing [N] & [g] (T->I), does this mean the initiator must verify that
    [N] is a prime and [g] is a primitive root modulo of [N]?  What are the
    min/max digits for [N] and [g]?  If any of these are not satisfied (N not
    prime, g not primitive modulo root, #digits too small or large), could it
    be
    used as an attack against the initiator or be used to derive the
    initiator's
    password?
    
    
    
    The reference to RFC 1994 does not fully describe the CHAP function for
    iSCSI, it describes the CHAP message protocol which isn't really used in
    our
    case.  There's some parameters that need to be nailed down.  What is the
    CHAP hash algorithm: (MD5)?  What is the sequence of hashes that take place
    on a CHAP challenge to form the CHAP digest?
    
    The iSCSI draft allows for algorithm selection (CHAP_A=<A1,A2,...>) but
    doesn't describe any.  Are these supposed to dictate the hashing function
    or
    give a description of [what/how it] gets hashed (or both)?  Will there be a
    mandatory set (A1..An) that compliant iSCSI implementations must provide?
    Is there a reference that actually shows the sequence for a CHAP digest
    being formed from MD5 hashes?
    
    
    
    It would help to have an appendix with real username/password examples of
    the result exchange?  A table with a few sample sets would be useful for
    validating designs.
    
    
    
    
    
    
    
    


Home

Last updated: Mon Oct 22 08:17:32 2001
7317 messages in chronological order