RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007

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.

Report New Errata