Subject: RE: iSCSI: Login authentication SRP/CHAP

From: "Lee, CJ" <[email-masked]>
Date: Wed, 17 Oct 2001 14:44:06 -0700

Michael,
     According to RFC2945, SHA1 is the hash algorithm used by SRP.  For
CHAP, according to 08 draft, MD5 is the required to be implemented algorithm
and other algorithms can certainly be added if so desired.  Unlike RFC2945,
RFC1994 describes CHAP in the context of PPP LCP negotiation and one
should/could not apply it directly to be used in iSCSI login authentication.
Take a look at the 08 draft Appendix A, CHAP challenge, response exchanges
are carried out using login commands and responses.  RFC1994 merely spells
out how response is calculated based on the challenge and info. associated
with the authentication session (ID) and the communicating peer (secret).

CJ Lee
Adaptec, Inc.

-----Original Message-----
From: Michael Schoberg [mailto:[email-masked]]
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: "Ofer Biran" <[email-masked]>
Date: Thu, 18 Oct 2001 13:34:22 +0300

Michael,.

For the SRP questions:

The hash is SHA-1 for which the parameter definitions are given in
 RFC -2945. We'll make that more clear (will reference the SRP-SHA1
mechanism there).

The issue of the allowed DH groups (N,g)  is still open - would hopefully
be closed by next revision and a statement for that will be added.

  Regards,
     Ofer

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

Steven Senum <[email-masked]>@ece.cmu.edu on 17/10/2001 22:59:52

Please respond to Steven Senum <[email-masked]>

Sent by:  [email-masked]

To:   "IPS Reflector (E-mail)" <[email-masked]>
cc:
Subject:  Re: iSCSI: Login authentication SRP/CHAP

Hi Michael,

I can't answer your questions on SRP, but I probably
can answer a few on CHAP.

The CHAP_A key (algorithm) is specified in RFC 1994:

         5       CHAP with MD5 [3]

The CHAP_I (identifier), CHAP_C (challenge),
CHAP_N (name) and CHAP_R (response)
are also specified in RFC 1994:

   Identifier

      The Identifier field is one octet.  The Identifier field MUST be
      changed each time a Challenge is sent.

      The Response Identifier MUST be copied from the Identifier field
      of the Challenge which caused the Response.

   Value (challenge and response)

      The Value field is one or more octets.  The most significant octet
      is transmitted first.

      The Challenge Value is a variable stream of octets.  The
      importance of the uniqueness of the Challenge Value and its
      relationship to the secret is described above.  The Challenge
      Value MUST be changed each time a Challenge is sent.  The length
      of the Challenge Value depends upon the method used to generate
      the octets, and is independent of the hash algorithm used.

      The Response Value is the one-way hash calculated over a stream of
      octets consisting of the Identifier, followed by (concatenated
      with) the "secret", followed by (concatenated with) the Challenge
      Value.  The length of the Response Value depends upon the hash
      algorithm used (16 octets for MD5).

   Name

      The Name field is one or more octets representing the
      identification of the system transmitting the packet.  There are
      no limitations on the content of this field.  For example, it MAY
      contain ASCII character strings or globally unique identifiers in
      ASN.1 syntax.  The Name should not be NUL or CR/LF terminated.
      The size is determined from the Length field.

Basically, iSCSI just uses a different encoding,
since it is sending "text" keys, instead of binary.

A sample output from my (Cisco's) implementation is as follows:

I-> AuthMethod=CHAP,none (CSG,NSG=0,1 T=1)

T-> AuthMethod=CHAP (CSG,NSG=0,1 T=0)

I-> CHAP_A=5 (CSG,NSG=0,1 T=0)

T-> CHAP_A=5 (CSG,NSG=0,1 T=0)
    CHAP_I=70
    CHAP_C=0x9593dd5e25f87b9e0fcc6891e6670461

I-> CHAP_N=u1 (CSG,NSG=0,1 T=1)
    CHAP_R=0x7e64294a4376affca14cdaecf3c72e21

T-> (CSG,NSG=0,1 T=1)

You can also look at Cisco's Linux implementation on SourceForge:

http://sourceforge.net/projects/linux-iscsi

Hope this helps.

Regards,
Steve Senum

---

From: "Lee, CJ" <[email-masked]>
Date: Tue, 23 Oct 2001 11:23:51 -0700

Bill,
   What I am trying to say is between SRP and CHAP (the subject) I would
pick SRP as MUST to implement base on the security strength of the protocol.
Forgive my naineness, I just don't understand why is

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

Why 'can't be used' (SRP I suppose)?  Don't you have the same per user
secret that needs to be amnaged on target side with CHAP as well?

cj

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

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

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

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

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

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: "Julian Satran" <[email-masked]>
Date: Wed, 24 Oct 2001 15:55:55 +0300

Bill,

You seem intent on having a working solution that fills a specific set of 
requirements.
As the ideas you put forward are beyond a simple controversial technical 
item but not "fleshed out" enough for simple mortals to read, I think that 
the group (list) could benefit from you having all your ideas about 
requirements and how they should be implemented completely fleshed out in 
a submitted draft that we can read and judge.

Thanks,
Julo

"Bill Strahm" <[email-masked]>
Sent by: [email-masked]
23-10-01 19:55
Please respond to "Bill Strahm"

        To:     "Lee, CJ" <[email-masked]>
        cc:     "IPS Reflector \(E-mail\)" <[email-masked]>, Ofer Biran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: Login authentication SRP/CHAP

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

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

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

2.

  Regards,
    Ofer

Ofer Biran

Dear Ofer:

Best,
Kirsten

  Thanks in advance,

      Ofer

Ofer Biran

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

Bill

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

Joe Czap
IBM Storage Networking
[email-masked]

---

From: "Ofer Biran" <[email-masked]>
Date: Fri, 26 Oct 2001 19:14:04 +0200

Bill,

IP
> claims on the usage of SRP in iSCSI ???

I'm not aware of any IBM claims on SRP, but I cannot make any such official
statement for IBM. Do yo have any specific IBM patent in mind or you asked
the
above just because you answered ME, and I happen to work for IBM ?

  Regards,
    Ofer

Ofer Biran

"Bill Strahm" <[email-masked]> on 23/10/2001 17:32:51

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

To:   Ofer Biran/Haifa/IBM@IBMIL
cc:   Joe Czap/Raleigh/IBM@IBMUS, "IPS Reflector \(E-mail\)"
      <[email-masked]>, John Hufferd/San Jose/IBM@IBMUS
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]