RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

See below:

> There are definitely people out there using X.509 
> certificates for this
> purpose.
> The most common certificates bind keys to DNS domains, but 
> the domain in
> the cert need not be the FQDN of the machine using the cert (e.g.,
> www.foo.com
> may consist of a bunch of machines behind a web load balancer, all of
> which present the same certificate to browsers - note that 
> this is actually
> an SSL/TLS example, but the same thing can be done in IPSec).  I don't
> know what else is in common use - Ran or Bernard?

I agree absolutely this is always the case for SSL/TLS.  The Cert either has
the FQDN or hostname of the machine.  I don't know if there are IPSec
implementations doing this, although it wouldn't surprise me if there were.

> If I understand this correctly, Josh is advocating that there 
> be no required
> relationship between the IP addresses used to authenticate 
> IPSec SAs and
> the WWUIs used to authenticate iSCSI login ... allow me to 

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.

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.

> demolish this
> strawman :-) ... I have at least two significant concerns about this
> approach:
> - 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.
It should be able to defeat any spoofing attacks, including those from bar
or anywhere else.

> 	and target identity makes the adversary's job 
> significantly easier.
> 	FCIP has a similar issue in its tunnel configuration.
> - It also opens up a set of man-in-the-middle attacks based on the
> 	adversary being *between* one of the iSCSI nodes and its IPSec
> 	gateway.  Many IPSec gateways are located one or more hops
> 	from the endpoints that they protect, and it's not in general
> 	correct to assume that the network protected by the gateway
> 	is inherently secure.

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

> Given the choice, I'd much rather lay down a set of rules and 
> guidelines
> for identity checking than resort to running an end to end 
> authentication
> and cryptographic integrity protocol inside an IPSec tunnel.

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

Josh
> 
> With my WG co-chair hat on, I want to clarify the above by 
> stating that
> I believe that the WG must consider the two classes of attacks/threats
> that I itemized above, but also that the "Given the choice" sentence
> above is probably not a comprehensive taxonomy of the possible
> countermeasures.
> 
> 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
> ---------------------------------------------------
>