On 24.11.2015 1.57, David Zych wrote: > Its description in the manual says "The RFCs say that IGNORE is the > correct behaviour, but..." -- do you know what RFC language in > particular this is referring to? I am most definitely not an expert and > might have overlooked something elsewhere, but I just noticed that > rfc3579#section-2.2 seems to offer helpful and relevant guidance, > recommending an Access-Reject for fatal errors or in the case of > non-fatal errors an Access-Challenge option (up to a limit of 5 invalid > EAP packets within a single session).
I did some investigation on this, and I think this is how PEAP fragmentation problem (request to send more fragments when there's nothing to send) was decided to be handled to match the EAP RFC. The PEAP drafts do not say anything about what to do in the case when more data is needed but none is left. RFC 3579 Section 4.1 mandates discarding requests in many cases when they are unexpected or contain incorrect values. Note that this is the only case when IGNORE is returned: the other PEAP errors cause REJECTs. In general there is always a response and the NAS is kept happy. > One more thought on this sub-topic: regardless of what RADIUS reply we > eventually send back (or don't), I think it would be very helpful for > Radiator to log EAP errors with at least INFO severity level so that > they'll be visible in a typical production environment. Currently I > only see them in DEBUG. Thanks for the suggestion. In addition to logging requests that hit EAPErrorReject there seem to be a couple of errors that are logged as DEBUG but could be raised to INFO. For example, the case when an EAP method that the client asks is not available might be one of these. > Looking forward to it! I figured it might take some time. :) So far I've taken a look at the specs and talked a bit about ignoring the PEAP fragment requests and how to handle duplicate EAP requests. When re-reading the spec (RFC 3579 Section 4.1), it says that the authenticator is responsible retransmitting the EAP request to the *peer* (aka client or supplicant). However, notice that the duplicate you are seeing is the EAP *response* to the request sent by Radiator. I'd say this means the NAS should resend the RADIUS request containing the original EAP response instead of sending a new RADIUS request with the resent EAP response. It does get hairy :( However, even if Radiator does not resend EAP requests, correctly rejecting the RADIUS requests should keep the RADIUS server up from the perspective of NAS while allowing the client to recover by doing reauthentication. Thanks, Heikki -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
