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

[Joshua Tseng <jtseng@NishanSystems.com>]

Stephen,
> 
> 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.

iSCSI is a transport protocol.  Its role is to transport SCSI commands
and data.  Therefore, the security associations negotiated during the
inband iSCSI security login phase should be bound to the principals
that define the iSCSI endpoints.  I believe this is the "iSCSI Name"
(formerly WWUI).  Attempting to bind iSCSI security to something that
sits above iSCSI is a layering violation.  This includes SCSI, OS, or
user identities, which all should be transparent to iSCSI.

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

This is SCSI's problem.  You should bring this up with T10.

Josh

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