Subject: RE: Security Use Requirements

From: [email-masked]
Date: Fri, 9 Feb 2001 08:57:09 -0500

> I think it might help to explicitly define what you mean by "correct".
> For example, it might be possible for the iSCSI target to control
> access to LUNs based on characteristics of the certs negotiated
> in IKE, and characteristics of the IPSEC SA. However, I wouldn't
> suggest that something like this (which requires more advanced
> APIs than are generally available) is required or even
> generally useful.

The more important problem is one level closer to the network.
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
natively (and I strongly agree with the comment about not
changing IKE being the preferred course).  Bernard's comments
about linking iSCSI identity or proof of identity to IPSec are
along the lines of what needs to be done here.

We should stay away from individual LUN access issues, for
two reasons:
(1) They're in T10's domain and T10 is working on them.
(2) There really aren't any standard ways to do this sort of thing
	currently deployed in the Fibre Channel world, yet.
Some words on how to accomplish this by using a (virtual) target per
initiator or group of initiators whose access privileges need to be
distinguished would be worth including as an example, but such
an approach probably should not be required.

--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: "Bernard Aboba" <[email-masked]>
Date: Fri, 9 Feb 2001 08:32:31 -0800

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

If the same initiator port is used, I think there
will be a problem. How would the conversants know which IPSEC QM SA 
to use to send a particular transaction? On outbound, from 
the point of view of the IPSEC driver, it sees a packet 
come down with a given IP and transport header. Based on this
information, it decides which IKE QM SA the packet belongs
to, if any. So the driver has no notion of WWUIs, and needs
to make its decision purely based on the IP and transport
headers. If there isn't anything in there that is different
between the QM SAs, the driver will pick one, but it might
not be the right one.

---

From: David Robinson <[email-masked]>
Date: Fri, 09 Feb 2001 11:01:55 -0800

> Does the initiator port vary between them or is that the

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

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 9 Feb 2001 15:04:30 -0800

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

---

From: Michael Eisler <[email-masked]>
Date: Fri, 9 Feb 2001 17:25:06 -0800 (PST)

> If the media provides protection,
> restrictions.

Concern about export controls is a syntax area with
respect to the IETF.  RFC 1984.

> A SAN in Germany will not be useable by someone in Spain

My understanding is that France has relaxed its domestic use
control due to concerns about the the US/UK/Canada/Australia spying
on Fench domestic communications. I've exported 56 bit
privacy products to France, albeit with the degree of red tape that
makes the NSA look reasonable by comparision.

	-mre

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 9 Feb 2001 18:31:32 -0800

>handled this using GSSAPI.  But I personally think that is

Are you saying that we *don't* need to worry about multiple
SCSI authentications to the same target IP address and port?
That would certainly simplify things.

---

From: David Robinson <[email-masked]>
Date: Sat, 10 Feb 2001 23:30:22 -0800

> That would certainly simplify things.

I can easily see a design that has multiple authentications
on the same connection.  But I am going to argue that we
resist it strongly. Unlike NFS where there are multiple
principals on a node muxed over a single connection,
SCSI tends to have just one principal (the node) over
a connection. While I think that the SCSI community would
like to move towards the more complex model, they will have to
come up with a common model that will map to all the various
transports which I hope will be above the transport layer.
iSCSI can then just focus on securing the connection between
two nodes and let SCSI deal with multiple authentications.

I am curious if anyone else thinks we should try and tackle
the much harder problem at the iSCSI layer?

	-David