Subject: RE: iSCSI: Login authentication SRP/CHAP

From: "John Hufferd" <[email-masked]>
Date: Fri, 19 Oct 2001 01:53:34 -0700

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: [email-masked]

"Bill Strahm" <[email-masked]>@ece.cmu.edu on 10/17/2001 02:19:38 PM

Sent by:  [email-masked]

To:   "IPS Reflector \(E-mail\)" <[email-masked]>
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
[email-masked] idiots.
(503) 601-0263  So far the Universe is winning --- Rich Cook

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]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.

---

From: "Bill Strahm" <[email-masked]>
Date: Fri, 19 Oct 2001 08:35:59 -0700

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

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Friday, October 19, 2001 1:54 AM
To: Bill Strahm
Cc: IPS Reflector (E-mail)
Subject: RE: iSCSI: Login authentication SRP/CHAP

Bill,

.
.
.
John L. Hufferd

Bill Strahm

-----Original Message-----

SRP_s = SRP salt

---

From: "Bill Strahm" <[email-masked]>
Date: Fri, 19 Oct 2001 09:42:17 -0700

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Fri, 19 Oct 2001 11:22:35 -0500

Bill-

We have to deal with #3.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Fri, 19 Oct 2001 12:17:24 -0500

> 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

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054