Subject: iSCSI: Login authentication SRP/CHAP

From: Michael Schoberg <[email-masked]>
Date: Wed, 17 Oct 2001 14:53:09 -0500

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: Wed, 17 Oct 2001 14:19:38 -0700

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

SRP_s = SRP salt

---

From: Steven Senum <[email-masked]>
Date: Wed, 17 Oct 2001 15:59:52 -0500

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