RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

> 
> Mandatory-to-implement means "how the protocol behaves
> on the wire" -- i.e., if one party starts to use a mandatory-to-
> implement mechanism, the other party must respond
> appropriately.  Whether 1, 5, or 15 boxes are used 
> is not something a protocol spec should care about,
> although if more than one box is used, whoever assembles
> those boxes will have to deal with the security issues
> that arise on the interfaces among the boxes.

The Security WG has invested a lot of time and effort defining "tunnel
mode", and its good to see that this can be leveraged for iSCSI.

> 
> I'm definitely not ruling out such gateways, but I want to make
> sure everyone understands that there will probably be interactions
> between such gateways and iSCSI in the area of naming - we
> are going to have to say something about how IPSec's notion
> of identities (e.g., X.509 certificates, and in the SAD/SPD) match
> up with iSCSI's notions (i.e., initiator and target names).

ISAKMP has an optional field for identification, defined in section 3.8 of
RFC 2408.  IKE uses this to identify the initiator and responder.  Here is
the text from RFC 2409:

     IDx is the identification payload for "x".  x can be: "ii" or "ir"
     for the ISAKMP initiator and responder respectively during phase
     one negotiation; or "ui" or "ur" for the user initiator and
     responder respectively during phase two.  The ID payload format for
     the Internet DOI is defined in [Pip97].

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.

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

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.

Josh

> If the gateway is completely independent of the iSCSI system,
> it'll fall to some higher level of management software or possibly
> manual configuration to make sure that the gateway and the
> corresponding iSCSI system(s) are configured consistently.
> 
> > In Orlando the agreement was that authentication digests 
> can be left to
> > specialized protocols (IPsec  and TLS) and iSCSI
> > is not mandated to have them specified outside such a protocol. 
> 
> Good thing, as there are lots of ways to get authentication protocols
> and the related integrity digests subtly wrong.
> 
> > The issue you raised - can now be translated should we make 
> IPsec or TLS
> > mandatory to implement?
> 
> That is correct - we are headed in the direction of making at 
> least one of
> those two mandatory to implement.  Note that it will NOT be 
> acceptable to
> say "implement at least one of these" and let implementers 
> choose which
> one because then an implementation that chose IPSec will not 
> interoperate
> with one that chose TLS (which is a wrong answer).
> 
> --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
> ---------------------------------------------------
>