RE: iSCSI: CHAP changes in Draft 20

[Black_David@emc.com]

Tony,

Detailed response below, but the two major points are:
- CHAP secrets are (intended to be) bound to identities in a
	fashion similar to passwords.
- Some of the design aspects that aren't making sense to you exist
	to deal with reuse of existing RADIUS servers and the like.

> Draft 20 section 8.2.1 "The same CHAP secret SHOULD NOT be configured for
> authentication of multiple initiators or multiple targets, as this enables
> any of them to impersonate any other one of them, and compromising one of
> them enables the attacker to impersonate any of them." ... "A single CHAP
> secret MAY be used for authentication of an individual initiator to
multiple
> targets. Likewise, a single CHAP secret MAY be used for authentication of
an
> individual target to multiple initiators."
> 
> I am having trouble understanding this paragraph.  It seems to be making
> recommendations that are opposite what I would expect.  Let me explain.
> 
> I take it that "authentication OF an initiator TO a target" is the process
> whereby a target confirms the initiator's credentials, which is performed
> during the first challenge/response exchange in a bi-directional
> authentication, or during the only challenge/response exchange in a
> single-directional authentication.   Similarly, "authentication OF a
target
> TO an initiator" is the process whereby an initiator confirms the target's
> credentials, which is performed during the second challenge/response
> exchange in a bi-directional authentication.

Ok.

> For authentication OF an initiator TO a target, the relevant text from the
> draft is "The same CHAP secret SHOULD NOT be configured for authentication
> of multiple initiators..." and "A single CHAP secret MAY be used for
> authentication of an individual initiator to multiple targets."  My
> interpretation of this is that:
> 
> 1) A given target should be configured with multiple CHAP secrets for the
> first stage of CHAP authentication so that a different secret  can be used
> for each initiator.
> 2) It is OK to configure multiple targets with the same set of CHAP
secrets
> for the first stage of CHAP authentication.  This would  enable any given
> initiator to use ONE secret to gain access to ALL targets for which it has
> authorization.

That's correct.

> These recommendations make no sense to me.  For 1), if the target accepts
> different secrets for different initiators, then ANY secret (out of the
set
> of accepted secrets) that is compromised will grant access to 
> the target.

But only to the resources to which that initiator has access to on that
target.  The secret is used to confirm the initiator's identity
and hence is associated with the initiator.  This is like someone's
password - if Alice knows Bob's password, Alice has access to Bob's
files, but not to Charlie's files as long as Charlie uses a different
password, and it is strongly recommended that different people use
different passwords for obvious reasons.

> (Note that a rogue initiator could impersonate any valid initiator it
> chooses, thereby selecting which secret the target uses for 
> authentication.)

And which resources the target will grant access to after the
authentication.

> This arguably weakens security, like accepting any one of a dozen
passwords
> for a login. IMHO, it would be more secure if a target used ONE secret to
> authenticate ALL initiators.

Nonsense, most large servers accept far more than a dozen passwords 
(one per account, far more than a dozen accounts).  Any reasonable
implementation will have a level of authorization behind the authentication
(e.g., LUN mapping or masking), but those tend to operate at the SCSI
level, and hence aren't specified in iSCSI.

> For 2), any ONE secret that is compromised enables a rogue initiator to
gain
> access to ALL targets configured to accept that secret.  Maybe that is not
a
> big worry for most people, but it certainly falls under the "...and
> compromising one of them enables the attacker to impersonate any of them"
> category which is seemingly the motivation for this whole paragraph.  But
> since it is a MAY and not a SHOULD, I won't complain any more about this
one
> if others think that it is not a big deal.

It's not a big deal.  Those who don't like it will configure N x M secrets
for N initiators to access M targets.  This gets unwieldy as N and M
scale up, though.

> For authentication OF a target TO an initiator, the relevant text from the
> draft is "The same CHAP secret SHOULD NOT be configured for authentication
> of [...] multiple targets" and "Likewise, a single CHAP secret MAY be used
> for authentication of an individual target to multiple initiators."  My
> interpretation of this is that:
> 
> 1) A given initiator should be configured with multiple CHAP secrets for
the
> second stage of CHAP authentication so that a different secret can be used
> for each target.
> 2) It is OK to configure multiple initiators with the same set of CHAP
> secrets for the second stage of CHAP authentication.  This would enable
any
> given target to use ONE secret to authenticate itself to ALL initiators.

That's correct.  The latter is similar to a website having ONE certificate
and private key to authenticate itself to ALL browsers.
 
> I think that 1), if implemented properly, makes some amount of sense.
> However, I am concerned about some implementation pitfalls that would make
> things less secure rather than more secure.  Specifically, I am concerned
> about the initiator letting the target choose which secret should be used
> for authentication rather than enforcing a specific secret to be used for
a
> specific target.  For example, the initiator implementation might use the
> CHAP_N value returned by the target to look up the proper secret to use
from
> a database of secrets.  An implementation like this would  suffer from a
> similar problem to the one I already mentioned for the other direction,
i.e.
> ONE compromised secret would enable a rogue target to impersonate ANY
target
> by allowing the rogue target to choose the compromised secret for
> authentication.  On the other hand, if the initiator enforces the use of a
> specific secret for authenticating a specific target, then this wouldn't
be
> a problem.

The latter is the intent.
 
> For 2), using the same CHAP secret on all initiators to confirm the
target's
> credentials would mean that if a rogue target compromises the secret, then
> it could impersonate the real target to ALL initiators.  Again, maybe that
> is not a big worry for most people, but it certainly falls under the
"...and
> compromising one of them enables the attacker to impersonate any of them"
> category which is seemingly the motivation for this whole  paragraph.  But
> since it is a MAY and not a SHOULD, I won't complain any more  about this
one
> either if others think that it is not a big deal.

Not a big deal - same comment as the other 2).

> All this brings up another point: what is the usefulness of CHAP_N during
> authentication?  As I have stated previously, allowing the party being
> authenticated to choose the secret to be used via CHAP_N (as in a PPP
login)
> makes things less secure.  What else could CHAP_N be used for?

It avoids inflicting iSCSI node names on things like RADIUS servers by
allowing existing identities known to such servers to be used ...

> One more thing: backing up a few paragraphs, another new addition in Draft
> 20 is the requirement for the secrets used in the two stages of
> bi-directional authentication to be different.  The wording in this
> paragraph implies that there can be only one secret configured for each
> direction, but as we all know by now, there may be multiple secrets
> configured.

Actually, we don't all know by now - the secret is bound to the identity,
see above.

> Also, the paragraph seems to imply that an implementation should check
> for these identical secrets by comparing the results of their hashed 
> CHAP responses rather than comparing the secrets directly.  Is this 
> intended, and if so, why?  After all, both sides should have access
> to the secrets for both directions in plaintext, so comparing them
> directly would be simpler.

That's not the case when one or both sides are using a RADIUS server
to check for validity of responses, as the entity receiving the response
does not know the secret needed to check the response - only the
RADIUS server and the sender know the secret.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------