Subject: [eap] Compound Authentication Draft

From: [email-masked] (Puthenkulam, Jose P)
Date: Fri, 28 Mar 2003 17:12:30 -0800

Hi Joe,

Some more comments. Again keeping relevant parts only...

> > 
> > > > > 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.
> > 
> > Looks like I'm not comprehending the attack you describe. So 
> > here's an attempt to clarify... Tell me if your case is as follows:
> > 
> > So A wants some service from B we call S1 and it uses 
> > identity IA1 for it. The MS-CHAPv2 credentials used were 
> > intended to get access for this service S1 from B. So this 
> > was in context of PEAP session BA (B authenticated by A).
> > 
> [Joe]  So far so good
> 
> > Now C offers service S2 to A and B and the identities for 
> > access are IA2 and IB2 and MSCHAPv2 is the method used. So B 
> > after setting up PEAP session with A now has a separate PEAP 
> > session CB with B (C authenticated by B). 
> > 
> [Joe] The identity for A is the same IA1. Service is not offered to B
> and IB2 does not exist

[JP] So A is sending IA1 to B for access to S1 or S2?

> 
> > So when A authenticates with B for S1 it uses identity IA1. 
> 
> [Joe] OK
> 
> > If A authenticates with C for S2 it would use IA2 right? 
> 
> [Joe] It uses IA1 (same identity for both services) 
> 
> How would A ever disclose IA2 to B when B doesn't provide the 
> service S2?  
> 
> [Joe] Same identity both services.  
> 
> > I agree the attack you describe is possible if A uses 
> > identity IA2 to access service from C but thru B. Why would 
> > this happen? Can you give an example.
> > 
> [Joe] This is not the case I was thinking about, but in this case it
> would have had to use the incorrect credential based on the 
> identity B.
> This could be done thrugh incorrect configuration or perhaps 
> some clever
> manipulation by B to make things appear to be C (except for the server
> side auth).   

[JP] So A attempts to get service S1 from B, but knowing that A has service
S2 from C is pretending to provide A with service S1, but obtains S2 from C
instead with A's identity IA1. Now can you explain how this clever
manipulation is done? 

Also, so far this attack is being performed by a trusted server entity,
which I'm not convinced is solvable? Our draft talks about attacks performed
by un-authenticated NASes. 

> 
> > Is your case when A has the same identity IA1=IA2 for both 
> > services S1 and S2?  
> > 
> [Joe]  Yes.   
> 

best regards,
jose

---

From: [email-masked] (Joseph Salowey)
Date: Fri, 28 Mar 2003 17:34:58 -0800

> -----Original Message-----
> From: Puthenkulam, Jose P [mailto:[email-masked]] 
> Sent: Friday, March 28, 2003 5:13 PM
> To: 'Joseph Salowey'; [email-masked]
> Subject: RE: [eap] Compound Authentication Draft
> 
> 
> Hi Joe,
> 
> > > > > > Take an example using MSCHAPv2 inside of a 
> mechanism such as 
> > > > > > PEAP.
> 

[Joe] No A is sending IA1 to be for access to service S1.  B uses the
authentication to get access to S2 as A1.

> identity 
> > B. This could be done thrugh incorrect configuration or perhaps
> > some clever
> [JP] So A attempts to get service S1 from B, but knowing that 
> A has service S2 from C is pretending to provide A with 
> service S1, but obtains S2 from C instead with A's identity 
> IA1. Now can you explain how this clever manipulation is done? 
> 

[Joe] Yes,  There is a server side authenticated tunnel between A and B
and B and C.  B may actually provide service S1 to A, this is
irrelevant. When A sends his authentication data to B, B turns around
and sends it to C.  When C sends authentication data to B then B turns
around and sends it to A.  This contiues until the authentication
between A and C is completed.  C now thinks there is a secure connection
with A, but in reality it is a secure connection to B.  

> Also, so far this attack is being performed by a trusted 
> server entity, which I'm not convinced is solvable? Our draft 
> talks about attacks performed by un-authenticated NASes. 
> 

[Joe] I'm not sure what you mean.  This problem is based on the same
principal as the compound authentication problem.  If A uses different
credentials with B and C there is no problem.  Also If there is binding
between the inner and outer methods then B can't send data and pretend
to be A.