Request for Comments: 4590 Kayote Networks
Category: Standards Track D. Sadolevsky
SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
July 2006
RADIUS Extension for Digest Authentication
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines an extension to the Remote Authentication
Dial-In User Service (RADIUS) protocol to enable support of Digest
Authentication, for use with HTTP-style protocols like the Session
Initiation Protocol (SIP) and HTTP.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Motivation .................................................3
1.3. Overview ...................................................4
2. Detailed Description ............................................6
2.1. RADIUS Client Behavior .....................................6
2.1.1. Credential Selection ................................6
2.1.2. Constructing an Access-Request ......................6
2.1.3. Constructing an Authentication-Info Header ..........7
2.1.4. Failed Authentication ...............................8
2.1.5. Obtaining Nonces ....................................9
2.2. RADIUS Server Behavior .....................................9
2.2.1. General Attribute Checks ............................9
2.2.2. Authentication .....................................10
2.2.3. Constructing the Reply .............................11
3. New RADIUS Attributes ..........................................12
3.1. Digest-Response attribute .................................12
3.2. Digest-Realm Attribute ....................................13
3.3. Digest-Nonce Attribute ....................................13
3.4. Digest-Response-Auth Attribute ............................14
3.5. Digest-Nextnonce Attribute ................................14
3.6. Digest-Method Attribute ...................................14
3.7. Digest-URI Attribute ......................................15
3.8. Digest-Qop Attribute ......................................15
3.9. Digest-Algorithm Attribute ................................16
3.10. Digest-Entity-Body-Hash Attribute ........................16
3.11. Digest-CNonce Attribute ..................................17
3.12. Digest-Nonce-Count Attribute .............................17
3.13. Digest-Username Attribute ................................17
3.14. Digest-Opaque Attribute ..................................18
3.15. Digest-Auth-Param Attribute ..............................18
3.16. Digest-AKA-Auts Attribute ................................19
3.17. Digest-Domain Attribute ..................................19
3.18. Digest-Stale Attribute ...................................20
3.19. Digest-HA1 Attribute .....................................20
3.20. SIP-AOR Attribute ........................................21
4. Diameter Compatibility .........................................21
5. Table of Attributes ............................................22
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................27
8.1. Denial of Service .........................................28
8.2. Confidentiality and Data Integrity ........................28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
1. Introduction
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The use of normative requirement key words in this document shall
apply only to RADIUS client and RADIUS server implementations that
include the features described in this document. This document
creates no normative requirements for existing implementations.
HTTP-style protocol
The term ’HTTP-style’ denotes any protocol that uses HTTP-like
headers and uses HTTP Digest Authentication as described in
[RFC2617]. Examples are HTTP and the Session Initiation
Protocol (SIP).
NAS
Network Access Server, the RADIUS client.
nonce
An unpredictable value used to prevent replay attacks. The
nonce generator may use cryptographic mechanisms to produce
nonces it can recognize without maintaining state.
protection space
HTTP-style protocols differ in their definition of the
protection space. For HTTP, it is defined as the combination
of realm and canonical root URL of the requested resource for
which the use is authorized by the RADIUS server. In the case
of SIP, the realm string alone defines the protection space.
SIP UA
SIP User Agent, an Internet endpoint that uses the Session
Initiation Protocol.
SIP UAS
SIP User Agent Server, a logical entity that generates a
response to a SIP (Session Initiation Protocol) request.
1.2. Motivation
The HTTP Digest Authentication mechanism, defined in [RFC2617], was
subsequently adapted for use with SIP [RFC3261]. Due to the
limitations and weaknesses of Digest Authentication (see [RFC2617],
section 4), additional authentication and encryption mechanisms are
defined in SIP [RFC3261], including Transport Layer Security (TLS)
[RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest
Authentication support is mandatory in SIP implementations, and
Digest Authentication is the preferred way for a SIP UA to
authenticate itself to a proxy server. Digest Authentication is used
in other protocols as well.
To simplify the provisioning of users, there is a need to support
this authentication mechanism within Authentication, Authorization,
and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
[RFC3588].
This document defines an extension to the RADIUS protocol to enable
support of Digest Authentication for use with SIP, HTTP, and other
HTTP-style protocols using this authentication method. Support for
Digest mechanisms such as Authentication and Key Agreement (AKA)
[RFC3310] is also supported. A companion document [SIP-APP] defines
support for Digest Authentication within Diameter.
1.3. Overview
HTTP Digest is a challenge-response protocol used to authenticate a
client’s request to access some resource on a server. Figure 1 shows
a single HTTP Digest transaction.
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+
Figure 1: Digest operation without RADIUS
If the client sends a request without any credentials (1), the server
will reply with an error response (2) containing a nonce. The client
creates a cryptographic digest from parts of the request, from the
nonce it received from the server, and from a shared secret. The
client re-transmits the request (3) to the server, but now includes
the digest within the packet. The server does the same digest
calculation as the client and compares the result with the digest it
received in (3). If the digest values are identical, the server
grants access to the resource and sends a positive response to the
client (4). If the digest values differ, the server sends a negative
response to the client (4).
Instead of maintaining a local user database, the server could use
RADIUS to access a centralized user database. However, RADIUS
[RFC2865] does not include support for HTTP Digest Authentication.
The RADIUS client cannot use the User-Password attribute, since it
does not receive a password from the HTTP-style client. The
CHAP-Challenge and CHAP-Password attributes described in [RFC1994]
are also not suitable since the CHAP algorithm is not compatible with
HTTP Digest.
This document defines new attributes that enable the RADIUS server to
perform the digest calculation defined in [RFC2617], providing
support for Digest Authentication as a native authentication
mechanism within RADIUS.
The nonces required by the digest algorithm are generated by the
RADIUS server. Generating them in the RADIUS client would save a
round-trip, but introduce security and operational issues. Some
digest algorithms -- e.g., AKA [RFC3310] -- would not work.
Figure 2 depicts a scenario in which the HTTP-style server defers
authentication to a RADIUS server. Entities A and B communicate
using HTTP or SIP, while entities B and C communicate using RADIUS.
HTTP/SIP RADIUS
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
Figure 2: HTTP Digest over RADIUS
The entities have the following roles:
A: HTTP client / SIP UA
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
acting also as a RADIUS NAS
C: RADIUS server
The following messages are sent in this scenario:
A sends B an HTTP/SIP request without an authorization header (step
1). B sends an Access-Request packet with the newly defined
Digest-Method and Digest-URI attributes but without a Digest-Nonce
attribute to the RADIUS server, C (step 2). C chooses a nonce and
responds with an Access-Challenge (step 3). This Access-Challenge
contains Digest attributes, from which B takes values to construct an
HTTP/SIP "(Proxy) Authorization required" response. B sends this
response to A (step 4). A resends its request with its credentials
(step 5). B sends an Access-Request to C (step 6). C checks the
credentials and replies with Access-Accept or Access-Reject (step 7).
Depending on C’s result, B processes A’s request or rejects it with a
"(Proxy) Authorization required" response (step 8).
2. Detailed Description
2.1. RADIUS Client Behavior
The attributes described in this document are sent in cleartext.
Therefore, were a RADIUS client to accept secure connections (HTTPS
or SIPS) from HTTP-style clients, this could result in information
intentionally protected by HTTP-style clients being sent in the clear
during RADIUS exchange.
2.1.1. Credential Selection
On reception of an HTTP-style request message, the RADIUS client
checks whether it is authorized to authenticate the request. Where
an HTTP-style request traverses several proxies and each of the
proxies requests to authenticate the HTTP-style client, the request
at the HTTP-style server may contain multiple credential sets.
The RADIUS client can use the ’realm’ directive in HTTP to determine
which credentials are applicable. Where none of the realms are of
interest, the RADIUS client MUST behave as though no relevant
credentials were sent. In all situations, the RADIUS client MUST
send zero or exactly one credential to the RADIUS server. The RADIUS
client MUST choose the credential of the (Proxy-)Authorization header
if the realm directive matches its locally configured realm.
2.1.2. Constructing an Access-Request
If a matching (Proxy-)Authorization header is present and contains
HTTP Digest information, the RADIUS client checks the ’nonce’
parameter.
If the RADIUS client recognizes the nonce, it takes the header
directives and puts them into a RADIUS Access-Request packet. It
puts the ’response’ directive into a Digest-Response attribute and
the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username,
and opaque directives into the respective Digest-Realm, Digest-Nonce,
Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,
Digest-Nonce-Count, Digest-Username, and Digest-Opaque attributes.
The RADIUS client puts the request method into the Digest-Method
attribute.
Due to syntactic requirements, HTTP-style protocols have to escape
with backslash all quote and backslash characters in contents of HTTP
Digest directives. When translating directives into RADIUS
attributes, the RADIUS client only removes the surrounding quotes
where present. See Section 3 for an example.
If the Quality of Protection (qop) directive’s value is ’auth-int’,
the RADIUS client calculates H(entity-body) as described in
[RFC2617], Section 3.2.1, and puts the result in a
Digest-Entity-Body-Hash attribute.
The RADIUS client adds a Message-Authenticator attribute, defined in
[RFC3579], and sends the Access-Request packet to the RADIUS server.
The RADIUS server processes the packet and responds with an
Access-Accept or an Access-Reject.
2.1.3. Constructing an Authentication-Info Header
After having received an Access-Accept from the RADIUS server, the
RADIUS client constructs an Authentication-Info header:
o If the Access-Accept packet contains a Digest-Response-Auth
attribute, the RADIUS client checks the Digest-Qop attribute:
* If the Digest-Qop attribute’s value is ’auth’ or not specified,
the RADIUS client puts the Digest-Response-Auth attribute’s
content into the Authentication-Info header’s ’rspauth’
directive of the HTTP-style response.
* If the Digest-Qop attribute’s value is ’auth-int’, the RADIUS
client ignores the Access-Accept packet and behaves as if it
had received an Access-Reject packet (Digest-Response-Auth
can’t be correct as the RADIUS server does not know the
contents of the HTTP-style response’s body).
o If the Access-Accept packet contains a Digest-HA1 attribute, the
RADIUS client checks the ’qop’ and ’algorithm’ directives in the
Authorization header of the HTTP-style request it wants to
authorize:
* If the ’qop’ directive is missing or its value is ’auth’, the
RADIUS client ignores the Digest-HA1 attribute. It does not
include an Authentication-Info header in its HTTP-style
response.
* If the ’qop’ directive’s value is ’auth-int’ and at least one
of the following conditions is true, the RADIUS client
calculates the contents of the HTTP-style response’s ’rspauth’
directive:
+ The algorithm directive’s value is ’MD5-sess’ or
’AKAv1-MD5-sess’.
+ IP Security (IPsec) is configured to protect traffic between
the RADIUS client and RADIUS server with IPsec (see
Section 8).
It creates the HTTP-style response message and calculates the
hash of this message’s body. It uses the result and the
Digest-URI attribute’s value of the corresponding
Access-Request packet to perform the H(A2) calculation. It
takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and
Digest-Qop values of the corresponding Access-Request and the
Digest-HA1 attribute’s value to finish the computation of the
’rspauth’ value.
o If the Access-Accept packet contains neither a
Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client
will not create an Authentication-Info header for its HTTP-style
response.
When the RADIUS server provides a Digest-Nextnonce attribute in the
Access-Accept packet, the RADIUS client puts the contents of this
attribute into a ’nextnonce’ directive. Now it can send an
HTTP-style response.
2.1.4. Failed Authentication
If the RADIUS client did receive an HTTP-style request without a
(Proxy-)Authorization header matching its locally configured realm
value, it obtains a new nonce and sends an error response (401 or
407) containing a (Proxy-)Authenticate header.
If the RADIUS client receives an Access-Challenge packet in response
to an Access-Request containing a Digest-Nonce attribute, the RADIUS
server did not accept the nonce. If a Digest-Stale attribute is
present in the Access-Challenge and has a value of ’true’ (without
surrounding quotes), the RADIUS client sends an error response (401
or 407) containing a WWW-/Proxy-Authenticate header with the
directive ’stale’ and the digest directives derived from the Digest-*
attributes.
If the RADIUS client receives an Access-Reject from the RADIUS
server, it sends an error response to the HTTP-style request it has
received. If the RADIUS client does not receive a response, it
retransmits or fails over to another RADIUS server as described in
[RFC2865].
2.1.5. Obtaining Nonces
The RADIUS client has two ways to obtain nonces: it has received one
in a Digest-Nextnonce attribute of a previously received
Access-Accept packet or it asks the RADIUS server for one. To do the
latter, it sends an Access-Request containing a Digest-Method and a
Digest-URI attribute but without a Digest-Nonce attribute. It adds a
Message-Authenticator (see [RFC3579]) attribute to the Access-Request
packet. The RADIUS server chooses a nonce and responds with an
Access-Challenge containing a Digest-Nonce attribute.
The RADIUS client constructs a (Proxy-)Authenticate header using the
received Digest-Nonce and Digest-Realm attributes to fill the nonce
and realm directives. The RADIUS server can send Digest-Qop,
Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the
Access-Challenge carrying the nonce. If these attributes are
present, the client MUST use them.
2.2. RADIUS Server Behavior
If the RADIUS server receives an Access-Request packet with a
Digest-Method and a Digest-URI attribute but without a Digest-Nonce
attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce
attribute and sends it in an Access-Challenge packet to the RADIUS
client. The RADIUS server MUST add Digest-Realm,
Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm
and one or more Digest-Qop, and MAY add Digest-Domain or
Digest-Opaque attributes to the Access-Challenge packet.
2.2.1. General Attribute Checks
If the RADIUS server receives an Access-Request packet containing a
Digest-Response attribute, it looks for the following attributes:
Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
Digest-Algorithm, and Digest-Username. Depending on the content of
Digest-Algorithm and Digest-Qop, it looks for
Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts, too.
See [RFC2617] and [RFC3310] for details. If the Digest-Algorithm
attribute is missing, ’MD5’ is assumed. If the RADIUS server has
issued a Digest-Opaque attribute along with the nonce, the
Access-Request MUST have a matching Digest-Opaque attribute.
If mandatory attributes are missing, it MUST respond with an
Access-Reject packet.
The RADIUS server removes ’\’ characters that escape quote and ’\’
characters from the text values it has received in the Digest-*
attributes.
If the mandatory attributes are present, the RADIUS server MUST check
if the RADIUS client is authorized to serve users of the realm
mentioned in the Digest-Realm attribute. If the RADIUS client is not
authorized, the RADIUS server MUST send an Access-Reject. The RADIUS
server SHOULD log the event so as to notify the operator, and MAY
take additional action such as sending an Access-Reject in response
to all future requests from this client, until this behavior is reset
by management action.
The RADIUS server determines the age of the nonce in Digest-Nonce by
using an embedded time-stamp or by looking it up in a local table.