RE: iSCSI: Security Enviornments

[Black_David@emc.com]

At the risk of further encouraging Doug ...

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

That's not the only piece of the current security text that
is "nebulous".  In any case, the relationship should be that
iSCSI sets up or runs over a suitably secure initiator-target
connection in a fashion that whatever access control mechanisms
T10 specifies for SCSI initiator-target sessions work in a
fashion that can be sufficiently relied upon.

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

I can think of a number of examples in which the
authentication server plays essentially no direct role
in authorization.  For example, access control lists
are usually not stored on authentication servers for
some fairly obvious scalability reasons.  The general
structure here is that things are implemented/structured
in a fashion that the authenticated identity can be
relied on for authorization even though the authentication
and authorization mechanisms are separate.  The passing
of SCSI LUN access control information over an authenticated
secure iSCSI channel described above would be another
example as long as the SCSI and iSCSI identities were
linked in some fashion.

> One could hardly make any meaningful tool to manage
> security without ability to control both authentication and authorization.

And a "meaningful tool" should certainly be capable of
accessing multiple interfaces to get its job done.  

> 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's managed to totally twist what I wrote, and make
at least two major mistakes in the process:
- Authorization is not completely out of scope.  Providing
	mechanisms to determine which iSCSI initiators may access
	which iSCSI targets is definitely in scope, and I believe
	iSNS does or will do this in its "zoning" support.
- The fact that something is out of scope for this WG
	does not prevent it from being standardized.  I would
	suggest that T10 is the appropriate forum in which to
	pursue a standard interface for configuring SCSI
	LUN access controls being defined by T10.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------