Summary

  • Revision 18 of the RADEXT RadSec working-group draft changes the consequence of a failed Response Authenticator: discard the response, but keep the (D)TLS connection open. It also requires the connection to remain open for a response with no outstanding request. The draft is under IESG evaluation, not an approved RFC.
  • A client can time out a request and reuse its one-byte Identifier. If the server's old response arrives while the new request is outstanding, validation against the new Request Authenticator can fail. That race explains the new packet-level exception; it does not authorize accepting the old response or ignoring a genuine Message-Authenticator failure.

The decisive event may be a reply that arrived too late. A RADIUS client has given up waiting for one request and reused its Identifier for another. The earlier reply then reaches the client, which checks it against the newer request. A failed Response Authenticator follows even though the server's protected connection has not necessarily lost its identity. The packet must be rejected. The question is whether the entire connection should be torn down with it.

The 30 September revision of draft-ietf-radext-radiusdtls-bis answers no for this particular failure. In section 3.12, a RadSec client MUST discard a response whose Response Authenticator fails validation while keeping the connection open. It must do the same for a response that matches no outstanding request. In revision 17, a bad Response Authenticator was still in the connection-closing list; an unmatched response sat in a category where keeping or closing the connection was an implementation choice. The new appendix makes the Identifier-reuse race explicit. That is a substantive change in fault disposition, not a newly discovered transport or a claim that failed authentication is acceptable.

RFC 6613 supplies the older baseline. Its RADIUS/TCP rule required closure for a failed Response Authenticator and permitted either outcome for an unmatched response. A one-octet Identifier provides only 256 values per connection. Under load, an Identifier may become available again soon after a request times out. The new draft's example has the server answer the old request just before it receives the new one. The client has already discarded the old request, so validation against the replacement request fails. In a proxy fabric, differing timeout settings can also deliver a response after the client has ceased to expect it.

Neither explanation establishes that a specific production network has suffered this race.

The exception has a hard edge. The response is not delivered to the application as a successful answer. If its Response Authenticator fails, the draft says checking that discarded packet's Message-Authenticator is irrelevant. That is not a waiver for all Message-Authenticator failures: where a response has a valid Request Authenticator but its Message-Authenticator fails, the connection-closing rule remains. An unacceptable client likewise obliges the server to terminate the (D)TLS connection immediately, and a RADIUS/TLS server must close TCP as well.

The draft distinguishes a stale packet from a peer whose authority genuinely cannot be accepted.

For operators, the useful evidence is not a single counter labelled “authentication failure.” A test of the proposed behavior should record whether the response matched an outstanding request, which authenticator check was reached, whether the response was discarded, whether the connection stayed up, and whether any subsequent valid exchange succeeded. Logging discarded packets should itself be rate-limited, as the draft advises when a connection stays open. This classification is editorial operating guidance, not a new IETF telemetry format or a guarantee that a bad response is benign.

The document remains an active working-group Internet-Draft in IESG Evaluation::AD Followup, with Proposed Standard as its intended status. Its proposed obsoletion of RFC 6614 and RFC 7360 is conditional on approval. The news is narrower and more useful: one false packet verdict need not become a wider service interruption, but the packet still fails. Without preserving both halves of that sentence, “resilience” becomes an excuse to accept bad data, or “security” becomes an excuse to sever a good channel.

Sources