Re: [Emu] EAP Erratum 6154 on RFC 3579:

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-ise@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.aboba@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
> >
>