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 _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
