Subject: RE: iSCSI: Login authentication SRP/CHAP

From: "Lee, CJ" <[email-masked]>
Date: Tue, 23 Oct 2001 10:42:24 -0700

Personally, I'd think that we ought to select a mandatory to implement
authentication protocol base on how secure it is rather than how convenient
it is. Especially under the MUST to implement but optional to use nature of
both the login authentication and IPSec.  One could argue the clear text PAP
could server equally well the very purpose of login authentication when
running on top of an encrypted IPSec link.

CJ Lee
Adaptec, Inc.

-----Original Message-----
From: Bill Strahm [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 8:33 AM
To: Ofer Biran
Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd
Subject: RE: iSCSI: Login authentication SRP/CHAP

Brian,

Arguing for situations where IPsec is not implemented/used is a Red Herring.
If it is not implemented it is not an iSCSI implementation (remember MUST
implement IPsec) therefor it does not have to be considered.  If it is not
used, then that is an administrative descision that is made based on the
security requirements of the environment.  My arguement is that CHAP is
understood, code is available, it plugs into other authentication services
(RADIUS/SecureID) that I am not sure how I would plug an SRP implementation
into anyway, and I think that I HAVE to implement it... now SRP doesn't seem
to be buying me anything except for "improved security" on a
administratively secured link, doesn't seem like much.

So based on your statement below have you warrented that IBM will make NO IP
claims on the usage of SRP in iSCSI ???

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ofer Biran
Sent: Tuesday, October 23, 2001 1:09 AM
To: Bill Strahm
Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd
Subject: RE: iSCSI: Login authentication SRP/CHAP

1. It's good news that the Stanford license fee is zero (I verified  this -
see attached note).

2.
> Can you warrant that I will not have to use SRP-Z to implement any iSCSI
> operations ?

The SRP usage defined in iSCSI is EXACTLY according to RFC-2945.
This usage is explicitly covered by the Stanford free license.
SRP-Z involves additional private/public keys for the server, and you
will not have to use that if you only want to follow the iSCSI standard.

3. If anyone has information about any other IP claiming on the
RFC-2945 usage (SRP-SHA1) please post the full information here.

4. There is no question about the superior cryptographic features of
SRP over CHAP. In situations where underlying IPsec will not be
implemented/used (and these are forecasted), basing the iSCSI security
on plain CHAP is a poor solution which IMHO the iSCSI standard should not
encourage (by mandating CHAP instead of SRP).

  Regards,
    Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

Kirsten Leute <[email-masked]> on 23/10/2001 00:18:00

Please respond to Kirsten Leute <[email-masked]>

To:   Ofer Biran/Haifa/IBM@IBMIL
cc:
Subject:  Re: SRP Licensing terms

Dear Ofer:

Yes, this is correct.  For the type of usage described in the agreement,
there are no licensing fees.

As far as I know, there are no licensing issues from Stanford.

Best,
Kirsten

At 06:58 PM 10/22/2001 +0300, you wrote:
Kirsten,

I'm working on the security aspects of the new iSCSI standard in the IPS
working group of the IETF.
Our intention is to define SRP (usage according to RFC2945) as the
'mandatory to implement' authentication algorithm.

There were concerns in the working group about the licensing terms with
Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems
to me that there are no fee involved in getting this license. I wanted to
verify this with you.

Also - are you aware of any other licensing issue with SRP

  Thanks in advance,

      Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

**************************************
Kirsten Leute
Licensing Associate
Office of Technology Licensing, Stanford University
900 Welch Road, Suite 350, Palo Alto, CA 94304
Direct: (650) 725-9407; Fax: (650) 725-7295
website: http://otl.stanford.edu/

"Bill Strahm" <[email-masked]>@ece.cmu.edu on 22/10/2001 18:58:06

Please respond to "Bill Strahm" <[email-masked]>

Sent by:  [email-masked]

To:   Joe Czap/Raleigh/IBM@IBMUS
cc:   "IPS Reflector \(E-mail\)" <[email-masked]>, John Hufferd/San
      Jose/IBM@IBMUS, <[email-masked]>
Subject:  RE: iSCSI: Login authentication SRP/CHAP

Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf)

"Licensed Field of Use" means use of the Invention(s), Software and
Licensed
Patent(s)
in Licensed Product(s) for implicit server authentication. By way of
example, but not by
limitation, RFC2945. The Licensed Field of Use specifically excludes use of
the
Invention(s), Software and Licensed Patent(s) machines and servers that
deal
with
explicit bidirectional authentication (for example, SRP-Z for explicit
server
authentification). SOFTWARE may only be transferred under a Use Sublicense.

Note that this applies only if Stanford is the only organization to own IP
on this technology and there are no other patents in this field.  Joe, can
you warrant that IBM will make NO patent claims against this algorithm ?
Can
you warrant that I will not have to use SRP-Z to implement any iSCSI
operations ?

Again the problem isn't with the algorithm necissarily, but with the fact
that it is the only MUST implement algorithm, I would rather see an
algorithm with NO encumbrance against it...

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
[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
Joe Czap
Sent: Monday, October 22, 2001 5:03 AM
To: Bill Strahm
Cc: IPS Reflector (E-mail); John Hufferd; [email-masked]
Subject: RE: iSCSI: Login authentication SRP/CHAP

The lack of information relating to SRP IP concerns make the issue seem a
little
like misdirection.  Can anyone offer a clear explanation the SRP IP
situation ?

Joe Czap
IBM Storage Networking
[email-masked]

---

From: "Bill Strahm" <[email-masked]>
Date: Tue, 23 Oct 2001 10:55:25 -0700

So you are perfectly willing to specify a MUST implement algorithm that
can't be used (what happens if the user password is not available on the
target) to clutter up the implementation space ???

I would rather that A SINGLE usable algorithm is labeled MUST implement (if
you must in fact specify a MUST implement at all) and the others are left as
SHOULD implment.  You are right a clear text Username-> Password-> challenge
response works great with a secure link (heck I do it every day with SSH)
The idea is usable...

Again if the problem is that no one will implmement IPsec/use IPsec, then
the problem seems to be with IPsec, lets either make it usable, or pick
another security protocol that is deployable.  If the problem is to see how
secure we can be by requiring as many unusable/unimplementable security
algorithms as possible, well I guess we as vendors can just decide to
implement the protocol, and the algorithms that make sense to us, and don't
worry about interoperability...

Bill

-----Original Message-----
From: Lee, CJ [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 10:42 AM
To: 'Bill Strahm'
Cc: IPS Reflector (E-mail); Ofer Biran
Subject: RE: iSCSI: Login authentication SRP/CHAP

CJ Lee
Adaptec, Inc.

-----Original Message-----
From: Bill Strahm [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 8:33 AM
To: Ofer Biran
Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd
Subject: RE: iSCSI: Login authentication SRP/CHAP

Brian,

Bill

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

2.

  Regards,
    Ofer

Ofer Biran

Dear Ofer:

Best,
Kirsten

  Thanks in advance,

      Ofer

Ofer Biran

Bill

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

Joe Czap
IBM Storage Networking
[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Wed, 24 Oct 2001 11:45:30 -0400

Excerpt of message (sent 23 October 2001) by Bill Strahm:
> ...
> another security protocol that is deployable.

There seem to be two issues.

1. The IPSec requirement, as stated in the security draft, is that
integrity is mandatory but confidentiality is optional to implement.
So in fact there is no mandatory-to-implement lower layer
confidentiality mechanism that protects the login authentication
handshake.  If the only vulnerability of a proposed login
authentication protocol is in the presence of replay attacks, the
IPSec based integrity requirement suffices.  If, however, the
mechanism is vulnerable to dictionary attacks or other similar
problems that require only passive attack, then IPSec based integrity
is of no help and its status is irrelevant.

2. It is not clear whether the "rough consensus" required to
incorporate a mandate for IPSec in iSCSI exists in this working
group.  There is significant question on whether it makes technical
sense as written.

The issue with IPSec implementation/use is not a problem with IPSec
that can be resolved by picking a different security protocol.
Instead, it is with the choice of requirements as currently stated in
the security draft vs. the requirements of a major part of the user
community for iSCSI.

      paul

---

From: "Bill Strahm" <[email-masked]>
Date: Wed, 24 Oct 2001 09:09:48 -0700

What do you mean... I have a MUST implement 3DES, SHA1, MD5, and DES (from
the IPsec requirements) all though IPS wants to put a SHOULD NOT implement
DES requirement in...

IPsec therefor mandates implementation of confidentiality.  It is up to the
network administrator to determine what the security levels are, therefor
you can say that ALL iSCSI links are administratively secure.  Just because
a link isn't encrypted doesn't mean it isn't secure (I can have a link in a
guarded and locked room surrounded by M-16 wielding Marines -- I defy you to
snoop it)

I disagree with your call saying that there is not rough concensus to use
IPsec with iSCSI.  I believe David Black (correct me if I am wrong here
David) has said the group has rough concensus to use IPsec as the security
solution.  Now it might be that the rough concensus is there because it is a
forced solution from the IESG, however in that case I propose you take that
up with the Area Directors (and Jeff Schiller/Marcus Leech the security
ADs).  You are right, I would prefer a TLS based solution, I think it is
much more deployable... However this isn't the case so lets make IPsec
work...

I agree with you on user/protocol requirements.  I worked for a couple of
years on an IPsec product and am rather underwhelmed with its deployability.
Some of that was the tool that was developed, much of it was the problems
with getting a interoperable security policy that would work between my old
companies product and several competitors products.  The interesting thing
is we were actually targetting end-end rather than tunneled VPN like most of
the other vendors that I knew of...

Some interesting things that I saw (and I am very afraid of in the iSCSI
context were)
1) Micro policies just don't seem to work/scale - i.e. having a SA per
connection, rather than per link
2) Bulk crypto to 100 Mbps is possible, but going beyond is expensive (2
years old multiply by 2.25 for Moores Law)
3) Asymetric Crypto Matters
4) Its all about deployability - I have yet to see a cross
platform/interoperable security policy product
5) Encrypting traffic on subset of the corprate net has interesting
results - Corperation IT departments (at least my former employers) tend to
do a LOT of scanning, management traffic to your box...

These are the negatives, the possitives are
1) You can get it to work and work well
2) With cheap crypto accelerators (ie built into your commodity NIC) it is
cheap and fast without much CPU impact and can run above 80Mbs on a 100 Mbs
network

Bill

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, October 24, 2001 8:46 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: iSCSI: Login authentication SRP/CHAP

      paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 24 Oct 2001 13:25:04 -0400

> the IPsec requirements) all though IPS wants to put a SHOULD NOT implement

I thought that the IPS security draft made confidentiality optional,
but apparently either I'm confused or I was thinking about an older
version of that spec.

> ...  Just because

Agreed, which is one of the problems with an IPSec (or other crypto)
mandate.

> forced solution from the IESG, ...

That's a peculiar use of the term "consensus", if your speculation is
accurate.  My comment was based on observation of this list: I've seen
a bunch of debate on the topic, and my reading of it is that there was
(a) substantial opposition, (b) no clear technical justification for
why "MUST" was needed.  My reading of the IETF standards process is
that technical considerations are supposed to govern standardization
decisions, which is why I raised the point.

     paul