Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSC SI

From: Charles Monia <[email-masked]>
Date: Wed, 29 Aug 2001 15:51:16 -0700

Hi Bill:

Everything you say is right, up to a point. The functionality envisioned is
a virtualization environment in which the operating system, acting on behalf
of a user, instantiates an initiator entity at the bottom of the O/S driver
stack.  That entity in turn, may be logged into a virtualized storage
environment created specifically for that user. Afterwords, all i/o directed
to that initiator is controlled by the standard O/S mechanisms.

All this is analogous to plugging in a new hardware HBA. The powerful
feature in this case is the ability to totally control the 'HBA's' view of
the storage network.

Charles 
> -----Original Message-----
> From: Bill Strahm [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 2:23 PM
> To: [email-masked]
> Cc: Ips@Ece. Cmu. Edu
> Subject: RE: ISCSI: User authentication vs. Machine Authentication for
> iSCSI
> 
> 
> I am not sure that helped.  Again, the model of a Tape drive...
> 
> The user does not own the tape drive, the operating system 
> owns the tape
> drive, when I (as a user) wants to use the tape drive, I ask 
> the operating
> system, it grants me access, and I go on.
> 
> In fact from a purely SCSI level, I do not believe there is 
> any concept of a
> user at all, the Operating system on the device provides the 
> concept of a
> user through the OS abstraction layer.
> 
> The problem that I am having is that I do not see how I can make user
> security work through the OS abstraction.  And if the OS HAS 
> to know about
> the multiple users, I now have to trust the OS as well, which 
> means that
> effectively I have one user on the machine anyway...
> 
> Bill
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 2:06 PM
> To: Bill Strahm
> Cc: Ips@Ece. Cmu. Edu
> Subject: Re: ISCSI: User authentication vs. Machine Authentication for
> iSCSI
> 
> 
> Bill Strahm wrote:
> >
> > I have been fighting with this problem since I left LA.
> >
> > I am not aware of any usage scenarios today where block 
> devices are owned
> by
> > the user rather than the machine.  I will conceed that in 
> many instances
> the
> > first thing the system does is assign the resource to a use (tape,
> scanner,
> > etc.) but the machine still owns the resource and can in 
> fact remove it
> out
> > from under the user...
> >
> > I am not to certain how I could build a trusted iSCSI 
> environment where
> one
> > user would have no knowledge about what was happening with 
> other users in
> a
> > malicious environment (especially where a system was 
> participating in the
> > exposure of resourses).  Examples of this include things 
> like co-located
> Web
> > hosting where a single user scans process memory looking 
> for 1Kbit of
> random
> > data, and when finding it attempts to determine if that is 
> the private key
> > of a user sharing the resource.
> >
> > The reason I am bringing this up, is I am not sure trying to define
> security
> > above the machine level makes any sense for iSCSI.  Aren't most SCSI
> devices
> > owned by the Operating System not the User and partitioned 
> out by the
> > Operating System to the users ?  If this is the case many of our
> > authentication methods simplify to simple IKE identities.
> >
> > Bill
> 
> Bill-
> 
> As you pointed out, there is a case where just using IKE with
> an iSCSI AuthMethod of "none" is valid.  That case is where:
> 
> - There a one-to-one correspondence between an initiator and an
>   operating system
> - IPsec is being used for all iSCSI traffic
> - The customer is willing to deploy public key certificates on the
>   client side (for each initiator) as well as on the devices
> 
> If all of the above are true, iSCSI can certainly use an AuthMethod
> of none, and be done with it.
> 
> However,
> 
> - There are cases (David Black brought up some tape 
> applications) where
>   more than one initiator might exist on an operating system
> 
> - IPsec is not likely to be used for a large percentage of iSCSI
>   traffic any time soon
> 
> - When IPsec is used, many customers will have an easier time with the
>   familiar model of authenticating the server "machine" but using a
>   dummy certificate for the client.
> 
> If any of the above are true, iSCSI-level of authentication is
> required.
> 
> Hope this helps,
> 
> Mark
>

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 30 Aug 2001 15:41:39 -0700

Just one clarification on John's response (which I agree with, by the way,
as well as Charles and Mark's comments).  John stated.

>Note: Mark pointed out that this was the way Web servers worked.
>3. Chap can  be used in this environment since the Link is already secure
>and encrypted, and sending the password in what otherwise would have been
>in the clear, is protected by the link encryption.

CHAP does not send passwords in the clear.  It may send user identities in
the clear, and it requires a shared secret to be stored in multiple
locations, but the password is hashed using MD5 or other similar algorithm.
MD5 may not be considered the tightest hash algorithm, but it produces stuff
far from clear text.

Paul

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 30 Aug 2001 16:34:36 -0700

Mark,
You clearly understand part of the problem well.  You need to step a bit
further.
Just recommending the names be the same, does not address what happens
when they are not.  So let me take you a bit further.

A system that has an iSCSI Initiator Node Name "iqn.com.mother.jump"
is given the UserID of "Wonder".
Now assume that "Wonder" is Authenticated. Now the iSCSI client system with
UserID
of "Wonder" can now masquerade as any other Authorized iSCSI Initiator
Node, by putting that name on its Login.

This seems like it is not a real good idea, so the target system needs to
prevent this.  That means that the Target System needs to bind together
in some way the UserID and the approprate iSCSI Initiator Node Name.

So only recommending that the UserID and iSCSI Initiator NodeName
be the same means that everyone MUST implement a relationship
binding Database that can be used to ensure that no one can masquerade
as some other iSCSI Initiator Node.

This also means that it needs to be tied into the UserID authorization
Database/Directory such that when name etc. are change (which
often they do), the iSCSI Target Device relationship/Binding Database
is also updated.  If this is a manual process, it will get out on hand
very quickly.

For those of you that think this is a very simple one to one table, you
might want to read Marks note again, he said that he could have
a different UserID for each network he logs into.  If there is any
cross connect to a specific iSCSI Target this means that the
iSCSI Target Device needs to perhaps carry more then one
UserID for each iSCSI Initiator Node Name.

That may not be a significant problem since the networks
may never interconnect.  Opinions would be useful here.

Is their any other reason that an iSCSI Initiator Node would  have
more then one UserID?

Does anyone have a technique to ensure that only the iSCSI
Initiator Node Name need be managed?

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

Mark Bakke <[email-masked]>@cisco.com on 08/30/2001 01:07:35 PM

Sent by:  [email-masked]

To:   Stephen Bailey <[email-masked]>
cc:   [email-masked], John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: ISCSI: User authentication vs. Machine Authentication for iSC
      SI

Stephen Bailey wrote:
>
> > The new Name (UserID) is exactly what was implied at the meeting in
> > Irvine.
>
> Oh.  How horrible.

Ideally, you're right.  For instance, if iSCSI was using AuthMethod=CHAP,
then it would be great if the CHAP username (N) specified was identical
to the InitiatorName.

In the draft, that's not how it is.  The user names for CHAP and SRP
(I'm not sure about the others) are specified separately from the
InitiatorName, so there's currently nothing in the protocol to prevent
them from being different.

In practise, there might be times when having them be different
makes the "fit in" better with whatever administration scheme is
out there.  For instance, if my desktop was assigned some iSCSI
storage, and my username and password were kept on a RADIUS server
somewhere, for use by file servers, web servers, and iSCSI servers
or devices, my user name is likely to be a non-globally-unique
string, probably "mbakke".  However, that's not likely to be
my InitiatorName.  To make them the same, I would either have to
change my InitiatorName on my desktop to "mbakke", to fit in with
my login on all of our web and file servers, or the admin would
have to create a new login for my iSCSI stuff on the RADIUS server,
and maintain two of them.  Changing my login on everything to
match an iSCSI name is likely not an option.

Another possible place this could happen is if I am obtaining
iSCSI "services" from more than one administratively-separate
environment.  Each of these environments may prefer to assign
me a user name for login that matches their own internal scheme.
I may have some control over this, but in the end, it has to be
unique within the service-provider's scheme.  This is very
similar to setting up a user-name for your ISP at home; you
may request a particular name, but if the ISP already has one,
you have to pick again.

The point is that if one had two of these environments providing
services, they may each need a separate user name.

Of course, the latter example could be solved by having the
admins accept the initiator name that's already on my iSCSI
client as the user name; these are supposed to be unique
anyway.  The only trouble then is the same as before; if I am
getting more than just iSCSI services from this provider, they
would then have to maintain two user names for me.

A third reason this might happen is that some centralized
password authenticated services such as RADIUS may have
length restrictions on their user names that are shorter than
what is allowed in an iSCSI initiator name.

Anyway, implementations have the most flexibility the way
these protocols (SRP, CHAP) are currently documented.  I think
that we could recommend that the iSCSI initiator name be the
same wherever possible, but I don't see how we can require it.

>
> > A number of us, I am sure, think this is a very poor direction for an
> > implementation.
>
> Agreed.  I just wanted to walk the space a little bit.  My point is
> that while traditional SCSI passthru does confer control privs (and is
> protected as such), it doesn't need to.  Specifically, a client using
> SCSI passthru is not actually given the identity of the host OS, per
> se.
>
> > So I believe we must consider such a potential application as
> > probably a rouge application and do nothing to help this, and work
> > to prevent it.
>
> I understand what you're saying, but I'm not sure it confers much
> architectural direction.  There already must be a concept of identity
> which is independent of anything bound to a particular system (e.g. IP
> address, hardware network port etc.), so there's no way to exclude
> that.
>
> > The important issue is, can we make the iSCSI Initiator Node Name be
> > used as the UserID.

Again, I think that the best we can do is recommend that they
be the same, but I don't think we can take the step of requiring
it.

> Agreed.  Are there minutes to the meeting?
>
> Thanks,
>   Steph

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