RFC 4590
RADIUS Extension for Digest Authentication
RFC 4590: RADIUS Extension for Digest Authentication 💖
okay bestie, this one is about getting Digest Authentication to work with RADIUS, the AAA protocol that handles who gets access to a network 🔐. It's a Standards Track document, which means it's an actual Internet standard and not just vibes. 🫶
The paper trail: B. Sterman (Kayote Networks), D. Sadolevsky (SecureOL, Inc.), D. Schwartz (Kayote Networks), D. Williams (Cisco Systems), and W. Beck (Deutsche Telekom AG) wrote it. It's dated July 2006 and it's published in the Network Working Group stream 🎀. The title block doesn't list anything that this RFC obsoletes or updates, so there's no drama there. ✨
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and 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, so share it with everyone 💅.
Copyright Notice ©️
Copyright (C) The Internet Society (2006). 🧚
Abstract 🦋
This document extends the Remote Authentication Dial-In User Service (RADIUS) protocol so it can support Digest Authentication 🔥. The point is to make it work for HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP 💜.
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Motivation .................................................3
1.3. Overview ...................................................4
2. Detailed Description ............................................6
2.1. RADIUS Client Behavior .....................................6
2.1.1. Credential Selection ................................6
2.1.2. Constructing an Access-Request ......................6
2.1.3. Constructing an Authentication-Info Header ..........7
2.1.4. Failed Authentication ...............................8
2.1.5. Obtaining Nonces ....................................9
2.2. RADIUS Server Behavior .....................................9
2.2.1. General Attribute Checks ............................9
2.2.2. Authentication .....................................10
2.2.3. Constructing the Reply .............................11
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 ...................................14
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 ............................................22
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................27
8.1. Denial of Service .........................................28
8.2. Confidentiality and Data Integrity ........................28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................301. Introduction ✨
1.1. 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]. Those are the official requirement words, so they carry real weight 💅.
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, nothing here is binding on it 🙈.
Here are the terms you need to know:
- HTTP-style protocol: The term 'HTTP-style' means 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, which is 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. It's giving "I can recognize you without remembering you" 🧠✨.
- protection space: HTTP-style protocols differ in how they define the protection space. For HTTP, it's the combination of realm and canonical root URL of the requested resource for which the use is authorized by the RADIUS server. For SIP, the realm string alone defines the protection space. Different vibes for different protocols 🦋.
- 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.2. Motivation 🌟
The HTTP Digest Authentication mechanism, defined in [RFC2617], was later adapted for use with SIP [RFC3261]. It has limitations and weaknesses (see [RFC2617], section 4), so additional authentication and encryption mechanisms are defined in SIP [RFC3261], including Transport Layer Security (TLS) [RFC4346] and Secure MIME (S/MIME) [RFC3851]. 🔒 However, Digest Authentication support is mandatory in SIP implementations, and Digest Authentication is the preferred way for a SIP UA to authenticate itself to a proxy server. Digest Authentication is used in other protocols as well, so it's kind of everywhere 👑.
To simplify the provisioning of users, there is a need to support this authentication mechanism within Authentication, Authorization, and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter [RFC3588]. That's the whole reason this extension exists: making user setup way less of a headache 🧚.
This document defines an extension to the RADIUS protocol to enable support of Digest Authentication for use with SIP, HTTP, and other HTTP-style protocols using this authentication method. 💜 Support for Digest mechanisms such as Authentication and Key Agreement (AKA) [RFC3310] is also supported. A companion document [SIP-APP] defines support for Digest Authentication within Diameter, so Diameter gets its own glow-up too 🫶.
Part 1 of 6 💖 Part 2 picks up with Section 1.3 (Overview) and the Detailed Description, so stay tuned bestie 🦋
1.3. Overview ✨
okay so HTTP Digest is a challenge-response protocol 🔐 that a server uses to check a client's request before it hands over a resource. Figure 1 shows one full Digest transaction, bestie 💅
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+Figure 1: Digest operation without RADIUS
so like, if the client sends a request with no credentials (1), the server bounces back an error response (2) with 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 re-sends the request (3), but now the digest is inside the packet ✨. The server runs the same digest calculation and compares its result with the digest it got in (3). If they're identical, access is granted and a positive response goes back (4) 🎀. If they differ, the server sends a negative response (4) 💀.
Instead of keeping its own local user database, the server could ask RADIUS to hit up a centralized one 🧚. BUT 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 from [RFC1994] are also a no, because the CHAP algorithm isn't compatible with HTTP Digest.
This document defines new attributes so the RADIUS server can do the digest calculation from [RFC2617] itself 👑. That makes Digest Authentication a native authentication mechanism within RADIUS, which is iconic.
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 brings security and operational issues 😬. Some digest algorithms, e.g., AKA [RFC3310], would not work at all.
Figure 2 depicts a scenario where the HTTP-style server defers authentication to a RADIUS server. Entities A and B talk over HTTP or SIP, while entities B and C talk over RADIUS 🦋.
HTTP/SIP RADIUS
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUSFigure 2: HTTP Digest over RADIUS
The entities have the following 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 how the messages flow in this scenario 🎬:
- (1) A sends B an HTTP/SIP request without an authorization header.
- (2) B sends an Access-Request packet to the RADIUS server, C, with the newly defined
Digest-MethodandDigest-URIattributes but without aDigest-Nonceattribute. - (3) C chooses a nonce and responds with an Access-Challenge. This Access-Challenge contains Digest attributes, and B takes values from them to build an HTTP/SIP "(Proxy) Authorization required" response.
- (4) B sends this response to A.
- (5) A resends its request with its credentials.
- (6) B sends an Access-Request to C.
- (7) C checks the credentials and replies with Access-Accept or Access-Reject.
- (8) Depending on C's result, B either processes A's request or rejects it with a "(Proxy) Authorization required" response.
2. Detailed Description ✨
2.1. RADIUS Client Behavior
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 the HTTP-style clients meant to keep 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's authorized to authenticate the request 🛂. If an HTTP-style request goes through several proxies and each one 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. If 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 from 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, and 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 syntactic requirements, HTTP-style protocols have to escape all quote and backslash characters in the contents of HTTP Digest directives with a backslash 🙃. When translating directives into RADIUS attributes, the RADIUS client only removes the surrounding quotes where they're present. 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 then 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 it has received an Access-Accept from the RADIUS server, the RADIUS client constructs an Authentication-Info header 🧩:
- If the Access-Accept packet contains a
Digest-Response-Authattribute, the RADIUS client checks theDigest-Qopattribute:- If the
Digest-Qopattribute's value isauthor not specified, the RADIUS client puts theDigest-Response-Authattribute's content into the Authentication-Info header'srspauthdirective of the HTTP-style response. - If the
Digest-Qopattribute's value isauth-int, the RADIUS client ignores the Access-Accept packet and behaves as if it had received an Access-Reject packet (Digest-Response-Authcan't be correct, since the RADIUS server doesn't know the contents of the HTTP-style response's body 🙅).
- If the
- If the Access-Accept packet contains a
Digest-HA1attribute, the RADIUS client checks theqopandalgorithmdirectives in the Authorization header of the HTTP-style request it wants to authorize:- If the
qopdirective is missing or its value isauth, the RADIUS client ignores theDigest-HA1attribute. It does not include an Authentication-Info header in its HTTP-style response. - If the
qopdirective's value isauth-intand at least one of the following conditions is true, the RADIUS client calculates the contents of the HTTP-style response'srspauthdirective ✨:- The
algorithmdirective's value isMD5-sessorAKAv1-MD5-sess. - IP Security (IPsec) is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8) 🛡️.
- The
- If the
It 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. Then it takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and Digest-Qop values of the corresponding Access-Request, plus the Digest-HA1 attribute's value, to finish computing the rspauth value 🎀.
- If the Access-Accept packet contains neither a
Digest-Response-Authnor aDigest-HA1attribute, 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 the HTTP-style response 💌.
2.1.4. Failed Authentication
If the RADIUS client received an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it gets 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 directive stale 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 received 🚫. If the RADIUS client doesn't receive a response at all, it retransmits or fails over to another RADIUS server, as described in [RFC2865] 🔁. that's the whole vibe, bestie 🫶
2.1.5. Obtaining Nonces 🎀
okay so the RADIUS client has two ways to get a nonce 🧚 it can either have one already from a Digest-Nextnonce attribute in an Access-Accept it got earlier, or it can just ask the RADIUS server for a fresh one 💅 to ask, it sends an Access-Request that has a Digest-Method and a Digest-URI attribute but NO Digest-Nonce attribute. it also tacks on a Message-Authenticator attribute (see [RFC3579]) to that Access-Request packet. then the RADIUS server picks a nonce and replies with an Access-Challenge that has a Digest-Nonce attribute in it 🦋
the RADIUS client then builds a (Proxy-)Authenticate header using the Digest-Nonce and Digest-Realm attributes it got, which fill in the nonce and realm directives. the RADIUS server is also allowed to send Digest-Qop, Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in that Access-Challenge carrying the nonce ✨ if any of those are there, the client MUST use them. no exceptions bestie 😭
2.2. RADIUS Server Behavior 👑
so if the RADIUS server gets an Access-Request with a Digest-Method and a Digest-URI but no Digest-Nonce, it picks a nonce 🌸 it puts that nonce in 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]) to that Access-Challenge. it SHOULD add Digest-Algorithm and one or more Digest-Qop, and it MAY add Digest-Domain or Digest-Opaque attributes too 💖
2.2.1. General Attribute Checks 🔥
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's inside Digest-Algorithm and Digest-Qop, it also looks for Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts 🧐 see [RFC2617] and [RFC3310] for the full details. 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. 🔒
if mandatory attributes are missing, the server MUST respond with an Access-Reject packet. 🚫
the RADIUS server takes \ characters that escape quote and \ characters OUT of 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 📝 and it MAY take extra action, like sending an Access-Reject for every future request from that client, until a management action resets this behavior. kinda intense but valid 💀
the RADIUS server figures out how old the nonce in Digest-Nonce is, either by reading an embedded time-stamp or by looking it up in a local table ⏰ if the nonce embeds the time-stamp, the server MUST check the integrity of the nonce. section 2.2.2 explains how the server handles old nonces 🦋
2.2.2. Authentication 🌈
if the Access-Request has passed the checks above, the RADIUS server works out the digest response the way [RFC2617] describes ✨ to look up the password, it uses the RADIUS User-Name attribute. the RADIUS server MUST check that the user identified by the User-Name attribute:
- is authorized to access the protection space, and
- is authorized to use the URI in the SIP-AOR attribute, if that attribute is present.
if any of those checks fails, the RADIUS server MUST send an Access-Reject. 🙅♀️
the correlation between the User-Name and SIP-AOR AVP values is required, just so nobody can register or misuse a SIP-AOR that belongs to someone else. protecting the main character 👑
all the values needed for the digest calculation come from the Digest attributes in this document. if the calculated digest response matches the value in the Digest-Response attribute, the authentication worked 🎉
if the response values match but the RADIUS server thinks the nonce in Digest-Nonce is too old, it sends an Access-Challenge with a new nonce and a Digest-Stale attribute set to 'true' (without surrounding quotes) 🫠
if the response values don't match, the RADIUS server replies with an Access-Reject. nope 🙅♀️
2.2.3. Constructing the Reply 💅
if the authentication was successful, the RADIUS server adds an attribute to the Access-Accept packet that the RADIUS client can use 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 conditions 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. 🛑
the RADIUS server MAY construct a Digest-Nextnonce attribute and add it to the Access-Accept packet 🍓 this helps limit how long a nonce lives and saves a round-trip on future requests (see the nextnonce discussion in [RFC2617], section 3.2.3). the RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) and then sends the Access-Accept packet to the RADIUS client 🧚
if the RADIUS server doesn't accept the nonce in an Access-Request but the authentication was successful anyway, 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-Qop, and it MAY add Digest-Domain and Digest-Opaque attributes to that Access-Challenge packet. ✨
3. New RADIUS Attributes 🦋
if nothing says otherwise, the attributes all use this format:
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, because they're just syntax delimiters and they're redundant in RADIUS. for example, the directive
realm="the \"example\" value"looks like this in RADIUS:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest-Realm | 23 | the \"example\" value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1. Digest-Response attribute 🔥
Description
if this attribute is in an Access-Request, a RADIUS server that implements this spec MUST treat that 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-Requests. 🙅♀️
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 the 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 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 don't all define protection space the same way, so see [RFC2617], Section 1.2, for details. it MUST only be used in Access-Request and Access-Challenge packets. ✨
Type
104 for Digest-Realm
Length
=3
Text
in Access-Requests, the RADIUS client takes the realm directive's value (the 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 nonce directive's value (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 picked 🫠
3.4. Digest-Response-Auth Attribute 👑
Description
this attribute lets the RADIUS server prove it knows the password 🔑 if the Digest-Qop attribute it got earlier 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 there, 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
this attribute holds the method value to be used in the HTTP Digest calculation 💜 this attribute MUST only be used in Access-Request packets.
Type
108 for Digest-Method
Length
=3
Text
in Access-Requests, the RADIUS client takes the request method's value from the HTTP-style request it wants to authenticate 🌸
3.7. Digest-URI Attribute 🦋
Description
Okay so this attribute carries either the contents of the digest-uri directive or the URI of the HTTP-style request. It MUST only be used in Access-Request packets. Bestie, that MUST is doing a lot 💅
Type
109 for Digest-URI 🎀
Length
>=3
Text
If the HTTP-style request has an Authorization header, the RADIUS client puts 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 the surrounding quotes. If there's no Authorization header, the RADIUS client grabs the request URI from the HTTP-style request it wants to authenticate instead 🧚
3.8. Digest-Qop Attribute 🌸
Description
This attribute holds the Quality of Protection parameter that influences the HTTP Digest calculation, and it's giving main character energy. It MUST only be used in Access-Request and Access-Challenge packets. A RADIUS client SHOULD insert the Digest-Qop attributes it received in an earlier 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 its own 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 and Access-Challenge packets. If this attribute is missing, MD5 is assumed, so no stress 🙈
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 this one is iconic. When using the qop-level 'auth-int', a hash of the HTTP-style message body's contents is required for the digest calculation. Instead of sending the whole body, only its hash value gets sent, and that hash can be used directly in the digest calculation. Lowkey genius ngl 🧠
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 that is 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 attribute includes the nonce count parameter, which is used to detect replay attacks. The attribute MUST only be used in Access-Request packets. Replay attacks are not it 🙅♀️
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 the purposes of calculating the digest. To figure out the appropriate 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 packets. Keep those two straight, bestie, it matters a lot 🔥
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 attribute holds the opaque parameter that gets passed to the HTTP-style client. The HTTP-style client passes this value back to the server (i.e., the RADIUS client) without modification, which is so iconic. 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 the mechanism whereby the RADIUS client and RADIUS server can exchange auth-param extension parameters contained within Digest headers that the RADIUS client doesn't understand and that have no matching stand-alone attributes. It's giving future-proof 🔮
Unlike the Digest-* attributes listed before, the Digest-Auth-Param contains not only the value but also the parameter name, since the RADIUS client doesn't know the name. If the Digest header contains 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, or Access-Accept 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 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
This attribute is sent by a RADIUS server 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 the generation of an Authentication-Info header happen even when the HTTP-style response's body is needed 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). 🙈
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 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 💖 This attribute is for authorizing SIP messages, bestie 🫶. SIP-AOR names the URI whose use has to be authenticated and authorized, and the RADIUS server looks at it to decide whether to process the SIP request 💅. You can pull it from the To header in a SIP REGISTER request (the user being registered), or from the From header in other SIP requests. The exact mapping can shift as the protocol evolves, so don't lock it in forever 🦋. And the big rule: 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 🍓 The number is 122 for SIP-AOR.
Length 🎀 It's >=3.
Text 🌈 The syntax is either a SIP URI (format defined in [RFC3261]) or a tel URI (format defined in [RFC3966]). The attribute holds the complete URI, parameters and all the other bits. It's totally up to the RADIUS server which parts 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" [SIP-APP] defines support for Digest Authentication in Diameter, and addresses compatibility issues between RADIUS and Diameter 🌸.
5. Table of Attributes 🌸
The following table gives you the tea on which attributes can show up in which kinds of packets, and how many of each 💅.
+-----+--------+--------+-----------+-----+-------------------------+
| Req | Accept | Reject | Challenge | # | Attribute |
+-----+--------+--------+-----------+-----+-------------------------+
| 1 | 0 | 0 | 0 | 1 | User-Name |
| 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
| 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
| 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
| 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
| 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
| | | | | | (see Note 1, 2) |
| 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
| 0-1 | 0 | 0 | 0 | 108 | Digest-Method |
| 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
| 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
| 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
| | | | | | Note 3) |
| 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
| 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
| 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
| 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
| 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
| 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
| 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
| 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
| 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
| 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
| | | | | | 2) |
| 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
+-----+--------+--------+-----------+-----+-------------------------+Table 1
[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. 🧚
6. Examples 🧚
This is an example selected 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 💖.
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 = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Message-Authenticator =
08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43 C->B
Code = 11 (Access-Challenge)
Attributes:
Digest-Nonce = 3bada1a0
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 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 algorithm="md5",nonce="3bada1a0"
,realm="example.com"
,response="f3ce87e6984557cd0fecc26f3c5e97a4"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com> B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
Digest-Realm = example.com
Digest-Nonce = 3bada1a0
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Qop = auth
Digest-Algorithm = md5
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator =
ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff C->B
Code = 2 (Access-Accept)
Attributes:
Digest-Response-Auth =
6303c41b0e2c3e524e413cafe8cce954
Message-Authenticator =
75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1 B->A
SIP/2.0 180 Ringing B->A
SIP/2.0 200 OK A->B
ACK sip:97226491335@example.com SIP/2.0A 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 = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
Digest-Method = GET
Digest-URI = /index.html
Message-Authenticator =
34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7 C->B
Code = 11 (Access-Challenge)
Attributes:
Digest-Nonce = a3086ac8
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40 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,nonce="a3086ac8"
,realm="example.com"
,response="f052b68058b2987aba493857ae1ab002"
,uri="/index.html",username="12345678"
,qop=auth,algorithm=MD5 B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f052b68058b2987aba493857ae1ab002
Digest-Realm = example.com
Digest-Nonce = a3086ac8
Digest-Method = GET
Digest-URI = /index.html
Digest-Username = 12345678
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b C->B
Code = 2 (Access-Accept)
Attributes:
Digest-Response-Auth =
e644aa513effbfe1caff67103ff6433c
Message-Authenticator =
7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7 B->A
HTTP/1.1 200 OK
...
<html>
...7. IANA Considerations 🦋
This document serves as an IANA registration request for a number of values from the RADIUS attribute type number space 💜. The IANA has assigned the following:
+-------------------------+------------------------+
| placeholder | value assigned by IANA |
+-------------------------+------------------------+
| Digest-Response | 103 |
| Digest-Realm | 104 |
| Digest-Nonce | 105 |
| Digest-Nextnonce | 106 |
| Digest-Response-Auth | 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 |
+-------------------------+------------------------+Table 2
8. Security Considerations 🔥
The RADIUS extensions described in this document let RADIUS carry the data needed to do a digest calculation 🔐. That means 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 that use this extension can authenticate HTTP-style requests that come in over the Internet 🌐. compared to using RADIUS for link-layer network access, attackers may find it way easier to cover their tracks here 🕵️♀️ not me being dramatic lol
an attacker can try a denial-of-service attack on one or more RADIUS servers by flooding them with a huge pile of HTTP-style requests 😭 to make the simple versions of this harder to pull off, the RADIUS server MUST check whether it actually generated the nonce it got back from an HTTP-style client 🛡️ this SHOULD be done statelessly ✨ for example, a nonce could be made of a cryptographically random part plus some kind of signature from the RADIUS client, like the way it's described in [RFC2617], section 3.2.1 💖
8.2. Confidentiality and Data Integrity 🔐
ok this part is kind of a big deal, so listen up 👂 the attributes in this document get sent in cleartext 🙈 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages 🎀 and here's the problem: a man in the middle can change or strip those attributes in a bidding down attack 😱 which tricks the RADIUS client into using a weaker authentication scheme than what was intended 💀
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 🧚 no skipping this one bestie
the Digest-HA1 attribute has no random components when the algorithm is 'MD5' or 'AKAv1-MD5' 🙃 which makes offline dictionary attacks easier and opens the door to replay attacks 🚪 unhinged behavior from this attribute, ngl
some parameter combinations need RADIUS packets protected against eavesdropping and tampering 🛡️ implementations SHOULD try to figure out automatically whether IPsec is set up to protect traffic between the RADIUS client and the RADIUS server 🔍 if that's not possible, the implementation checks a configuration parameter that tells it whether IPsec will protect RADIUS traffic 📋 and the default value of that parameter says RADIUS packets will not be protected, so you have to opt in 🙌
HTTP-style clients can use TLS with server-side certificates together with HTTP-Digest Authentication 🎀 IPsec works too, if you'd rather 🫶 TLS or IPsec secure the connection, while Digest Authentication authenticates the user 👑 the RADIUS transaction counts as one leg on the path between the HTTP-style client and the HTTP-style server 🛤️ so to keep RADIUS from being the weak link, a RADIUS client that gets an HTTP-style request over TLS or IPsec could use an equally secure connection to the RADIUS server 🔒 there are a few ways to do 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. ⚠️ this one is non-negotiable, bestie
9. Acknowledgements 🫶
we want to give a shoutout to Kevin McDermott (Cisco Systems) for providing comments and an experimental implementation 🙌
thank you SO much to all the reviewers, especially Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang 💜 you're all iconic ✨
10. References 📚
10.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.10.2. Informative References
[SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol
(SIP) Application", Work in Progress), April 2006.
[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.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[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.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.comFull Copyright Statement ©️
the Internet Society owns the copyright for this one, (C) 2006 🌸 this document is subject to the rights, licenses and restrictions in BCP 78, and apart from what's set out there, the authors keep all their rights 💅
this doc and the info in it get provided "AS IS" 🫠 and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this document are valid or how far they reach 🤷♀️ it also doesn't say whether a license for those rights is available, and it hasn't independently gone looking for any of them 🔍 info about how rights work for RFC documents is in BCP 78 and BCP 79 📖
copies of IPR disclosures sent to the IETF Secretariat, any promises of licenses, or the results of trying to get a general license or permission to use those proprietary rights for implementing or using this spec can be found in the IETF online IPR repository at http://www.ietf.org/ipr 💼
the IETF also invites anyone interested to point out any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard ✨ send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌈
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖
📦 where this page comes from
- ietf: rfc4590 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms