iSCSI SLP: Updated identity model

[Mark Bakke <mbakke@cisco.com>]

The iSCSI SLP template currently supports an access-list
attribute for each registered iSCSI URL.  This access-list
is a list of iSCSI initiator names that are to be allowed
access to the IP address and target in the URL.  Since
this attribute was added, we have added more authentication
methods to the iSCSI authentication MIB, including access
control by IP address and CHAP or SRP credentials, as well
as methods to keep track of multiple identities.

To support accurate discovery searches by initiators looking
for appropriate targets, I'd like to propose the following
modifications to the current SLP template:

1. Rename access-list to auth-name, to reflect that
   this is really a list of names that can access the target.

2. Add an auth-addr attribute, which takes a list of
   IP addresses of hosts allowed to access the target.

3. Add an auth-cred attribute, which lists the CHAP and/or
   SRP usernames allowed to access the target (subject, of course,
   to the host providing the correct password which is not published
   via SLP).

4. Change the default value of auth-name from "iscsi"
   to "any", to be consistent with other list wildcards.

5. Add an optional, opaque "identity" string to the end
   of the URL, to allow the above attributes to be used
   in different combinations (I'll try to explain the
   reason for this better below; it's easier after the
   attributes have been properly described).


These attributes would work together with the same semantics
described in the authentication MIB:

1. An initiator, to access a target, must have:

   - an initiator name matching one name in the auth-name
   - an IP address matching one address in the auth-addr
   - a CHAP or SRP credential matching one user name in the
     auth-cred.

2. If auth-name contains the value "any", the initiator
   name requirement is ignored.

3. If the auth-addr contains the value "any", the IP
   address requirement is ignored.

4. If the auth-cred contains the value "any", the CHAP/SRP
   requirement is ignored.


So the new template would include:

auth-name = string M X
# A list of iSCSI Initiator Names that can access this target.
# Normal iSCSI names will be 80 characters or less; max length is 255.
# Normally, only one or a few values will be in the list.
# Using the equivalence search on this will evaluate to "true"
# if any one of the items in this list matches the query.
# If this list contains the default name "any", any initiator
# is allowed to access this target, provided it matches the
# other auth-xxx attributes.

auth-addr = string M X
# A list of initiator IP addresses (or host names) which will
# be allowed access to this target.  If this list contains the
# default name "any", any IP address is allowed access to this
# target, provided it matches the other auth-xxx attributes.

auth-cred = string M X
# A list of credentials which will be allowed access to the target
# (provided they can provide the correct password or other
# authenticator).  Entries in this list are of the form
# "method/identifier", where the currently defined methods are
# "chap" and "srp", both of which take usernames as their identifiers.


These attributes are use by an initiator when doing SLP discovery,
so that only appropriate targets are found.

In the following example, suppose that the initiator has the initiator
name "iqn.com.mydisk:host47", IP addresses 10.1.1.47 and 10.1.2.47,
and can use both a CHAP user name of "foo" and an SRP user name
of "my-user-name".  This initiator needs to locate targets that
will accept its identity.

Example:

  Service: service:iscsi:target
  Scope:   initiator-scope
  Query:   &(|(auth-name=iqn.com.mydisk:host47)(auth-name=any)
             |(auth-addr=10.1.1.47)(auth-addr=10.1.2.47)(auth-addr=any)
             |(auth-cred=chap/foo)(auth-cred=srp/my-user-name)(auth-cred=any))

Note that it's possible for the initiator to have multiple identities
that are acceptable to the target, so multiple URLs for the same
target and address may be returned.  It is up to the iSCSI initiator
as the user of SLP sort this out.

Also note that if an initiator does not include all three auth-
attributes in its query, it is very likely to receive URLs to
which it is not allowed access.  It must be prepared to handle
the fact that it will not be able to log in to these.  A well-
behaved iSCSI initiator must search using all three attributes.



Now, back to that opaque identity thing.

Basically, all of the above attributes can be used as described
in the authentication MIB to say things like:

  auth-name=iqn.com.mydisk:host1, iqn.com.mydisk:host2
  auth-addr=10.1.1.1-10.1.1.254, 10.2.1.1
  auth-cred=chap/user42

This translates to "if the initiator name is iqn.com.mydisk:host1
or iqn.com.mydisk.host2 and the IP address is in the range 10.1.1.1
to 10.1.1.254 or is 10.2.1.1, and the CHAP user name is user42,
the initiator can access the target."

This is reasonably powerful by itself.  However, it can't also
express that the target can also be accessed by an initiator
that provides SRP user name "srp-name1" from any initiator name
or IP address.  To do that requires an additional set of
attributes:

  auth-name=any
  auth-addr=any
  auth-cred=srp/srp-name1

Obviously, we can't combine these two lists of attributes in
the same SLP registration for the target.  This means we have
to have two registrations; one for each of the above identities.
Since we can't register the same URL twice (remember the URL
contains the IP address, TCP port, and iSCSI target name), we
have to have a different URL for each one.  Since the basic
URL information is the same, we need to add something to make
each one unique.

The simplest way to do this is the extent the URL, adding
an opaque identifier (selected by the target that produces
the registration, and ignored by the initiator), for each
address-target-identity tuple.  Since the "/" character is
allowed in the SLP URL but not in the iSCSI target name, we
can use it as a separator.  Here's the new URL format:

template-url-syntax=
  url-path   =  ipaddr [ : tcpport ] / iscsi-name [ / identity ]
  ipaddr     =  DNS host name or ip address
  tcpport    =  decimal tcp port number
  iscsi-name =  iSCSI target name
  identity   =  optional initiator identity allowed to access target
  ; The iscsi-name part of the URL is required and must be the iSCSI
  ; name of the target being registered.
  ; A device representing multiple targets must individually
  ; register each target/address combination with SLP.
  ;
  ; Example:
  ;   service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678

Here are some examples using the above target, and the previously-
described identies:

Registration #1:

  service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678/1
  auth-name=iqn.com.mydisk:host1, iqn.com.mydisk:host2
  auth-addr=10.1.1.1-10.1.1.254, 10.2.1.1
  auth-cred=chap/user42

Registration #2:
  service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678/1
  auth-name=any
  auth-addr=any
  auth-cred=srp/srp-name1

This scheme has the added advantage of being completely consistent
with the iSCSI and Authentication MIBs.

Thoughts?

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054