eap Mailing List: RE: Issue 199: Full authenticator SM issue

[Pasi.Eronen (Pasi.Eronen]

Yoshihiro Ohba wrote:
> 
> In this case, the second RADIUS server will receive a Nak while 
> it is in "PICK_UP_METHOD" state.  There are two issues:
> 
> - Does RFC3579 allow "pickup" operation when the initial 
> EAP-Response is a Nak?  I think the document is a bit vague on 
> this (at least it does not seem to prohibit the case).

I don't think RFC3579 discusses the case where the EAP
conversation is "switched" from one RADIUS server to another
(it doesn't prohibit it either). It does allow the case
where the initial EAP-Response is a Nak:
 
  "Where the initial EAP-Request sent by the NAS is for an
  authentication Type (4 or greater), the peer MAY respond with
  a Nak indicating that it would prefer another authentication
  method that is not implemented locally.  In this case, the NAS
  SHOULD send Access-Request encapsulating the received
  EAP-Response/Nak."

> - If the above question is yes, how does the backend
> authenticator state machine work in this case?  I think there
> would need a state transition from "PICK_UP_METHOD" to "NAK"
> state to explicitly support the case.

There is already a transition from INITIALIZE to NAK that 
does this.

There is currently no text explicitly discussing how a backend
might pass EAP messages to another backend.  However, I'm not
sure that this is really needed (at least in the state machine
doc): in this case, the first backend really works as an ordinary 
RADIUS proxy (and not as EAP passthrough NAS).

So, I propose that we close issue 199 with no changes to the
document.

Best regards,
Pasi