eap Mailing List: RE: Question on EAP statemachine

[Pasi.Eronen (Pasi.Eronen]

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