[storm] iSCSI consolidated draft: Authentication consistency

["Black, David" <[e-mail]>]

<WG Chair hat OFF>

This email is sent as the shepherd for the iSCSI consolidated draft.

Security review has turned up a couple of issues in iSCSI in-band
authentication.  I want to summarize them for discussion before the
effort is invested in writing detailed text.

I believe that good implementers will get these right, but some
security text appears to be needed.  This is not supposed to affect
existing implementations, so please speak up if something appears
potentially problematic.

(1) iSCSI name association with authenticated identity.  The iSCSI name
is for the initiator or target (e.g., iqn.*); the authenticated identity
is the identity used in the inband authentication protocol (e.g., CHAP
name).

This concern is about how the identity used for authentication aligns with
the iSCSI name for the initiator or target.  Abstractly, the concern is
that someone has to check that Bob is the authenticated identity for an iSCSI
initiator that's accessing Bob's storage, otherwise Alice can claim to be
Bob's initiator (iSCSI name) authenticate as herself (Alice as authentication
identity) and then freely access Bob's storage, which would be bad.

The draft doesn't say much about this, in large part because iSCSI names
are not exactly friendly to existing authentication infrastructure, and
the original design intent was to allow flexibility in identities used with
authentication infrastructure.

Proposal: The draft needs to say something - that something might be to say
that implementations SHOULD be managing authentication so that
impersonation is not possible across iSCSI Names.  The preferred approach
(SHOULD) would be to manage authentication material as triples:
	- iSCSI Name
	- Authentication identity for that name
	- Authentication credentials for that identity
In this case, the name-identity relationship SHOULD be checked in addition
to the authentication of the identity.  This check is simple if the identity
and name are the same, or the identity is algorithmically derived from the
name.

I can think of ways to bind credentials directly to an iSCSI Name, where
the identity is a bystander, although this is a particularly bad idea for
CHAP, as it will have rather unfortunate results when used with an external
server (e.g., RADIUS) that gets the authentication identity, but not the
iSCSI name, making this a "SHOULD NOT" requirement with a warning about
external authentication servers that don't see the iSCSI Names.

(2) Authentication consistency for multi-connection sessions.

When an iSCSI session has multiple connections, either concurrently, or
sequentially (e.g., TCP connection fails, new connection created to recover
the session), it's important that the same initiator be involved in all
the connections, *and* that the initiator authenticate as itself every
time.  There are several pieces to this:
- Authentication SHOULD be consistently used across a session. It's
	not a good idea to mix authenticated and unauthenticated connections
	in the same session.  Mixing authentication mechanisms is probably
	ok, if someone wants to do that, so it may not need to be mentioned.
- The authentication of the iSCSI Name SHOULD be consistent across a session,
	preferably by using the same authentication identity.  In the end,
	it's the iSCSI Name that matters, and the same authentication
	identity (see "triples" above) is the simplest way to get there.


Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------