Version

RADIUS Extension [RFC4590] AVPs

RADIUS Extension for Digest Authentication Interface

The RADIUS Extension for Digest Authentication Interface enables native support for HTTP Digest Authentication within the RADIUS protocol. It addresses the limitations of traditional RADIUS attributes when handling digest-based authentication, which is used extensively in HTTP, SIP, and other HTTP-style protocols.

Purpose of the RADIUS Digest Authentication Extension

  • Integrating Digest Authentication into RADIUS: HTTP Digest Authentication, defined in [RFC2617] and adapted for SIP in [RFC3261], remains mandatory for SIP user agents and is used in various protocols. However, standard RADIUS [RFC2865] does not support this mechanism natively. This extension allows a RADIUS server to perform the digest calculation as specified in RFC2617, thus simplifying user provisioning and centralized authentication.
  • Supporting Diverse Digest Mechanisms: In addition to standard HTTP Digest, the extension also supports digest methods such as Authentication and Key Agreement (AKA) as defined in [RFC3310]. A companion document ([SIP-APP]) provides corresponding support within the Diameter protocol.

Key Elements of the RADIUS Digest Authentication Interface

Digest Challenge-Response Mechanism:
The interface leverages the challenge-response protocol inherent in HTTP Digest. When an HTTP/SIP client requests access without credentials, the server issues a challenge by returning a nonce. The client then calculates a cryptographic digest using this nonce, portions of its request, and a shared secret. The server performs the same calculation to verify the credentials.

New RADIUS Attributes. To support HTTP Digest Authentication, the following new attributes are defined:

  • Digest-Method: Indicates the digest algorithm or method being used.
  • Digest-URI: Specifies the Uniform Resource Identifier for which the digest is calculated.
  • Digest-Nonce: Generated by the RADIUS server to provide a unique challenge.
  • Digest-Realm: Defines the protection domain for the authentication.
  • Message-Authenticator: As per [RFC3579], to ensure message integrity.
  • Optionally, Digest-Algorithm, Digest-Qop, Digest-Domain, and Digest-Opaque may be included to support additional parameters of the digest mechanism.

RADIUS Client Considerations:
The new digest-related attributes are transmitted in cleartext. As such, if a RADIUS client accepts secure connections (HTTPS or SIPS) from HTTP-style clients, there is a risk that sensitive information could be exposed during the RADIUS exchange.

RADIUS Server Operations:
When receiving an Access-Request with a Digest-Method and Digest-URI but without a Digest-Nonce, the RADIUS server generates a nonce and includes it in an Access-Challenge packet. The server must always include Digest-Realm and Message-Authenticator, and it should also include Digest-Algorithm and Digest-Qop as appropriate. Optionally, Digest-Domain or Digest-Opaque may be added to further define the authentication parameters.

Operational Workflow

Initial Request:

  • An HTTP/SIP client sends a request without an authorization header to a server acting as both the HTTP/SIP server and a RADIUS NAS.

RADIUS Access-Request (First Step):

  • The server forwards an Access-Request to the RADIUS server including the Digest-Method and Digest-URI attributes but omitting the Digest-Nonce.

Nonce Generation and Challenge:

  • The RADIUS server detects the missing nonce and generates one. It then sends an Access-Challenge containing the new Digest-Nonce along with Digest-Realm, Message-Authenticator, and optionally Digest-Algorithm and Digest-Qop.

Challenge Response to Client:

  • The server extracts the relevant digest attributes from the Access-Challenge to construct an HTTP/SIP “(Proxy) Authorization required” response, which it sends back to the client.

Credential Submission:

  • Upon receiving the challenge, the client resends its request now including its calculated digest credentials.

Final Authentication Request:

  • The server sends a second Access-Request to the RADIUS server containing the client’s credentials.

Verification and Response:

  • The RADIUS server (C) verifies the received digest against its own calculation. It then responds with an Access-Accept if the credentials are valid or an Access-Reject if they are not. Based on this outcome, the server (B) either processes the client’s request or returns an authorization failure message.

For complete technical specification of RADIUS Extension for Digest Authentication Interface in Diameter protocol please refer to: [RFC4590]

package com.mobius.software.telco.protocols.diameter.primitives.rfc4590
 

Name

AVP Code

Data Type

Vendor

Digest-AKA-Auts

118

UTF8String

IETF

Used in Authentication and Key Agreement (AKA) Digest Authentication, as specified in [RFC 3310] and [RFC 4590]. It carries the AUTS parameter, which is essential for synchronization failure recovery in AKA-based authentication. This AVP is only present in Access-Request packets, typically within Diameter applications that support HTTP Digest Authentication with AKA.

Used only when Digest Authentication is based on AKA.

AUTS parameter is a base64-encoded value that facilitates sequence number (SQN) synchronization between the client and the Authentication Center (AuC).

If SQN synchronization fails, the client includes AUTS in the request to inform the Diameter server of the discrepancy.

The server uses AUTS to re-sync the SQN and generate a fresh authentication vector (AV), which is then used to re-challenge the client.

Client-Side Behavior:

  • If the authentication challenge fails due to SQN mismatch, the client sends the AUTS parameter.

  • The AUTS value is extracted from the auts-param in the HTTP Digest Authentication request.

  • The client does not use a password when computing its credentials; instead, it calculates them using an empty password ("").

Server-Side Behavior:

  • The server receives the AUTS parameter.

  • It verifies the validity of the AUTS using the shared secret key (K).

  • If valid, the server updates its SQN and issues a new authentication challenge to the client.

Example Usage (Base64-Encoded AUTS Parameter in HTTP Digest Authentication):

auts="CjkyMzRfOiwg5CfkJ2UK="

Digest-Algorithm

111

UTF8String

IETF

Used in HTTP Digest Authentication [RFC 2617] within Diameter-based authentication frameworks [RFC 4590]. It specifies the cryptographic hash algorithm to be used for digest calculations in Access-Request and Access-Challenge messages. If this AVP is absent, the default algorithm is assumed to be MD5. 

Specifies the hashing algorithm for Digest Authentication.

Used exclusively in Access-Request and Access-Challenge packets.

Client Behavior:

  • In Access-Requests, the RADIUS/Diameter client extracts the algorithm value from the HTTP-style authentication request.

Server Behavior:

  • In Access-Challenges, the RADIUS/Diameter server specifies the preferred algorithm in this AVP.

Supported Algorithm Values:

"MD5" (default if AVP is absent)

"SHA-256"

"SHA-512/256"

"SHA-512"

"SHA-1" (deprecated due to security concerns)

Digest-Auth-Param

117

UTF8String

IETF

Serves as a placeholder for future extensions and corresponds to the "auth-param" parameter defined in [RFC 2617], Section 3.2.1. It allows for the exchange of authentication extension parameters within Digest headers that:

  • Are unknown to the RADIUS client.

  • Have no corresponding stand-alone attributes.

The AVP carries both the parameter name and value, ensuring the client and server can process unrecognized Digest attributes during authentication.

If the Digest header includes multiple unknown parameters, each parameter/value combination MUST be sent as a separate AVP.

Used only in:

Access-Request

Access-Challenge

Access-Accept

Value Format:

  • Parameter name

  • Equal sign ('=')

  • Parameter value enclosed in quotes (e.g., "qop=\"auth\"").

The value MUST be at least 3 characters long.

Digest-CNonce

113

UTF8String

IETF

Used to carry the client nonce parameter (cnonce) required in HTTP Digest Authentication calculations. This parameter ensures the integrity and uniqueness of authentication sessions by preventing replay attacks. It is derived from the cnonce-value defined in [RFC 2617] and is used for Access-Request packets only.

Digest-Domain

119

UTF8String

IETF

Defines the protection space component for HTTP-style protocols, such as Digest Authentication, based on [RFC 2617]. It specifies the URIs included in the 'domain' directive of a WWW-Authenticate header and is used in Access-Challenge packets only.

Digest-Entity-Body-Hash

112

UTF8String

IETF

Used in Diameter-based HTTP Digest Authentication [RFC 4590] when the qop (quality of protection) level is set to "auth-int" (authentication with integrity protection). Instead of sending the full HTTP message body, this AVP contains a hash of the entity body that is used in the digest calculation. This AVP MUST only be present in Access-Request messages.

When a client authenticates using HTTP Digest with qop="auth-int", it must hash the HTTP entity body before computing the digest.

Instead of transmitting the full entity body, the client sends only H(entity-body) in Digest-Entity-Body-Hash.

The server uses this hash in digest verification.

The value stored in this AVP is the hexadecimal representation of H(entity-body), where H() is the cryptographic hash function used in digest calculation.

Common hash functions include MD5, SHA-256, or SHA-512, as defined in Digest-Algorithm AVP.

If the HTTP message body is empty, the hash value is computed as per [RFC 3261], Section 22.4.

Digest-HA1

121

UTF8String

IETF

Used in Access-Accept packets to facilitate the generation of the Authentication-Info header, particularly when the HTTP-style response body is required for calculating the rspauth value. It supports HTTP Digest Authentication mechanisms where quality of protection (qop) is set to 'auth-int' and ensures secure authentication based on H(A1), as defined in [RFC 2617].

The Digest-Algorithm AVP must be set to MD5-sess or AKAv1-MD5-sess.

Alternatively, IPsec must be configured between the RADIUS client and RADIUS server for transport security.

MUST NOT be sent if the qop parameter is not specified or set to 'auth'.

Use Digest-Response-Auth AVP instead for 'auth' scenarios.

Digest-Method

108

UTF8String

IETF

Specifies the HTTP method (e.g., GET, POST, PUT, etc.) that is used in the HTTP Digest Authentication calculation. It provides the method value as part of the authentication request and is critical for verifying client requests during Access-Request processing.

Digest-Nextnonce

107

UTF8String

IETF

Holds a nonce value used in HTTP Digest Authentication as in [RFC 4590]. This value is utilized for ensuring the security and continuity of digest sessions by providing a new nonce that prevents replay attacks. Works with HTTP-style authentication protocols, specifically using the Authentication-Info header as per [RFC 2617].

Digest-Nonce

105

UTF8String

IETF

Used in HTTP Digest Authentication to carry a nonce value, which acts as a unique identifier for the authentication session.

Client Behavior:

  • When sending an Access-Request, the nonce is included if it was received in a prior Access-Challenge.

Server Behavior:

  • The RADIUS server must include a nonce in its Access-Challenge if the Access-Request does not contain one.

Nonce format should be a base64-encoded or hexadecimal string. The nonce should be unpredictable, cryptographically secure, and tied to a server-side state if needed.

Digest-Nonce-Count

114

UTF8String

IETF

Used in HTTP Digest Authentication to maintain the count of nonce usage by the client. It plays a key role in replay attack protection by ensuring that each nonce is used only once in a sequence of requests.

Client Behavior:

  • Includes this AVP to specify the current nonce count (nc-value) for each request.

Server Behavior:

  • Validates that the nonce count is monotonically increasing.

  • Rejects requests if the count is reused or out of order.

Digest-Opaque

116

UTF8String

IETF

Used to store server-specific opaque data. This data is sent by the server to the client and returned by the client unchanged during authentication. It is primarily used for session tracking, stateful information, or context handling between the client and the server.

Client Behavior:

  • Access-Request: Includes the value of the opaque directive from the HTTP-style request.

Server Behavior:

  • Access-Challenge: May include this attribute to provide additional session information to the client.

Digest-Qop

110

UTF8String

IETF

Specifies the security mechanisms applied during HTTP Digest Authentication. It defines the level of protection required for the authentication exchange, influencing the digest calculation. This AVP supports both backward compatibility and enhanced security options specified in [RFC 2617] and [RFC 2069].

Choosing auth vs auth-int:

auth offers basic authentication but lacks integrity protection for data payloads.

auth-int ensures the integrity of the message body by hashing it, providing stronger security.

Client Behavior:

  • Access-Request: The client inserts the qop-value received in a previous Access-Challenge packet.

Server Behavior:

  • Access-Challenge: The server specifies the required qop-value(s) for authentication.

  • Multiple Digest-Qop attributes may be included, each with a different qop-value.

Digest-Realm

104

UTF8String

IETF

Specifies the protection space component required for HTTP Digest Authentication. It defines the realm value used by the RADIUS server to identify the authentication domain.

This attribute aligns with [RFC 2617] and is essential for ensuring the correct domain scope for authentication requests.

Client Behavior:

Access-Request: The client provides the realm-value extracted from the HTTP-style request.

Server Behavior: 

Access-Challenge: The server specifies the expected realm to guide authentication.

Digest-Response

103

UTF8String

IETF

Used to carry the request-digest value as part of Digest Authentication in Diameter and RADIUS protocols. It allows the client to prove possession of the password by submitting a cryptographic hash derived from the HTTP Digest Authentication process defined in [RFC 2617]. Digest Length: typically 32 octets (hexadecimal representation of 16 bytes) when using MD5.

Client Behavior:

Computes the request-digest using the HTTP Digest formula and inserts it into this AVP in the Access-Request.

Server Behavior:

Validates the Digest-Response against its locally computed digest based on the stored password and request parameters.

Digest-Response-Auth

106

UTF8String

IETF

Used in HTTP Digest Authentication to allow the RADIUS server to prove possession of the password. It is included in Access-Accept packets as part of the Authentication-Info header. This attribute serves as a digest hash for validating the integrity of the authentication exchange between the client and server. 

If Digest-Qop was set to auth-int, the server MUST send a Digest-HA1 instead of this attribute.

The server calculates the rspauth digest hash following [RFC 2617], Section 3.2.3, and copies the result into this attribute.

Digest-Stale

120

UTF8String

IETF

Used by a RADIUS server to inform the RADIUS client whether the presented nonce has been accepted or is considered stale. It is part of the HTTP Digest Authentication mechanism and is included in Access-Challenge packets.

This AVP determines whether the nonce sent by the client can be reused or if a new authentication request must be initiated. Its value is either 'true' (nonce is stale) or 'false' (nonce is valid). The client uses this information to set the 'stale' directive in the WWW-Authenticate header of the HTTP-style response it wants to authenticate.

Digest-URI

109

UTF8String

IETF

Designed to transport the URI of an HTTP-style request or the value of the digest-uri directive during Digest Authentication. It is mandatory for inclusion in Access-Request packets and plays a key role in validating the request context during authentication. This AVP ensures that the Digest Authentication process can associate the provided URI with the authentication challenge, supporting secure validation.

Value Extraction Rules:

  • If the HTTP-style request includes an Authorization header, the RADIUS client MUST extract the uri directive value (referred to as digest-uri-value in [RFC 2617], Section 3.2.2) and place it in this attribute without surrounding quotes.

  • If the Authorization header is absent, the RADIUS client MUST take the request URI directly from the HTTP-style request being authenticated.

Digest-Username

115

UTF8String

IETF

Carries the user name used in the HTTP Digest calculation. It is specifically designed to facilitate Digest Authentication processes and must be included only in Access-Request packets. This AVP is used by the RADIUS server solely for the purpose of digest computation. 

Digest-Username attribute is not used for identifying or validating the user. Instead, user identification and credential validation are performed using the User-Name (1) attribute, ensuring separation of roles between digest computation and authentication.

SIP-AOR

122

UTF8String

IETF

Used to authorize SIP (Session Initiation Protocol) messages by identifying the URI associated with the user whose access is being authenticated and authorized. The attribute is primarily employed by the RADIUS server to validate and approve SIP requests. It supports both SIP URIs [RFC 3261] and tel URIs [RFC 3966], enabling flexible authorization across different SIP scenarios. Used for the authorization of SIP messages based on the provided Address of Record (AOR).

 

Start innovating with Mobius

What's next? Let's talk!

Mobius Software

As a company you'll get:

  • Get started quickly

  • Support any business model

  • Join millions of businesses

Questions? websupport@mobius.com