RFC Errata
Found 2 records.
Status: Held for Document Update (1)
RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007
Source of RFC: radext (sec)
Errata ID: 4623
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2016-02-22
Held for Document Update by: Benoit Claise
Date Held: 2016-05-18
Section 2.2.1 says:
For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded.
It should say:
For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. This retransmission behavior can be modified for Accounting-Request packets containing Acct-Status-Type of Interim-Update. A "retransmission" MAY include updated statistics, but will otherwise be treated as a retransmission of the original packet, with timers as described above. Such an updated packet MUST set Acct-Delay-Time (if present) to zero, and Event-Timestamp (if present) to the current time. These changes indicate that the statistics contained in the packet are new, and were not previously sent. When the NAS sends periodic Accounting-Request packets containing Acct-Status-Type of Interim-Update, the NAS SHOULD NOT continue to retransmit an old Accounting-Request packet when it is time to send a new one. The old packet SHOULD be discarded, and the new one sent in its place. The alternative is for a NAS to send a new Accounting-Request packet while it still is trying to send an old one. This situation could lead to the NAS sending multiple Accounting-Request packets simultaneously for the same session, leading to congestive collapse of the network.
Notes:
- if we're retransmitting an Accounting-Request packet, it should be acceptable
to update the statistics in it.
- i.e. there should not be a requirement that the content remain the same. The
Acct-Delay-Time attribute is changing, so why not other things, too?
- And MRT of zero for Accounting-Request packet SHOULD NOT mean that the
NAS starts a new retransmission timer every 5 minutes.
- e.g. if the server is down for 20 minutes, the NAS should have *one*
Accounting-Status packet in it's retransmit queue. Not 4.
Status: Rejected (1)
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.