|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: CHAP changes in Draft 20Draft 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
Home Last updated: Fri Jan 24 14:19:04 2003 12255 messages in chronological order |