eap Mailing List: Re: [Issue 248] Comments on EAP state machine v4

[John Vollbrecht (jrv]

looks good to me as well - John

--On Friday, July 16, 2004 12:22 PM -0400 Nick Petroni 
<npetroni [at] cs.umd.edu> wrote:

> Looks good to me. Thanks for all of the comments, suggestions, and text.
>
> Best,
> nick
>
> Nick L. Petroni, Jr.
> Graduate Student, Computer Science
> Maryland Information Systems Security Lab
> University of Maryland
> http://www.cs.umd.edu/~npetroni
>
> On Fri, 16 Jul 2004, Florent Bersani wrote:
>
> > Nick, all
> >
> > Here is some proposed text:
> >
> > Add to the definition of Policy.getNextMethod (section 5.4 page 20 of
> > the .pdf):
> > "Policy.getNextMethod MUST comply to RFC 3748 that forbids, in its
> > Section 2.1, the use of sequences of authentication methods within an
> > EAP conversation. Hence, if an authentication method has already been
> > executed within an EAP dialog, Policy.getNextMethod MUST NOT propose
> > another authentication method within the same EAP dialog"
> >
> > What do you think of it?
> >
> > Florent
> >
> > Nick Petroni wrote:
> >
> > > Florent and all,
> > >
> > > As Monday 7/19 is the cut-off for document submission, I would like
> > > to ask for help in resolving as much of the remaining issues as
> > > possible in the state machine document. Here is a list of necessary
> > > changes as I see them for Issue 248. Please let me know how these
> > > look in principle and contribute text if possible. I also will
> > > attempt to contribute text over the next couple of days.
> > >
> > > Thanks,
> > > nick
> > >
> > >
> > >
> > > Comment #9 - Technical
> > >  Request text amendments for policy functions to clarify that
> > >  multiple authentication methods are not expected or propose
> > >  alternate solution.
> > >
> > >
> > Florent Bersani wrote:
> >
> > > Comment #9 - Technical
> > >
> > > Apparently Figure 4 (EAP Standalone Authenticator State Machine)
> > > leaves the door open to a sequence of EAP authentication methods
> > > (which is explicitly forbidden by RFC 3748 section 2.1 "However, the
> > > peer and authenticator MUST utilize only one authentication method
> > > (Type 4 or greater) within an EAP conversation"). This behavior may be
> > > prevented thanks to Policy.getDecision or PolicygetNextMethod... but I
> > > do not find this is exactly a matter of policy and at least, this
> > > should be pointed out (that the policy MUST forbid this behavior).
> >
> >
>
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap