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

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
>