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. 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. On Thu, Mar 31, 2022 at 2:08 AM Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org> wrote: > Dear EMU working group, > > Alan Dekok has reported two errata[1,2] against RFC 3579. RFC 3579 is > classed an independent submission, and thus falls under the purview of > the Independent Submissions Editor (ISE). The ISE is inclined to verify > both errata, and will do so in the next two months unless this group > advises otherwise. > > Eliot Lear (ISE) > > [1] https://www.rfc-editor.org/errata/eid6154 > [2] https://www.rfc-editor.org/errata/eid6259 >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
