[RADIATOR] duplicate EAP Responses

[David Zych]

On 11/30/2015 09:46 AM, Heikki Vatiainen wrote:
> 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.

I don't see anything like the mandate you describe in
https://tools.ietf.org/html/rfc3579#section-4.1

Perhaps you meant rfc3748?  I do see a couple of very specific discard 
situations in rfc3748#section-4.1, but I wouldn't describe it as "many 
cases" or an overall pattern; in fact I would argue that in general this 
section does *not* encourage discards ("Additional Request packets MUST 
be sent until a valid Response packet is received, an optional retry 
counter expires, or a lower layer failure indication is received.")

       An authenticator receiving a
       Response whose Identifier value does not match that of the
       currently outstanding Request MUST silently discard the Response.

applies to the NAS, not to RADIUS

       A message with the Length field set to a value larger
       than the number of received octets MUST be silently discarded.

very narrow case, not applicable in my scenario

       The Type field of a Response MUST either match that of the
       Request, or correspond to a legacy or Expanded Nak (see Section
       5.3) indicating that a Request Type is unacceptable to the peer.
       A peer MUST NOT send a Nak (legacy or expanded) in response to a
       Request, after an initial non-Nak Response has been sent.  An EAP
       server receiving a Response not meeting these requirements MUST
       silently discard it.

another very narrow case, not applicable in my scenario

Are those the excerpts you meant?

I can certainly see justification here for implementing a behavior of 
IGNORE, and an EAPErrorReject option to REJECT instead, for those two 
specific circumstances (i.e. wrong Length field or unacceptable Type 
field), but I don't think it's appropriate to generalize this behavior 
to "If an EAP error occurs" (the current language in section 5.21.72 of 
the Radiator manual).

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

I see a number of calls to $self->eap_error in the various EAP_* 
modules; AFAICT all of these will return IGNORE unless EAPErrorReject is 
configured.

Perhaps some of those are justified by the RFCs for their specific EAP 
types, I don't know, but at first glance they don't particularly seem to 
correspond to the particular circumstances above (i.e. wrong Length 
field or unacceptable Type field) for which discarding is mandated.

> 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

I assume you mean rfc3748

> 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 :(

a. RADIUS sends EAP Request 5 to NAS
b. NAS sends EAP Request 5 to peer
c. NAS retransmits EAP Request 5 to peer
d. peer sends first EAP Response 5
e. NAS sends first EAP Response 5 to RADIUS
f. peer sends second EAP Response 5
g. NAS sends second EAP Response 5 to RADIUS
h. RADIUS processes first EAP Response 5, replies with EAP Request 6
i. NAS sends EAP Request 6 to peer
j. RADIUS processes second EAP Response 5, ???

If steps c and d can happen at the same time (overlapping), then I think 
the rest of the sequence shows that it's entirely plausible for us to 
receive two separate RADIUS packets containing two separate instances of 
EAP Response 5.

You're suggesting that in step g the NAS should remember and resend the 
RADIUS packet from step e rather than making a new one, but that would 
considerably complicate the NAS's job, and 
https://tools.ietf.org/html/rfc3748#section-4.1 states:
"""
    Since
    the authenticator can retransmit before receiving a Response from the
    peer, the authenticator can receive multiple Responses, each with a
    matching Identifier.  Until a new Request is received by the
    authenticator, the Identifier value is not updated, so that the
    authenticator forwards Responses to the backend authentication
    server, one at a time.
"""

which I think makes it clear that RADIUS must be prepared to handle 
receiving another Response with the same Identifier (step j), although 
it doesn't specify how.

That's where https://tools.ietf.org/html/rfc3579#section-2.2 (note 
different RFC) comes in.  It doesn't address in so many words the 
specific case of receiving a second EAP Response with the same 
identifier, but if we're willing to categorize that case as a "non-fatal 
error" (which I think we should) then it suggests:

"""
    A RADIUS server determining that a non-fatal error has occurred MAY
    send an Access-Challenge to the NAS including EAP-Message
    attribute(s) as well as an Error-Cause attribute [RFC3576] with value
    202 (decimal), "Invalid EAP Packet (Ignored)".  The Access-Challenge
    SHOULD encapsulate within EAP-Message attribute(s) the most recently
    sent EAP-Request packet (including the same Identifier value).  On
    receiving such an Access-Challenge, a NAS implementing previous
    versions of this specification will decapsulate the EAP-Request and
    send it to the peer, which will retransmit the EAP-Response.

    A NAS compliant with this specification, on receiving an
    Access-Challenge with an Error-Cause attribute of value 202 (decimal)
    SHOULD discard the EAP-Response packet most recently transmitted to
    the RADIUS server and check whether additional EAP-Response packets
    have been received matching the current Identifier value.  If so, a
    new EAP-Response packet, if available, MUST be sent to the RADIUS
    server within an Access-Request, and the EAP-Message attribute(s)
    included within the Access-Challenge are silently discarded.  If no
    EAP-Response packet is available, then the EAP-Request encapsulated
    within the Access-Challenge is sent to the peer, and the
    retransmission timer is reset.
"""

which is the behavior I want, since it would successfully allow us to 
continue the EAP conversation:

j. RADIUS processes second EAP Response 5, replies with same identical 
EAP Request 6 from step h, plus Error-Cause = 202 Invalid EAP Packet 
(Ignored).
k. NAS sends EAP Request 6 to peer
l. peer sends EAP Response 6
m. NAS sends EAP Response 6 to RADIUS
n. RADIUS processes EAP Response 6, replies with EAP Request 7
...

Note: of course, we might now end up getting two copies of EAP Response 
6 (since the NAS has sent two copies of EAP Request 6 in steps i and k), 
though if we're lucky, NAS won't receive a second EAP Response 6 from 
peer until *after* receiving EAP Request 7 (step m), in which case NAS 
will discard the second Response 6 (non-matching identifier) and we're 
back to normal.  Even if we do have to deal with lock-step duplicates 
for the rest of the conversation, though, it still seems better to move 
forward and complete the authentication rather than having to start over 
from the very beginning.

Thanks,
David