RE: Security Use Requirements

[Black_David@emc.com]

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
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------