On Mar 31, 2022, at 4:40 PM, Bernard Aboba <bernard.ab...@gmail.com> wrote: > > 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.
Thanks. > [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." That looks good to me, thanks. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
