Re: ISCSI: User authentication vs. Machine Authentication for iSCSI

["Prasenjit Sarkar" <psarkar@almaden.ibm.com>]

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                                                         
                    <steph@cs.uchi       To:     ips@ece.cmu.edu                           
                    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