RFC Errata
Found 2 records.
Status: Reported (2)
RFC 3579, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", September 2003
Source of RFC: INDEPENDENT
Errata ID: 6154
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2020-05-01
Edited by: Adrian Farrel
Date Edited: 2020-07-01
Section 2.1 says:
EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data).
It 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.
Notes:
RFC 2865 Section 5 says that empty attributes must be omitted:
text 1-253 octets containing UTF-8 encoded 10646 [7]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
Section 3.1 of RFC 3579 also says that the EAP-Message attribute cannot be sent with length 2:
...
Type
79 for EAP-Message
Length
>= 3
...
In practice, few devices seem to send EAP-Message with Length 2.
Errata ID: 6259
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2020-08-20
Section 2.1 says:
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.
It should say:
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 locally.
Notes:
Remove the "not". The NAK should be requesting an authentication which is implemented, instead of preferring one which is NOT implemented.