RFC Errata
RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007
Source of RFC: radext (sec)
Errata ID: 4476
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Wang
Date Reported: 2015-09-17
Rejected by: Kathleen Moriarty
Date Rejected: 2015-09-22
Section Section 2 says:
Section 2.1.1. page 6: Any Access-Request packet that performs authorization checks, including Call Check, SHOULD contain a Message-Authenticator attribute. section 2.2.2 page 11: However, Access-Request packets not containing a Message- Authenticator attribute always affect the cache, even though they may be trivially forged. To avoid this issue, server implementations may be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded. Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue.
It should say:
Section 2.1.1. page 6: Any Access-Request packet that performs authorization checks, including Call Check, Must contain a Message-Authenticator attribute. section 2.2.2 page 11: However, Access-Request packets not containing a Message- Authenticator attribute always affect the cache, in some case such forgery is not trivial. To avoid this issue, server implementations MUST be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded. Client implementations MUST include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue.
Notes:
Message-Authenticator attribute defined in [RFC3579] is mandatory attribute for IEEE802.1x EAP User and optional attribute for other type of users. In RFC5080, the message-authenticator is used as an optional attribute. However in practice, Radius Implementation without Message-Authenticator attribute for Integrity check protection has become serious issue.
The attacker can take advantage of Access-Request packets not containing a Message-Authenticator attribute to perform authentication successfully.
Alternatively,the attacker can capture the packet and delete message-authenticatorattribute.
If the server do not check the message-authenticator attribute, the attacker can pass the authentication as well.
--VERIFIER NOTES--
This suggested errata would result in a normative change to the RFC, which requires consensus. The conversation has been moved to the RADext list to see if an update to the RFC is appropriate or not.