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

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 Mar 2022 07:29:26 -0700

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.

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.

On Thu, Mar 31, 2022 at 2:08 AM Independent Submissions Editor (Eliot Lear)
<[email-masked]> wrote:

> Dear EMU working group,
>
> Alan Dekok has reported two errata[1,2] against RFC 3579.  RFC 3579 is
> classed an independent submission, and thus falls under the purview of
> the Independent Submissions Editor (ISE).  The ISE is inclined to verify
> both errata, and will do so in the next two months unless this group
> advises otherwise.
>
> Eliot Lear (ISE)
>
> [1] https://www.rfc-editor.org/errata/eid6154
> [2] https://www.rfc-editor.org/errata/eid6259
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 31 Mar 2022 10:59:33 -0400

On Mar 31, 2022, at 10:29 AM, Bernard Aboba <[email-masked]> 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.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 Mar 2022 13:40:36 -0700

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
  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 <[email-masked]>
wrote:

> > 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.
>
>   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:
> >
>   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:
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 31 Mar 2022 18:52:35 -0400

On Mar 31, 2022, at 4:40 PM, Bernard Aboba <[email-masked]> wrote:
>   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."
> 

  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: 
> 

  That looks good to me, thanks.

  Alan DeKok.

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Fri, 1 Apr 2022 06:48:54 +0200

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)

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Fri, 1 Apr 2022 07:07:31 +0200

Corrected URLs below:

On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote:
> https://www.rfc-editor.org/errata/eid6154
> https://www.rfc-editor.org/errata/eid6259
>
>>>    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 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:
>>>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 Mar 2022 22:16:53 -0700

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