Re: [storm] iSCSI consolidated draft: Authentication consistency

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

Julo,

As long as that's only a suggestion (MAY, nothing stronger), that's
fine w/me, although the original design rationale for the shorter
identities was to allow (re)use of identities already in authentication
systems.

Thanks,
--David


> -----Original Message-----
> From: Julian Satran [mailto:[e-mail]]
> Sent: Wednesday, January 02, 2013 1:39 AM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [storm] iSCSI consolidated draft: Authentication consistency
> Importance: High
> 
> 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
>