RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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 (ops)

Errata ID: 4623

Status: Held for Document Update
Type: Technical

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 (ops)

Errata ID: 4476

Status: Rejected
Type: Technical

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