I think the note in eid6259 is now superfluous. Can we remove it? On Thu, Mar 31, 2022 at 10:09 PM Independent Submissions Editor (Eliot Lear) <rfc-...@rfc-editor.org> wrote:
> Corrected URLs below: > > On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote: > > Ok. > > > > I have edited – but not yet verified – the two errata accordingly. > > Please see: > > > > https://www.rfc-editor.org/errata/eid6154 > > https://www.rfc-editor.org/errata/eid6259 > > > > Are there any further edits that are required? > > > > Eliot (ISE) > > > > On 01.04.22 00:52, Alan DeKok wrote: > >> 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 > > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
