iSCSI: CHAP changes in Draft 20

["Tony Battersby" <tonyb@cybernetics.com>]

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.

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.

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.
(Note that a rogue initiator could impersonate any valid initiator it
chooses, thereby selecting which secret the target uses for 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.

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.

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.

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.

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.

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?

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.  This paragraph does not take this fact into account.  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.

Anthony J. Battersby
Cybernetics