Subject: [eap] Compound Authentication Draft

From: [email-masked] (Joseph Salowey)
Date: Mon, 24 Mar 2003 12:27:26 -0800

A similar problem exists with compound authentication even when a
mechanism is used only within secure tunnels.  A appropriate use of
policy can be used to reduce the vulnerability and I think it should be
noted in the document.

Take a mechanism such as MSCHAPv2 which is secure against a man it the
middle and generates session keys which can be used to protect
additional data and further prevent a man in the middle.  This method
can be used securely by itself.  

Take an example using MSCHAPv2 inside of a mechanism such as PEAP.
Party A can establish a secure connection to party B by establishing
PEAP and verifying B's identity.  B can then request that A authenticate
with MSCHAPv2.   A will perform MSCHAPv2 authentication with B.  B can
open up another PEAP session to C.  B can proxy the MSCHAPv2
authentication to C and authenticate as A.  B can now carry on a
conversation with C as if he were A.  This attack can be avoided if A
has an appropriate policy configuration or if A can detect that the
identity authenticated as B during PEAP is not equivalent to the
identity authenticated as B in the MSCHAPv2 conversation and abort the
authentication before it completes.  In practice it may be difficult to
verify that one identity is or is not equivalent because of different
identity formats used in different credential types.  

This is a result of a faulty trust relationship.  In a sense if B is a
malevolent entity A should not allow the connection since it should know
there is no way that B should not have access to the credentials used by
the inner method (MSCHAPv2 in this case).   This sort of determination
may be difficult in practice.  It also means that any entity that you
trust to participate with in an inner authentication mechanism you must
also trust to be able to impersonate you.  More investigation is needed
to see if this is really a problem (intuitively I think it is a problem,
but I haven't had a chance to think it through).    

A solution to this problem is for the client to have a policy that
limits which inner authentication methods and credentials can be used
based on the identity authenticated in the outer tunnel (it seems that
this should exist in implementations already).  The client mechanism may
also have a policy that aborts the authentication if it is determined
that the identity validated in the inner mechanism is not the same as
the identity validated in the outer mechanism (with some mechanism this
may be impossible as the server identity may not be known until the
authentication completes).  Cryptographic binding may also help in this
case.

Joe