7 Network Working Group B. Sterman
8 Request for Comments: 5090 Kayote Networks
9 Obsoletes: 4590 D. Sadolevsky
10 Category: Standards Track SecureOL, Inc.
20 RADIUS Extension for Digest Authentication
24 This document specifies an Internet standards track protocol for the
25 Internet community, and requests discussion and suggestions for
26 improvements. Please refer to the current edition of the "Internet
27 Official Protocol Standards" (STD 1) for the standardization state
28 and status of this protocol. Distribution of this memo is unlimited.
32 This document defines an extension to the Remote Authentication
33 Dial-In User Service (RADIUS) protocol to enable support of Digest
34 Authentication, for use with HTTP-style protocols like the Session
35 Initiation Protocol (SIP) and HTTP.
58 Sterman, et al. Standards Track [Page 1]
60 RFC 5090 RADIUS Extension Digest Authentication February 2008
65 1. Introduction ....................................................3
66 1.1. Motivation .................................................3
67 1.2. Terminology ................................................3
68 1.3. Overview ...................................................4
69 2. Detailed Description ............................................6
70 2.1. RADIUS Client Behavior .....................................6
71 2.2. RADIUS Server Behavior .....................................9
72 3. New RADIUS Attributes ..........................................12
73 3.1. Digest-Response Attribute .................................12
74 3.2. Digest-Realm Attribute ....................................13
75 3.3. Digest-Nonce Attribute ....................................13
76 3.4. Digest-Response-Auth Attribute ............................14
77 3.5. Digest-Nextnonce Attribute ................................14
78 3.6. Digest-Method Attribute ...................................15
79 3.7. Digest-URI Attribute ......................................15
80 3.8. Digest-Qop Attribute ......................................15
81 3.9. Digest-Algorithm Attribute ................................16
82 3.10. Digest-Entity-Body-Hash Attribute ........................16
83 3.11. Digest-CNonce Attribute ..................................17
84 3.12. Digest-Nonce-Count Attribute .............................17
85 3.13. Digest-Username Attribute ................................17
86 3.14. Digest-Opaque Attribute ..................................18
87 3.15. Digest-Auth-Param Attribute ..............................18
88 3.16. Digest-AKA-Auts Attribute ................................19
89 3.17. Digest-Domain Attribute ..................................19
90 3.18. Digest-Stale Attribute ...................................20
91 3.19. Digest-HA1 Attribute .....................................20
92 3.20. SIP-AOR Attribute ........................................21
93 4. Diameter Compatibility .........................................21
94 5. Table of Attributes ............................................21
95 6. Examples .......................................................23
96 7. IANA Considerations ............................................27
97 8. Security Considerations ........................................28
98 8.1. Denial of Service .........................................28
99 8.2. Confidentiality and Data Integrity ........................28
100 9. References .....................................................29
101 9.1. Normative References ......................................29
102 9.2. Informative References ....................................30
103 Appendix A - Changes from RFC 4590 ................................31
104 Acknowledgements ..................................................31
114 Sterman, et al. Standards Track [Page 2]
116 RFC 5090 RADIUS Extension Digest Authentication February 2008
123 The HTTP Digest Authentication mechanism, defined in [RFC2617], was
124 subsequently adapted for use with SIP [RFC3261]. Due to the
125 limitations and weaknesses of Digest Authentication (see [RFC2617],
126 Section 4), additional authentication and encryption mechanisms are
127 defined in SIP [RFC3261], including Transport Layer Security (TLS)
128 [RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest
129 Authentication support is mandatory in SIP implementations, and
130 Digest Authentication is the preferred way for a SIP UA to
131 authenticate itself to a proxy server. Digest Authentication is used
132 in other protocols as well.
134 To simplify the provisioning of users, there is a need to support
135 this authentication mechanism within Authentication, Authorization,
136 and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
139 This document defines an extension to the RADIUS protocol to enable
140 support of Digest Authentication for use with SIP, HTTP, and other
141 HTTP-style protocols using this authentication method. Support for
142 Digest mechanisms such as Authentication and Key Agreement (AKA)
143 [RFC3310] is also supported. A companion document [RFC4740] defines
144 support for Digest Authentication within Diameter.
148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
150 document are to be interpreted as described in [RFC2119].
152 The use of normative requirement key words in this document shall
153 apply only to RADIUS client and RADIUS server implementations that
154 include the features described in this document. This document
155 creates no normative requirements for existing implementations.
158 The term "HTTP-style" denotes any protocol that uses HTTP-like
159 headers and uses HTTP Digest Authentication as described in
160 [RFC2617]. Examples are HTTP and the Session Initiation Protocol
163 NAS (Network Access Server)
170 Sterman, et al. Standards Track [Page 3]
172 RFC 5090 RADIUS Extension Digest Authentication February 2008
176 An unpredictable value used to prevent replay attacks. The nonce
177 generator may use cryptographic mechanisms to produce nonces it
178 can recognize without maintaining state.
181 HTTP-style protocols differ in their definition of the protection
182 space. For HTTP, it is defined as the combination of the realm
183 and canonical root URL of the requested resource for which the use
184 is authorized by the RADIUS server. In the case of SIP, the realm
185 string alone defines the protection space.
187 SIP UA (SIP User Agent)
188 An Internet endpoint that uses the Session Initiation Protocol.
190 SIP UAS (SIP User Agent Server)
191 A logical entity that generates a response to a SIP (Session
192 Initiation Protocol) request.
196 HTTP Digest is a challenge-response protocol used to authenticate a
197 client's request to access some resource on a server. Figure 1 shows
198 a single HTTP Digest transaction.
201 +------------+ (1) +------------+
203 | HTTP-style | (2) | HTTP-style |
204 | client |<---------| server |
209 +------------+ +------------+
211 Figure 1: Digest Operation without RADIUS
213 If the client sends a request without any credentials (1), the server
214 will reply with an error response (2) containing a nonce. The client
215 creates a cryptographic digest from parts of the request, from the
216 nonce it received from the server, and from a shared secret. The
217 client retransmits the request (3) to the server, but now includes
218 the digest within the packet. The server does the same digest
219 calculation as the client and compares the result with the digest it
220 received in (3). If the digest values are identical, the server
221 grants access to the resource and sends a positive response to the
226 Sterman, et al. Standards Track [Page 4]
228 RFC 5090 RADIUS Extension Digest Authentication February 2008
231 client (4). If the digest values differ, the server sends a negative
232 response to the client (4).
234 Instead of maintaining a local user database, the server could use
235 RADIUS to access a centralized user database. However, RADIUS
236 [RFC2865] does not include support for HTTP Digest Authentication.
237 The RADIUS client cannot use the User-Password Attribute, since it
238 does not receive a password from the HTTP-style client. The CHAP-
239 Challenge and CHAP-Password attributes described in [RFC1994] are
240 also not suitable since the Challenge Handshake Authentication
241 Protocol (CHAP) algorithm is not compatible with HTTP Digest.
243 This document defines new attributes that enable the RADIUS server to
244 perform the digest calculation defined in [RFC2617], providing
245 support for Digest Authentication as a native authentication
246 mechanism within RADIUS.
248 The nonces required by the digest algorithm are generated by the
249 RADIUS server. Generating them in the RADIUS client would save a
250 round-trip, but introduce security and operational issues. Some
251 digest algorithms -- e.g., AKA [RFC3310] -- would not work.
253 Figure 2 depicts a scenario in which the HTTP-style server defers
254 authentication to a RADIUS server. Entities A and B communicate
255 using HTTP or SIP, while entities B and C communicate using RADIUS.
259 +-----+ (1) +-----+ +-----+
260 | |==========>| | (2) | |
261 | | | |---------->| |
263 | | (4) | |<----------| |
264 | |<==========| | | |
266 | |==========>| | | |
267 | A | | B | (6) | C |
268 | | | |---------->| |
270 | | | |<----------| |
272 | |<==========| | | |
273 +-----+ +-----+ +-----+
278 Figure 2: HTTP Digest over RADIUS
282 Sterman, et al. Standards Track [Page 5]
284 RFC 5090 RADIUS Extension Digest Authentication February 2008
287 The entities have the following roles:
289 A: HTTP client / SIP UA
291 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
292 acting also as a RADIUS NAS
296 The following messages are sent in this scenario:
298 A sends B an HTTP/SIP request without an Authorization header (step
299 1). B sends an Access-Request packet with the newly defined Digest-
300 Method and Digest-URI attributes but without a Digest-Nonce Attribute
301 to the RADIUS server, C (step 2). C chooses a nonce and responds
302 with an Access-Challenge (step 3). This Access-Challenge contains
303 Digest attributes, from which B takes values to construct an HTTP/SIP
304 "(Proxy) Authorization required" response. B sends this response to
305 A (step 4). A resends its request with its credentials (step 5). B
306 sends an Access-Request to C (step 6). C checks the credentials and
307 replies with Access-Accept or Access-Reject (step 7). Depending on
308 C's result, B processes A's request or rejects it with a "(Proxy)
309 Authorization required" response (step 8).
311 2. Detailed Description
313 2.1. RADIUS Client Behavior
315 The attributes described in this document are sent in cleartext.
316 Therefore, were a RADIUS client to accept secure connections (HTTPS
317 or SIPS) from HTTP-style clients, this could result in information
318 intentionally protected by HTTP-style clients being sent in the clear
319 during RADIUS exchange.
321 2.1.1. Credential Selection
323 On reception of an HTTP-style request message, the RADIUS client
324 checks whether it is authorized to authenticate the request. Where
325 an HTTP-style request traverses several proxies, and each of the
326 proxies requests to authenticate the HTTP-style client, the request
327 at the HTTP-style server may contain multiple credential sets.
329 The RADIUS client can use the realm directive in HTTP to determine
330 which credentials are applicable. Where none of the realms are of
331 interest, the RADIUS client MUST behave as though no relevant
332 credentials were sent. In all situations, the RADIUS client MUST
333 send zero or exactly one credential to the RADIUS server. The RADIUS
338 Sterman, et al. Standards Track [Page 6]
340 RFC 5090 RADIUS Extension Digest Authentication February 2008
343 client MUST choose the credential of the (Proxy-)Authorization header
344 if the realm directive matches its locally configured realm.
346 2.1.2. Constructing an Access-Request
348 If a matching (Proxy-)Authorization header is present and contains
349 HTTP Digest information, the RADIUS client checks the nonce
352 If the RADIUS client recognizes the nonce, it takes the header
353 directives and puts them into a RADIUS Access-Request packet. It
354 puts the response directive into a Digest-Response Attribute and the
355 realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, and
356 opaque directives into the respective Digest-Realm, Digest-Nonce,
357 Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest-
358 Nonce-Count, Digest-Username, and Digest-Opaque attributes. The
359 RADIUS client puts the request method into the Digest-Method
362 Due to HTTP syntactic requirements, quoted strings found in HTTP
363 Digest directives may contain escaped quote and backslash characters.
364 When translating these directives into RADIUS attributes, the RADIUS
365 client only removes the leading and trailing quote characters which
366 surround the directive value, it does not unescape anything within
367 the string. See Section 3 for an example.
369 If the Quality of Protection (qop) directive's value is 'auth-int',
370 the RADIUS client calculates H(entity-body) as described in
371 [RFC2617], Section 3.2.1, and puts the result in a Digest-Entity-
374 The RADIUS client adds a Message-Authenticator Attribute, defined in
375 [RFC3579], and sends the Access-Request packet to the RADIUS server.
377 The RADIUS server processes the packet and responds with an Access-
378 Accept or an Access-Reject.
380 2.1.3. Constructing an Authentication-Info Header
382 After having received an Access-Accept from the RADIUS server, the
383 RADIUS client constructs an Authentication-Info header:
385 o If the Access-Accept packet contains a Digest-Response-Auth
386 Attribute, the RADIUS client checks the Digest-Qop Attribute:
388 * If the Digest-Qop Attribute's value is 'auth' or not specified,
389 the RADIUS client puts the Digest-Response-Auth Attribute's
394 Sterman, et al. Standards Track [Page 7]
396 RFC 5090 RADIUS Extension Digest Authentication February 2008
399 content into the Authentication-Info header's rspauth directive
400 of the HTTP-style response.
402 * If the Digest-Qop Attribute's value is 'auth-int', the RADIUS
403 client ignores the Access-Accept packet and behaves as if it
404 had received an Access-Reject packet (Digest-Response-Auth
405 can't be correct as the RADIUS server does not know the
406 contents of the HTTP-style response's body).
408 o If the Access-Accept packet contains a Digest-HA1 Attribute, the
409 RADIUS client checks the qop and algorithm directives in the
410 Authorization header of the HTTP-style request it wants to
413 * If the qop directive is missing or its value is 'auth', the
414 RADIUS client ignores the Digest-HA1 Attribute. It does not
415 include an Authentication-Info header in its HTTP-style
418 * If the qop directive's value is 'auth-int' and at least one of
419 the following conditions is true, the RADIUS client calculates
420 the contents of the HTTP-style response's rspauth directive:
422 + The algorithm directive's value is 'MD5-sess' or 'AKAv1-
425 + IP Security (IPsec) is configured to protect traffic between
426 the RADIUS client and RADIUS server with IPsec (see Section
429 The RADIUS client creates the HTTP-style response message and
430 calculates the hash of this message's body. It uses the result
431 and the Digest-URI Attribute's value of the corresponding
432 Access-Request packet to perform the H(A2) calculation. It
433 takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and
434 Digest-Qop values of the corresponding Access-Request and the
435 Digest-HA1 Attribute's value to finish the computation of the
438 o If the Access-Accept packet contains neither a Digest-Response-
439 Auth nor a Digest-HA1 Attribute, the RADIUS client will not create
440 an Authentication-Info header for its HTTP-style response.
442 When the RADIUS server provides a Digest-Nextnonce Attribute in the
443 Access-Accept packet, the RADIUS client puts the contents of this
444 attribute into a nextnonce directive. Now it can send an HTTP-style
450 Sterman, et al. Standards Track [Page 8]
452 RFC 5090 RADIUS Extension Digest Authentication February 2008
455 2.1.4. Failed Authentication
457 If the RADIUS client did receive an HTTP-style request without a
458 (Proxy-)Authorization header matching its locally configured realm
459 value, it obtains a new nonce and sends an error response (401 or
460 407) containing a (Proxy-)Authenticate header.
462 If the RADIUS client receives an Access-Challenge packet in response
463 to an Access-Request containing a Digest-Nonce Attribute, the RADIUS
464 server did not accept the nonce. If a Digest-Stale Attribute is
465 present in the Access-Challenge and has a value of 'true' (without
466 surrounding quotes), the RADIUS client sends an error response (401
467 or 407) containing a WWW-/Proxy-Authenticate header with the stale
468 directive set to 'true' and the digest directives derived from the
471 If the RADIUS client receives an Access-Reject from the RADIUS
472 server, it sends an error response to the HTTP-style request it has
473 received. If the RADIUS client does not receive a response, it
474 retransmits or fails over to another RADIUS server as described in
477 2.1.5. Obtaining Nonces
479 The RADIUS client has two ways to obtain nonces: it has received one
480 in a Digest-Nextnonce Attribute of a previously received Access-
481 Accept packet, or it asks the RADIUS server for one. To do the
482 latter, it sends an Access-Request containing a Digest-Method and a
483 Digest-URI Attribute, but without a Digest-Nonce Attribute. It adds
484 a Message-Authenticator (see [RFC3579]) Attribute to the Access-
485 Request packet. The RADIUS server chooses a nonce and responds with
486 an Access-Challenge containing a Digest-Nonce Attribute.
488 The RADIUS client constructs a (Proxy-)Authenticate header using the
489 received Digest-Nonce and Digest-Realm attributes to fill the nonce
490 and realm directives. The RADIUS server can send Digest-Qop,
491 Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the
492 Access-Challenge carrying the nonce. If these attributes are
493 present, the client MUST use them.
495 2.2. RADIUS Server Behavior
497 If the RADIUS server receives an Access-Request packet with a
498 Digest-Method and a Digest-URI Attribute but without a Digest-Nonce
499 Attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce
500 Attribute and sends it in an Access-Challenge packet to the RADIUS
501 client. The RADIUS server MUST add Digest-Realm, Message-
502 Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm and one or
506 Sterman, et al. Standards Track [Page 9]
508 RFC 5090 RADIUS Extension Digest Authentication February 2008
511 more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque
512 attributes to the Access-Challenge packet.
514 2.2.1. General Attribute Checks
516 If the RADIUS server receives an Access-Request packet containing a
517 Digest-Response Attribute, it looks for the following attributes:
519 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
520 Digest-Algorithm, and Digest-Username. Depending on the content of
521 Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-
522 Hash, Digest-CNonce, and Digest-AKA-Auts, too. See [RFC2617] and
523 [RFC3310] for details. If the Digest-Algorithm Attribute is missing,
524 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque
525 Attribute along with the nonce, the Access-Request MUST have a
526 matching Digest-Opaque Attribute.
528 If mandatory attributes are missing, it MUST respond with an Access-
531 The RADIUS server removes '\' characters that escape quote and '\'
532 characters from the text values it has received in the Digest-*
535 If the mandatory attributes are present, the RADIUS server MUST check
536 if the RADIUS client is authorized to serve users of the realm
537 mentioned in the Digest-Realm Attribute. If the RADIUS client is not
538 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS
539 server SHOULD log the event so as to notify the operator, and MAY
540 take additional action such as sending an Access-Reject in response
541 to all future requests from this client, until this behavior is reset
542 by management action.
544 The RADIUS server determines the age of the nonce in the Digest-Nonce
545 by using an embedded timestamp or by looking it up in a local table.
546 The RADIUS server MUST check the integrity of the nonce if it embeds
547 the timestamp in the nonce. Section 2.2.2 describes how the server
550 2.2.2. Authentication
552 If the Access-Request message passes the checks described above, the
553 RADIUS server calculates the digest response as described in
554 [RFC2617]. To look up the password, the RADIUS server uses the
555 RADIUS User-Name Attribute. The RADIUS server MUST check if the user
556 identified by the User-Name Attribute:
558 o is authorized to access the protection space and
562 Sterman, et al. Standards Track [Page 10]
564 RFC 5090 RADIUS Extension Digest Authentication February 2008
567 o is authorized to use the URI included in the SIP-AOR Attribute, if
568 this attribute is present.
570 If any of those checks fails, the RADIUS server MUST send an Access-
573 Correlation between User-Name and SIP-AOR AVP values is required just
574 to avoid any user from registering or misusing a SIP-AOR that has
575 been allocated to a different user.
577 All values required for the digest calculation are taken from the
578 Digest attributes described in this document. If the calculated
579 digest response equals the value received in the Digest-Response
580 Attribute, the authentication was successful.
582 If the response values match, but the RADIUS server considers the
583 nonce in the Digest-Nonce Attribute too old, it sends an Access-
584 Challenge packet containing a new nonce and a Digest-Stale Attribute
585 with a value of 'true' (without surrounding quotes).
587 If the response values don't match, the RADIUS server responds with
590 2.2.3. Constructing the Reply
592 If the authentication was successful, the RADIUS server adds an
593 attribute to the Access-Accept packet that can be used by the RADIUS
594 client to construct an Authentication-Info header:
596 o If the Digest-Qop Attribute's value is 'auth' or unspecified, the
597 RADIUS server SHOULD put a Digest-Response-Auth Attribute into the
598 Access-Accept packet.
600 o If the Digest-Qop Attribute's value is 'auth-int' and at least one
601 of the following conditions is true, the RADIUS server SHOULD put
602 a Digest-HA1 Attribute into the Access-Accept packet:
604 * The Digest-Algorithm Attribute's value is 'MD5-sess' or
607 * IPsec is configured to protect traffic between the RADIUS
608 client and RADIUS server with IPsec (see Section 8).
610 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
613 RADIUS servers MAY construct a Digest-Nextnonce Attribute and add it
614 to the Access-Accept packet. This is useful to limit the lifetime of
618 Sterman, et al. Standards Track [Page 11]
620 RFC 5090 RADIUS Extension Digest Authentication February 2008
623 a nonce and to save a round-trip in future requests (see nextnonce
624 discussion in [RFC2617], Section 3.2.3). The RADIUS server adds a
625 Message-Authenticator Attribute (see [RFC3579]) and sends the
626 Access-Accept packet to the RADIUS client.
628 If the RADIUS server does not accept the nonce received in an
629 Access-Request packet but authentication was successful, the RADIUS
630 server MUST send an Access-Challenge packet containing a Digest-Stale
631 Attribute set to 'true' (without surrounding quotes). The RADIUS
632 server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce,
633 Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-
634 Qops, and MAY add Digest-Domain or Digest-Opaque attributes to the
635 Access-Challenge packet.
637 3. New RADIUS Attributes
639 If not stated otherwise, the attributes have the following format:
642 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
644 | Type | Length | Text ...
645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
647 Quote and backslash characters in Digest-* attributes representing
648 HTTP-style directives with a quoted-string syntax are escaped. The
649 surrounding quotes are removed. They are syntactical delimiters that
650 are redundant in RADIUS. For example, the directive
652 realm="the \"example\" value"
654 is represented as follows:
656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
657 | Digest-Realm | 23 | the \"example\" value |
658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
660 3.1. Digest-Response Attribute
663 If this attribute is present in an Access-Request message, a
664 RADIUS server implementing this specification MUST treat the
665 Access-Request as a request for Digest Authentication. When a
666 RADIUS client receives a (Proxy-)Authorization header, it puts
667 the request-digest value into a Digest-Response Attribute.
668 This attribute (which enables the user to prove possession of
669 the password) MUST only be used in Access-Request packets.
674 Sterman, et al. Standards Track [Page 12]
676 RFC 5090 RADIUS Extension Digest Authentication February 2008
680 103 for Digest-Response.
684 When using HTTP Digest, the text field is 32 octets long and
685 contains a hexadecimal representation of a 16-octet digest
686 value as it was calculated by the authenticated client. Other
687 digest algorithms MAY define different digest lengths. The
688 text field MUST be copied from request-digest of digest-
689 response [RFC2617] without surrounding quotes.
691 3.2. Digest-Realm Attribute
694 This attribute describes a protection space component of the
695 RADIUS server. HTTP-style protocols differ in their definition
696 of the protection space. See [RFC2617], Section 1.2, for
697 details. It MUST only be used in Access-Request, Access-
698 Challenge, and Accounting-Request packets.
704 In Access-Requests, the RADIUS client takes the value of the
705 realm directive (realm-value according to [RFC2617]) without
706 surrounding quotes from the HTTP-style request it wants to
707 authenticate. In Access-Challenge packets, the RADIUS server
708 puts the expected realm value into this attribute.
710 3.3. Digest-Nonce Attribute
713 This attribute holds a nonce to be used in the HTTP Digest
714 calculation. If the Access-Request had a Digest-Method and a
715 Digest-URI but no Digest-Nonce Attribute, the RADIUS server
716 MUST put a Digest-Nonce Attribute into its Access-Challenge
717 packet. This attribute MUST only be used in Access-Request and
718 Access-Challenge packets.
730 Sterman, et al. Standards Track [Page 13]
732 RFC 5090 RADIUS Extension Digest Authentication February 2008
736 In Access-Requests, the RADIUS client takes the value of the
737 nonce directive (nonce-value in [RFC2617]) without surrounding
738 quotes from the HTTP-style request it wants to authenticate.
739 In Access-Challenge packets, the attribute contains the nonce
740 selected by the RADIUS server.
742 3.4. Digest-Response-Auth Attribute
745 This attribute enables the RADIUS server to prove possession of
746 the password. If the previously received Digest-Qop Attribute
747 was 'auth-int' (without surrounding quotes), the RADIUS server
748 MUST send a Digest-HA1 Attribute instead of a Digest-Response-
749 Auth Attribute. The Digest-Response-Auth Attribute MUST only
750 be used in Access-Accept packets. The RADIUS client puts the
751 attribute value without surrounding quotes into the rspauth
752 directive of the Authentication-Info header.
754 106 for Digest-Response-Auth.
758 The RADIUS server calculates a digest according to Section
759 3.2.3 of [RFC2617] and copies the result into this attribute.
760 Digest algorithms other than the one defined in [RFC2617] MAY
761 define digest lengths other than 32.
763 3.5. Digest-Nextnonce Attribute
765 This attribute holds a nonce to be used in the HTTP Digest
769 The RADIUS server MAY put a Digest-Nextnonce Attribute into an
770 Access-Accept packet. If this attribute is present, the RADIUS
771 client MUST put the contents of this attribute into the
772 nextnonce directive of an Authentication-Info header in its
773 HTTP-style response. This attribute MUST only be used in
774 Access-Accept packets.
776 107 for Digest-Nextnonce
780 It is recommended that this text be base64 or hexadecimal data.
786 Sterman, et al. Standards Track [Page 14]
788 RFC 5090 RADIUS Extension Digest Authentication February 2008
791 3.6. Digest-Method Attribute
794 This attribute holds the method value to be used in the HTTP
795 Digest calculation. This attribute MUST only be used in
796 Access-Request and Accounting-Request packets.
798 108 for Digest-Method
802 In Access-Requests, the RADIUS client takes the value of the
803 request method from the HTTP-style request it wants to
806 3.7. Digest-URI Attribute
809 This attribute is used to transport the contents of the
810 digest-uri directive or the URI of the HTTP-style request. It
811 MUST only be used in Access-Request and Accounting-Request
818 If the HTTP-style request has an Authorization header, the
819 RADIUS client puts the value of the uri directive found in the
820 HTTP-style request Authorization header (known as "digest-uri-
821 value" in Section 3.2.2 of [RFC2617]) without surrounding
822 quotes into this attribute. If there is no Authorization
823 header, the RADIUS client takes the value of the request URI
824 from the HTTP-style request it wants to authenticate.
826 3.8. Digest-Qop Attribute
829 This attribute holds the Quality of Protection parameter that
830 influences the HTTP Digest calculation. This attribute MUST
831 only be used in Access-Request, Access-Challenge, and
832 Accounting-Request packets. A RADIUS client SHOULD insert one
833 of the Digest-Qop attributes it has received in a previous
834 Access-Challenge packet. RADIUS servers SHOULD insert at least
835 one Digest-Qop Attribute in an Access-Challenge packet.
836 Digest-Qop is optional in order to preserve backward
837 compatibility with a minimal implementation of [RFC2069].
842 Sterman, et al. Standards Track [Page 15]
844 RFC 5090 RADIUS Extension Digest Authentication February 2008
852 In Access-Requests, the RADIUS client takes the value of the
853 qop directive (qop-value as described in [RFC2617]) from the
854 HTTP-style request it wants to authenticate. In Access-
855 Challenge packets, the RADIUS server puts a desired qop-value
856 into this attribute. If the RADIUS server supports more than
857 one "quality of protection" value, it puts each qop-value into
858 a separate Digest-Qop Attribute.
860 3.9. Digest-Algorithm Attribute
863 This attribute holds the algorithm parameter that influences
864 the HTTP Digest calculation. It MUST only be used in Access-
865 Request, Access-Challenge and Accounting-Request packets. If
866 this attribute is missing, MD5 is assumed.
868 111 for Digest-Algorithm
872 In Access-Requests, the RADIUS client takes the value of the
873 algorithm directive (as described in [RFC2617], Section 3.2.1)
874 from the HTTP-style request it wants to authenticate. In
875 Access-Challenge packets, the RADIUS server SHOULD put the
876 desired algorithm into this attribute.
878 3.10. Digest-Entity-Body-Hash Attribute
881 When using the qop-value 'auth-int', a hash of the HTTP-style
882 message body's contents is required for digest calculation.
883 Instead of sending the complete body of the message, only its
884 hash value is sent. This hash value can be used directly in
885 the digest calculation.
887 The clarifications described in section 22.4 of [RFC3261] about
888 the hash of empty entity bodies apply to the Digest-Entity-
889 Body-Hash Attribute. This attribute MUST only be sent in
890 Access-Request packets.
892 112 for Digest-Entity-Body-Hash
898 Sterman, et al. Standards Track [Page 16]
900 RFC 5090 RADIUS Extension Digest Authentication February 2008
904 The attribute holds the hexadecimal representation of
905 H(entity-body). This hash is required by certain
906 authentication mechanisms, such as HTTP Digest with quality of
907 protection set to 'auth-int'. RADIUS clients MUST use this
908 attribute to transport the hash of the entity body when HTTP
909 Digest is the authentication mechanism and the RADIUS server
910 requires that the integrity of the entity body (e.g., qop
911 parameter set to 'auth-int') be verified. Extensions to this
912 document may define support for authentication mechanisms other
915 3.11. Digest-CNonce Attribute
918 This attribute holds the client nonce parameter that is used in
919 the HTTP Digest calculation. It MUST only be used in Access-
922 113 for Digest-CNonce
926 This attribute includes the value of the cnonce-value [RFC2617]
927 without surrounding quotes, taken from the HTTP-style request.
929 3.12. Digest-Nonce-Count Attribute
932 This attribute includes the nonce count parameter that is used
933 to detect replay attacks. The attribute MUST only be used in
934 Access-Request packets.
936 114 for Digest-Nonce-Count
940 In Access-Requests, the RADIUS client takes the value of the nc
941 directive (nc-value according to [RFC2617]) without surrounding
942 quotes from the HTTP-style request it wants to authenticate.
944 3.13. Digest-Username Attribute
947 This attribute holds the user name used in the HTTP Digest
948 calculation. The RADIUS server MUST use this attribute only
949 for the purposes of calculating the digest. In order to
950 determine the appropriate user credentials, the RADIUS server
954 Sterman, et al. Standards Track [Page 17]
956 RFC 5090 RADIUS Extension Digest Authentication February 2008
959 MUST use the User-Name (1) Attribute, and MUST NOT use the
960 Digest-Username Attribute. This attribute MUST only be used in
961 Access-Request and Accounting-Request packets.
963 115 for Digest-Username
967 In Access-Requests, the RADIUS client takes the value of the
968 username directive (username-value according to [RFC2617])
969 without surrounding quotes from the HTTP-style request it wants
972 3.14. Digest-Opaque Attribute
975 This attribute holds the opaque parameter that is passed to the
976 HTTP-style client. The HTTP-style client will pass this value
977 back to the server (i.e., the RADIUS client) without
978 modification. This attribute MUST only be used in Access-
979 Request and Access-Challenge packets.
981 116 for Digest-Opaque
985 In Access-Requests, the RADIUS client takes the value of the
986 opaque directive (opaque-value according to [RFC2617]) without
987 surrounding quotes from the HTTP-style request it wants to
988 authenticate and puts it into this attribute. In Access-
989 Challenge packets, the RADIUS server MAY include this
992 3.15. Digest-Auth-Param Attribute
995 This attribute is a placeholder for future extensions and
996 corresponds to the auth-param parameter defined in Section
997 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism
998 whereby the RADIUS client and RADIUS server can exchange auth-
999 param extension parameters contained within Digest headers that
1000 are not understood by the RADIUS client and for which there are
1001 no corresponding stand-alone attributes.
1003 Unlike the previously listed Digest-* attributes, the Digest-
1004 Auth-Param contains not only the value but also the parameter
1005 name, since the parameter name is unknown to the RADIUS client.
1006 If the Digest header contains several unknown parameters, then
1010 Sterman, et al. Standards Track [Page 18]
1012 RFC 5090 RADIUS Extension Digest Authentication February 2008
1015 the RADIUS implementation MUST repeat this attribute, and each
1016 instance MUST contain one different unknown Digest
1017 parameter/value combination. This attribute MUST ONLY be used
1018 in Access-Request, Access-Challenge, Access-Accept, and
1019 Accounting-Request packets.
1021 117 for Digest-Auth-Param
1025 The text consists of the whole parameter, including its name,
1026 the equal sign ('='), and quotes.
1028 3.16. Digest-AKA-Auts Attribute
1031 This attribute holds the auts parameter that is used in the
1032 Digest AKA [RFC3310] calculation. It is only used if the
1033 algorithm of the digest-response denotes a version of AKA
1034 Digest [RFC3310]. This attribute MUST only be used in Access-
1037 118 for Digest-AKA-Auts
1041 In Access-Requests, the RADIUS client takes the value of the
1042 auts directive (auts-param according to Section 3.4 of
1043 [RFC3310]) without surrounding quotes from the HTTP-style
1044 request it wants to authenticate.
1046 3.17. Digest-Domain Attribute
1049 When a RADIUS client has asked for a nonce, the RADIUS server
1050 MAY send one or more Digest-Domain attributes in its Access-
1051 Challenge packet. The RADIUS client puts them into the quoted,
1052 space-separated list of URIs of the domain directive of a WWW-
1053 Authenticate header. Together with Digest-Realm, the URIs in
1054 the list define the protection space (see [RFC2617], Section
1055 3.2.1) for some HTTP-style protocols. This attribute MUST only
1056 be used in Access-Challenge and Accounting-Request packets.
1058 119 for Digest-Domain
1066 Sterman, et al. Standards Track [Page 19]
1068 RFC 5090 RADIUS Extension Digest Authentication February 2008
1072 This attribute consists of a single URI that defines a
1073 protection space component.
1075 3.18. Digest-Stale Attribute
1078 This attribute is sent by a RADIUS server in order to notify
1079 the RADIUS client whether it has accepted a nonce. If the
1080 nonce presented by the RADIUS client was stale, the value is
1081 'true' and is 'false' otherwise. The RADIUS client puts the
1082 content of this attribute into a stale directive of the WWW-
1083 Authenticate header in the HTTP-style response to the request
1084 it wants to authenticate. The attribute MUST only be used in
1085 Access-Challenge packets.
1087 120 for Digest-Stale
1091 The attribute has either the value 'true' or 'false' (both
1092 values without surrounding quotes).
1094 3.19. Digest-HA1 Attribute
1097 This attribute is used to allow the generation of an
1098 Authentication-Info header, even if the HTTP-style response's
1099 body is required for the calculation of the rspauth value. It
1100 SHOULD be used in Access-Accept packets if the required quality
1101 of protection (qop) is 'auth-int'.
1103 This attribute MUST NOT be sent if the qop parameter was not
1104 specified or has a value of 'auth' (in this case, use Digest-
1105 Response-Auth instead).
1107 The Digest-HA1 Attribute MUST only be sent by the RADIUS server
1108 or processed by the RADIUS client if at least one of the
1109 following conditions is true:
1111 + The Digest-Algorithm Attribute's value is 'MD5-sess' or
1114 + IPsec is configured to protect traffic between the RADIUS
1115 client and RADIUS server with IPsec (see Section 8).
1117 This attribute MUST only be used in Access-Accept packets.
1122 Sterman, et al. Standards Track [Page 20]
1124 RFC 5090 RADIUS Extension Digest Authentication February 2008
1132 This attribute contains the hexadecimal representation of H(A1)
1133 as described in [RFC2617], Sections 3.1.3, 3.2.1, and 3.2.2.2.
1135 3.20. SIP-AOR Attribute
1138 This attribute is used for the authorization of SIP messages.
1139 The SIP-AOR Attribute identifies the URI, the use of which must
1140 be authenticated and authorized. The RADIUS server uses this
1141 attribute to authorize the processing of the SIP request. The
1142 SIP-AOR can be derived from, for example, the To header field
1143 in a SIP REGISTER request (user under registration), or the
1144 From header field in other SIP requests. However, the exact
1145 mapping of this attribute to SIP can change due to new
1146 developments in the protocol. This attribute MUST only be used
1147 when the RADIUS client wants to authorize SIP users and MUST
1148 only be used in Access-Request packets.
1154 The syntax of this attribute corresponds either to a SIP URI
1155 (with the format defined in [RFC3261] or a tel URI (with the
1156 format defined in [RFC3966]).
1158 The SIP-AOR Attribute holds the complete URI, including
1159 parameters and other parts. It is up to the RADIUS server as
1160 to which components of the URI are regarded in the
1161 authorization decision.
1163 4. Diameter Compatibility
1165 This document defines support for Digest Authentication in RADIUS. A
1166 companion document "Diameter Session Initiation Protocol (SIP)
1167 Application" [RFC4740] defines support for Digest Authentication in
1168 Diameter, and addresses compatibility issues between RADIUS and
1171 5. Table of Attributes
1173 The following table provides a guide to which attributes may be found
1174 in which kinds of packets, and in what quantity.
1178 Sterman, et al. Standards Track [Page 21]
1180 RFC 5090 RADIUS Extension Digest Authentication February 2008
1183 Access- Access- Access- Access- Acct-
1184 Request Accept Reject Challenge Req # Attribute
1185 0-1 0 0 0 0-1 1 User-Name
1186 0-1 0 0 1 0 24 State [4]
1187 1 1 1 1 0-1 80 Message-Authenticator
1188 0-1 0 0 0 0 103 Digest-Response
1189 0-1 0 0 1 0-1 104 Digest-Realm
1190 0-1 0 0 1 0 105 Digest-Nonce
1191 0 0-1 0 0 0 106 Digest-Response-Auth [1][2]
1192 0 0-1 0 0 0 107 Digest-Nextnonce
1193 1 0 0 0 0-1 108 Digest-Method
1194 0-1 0 0 0 0-1 109 Digest-URI
1195 0-1 0 0 0+ 0-1 110 Digest-Qop
1196 0-1 0 0 0-1 0-1 111 Digest-Algorithm [3]
1197 0-1 0 0 0 0 112 Digest-Entity-Body-Hash
1198 0-1 0 0 0 0 113 Digest-CNonce
1199 0-1 0 0 0 0 114 Digest-Nonce-Count
1200 0-1 0 0 0 0-1 115 Digest-Username
1201 0-1 0 0 0-1 0 116 Digest-Opaque
1202 0+ 0+ 0 0+ 0+ 117 Digest-Auth-Param
1203 0-1 0 0 0 0 118 Digest-AKA-Auts
1204 0 0 0 0+ 0+ 119 Digest-Domain
1205 0 0 0 0-1 0 120 Digest-Stale
1206 0 0-1 0 0 0 121 Digest-HA1 [1][2]
1207 0-1 0 0 0 0 122 SIP-AOR
1209 The following table defines the meaning of the above table entries.
1211 0 This attribute MUST NOT be present in the packet.
1212 0+ Zero or more instances of this attribute MAY be
1213 present in the packet.
1214 0-1 Zero or one instance of this attribute MAY be
1215 present in the packet.
1217 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
1218 Digest-Qop is 'auth-int'.
1220 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
1221 Digest-Qop is 'auth'.
1223 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
1225 [Note 4] An Access-Challenge MUST contain a State attribute, which is
1226 copied to the subsequent Access-Request. A server receiving
1227 an Access-Request that contains a State attribute MUST
1228 respond with either an Access-Accept or an Access-Reject;
1229 the server MUST NOT respond with an Access-Challenge.
1234 Sterman, et al. Standards Track [Page 22]
1236 RFC 5090 RADIUS Extension Digest Authentication February 2008
1241 This is an example selected from the traffic between a softphone (A),
1242 a Proxy Server (B), and an example.com RADIUS server (C). The
1243 communication between the Proxy Server and a SIP Public Switched
1244 Telephone Network (PSTN) gateway is omitted for brevity. The SIP
1245 messages are not shown completely.
1247 The password of user '12345678' is 'secret'. The shared secret
1248 between the RADIUS client and server is 'secret'. To ease testing,
1249 only the last byte of the RADIUS authenticator changes between
1250 requests. In a real implementation, this would be a serious flaw.
1254 INVITE sip:97226491335@example.com SIP/2.0
1255 From: <sip:12345678@example.com>
1256 To: <sip:97226491335@example.com>
1264 Code = Access-Request (1)
1265 Packet identifier = 0x7c (124)
1267 Authenticator = F5E55840E324AA49D216D9DBD069807C
1268 NAS-IP-Address = 192.0.2.38
1270 User-Name = 12345678
1271 Digest-Method = INVITE
1272 Digest-URI = sip:97226491335@example.com
1273 Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B
1277 Code = Access-challenge (11)
1278 Packet identifier = 0x7c (124)
1280 Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
1281 Digest-Nonce = 3bada1a0
1282 Digest-Realm = example.com
1284 Digest-Algorithm = MD5
1285 Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3
1290 Sterman, et al. Standards Track [Page 23]
1292 RFC 5090 RADIUS Extension Digest Authentication February 2008
1297 SIP/2.0 407 Proxy Authentication Required
1298 Proxy-Authenticate: Digest realm="example.com"
1299 ,nonce="3bada1a0",qop=auth,algorithm=MD5
1304 ACK sip:97226491335@example.com SIP/2.0
1308 INVITE sip:97226491335@example.com SIP/2.0
1309 Proxy-Authorization: Digest nonce="3bada1a0"
1310 ,realm="example.com"
1311 ,response="756933f735fcd93f90a4bbdd5467f263"
1312 ,uri="sip:97226491335@example.com",username="12345678"
1313 ,qop=auth,algorithm=MD5
1314 ,cnonce="56593a80,nc="00000001"
1316 From: <sip:12345678@example.com>
1317 To: <sip:97226491335@example.com>
1321 Code = Access-Request (1)
1322 Packet identifier = 0x7d (125)
1324 Authenticator = F5E55840E324AA49D216D9DBD069807D
1325 NAS-IP-Address = 192.0.2.38
1327 User-Name = 12345678
1328 Digest-Method = INVITE
1329 Digest-URI = sip:97226491335@example.com
1330 Digest-Realm = example.com
1332 Digest-Algorithm = MD5
1333 Digest-CNonce = 56593a80
1334 Digest-Nonce = 3bada1a0
1335 Digest-Nonce-Count = 00000001
1336 Digest-Response = 756933f735fcd93f90a4bbdd5467f263
1337 Digest-Username = 12345678
1338 SIP-AOR = sip:12345678@example.com
1339 Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60
1346 Sterman, et al. Standards Track [Page 24]
1348 RFC 5090 RADIUS Extension Digest Authentication February 2008
1353 Code = Access-Accept (2)
1354 Packet identifier = 0x7d (125)
1356 Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2
1357 Digest-Response-Auth = f847de948d12285f8f4199e366f1af21
1358 Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E
1370 ACK sip:97226491335@example.com SIP/2.0
1372 A second example shows the traffic between a web browser (A), a web
1373 server (B), and a RADIUS server (C).
1377 GET /index.html HTTP/1.1
1381 Code = Access-Request (1)
1382 Packet identifier = 0x7e (126)
1384 Authenticator = F5E55840E324AA49D216D9DBD069807E
1385 NAS-IP-Address = 192.0.2.38
1388 Digest-URI = /index.html
1389 Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992
1402 Sterman, et al. Standards Track [Page 25]
1404 RFC 5090 RADIUS Extension Digest Authentication February 2008
1409 Code = Access-challenge (11)
1410 Packet identifier = 0x7e (126)
1412 Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
1413 Digest-Nonce = a3086ac8
1414 Digest-Realm = example.com
1416 Digest-Algorithm = MD5
1417 Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A
1421 HTTP/1.1 401 Authentication Required
1422 WWW-Authenticate: Digest realm="example.com",
1423 nonce="a3086ac8",qop=auth,algorithm=MD5
1428 GET /index.html HTTP/1.1
1429 Authorization: Digest = algorithm=MD5,qop=auth,nonce="a3086ac8"
1430 ,nc="00000001",cnonce="56593a80"
1431 ,realm="example.com"
1432 ,response="a4fac45c27a30f4f244c54a2e99fa117"
1433 ,uri="/index.html",username="12345678"
1437 Code = Access-Request (1)
1438 Packet identifier = 0x7f (127)
1440 Authenticator = F5E55840E324AA49D216D9DBD069807F
1441 NAS-IP-Address = 192.0.2.38
1443 User-Name = 12345678
1445 Digest-URI = /index.html
1446 Digest-Realm = example.com
1448 Digest-Algorithm = MD5
1449 Digest-CNonce = 56593a80
1450 Digest-Nonce = a3086ac8
1451 Digest-Nonce-Count = 00000001
1452 Digest-Response = a4fac45c27a30f4f244c54a2e99fa117
1453 Digest-Username = 12345678
1454 Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821
1458 Sterman, et al. Standards Track [Page 26]
1460 RFC 5090 RADIUS Extension Digest Authentication February 2008
1465 Code = Access-Accept (2)
1466 Packet identifier = 0x7f (127)
1468 Authenticator = 6364FA6ED66012847C05A0895607C694
1469 Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147
1470 Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56
1480 7. IANA Considerations
1482 The following values from the RADIUS Attribute Types number space
1483 were assigned in [RFC4590]. This document requests that the values
1484 in the table below be entered within the existing registry.
1487 --------------- ----
1491 Digest-Response-Auth 106
1492 Digest-Nextnonce 107
1496 Digest-Algorithm 111
1497 Digest-Entity-Body-Hash 112
1499 Digest-Nonce-Count 114
1502 Digest-Auth-Param 117
1514 Sterman, et al. Standards Track [Page 27]
1516 RFC 5090 RADIUS Extension Digest Authentication February 2008
1519 8. Security Considerations
1521 The RADIUS extensions described in this document enable RADIUS to
1522 transport the data that is required to perform a digest calculation.
1523 As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
1524 [RFC2617], Section 4) in addition to RADIUS security vulnerabilities
1525 described in [RFC2865], Section 8, and [RFC3579], Section 4.
1527 An attacker compromising a RADIUS client or proxy can carry out man-
1528 in-the-middle attacks even if the paths between A, B and B, C (Figure
1529 2) have been secured with TLS or IPsec.
1531 The RADIUS server MUST check the Digest-Realm Attribute it has
1532 received from a client. If the RADIUS client is not authorized to
1533 serve HTTP-style clients of that realm, it might be compromised.
1535 8.1. Denial of Service
1537 RADIUS clients implementing the extension described in this document
1538 may authenticate HTTP-style requests received over the Internet. As
1539 compared with the use of RADIUS to authenticate link-layer network
1540 access, attackers may find it easier to cover their tracks in such a
1543 An attacker can attempt a denial-of-service attack on one or more
1544 RADIUS servers by sending a large number of HTTP-style requests. To
1545 make simple denial-of-service attacks more difficult, the RADIUS
1546 server MUST check whether it has generated the nonce received from an
1547 HTTP-style client. This SHOULD be done statelessly. For example, a
1548 nonce could consist of a cryptographically random part and some kind
1549 of signature provided by the RADIUS client, as described in
1550 [RFC2617], Section 3.2.1.
1552 8.2. Confidentiality and Data Integrity
1554 The attributes described in this document are sent in cleartext.
1555 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
1556 attributes in Access-Challenge messages. A man in the middle can
1557 modify or remove those attributes in a bidding down attack, causing
1558 the RADIUS client to use a weaker authentication scheme than
1561 The Message-Authenticator Attribute, described in [RFC3579], Section
1562 3.2 MUST be included in Access-Request, Access-Challenge, Access-
1563 Reject, and Access-Accept messages that contain attributes described
1564 in this specification.
1570 Sterman, et al. Standards Track [Page 28]
1572 RFC 5090 RADIUS Extension Digest Authentication February 2008
1575 The Digest-HA1 Attribute contains no random components if the
1576 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
1577 attacks easier and enables replay attacks.
1579 Some parameter combinations require the protection of RADIUS packets
1580 against eavesdropping and tampering. Implementations SHOULD try to
1581 determine automatically whether IPsec is configured to protect
1582 traffic between the RADIUS client and the RADIUS server. If this is
1583 not possible, the implementation checks a configuration parameter
1584 telling it whether IPsec will protect RADIUS traffic. The default
1585 value of this configuration parameter tells the implementation that
1586 RADIUS packets will not be protected.
1588 HTTP-style clients can use TLS with server-side certificates together
1589 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used,
1590 too. TLS or IPsec secure the connection while Digest Authentication
1591 authenticates the user. The RADIUS transaction can be regarded as
1592 one leg on the path between the HTTP-style client and the HTTP-style
1593 server. To prevent RADIUS from representing the weak link, a RADIUS
1594 client receiving an HTTP-style request via TLS or IPsec could use an
1595 equally secure connection to the RADIUS server. There are several
1596 ways to achieve this, for example:
1598 o The RADIUS client may reject HTTP-style requests received over TLS
1601 o The RADIUS client may require that traffic be sent and received
1604 RADIUS over IPsec, if used, MUST conform to the requirements
1605 described in [RFC3579], Section 4.2.
1609 9.1. Normative References
1611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1612 Requirement Levels", BCP 14, RFC 2119, March 1997.
1614 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1615 Leach, P., Luotonen, A., and L. Stewart, "HTTP
1616 Authentication: Basic and Digest Access Authentication",
1617 RFC 2617, June 1999.
1619 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1620 "Remote Authentication Dial In User Service (RADIUS)", RFC
1626 Sterman, et al. Standards Track [Page 29]
1628 RFC 5090 RADIUS Extension Digest Authentication February 2008
1631 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1632 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
1633 "SIP: Session Initiation Protocol", RFC 3261, June 2002.
1635 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
1636 Dial In User Service) Support For Extensible Authentication
1637 Protocol (EAP)", RFC 3579, September 2003.
1639 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
1640 3966, December 2004.
1642 9.2. Informative References
1644 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
1645 Protocol (CHAP)", RFC 1994, August 1996.
1647 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
1648 Luotonen, A., Sink, E., and L. Stewart, "An Extension to
1649 HTTP : Digest Access Authentication", RFC 2069, January
1652 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
1653 Protocol (HTTP) Digest Authentication Using Authentication
1654 and Key Agreement (AKA)", RFC 3310, September 2002.
1656 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
1657 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
1659 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
1660 Extensions (S/MIME) Version 3.1 Message Specification", RFC
1663 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1664 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1666 [RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D.,
1667 and W. Beck, "RADIUS Extension for Digest Authentication",
1668 RFC 4590, July 2006.
1670 [RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M.,
1671 Canales-Valenzuela, C., and K. Tammi, "Diameter Session
1672 Initiation Protocol (SIP) Application", RFC 4740, November
1682 Sterman, et al. Standards Track [Page 30]
1684 RFC 5090 RADIUS Extension Digest Authentication February 2008
1687 Appendix A - Changes from RFC 4590
1689 This Appendix lists the major changes between [RFC4590] and this
1690 document. Minor changes, including style, grammar, spelling, and
1691 editorial changes are not mentioned here.
1693 o The Table of Attributes (Section 5) now indicates that the
1694 Digest-Method Attribute is required within an Access-Request.
1695 Also, an entry has been added for the State attribute. The table
1696 also includes entries for Accounting-Request messages. As noted
1697 in the examples, the User-Name Attribute is not necessary when
1700 o Two errors in attribute assignment have been corrected within the
1701 IANA Considerations (Section 7). Digest-Response-Auth is assigned
1702 attribute 106, and Digest-Nextnonce is assigned attribute 107.
1704 o Several errors in the examples section have been corrected.
1708 The authors would like to thank Mike McCauley for his help in working
1709 through the details of the examples.
1711 We would like to acknowledge Kevin McDermott (Cisco Systems) for
1712 providing comments and experimental implementation.
1714 Many thanks to all reviewers, especially to Miguel Garcia, Jari
1715 Arkko, Avi Lior, and Jun Wang.
1738 Sterman, et al. Standards Track [Page 31]
1740 RFC 5090 RADIUS Extension Digest Authentication February 2008
1751 EMail: baruch@kayote.com
1755 Jerusalem Technology Park
1760 EMail: dscreat@dscreat.com
1768 EMail: david@kayote.com
1774 Research Triangle Park NC 27709
1777 EMail: dwilli@cisco.com
1781 Deutsche Telekom Allee 7
1785 EMail: beckw@t-systems.com
1794 Sterman, et al. Standards Track [Page 32]
1796 RFC 5090 RADIUS Extension Digest Authentication February 2008
1799 Full Copyright Statement
1801 Copyright (C) The IETF Trust (2008).
1803 This document is subject to the rights, licenses and restrictions
1804 contained in BCP 78, and except as set forth therein, the authors
1805 retain all their rights.
1807 This document and the information contained herein are provided on an
1808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1810 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1811 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1812 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1815 Intellectual Property
1817 The IETF takes no position regarding the validity or scope of any
1818 Intellectual Property Rights or other rights that might be claimed to
1819 pertain to the implementation or use of the technology described in
1820 this document or the extent to which any license under such rights
1821 might or might not be available; nor does it represent that it has
1822 made any independent effort to identify any such rights. Information
1823 on the procedures with respect to rights in RFC documents can be
1824 found in BCP 78 and BCP 79.
1826 Copies of IPR disclosures made to the IETF Secretariat and any
1827 assurances of licenses to be made available, or the result of an
1828 attempt made to obtain a general license or permission for the use of
1829 such proprietary rights by implementers or users of this
1830 specification can be obtained from the IETF on-line IPR repository at
1831 http://www.ietf.org/ipr.
1833 The IETF invites any interested party to bring to its attention any
1834 copyrights, patents or patent applications, or other proprietary
1835 rights that may cover technology that may be required to implement
1836 this standard. Please address the information to the IETF at
1850 Sterman, et al. Standards Track [Page 33]