Subject: [eap] Compound Authentication Draft

From: [email-masked] (Puthenkulam, Jose P)
Date: Fri, 28 Mar 2003 18:14:31 -0800

At this point I think we maybe crossing into philosohical arguments...

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

When A did a PEAP stage 1 server authentication with B, that implied B would
meet certain expectations of A. So B does not seem to be meeting it. The
server certificate that B provided to A has some limited scope and meaning.
If B does not honor it, then what's the use of the tunnel between A and B? 

It is understandable that B can violate its trust with C, as C is not
authenticating B. But B cannot violate its trust with A. If it does, then
certificates, tunnels etc. are all useless.

best regards,
jose

---

From: [email-masked] (Joseph Salowey)
Date: Fri, 28 Mar 2003 18:59:59 -0800

[Joe]  Yes I think perhaps we are.  We should probably take this off
line.  I still think there is a problem, but it is either a
configuration problem or a problem with different tunnel endpoints on
the backend (which makes proper configuration impossible).  A few
comments below that should clarify.  I disagree with the assertion that
this is a "trust" problem.

> -----Original Message-----
> From: Puthenkulam, Jose P [mailto:[email-masked]] 
> Sent: Friday, March 28, 2003 6:15 PM
> To: 'Joseph Salowey'; Puthenkulam, Jose P; [email-masked]
> Subject: RE: [eap] Compound Authentication Draft
> 
> 

> meet certain expectations of A. So B does not seem to be 
> meeting it. 

[Joe] Not necessarily.  B should not be able to authenticate to someone
else as A.   
This problem comes from one of the following:

1. A is unable to determine that it should not use a particular
credential with B or A cannot validate that the server identity
authenticated in the inner mechanism (C) is not the same as B during the
authentication.  This is a configuration problem (perhaps an inner
protocol problem as well).  

2. In another case B and C are referring to the same back end
authentication service (R) and the tunnel is expected to be terminated
on B or C.  This is perhaps more of a realistic problem.  In this case A
cannot match the inner mechanism authentication (R) with the tunnel
authentication (B or C).  It is possible for B and C to be in two
different security domains and R to be a third domain (like roaming
case).  B can then impersonate A to C. Now the problem here is the
reverse of the case you have described.  It results from a difference of
tunnel endpoints on the backed end.  This sort of thing is already
discouraged and known to be a problem.

The
> If B does not honor it, then what's the use of the tunnel 
[Joe] I disgree. If B can authenticate as A to another party there is a
problem with the system. 

> certificates, tunnels etc. are all useless.

[Joe] Again I don't think that trust is the issue.  An authentication
mechanism is not much good if it allows one party to impersonate another
without consent.  

Have a good weekend,

Joe