RE: Security Use Requirements

[Black_David@emc.com]

> As far as a host-based IPSec implementation is concerned, we could use
this
> for the WWUI to identify the initiator and target (I don't think its
> feasible to have external security gateways use WWUI).  An IKE negotiation
> between iSCSI devices could thus use the WWUI to set up the IPSec SA's.
> However, RFC 2407 section 4.6.2.1 (IPSec DOI) indicates the only
identifiers
> usable (at least at the time of writing of RFC 2407) are FQDN's, IP
> addresses or subnets, X500 names, or X509 certificates as the identifier.
> If iSCSI intends to use WWUI, we would need to coordinate with IANA to add
> in WWUI as another identifier type.

Or lay out some guidelines for things that SHOULD or MUST be checked to
make sure that the identity used in IPSec is the correct one for the iSCSI
initiator or target.  This has some implications for iSNS security as well.

> But I wonder if this is all really necessary???  Isn't it sufficient to
have
> the IP addresses identify the SA endpoints?  Isn't this what most ISAKMP
> implementations are doing?  Is anyone aware of any other application that
> use something other than IP addresses or FQDN's to negotiate IPSec SA's???

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?

> This leads to the original point I was trying to make at the interim
> meeting, that for all practical purpposes, IPSec SA's really need only be
> negotiated between IP addresses.  Once a connection has been secured
between
> the IP addresses, then WWUI's are used for authorization in the iSCSI
login
> exchange.  Sure, if we really wanted we could go in and include the WWUI
in
> the ISAKMP exchange, but I question if this adds any value at all.

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

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