Re: [storm] iSCSI consolidated draft: Authentication consistency

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

I've checked w/Julian offline - the upshot is roughly the following:

The identity binding has to be done, and it could be simplified by
algorithmically deriving the short identities (there are potential
problems when the shorter identities collide because two longer strings
hash to the same short one), but use or reuse of other authentication
identities is fine.

I think that's enough to set direction for the text that will be needed
for both issues in this thread.

Thanks,
--David (storm WG co-chair)

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Black, David
> Sent: Saturday, March 09, 2013 9:47 PM
> To: Julian Satran
> Cc: [e-mail]
> Subject: Re: [storm] iSCSI consolidated draft: Authentication consistency
> 
> 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
> >
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm