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

[Bernard Aboba <[e-mail]>]

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.

Alan said:

"  Then the text needs more work, I think.  A naive reading of the text is
that the peer is NAKing type A, and asking for type B, which it doesn't
implement.  That doesn't make much sense.  And the NAK is also sent by EAP
servers, when the peer requests a type that the server does not respond."

[BA]  "not implemented locally" means "not implemented locally on the NAS".

The use case is: "a NAS suggests EAP-MD5 by default and the peer wants to
use a key-generating EAP method instead (like EAP-TLS or TTLS), so it sends
a Nak."

Suggestion:

"  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 that is
  implemented by the RADIUS server, and not by the NAS. In this case,
  the NAS SHOULD send an Access-Request encapsulating the received
  EAP-Response/Nak."

[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."

On Thu, Mar 31, 2022 at 7:59 AM Alan DeKok <[e-mail]>
wrote:

> On Mar 31, 2022, at 10:29 AM, Bernard Aboba <[e-mail]>
> wrote:
> >
> >  I am CC'ing the RADEXT WG mailing list, since the errata relates to a
> widely implemented RADIUS specification.
> >
> > Errata 6154:
> >
> > While Alan is correct that a RADIUS attribute with no data is not
> permitted by RFC 2865, and RFC 3579 is ambiguous about the length, I am
> concerned about the potential backward compatibility impact of this
> change.  In practice, is the EAP-Start being sent with a length of 2 or 3?
> Suggesting it be sent with a length of 3 is fine, but I'd suggest adding
> language stating that RADIUS servers should be aware of existing practice
> (e.g. be able to deal with a length of 2 if it is received).  We want to be
> careful not to break existing RADIUS clients.
>
>   Existing practice is all over the place.  I agree that the text should
> be clear that the RADIUS server should accept whatever is sent.  But also
> state that sending EAP-Message of zero length is not allowed.
>
>   Perhaps the new text should say:
>
>    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.
>
>   However, it won't encode zero-length EAP-Message.  So if the server is
> asked to proxy zero-length EAP-Message attributes, that attribute will get
> silently dropped from the proxied packet.
>
>   Looking at the code, that encoding limit has been there since 2005.
> I've never heard anyone complaining about it.  So I think it's safe to say
> that there are few, if any, RADIUS clients which send EAP-Message with
> length==2.
>
> > Errata 6259:
> >
> > I believe the original text is correct here.  EAP method types 1-3
> (Identity, Notification, Nak) are typically implemented locally on the NAS,
> so that the device (e.g. an 802.11 access point) can handle these methods
> without interacting with the RADIUS server.  In some cases, an EAP Type of
> 4 (MD5-Challenge) was also implemented on the NAS (e.g. for 802.1X on
> Ethernet) and would be set as the default method.  If the peer did not wish
> to use the default method, it would need to send a NAK.
>
>   Then the text needs more work, I think.  A naive reading of the text is
> that the peer is NAKing type A, and asking for type B, which it doesn't
> implement.  That doesn't make much sense.  And the NAK is also sent by EAP
> servers, when the peer requests a type that the server does not respond.
>
>   The original text is:
>
>   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 that is
>   not implemented locally.  In this case, the NAS SHOULD send
>    Access-Request encapsulating the received EAP-Response/Nak.
>
>   It could be updated to:
>
> a) replace "locally" with explicit names
>
> b) add missing "an" to make the second sentence a bit more grammatical. :)
>
>   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 that is
>   implemented by the RADIUS server, and not by the NAS. In this case,
>   the NAS SHOULD send an Access-Request encapsulating the received
>   EAP-Response/Nak.
>
>   I hope that addresses all concerns.
>
>   Alan DeKok.
>
>
>