RADIUS Authentication Client MIB
obsoleted by
- rfc-4668 — RADIUS Authentication Client MIB for IPv6
Extracted elements (21)
Packet accounting relationships are embedded as MIB comments: TotalIncomingPackets = Accepts + Rejects + Challenges + UnknownTypes, and successfully received = TotalIncoming - Malformed - BadAuthenticators - UnknownTypes - Dropped, enabling NMS consistency checks.
The MIB is defined in SMIv2 but can be translated to SMIv1; the translation is semantically equivalent except that Counter64 objects would be omitted and machine-readable SMIv2 annotations become textual descriptions — this loss is not considered a semantic change.
A RADIUS proxy acting as both client and server is expected to implement both the RADIUS Authentication Client MIB (RFC 2618) and the RADIUS Authentication Server MIB simultaneously.
Implementations compliant with this MIB MUST support all objects in radiusAuthClientMIBGroup, as declared in the MODULE-COMPLIANCE statement radiusAuthClientMIBCompliance.
radiusAuthClientAccessRequests (Counter32) counts Access-Request packets sent, excluding retransmissions; radiusAuthClientAccessRetransmissions (Counter32) counts retransmitted Access-Requests separately.
radiusAuthClientBadAuthenticators (Counter32) counts Access-Response packets containing invalid authenticators or Signature attributes, providing a distinct error class from malformed packets.
radiusAuthClientIdentifier (SnmpAdminString, read-only) holds the NAS-Identifier of the RADIUS authentication client; explicitly noted as not necessarily the same as sysName.
radiusAuthClientInvalidServerAddresses (Counter32, read-only) counts RADIUS Access-Response packets received from unknown addresses, indicating possible misconfiguration or spoofing.
radiusAuthClientMalformedAccessResponses (Counter32) counts responses with invalid length; bad authenticators, invalid Signature attributes, and unknown types are explicitly excluded from this counter.
radiusAuthClientMIB is the MODULE-IDENTITY for entities implementing the client side of the RADIUS authentication protocol, assigned OID { radiusAuthentication 2 }.
radiusAuthClientPendingRequests (Gauge32, read-only) is a current-value gauge incremented on Access-Request send and decremented on Access-Accept, Access-Reject, Access-Challenge, timeout, or retransmission receipt.
radiusAuthClientRoundTripTime (TimeTicks, read-only) records the interval in hundredths of a second between the most recent Access-Reply/Access-Challenge and the Access-Request that matched it.
radiusAuthClientTimeouts (Counter32) counts authentication timeouts per server; a retry to the same server increments both this counter and retransmissions; a send to a different server increments both this counter and access requests.
radiusAuthClientUnknownTypes (Counter32) and radiusAuthClientPacketsDropped (Counter32) count packets received on the authentication port that were unrecognized or dropped for other reasons, respectively.
radiusAuthServerAddress (IpAddress, read-only) and radiusAuthClientServerPortNumber (Integer32 0..65535, read-only) identify the server IP and the UDP port the client uses for requests to that server.
radiusAuthServerTable is a conceptual table (indexed by radiusAuthServerIndex) containing one row per RADIUS authentication server with which the client shares a secret; each row has 15 columns.
Three counters track server responses: radiusAuthClientAccessAccepts, radiusAuthClientAccessRejects, and radiusAuthClientAccessChallenges — all Counter32, all counting valid or invalid packets received.
The IANA assigned OID { mib-2 67 } to RADIUS MIB work, under which radiusAuthentication (1) and radiusAuthClientMIB (2) are defined.
All managed objects have MAX-ACCESS read-only; there are no read-write or read-create objects, so a correctly implemented MIB cannot be altered via SNMP SET operations.
radiusAuthServerAddress and radiusAuthClientServerPortNumber are sensitive: the former can assist in attacking the authentication server, the latter in impersonating the client. GET access to these objects should be controlled and values should possibly be encrypted in transit.
SNMPv1 is not a secure environment even over IPsec, as it provides no access control. Implementers are recommended to use SNMPv3 with the User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575).