Subject: Re: [storm] iSCSI consolidated draft: Authentication consistency

From: "Black, David" <[email-masked]>
Date: Sat, 9 Mar 2013 21:47:19 -0500

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:[email-masked]]
> Sent: Wednesday, January 02, 2013 1:39 AM
> To: Black, David
> Cc: [email-masked]
> 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" <[email-masked]> 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
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > storm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/storm
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 18 Mar 2013 21:33:55 -0400

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)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Black, David
> Sent: Saturday, March 09, 2013 9:47 PM
> To: Julian Satran
> Cc: [email-masked]

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Fri, 29 Mar 2013 19:40:34 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Black, David
Sent: Monday, March 18, 2013 6:34 PM
To: Black, David; Julian Satran
Cc: [email-masked]
Subject: Re: [storm] iSCSI consolidated draft: Authentication consistency

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,

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Black, David
> identities was to allow (re)use of identities already in 
> authentication systems.
> 
> Thanks,
> --David
> 
> 
> > 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.
> > > authentication.  I want to summarize them for discussion before 
> > > the effort is invested in writing detailed text.
> > >
> > > 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
> > > 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
> > > Proposal: The draft needs to say something - that something might 
> > > be to
> say
> > > 	- 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.
> > > 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:
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 South 
> > > St., Hopkinton, MA  01748