Subject: iSCSI: U=<user> in Authentication

From: "John Hufferd" <[email-masked]>
Date: Tue, 18 Sep 2001 18:22:16 -0700

Folks,
I think we should indicate in the Security section of the document how the
security Authentication process might validate that the iSCSI Initiator
Name sent in the Initial Login, has something approprate to do with the
"user" being authenticated.  (Otherwise, you could authenticate a user and
that user could claim/use any iSCSI Initiator Name in the InitiatorName
key=value pair.

It is kind of obvious how to relate the U=<user> to the approprate iSCSI
Initiator Name (in the case of SRP), and little less obvious with Chap,
though I think it would be the N=<N> parameter.  However, it is really not
obvious when using Kerberos, and SPKM.

It also should be possible for the initiator not to send another UserID, if
the Security Data Base the customer uses can support the iSCSI Initiator
Name as a UserID.  That is, it should be possible for the U=<user>
parameter not to be sent,and have that  imply  the value of <user> is the
iSCSI Initiator Node Name entered previously as a value in the InitiaorName
key=value pair. Same way with the N=<N> in Chap.

However, it is not clear, how you do similar things with Kerberos, and
SPKM.

What do you folks think about this, and how should we document it?

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

---

From: "Ofer Biran" <[email-masked]>
Date: Thu, 20 Sep 2001 15:28:02 +0300

Paul,

The implementers are sent to the relevant RFC for the definition of each
authentication method, so the clearest way in my opinion was to use the
exact keys
as appeared in the RFCs (with a simple statement e.g. -
"Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]"   ).

I don't think, as Steve doesn't, that there is a real parsing problem since
these
keys are authentication method's specific (and you know where you are at
that point).

   Regards,
     Ofer

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

"CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu on
19/09/2001 20:12:37

Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL,
      Ofer_Biran/Haifa/IBM <Ofer_Biran/Haifa/[email-masked]>,
      [email-masked], [email-masked]
cc:   [email-masked]
Subject:  RE: iSCSI: U=<user> in Authentication

I agree that more clarification regarding how to associate SCSI Names with
user identities should be provided.  I'm not sure if I agree that it should
be possible to omit the names entirely - however.  This would provide
another optional way to approach the exchange (may provide or may not)
which
adds complexity to this portion of the code, more test cases, more
unnecessary options, etc..  As you've mentioned it may also be different
depending upon the authentication method in use. There is certainly room
for
improvement here.

I have a bit of a gripe about the key=value pairs during authentication
phase in general.  First of all, the key names are not very descriptive,
which defeats the purpose of using Text keys in the first place (in my
opinion).  Secondly and more importantly, there are key values that are not
unique and depend upon what authentication method is in progress in order
to
decode/parse them.  For example, A=5 in CHAP for algorithm selection is
completely different that A=2345 in SRP.  Also N=initiatorName in CHAP is
totally different than N=5678 in SRP.   It would be much easier if the text
command parser didn't have to consider what authentication method was
running and that all key values were unique.  Thus I propose making the
following name changes to CHAP and SRP key values.  I'm not too concerned
about the exact key names used, just that they are somewhat descriptive and
unique.

CHAP Key Values

Old         New
---         --------
A           ChapAlgorithm
I           ChapID
N           ChapUser
C           ChapChallenge
R           ChapResponse

SRP Key Values

Old       New
---       ---
U         SrpUser
N         SrpSafePrime
g         SrpGenerator
s         SrpSalt
A         SrpPubKeyA
B         SrpPubKeyB
M         SrpSessionKey
HM        SrpKeyProof

Paul

+------------------------------------------+
Paul Congdon
HP ProCurve Networking
Hewlett Packard Company
8000 Foothills Blvd - M/S 5662
Roseville, CA   95747
phone: 916-785-5753
email: [email-masked]
+------------------------------------------+

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 20 Sep 2001 13:10:24 -0400

Ofer and Steve,

The fact that the keys are authentication method specific is exactly the
problem.  The difficulty with parsing non-unique keys is that you must tell
your parser what context it is operating under.  I can conceive of how this
can be done, it's not that hard, but it seems like unnecessary complexity.
It could get worse if key names overlap outside of authentication phase.

I agree that aligning with the names used in the relevant RFCs has some
merit.  Perhaps we could satisfy both needs by using names such as:

Srp-U, Srp-N, Srp-g, Srp-s, Srp-A, Srp-B, Srp-M, Srp-HM
Chap-N, Chap-I, Chap-C, Chap-R, Chap-A

Paul

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 5:28 AM
To: CONGDON,PAUL (HP-Roseville,ex1)
Cc: [email-masked]
Subject: RE: iSCSI: U=<user> in Authentication

Paul,

   Regards,
     Ofer

Ofer Biran

CHAP Key Values

Old         New
---         --------
A           ChapAlgorithm
I           ChapID
N           ChapUser
C           ChapChallenge
R           ChapResponse

SRP Key Values

Old       New
---       ---
U         SrpUser
N         SrpSafePrime
g         SrpGenerator
s         SrpSalt
A         SrpPubKeyA
B         SrpPubKeyB
M         SrpSessionKey
HM        SrpKeyProof

Paul

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 20 Sep 2001 10:13:57 -0700

I agree with Steve here.  The most likely deployment will be to use
InitiatorName as UserID whenever possible, but it doesn't seem necessary to
force that or allow the option to omit a name in one phase or another.

Paul

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 9:38 AM
To: John Hufferd
Cc: ietf-ips
Subject: Re: iSCSI: U=<user> in Authentication

John,

My opinion on this is:

What you are calling the UserID (i.e., U=<name>
for SRP, N=<name> for CHAP), could be the same
as the iSCSI Initiator Name, but it should not
be required to be so.

I see the N=<name> within CHAP (or U=<name> for SRP)
being used for authentication, the process of verifying the
Initiator is who it claims to be.  I also see it as
an integral part of the chosen AuthMethod.

I see the InitiatorName=<name> being used for
authorization, the process of verifying what
resources the Initiator can access.

There are two reasons I can think of that
the two names would be different:

1. The particular AuthMethod, or the implementation
of some third party authentication server, might
restrict what form a name can take that is not
compatible with iSCSI naming.

2. A group of Initiators might be configured to
use the same name for authentication purposes,
simply because they are being managed as a group
for authentication purposes.

Steve Senum

John Hufferd wrote:
> 
> OK then Steve, and others  I would be interested in your answers to the
> following questions:
> 
> If the UserID is exactly the same as the iSCSI Initiator Name, why would
it
> be entered again?
> 
> If the UserID is different, why was the iSCSI initiator Name required?  It
> is only used as:
> 1. A unique string that can ensure that the full Session identification is
> unique, The UserID can do that.
> 2. As an Authentication String.   The UserID can do that.
> 
> If the same users wants access to different storage from different
systems,
> that user can have a unique UserID for each system.
> 
> If the User wants the same storage access from different systems,
serially,
> then that user can use the same UserID on each system.
> 
> So is the UserID a substitute for iSCSI Initiator Name?
> 
> .
> .
> .
> John L. Hufferd
> Steve Senum <[email-masked]>@ece.cmu.edu on 09/19/2001 03:27:08 PM
> 
> To:   ietf-ips <[email-masked]>
> cc:
> Subject:  Re: iSCSI: U=<user> in Authentication
> 
> I don't think it should be possible to omit
> the usernames for AuthMethods SRP and CHAP.
> 
> On the SRP and CHAP key names, I am mostly netural,
> though I would prefer ChapId instead of ChapID.
> Since they are AuthMethod specific though, I don't
> really see the need to change them.
> 
> Steve Senum
> 
> "CONGDON,PAUL (HP-Roseville,ex1)" wrote:
> >
> > From: John Hufferd [mailto:[email-masked]]
> > Sent: Tuesday, September 18, 2001 6:22 PM
> > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > Subject: iSCSI: U=<user> in Authentication
> >
> > Folks,

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 20 Sep 2001 11:12:12 -0700

I agree with Paul on this Key Name issue.  We should not leave our keywords
up to a separate organization and process.  I can imagine that in the
future, we might want to permit a new Authentication routine.  It might
have Keywords that are duplicates of other, perhaps non security keywords,
which are part of the base iSCSI protocol.  Though I understand that we can
get the parsing done correctly, I see a lot of possible human confusion,
and communication problems with the straight insertion of other RFC
keywords into iSCSI.

.
.
.
John L. Hufferd

09/20/2001 10:10:24 AM

To:   Ofer Biran/Haifa/IBM@IBMIL, "CONGDON,PAUL (HP-Roseville,ex1)"
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: iSCSI: U=<user> in Authentication

Ofer and Steve,

Paul

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 5:28 AM
To: CONGDON,PAUL (HP-Roseville,ex1)
Cc: [email-masked]
Subject: RE: iSCSI: U=<user> in Authentication

Paul,

   Regards,
     Ofer

Ofer Biran

CHAP Key Values

Old         New
---         --------
A           ChapAlgorithm
I           ChapID
N           ChapUser
C           ChapChallenge
R           ChapResponse

SRP Key Values

Old       New
---       ---
U         SrpUser
N         SrpSafePrime
g         SrpGenerator
s         SrpSalt
A         SrpPubKeyA
B         SrpPubKeyB
M         SrpSessionKey
HM        SrpKeyProof

Paul

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 20 Sep 2001 11:48:04 -0700

.
.
.
John L. Hufferd

Ofer and Steve,

Paul

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 5:28 AM
To: CONGDON,PAUL (HP-Roseville,ex1)
Cc: [email-masked]
Subject: RE: iSCSI: U=<user> in Authentication

Paul,

   Regards,
     Ofer

Ofer Biran

CHAP Key Values

Old         New
---         --------
A           ChapAlgorithm
I           ChapID
N           ChapUser
C           ChapChallenge
R           ChapResponse

SRP Key Values

Old       New
---       ---
U         SrpUser
N         SrpSafePrime
g         SrpGenerator
s         SrpSalt
A         SrpPubKeyA
B         SrpPubKeyB
M         SrpSessionKey
HM        SrpKeyProof

Paul

---

From: [email-masked]
Date: Thu, 20 Sep 2001 19:48:33 -0400

> You would certainly want the end-user or administrator to have the
> capability of not entering the UserID if it is the same as 
> the iSCSI Node Name.

Sounds like a simple checkbox in a management GUI, or a switch on
a command line or ...

> I just think it would be useful and simpler, to include in our
> documentation a statement that says that the Default for U=<user> or N
> =<name> etc., if not entered, is the iSCSI Initiator Node Name.

I disagree - all the authentication parameters need to be present,
and management tools are quite capable of doing a string copy.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> Sent: Thursday, September 20, 2001 2:45 PM
> Cc: ietf-ips; 'Steve Senum'
> Paul, Steve,
> I understand your point, however, with duplication you often 
> cause hard to
> detect errors.  Often I have looked at two similar strings 
> and have had
> difficulty in seeing minor differences in them.  When 
> administrators, or
> end-users are the ones that are attempting to enter what 
> maybe very long
> strings (in the case of iSCSI Initiator Node Names), you can 
> imagine the
> finger checks maybe an important problem.
> 
> Also if you think through the process of how a UserID is 
> obtained, by the
> Initiator, you see that it is the end-user/administrator that 
> must enter
> the value.
> 
> You would certainly want the end-user or administrator to have the
> capability of not entering the UserID if it is the same as 
> the iSCSI Node
> Name.  In this case, a good implementation (if the UserID is 
> not entered)
> will include code to find and replicate the iSCSI Initiator 
> Node Name as a
> UserID.  Again, this is not a hard problem, just another 
> thing to handle.
> 
> I just think it would be useful and simpler, to include in our
> documentation a statement that says that the Default for U=<user> or N
> =<name> etc., if not entered, is the iSCSI Initiator Node Name.
> 
> 
> .
> .
> .
> John L. Hufferd
> "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]> on 09/20/2001
> 10:13:57 AM
> 
> To:   "'Steve Senum'" <[email-masked]>, John Hufferd/San 
> Jose/IBM@IBMUS
> cc:   ietf-ips <[email-masked]>
> > If the UserID is different, why was the iSCSI initiator 
> Name required?
> It
> > is only used as:
> > 1. A unique string that can ensure that the full Session 
> identification
> is
> > > I agree that more clarification regarding how to 
> associate SCSI Names
> > with
> > > user identities should be provided.  I'm not sure if I 
> agree that it
> > should
> > > depending upon the authentication method in use. There is 
> certainly
> room
> > for
> > > improvement here.
> > >
> > > opinion).  Secondly and more importantly, there are key 
> values that are
> > not
> > > unique and depend upon what authentication method is in 
> progress in
> order
> > to
> > > completely different that A=2345 in SRP.  Also 
> N=initiatorName in CHAP
> is
> > > totally different than N=5678 in SRP.   It would be much 
> easier if the
> > text
> > > about the exact key names used, just that they are 
> somewhat descriptive
> > and
> > > unique.
> > >
> > > CHAP Key Values
> > >
> > > Old         New
> > > ---         --------
> > > A           ChapAlgorithm
> > > I           ChapID
> > > N           ChapUser
> > > C           ChapChallenge
> > > R           ChapResponse
> > >
> > > SRP Key Values
> > >
> > > Old             New
> > > ---             ---
> > > U               SrpUser
> > > N               SrpSafePrime
> > > g               SrpGenerator
> > > s               SrpSalt
> > > A               SrpPubKeyA
> > > B               SrpPubKeyB
> > > M               SrpSessionKey
> > > HM              SrpKeyProof
> > >
> > > Paul
> > >
> > > I think we should indicate in the Security section of the 
> document how
> > the
> > > "user" being authenticated.  (Otherwise, you could 
> authenticate a user
> > and
> > > though I think it would be the N=<N> parameter.  However, 
> it is really
> > not
> > > It also should be possible for the initiator not to send another
> UserID,
> > if
> > > parameter not to be sent,and have that  imply  the value 
> of <user> is
> the

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 20 Sep 2001 17:18:48 -0700

David,
I said that the code is not hard, however, the GUI will have to span the
users normal Password handling system (since I am sure that a good GUI
would want to check it out), and it needs to know where the iSCSI Initiator
Node Names are stored etc.  Again not hard, just a little bit more then
most folks thought about.  Again, I do not think the GUI part is important,
every vendor will do it better then every other vendor.

What I don't understand is why not have the target copy the string from the
TargetName=<value> string to the U=<user> string.  That has got to be the
simplest thing to do.  Why have both strings transferred and then have to
explain to every one why the Target cant just do the simple string copy you
mentioned.  Not doing that seem kind of dull.

.
.
.
John L. Hufferd

[email-masked] on 09/20/2001 04:48:33 PM

To:   John Hufferd/San Jose/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: U=<user> in Authentication

--David

---

From: "Ofer Biran" <[email-masked]>
Date: Mon, 24 Sep 2001 10:52:07 +0300

OK, we'll add SRP_ and CHAP_ prefixes to their keys.

  Regards,
     Ofer

Ofer Biran

John Hufferd/San Jose/IBM@[email-masked] on 20/09/2001 21:12:12

Please respond to John Hufferd/San Jose/IBM@IBMUS

To:   [email-masked]
cc:   Amy N Congdon/Austin/IBM@IBMUS, PAUL__"
      <[email-masked]/OU=San Jose/O=IBM/@boulder.ibm.com
      (HP-Roseville,ex1)"@westrelay02.boulder.ibm.com
Subject:  RE: iSCSI: U=<user> in Authentication

.
.
.
John L. Hufferd

Ofer and Steve,

Paul

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 5:28 AM
To: CONGDON,PAUL (HP-Roseville,ex1)
Cc: [email-masked]
Subject: RE: iSCSI: U=<user> in Authentication

Paul,

   Regards,
     Ofer

Ofer Biran

CHAP Key Values

Old         New
---         --------
A           ChapAlgorithm
I           ChapID
N           ChapUser
C           ChapChallenge
R           ChapResponse

SRP Key Values

Old       New
---       ---
U         SrpUser
N         SrpSafePrime
g         SrpGenerator
s         SrpSalt
A         SrpPubKeyA
B         SrpPubKeyB
M         SrpSessionKey
HM        SrpKeyProof

Paul