IKE and iSCSI Authentication

[Black_David@emc.com]

Starting a new thread to try to roll up a number of related
issues from the User vs. Machine Authentication thread and
a few others.

-- Concept of "user".

This has been confusing due in part to lazy/sloppy use of
terminology by yours truly.  The term "machine"
has been used to refer to IKE authentication that has a single
identity associated with the network interface (i.e., IP address).
Finer grain authentication at a higher level has been referred
to as "user" authentication by analogy to remote access via
ppp/l2tp/ipsec, where a "machine" is authenticated by IKE
and a "user" is authenticated by ppp.  For iSCSI, we do have
a need to authenticate at a finer grain than one entity per
network interface, but "user" is a poor choice of word for
that.

-- Need for finer grain authentication than "machine"

As noted earlier, IKE starts up in response to the TCP SYN
packet being queued for transmission to set up a TCP connection
for iSCSI.  IKE intercepts that packet and completes its
its authentication and SA setup before allowing that packet
to continue on its way (over the SA that was just set up).
Hence IKE can't know what the iSCSI Initiator and
Target names are.  The usual result is that the IPsec
implementation behind a single network interface has a
single identity.  We went to great efforts in iSCSI to allow
multiple Initiators and Targets to share IP addresses, and
hence if there's any authentication associated with those
names, some other authentication mechanism is required that
occurs at a later stage and higher level than IKE (i.e.,
iSCSI inband authentication).

-- Need for authentication management

A careful reader of RFC 2401 will note the ability to inject
Name information into an IPsec SPD, and if one is careful about
having Initiators or Targets that one wants to distinguish be
associated with different OS user identities, this can be made
to work when IPsec is on the same system as the Initiator or
Target (it won't work with an outboard security gateway).  This
is not the best approach in many cases because it requires IKE
keying material (a certificate or pre-shared key) per identity
and these things are at best clumsy to administer.

Due to the complexities involved in administering even the best
IPsec systems, I expect to see deployments in which IPsec and IKE
are simply not used, or the authentication is very coarse.  One
could load the same pre-shared key or certificate into multiple
systems so that the IKE authentication only establishes that both
systems are members of some "ok" group, and then another mechanism
is used to determine who can actually access what - inband
authentication provides that mechanism.  The SRP mechanism is easy
to set up in situations where one does not want to run IKE, and
the other mechanisms are motivated by integration into existing
scalable centrally managed authentication systems - Kerberos,
CHAP (RADIUS), SPKM* (PKI).

-- That "tape" example

Obviously, I didn't explain this well, because nobody seems to
understand it.  Consider a SAN-accessible tape drive that is
sequentially shared by multiple hosts for backup.  To claim
that the operating systems own the tape drive misses the point
here - the multiple OSs will allow multiple backups from different
systems to the same drive to start at the same time, and the result
will be chaos.  One plausible alternative view is that the SAN
owns the tape drive, in which case authentication to the drive
can be used to control who can access it when, and the backup
application is the obvious entity to authenticate.  Some backup
applications have application-specific solutions to this problem
that work among cooperating entities (i.e., each instance of the backup
app knows that it has to ask permission) - requiring authentication
can keep out the uncooperative entities that won't bother asking
for permission.

-- iSCSI names and authentication identities

One could certainly use the same string as the iSCSI Initiator or
Target name and the userid used to do inband authentication, but
requiring that forces those strings into the existing authentication
systems that we'd like to live with.  The alternative of associating
userids from those systems with iSCSI authentication information
should be allowed to avoid forcing this.  John complains mightily
about the required translation, forgetting that there already has
to be a table indicating which Initiators are allowed to access
each Target; adding a userid column (or even a list) to this table
is a minor addition for the benefit of being able to reuse the
existing authentication infrastructure.  Pierre's suggestion of
issuing a certificate for every iSCSI initiator and target seems
to prevent reuse of existing certificates that were already issued
for some other reason, and that seems very wrong given the administrative
difficulties already posed by certificate issuance and management.
Mark's example of wanting to reuse his login ID on a local RADIUS
server (which is highly unlikely to meet the uniqueness requirements
of iSCSI Initiator and Target names) is a related situation in which
this forcing causes problems.

I'll stop here - I think I've caught most of the major points.
Comments?

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