Subject: RE: iSCSI: Security Enviornments

From: [email-masked]
Date: Mon, 12 Feb 2001 22:51:48 -0500

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

Beyond that, a properly configured TLS should be adequately secure
for a SAN.  Doug's opinion that privacy should not be mandatory to
implement is hereby officially noted (i.e., he can stop repeatedly
reminding us of it), and I would point out that this was also
the rough consensus at the WG meeting in Pittsburgh, which I believe
remains the rough consensus of the WG.

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

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 12 Feb 2001 20:27:10 -0800

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