Re: [storm] iSCSI consolidated draft: Authentication consistency

["Mallikarjun Chadalapaka" <[e-mail]>]

Hi David, Julian, 

FYI, some existing iSCSI implementations allow a shared system-wide (target
or initiator) CHAP secret. This works fine in certain deployment scenarios.
I do not see anything in the suggested text that precludes such
implementations. So I am fine with the current direction.

Here's existing Section 9.2 (In-band Initiator-Target Authentication) text:

For some of the authentication methods, a key specifies the identity of the
iSCSI initiator or target for authentication purposes. The value associated
with that key MAY be different from the iSCSI name and SHOULD be
configurable. (CHAP_N, see Section 12.1.3 and SRP_U, see Section 12.1.2).

Updated text with the summary of this thread:

For some of the authentication methods, a key specifies the identity of the
iSCSI initiator or target for authentication purposes. The value associated
with that key MAY be different from the iSCSI Name and SHOULD be
configurable. (CHAP_N, see Section 12.1.3 and SRP_U, see Section 12.1.2).
For this reason, iSCSI implementations SHOULD manage authentication in a way
that impersonation across iSCSI Names is not possible. Specifically,
implementations SHOULD allow configuration of an authentication identity for
a Name if different, and authentication credentials for that identity.
During the login time, implementations SHOULD verify the Name-to-identity
relationship in addition to authenticating the identity through the
negotiated authentication method.   

Thanks.

Mallikarjun


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Black, David
Sent: Monday, March 18, 2013 6:34 PM
To: Black, David; Julian Satran
Cc: [e-mail]
Subject: Re: [storm] iSCSI consolidated draft: Authentication consistency

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

_______________________________________________
storm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/storm