Ok.
I have edited – but not yet verified – the two errata accordingly.
Please see:
https://www.rfc-editor.org/verify_errata_select.php?eid=6154
https://www.rfc-editor.org/verify_errata_select.php?eid=6259
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
