Re: [storm] iSCSI consolidated draft: Authentication consistency

[Julian Satran <[e-mail]>]

WRT 1 - I always thought that the iSCSI name is/will-become the authenticated identity and the "tiny bit-strings" used in some communities will become a thing of the past - or at best will serve as temporary identifiers (something like short addresses).  However if we want to accommodate them  we should suggest a way of deriving the authenticated identity from the name - e.g., a hash - that binds them for good. The target may/should verify that the authenticated identity used in the protocol is  correct.  Obviously that assumes that authentication identities are small string that can be "allocated" arbitrarily - i.e. have no purposeful structure.

Julo
On Jan 2, 2013, at 3:48 AM, "Black, David" <[e-mail]> wrote:

> <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]
> ----------------------------------------------------
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm