[RADIATOR] duplicate EAP Responses

[Heikki Vatiainen]

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 <hvn at 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.