RE: iSCSI: Security Enviornments

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

David,

Thank you for the information.  You have made it clear you view iSNS is to
be the source of authorization.  I fail to understand what limitation exists
using LDAP directly versus this rehash of DNS and LDAP, but you should
understand the importance of asking such dumb questions.  Although the SCSI
target can be programmed to respond with authorization and this is clearly
within the scope of the T10 group, security management must be able to
endure device failure.  This implies security is placed safely somewhere
which contains both authentication and authorization information.  Forgive
my ignorance, but being a network storage protocol, I assumed maintenance of
this security scheme would also be network based and outside the scope of
T10.  Telling the device about these settings would be within their domain.
Security can be seen as good as the weakest link in the chain.  In this
case, iSNS is the weak link.  Again, thank you for enduring these dumb
questions and as you may have guessed, I am neither encouraged or
discouraged, simply confused.

Doug

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