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

[Alan DeKok <[e-mail]>]

On Mar 31, 2022, at 4:40 PM, Bernard Aboba <[e-mail]> 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.