RE: iSCSI: Security Enviornments

["Douglas Otis" <dotis@sanlight.net>]

David,

> > Consider aspects of management.  If the SCSI controller
> > responds to client with lists of accessible devices, how
> > is the SCSI controller informed?  How is access managed
> > in a uniform manner?
>
> I'd recommend not discussing security of management right now beyond that
> necessary to ensure that iSCSI identities and authentication work as
> intended/required.  Significant pieces of this are also outside the scope
> of the working group, for example, how a target gets the information
> required to respond to a REPORT LUNS command is in T10's space, not the
> ips WG, and the same is true of SCSI-level access controls.

I understand that Report LUNS is a SCSI command and outside the scope of the
WG.  Security has two aspects regardless of the mechanisms used to inform
the drivers, authentication and authorization.  These to aspects go hand in
hand.  As it is structured currently, there is only some nebulous concept
that authentication is tied in some indirect fashion to an associated
authorization.  As there is going to be extensive efforts in obtaining the
authentication, it also make sense that there be some means to assess and
express the associated authorization.  How do you expect that aspect to be
managed?  Would you not expect the server that provides authentication to
also contain the authorization or at least some means of expressing this
aspect of security?  One could hardly make any meaningful tool to manage
security without ability to control both authentication and authorization.

Would it not be to the benefit of the WG to consider this topic more fully
than to just say that authorization is outside the scope whereas
authentication is not.  These are not independent topics.  Leaving out a
standard means of controlling both aspects found in any security scheme
ensures only vendor unique tools for management will be possible.

Doug