SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    iSCSI: CHAP changes in Draft 20



    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
    
    


Home

Last updated: Fri Jan 24 14:19:04 2003
12255 messages in chronological order