Re: iSCSI: Login authentication SRP/CHAP

[Mark Bakke <mbakke@cisco.com>]

Bill Strahm wrote:
> 
> So what you are arguing is that you expect a large number of implementations
> to opt for #3... In that case we do not have a secure link.  You have two
> choices, either remove option #3 because they are not iSCSI devices
> therefore do not need to be considered, or change your security requirement
> to use IPsec to a SHOULD...

I like the SHOULD.  The problem is that the IETF will not let us
go through last call with the SHOULD; they want a MUST implement.

So the best we can do as implementors is provide the full solution
(at a premium price) where needed, and claim a minor deviance from
the specification where it's not required.

BTW, I prefer CHAP as well; even if it's not as secure, it's the
only thing compatible with existing RADIUS infrastructure.

Perhaps we could say:

- IPsec is a MUST implement
- CHAP is a MUST implement

and anyone wanting a non-IPsec implementation can put in SRP if
they think that they need a more secure method than CHAP.

--
Mark

> I honestly think the later is the better choice because right now there are
> VERY few solutions that can handle IPsec at the speeds we are talking about
> (there are a few IPsec accellerators that you hinted at in existance today
> however)...  Now if I have a situation where I do not have a required secure
> link under the protocol, then I think we MUST have a secure login... But I
> don't think we need both (I think both requirements should be SHOULD
> requirements to solve a problem)
> 
> 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: mbakke@cisco.com [mailto:mbakke@cisco.com]
> Sent: Friday, October 19, 2001 9:23 AM
> To: Bill Strahm
> Cc: John Hufferd; IPS Reflector (E-mail)
> Subject: Re: iSCSI: Login authentication SRP/CHAP
> 
> Bill-
> 
> We have talked about this very subject extensively in other
> face-to-face meetings.  Here's a summary.  Basically, the
> "mandatory to implement" for a secure link (either IPsec or
> SSL) is an IETF requirement, and not necessarily a product
> requirement.  Therefore, we will see three kinds of products:
> 
> 1. Products that implement IPsec in hardware.  These will
>    provide good performance and security in the same package,
>    but will add hardware cost (not list price) at a few
>    hundred dollars per port.  This, plus development cost,
>    plus the fact that not everyone requires this kind of
>    security, will make this cost-prohibitive for many products.
> 
>    As IPsec chips are developed, this could be integrated at
>    a somewhat lower cost, but again, we're talking a fairly
>    long time before these things are realized in products.
> 
> 2. Products that implement IPsec in software.  This may be
>    acceptable for some initiators that do not require much
>    bandwidth, but will almost never be acceptable to meet
>    a target's bandwidth requirements.  Some vendors may be
>    tempted to put in a "toy implementation" of IPsec in
>    software just to claim RFC compliance, but performance
>    will be so poor that nobody will actually want to use it.
> 
> 3. Products that just leave out IPsec entirely.  This is what
>    today's iSCSI products already do, and this is cheaper than
>    putting IPsec in hardware, and more honest (at least in
>    high bandwidth products) than putting it in software.  The
>    marketing guys can deal with the "compliant-except-for-IPsec"
>    problem.  After all, very few file server or other data
>    storage products support this kind of security; the demand
>    for IPsec may be a specialty market, or an optional, added-cost
>    item for some products.
> 
> It doesn't matter whether IPsec or SSL is used for the
> secure link; either one requires roughly the same hardware
> cost and/or software performance cost for the above solutions.
> 
> We have to deal with #3.
> 
> --
> Mark
> 
> Bill Strahm wrote:
> >
> > 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.
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054