On Mar 31, 2022, at 10:29 AM, Bernard Aboba <bernard.ab...@gmail.com> wrote: > > I am CC'ing the RADEXT WG mailing list, since the errata relates to a widely > implemented RADIUS specification. > > Errata 6154: > > While Alan is correct that a RADIUS attribute with no data is not permitted > by RFC 2865, and RFC 3579 is ambiguous about the length, I am concerned about > the potential backward compatibility impact of this change. In practice, is > the EAP-Start being sent with a length of 2 or 3? Suggesting it be sent with > a length of 3 is fine, but I'd suggest adding language stating that RADIUS > servers should be aware of existing practice (e.g. be able to deal with a > length of 2 if it is received). We want to be careful not to break existing > RADIUS clients.
Existing practice is all over the place. I agree that the text should be clear that the RADIUS server should accept whatever is sent. But also state that sending EAP-Message of zero length is not allowed. Perhaps the new text should say: EAP-Start is indicated by sending an EAP-Message attribute with a length of 3. The single byte of data SHOULD be set to zero on transmission and MUST be ignored on receipt. RADIUS clients MUST NOT send EAP-Message attributes of length 2, as attributes with no value are not permitted in RADIUS. However, for historical reasons and for compatibility with existing practice, RADIUS servers MUST accept EAP-Messages of length 2, and treat them as EAP-Start. Just checking the source I have locally, the server accepts zero-length EAP-Message (or any other text/string attribute, for that matter). So that's fine. However, it won't encode zero-length EAP-Message. So if the server is asked to proxy zero-length EAP-Message attributes, that attribute will get silently dropped from the proxied packet. Looking at the code, that encoding limit has been there since 2005. I've never heard anyone complaining about it. So I think it's safe to say that there are few, if any, RADIUS clients which send EAP-Message with length==2. > Errata 6259: > > I believe the original text is correct here. EAP method types 1-3 (Identity, > Notification, Nak) are typically implemented locally on the NAS, so that the > device (e.g. an 802.11 access point) can handle these methods without > interacting with the RADIUS server. In some cases, an EAP Type of 4 > (MD5-Challenge) was also implemented on the NAS (e.g. for 802.1X on Ethernet) > and would be set as the default method. If the peer did not wish to use the > default method, it would need to send a NAK. Then the text needs more work, I think. A naive reading of the text is that the peer is NAKing type A, and asking for type B, which it doesn't implement. That doesn't make much sense. And the NAK is also sent by EAP servers, when the peer requests a type that the server does not respond. The original text is: Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is not implemented locally. In this case, the NAS SHOULD send Access-Request encapsulating the received EAP-Response/Nak. It could be updated to: a) replace "locally" with explicit names b) add missing "an" to make the second sentence a bit more grammatical. :) Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is implemented by the RADIUS server, and not by the NAS. In this case, the NAS SHOULD send an Access-Request encapsulating the received EAP-Response/Nak. I hope that addresses all concerns. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
