7 Network Working Group B. Sterman
8 Request for Comments: 4590 Kayote Networks
9 Category: Standards Track D. Sadolevsky
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 Copyright (C) The Internet Society (2006).
36 This document defines an extension to the Remote Authentication
37 Dial-In User Service (RADIUS) protocol to enable support of Digest
38 Authentication, for use with HTTP-style protocols like the Session
39 Initiation Protocol (SIP) and HTTP.
43 1. Introduction ....................................................2
44 1.1. Terminology ................................................2
45 1.2. Motivation .................................................3
46 1.3. Overview ...................................................4
47 2. Detailed Description ............................................6
48 2.1. RADIUS Client Behavior .....................................6
49 2.1.1. Credential Selection ................................6
50 2.1.2. Constructing an Access-Request ......................6
51 2.1.3. Constructing an Authentication-Info Header ..........7
52 2.1.4. Failed Authentication ...............................8
53 2.1.5. Obtaining Nonces ....................................9
54 2.2. RADIUS Server Behavior .....................................9
58 Sterman, et al. Standards Track [Page 1]
60 RFC 4590 RADIUS Digest Authentication July 2006
63 2.2.1. General Attribute Checks ............................9
64 2.2.2. Authentication .....................................10
65 2.2.3. Constructing the Reply .............................11
66 3. New RADIUS Attributes ..........................................12
67 3.1. Digest-Response attribute .................................12
68 3.2. Digest-Realm Attribute ....................................13
69 3.3. Digest-Nonce Attribute ....................................13
70 3.4. Digest-Response-Auth Attribute ............................14
71 3.5. Digest-Nextnonce Attribute ................................14
72 3.6. Digest-Method Attribute ...................................14
73 3.7. Digest-URI Attribute ......................................15
74 3.8. Digest-Qop Attribute ......................................15
75 3.9. Digest-Algorithm Attribute ................................16
76 3.10. Digest-Entity-Body-Hash Attribute ........................16
77 3.11. Digest-CNonce Attribute ..................................17
78 3.12. Digest-Nonce-Count Attribute .............................17
79 3.13. Digest-Username Attribute ................................17
80 3.14. Digest-Opaque Attribute ..................................18
81 3.15. Digest-Auth-Param Attribute ..............................18
82 3.16. Digest-AKA-Auts Attribute ................................19
83 3.17. Digest-Domain Attribute ..................................19
84 3.18. Digest-Stale Attribute ...................................20
85 3.19. Digest-HA1 Attribute .....................................20
86 3.20. SIP-AOR Attribute ........................................21
87 4. Diameter Compatibility .........................................21
88 5. Table of Attributes ............................................22
89 6. Examples .......................................................23
90 7. IANA Considerations ............................................27
91 8. Security Considerations ........................................27
92 8.1. Denial of Service .........................................28
93 8.2. Confidentiality and Data Integrity ........................28
94 9. Acknowledgements ...............................................29
95 10. References ....................................................29
96 10.1. Normative References .....................................29
97 10.2. Informative References ...................................30
103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
105 document are to be interpreted as described in [RFC2119].
107 The use of normative requirement key words in this document shall
108 apply only to RADIUS client and RADIUS server implementations that
109 include the features described in this document. This document
110 creates no normative requirements for existing implementations.
114 Sterman, et al. Standards Track [Page 2]
116 RFC 4590 RADIUS Digest Authentication July 2006
120 The term 'HTTP-style' denotes any protocol that uses HTTP-like
121 headers and uses HTTP Digest Authentication as described in
122 [RFC2617]. Examples are HTTP and the Session Initiation
126 Network Access Server, the RADIUS client.
129 An unpredictable value used to prevent replay attacks. The
130 nonce generator may use cryptographic mechanisms to produce
131 nonces it can recognize without maintaining state.
134 HTTP-style protocols differ in their definition of the
135 protection space. For HTTP, it is defined as the combination
136 of realm and canonical root URL of the requested resource for
137 which the use is authorized by the RADIUS server. In the case
138 of SIP, the realm string alone defines the protection space.
141 SIP User Agent, an Internet endpoint that uses the Session
145 SIP User Agent Server, a logical entity that generates a
146 response to a SIP (Session Initiation Protocol) request.
150 The HTTP Digest Authentication mechanism, defined in [RFC2617], was
151 subsequently adapted for use with SIP [RFC3261]. Due to the
152 limitations and weaknesses of Digest Authentication (see [RFC2617],
153 section 4), additional authentication and encryption mechanisms are
154 defined in SIP [RFC3261], including Transport Layer Security (TLS)
155 [RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest
156 Authentication support is mandatory in SIP implementations, and
157 Digest Authentication is the preferred way for a SIP UA to
158 authenticate itself to a proxy server. Digest Authentication is used
159 in other protocols as well.
161 To simplify the provisioning of users, there is a need to support
162 this authentication mechanism within Authentication, Authorization,
163 and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
170 Sterman, et al. Standards Track [Page 3]
172 RFC 4590 RADIUS Digest Authentication July 2006
175 This document defines an extension to the RADIUS protocol to enable
176 support of Digest Authentication for use with SIP, HTTP, and other
177 HTTP-style protocols using this authentication method. Support for
178 Digest mechanisms such as Authentication and Key Agreement (AKA)
179 [RFC3310] is also supported. A companion document [SIP-APP] defines
180 support for Digest Authentication within Diameter.
184 HTTP Digest is a challenge-response protocol used to authenticate a
185 client's request to access some resource on a server. Figure 1 shows
186 a single HTTP Digest transaction.
189 +------------+ (1) +------------+
191 | HTTP-style | (2) | HTTP-style |
192 | client |<---------| server |
197 +------------+ +------------+
199 Figure 1: Digest operation without RADIUS
201 If the client sends a request without any credentials (1), the server
202 will reply with an error response (2) containing a nonce. The client
203 creates a cryptographic digest from parts of the request, from the
204 nonce it received from the server, and from a shared secret. The
205 client re-transmits the request (3) to the server, but now includes
206 the digest within the packet. The server does the same digest
207 calculation as the client and compares the result with the digest it
208 received in (3). If the digest values are identical, the server
209 grants access to the resource and sends a positive response to the
210 client (4). If the digest values differ, the server sends a negative
211 response to the client (4).
213 Instead of maintaining a local user database, the server could use
214 RADIUS to access a centralized user database. However, RADIUS
215 [RFC2865] does not include support for HTTP Digest Authentication.
216 The RADIUS client cannot use the User-Password attribute, since it
217 does not receive a password from the HTTP-style client. The
218 CHAP-Challenge and CHAP-Password attributes described in [RFC1994]
219 are also not suitable since the CHAP algorithm is not compatible with
226 Sterman, et al. Standards Track [Page 4]
228 RFC 4590 RADIUS Digest Authentication July 2006
231 This document defines new attributes that enable the RADIUS server to
232 perform the digest calculation defined in [RFC2617], providing
233 support for Digest Authentication as a native authentication
234 mechanism within RADIUS.
236 The nonces required by the digest algorithm are generated by the
237 RADIUS server. Generating them in the RADIUS client would save a
238 round-trip, but introduce security and operational issues. Some
239 digest algorithms -- e.g., AKA [RFC3310] -- would not work.
241 Figure 2 depicts a scenario in which the HTTP-style server defers
242 authentication to a RADIUS server. Entities A and B communicate
243 using HTTP or SIP, while entities B and C communicate using RADIUS.
247 +-----+ (1) +-----+ +-----+
248 | |==========>| | (2) | |
249 | | | |---------->| |
251 | | (4) | |<----------| |
252 | |<==========| | | |
254 | |==========>| | | |
255 | A | | B | (6) | C |
256 | | | |---------->| |
258 | | | |<----------| |
260 | |<==========| | | |
261 +-----+ +-----+ +-----+
266 Figure 2: HTTP Digest over RADIUS
268 The entities have the following roles:
270 A: HTTP client / SIP UA
272 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
273 acting also as a RADIUS NAS
282 Sterman, et al. Standards Track [Page 5]
284 RFC 4590 RADIUS Digest Authentication July 2006
287 The following messages are sent in this scenario:
289 A sends B an HTTP/SIP request without an authorization header (step
290 1). B sends an Access-Request packet with the newly defined
291 Digest-Method and Digest-URI attributes but without a Digest-Nonce
292 attribute to the RADIUS server, C (step 2). C chooses a nonce and
293 responds with an Access-Challenge (step 3). This Access-Challenge
294 contains Digest attributes, from which B takes values to construct an
295 HTTP/SIP "(Proxy) Authorization required" response. B sends this
296 response to A (step 4). A resends its request with its credentials
297 (step 5). B sends an Access-Request to C (step 6). C checks the
298 credentials and replies with Access-Accept or Access-Reject (step 7).
299 Depending on C's result, B processes A's request or rejects it with a
300 "(Proxy) Authorization required" response (step 8).
302 2. Detailed Description
304 2.1. RADIUS Client Behavior
306 The attributes described in this document are sent in cleartext.
307 Therefore, were a RADIUS client to accept secure connections (HTTPS
308 or SIPS) from HTTP-style clients, this could result in information
309 intentionally protected by HTTP-style clients being sent in the clear
310 during RADIUS exchange.
312 2.1.1. Credential Selection
314 On reception of an HTTP-style request message, the RADIUS client
315 checks whether it is authorized to authenticate the request. Where
316 an HTTP-style request traverses several proxies and each of the
317 proxies requests to authenticate the HTTP-style client, the request
318 at the HTTP-style server may contain multiple credential sets.
320 The RADIUS client can use the 'realm' directive in HTTP to determine
321 which credentials are applicable. Where none of the realms are of
322 interest, the RADIUS client MUST behave as though no relevant
323 credentials were sent. In all situations, the RADIUS client MUST
324 send zero or exactly one credential to the RADIUS server. The RADIUS
325 client MUST choose the credential of the (Proxy-)Authorization header
326 if the realm directive matches its locally configured realm.
328 2.1.2. Constructing an Access-Request
330 If a matching (Proxy-)Authorization header is present and contains
331 HTTP Digest information, the RADIUS client checks the 'nonce'
338 Sterman, et al. Standards Track [Page 6]
340 RFC 4590 RADIUS Digest Authentication July 2006
343 If the RADIUS client recognizes the nonce, it takes the header
344 directives and puts them into a RADIUS Access-Request packet. It
345 puts the 'response' directive into a Digest-Response attribute and
346 the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username,
347 and opaque directives into the respective Digest-Realm, Digest-Nonce,
348 Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,
349 Digest-Nonce-Count, Digest-Username, and Digest-Opaque attributes.
350 The RADIUS client puts the request method into the Digest-Method
353 Due to syntactic requirements, HTTP-style protocols have to escape
354 with backslash all quote and backslash characters in contents of HTTP
355 Digest directives. When translating directives into RADIUS
356 attributes, the RADIUS client only removes the surrounding quotes
357 where present. See Section 3 for an example.
359 If the Quality of Protection (qop) directive's value is 'auth-int',
360 the RADIUS client calculates H(entity-body) as described in
361 [RFC2617], Section 3.2.1, and puts the result in a
362 Digest-Entity-Body-Hash attribute.
364 The RADIUS client adds a Message-Authenticator attribute, defined in
365 [RFC3579], and sends the Access-Request packet to the RADIUS server.
367 The RADIUS server processes the packet and responds with an
368 Access-Accept or an Access-Reject.
370 2.1.3. Constructing an Authentication-Info Header
372 After having received an Access-Accept from the RADIUS server, the
373 RADIUS client constructs an Authentication-Info header:
375 o If the Access-Accept packet contains a Digest-Response-Auth
376 attribute, the RADIUS client checks the Digest-Qop attribute:
378 * If the Digest-Qop attribute's value is 'auth' or not specified,
379 the RADIUS client puts the Digest-Response-Auth attribute's
380 content into the Authentication-Info header's 'rspauth'
381 directive of the HTTP-style response.
383 * If the Digest-Qop attribute's value is 'auth-int', the RADIUS
384 client ignores the Access-Accept packet and behaves as if it
385 had received an Access-Reject packet (Digest-Response-Auth
386 can't be correct as the RADIUS server does not know the
387 contents of the HTTP-style response's body).
394 Sterman, et al. Standards Track [Page 7]
396 RFC 4590 RADIUS Digest Authentication July 2006
399 o If the Access-Accept packet contains a Digest-HA1 attribute, the
400 RADIUS client checks the 'qop' and 'algorithm' directives in the
401 Authorization header of the HTTP-style request it wants to
404 * If the 'qop' directive is missing or its value is 'auth', the
405 RADIUS client ignores the Digest-HA1 attribute. It does not
406 include an Authentication-Info header in its HTTP-style
409 * If the 'qop' directive's value is 'auth-int' and at least one
410 of the following conditions is true, the RADIUS client
411 calculates the contents of the HTTP-style response's 'rspauth'
414 + The algorithm directive's value is 'MD5-sess' or
417 + IP Security (IPsec) is configured to protect traffic between
418 the RADIUS client and RADIUS server with IPsec (see
421 It creates the HTTP-style response message and calculates the
422 hash of this message's body. It uses the result and the
423 Digest-URI attribute's value of the corresponding
424 Access-Request packet to perform the H(A2) calculation. It
425 takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and
426 Digest-Qop values of the corresponding Access-Request and the
427 Digest-HA1 attribute's value to finish the computation of the
430 o If the Access-Accept packet contains neither a
431 Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client
432 will not create an Authentication-Info header for its HTTP-style
435 When the RADIUS server provides a Digest-Nextnonce attribute in the
436 Access-Accept packet, the RADIUS client puts the contents of this
437 attribute into a 'nextnonce' directive. Now it can send an
440 2.1.4. Failed Authentication
442 If the RADIUS client did receive an HTTP-style request without a
443 (Proxy-)Authorization header matching its locally configured realm
444 value, it obtains a new nonce and sends an error response (401 or
445 407) containing a (Proxy-)Authenticate header.
450 Sterman, et al. Standards Track [Page 8]
452 RFC 4590 RADIUS Digest Authentication July 2006
455 If the RADIUS client receives an Access-Challenge packet in response
456 to an Access-Request containing a Digest-Nonce attribute, the RADIUS
457 server did not accept the nonce. If a Digest-Stale attribute is
458 present in the Access-Challenge and has a value of 'true' (without
459 surrounding quotes), the RADIUS client sends an error response (401
460 or 407) containing a WWW-/Proxy-Authenticate header with the
461 directive 'stale' and the digest directives derived from the Digest-*
464 If the RADIUS client receives an Access-Reject from the RADIUS
465 server, it sends an error response to the HTTP-style request it has
466 received. If the RADIUS client does not receive a response, it
467 retransmits or fails over to another RADIUS server as described in
470 2.1.5. Obtaining Nonces
472 The RADIUS client has two ways to obtain nonces: it has received one
473 in a Digest-Nextnonce attribute of a previously received
474 Access-Accept packet or it asks the RADIUS server for one. To do the
475 latter, it sends an Access-Request containing a Digest-Method and a
476 Digest-URI attribute but without a Digest-Nonce attribute. It adds a
477 Message-Authenticator (see [RFC3579]) attribute to the Access-Request
478 packet. The RADIUS server chooses a nonce and responds with an
479 Access-Challenge containing a Digest-Nonce attribute.
481 The RADIUS client constructs a (Proxy-)Authenticate header using the
482 received Digest-Nonce and Digest-Realm attributes to fill the nonce
483 and realm directives. The RADIUS server can send Digest-Qop,
484 Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the
485 Access-Challenge carrying the nonce. If these attributes are
486 present, the client MUST use them.
488 2.2. RADIUS Server Behavior
490 If the RADIUS server receives an Access-Request packet with a
491 Digest-Method and a Digest-URI attribute but without a Digest-Nonce
492 attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce
493 attribute and sends it in an Access-Challenge packet to the RADIUS
494 client. The RADIUS server MUST add Digest-Realm,
495 Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm
496 and one or more Digest-Qop, and MAY add Digest-Domain or
497 Digest-Opaque attributes to the Access-Challenge packet.
499 2.2.1. General Attribute Checks
501 If the RADIUS server receives an Access-Request packet containing a
502 Digest-Response attribute, it looks for the following attributes:
506 Sterman, et al. Standards Track [Page 9]
508 RFC 4590 RADIUS Digest Authentication July 2006
511 Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
512 Digest-Algorithm, and Digest-Username. Depending on the content of
513 Digest-Algorithm and Digest-Qop, it looks for
514 Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts, too.
515 See [RFC2617] and [RFC3310] for details. If the Digest-Algorithm
516 attribute is missing, 'MD5' is assumed. If the RADIUS server has
517 issued a Digest-Opaque attribute along with the nonce, the
518 Access-Request MUST have a matching Digest-Opaque attribute.
520 If mandatory attributes are missing, it MUST respond with an
521 Access-Reject packet.
523 The RADIUS server removes '\' characters that escape quote and '\'
524 characters from the text values it has received in the Digest-*
527 If the mandatory attributes are present, the RADIUS server MUST check
528 if the RADIUS client is authorized to serve users of the realm
529 mentioned in the Digest-Realm attribute. If the RADIUS client is not
530 authorized, the RADIUS server MUST send an Access-Reject. The RADIUS
531 server SHOULD log the event so as to notify the operator, and MAY
532 take additional action such as sending an Access-Reject in response
533 to all future requests from this client, until this behavior is reset
534 by management action.
536 The RADIUS server determines the age of the nonce in Digest-Nonce by
537 using an embedded time-stamp or by looking it up in a local table.
538 The RADIUS server MUST check the integrity of the nonce if it embeds
539 the time-stamp in the nonce. Section 2.2.2 describes how the server
542 2.2.2. Authentication
544 If the Access-Request message has passed the checks described above,
545 the RADIUS server calculates the digest response as described in
546 [RFC2617]. To look up the password, the RADIUS server uses the
547 RADIUS User-Name attribute. The RADIUS server MUST check if the user
548 identified by the User-Name attribute
550 o is authorized to access the protection space and
552 o is authorized to use the URI included in the SIP-AOR attribute, if
553 this attribute is present.
555 If any of those checks fails, the RADIUS server MUST send an
562 Sterman, et al. Standards Track [Page 10]
564 RFC 4590 RADIUS Digest Authentication July 2006
567 Correlation between User-Name and SIP-AOR AVP values is required just
568 to avoid that any user can register or misuse a SIP-AOR allocated to
571 All values required for the digest calculation are taken from the
572 Digest attributes described in this document. If the calculated
573 digest response equals the value received in the Digest-Response
574 attribute, the authentication was successful.
576 If the response values match, but the RADIUS server considers the
577 nonce in the Digest-Nonce attribute as too old, it sends an
578 Access-Challenge packet containing a new nonce and a Digest-Stale
579 attribute with a value of 'true' (without surrounding quotes).
581 If the response values don't match, the RADIUS server responds with
584 2.2.3. Constructing the Reply
586 If the authentication was successful, the RADIUS server adds an
587 attribute to the Access-Accept packet that can be used by the RADIUS
588 client to construct an Authentication-Info header:
590 o If the Digest-Qop attribute's value is 'auth' or unspecified, the
591 RADIUS server SHOULD put a Digest-Response-Auth attribute into the
592 Access-Accept packet.
594 o If the Digest-Qop attribute's value is 'auth-int' and at least one
595 of the following conditions is true, the RADIUS server SHOULD put
596 a Digest-HA1 attribute into the Access-Accept packet:
598 * The Digest-Algorithm attribute's value is 'MD5-sess' or
601 * IPsec is configured to protect traffic between the RADIUS
602 client and RADIUS server with IPsec (see Section 8).
604 In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
607 RADIUS servers MAY construct a Digest-Nextnonce attribute and add it
608 to the Access-Accept packet. This is useful to limit the lifetime of
609 a nonce and to save a round-trip in future requests (see nextnonce
610 discussion in [RFC2617], section 3.2.3). The RADIUS server adds a
611 Message-Authenticator attribute (see [RFC3579]) and sends the
612 Access-Accept packet to the RADIUS client.
618 Sterman, et al. Standards Track [Page 11]
620 RFC 4590 RADIUS Digest Authentication July 2006
623 If the RADIUS server does not accept the nonce received in an
624 Access-Request packet but authentication was successful, the RADIUS
625 server MUST send an Access-Challenge packet containing a Digest-Stale
626 attribute set to 'true' (without surrounding quotes). The RADIUS
627 server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce,
628 Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-Qop
629 and MAY add Digest-Domain, Digest-Opaque attributes to the
630 Access-Challenge packet.
632 3. New RADIUS Attributes
634 If not stated otherwise, the attributes have the following format:
637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
639 | Type | Length | Text ...
640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
642 Quote and backslash characters in Digest-* attributes representing
643 HTTP-style directives with a quoted-string syntax are escaped. The
644 surrounding quotes are removed. They are syntactical delimiters that
645 are redundant in RADIUS. For example, the directive
647 realm="the \"example\" value"
649 is represented as follows:
651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
652 | Digest-Realm | 23 | the \"example\" value |
653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
655 3.1. Digest-Response attribute
658 If this attribute is present in an Access-Request message, a
659 RADIUS server implementing this specification MUST treat the
660 Access-Request as a request for Digest Authentication. When a
661 RADIUS client receives a (Proxy-)Authorization header, it puts
662 the request-digest value into a Digest-Response attribute.
663 This attribute (which enables the user to prove possession of
664 the password) MUST only be used in Access-Requests.
666 103 for Digest-Response.
674 Sterman, et al. Standards Track [Page 12]
676 RFC 4590 RADIUS Digest Authentication July 2006
680 When using HTTP Digest, the text field is 32 octets long and
681 contains a hexadecimal representation of a 16-octet digest
682 value as it was calculated by the authenticated client. Other
683 digest algorithms MAY define different digest lengths. The
684 text field MUST be copied from request-digest of
685 digest-response ([RFC2617]) without surrounding quotes.
687 3.2. Digest-Realm Attribute
690 This attribute describes a protection space component of the
691 RADIUS server. HTTP-style protocols differ in their definition
692 of the protection space. See [RFC2617], Section 1.2, for
693 details. It MUST only be used in Access-Request and
694 Access-Challenge packets.
700 In Access-Requests, the RADIUS client takes the value of the
701 realm directive (realm-value according to [RFC2617]) without
702 surrounding quotes from the HTTP-style request it wants to
703 authenticate. In Access-Challenge packets, the RADIUS server
704 puts the expected realm value into this attribute.
706 3.3. Digest-Nonce Attribute
710 This attribute holds a nonce to be used in the HTTP Digest
711 calculation. If the Access-Request had a Digest-Method and a
712 Digest-URI but no Digest-Nonce attribute, the RADIUS server
713 MUST put a Digest-Nonce attribute into its Access-Challenge
714 packet. This attribute MUST only be used in Access-Request and
715 Access-Challenge packets.
721 In Access-Requests, the RADIUS client takes the value of the
722 nonce directive (nonce-value in [RFC2617]) without surrounding
723 quotes from the HTTP-style request it wants to authenticate.
724 In Access-Challenge packets, the attribute contains the nonce
725 selected by the RADIUS server.
730 Sterman, et al. Standards Track [Page 13]
732 RFC 4590 RADIUS Digest Authentication July 2006
735 3.4. Digest-Response-Auth Attribute
738 This attribute enables the RADIUS server to prove possession of
739 the password. If the previously received Digest-Qop attribute
740 was 'auth-int' (without surrounding quotes), the RADIUS server
741 MUST send a Digest-HA1 attribute instead of a
742 Digest-Response-Auth attribute. The Digest-Response-Auth
743 attribute MUST only be used in Access-Accept packets. The
744 RADIUS client puts the attribute value without surrounding
745 quotes into the rspauth directive of the Authentication-Info
748 106 for Digest-Response-Auth.
752 The RADIUS server calculates a digest according to section
753 3.2.3 of [RFC2617] and copies the result into this attribute.
754 Digest algorithms other than the one defined in [RFC2617] MAY
755 define digest lengths other than 32.
757 3.5. Digest-Nextnonce Attribute
759 This attribute holds a nonce to be used in the HTTP Digest
764 The RADIUS server MAY put a Digest-Nextnonce attribute into an
765 Access-Accept packet. If this attribute is present, the RADIUS
766 client MUST put the contents of this attribute into the
767 nextnonce directive of an Authentication-Info header in its
768 HTTP-style response. This attribute MUST only be used in
769 Access-Accept packets.
771 107 for Digest-Nextnonce
775 It is recommended that this text be base64 or hexadecimal data.
777 3.6. Digest-Method Attribute
780 This attribute holds the method value to be used in the HTTP
781 Digest calculation. This attribute MUST only be used in
782 Access-Request packets.
786 Sterman, et al. Standards Track [Page 14]
788 RFC 4590 RADIUS Digest Authentication July 2006
792 108 for Digest-Method
796 In Access-Requests, the RADIUS client takes the value of the
797 request method from the HTTP-style request it wants to
800 3.7. Digest-URI Attribute
803 This attribute is used to transport the contents of the
804 digest-uri directive or the URI of the HTTP-style request. It
805 MUST only be used in Access-Request packets.
811 If the HTTP-style request has an Authorization header, the
812 RADIUS client puts the value of the "uri" directive found in
813 the HTTP-style request Authorization header (known as
814 "digest-uri-value" in section 3.2.2 of [RFC2617]) without
815 surrounding quotes into this attribute. If there is no
816 Authorization header, the RADIUS client takes the value of the
817 request URI from the HTTP-style request it wants to
820 3.8. Digest-Qop Attribute
823 This attribute holds the Quality of Protection parameter that
824 influences the HTTP Digest calculation. This attribute MUST
825 only be used in Access-Request and Access-Challenge packets. A
826 RADIUS client SHOULD insert one of the Digest-Qop attributes it
827 has received in a previous Access-Challenge packet. RADIUS
828 servers SHOULD insert at least one Digest-Qop attribute in an
829 Access-Challenge packet. Digest-Qop is optional in order to
830 preserve backward compatibility with a minimal implementation
837 In Access-Requests, the RADIUS client takes the value of the
838 qop directive (qop-value as described in [RFC2617]) from the
842 Sterman, et al. Standards Track [Page 15]
844 RFC 4590 RADIUS Digest Authentication July 2006
847 HTTP-style request it wants to authenticate. In
848 Access-Challenge packets, the RADIUS server puts a desired
849 qop-value into this attribute. If the RADIUS server supports
850 more than one "quality of protection" value, it puts each
851 qop-value into a separate Digest-Qop attribute.
853 3.9. Digest-Algorithm Attribute
856 This attribute holds the algorithm parameter that influences
857 the HTTP Digest calculation. It MUST only be used in
858 Access-Request and Access-Challenge packets. If this attribute
859 is missing, MD5 is assumed.
861 111 for Digest-Algorithm
865 In Access-Requests, the RADIUS client takes the value of the
866 algorithm directive (as described in [RFC2617], section 3.2.1)
867 from the HTTP-style request it wants to authenticate. In
868 Access-Challenge packets, the RADIUS server SHOULD put the
869 desired algorithm into this attribute.
871 3.10. Digest-Entity-Body-Hash Attribute
874 When using the qop-level 'auth-int', a hash of the HTTP-style
875 message body's contents is required for digest calculation.
876 Instead of sending the complete body of the message, only its
877 hash value is sent. This hash value can be used directly in
878 the digest calculation.
880 The clarifications described in section 22.4 of [RFC3261] about
881 the hash of empty entity bodies apply to the
882 Digest-Entity-Body-Hash attribute. This attribute MUST only be
883 sent in Access-Request packets.
885 112 for Digest-Entity-Body-Hash
889 The attribute holds the hexadecimal representation of
890 H(entity-body). This hash is required by certain
891 authentication mechanisms, such as HTTP Digest with quality of
892 protection set to "auth-int". RADIUS clients MUST use this
893 attribute to transport the hash of the entity body when HTTP
894 Digest is the authentication mechanism and the RADIUS server
898 Sterman, et al. Standards Track [Page 16]
900 RFC 4590 RADIUS Digest Authentication July 2006
903 requires that the integrity of the entity body (e.g., qop
904 parameter set to "auth-int") be verified. Extensions to this
905 document may define support for authentication mechanisms other
908 3.11. Digest-CNonce Attribute
911 This attribute holds the client nonce parameter that is used in
912 the HTTP Digest calculation. It MUST only be used in
913 Access-Request packets.
915 113 for Digest-CNonce
919 This attribute includes the value of the cnonce-value [RFC2617]
920 without surrounding quotes, taken from the HTTP-style request.
922 3.12. Digest-Nonce-Count Attribute
925 This attribute includes the nonce count parameter that is used
926 to detect replay attacks. The attribute MUST only be used in
927 Access-Request packets.
930 114 for Digest-Nonce-Count
934 In Access-Requests, the RADIUS client takes the value of the nc
935 directive (nc-value according to [RFC2617]) without surrounding
936 quotes from the HTTP-style request it wants to authenticate.
938 3.13. Digest-Username Attribute
941 This attribute holds the user name used in the HTTP Digest
942 calculation. The RADIUS server MUST use this attribute only
943 for the purposes of calculating the digest. In order to
944 determine the appropriate user credentials, the RADIUS server
945 MUST use the User-Name (1) attribute, and MUST NOT use the
946 Digest-Username attribute. This attribute MUST only be used in
947 Access-Request packets.
949 115 for Digest-Username
954 Sterman, et al. Standards Track [Page 17]
956 RFC 4590 RADIUS Digest Authentication July 2006
962 In Access-Requests, the RADIUS client takes the value of the
963 username directive (username-value according to [RFC2617])
964 without surrounding quotes from the HTTP-style request it wants
967 3.14. Digest-Opaque Attribute
970 This attribute holds the opaque parameter that is passed to the
971 HTTP-style client. The HTTP-style client will pass this value
972 back to the server (i.e., the RADIUS client) without
973 modification. This attribute MUST only be used in
974 Access-Request and Access-Challenge packets.
976 116 for Digest-Opaque
980 In Access-Requests, the RADIUS client takes the value of the
981 opaque directive (opaque-value according to [RFC2617]) without
982 surrounding quotes from the HTTP-style request it wants to
983 authenticate and puts it into this attribute. In
984 Access-Challenge packets, the RADIUS server MAY include this
987 3.15. Digest-Auth-Param Attribute
990 This attribute is a placeholder for future extensions and
991 corresponds to the "auth-param" parameter defined in section
992 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism
993 whereby the RADIUS client and RADIUS server can exchange
994 auth-param extension parameters contained within Digest headers
995 that are not understood by the RADIUS client and for which
996 there are no corresponding stand-alone attributes.
998 Unlike the previously listed Digest-* attributes, the
999 Digest-Auth-Param contains not only the value but also the
1000 parameter name, since the parameter name is unknown to the
1001 RADIUS client. If the Digest header contains several unknown
1002 parameters, then the RADIUS implementation MUST repeat this
1003 attribute and each instance MUST contain one different unknown
1004 Digest parameter/value combination. This attribute MUST ONLY
1005 be used in Access-Request, Access-Challenge, or Access-Accept
1010 Sterman, et al. Standards Track [Page 18]
1012 RFC 4590 RADIUS Digest Authentication July 2006
1016 117 for Digest-Auth-Param
1020 The text consists of the whole parameter, including its name
1021 and the equal sign ('=') and quotes.
1023 3.16. Digest-AKA-Auts Attribute
1026 This attribute holds the auts parameter that is used in the
1027 Digest AKA ([RFC3310]) calculation. It is only used if the
1028 algorithm of the digest-response denotes a version of AKA
1029 Digest [RFC3310]. This attribute MUST only be used in
1030 Access-Request packets.
1032 118 for Digest-AKA-Auts
1036 In Access-Requests, the RADIUS client takes the value of the
1037 auts directive (auts-param according to section 3.4 of
1038 [RFC3310]) without surrounding quotes from the HTTP-style
1039 request it wants to authenticate.
1041 3.17. Digest-Domain Attribute
1044 When a RADIUS client has asked for a nonce, the RADIUS server
1045 MAY send one or more Digest-Domain attributes in its
1046 Access-Challenge packet. The RADIUS client puts them into the
1047 quoted, space-separated list of URIs of the 'domain' directive
1048 of a WWW-Authenticate header. Together with Digest-Realm, the
1049 URIs in the list define the protection space (see [RFC2617],
1050 section 3.2.1) for some HTTP-style protocols. This attribute
1051 MUST only be used in Access-Challenge packets.
1053 119 for Digest-Domain
1057 This attribute consists of a single URI that defines a
1058 protection space component.
1066 Sterman, et al. Standards Track [Page 19]
1068 RFC 4590 RADIUS Digest Authentication July 2006
1071 3.18. Digest-Stale Attribute
1074 This attribute is sent by a RADIUS server in order to notify
1075 the RADIUS client whether it has accepted a nonce. If the
1076 nonce presented by the RADIUS client was stale, the value is
1077 'true' and is 'false' otherwise. The RADIUS client puts the
1078 content of this attribute into a 'stale' directive of the
1079 WWW-Authenticate header in the HTTP-style response to the
1080 request it wants to authenticate. The attribute MUST only be
1081 used in Access-Challenge packets.
1083 120 for Digest-Stale
1087 The attribute has either the value 'true' or 'false' (both
1088 values without surrounding quotes).
1090 3.19. Digest-HA1 Attribute
1093 This attribute is used to allow the generation of an
1094 Authentication-Info header, even if the HTTP-style response's
1095 body is required for the calculation of the rspauth value. It
1096 SHOULD be used in Access-Accept packets if the required quality
1097 of protection ('qop') is 'auth-int'.
1099 This attribute MUST NOT be sent if the qop parameter was not
1100 specified or has a value of 'auth' (in this case, use
1101 Digest-Response-Auth instead).
1103 The Digest-HA1 attribute MUST only be sent by the RADIUS server
1104 or processed by the RADIUS client if at least one of the
1105 following conditions is true:
1107 + The Digest-Algorithm attribute's value is 'MD5-sess' or
1110 + IPsec is configured to protect traffic between RADIUS client
1111 and RADIUS server with IPsec (see Section 8).
1113 This attribute MUST only be used in Access-Accept packets.
1122 Sterman, et al. Standards Track [Page 20]
1124 RFC 4590 RADIUS Digest Authentication July 2006
1128 This attribute contains the hexadecimal representation of H(A1)
1129 as described in [RFC2617], sections 3.1.3, 3.2.1, and 3.2.2.2.
1131 3.20. SIP-AOR Attribute
1134 This attribute is used for the authorization of SIP messages.
1135 The SIP-AOR attribute identifies the URI, the use of which must
1136 be authenticated and authorized. The RADIUS server uses this
1137 attribute to authorize the processing of the SIP request. The
1138 SIP-AOR can be derived from, for example, the To header field
1139 in a SIP REGISTER request (user under registration), or the
1140 From header field in other SIP requests. However, the exact
1141 mapping of this attribute to SIP can change due to new
1142 developments in the protocol. This attribute MUST only be used
1143 when the RADIUS client wants to authorize SIP users and MUST
1144 only be used in Access-Request packets.
1150 The syntax of this attribute corresponds either to a SIP URI
1151 (with the format defined in [RFC3261] or a tel URI (with the
1152 format defined in [RFC3966]).
1154 The SIP-AOR attribute holds the complete URI, including
1155 parameters and other parts. It is up to the RADIUS server what
1156 components of the URI are regarded in the authorization
1159 4. Diameter Compatibility
1161 This document defines support for Digest Authentication in RADIUS. A
1162 companion document "Diameter Session Initiation Protocol (SIP)
1163 Application" [SIP-APP] defines support for Digest Authentication in
1164 Diameter, and addresses compatibility issues between RADIUS and
1178 Sterman, et al. Standards Track [Page 21]
1180 RFC 4590 RADIUS Digest Authentication July 2006
1183 5. Table of Attributes
1185 The following table provides a guide to which attributes may be found
1186 in which kinds of packets, and in what quantity.
1188 +-----+--------+--------+-----------+-----+-------------------------+
1189 | Req | Accept | Reject | Challenge | # | Attribute |
1190 +-----+--------+--------+-----------+-----+-------------------------+
1191 | 1 | 0 | 0 | 0 | 1 | User-Name |
1192 | 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
1193 | 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
1194 | 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
1195 | 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
1196 | 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
1197 | | | | | | (see Note 1, 2) |
1198 | 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
1199 | 0-1 | 0 | 0 | 0 | 108 | Digest-Method |
1200 | 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
1201 | 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
1202 | 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
1203 | | | | | | Note 3) |
1204 | 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
1205 | 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
1206 | 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
1207 | 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
1208 | 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
1209 | 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
1210 | 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
1211 | 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
1212 | 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
1213 | 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
1215 | 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
1216 +-----+--------+--------+-----------+-----+-------------------------+
1220 [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
1221 Digest-Qop is 'auth-int'.
1223 [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
1224 Digest-Qop is 'auth'.
1226 [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
1234 Sterman, et al. Standards Track [Page 22]
1236 RFC 4590 RADIUS Digest Authentication July 2006
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.
1249 INVITE sip:97226491335@example.com SIP/2.0
1250 From: <sip:12345678@example.com>
1251 To: <sip:97226491335@example.com>
1259 Code = 1 (Access-Request)
1261 NAS-IP-Address = c0 0 2 26 (192.0.2.38)
1262 NAS-Port-Type = 5 (Virtual)
1263 User-Name = 12345678
1264 Digest-Method = INVITE
1265 Digest-URI = sip:97226491335@example.com
1266 Message-Authenticator =
1267 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43
1271 Code = 11 (Access-Challenge)
1273 Digest-Nonce = 3bada1a0
1274 Digest-Realm = example.com
1276 Digest-Algorithm = MD5
1277 Message-Authenticator =
1278 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
1282 SIP/2.0 407 Proxy Authentication Required
1283 Proxy-Authenticate: Digest realm="example.com"
1284 ,nonce="3bada1a0",qop=auth,algorithm=MD5
1290 Sterman, et al. Standards Track [Page 23]
1292 RFC 4590 RADIUS Digest Authentication July 2006
1297 ACK sip:97226491335@example.com SIP/2.0
1301 INVITE sip:97226491335@example.com SIP/2.0
1302 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
1303 ,realm="example.com"
1304 ,response="f3ce87e6984557cd0fecc26f3c5e97a4"
1305 ,uri="sip:97226491335@example.com",username="12345678"
1306 ,qop=auth,algorithm=MD5
1307 From: <sip:12345678@example.com>
1308 To: <sip:97226491335@example.com>
1312 Code = 1 (Access-Request)
1314 NAS-IP-Address = c0 0 2 26 (192.0.2.38)
1315 NAS-Port-Type = 5 (Virtual)
1316 User-Name = 12345678
1317 Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
1318 Digest-Realm = example.com
1319 Digest-Nonce = 3bada1a0
1320 Digest-Method = INVITE
1321 Digest-URI = sip:97226491335@example.com
1323 Digest-Algorithm = md5
1324 Digest-Username = 12345678
1325 SIP-AOR = sip:12345678@example.com
1326 Message-Authenticator =
1327 ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff
1331 Code = 2 (Access-Accept)
1333 Digest-Response-Auth =
1334 6303c41b0e2c3e524e413cafe8cce954
1335 Message-Authenticator =
1336 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1
1346 Sterman, et al. Standards Track [Page 24]
1348 RFC 4590 RADIUS Digest Authentication July 2006
1357 ACK sip:97226491335@example.com SIP/2.0
1359 A second example shows the traffic between a web browser (A), web
1360 server (B), and a RADIUS server (C).
1364 GET /index.html HTTP/1.1
1368 Code = 1 (Access-Request)
1370 NAS-IP-Address = c0 0 2 26 (192.0.2.38)
1371 NAS-Port-Type = 5 (Virtual)
1373 Digest-URI = /index.html
1374 Message-Authenticator =
1375 34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7
1379 Code = 11 (Access-Challenge)
1381 Digest-Nonce = a3086ac8
1382 Digest-Realm = example.com
1384 Digest-Algorithm = MD5
1385 Message-Authenticator =
1386 f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
1390 HTTP/1.1 401 Authentication Required
1391 WWW-Authenticate: Digest realm="example.com",
1392 nonce="a3086ac8",qop=auth,algorithm=MD5
1402 Sterman, et al. Standards Track [Page 25]
1404 RFC 4590 RADIUS Digest Authentication July 2006
1409 GET /index.html HTTP/1.1
1410 Authorization: Digest algorithm=MD5,nonce="a3086ac8"
1411 ,realm="example.com"
1412 ,response="f052b68058b2987aba493857ae1ab002"
1413 ,uri="/index.html",username="12345678"
1414 ,qop=auth,algorithm=MD5
1418 Code = 1 (Access-Request)
1420 NAS-IP-Address = c0 0 2 26 (192.0.2.38)
1421 NAS-Port-Type = 5 (Virtual)
1422 User-Name = 12345678
1423 Digest-Response = f052b68058b2987aba493857ae1ab002
1424 Digest-Realm = example.com
1425 Digest-Nonce = a3086ac8
1427 Digest-URI = /index.html
1428 Digest-Username = 12345678
1430 Digest-Algorithm = MD5
1431 Message-Authenticator =
1432 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b
1436 Code = 2 (Access-Accept)
1438 Digest-Response-Auth =
1439 e644aa513effbfe1caff67103ff6433c
1440 Message-Authenticator =
1441 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7
1458 Sterman, et al. Standards Track [Page 26]
1460 RFC 4590 RADIUS Digest Authentication July 2006
1463 7. IANA Considerations
1465 This document serves as an IANA registration request for a number of
1466 values from the RADIUS attribute type number space. The IANA has
1467 assigned the following:
1469 +-------------------------+------------------------+
1470 | placeholder | value assigned by IANA |
1471 +-------------------------+------------------------+
1472 | Digest-Response | 103 |
1473 | Digest-Realm | 104 |
1474 | Digest-Nonce | 105 |
1475 | Digest-Nextnonce | 106 |
1476 | Digest-Response-Auth | 107 |
1477 | Digest-Method | 108 |
1478 | Digest-URI | 109 |
1479 | Digest-Qop | 110 |
1480 | Digest-Algorithm | 111 |
1481 | Digest-Entity-Body-Hash | 112 |
1482 | Digest-CNonce | 113 |
1483 | Digest-Nonce-Count | 114 |
1484 | Digest-Username | 115 |
1485 | Digest-Opaque | 116 |
1486 | Digest-Auth-Param | 117 |
1487 | Digest-AKA-Auts | 118 |
1488 | Digest-Domain | 119 |
1489 | Digest-Stale | 120 |
1490 | Digest-HA1 | 121 |
1492 +-------------------------+------------------------+
1496 8. Security Considerations
1498 The RADIUS extensions described in this document enable RADIUS to
1499 transport the data that is required to perform a digest calculation.
1500 As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
1501 [RFC2617], section 4) in addition to RADIUS security vulnerabilities
1502 described in [RFC2865], section 8, and [RFC3579], section 4.
1504 An attacker compromising a RADIUS client or proxy can carry out
1505 man-in-the-middle attacks even if the paths between A, B and B, C
1506 (Figure 2) have been secured with TLS or IPsec.
1508 The RADIUS server MUST check the Digest-Realm attribute it has
1509 received from a client. If the RADIUS client is not authorized to
1510 serve HTTP-style clients of that realm, it might be compromised.
1514 Sterman, et al. Standards Track [Page 27]
1516 RFC 4590 RADIUS Digest Authentication July 2006
1519 8.1. Denial of Service
1521 RADIUS clients implementing the extension described in this document
1522 may authenticate HTTP-style requests received over the Internet. As
1523 compared with the use of RADIUS to authenticate link-layer network
1524 access, attackers may find it easier to cover their tracks in such a
1527 An attacker can attempt a denial-of-service attack on one or more
1528 RADIUS servers by sending a large number of HTTP-style requests. To
1529 make simple denial-of-service attacks more difficult, the RADIUS
1530 server MUST check whether it has generated the nonce received from an
1531 HTTP-style client. This SHOULD be done statelessly. For example, a
1532 nonce could consist of a cryptographically random part and some kind
1533 of signature provided by the RADIUS client, as described in
1534 [RFC2617], section 3.2.1.
1536 8.2. Confidentiality and Data Integrity
1538 The attributes described in this document are sent in cleartext.
1539 RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
1540 attributes in Access-Challenge messages. A man in the middle can
1541 modify or remove those attributes in a bidding down attack, causing
1542 the RADIUS client to use a weaker authentication scheme than
1545 The Message-Authenticator attribute, described in [RFC3579], section
1546 3.2 MUST be included in Access-Request, Access-Challenge,
1547 Access-Reject, and Access-Accept messages that contain attributes
1548 described in this specification.
1550 The Digest-HA1 attribute contains no random components if the
1551 algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
1552 attacks easier and enables replay attacks.
1554 Some parameter combinations require the protection of RADIUS packets
1555 against eavesdropping and tampering. Implementations SHOULD try to
1556 determine automatically whether IPsec is configured to protect
1557 traffic between the RADIUS client and the RADIUS server. If this is
1558 not possible, the implementation checks a configuration parameter
1559 telling it whether IPsec will protect RADIUS traffic. The default
1560 value of this configuration parameter tells the implementation that
1561 RADIUS packets will not be protected.
1563 HTTP-style clients can use TLS with server side certificates together
1564 with HTTP-Digest Authentication. Instead of TLS, IPsec can be used,
1565 too. TLS or IPsec secure the connection while Digest Authentication
1566 authenticates the user. The RADIUS transaction can be regarded as
1570 Sterman, et al. Standards Track [Page 28]
1572 RFC 4590 RADIUS Digest Authentication July 2006
1575 one leg on the path between the HTTP-style client and the HTTP-style
1576 server. To prevent RADIUS from representing the weak link, a RADIUS
1577 client receiving an HTTP-style request via TLS or IPsec could use an
1578 equally secure connection to the RADIUS server. There are several
1579 ways to achieve this, for example:
1581 o The RADIUS client may reject HTTP-style requests received over TLS
1584 o The RADIUS client may require that traffic be sent and received
1587 RADIUS over IPsec, if used, MUST conform to the requirements
1588 described in [RFC3579], section 4.2.
1592 We would like to acknowledge Kevin McDermott (Cisco Systems) for
1593 providing comments and experimental implementation.
1595 Many thanks to all reviewers, especially to Miguel Garcia, Jari
1596 Arkko, Avi Lior, and Jun Wang.
1600 10.1. Normative References
1602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1603 Requirement Levels", BCP 14, RFC 2119, March 1997.
1605 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1606 Leach, P., Luotonen, A., and L. Stewart, "HTTP
1607 Authentication: Basic and Digest Access Authentication",
1608 RFC 2617, June 1999.
1610 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1611 "Remote Authentication Dial In User Service (RADIUS)", RFC
1614 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1615 A., Peterson, J., Sparks, R., Handley, M., and E.
1616 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1619 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
1620 Dial In User Service) Support For Extensible
1621 Authentication Protocol (EAP)", RFC 3579, September 2003.
1626 Sterman, et al. Standards Track [Page 29]
1628 RFC 4590 RADIUS Digest Authentication July 2006
1631 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
1632 3966, December 2004.
1634 10.2. Informative References
1636 [SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol
1637 (SIP) Application", Work in Progress), April 2006.
1639 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
1640 Protocol (CHAP)", RFC 1994, August 1996.
1642 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
1643 Luotonen, A., Sink, E., and L. Stewart, "An Extension to
1644 HTTP : Digest Access Authentication", RFC 2069, January
1647 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1648 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1650 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
1651 Extensions (S/MIME) Version 3.1 Message Specification",
1652 RFC 3851, July 2004.
1654 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
1655 Protocol (HTTP) Digest Authentication Using Authentication
1656 and Key Agreement (AKA)", RFC 3310, September 2002.
1658 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
1659 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
1682 Sterman, et al. Standards Track [Page 30]
1684 RFC 4590 RADIUS Digest Authentication July 2006
1695 EMail: baruch@kayote.com
1700 Jerusalem Technology Park
1705 EMail: dscreat@dscreat.com
1714 EMail: david@kayote.com
1721 Research Triangle Park NC 27709
1724 EMail: dwilli@cisco.com
1729 Deutsche Telekom Allee 7
1733 EMail: beckw@t-systems.com
1738 Sterman, et al. Standards Track [Page 31]
1740 RFC 4590 RADIUS Digest Authentication July 2006
1743 Full Copyright Statement
1745 Copyright (C) The Internet Society (2006).
1747 This document is subject to the rights, licenses and restrictions
1748 contained in BCP 78, and except as set forth therein, the authors
1749 retain all their rights.
1751 This document and the information contained herein are provided on an
1752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1754 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1755 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1756 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1759 Intellectual Property
1761 The IETF takes no position regarding the validity or scope of any
1762 Intellectual Property Rights or other rights that might be claimed to
1763 pertain to the implementation or use of the technology described in
1764 this document or the extent to which any license under such rights
1765 might or might not be available; nor does it represent that it has
1766 made any independent effort to identify any such rights. Information
1767 on the procedures with respect to rights in RFC documents can be
1768 found in BCP 78 and BCP 79.
1770 Copies of IPR disclosures made to the IETF Secretariat and any
1771 assurances of licenses to be made available, or the result of an
1772 attempt made to obtain a general license or permission for the use of
1773 such proprietary rights by implementers or users of this
1774 specification can be obtained from the IETF on-line IPR repository at
1775 http://www.ietf.org/ipr.
1777 The IETF invites any interested party to bring to its attention any
1778 copyrights, patents or patent applications, or other proprietary
1779 rights that may cover technology that may be required to implement
1780 this standard. Please address the information to the IETF at
1785 Funding for the RFC Editor function is provided by the IETF
1786 Administrative Support Activity (IASA).
1794 Sterman, et al. Standards Track [Page 32]