Subject: RE: Security Use Requirements

From: [email-masked]
Date: Wed, 7 Feb 2001 19:35:38 -0500

Before I launch into the latest response to Josh, I want to
summarize the high level point I'm trying to make:

	It isn't enough to just point to existing security mechanisms and
	say "use these".  It's necessary to say how to use them with
	the protocol and what other assumptions must be true in order
	to achieve the desired security properties - some of these
	assumptions will be requirements on other components/protocols
	in the environment.

This is particularly true because iSCSI contains a naming architecture
that does not match the identities used in existing security mechanisms,
resulting in a need to spell out in detail what is being authenticated
using what sort of identities, the relationships (if any) among the
different sorts of identities, and how those relationships are achieved/
assured.

There's nothing in principle wrong with the existing security mechanisms
being discussed - the devil is in the details of exactly how they're used.
The following set of responses to Josh provide some examples:

> There is an implied relationship in that once a set of SA's is set up
> between two IP addresses, each endpoint is completely secure when talking
to
> the other endpoint.  This includes spoofing, man-in-middle, eavesdropping,
> etc...  If an iSCSI login comes
> in from the other endpoint IP address=A, then I KNOW it is coming from IP
> address=A.  If that login from IP address=A says WWUI=XYZ, then I can now
> take action to allow or disallow WWUI=XYZ.

An important assumption underlying the "implied relationship" is that the SA
terminates at the iSCSI endpoints.  That's not in general the case for
traffic passing through IPSec security gateways and hence is the sort of
thing that has to be spelled out if/when this sort of setup is intended.

FWIW, "completely" is also not the right word - IPSec can set up SAs that
provide integrity but not confidentiality, and hence do not protect against
eavesdropping, but I'll bet that was just a poor choice of words
on Josh's part.

> But what if it is really WWUI=PDQ just pretending that it is WWUI=XYZ at
IP
> address=A?  Well, then there is already a public key authentication
> mechanism defined in the current iSCSI draft, which presents a digital
> signature of the iSCSI login message. Since I have the public key of the
> real WWUI=XYZ, I can locally regenerate the required digital signature of
> the REAL WWUI=XYZ.  If it doesn't match, then I reject the login.

But how do one know that one has the *right* public key?  Since
certificates aren't required in the current iSCSI draft, and the key
distribution mechanism is not specified, all sorts of mischief is
possible if naked public keys are being passed around.  Needless
to say, that's not a particularly intelligent way to do key distribution,
but like the previous case, a discussion about what is required
to assure that key distribution actually distributes the correct
keys (and how to verify that if necessary) is in order.  The
current iSCSI draft also includes a number of weaker authentication
mechanisms that are vulnerable to man-in-the-middle attacks when
there is not an end-to-end SA in contrast to public key mechanisms.

> > - It opens up a set of attacks based on subverting the mechanism (or
> > 	lack thereof) used to associate IP addresses with iSCSI targets
> > 	(and initiators). 	If iSCSI target T is supposed to be behind
IP address
> > 	foo, and the adversary can convince initiator I to access T
> > 	by instead opening up a tunnel-mode IPSec SA to a different
> > 	IP address bar, the absence of any check between IP address
> 
> This could never happen.  Remember, initiator I has an SA to IP address
foo.

That's not correct.  The analogous attacks on DNS are old news.
This class of attack targets the configuration/discovery/naming
mechanism(s), convincing I to initially contact T at bar rather than foo -
once I makes this mistake, it's downhill from there.  It's necessary
to spell out the base assumptions, some of which will be requirements
on configuration/naming/discovery and authentication, and explain
how to get from them to the conclusion that this sort of attack can't
happen.

> If the user chooses to deploy gateway-based security, then of course there
> must be other measures taken to secure against attacks between the iSCSI
> node and the gateway.

And some of those measures will almost certainly be
mandatory-to-implement if there are no words in the spec
about how the gateway SHOULD/MUST be related to the
iSCSI nodes accessed through it.

> However, I believe having the iSCSI node transfer its
> WWUI to the gateway so that the gateway can set up an WWUI-based SA
> is not practical.  How would you do it?  Would you need another IPSec SA
to
> transfer the WWUI between the iSCSI node and the gateway?

The short answer is configuration of the SPD and related things on
the gateway (assuming the gateway can use WWUI identities to set
up SAs), but that misses the point.  The point is that just saying
"use an IPsec gateway" isn't enough.  Something more needs to be
said about *how* to use the gateway to achieve the desired security
properties.  For example, a suitably secured iSNS may be one
place to put the bindings between WWUIs and IP addresses, which
would allow IPSec SAs based on IP address identities to be used
to help assure WWUI-based authentication.

> There already is a public key authentication mechanism in iSCSI.  I think
> this is all that is required.

The text describing this in the -03 version of the draft needs some
significant work.

Thanks,
--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: Sean Quinlan <[email-masked]>
Date: Wed, 07 Feb 2001 23:56:06 -0500

>         assumptions will be requirements on other components/protocols

This has been an interesting thread to read.  I could not resist adding a
few comments of my own.

Many posts ago, there was mention of three levels of security for iSCSI
        
	1: none
	2: iSCSI authentication
	3: tls or IPsec

these level seems to correspond to what is in the version 3 draft.

The trend in the current discussion seems to be that security must be implemented.
Correct me if I am wrong, but I am under the impression that fibre channel currently
is used at level 1 (although there is CRC).  I was also under the impression that
one of the main motivations of iSCSI was the belief that ethernet would win over
Fibre Channel as a network technology and hence the desire to send SCSI over ethernet.
Assuming this is the case, it would appear that there is a ready market for devices
that have no security and are attached by dedicated ethernet based SAN.  I would assume
that if iSCSI ever becomes the interface to disk drives then the no security option
would be popular for such devices with the assumption that the drives are combined
within boxes that have security implemented at the outer level.  I doubt that drive
manufacturers would be very keen to implement IPsec in their devices...

the current draft of iSCSI describes a rather large selection of authentication options
for both login and per PDU.  When reading the text I get the impression that iSCSI
will support both login and data authentication, but the draft is missing many details
I would expect - for example what is the key to use for hmac-md5-96.  The impression
I get from the posts is that iSCSI will NOT support data authentication because it
is considered too hard to get security right.  I agree that getting security correct is tough,
but data authentication is well understood and not very tough at all.  All the
difficulty is in the session authentication and session key generation - which it
appears iSCSI will support.  In my opinion, iSCSI would be better off with fewer
session authentication methods - perhaps just SRP - and with a well defined
data authentication method.  I know people on this list disagree.. but with a little
work I think iSCSI could achieve a high level of data integrity without the
complexity of tls or IPsec.  Assuming iSCSI will support session authentication, the
work required to include data authentication is relatively small.  A small aside...
at least in software and on modern CPUs, hmac-md5-96 and CRC32 take about the
same amount of time to compute.

Obviously, iSCSI should be able to take advantage of security methods such as TLS and IPsec.
I would suggest that iSCSI would be better off if it left all use of public keys to
such protocols and avoid using them in iSCSI authentication.  Perhaps the same can be said for
all encryption.  On the other hand, I think people need to be aware that TLS and
IPSEC/IKE are rather massive entities themselves - As a point of reference, OpenSSL - a
free version of TLS is over 140K lines of C - by comparison, all of Berkeley TCP/IP is 40K.
Just dealing with X509 certificates is a nightmare itself 		http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
I know you can use TLS and IPsec without buying into the whole Certificate Authority/
Revocation List mess, but then you need to describe what you are planning to use as an alternative.
I suspect if iSCSI mandates that iSCSI implementations must also implement IPsec, their
will be a lot of products that punt by stating an IPsec gateway must be used...

just my two cents...