RE: Security Use Requirements

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

David,

The GSS-API supports efforts promoted by Julian.  Privacy at the SAN level
will be expensive and, if done in software, appear broken.  A
compression-encryption then signed with a digest will be very
computationally intensive and increase latency.  Just a signature would
provide integrity.  There are many mediums and applications that can provide
privacy as an add-on feature at the file level usable as required without
impacting the entire operation of the SAN. If the media provides protection,
then adding privacy at the SAN becomes redundant and may run into export
restrictions.  A SAN in Germany will not be useable by someone in Spain
because the fiber travels through France.

With all of this security, we have yet to discuss the back door.  How is the
user authorized?  The SCSI controller tells the user but where does the
controller discovery this information?  Who holds the key for the back door
and how does one go about changing the locks.  Most people still have
windows in their homes at the cost of privacy.  If it becomes important,
there are curtains that can be drawn over the window and the sound of
breaking glass is a bad signature.  Privacy applications, curtains, can work
on any drive and not just network drives.

Doug

> Bernard Aboba wrote:
> > >iSCSI envisions and allows multiple targets behind a single IP
> > >address and TCP port.  The targets are named (via WWUIs) in a
> > >fashion that neither IPsec nor TLS can be expected to understand
> >
> > Let me make sure I understand this. You will have multiple
> > SCSI authentications to the same target IP address and port.
> > Does the initiator port vary between them or is that the
> > same too?
>
> I haven't heard anyone strongly request this. Hopefully
> another body will handle this within the SCSI layer.  If
> there is demand I would suggest looking at how the NFSv4 WG
> handled this using GSSAPI.  But I personally think that is
> overkill for iSCSI.
>
> 	-David
>