> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Tuesday, October 30, 2012 12:37 PM > To: Jim Schaad > Cc: 'Alan DeKok'; 'Alper Yegin'; [email protected] > Subject: Re: [abfab] EAP Applicability: retransmissions > > >>>>> "Jim" == Jim Schaad <[email protected]> writes: > > Jim> I agree that an access reject from RADIUS is the correct way to > Jim> shut down. Who sends it and when? > > Alan implied that when the eap stack fails to produce an answer the RADIUS > server doesn't have anything else to do.
I think he was talking about the RADIUS server not having any EAP data to send back to the client. And that in that case the server SHOULD send a reject message back. I am looking at the case of the EAP client not having any data to send. The RADIUS server will not have an opportunity to send a reject message, but it will still have some state data for a while (as will the EAP server). Also the GSS-EAP acceptor will have state data that it keeps around because the session has not been shut down from either the RADIUS side or the initiator side. This means that there are three entities waiting for something to happen and nothing going on. Some of this could be fixed if the initiator closes the session in the case that it ignores the EAP packet on the grounds that there is a reliable transport and it knows that it is dead locked. This could force a shutdown of state back to the IdP from the acceptor, although I am not sure at this point what RADIUS message it would send back to spin down state. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
