Subject: [eap] Compound Authentication Draft

From: [email-masked] (Puthenkulam, Jose P)
Date: Fri, 28 Mar 2003 11:28:44 -0800

Hi Joe,

Thanks for your scenario. Some comments below

> -----Original Message-----
> From: Joseph Salowey [mailto:[email-masked]] 
> Sent: Monday, March 24, 2003 12:27 PM
> To: [email-masked]
> Subject: [eap] Compound Authentication Draft
> 
> 
> 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.

Surely, can consider if the attack is really a genuine worthwhile case.
> 
> 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.

So B is the final authentication server. Also PEAP stage 1 helped A validate
B's identity and expects B to be a good trustworthy server.
  
> 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.

So here B the final authentication server that A trusted, proxies A's
authentication to another server C. So basically B has violated A's trust in
totality. Now what did A trust B for? The PEAP stage 1 between A and B seems
to have no meaning? I guess all bets are off at this point. 

> 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.

But this doesn't help even if B has one single identity on ten identities
which you are trying to prove, because B is inherently not trust worthy.
What prevents B from shipping the shared secret to C?  

> 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.

Are you suggesting PEAP stage 1 certificate validation is not meaningful? 

> 
> 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. 

What you are challenging here is basic trust for transactions? Its an
unsolvable problem except through detection and appropriate post-event
action.

>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.

In your description B actually was trusted by A not to impersonate it. 

> 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.

Cryptographic binding is not a cure-all. Fundamentally it is just trying to
provide mutual authenitcation where it didn't exist. But if entities violate
trust then it won't help anways.

best regards,
jose

---

From: [email-masked] (Joseph Salowey)
Date: Fri, 28 Mar 2003 12:32:00 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Puthenkulam, Jose P
> Sent: Friday, March 28, 2003 11:29 AM
> To: 'Joseph Salowey'; [email-masked]
> Subject: RE: [eap] Compound Authentication Draft
> 
> 
> Hi Joe,
> 
> > policy can be used to reduce the vulnerability and I think 
> it should 
> > be noted in the document.
> 
> So B is the final authentication server. Also PEAP stage 1 
> helped A validate B's identity and expects B to be a good 
> trustworthy server.
>   

[Joe] What does trustworthy mean? Just because I "trust" B for some
things does not mean that he should be able to impersonate me.  This is
all or nothing "trust" which is not so good.

> So here B the final authentication server that A trusted, 
> proxies A's authentication to another server C. So basically 
> B has violated A's trust in totality. Now what did A trust B 
> for? The PEAP stage 1 between A and B seems to have no 
> meaning? I guess all bets are off at this point. 
> 

[Joe] Here the problem is that if the inner protocol is not run inside
of PEAP then B could not send data to C as A.  A may trust B to do
somethings for him and not others.  For example A may want sotck quites
from B, probably he does not want B to impersonate him.  

> But this doesn't help even if B has one single identity on 
> ten identities which you are trying to prove, because B is 
> inherently not trust worthy. What prevents B from shipping 
> the shared secret to C?  
> 

[Joe] Again I am not sure what you mean by trustworthy.  B can be
trusted for some things, but he should not be able to impersonate A.  If
B has access to the shared secret then all bets are off, however it is
not required for B to have access to a shared secret.   B only needs to
have access to the authentication messages.  

> > In practice it may be difficult to verify that one identity 
> is or is 
> > not
> equivalent
[Joe]  Not at all.  I am saying it is not just sufficient to validate a
certificate.  You must make sure that the stage two credentials you use
inside the tunnel can only be used with B or you must accept the fact
that B can use to credentials to authenticate as you to another service
that uses the same credentials.  Note that in a AAA or public key models
the authenticating parties do not have access to shared secrets.  

> > 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
> What you are challenging here is basic trust for 
> transactions? Its an unsolvable problem except through 
> detection and appropriate post-event action.
> 

[Joe] No, again you must be careful with the word trust.  The basic
principal is that I trust B for somethings, but A really doesn't want
him to be able to athenticate to another party as A.  

> In your description B actually was trusted by A not to 

[Joe] No, B is "trusted" for certain services".  B should not be able to
impersonate A if a reasonable authentication mechanism is used. The
inner protocol by itself is not subject to impersonation by a man in the
middle, only when it is used in PEAP is it subject to this attack. 

> 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
> Cryptographic binding is not a cure-all. Fundamentally it is 
> just trying to provide mutual authenitcation where it didn't 
> exist. But if entities violate trust then it won't help anways.
> 

[Joe] Actually in this case it will. 

> best regards,
> jose
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>