RE: Security Use Requirements

["Bernard Aboba" <aboba@internaut.com>]

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

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.

A thought: if you want to do access control based on the source
IP address, you will need to be using AH, rather than ESP,
since the former's MIC covers the IP header whereas the latter
does not.

>Isn't it sufficient to have the IP addresses identify the
>SA endpoints?  Isn't this what most ISAKMP implementations are doing?

In practice, this is what implementations do, yes.

>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

I think you're confusing IPSEC and TLS. In the case of our IPSEC
implementation, we use a machine certificate that includes the
machine name. The machine cert is obtained after domain
auto-enrollment, after the machine key and name have been
generated. So in practice, the machine name and therefore
the machine cert used by IPSEC will be unique.  Note that
the machine cert used for IPSEC may *not* be the same
as the cert used for SSL/TLS.