Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSCSI

From: "Jim Hafner" <[email-masked]>
Date: Wed, 29 Aug 2001 15:00:13 -0700

Bill,
I think I understand your question, so here's a remark.

I think a problem that creeps in to the iSCSI space (that doesn't exist in
essentially every other existing SCSI stack) is that a user can write an
application that acts like an iSCSI initiator and never ever go through the
OS stack.  (I've written an iSCSI initiator in Java that doesn't ever use
the host stack at all, just the standard network interfaces).   So, I could
easily have multiple iSCSI Initiators running (even in user space) on the
same machine.  At that point, I may want user level security.

If I didn't understand your question, I'll shut up (on this topic :-{))

Jim Hafner

"Bill Strahm" <[email-masked]>@ece.cmu.edu on 08/29/2001 02:23:20 pm

Sent by:  [email-masked]

To:   <[email-masked]>
cc:   "Ips@Ece. Cmu. Edu" <[email-masked]>
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: "Prasenjit Sarkar" <[email-masked]>
Date: Wed, 29 Aug 2001 23:22:44 -0700

Stephen,

You missed my point. The example of an user-mode FC driver was to
illustrate the creation of an networking API (like sockets) that (i) gives
access to the fibre channel
*network* and (ii) does not interpret the communication between the end
points. Such
an FC API (since it already exists) has as much of a user-level security
implication
as was pointed out in the case of iSCSI.

I agree mostly with the rest of what you said.

I hate to get embroiled in long-winded counter-productive mailing list
arguments,
so I shall not be responding any more.

Regards,
Prasenjit

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                    Stephen Bailey                                                         
                    <[email-masked]       To:     [email-masked]                           
                    cago.edu>            cc:                                               
                    Sent by:             Subject:     Re: ISCSI: User authentication vs.   
                    owner-ips@ece.        Machine Authentication for iSCSI                 
                    cmu.edu                                                                

                    08/29/2001                                                             
                    07:35 PM                                                               

Prasenjit,

I agree with Jim Hafner.  The notion of `user level security' is
exactly what iSCSI needs, due to the unique combination of factors
that compose an iSCSI system.  In the initial case, where the iSCSI
client is the host OS, the OS is fully capable of representing an
identity (being a user) and hiding that identity from unprivileged
users of that system.

> I'm not sure the problem you mentioned is specific to iSCSI as I have
seen
> a user-level Fibre Channel driver in action.

True.  However, the user-mode driver is granted full `control'
(i.e. root) privs if it is allowed to execute arbitrary SCSI commands.

Access to raw storage has traditionally been a rigidly protected
resource, which when granted, gives complete control of the associated
domain (which might be more than one system in a SAN or cluster).
This is a well-understood characteristic of the raw storage trust
model.

In the Berkeley networking model (praise the mighty), access to
network communication (other than evesdropping) is not a rigidly
protected resource.  The assumption is that the local endpoint is not
granted any additional power by being able to communicate arbitrarily,
and the remote endpoint must protect itself as appropriate to the
service it offers.

> The issue here is that the notion of user is an operating system
> abstraction and has no meaning in domains in which the
> OS has no administrative control (such as a SAN).

Not really.  A user is an authenticable identity in any form.  The
control is the access provided.

> Extending the notion of an user outside the domain of an OS requires
> primitives current SAN technology does not support (yet!)

I agree that the present infrastructure doesn't support this idea
well.  However, what we should do is define our security in such a way
that the SAN infrastructure can evolve towards the same type of
identity mechanisms that other networking services (try to) support.

If we do this right (and I think Jim's got the idea) it can support
both `the OS is completely trusted' (for now) and `each user has their
own credentials' (later) models.  We just need to make sure we don't
do anything stupid like claim that authenticable entity == IP address
in the protocol itself.  At present we're not in risk of doing that,
but maybe I should come out in support of it just in case :^)

I don't think there's any concrete change to what's already specified
to support this.  We certainly don't have to dot every I and cross
every T on the multiple identities per system model
(i.e. authentication and authorization infrastructure needn't
instantly be created to solve the full problem), but I guess we should
be aware of what we're shooting for as we specify additional security
behavior.

Steph

---

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

Pierre asks the following question.

"John,

Do i miss something? Why not use Certificate where
the subjectname is the iSCSI name (iqn or eui)?.
So as soon as the IPSEC SA are established each side
knows what intitiator/target is the other side.
There no need for extra password or alias.
The only problem with that is that some directory
as you mentionned below wouldn't support subjectname
as long as an iqn? "

I would like to see more discussion on the feasibility of this approach,
especially
since iSCSI and IKE/IPSec are disjoint processes.  Please, anyone, that
understands
how these different layers would communicate with each other (using
Standard IKE/IPSec
implementations) please help.  For instance how does the IKE get the iSCSI
name of the
system on which it is running, and how does the iSCSI layer find out the
"Subjectname"
the remote system used to establish the connection, since it must be check
that it is the
same name sent on the iSCSI Login."  (Otherwise any valid Certificate owner
could still
masquerade as any other iSCSI Initiator Node.)

Also, if we can figure out how the above works, we need to understand how,
in an SRP environment,
the iqn or eui type name can be used.  (Environment 3).

Further, following Mark's Environment 2, we still need to find a way to use
the iSCSI initiator Node
Name, or understand the ramifications of establishing and using a related
Alias for the
iSCSI initiator node name.

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

Pierre Labat <[email-masked]>@cup.hp.com on 08/30/2001 08:37:46 AM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: ISCSI: User authentication vs. Machine Authentication for
      iSCSI

John Hufferd wrote: Bill,
You are correct, in my opinion, on the problem statement, but not  on the
solution.

The IKE stuff will Get a system identified, and perhaps ensure that a
encrypted connection is put in place.  This then give the Source and Target
the Freedom to exchange stuff that would otherwise be in the clear, such as
iSCSI Node Names etc.  But after the iSCSI session is established, it is
between an OS and a target.  The OS, is the thing that actually owns the
resource, it only loans the resources, in some manor, to applications.

I was having a similar problem to what you stated, at the Irvine meeting,
and kept digging and objecting (off-stage) until I got the following more
acceptable response.

Environment 1: (Use of IKE with complete Certificates processing ( or
pre-Shared password), with ESP equal to something other then Null)
1. We use IKE to get a mutually authenticated and Encrypted communication
link.  This means that the Target knows that (at the IKE/TCP Layer) there
is, at the other end, an authorized thing.  (What or who that thing is,
relative to iSCSI is not really known).  This secure link can be
established either via Certificates or via a pre-Shared password.
2. An iSCSI Login can now be done, over a secure link, so the iSCSI
Initiator Name, and iSCSI Target Name etc can be exchanged securely.
Please note, just because you passed the IKE certificate gate does not mean
you are the iSCSI Initiator that you claim to be.John,

Do i miss something? Why not use Certificate where
the subjectname is the iSCSI name (iqn or eui)?.
So as soon as the IPSEC SA are established each side
knows what intitiator/target is the other side.
There no need for extra password or alias.
The only problem with that is that some directory
as you mentionned below wouldn't support subjectname
as long as an iqn?

Regards,

Pierre Therefore, a password,
for example, that is associated with the iSCSI Initiator Name can now be
used to perform an iSCSI validation of the Initiator.  (Please note, this
could, instead of a password,  be a Kerberos type Validation etc.)
3. David, and perhaps other used the words "User" or "Application" name to
address what was being addressed in 2 above.  But there was more to this
then just assuming that the iSCSI Initiator Name was the User name.  Since
folks may actually want to use existing infrastructure, to handle the
password management and authentication process, they will need to assign
what I might call an "Alias for the iSCSI Initiator" which can actually be
saved in the existing infrastructure user authentication repository.  The
point that was made to me, is that iSCSI Initiator Name (iqn or eui) will
not "fit" into things that contain "User Names" so we need to have a
corresponding "User Name" that we can actually authenticate using, for
example Microsoft Active Directory etc. Hence the need for a "Alias for the
iSCSI initiator.  (I really hate this, and wish there was something else we
could do.)