Alan suggested: " 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." [BA] This suggested errata text looks good. Alan said: " 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." [BA] "not implemented locally" means "not implemented locally on the NAS". The use case is: "a NAS suggests EAP-MD5 by default and the peer wants to use a key-generating EAP method instead (like EAP-TLS or TTLS), so it sends a Nak." Suggestion: " 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." [BA] This text is better. The implicit assumption here is that the NAS is sending an EAP-Request with a locally implemented EAP type, without talking to the RADIUS server. Of course, the same thing could happen if the RADIUS server uses an inappropriate default type. So perhaps this might work: " 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. In this case, the NAS should send an Access-Request encapsulating the received EAP-Response/Nak. This allows a peer to suggest another EAP method where the NAS is configured to send a default EAP type (such as MD5-Challenge) which may not be appropriate." On Thu, Mar 31, 2022 at 7:59 AM Alan DeKok <al...@deployingradius.com> wrote: > 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
