RFC 5090

RADIUS Extension for Digest Authentication

📅 published February 2008, from ietf

RFC 5090: RADIUS Extension for Digest Authentication ✨

Okay bestie, let's start with the basics 🎀. This is RFC 5090, published in February 2008 by the Network Working Group. It's a Standards Track document, so it's an actual Internet standard and not just a suggestion 💅. Five people wrote it: B. Sterman (Kayote Networks), D. Sadolevsky (SecureOL, Inc.), D. Schwartz (Kayote Networks), D. Williams (Cisco Systems), and W. Beck (Deutsche Telekom AG) 🫶. It obsoletes RFC 4590 🦋, so if you're still reading 4590, this is the newer main-character version.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's basically inviting everyone to discuss it and send suggestions for improvements 🗣️. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Abstract 🧚

So the big idea is this: the doc defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol so it can support Digest Authentication 🔐. That way it works with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. It's giving interoperability ✨.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Motivation .................................................3
      1.2. Terminology ................................................3
      1.3. Overview ...................................................4
   2. Detailed Description ............................................6
      2.1. RADIUS Client Behavior .....................................6
      2.2. RADIUS Server Behavior .....................................9
   3. New RADIUS Attributes ..........................................12
      3.1. Digest-Response Attribute .................................12
      3.2. Digest-Realm Attribute ....................................13
      3.3. Digest-Nonce Attribute ....................................13
      3.4. Digest-Response-Auth Attribute ............................14
      3.5. Digest-Nextnonce Attribute ................................14
      3.6. Digest-Method Attribute ...................................15
      3.7. Digest-URI Attribute ......................................15
      3.8. Digest-Qop Attribute ......................................15
      3.9. Digest-Algorithm Attribute ................................16
      3.10. Digest-Entity-Body-Hash Attribute ........................16
      3.11. Digest-CNonce Attribute ..................................17
      3.12. Digest-Nonce-Count Attribute .............................17
      3.13. Digest-Username Attribute ................................17
      3.14. Digest-Opaque Attribute ..................................18
      3.15. Digest-Auth-Param Attribute ..............................18
      3.16. Digest-AKA-Auts Attribute ................................19
      3.17. Digest-Domain Attribute ..................................19
      3.18. Digest-Stale Attribute ...................................20
      3.19. Digest-HA1 Attribute .....................................20
      3.20. SIP-AOR Attribute ........................................21
   4. Diameter Compatibility .........................................21
   5. Table of Attributes ............................................21
   6. Examples .......................................................23
   7. IANA Considerations ............................................27
   8. Security Considerations ........................................28
      8.1. Denial of Service .........................................28
      8.2. Confidentiality and Data Integrity ........................28
   9. References .....................................................29
      9.1. Normative References ......................................29
      9.2. Informative References ....................................30
   Appendix A - Changes from RFC 4590 ................................31
   Acknowledgements ..................................................31

1. Introduction ✨

1.1. Motivation 💭

Okay so the HTTP Digest Authentication mechanism, defined in [RFC2617], later got adapted for use with SIP [RFC3261] 🧩. Digest has some limitations and weaknesses (see [RFC2617], Section 4), so SIP also defines extra authentication and encryption mechanisms, including Transport Layer Security (TLS) [RFC4346] and Secure MIME (S/MIME) [RFC3851] 🔒. But here's the tea: Digest Authentication support is mandatory in SIP implementations, and it's the preferred way for a SIP UA to authenticate itself to a proxy server 🫖. Digest is used in other protocols too, literally everywhere 🌸.

To make user provisioning easier, there's a need to support this authentication mechanism inside Authentication, Authorization, and Accounting (AAA) protocols like RADIUS [RFC2865] and Diameter [RFC3588] 🧚. That's the whole reason this doc exists.

This document defines an extension to the RADIUS protocol so it can support Digest Authentication for use with SIP, HTTP, and other HTTP-style protocols that use this authentication method 💖. Digest mechanisms such as Authentication and Key Agreement (AKA) [RFC3310] are supported too ✨. And a companion document, [RFC4740], defines support for Digest Authentication within Diameter 🎀.

1.2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🦋.

The use of normative requirement key words in this document shall apply only to RADIUS client and RADIUS server implementations that include the features described in this document. This document creates no normative requirements for existing implementations 🙈. So if your implementation doesn't have these features, don't panic, nothing is being forced on you.

Now let's get into the vocab, bestie 💅:

  • HTTP-style protocol: The term "HTTP-style" denotes any protocol that uses HTTP-like headers and uses HTTP Digest Authentication as described in [RFC2617]. Examples are HTTP and the Session Initiation Protocol (SIP) 🌈.
  • NAS (Network Access Server): The RADIUS client 🖥️.
  • nonce: An unpredictable value used to prevent replay attacks 🛡️. The nonce generator may use cryptographic mechanisms to produce nonces it can recognize without maintaining state. Iconic, no state needed 🧠.
  • protection space: HTTP-style protocols differ in how they define the protection space 🏰. For HTTP, it's the combination of the realm and canonical root URL of the requested resource, for which the use is authorized by the RADIUS server. In the case of SIP, the realm string alone defines the protection space 💜.
  • SIP UA (SIP User Agent): An Internet endpoint that uses the Session Initiation Protocol 📱.
  • SIP UAS (SIP User Agent Server): A logical entity that generates a response to a SIP (Session Initiation Protocol) request 📨.

1.3. Overview ✨

Okay bestie, so HTTP Digest is a challenge-response protocol 💖 It's used to authenticate a client's request to access some resource on a server. Figure 1 shows one whole HTTP Digest transaction 🦋

                              HTTP/SIP..
               +------------+  (1)     +------------+
               |            |--------->|            |
               | HTTP-style |  (2)     | HTTP-style |
               | client     |<---------| server     |
               |            |  (3)     |            |
               |            |--------->|            |
               |            |  (4)     |            |
               |            |<---------|            |
               +------------+          +------------+

               Figure 1: Digest Operation without RADIUS

Here's how the vibe goes 💅 If the client sends a request with no credentials (1), the server replies with an error response (2) that includes a nonce. The client then makes a cryptographic digest out of parts of the request, the nonce it got from the server, and a shared secret. It retransmits the request (3) to the server, but this time the digest is included in the packet. The server does the same digest calculation as the client and compares its result with the digest it received in (3). If the digest values match, the server grants access to the resource and sends a positive response to the client (4). If they differ, the server sends a negative response to the client (4). ✨

Instead of keeping a local user database, the server could use RADIUS to reach a centralized user database 🌸 Plot twist though: RADIUS [RFC2865] doesn't include support for HTTP Digest Authentication 🙈 The RADIUS client can't use the User-Password Attribute, since it never gets a password from the HTTP-style client. The CHAP-Challenge and CHAP-Password attributes described in [RFC1994] aren't suitable either, because the Challenge Handshake Authentication Protocol (CHAP) algorithm isn't compatible with HTTP Digest 😭

This document defines new attributes so the RADIUS server can do the digest calculation defined in [RFC2617]. That gives you Digest Authentication as a native authentication mechanism inside RADIUS 👑

The nonces the digest algorithm needs are generated by the RADIUS server. Generating them in the RADIUS client would save a round-trip, but it would introduce security and operational issues. Some digest algorithms -- e.g., AKA [RFC3310] -- would not work.

Figure 2 shows a scenario where the HTTP-style server hands off authentication to a RADIUS server 🧚 Entities A and B talk using HTTP or SIP, while entities B and C talk using RADIUS.

                       HTTP/SIP           RADIUS

               +-----+    (1)    +-----+           +-----+
               |     |==========>|     |    (2)    |     |
               |     |           |     |---------->|     |
               |     |           |     |    (3)    |     |
               |     |    (4)    |     |<----------|     |
               |     |<==========|     |           |     |
               |     |    (5)    |     |           |     |
               |     |==========>|     |           |     |
               |  A  |           |  B  |    (6)    |  C  |
               |     |           |     |---------->|     |
               |     |           |     |    (7)    |     |
               |     |           |     |<----------|     |
               |     |    (8)    |     |           |     |
               |     |<==========|     |           |     |
               +-----+           +-----+           +-----+

                ====> HTTP/SIP
                ----> RADIUS

                     Figure 2: HTTP Digest over RADIUS

The entities have these roles:

  • A: HTTP client / SIP UA
  • B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} acting also as a RADIUS NAS
  • C: RADIUS server

Here's the message flow for this scenario 🎀 A sends B an HTTP/SIP request without an Authorization header (step 1). B sends an Access-Request packet with the newly defined Digest-Method and Digest-URI attributes, but without a Digest-Nonce Attribute, to the RADIUS server, C (step 2). C chooses a nonce and responds with an Access-Challenge (step 3). This Access-Challenge contains Digest attributes, and B takes values from them to construct an HTTP/SIP "(Proxy) Authorization required" response. B sends this response to A (step 4). A resends its request with its credentials (step 5). B sends an Access-Request to C (step 6). C checks the credentials and replies with Access-Accept or Access-Reject (step 7). Depending on C's result, B either processes A's request or rejects it with a "(Proxy) Authorization required" response (step 8).

2. Detailed Description 🌈

2.1. RADIUS Client Behavior 🔥

Heads up, this part is serious 🙈 The attributes described in this document are sent in cleartext. So if a RADIUS client accepted secure connections (HTTPS or SIPS) from HTTP-style clients, information that those clients intentionally protected could end up being sent in the clear during the RADIUS exchange 😭

2.1.1. Credential Selection 🦋

When an HTTP-style request message comes in, the RADIUS client checks whether it is authorized to authenticate the request. Where an HTTP-style request traverses several proxies, and each of those proxies asks to authenticate the HTTP-style client, the request at the HTTP-style server may contain multiple credential sets.

The RADIUS client can use the realm directive in HTTP to figure out which credentials apply. Where none of the realms are of interest, the RADIUS client MUST behave as though no relevant credentials were sent. In all situations, the RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its locally configured realm.

2.1.2. Constructing an Access-Request 💖

If a matching (Proxy-)Authorization header is present and contains HTTP Digest information, the RADIUS client checks the nonce parameter.

If the RADIUS client recognizes the nonce, it takes the header directives and puts them into a RADIUS Access-Request packet. It puts the response directive into a Digest-Response Attribute. The realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, and opaque directives go into the matching Digest-Realm, Digest-Nonce, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest-Nonce-Count, Digest-Username, and Digest-Opaque attributes. The RADIUS client puts the request method into the Digest-Method Attribute.

Due to HTTP syntactic requirements, quoted strings found in HTTP Digest directives may contain escaped quote and backslash characters. When translating these directives into RADIUS attributes, the RADIUS client only removes the leading and trailing quote characters that surround the directive value. It does not unescape anything within the string. See Section 3 for an example.

If the Quality of Protection (qop) directive's value is 'auth-int', the RADIUS client calculates H(entity-body) as described in [RFC2617], Section 3.2.1, and puts the result in a Digest-Entity-Body-Hash Attribute.

The RADIUS client adds a Message-Authenticator Attribute, defined in [RFC3579], and sends the Access-Request packet to the RADIUS server.

The RADIUS server processes the packet and responds with either an Access-Accept or an Access-Reject 🎀

2.1.3. Constructing an Authentication-Info Header ✨

After receiving an Access-Accept from the RADIUS server, the RADIUS client constructs an Authentication-Info header:

  • If the Access-Accept packet contains a Digest-Response-Auth Attribute, the RADIUS client checks the Digest-Qop Attribute:
    • If the Digest-Qop Attribute's value is 'auth' or not specified, the RADIUS client puts the Digest-Response-Auth Attribute's content into the Authentication-Info header's rspauth directive of the HTTP-style response.
    • If the Digest-Qop Attribute's value is 'auth-int', the RADIUS client ignores the Access-Accept packet and behaves as if it had received an Access-Reject packet (Digest-Response-Auth can't be correct, as the RADIUS server does not know the contents of the HTTP-style response's body) 💀
  • If the Access-Accept packet contains a Digest-HA1 Attribute, the RADIUS client checks the qop and algorithm directives in the Authorization header of the HTTP-style request it wants to authorize:
    • If the qop directive is missing or its value is 'auth', the RADIUS client ignores the Digest-HA1 Attribute. It does not include an Authentication-Info header in its HTTP-style response.
    • If the qop directive's value is 'auth-int' and at least one of the following conditions is true, the RADIUS client calculates the contents of the HTTP-style response's rspauth directive:
      • The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
      • IP Security (IPsec) is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).

The RADIUS client creates the HTTP-style response message and calculates the hash of this message's body. It uses the result and the Digest-URI Attribute's value of the corresponding Access-Request packet to perform the H(A2) calculation. It takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and Digest-Qop values of the corresponding Access-Request, along with the Digest-HA1 Attribute's value, to finish the computation of the rspauth value.

  • If the Access-Accept packet contains neither a Digest-Response-Auth nor a Digest-HA1 Attribute, the RADIUS client will not create an Authentication-Info header for its HTTP-style response.

When the RADIUS server provides a Digest-Nextnonce Attribute in the Access-Accept packet, the RADIUS client puts the contents of this attribute into a nextnonce directive. Now it can send an HTTP-style response 🌸

2.1.4. Failed Authentication 😭

If the RADIUS client receives an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header.

If the RADIUS client receives an Access-Challenge packet in response to an Access-Request containing a Digest-Nonce Attribute, the RADIUS server did not accept the nonce. If a Digest-Stale Attribute is present in the Access-Challenge and has a value of 'true' (without surrounding quotes), the RADIUS client sends an error response (401 or 407) containing a WWW-/Proxy-Authenticate header with the stale directive set to 'true' and the digest directives derived from the Digest-* attributes 🧚

If the RADIUS client receives an Access-Reject from the RADIUS server, it sends an error response to the HTTP-style request it has received. If the RADIUS client does not receive a response, it retransmits or fails over to another RADIUS server, as described in [RFC2865] 🫶

2.1.5. Obtaining Nonces 🔐

okay so the RADIUS client has two ways to get its hands on a nonce 💅 Option one: a previous Access-Accept packet already handed it a Digest-Nextnonce Attribute. Option two: it just asks the RADIUS server for one. To ask, it sends an Access-Request with a Digest-Method and a Digest-URI Attribute, but no Digest-Nonce Attribute. It also tacks on a Message-Authenticator (see [RFC3579]) Attribute 🎀 The RADIUS server picks a nonce and replies with an Access-Challenge that carries a Digest-Nonce Attribute. Iconic. ✨

Next, the client builds a (Proxy-)Authenticate header using the Digest-Nonce and Digest-Realm values, which fill the nonce and realm directives 🦋 The server is also allowed to send Digest-Qop, Digest-Algorithm, Digest-Domain, and Digest-Opaque Attributes in that same Access-Challenge carrying the nonce. If any of those show up, the client MUST use them. No skipping, bestie 🫶

2.2. RADIUS Server Behavior 🖥️

Now let's flip to the server side 👑 If the RADIUS server gets an Access-Request with a Digest-Method and a Digest-URI Attribute but no Digest-Nonce Attribute, it picks a nonce. It shoves that nonce into a Digest-Nonce Attribute and sends it back in an Access-Challenge packet to the RADIUS client. The server MUST add Digest-Realm and Message-Authenticator (see [RFC3579]). It SHOULD add Digest-Algorithm and one or more Digest-Qop Attributes, and it MAY add Digest-Domain or Digest-Opaque Attributes to the Access-Challenge packet 💖

2.2.1. General Attribute Checks 🔍

This part is giving detective energy 🕵️‍♀️ If the RADIUS server gets an Access-Request containing a Digest-Response Attribute, it looks for these attributes: Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, and Digest-Username. Depending on what Digest-Algorithm and Digest-Qop contain, it also looks for Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts. For the details, check out [RFC2617] and [RFC3310] 📚 If the Digest-Algorithm Attribute is missing, 'MD5' is assumed. And if the server issued a Digest-Opaque Attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque Attribute. Non-negotiable, periodt 💅

If mandatory attributes are missing, the server MUST respond with an Access-Reject packet. No exceptions, no vibes-based decisions 🙅‍♀️

The RADIUS server removes \ characters that escape quote and \ characters from the text values it got in the Digest-* attributes ✂️

If the mandatory attributes are all there, the RADIUS server MUST check whether the RADIUS client is authorized to serve users of the realm named in the Digest-Realm Attribute. If the client isn't authorized, the server MUST send an Access-Reject. The server SHOULD log the event so the operator gets notified 🚨 It MAY also take extra action, like sending an Access-Reject for every future request from this client, until management action resets that behavior. Main character energy for security 😤

Last thing: the server figures out how old the nonce in Digest-Nonce is, either by reading an embedded timestamp or by looking it up in a local table ⏰ If the timestamp is embedded in the nonce, the RADIUS server MUST check the nonce's integrity. Section 2.2.2 covers how the server handles old nonces, so keep that in your back pocket 🫶

2.2.2. Authentication 🔑

If the Access-Request passes the checks above, the RADIUS server works out the digest response as described in [RFC2617] ✨ To look up the password, it uses the RADIUS User-Name Attribute. The RADIUS server MUST check that the user identified by User-Name is:

  • authorized to access the protection space, and
  • authorized to use the URI included in the SIP-AOR Attribute, if that attribute is present.

If any of those checks fail, the RADIUS server MUST send an Access-Reject 🙈

Matching User-Name with SIP-AOR values is required, just so nobody can register or misuse a SIP-AOR that belongs to someone else. Protecting the vibes, literally 💜

Every value needed for the digest calculation comes from the Digest attributes described in this document 🧮 If the calculated digest response equals the value in the Digest-Response Attribute, the authentication was successful. Yay 🎉

If the response values match but the RADIUS server thinks the nonce in Digest-Nonce is too old, it sends an Access-Challenge packet with a new nonce and a Digest-Stale Attribute set to 'true' (without surrounding quotes) 🌸 And if the response values don't match, the RADIUS server responds with an Access-Reject. Not me, not today 💀

2.2.3. Constructing the Reply 📬

If the authentication worked, the RADIUS server adds an attribute to the Access-Accept packet. The RADIUS client can use it to build an Authentication-Info header 🎀

  • If the Digest-Qop Attribute's value is 'auth' or unspecified, the RADIUS server SHOULD put a Digest-Response-Auth Attribute into the Access-Accept packet.
  • If the Digest-Qop Attribute's value is 'auth-int' and at least one of the following is true, the RADIUS server SHOULD put a Digest-HA1 Attribute into the Access-Accept packet:
    • The Digest-Algorithm Attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
    • IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).

In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent. Strict, but iconic 🚫

RADIUS servers MAY construct a Digest-Nextnonce Attribute and add it to the Access-Accept packet 🍓 This is handy for limiting how long a nonce lives and for saving a round-trip in future requests (see the nextnonce discussion in [RFC2617], Section 3.2.3). The RADIUS server then adds a Message-Authenticator Attribute (see [RFC3579]) and sends the Access-Accept packet to the RADIUS client 🧚

If the RADIUS server doesn't accept the nonce from an Access-Request but the authentication still succeeded, the server MUST send an Access-Challenge packet with a Digest-Stale Attribute set to 'true' (without surrounding quotes). The server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, and Digest-Realm. It SHOULD add Digest-Algorithm and one or more Digest-Qops, and it MAY add Digest-Domain or Digest-Opaque attributes to the Access-Challenge packet 🌈

3. New RADIUS Attributes 🎀

Okay, here comes the attribute format! Unless stated otherwise, every attribute looks like this 🧁

0                   1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  Length       | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Quote and backslash characters in Digest-* attributes that represent HTTP-style directives with quoted-string syntax get escaped 🪄 The surrounding quotes get removed, too, since they're just syntax and totally redundant in RADIUS. For example, the directive

realm="the \"example\" value"

gets represented like this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest-Realm  |       23      | the \"example\" value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1. Digest-Response Attribute 💌

  • Description: If this attribute shows up in an Access-Request message, a RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication. When a RADIUS client gets a (Proxy-)Authorization header, it puts the request-digest value into a Digest-Response Attribute. This attribute (which lets the user prove they know the password 🔐) MUST only be used in Access-Request packets.
  • Type: 103 for Digest-Response.
  • Length: >= 3
  • Text: When using HTTP Digest, the text field is 32 octets long and holds a hexadecimal representation of a 16-octet digest value, calculated by the authenticated client. Other digest algorithms MAY define different digest lengths 🦋 The text field MUST be copied from the request-digest of the digest-response [RFC2617], without surrounding quotes.

3.2. Digest-Realm Attribute 🗺️

  • Description: This attribute describes a protection space component of the RADIUS server. HTTP-style protocols define protection space differently, so see [RFC2617], Section 1.2, for the details. It MUST only be used in Access-Request, Access-Challenge, and Accounting-Request packets.
  • Type: 104 for Digest-Realm
  • Length: >= 3
  • Text: In Access-Requests, the RADIUS client takes the value of the realm directive (realm-value according to [RFC2617]), without surrounding quotes, from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts the expected realm value into this attribute.

3.3. Digest-Nonce Attribute 🧂

  • Description: This attribute holds a nonce for the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce Attribute, the RADIUS server MUST put a Digest-Nonce Attribute into its Access-Challenge packet. This attribute MUST only be used in Access-Request and Access-Challenge packets.
  • Type: 105 for Digest-Nonce
  • Length: >= 3
  • Text: In Access-Requests, the RADIUS client takes the value of the nonce directive (nonce-value in [RFC2617]), without surrounding quotes, from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the attribute contains the nonce the RADIUS server selected 🌟

3.4. Digest-Response-Auth Attribute 🫶

  • Description: This attribute lets the RADIUS server prove it knows the password 💪 If the previously received Digest-Qop Attribute was 'auth-int' (without surrounding quotes), the RADIUS server MUST send a Digest-HA1 Attribute instead of a Digest-Response-Auth Attribute. The Digest-Response-Auth Attribute MUST only be used in Access-Accept packets. The RADIUS client puts the attribute value, without surrounding quotes, into the rspauth directive of the Authentication-Info header.
  • Type: 106 for Digest-Response-Auth.
  • Length: >= 3
  • Text: The RADIUS server calculates a digest according to Section 3.2.3 of [RFC2617] and copies the result into this attribute. Digest algorithms other than the one defined in [RFC2617] MAY define digest lengths other than 32 ✨

3.5. Digest-Nextnonce Attribute 🌸

This attribute holds a nonce for the HTTP Digest calculation too 💕

  • Description: The RADIUS server MAY put a Digest-Nextnonce Attribute into an Access-Accept packet. If this attribute is present, the RADIUS client MUST put its contents into the nextnonce directive of an Authentication-Info header in its HTTP-style response. This attribute MUST only be used in Access-Accept packets.
  • Type: 107 for Digest-Nextnonce
  • Length: >= 3
  • Text: It is recommended that this text be base64 or hexadecimal data 🍓

3.6. Digest-Method Attribute 💅

Description 🎀 okay so this one holds the method value that goes into the HTTP Digest calculation 🦋 and it's giving very specific energy, because this attribute MUST only be used in Access-Request and Accounting-Request packets 🔥

Type 🧚 108 for Digest-Method

Length 📏 >= 3

Text 💬 in Access-Requests, the RADIUS client grabs the value of the request method from the HTTP-style request it wants to authenticate ✨

3.7. Digest-URI Attribute 🌸

Description 🎀 this attribute carries the contents of the digest-uri directive, or the URI of the HTTP-style request 🔗 bestie, it MUST only be used in Access-Request and Accounting-Request packets, no exceptions 🙈

Type 🧚 109 for Digest-URI

Length 📏 >= 3

Text 💬 if the HTTP-style request has an Authorization header, the RADIUS client copies the value of the uri directive from that header (known as "digest-uri-value" in Section 3.2.2 of [RFC2617]) into this attribute, without surrounding quotes 💅 if there's no Authorization header, the RADIUS client takes the value of the request URI from the HTTP-style request it wants to authenticate instead 🫶

3.8. Digest-Qop Attribute 👑

Description 🎀 this one holds the Quality of Protection parameter that influences the HTTP Digest calculation 🔐 this attribute MUST only be used in Access-Request, Access-Challenge, and Accounting-Request packets 🌈 a RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet ✨ RADIUS servers SHOULD insert at least one Digest-Qop Attribute in an Access-Challenge packet 💖 Digest-Qop is optional, which keeps backward compatibility with a minimal implementation of [RFC2069] 🧚

Type 🧚 110 for Digest-Qop

Length 📏 >= 3

Text 💬 in Access-Requests, the RADIUS client takes the value of the qop directive (qop-value as described in [RFC2617]) from the HTTP-style request it wants to authenticate 🎀 in Access-Challenge packets, the RADIUS server puts a desired qop-value into this attribute 🦋 if the RADIUS server supports more than one "quality of protection" value, it puts each qop-value into a separate Digest-Qop Attribute 🍓

3.9. Digest-Algorithm Attribute 🌈

Description 🎀 this attribute holds the algorithm parameter that influences the HTTP Digest calculation 🧮 it MUST only be used in Access-Request, Access-Challenge, and Accounting-Request packets 💅 if this attribute is missing, MD5 is assumed 🫶

Type 🧚 111 for Digest-Algorithm

Length 📏 >= 3

Text 💬 in Access-Requests, the RADIUS client takes the value of the algorithm directive (as described in [RFC2617], Section 3.2.1) from the HTTP-style request it wants to authenticate ✨ in Access-Challenge packets, the RADIUS server SHOULD put the desired algorithm into this attribute 💖

3.10. Digest-Entity-Body-Hash Attribute 🍓

Description 🎀 okay so when the qop-value is 'auth-int', a hash of the HTTP-style message body's contents is required for the digest calculation 🔥 instead of sending the whole body, you only send its hash value 🙈 and that hash can be used directly in the digest calculation 💅

The clarifications described in section 22.4 of [RFC3261] about the hash of empty entity bodies apply to the Digest-Entity-Body-Hash Attribute 🌸 this attribute MUST only be sent in Access-Request packets 💜

Type 🧚 112 for Digest-Entity-Body-Hash

Length 📏 >= 3

Text 💬 the attribute holds the hexadecimal representation of H(entity-body) 🔐 this hash is required by certain authentication mechanisms, such as HTTP Digest with quality of protection set to 'auth-int' 🌈 RADIUS clients MUST use this attribute to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the RADIUS server requires that the integrity of the entity body (e.g., qop parameter set to 'auth-int') be verified 👑 extensions to this document may define support for authentication mechanisms other than HTTP Digest 🦋

3.11. Digest-CNonce Attribute 🌷

Description 🎀 this attribute holds the client nonce parameter used in the HTTP Digest calculation 🧁 it MUST only be used in Access-Request packets 💅

Type 🧚 113 for Digest-CNonce

Length 📏 >= 3

Text 💬 this attribute includes the value of the cnonce-value [RFC2617], without surrounding quotes, taken from the HTTP-style request ✨

3.12. Digest-Nonce-Count Attribute 🔁

Description 🎀 this one includes the nonce count parameter, which is used to detect replay attacks 🚨 the attribute MUST only be used in Access-Request packets 🙈

Type 🧚 114 for Digest-Nonce-Count

Length 📏 10

Text 💬 in Access-Requests, the RADIUS client takes the value of the nc directive (nc-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate 🫶

3.13. Digest-Username Attribute 🧸

Description 🎀 this attribute holds the user name used in the HTTP Digest calculation 💁‍♀️ the RADIUS server MUST use this attribute only for calculating the digest 🧮 to figure out the right user credentials, the RADIUS server MUST use the User-Name (1) Attribute, and MUST NOT use the Digest-Username Attribute 🛑 this attribute MUST only be used in Access-Request and Accounting-Request packets 💜

Type 🧚 115 for Digest-Username

Length 📏 >= 3

Text 💬 in Access-Requests, the RADIUS client takes the value of the username directive (username-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate 🌸

3.14. Digest-Opaque Attribute 🦋

Description 🎀 this one holds the opaque parameter that gets passed to the HTTP-style client 🎁 the HTTP-style client passes this value back to the server (aka the RADIUS client) without modification ✨ this attribute MUST only be used in Access-Request and Access-Challenge packets 💅

Type 🧚 116 for Digest-Opaque

Length 📏 >= 3

Text 💬 in Access-Requests, the RADIUS client takes the value of the opaque directive (opaque-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate, and puts it into this attribute 🫶 in Access-Challenge packets, the RADIUS server MAY include this attribute 🌈

3.15. Digest-Auth-Param Attribute 🧩

Description 🎀 this attribute is a placeholder for future extensions, and it corresponds to the auth-param parameter defined in Section 3.2.1 of [RFC2617] 🔮 the Digest-Auth-Param is how the RADIUS client and RADIUS server swap auth-param extension parameters that live inside Digest headers, which the RADIUS client doesn't understand and which don't have any matching stand-alone attributes 🤝

Unlike the Digest-* attributes we've looked at already, Digest-Auth-Param carries both the value and the parameter name, since the RADIUS client doesn't know the name 🙈 if the Digest header has several unknown parameters, the RADIUS implementation MUST repeat this attribute, and each instance MUST contain one different unknown Digest parameter/value combination 💥 this attribute MUST ONLY be used in Access-Request, Access-Challenge, Access-Accept, and Accounting-Request packets 🔥

Type 🧚 117 for Digest-Auth-Param

Length 📏 >= 3

Text 💬 the text consists of the whole parameter, including its name, the equal sign ('='), and quotes 🎀

3.16. Digest-AKA-Auts Attribute 🌙

Description 🎀 this attribute holds the auts parameter used in the Digest AKA [RFC3310] calculation 🧮 it's only used if the algorithm of the digest-response denotes a version of AKA Digest [RFC3310] ✨ this attribute MUST only be used in Access-Request packets 💅

Type 🧚 118 for Digest-AKA-Auts

Length 📏 >= 3

Text 💬 in Access-Requests, the RADIUS client takes the value of the auts directive (auts-param according to Section 3.4 of [RFC3310]) without surrounding quotes from the HTTP-style request it wants to authenticate 🫶

3.17. Digest-Domain Attribute 🗺️

Description 🎀 when a RADIUS client has asked for a nonce, the RADIUS server MAY send one or more Digest-Domain attributes in its Access-Challenge packet 💌 the RADIUS client puts them into the quoted, space-separated list of URIs of the domain directive of a WWW-Authenticate header 🌐 together with Digest-Realm, the URIs in the list define the protection space (see [RFC2617], Section 3.2.1) for some HTTP-style protocols 🔐 this attribute MUST only be used in Access-Challenge and Accounting-Request packets 💜

Type 🧚 119 for Digest-Domain

Length 📏 3

Text 💬 this attribute consists of a single URI that defines a protection space component 🦋

3.18. Digest-Stale Attribute 🫧

Description 🎀 a RADIUS server sends this attribute to tell the RADIUS client whether it has accepted a nonce 🙋‍♀️ if the nonce the RADIUS client presented was stale, the value is 'true', and it's 'false' otherwise 🌗 the RADIUS client puts the content of this attribute into a stale directive of the WWW-Authenticate header in the HTTP-style response to the request it wants to authenticate ✨ the attribute MUST only be used in Access-Challenge packets 💅

Type 🧚 120 for Digest-Stale

Length 📏 3

Text 💬 the attribute has either the value 'true' or 'false' (both values without surrounding quotes) 🎀

3.19. Digest-HA1 Attribute 🔑

Description 🎀 this attribute lets you generate an Authentication-Info header even when the HTTP-style response's body is required for the calculation of the rspauth value 🧠 it SHOULD be used in Access-Accept packets if the required quality of protection (qop) is 'auth-int' 🌟

This attribute MUST NOT be sent if the qop parameter was not specified or has a value of 'auth' (in this case, use Digest-Response-Auth instead). Bestie, read that twice 🙈

The Digest-HA1 Attribute MUST only be sent by the RADIUS server or processed by the RADIUS client if at least one of the following conditions is true 🧐

  • The Digest-Algorithm Attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
  • IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).

This attribute MUST only be used in Access-Accept packets 💅

Type 🧚 121 for Digest-HA1

Length 📏 >= 3

Text 💬 this attribute contains the hexadecimal representation of H(A1) as described in [RFC2617], Sections 3.1.3, 3.2.1, and 3.2.2.2 🥹✨

3.20. SIP-AOR Attribute ✨

Description

okay so this attribute is all about authorizing SIP messages 💅 The SIP-AOR Attribute identifies the URI whose use has to be authenticated and authorized 🔐 The RADIUS server uses it to decide whether the SIP request gets to be processed 🫶 The SIP-AOR can be derived from, for example, the To header field in a SIP REGISTER request (that's the user under registration 📞), or from the From header field in other SIP requests. ngl the exact mapping to SIP can shift as the protocol evolves, so stay alert 👀 This attribute MUST only be used when the RADIUS client wants to authorize SIP users, and it MUST only be used in Access-Request packets 🚫

Type

122 for SIP-AOR 🍓

Length

>= 3 🦋

Text

The syntax of this attribute corresponds either to a SIP URI (with the format defined in [RFC3261] or a tel URI (with the format defined in [RFC3966]).

The SIP-AOR Attribute holds the complete URI, including parameters and other parts 🌈 It's up to the RADIUS server to decide which components of the URI count in the authorization decision 🧚

4. Diameter Compatibility ✨

This document defines support for Digest Authentication in RADIUS 🎀 A companion document, "Diameter Session Initiation Protocol (SIP) Application" [RFC4740], defines support for Digest Authentication in Diameter, and it addresses compatibility issues between RADIUS and Diameter 💜

5. Table of Attributes 💅

The following table is your guide to which attributes can show up in which kinds of packets, and how many of each you can have 🌸

 Access- Access- Access- Access-    Acct-
 Request Accept  Reject  Challenge  Req   #  Attribute
  0-1      0      0      0          0-1   1  User-Name
  0-1      0      0      1          0    24  State [4]
  1        1      1      1          0-1  80  Message-Authenticator
  0-1      0      0      0          0   103  Digest-Response
  0-1      0      0      1          0-1 104  Digest-Realm
  0-1      0      0      1          0   105  Digest-Nonce
  0        0-1    0      0          0   106  Digest-Response-Auth [1][2]
  0        0-1    0      0          0   107  Digest-Nextnonce
  1        0      0      0          0-1 108  Digest-Method
  0-1      0      0      0          0-1 109  Digest-URI
  0-1      0      0      0+         0-1 110  Digest-Qop
  0-1      0      0      0-1        0-1 111  Digest-Algorithm [3]
  0-1      0      0      0          0   112  Digest-Entity-Body-Hash
  0-1      0      0      0          0   113  Digest-CNonce
  0-1      0      0      0          0   114  Digest-Nonce-Count
  0-1      0      0      0          0-1 115  Digest-Username
  0-1      0      0      0-1        0   116  Digest-Opaque
  0+       0+     0      0+         0+  117  Digest-Auth-Param
  0-1      0      0      0          0   118  Digest-AKA-Auts
  0        0      0      0+         0+  119  Digest-Domain
  0        0      0      0-1        0   120  Digest-Stale
  0        0-1    0      0          0   121  Digest-HA1 [1][2]
  0-1      0      0      0          0   122  SIP-AOR

Here's what the entries in that table mean 🧁

  0     This attribute MUST NOT be present in the packet.
  0+    Zero or more instances of this attribute MAY be
        present in the packet.
  0-1   Zero or one instance of this attribute MAY be
        present in the packet.

[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if Digest-Qop is 'auth-int'. 🫣

[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if Digest-Qop is 'auth'. 🙈

[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed. 🌷

[Note 4] An Access-Challenge MUST contain a State attribute, which is copied to the subsequent Access-Request. A server receiving an Access-Request that contains a State attribute MUST respond with either an Access-Accept or an Access-Reject; the server MUST NOT respond with an Access-Challenge. 🔁

6. Examples 🎀

This is an example pulled from the traffic between a softphone (A), a Proxy Server (B), and an example.com RADIUS server (C) 📱 The communication between the Proxy Server and a SIP Public Switched Telephone Network (PSTN) gateway is left out for brevity, and the SIP messages aren't shown in full 🙃

The password of user '12345678' is 'secret'. The shared secret between the RADIUS client and server is 'secret'. To make testing easier, only the last byte of the RADIUS authenticator changes between requests.

⚠️ bestie, in a real implementation, this would be a serious flaw. Don't copy this pattern. Ever. 💀

Here's the first exchange 👇

A->B

   INVITE sip:97226491335@example.com SIP/2.0
   From: <sip:12345678@example.com>
   To: <sip:97226491335@example.com>

B->A

   SIP/2.0 100 Trying

B->C

   Code = Access-Request (1)
   Packet identifier = 0x7c (124)
   Length = 97
   Authenticator = F5E55840E324AA49D216D9DBD069807C
   NAS-IP-Address = 192.0.2.38
   NAS-Port = 5
   User-Name = 12345678
   Digest-Method = INVITE
   Digest-URI = sip:97226491335@example.com
   Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B

C->B

   Code = Access-challenge (11)
   Packet identifier = 0x7c (124)
   Length = 72
   Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
   Digest-Nonce = 3bada1a0
   Digest-Realm = example.com
   Digest-Qop = auth
   Digest-Algorithm = MD5
   Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3

B->A

   SIP/2.0 407 Proxy Authentication Required
   Proxy-Authenticate: Digest realm="example.com"
        ,nonce="3bada1a0",qop=auth,algorithm=MD5
   Content-Length: 0

A->B

   ACK sip:97226491335@example.com SIP/2.0

A->B

   INVITE sip:97226491335@example.com SIP/2.0
   Proxy-Authorization: Digest nonce="3bada1a0"
        ,realm="example.com"
        ,response="756933f735fcd93f90a4bbdd5467f263"
        ,uri="sip:97226491335@example.com",username="12345678"
        ,qop=auth,algorithm=MD5
        ,cnonce="56593a80,nc="00000001"

   From: <sip:12345678@example.com>
   To: <sip:97226491335@example.com>

B->C

   Code = Access-Request (1)
   Packet identifier = 0x7d (125)
   Length = 221
   Authenticator = F5E55840E324AA49D216D9DBD069807D
   NAS-IP-Address = 192.0.2.38
   NAS-Port = 5
   User-Name = 12345678
   Digest-Method = INVITE
   Digest-URI = sip:97226491335@example.com
   Digest-Realm = example.com
   Digest-Qop = auth
   Digest-Algorithm = MD5
   Digest-CNonce = 56593a80
   Digest-Nonce = 3bada1a0
   Digest-Nonce-Count = 00000001
   Digest-Response = 756933f735fcd93f90a4bbdd5467f263
   Digest-Username = 12345678
   SIP-AOR = sip:12345678@example.com
   Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60

C->B

   Code = Access-Accept (2)
   Packet identifier = 0x7d (125)
   Length = 72
   Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2
   Digest-Response-Auth = f847de948d12285f8f4199e366f1af21
   Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E

B->A

   SIP/2.0 180 Ringing

B->A

   SIP/2.0 200 OK

A->B

   ACK sip:97226491335@example.com SIP/2.0

A second example shows the traffic between a web browser (A), a web server (B), and a RADIUS server (C) 🌐

A->B

   GET /index.html HTTP/1.1

B->C

   Code = Access-Request (1)
   Packet identifier = 0x7e (126)
   Length = 68
   Authenticator = F5E55840E324AA49D216D9DBD069807E
   NAS-IP-Address = 192.0.2.38
   NAS-Port = 5
   Digest-Method = GET
   Digest-URI = /index.html
   Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992

C->B

   Code = Access-challenge (11)
   Packet identifier = 0x7e (126)
   Length = 72
   Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
   Digest-Nonce = a3086ac8
   Digest-Realm = example.com
   Digest-Qop = auth
   Digest-Algorithm = MD5
   Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A

B->A

   HTTP/1.1 401 Authentication Required
   WWW-Authenticate: Digest realm="example.com",
       nonce="a3086ac8",qop=auth,algorithm=MD5
   Content-Length: 0

A->B

   GET /index.html HTTP/1.1
   Authorization: Digest = algorithm=MD5,qop=auth,nonce="a3086ac8"
        ,nc="00000001",cnonce="56593a80"
        ,realm="example.com"
        ,response="a4fac45c27a30f4f244c54a2e99fa117"
        ,uri="/index.html",username="12345678"

B->C

   Code = Access-Request (1)
   Packet identifier = 0x7f (127)
   Length = 176
   Authenticator = F5E55840E324AA49D216D9DBD069807F
   NAS-IP-Address = 192.0.2.38
   NAS-Port = 5
   User-Name = 12345678
   Digest-Method = GET
   Digest-URI = /index.html
   Digest-Realm = example.com
   Digest-Qop = auth
   Digest-Algorithm = MD5
   Digest-CNonce = 56593a80
   Digest-Nonce = a3086ac8
   Digest-Nonce-Count = 00000001
   Digest-Response = a4fac45c27a30f4f244c54a2e99fa117
   Digest-Username = 12345678
   Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821

C->B

   Code = Access-Accept (2)
   Packet identifier = 0x7f (127)
   Length = 72
   Authenticator = 6364FA6ED66012847C05A0895607C694
   Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147
   Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56

B->A

   HTTP/1.1 200 OK
   ...

   <html>
   ...

7. IANA Considerations 🌸

The following values from the RADIUS Attribute Types number space were assigned in [RFC4590]. This document requests that the values in the table below be entered within the existing registry 📋

Attribute               #
---------------        ----
Digest-Response         103
Digest-Realm            104
Digest-Nonce            105
Digest-Response-Auth    106
Digest-Nextnonce        107
Digest-Method           108
Digest-URI              109
Digest-Qop              110
Digest-Algorithm        111
Digest-Entity-Body-Hash 112
Digest-CNonce           113
Digest-Nonce-Count      114
Digest-Username         115
Digest-Opaque           116
Digest-Auth-Param       117
Digest-AKA-Auts         118
Digest-Domain           119
Digest-Stale            120
Digest-HA1              121
SIP-AOR                 122

8. Security Considerations 💀

The RADIUS extensions described in this document let RADIUS carry the data needed to perform a digest calculation 🔑 As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see [RFC2617], Section 4), on top of the RADIUS security vulnerabilities described in [RFC2865], Section 8, and [RFC3579], Section 4 😱

An attacker who compromises a RADIUS client or proxy can carry out man-in-the-middle attacks, even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec 🚨

The RADIUS server MUST check the Digest-Realm Attribute it has received from a client. If the RADIUS client isn't authorized to serve HTTP-style clients of that realm, it might be compromised 🫣

8.1. Denial of Service 🙈

okay so RADIUS clients using this extension can authenticate HTTP-style requests that come in over the Internet 🌐. compared to RADIUS handling link-layer network access, attackers may find it easier to cover their tracks in that setup 🕵️‍♀️

an attacker can try a denial-of-service attack on one or more RADIUS servers by sending a huge pile of HTTP-style requests 💀. to make the simple DoS stuff harder, the RADIUS server MUST check whether it generated the nonce it received from an HTTP-style client. this SHOULD be done statelessly ✨. for example, a nonce could be a cryptographically random part plus some kind of signature provided by the RADIUS client, as described in [RFC2617], Section 3.2.1 🔐.

8.2. Confidentiality and Data Integrity 🔐

the attributes in this document get sent in cleartext 🫣. RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. a man in the middle can modify or remove those attributes in a bidding down attack, which makes the RADIUS client use a weaker auth scheme than intended 😤.

the bidding down attack is the sneaky one. the MITM strips the good stuff so the client settles for something weaker. not it 💀

the Message-Authenticator Attribute, described in [RFC3579], Section 3.2, MUST be included in Access-Request, Access-Challenge, Access-Reject, and Access-Accept messages that contain attributes described in this specification 💅.

the Digest-HA1 Attribute contains no random components if the algorithm is 'MD5' or 'AKAv1-MD5'. this makes offline dictionary attacks easier and enables replay attacks 🥀.

some parameter combinations need RADIUS packets protected against eavesdropping and tampering 🛡️. implementations SHOULD try to figure out automatically whether IPsec is configured to protect traffic between the RADIUS client and the RADIUS server. if that's not possible, the implementation checks a configuration parameter telling it whether IPsec will protect RADIUS traffic. the default value of that parameter tells the implementation that RADIUS packets will not be protected 🙃.

HTTP-style clients can use TLS with server-side certificates together with HTTP-Digest Authentication. IPsec can be used instead of TLS, too. TLS or IPsec secures the connection, while Digest Authentication authenticates the user 🫶. the RADIUS transaction can be regarded as one leg on the path between the HTTP-style client and the HTTP-style server. so to stop RADIUS from being the weak link, a RADIUS client receiving an HTTP-style request via TLS or IPsec could use an equally secure connection to the RADIUS server 🔥. there are several ways to achieve this, for example:

  • The RADIUS client may reject HTTP-style requests received over TLS or IPsec.
  • The RADIUS client may require that traffic be sent and received over IPsec.

RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579], Section 4.2 🌸.

9. References ✨

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.

[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.

9.2. Informative References

[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.

[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 4590, July 2006.

[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006.

Appendix A - Changes from RFC 4590 🎀

this Appendix lists the major changes between [RFC4590] and this document. minor stuff like style, grammar, spelling, and editorial changes isn't mentioned here 🌈.

  • The Table of Attributes (Section 5) now indicates that the Digest-Method Attribute is required within an Access-Request. an entry was also added for the State attribute. the table includes entries for Accounting-Request messages too. as noted in the examples, the User-Name Attribute is not necessary when requesting a nonce 💖.
  • Two errors in attribute assignment were corrected within the IANA Considerations (Section 7). Digest-Response-Auth is assigned attribute 106, and Digest-Nextnonce is assigned attribute 107 🔥.
  • Several errors in the examples section were corrected 🧚.

Acknowledgments 🫶

the authors would like to thank Mike McCauley for his help in working through the details of the examples 💜.

we would like to acknowledge Kevin McDermott (Cisco Systems) for providing comments and experimental implementation 👑.

many thanks to all reviewers, especially to Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang ⭐.

Authors' Addresses 🦋

Baruch Sterman
Kayote Networks
P.O. Box 1373
Efrat  90435
Israel

EMail: baruch@kayote.com
Daniel Sadolevsky
SecureOL, Inc.
Jerusalem Technology Park
P.O. Box 16120
Jerusalem  91160
Israel

EMail: dscreat@dscreat.com
David Schwartz
Kayote Networks
P.O. Box 1373
Efrat  90435
Israel

EMail: david@kayote.com
David Williams
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
Research Triangle Park  NC 27709
USA

EMail: dwilli@cisco.com
Wolfgang Beck
Deutsche Telekom AG
Deutsche Telekom Allee 7
Darmstadt  64295
Germany

EMail: beckw@t-systems.com

Copyright (C) The IETF Trust (2008).

this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 📜.

this document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅.

Intellectual Property 🌸

the IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. nor does it represent that it has made any independent effort to identify any such rights. information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 🦋.

copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔍.

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. please address the information to the IETF at ietf-ipr@ietf.org 💌✨.

📦 where this page comes from