eap Mailing List: RE: Question on EAP statemachine

[Mahesh Kelkar (mkelkar]

Pasi,

Great!! thanks. How do you define a single EAP
conversation? I mean when would you say that EAP
converation is started? and when would you say that EAP
conversation is ended?

Thanks
Mahesh

--- Pasi.Eronen [at] nokia.com wrote:

> Mahesh,
> 
> Using multiple authentication methods in a single
> EAP conversation is explicitly prohibited by RFC 3748.
> 
> So if multiple authentication methods are used, they 
> have to be in separate EAP conversations (like in PANA),
> and the lower layer has to be aware of these. (Unless
> a "tunneled" method is used; but that's a single 
> authentication method from RFC 3748 point of view.)
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Mahesh Kelkar [mailto:mkelkar [at] rocketmail.com]
> > Sent: Wednesday, June 29, 2005 6:38 PM
> > To: Eronen Pasi (Nokia-NRC/Helsinki); eap [at] frascone.com
> > Subject: RE: Question on EAP statemachine
> > 
> > 
> > Pasi,
> > 
> > L2tp is unawre of EAP and merely forwards the PPP
> frames
> > from LAC to LNS. LAC & LNS are the terms used for the
> APs
> > in the context of L2tp protocol. 
> > 
> > If for some reason, we MUST not allow the back to back
> EAP
> > protocol/method negotiations, then following discussion
> it
> > out of question. I am just wanted to find out if its
> > conceivable.
> > 
> > In the peer statemachine on page 8 of the pdf version
> of
> > the draft: 
> > 
> > on the receipt of the EAP request there are several
> > condition checks. The couple of conditions are as
> follows
> > 
> > Condition 1:-
> > rxReq &&
> > (reqId != lastId) &&
> > (selectedMethod == None) &&
> > (reqMethod != IDENTITY) &&
> > (reqMethod != NOTIFICATION)
> > 
> > Condition 2:-
> > rxReq &&
> > (reqId != lastId) &&
> > (selectedMethod == None) &&
> > (reqMethod == IDENTITY)
> > 
> > These 2 conditions prohibit the back to back
> negotiation of
> > the EAP protocol/auth methods. If we want to allow the
> back
> > to back negotiations then perhaps we should remove the
> > (Selected == None) checks from these two conditions or
> add
> > two more conditions as follows
> > 
> > Condition 1A:-
> > rxReq &&
> > (reqId != lastId) &&
> > (selectedMethod != None) &&
> > (methodState == Done) &&
> > (reqMethod != IDENTITY) &&
> > (reqMethod != NOTIFICATION) &&
> > 
> > Condition 1A allows the EAP negotiation (by
> allocMethod) on
> > the receipt of EAP request/auth method (this auth
> method
> > could be different) only if current negotiation is
> > finished.
> > 
> > Condition 2A:-
> > rxReq &&
> > (reqId != lastId) &&
> > (selectedMethod != None) &&
> > (methodState == Done) &&
> > (reqMethod == IDENTITY)
> > 
> > Condition 2A is optional because it could help us avoid
> an
> > extra user interaction. But this condition would allow
> the
> > peer to respond to the EAP request/Identity received
> after
> > the conclusion of the  earlier EAP negitiation.
> > 
> > Any successive authentication failure MUST result into
> a
> > failure.
> > 
> > During the back to back EAP protocol/method negotiation
> > eapRestart & potEnabled flags remain UP. i.e the intial
> > negotiation was intiated by the lower layer. But lower
> > layer should be unaware of the any successive
> negotiations.
> > 
> > 
> > Thanks
> > Mahesh
> 


+++++++++++++++++++++++++++++
 M a h e s h  V  K e l k a r


                
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com