Subject: [eap] tommorrow meeting

From: [email-masked] (John Vollbrecht)
Date: Tue, 13 May 2003 21:48:43 -0400

I am not able to join the conversation tomorrow.  I am having a medical 
problem this week - hopefully I will be better by Thursday and getting 
email.  I am pretty happy with 2284 and 2869 bis and with the stqte 
machine.  I have one major concern with both 2284bis and with the state 
machine - and that is that tunnelled methods will not be able to do 
sequences of methods.

Another concern is that the keying material information be taken from 2284 
and put in its own section, if possible.  I think keying is not always 
necessqry so putting it in its own section is important.

Sorry I can't join you tomorrow --

John

--On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > I think the problem is not with EAP, or AAA. The problem is with the EAP
> > lower layers, such as PPP and 802.1X. If they had a way to carry
> > authorization results, this problem wouldn't exist. In PANA, we carry
> > PANA result so this wouldn't be a problem.
>
> 802.1X considered, and rejected the carriage of authorization results. It
> was simpler to just recommend that the AAA result and EAP results agree.
>
> > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we
> > are discovering that (1) and (2) must agree too.
>
> This is not a "discovery" -- it is an implication of the proposed state
> machine.
>
> > So, when an authentication
> > method succeeds, but authorization fails, should the authenticatin
> > server go back and flip the authentication method to "failed" so that
> > the results are all aligned?
>
> If the authentication method supports an authorization failure error
> message, it can send that and there is no problem. Alternatively, the AAA
> server can send a Reject/EAP Failure. If this does not agree with the EAP
> method, which completed successfully, then the peer may silently discard
> the EAP Failure. Again there is no issue, as long as the NAS sends a lower
> layer failure indication such as an LCP-Terminate or 802.11
> Deauthenticate/Disassociate.
>
> Why doesn't this address the problem?
>
> > We could make (1) and (2) the same, and keep (3) independent. But the
> > problem is there is no equivalent of (3) for the last hop when PPP or
> > 802.1X is used.
>
> That seems needlessly complex -- given that our goal is to improve
> interoperability.
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>