Network Working Group B. Sterman
Internet-Draft Kayote Networks
Expires: August 6, 2004 D. Sadolevsky
SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
February 6, 2004
RADIUS Extension for Digest Authentication
draft-sterman-aaa-sip-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Basic and Digest authentication schemes are widely used in
protocols such as SIP and HTTP . RADIUS is a protocol for back end
authentication. RADIUS supports Basic authentication natively, as
well as several other authentication schemes, such as CHAP, but does
not support Digest authentication scheme. This document describes
Sterman, et al. Expires August 6, 2004 [Page 1]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
an extension to RADIUS for Digest authentication and provides a
scenario of Digest user authentication.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . 7
2.1 Digest-Response attribute . . . . . . . . . . . . . . . . . 7
2.2 Digest-Attributes attribute . . . . . . . . . . . . . . . . 8
2.3 Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 QOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9 Body-Digest . . . . . . . . . . . . . . . . . . . . . . . . 11
2.10 CNonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11 Nonce-Count . . . . . . . . . . . . . . . . . . . . . . . . 12
2.12 User-Name . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Detailed Description . . . . . . . . . . . . . . . . . . . . 14
3.1 RADIUS Client Behaviour . . . . . . . . . . . . . . . . . . 14
3.2 RADIUS Server Behaviour . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 16
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 26
Sterman, et al. Expires August 6, 2004 [Page 2]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
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].
1.2 Motivation
Digest authentication is a simple authentication mechanism for HTTP
and SIP. While it was not too successful in HTTP environments, it is
the only SIP authentication mechanism that has been widely adopted.
Due to the weaknesses of Digest authentication (see Section 4),
PKI-based authentication and encryption mechanisms have been
introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However,
most SIP user agents that support TLS don't send client certificates.
SIP with S/MIME is lacking support, too: even two years after the
inclusion of S/MIME into SIP, almost no implementations exist.
SIP service providers whishing to authenticate their clients have the
following options: they can
o build a PKI and wait for interopable S/MIME capable SIP
implementations,
o build a PKI and wait for SIP implementations supporting TLS with
client-side certificates,
o replace their existing RADIUS infrastructure with DIAMETER
[RFC3588], when DIAMETER supports HTTP Digest authentication,
o use TLS for server authentication and plaintext passwords (Basic)
for client authentication, which can be done with standard RADIUS,
o upgrade their existing RADIUS servers with the functionality
described in this document
PKI solutions only cover authentication, not authorization (EAP could
change this, but its use with SIP is not standardized). TLS / Basic
authentication works only with the limited number of SIP devices that
implement TLS. Basic authentication has been deprecated for SIP in
[RFC3261].
Current RADIUS-based AAA infrastructures have been built and debugged
over years. Deficiencies of RADIUS have been mitigated with
proprietary (ie costly) extensions. Operators are therefore reluctant
to replace their RADIUS infrastructure in order to enable a single
Sterman, et al. Expires August 6, 2004 [Page 3]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
new authentication mechanism.
Given the complexity of S/MIME, simple clients will continue to
support HTTP digest authentication only. Its interopability with a
back-end authentication protocol such as RADIUS is needed.
Operators that are about to replace their RADIUS-based AAA
infrastructure are strongly recommended to use DIAMETER.
1.3 Scenario
Figure 1 depicts the scenario that is relevant for this document. It
shows a generic case where entities A and B communicate in the
front-end using protocols such as HTTP/SIP, while entities B and C
communicate in the back-end using RADIUS.
HTTP/SIP RADIUS
+-----+ (1) +-----+ +-----+
| |==========>| | | |
| | (2) | | | |
| |<==========| | | |
| | (3) | | | |
| |==========>| | | |
| A | | B | (4) | C |
| | | |---------->| |
| | | | (5) | |
| | | |<----------| |
| | (6) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
Figure 1: Overview of operation
The roles played by the entities in this scenario are as follows:
A: HTTP client / SIP UA
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
Sterman, et al. Expires August 6, 2004 [Page 4]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
acting also as a RADIUS NAS
C: RADIUS server
The relevant order of messages sent in this scenario is as
follows:
A sends B an HTTP/SIP request without authorization header (step 1).
B challenges A sending an HTTP/SIP "(Proxy) Authorization required"
response containing a locally generated nonce (step 2). A sends B
an HTTP/SIP request with authorization header (step 3). B sends C a
RADIUS Access-Request with attributes described in this document
(step 4). C responds to B with a RADIUS Access-Accept/Access-Reject
response (step 5). If credentials were accepted B receives an
Access-Accept response and the message sent from A is considered
authentic. If B receives an Access-Reject response, however, B then
responds to A with a "(Proxy) Authorization required" response (step
6).
1.4 Approach
The approach taken here is to extend RADIUS to support Digest
authentication by mimicking its native support for CHAP
authentication. According to [RFC2865], the RADIUS server
distinguishes between different authentication schemes by looking at
the presence of an attribute specific for that scheme. For the three
natively supported authentication schemes, these attributes are:
User-Password for PAP (or any other clear-text password scheme),
CHAP-Password for CHAP, and State + User- Password for
challenge-response scheme. This document adds another attribute to be
used in this role: Digest-Response. Also according to [RFC2865], "An
Access-Request packet MUST contain either a User-Password or a
CHAP-Password or a State. It MUST NOT contain both a User-Password
and a CHAP-Password. If future extensions allow other kinds of
authentication information to be conveyed, the attribute for that can
be used instead of User-Password or CHAP-Password." The
Digest-Response introduced here therefore can be used instead of
User-Password or CHAP-Password.
The HTTP Authentication parameters found in the Proxy-Authorization
or Authorization request header are mapped into two newly defined
RADIUS attributes. The Digest-Response attribute and the
Digest-Attributes attribute carrying multiple HTTP Digest parameters
as subattributes. These two new RADIUS attributes are defined in the
document together with some other information required for
calculating the correct digest response on the RADIUS server with
exception of the password, which the RADIUS server is assumed to be
able to retrieve from a data store given the username. The structure
Sterman, et al. Expires August 6, 2004 [Page 5]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
of Digest-Response, the structure of Digest-Attributes and the
mapping/meaning of its subattributes are described in the next
chapter.
Sterman, et al. Expires August 6, 2004 [Page 6]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
2. New RADIUS attributes
DIG-RES and DIG-ATTRS are placeholders for values that will be
assigned by IANA, if this specification becomes a working group
document.
2.1 Digest-Response attribute
If this attribute is present, the RADIUS server SHOULD view the
Access-Request as a Digest one. The following paragraphs apply for
RADIUS servers implementing this specification.
Access-Request packets MUST contain an Digest-Response attribute. In
Access-Request packets, this attribute contains the digest taken from
request-digest field in Digest (Proxy)Authorization header, as
received from the HTTP or SIP client.
Access-Accept packets MUST contain a Digest-Response attribute. In
Access-Accept packets, this attribute contains a digest that can be
used for generating Authentication-Info headers. The calculation of
this digest is described [RFC2617], section 3.2.3. A summary of the
Digest-Response attribute format is shown below. The fields are
transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DIG-RES for Digest-Response. Early implementations have used
the experimental type 206.
Length
34
String
Sterman, et al. Expires August 6, 2004 [Page 7]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
In Access-Requests, this string proves the user knows a
password. The String field is 32 octets long and contains
hexadecimal representation of 16 octet digest value as it was
calculated by the authenticated client. The String field
SHOULD be copied from request-digest of digest-response
([RFC2617]). In Access-Accepts, this string proves the RADIUS
server knows the password. The RADIUS server calculates a
digest according to section 3.2.3 of [RFC2617] and copies the
result into this string.
2.2 Digest-Attributes attribute
This attribute contains subattributes which indicate the values
contained in a Digest (Proxy)Authorization header and other
information necessary to calculate the correct digest response. It
is only used in Access- Request packets. There can be multiple
Digest-Attributes attributes contained in one Access-Request packet.
In this case RADIUS server MUST interpret a concatenation of their
values as if it came in one attribute.
A summary of the Digest-Attributes attribute format is shown below.
The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DIG-ATTRS for Digest-Attributes. Early implementations have
used the experimental type 207.
Length
>= 5
String
Sterman, et al. Expires August 6, 2004 [Page 8]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
The String field is 3 or more octets and contains one or more
subattributes. Format of a subattribute is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Sub-Type | Sub-Length | Sub-Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Sub-Type
Subattribute type. Meanings of the following defined types
can be found in section Section 2.3
1 Realm
2 Nonce
3 Method
4 URI
5 QOP
6 Algorithm
7 Body-Digest
8 CNonce
9 Nonce-Count
10 User-Name
Sub-Length >= 3
Sub-Value Subattribute-specific value
2.3 Realm
Sterman, et al. Expires August 6, 2004 [Page 9]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Sub-Type
1
Sub-Length
>= 3
Sub-Value
String, copied from realm-value of digest-response ([RFC2617])
2.4 Nonce
Sub-Type
2
Sub-Length
>= 3
Sub-Value
String, copied from realm-value of digest-response ([RFC2617])
2.5 Method
Sub-Type
3
Sub-Length
>= 3
Sub-Value
String, copied from digest-response. Method is taken from HTTP
or SIP request ([RFC2616], [RFC3261])
2.6 URI
Sterman, et al. Expires August 6, 2004 [Page 10]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Sub-Type
4
Sub-Length
>= 3
Sub-Value
String, copied from digest-uri-value of digest-response
([RFC2617])
2.7 QOP
Sub-Type
5
Sub-Length
>= 3
Sub-Value
String, copied from qop-value of digest-response ([RFC2617])
2.8 Algorithm
Sub-Type
6
Sub-Length
>= 3
Sub-Value
String, "MD5" | "MD5-sess" | token, copied from of
digest-response ([RFC2617])
2.9 Body-Digest
Sterman, et al. Expires August 6, 2004 [Page 11]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Sub-Type
7
Sub-Length
34
Sub-Value
String, hexadecimal representation of a digest calculated over
entity-body of HTTP/SIP request ([RFC2616], [RFC3261]).
Computed by entity B in figure Figure 1. This attribute is not
part of the HTTP Digest response. See [RFC2617] section
3.2.2.3.
2.10 CNonce
Sub-Type
8
Sub-Length
>= 3
Sub-Value
String copied from cnonce-value of digest-response ([RFC2617])
2.11 Nonce-Count
Sub-Type
9
Sub-Length
10
Sub-Value
String, 8LHEX, copied from nc-value of digest-response
([RFC2617])
Sterman, et al. Expires August 6, 2004 [Page 12]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
2.12 User-Name
Sub-Type
10
Sub-Length
>= 3
Sub-Value
String copied from username-value of digest-response
([RFC2617]) the RADIUS server SHOULD NOT use this value for
password finding, but only for digest calculation purpose. In
order to find the user record containing password, the RADIUS
server SHOULD use the value of the User-Name _attribute_
Sterman, et al. Expires August 6, 2004 [Page 13]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
3. Detailed Description
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 SIP.
3.1 RADIUS Client Behaviour
A RADIUS client without an encrypted or otherwise secured connection
to its RADIUS server only accepts unsecured connections from its
HTTP-style clients (or else the clients would have a false sense of
security).
The RADIUS client examines the (Proxy-)Authorization header of an
incoming HTTP-style request message. If this header is present and
contains HTTP digest information, the RADIUS client checks the
'nonce' parameter. If the 'nonce' parameter has not been issued by
the RADIUS client, it responds with a 401 (Unauthorized) or 407
(Proxy Authentication Required) to the HTTP-style client. In this
error response, the RADIUS client issues a new nonce.
If the RADIUS client recognizes the nonce, it takes the header
parameters and puts them into a RADIUS Access-Request message. It
puts the 'response' parameter into a Digest-Response attribute and
the realm / nonce / qop / algorithm / cnonce / nc / username into a
Digest-Attributes attribute. The request URI and the request method
are put into the Digest-Attributes attribute, too. Now, the RADIUS
client sends the Access-Request message to the RADIUS server.
The RADIUS server processes the message and responds with an
Access-Accept or an Access-Reject. If the RADIUS client receives an
Access-Accept, it examines the Digest-Response attribute contained in
the message. It constructs an Authentication-Info header and puts the
contents of Digest-Response into the 'rspauth' header parameter. Now
it can send a HTTP-style response.
If the RADIUS client did not receive a (Proxy-)Authorization header
from its HTTP-style client, it generates a new nonce and sends an
error response (401 or 407) containing a (Proxy-)Authenticate header.
If the RADIUS client receives an Access-Reject or no response from
the RADIUS server, it sends an error response to the HTTP-style
request it has received.
3.2 RADIUS Server Behaviour
If the RADIUS server receives an Access-Request message containing a
Digest-Response attribute, it looks for the Digest-Attributes
Sterman, et al. Expires August 6, 2004 [Page 14]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
attribute. If it does not find this attribute, it responds with an
Access-Reject message. If the Digest-Attribute attribute is present,
the RADIUS server calculates the digest response as described in
[RFC2617]. To look up the password, the RADIUS server uses the RADIUS
User-Name attribute. All other values are taken from the
Digest-Attribute attribute. If the calculated digest response equals
the string received in the Digest-Response attribute, the
authentication was successful. If not, the RADIUS server responds
with an Access-Reject.
If the authentication was successful, the RADIUS server calculates a
Digest-Response attribute that can be used by the RADIUS client to
construct an Authentication-Info header. The calculation of this
response is described in [RFC2617], section 3.2.3. The
Digest-Response attribute is send to the RADIUS client in an
Access-Accept message.
Sterman, et al. Expires August 6, 2004 [Page 15]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
4. Security Considerations
The RADIUS extensions described in this document make RADIUS a
transport protocol for the data that is required to perform a digest
calculation. It adds the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or
here [1])).
If an attacker gets access to a RADIUS client, it can perform
man-in-the-middle attacks even if the connections between A, B and B,
C (Figure 1) have been secured with TLS or IPSec.
SIP or HTTP requests occur much more frequently than dial-in
requests. RADIUS servers implementing this specification must meet
that additional performance requirements. An attacker could try to
overload the RADIUS infrastructure by excessively sending SIP or HTTP
requests. This kind of attack was more difficult when RADIUS was just
used for dial-in authentication: the attacker could be identified by
the DSL / Cable interface or with some help of the PSTN provider.
To make simple denial of service attacks more difficult, RADIUS
clients MUST check if nonces received from a client have been issued
by them. This SHOULD be done statelessly. For example, a nonce could
consist of a cryptographically random part and some kind of signature
of the RADIUS client, as described in [RFC2617], section 3.2.1.
HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. IPSec can be used in a similar way.
TLS or IPSec secure the connection while Digest Authentication
authenticates the user. If a RADIUS client accepts such connections,
it MUST have a secure connection to the RADIUS server.
Sterman, et al. Expires August 6, 2004 [Page 16]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
5. Example
This is an example sniffed from the traffic between HearMe softphone
(A), Cisco Systems Proxy Server (B) and deltathree RADIUS server (C)
(The communication between Cisco Systems Proxy Server and a SIP PSTN
gateway is omitted for brevity):
A->B
INVITE sip:97226491335@213.137.69.38 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38
Contact: sip:12345678@213.137.67.67:5061
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
CSeq: 2544265 INVITE
Content-Length: 150
Content-Type: application/sdp
User-Agent: HearMe SoftPHONE
v=0
o=HearMe 2544265 2544265 IN IP4 213.137.67.67
s=HearMe
c=IN IP4 213.137.67.67
t=0 0
m=audio 8000 RTP/AVP 0 4
a=ptime:20
a=x-ssrc:009aa330
B->A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 213.137.67.67:5061
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38
CSeq: 2544265 INVITE
Content-Length: 0
B->A
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 213.137.67.67:5061
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
Sterman, et al. Expires August 6, 2004 [Page 17]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
CSeq: 2544265 INVITE
Proxy-Authenticate: DIGEST realm="deltathree"
,nonce="3bada1a0", algorithm="md5"
Content-Length: 0
A->B
ACK sip:97226491335@213.137.69.38 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
CSeq: 2544265 ACK
Content-Length: 0
A->B
INVITE sip:97226491335@213.137.69.38 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38
Contact: sip:12345678@213.137.67.67:5061
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
CSeq: 2544266 INVITE
Content-Length: 150
Content-Type: application/sdp
User-Agent: HearMe SoftPHONE
Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0"
,opaque="",realm="deltathree"
,response="2ae133421cda65d67dc50d13ba0eb9bc"
,uri="sip:97226491335@213.137.69.38",username="12345678"
v=0
o=HearMe 2544265 2544265 IN IP4 213.137.67.67
s=HearMe
c=IN IP4 213.137.67.67
t=0 0
m=audio 8000 RTP/AVP 0 4
a=ptime:20
a=x-ssrc:009aa330
B->C
Sterman, et al. Expires August 6, 2004 [Page 18]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Code = 1 (Access-Request)
Identifier = 1
Length = 164
Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e
Attributes:
NAS-IP-Address = d5 89 45 26 (213.137.69.38)
NAS-Port-Type = 5 (Virtual)
User-Name = "12345678"
Digest-Response (206) = "2ae133421cda65d67dc50d13ba0eb9bc"
Digest-Attributes (207) = [Realm (1) = "deltathree"]
Digest-Attributes (207) = [Nonce (2) = "3bada1a0"]
Digest-Attributes (207) = [Method (3) = "INVITE"]
Digest-Attributes (207) =
[URI (4) = "sip:97226491335@213.137.69.38"]
Digest-Attributes (207) = [Algorithm (5) = "md5"]
Digest-Attributes (207) = [User-Name (10) = "12345678"]
C->B
Code = 2 (Access-Accept)
Identifier = 1
Length = 20
Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d
Attributes:
Digest-Response (206) = "6303c41b0e2c3e524e413cafe8cce954"
B->A
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
Date: Tue, 25 Jan 2000 03:41:00 gmt
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
Server: Cisco-SIPGateway/IOS-12.x
Record-Route: <sip:97226491335@213.137.69.38:5060
;maddr=213.137.69.38>
CSeq: 2544266 INVITE
Content-Length: 0
B->A
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
Sterman, et al. Expires August 6, 2004 [Page 19]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
Date: Tue, 25 Jan 2000 03:41:00 gmt
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
Authentication-Info: nextnonce="ef0189c5",
rspauth="6303c41b0e2c3e524e413cafe8cce954"
Server: Cisco-SIPGateway/IOS-12.x
Record-Route: <sip:97226491335@213.137.69.38:5060
;maddr=213.137.69.38>
CSeq: 2544266 INVITE
Contact: <sip:97226491335@213.137.69.36:5060;user=phone>
Content-Type: application/sdp
Content-Length: 158
v=0
o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36
s=SIP Call
c=IN IP4 213.137.69.36
t=0 0
m=audio 17724 RTP/AVP 0
a=rtpmap:0 PCMU/8000
A->B
ACK sip:97226491335@213.137.69.38:5060 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
CSeq: 2544266 ACK
Content-Length: 0
Route: <sip:97226491335@213.137.69.36:5060;user=phone>
Sterman, et al. Expires August 6, 2004 [Page 20]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
Sterman, et al. Expires August 6, 2004 [Page 21]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Informative References
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Sterman, et al. Expires August 6, 2004 [Page 22]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
URIs
[1] <http://www.untruth.org/~josh/security/radius/radius-auth.html>
Authors' Addresses
Baruch Sterman
Kayote Networks
P.O. Box 1373
Efrat 90435
Israel
EMail: baruch@kayote.com
Daniel Sadolevsky
SecureOL, Inc.
Jerusalem Technology Park
P.O. Box 16120
Jerusalem 91160
Israel
EMail: dscreat@dscreat.com
David Schwartz
Kayote Networks
P.O. Box 1373
Efrat 90435
Israel
EMail: david@kayote.com
David Williams
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
Research Triangle Park NC 27709
USA
EMail: dwilli@cisco.com
Sterman, et al. Expires August 6, 2004 [Page 23]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Wolfgang Beck
Deutsche Telekom AG
Am Kavalleriesand 3
Darmstadt 64295
Germany
EMail: beckw@t-systems.com
Sterman, et al. Expires August 6, 2004 [Page 24]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Appendix A. Acknowledgements
We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or
providing comments and experimental implementation.
Sterman, et al. Expires August 6, 2004 [Page 25]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Sterman, et al. Expires August 6, 2004 [Page 26]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sterman, et al. Expires August 6, 2004 [Page 27]
Network Working Group B. Sterman
Internet-Draft Kayote Networks
Expires: August 6, 2004 D. Sadolevsky
SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
February 6, 2004
RADIUS Extension for Digest Authentication
draft-sterman-aaa-sip-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Basic and Digest authentication schemes are widely used in
protocols such as SIP and HTTP . RADIUS is a protocol for back end
authentication. RADIUS supports Basic authentication natively, as
well as several other authentication schemes, such as CHAP, but does
not support Digest authentication scheme. This document describes
Sterman, et al. Expires August 6, 2004 [Page 1]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
an extension to RADIUS for Digest authentication and provides a
scenario of Digest user authentication.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . 7
2.1 Digest-Response attribute . . . . . . . . . . . . . . . . . 7
2.2 Digest-Attributes attribute . . . . . . . . . . . . . . . . 8
2.3 Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 QOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9 Body-Digest . . . . . . . . . . . . . . . . . . . . . . . . 11
2.10 CNonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11 Nonce-Count . . . . . . . . . . . . . . . . . . . . . . . . 12
2.12 User-Name . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Detailed Description . . . . . . . . . . . . . . . . . . . . 14
3.1 RADIUS Client Behaviour . . . . . . . . . . . . . . . . . . 14
3.2 RADIUS Server Behaviour . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 16
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 26
Sterman, et al. Expires August 6, 2004 [Page 2]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
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].
1.2 Motivation
Digest authentication is a simple authentication mechanism for HTTP
and SIP. While it was not too successful in HTTP environments, it is
the only SIP authentication mechanism that has been widely adopted.
Due to the weaknesses of Digest authentication (see Section 4),
PKI-based authentication and encryption mechanisms have been
introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However,
most SIP user agents that support TLS don't send client certificates.
SIP with S/MIME is lacking support, too: even two years after the
inclusion of S/MIME into SIP, almost no implementations exist.
SIP service providers whishing to authenticate their clients have the
following options: they can
o build a PKI and wait for interopable S/MIME capable SIP
implementations,
o build a PKI and wait for SIP implementations supporting TLS with
client-side certificates,
o replace their existing RADIUS infrastructure with DIAMETER
[RFC3588], when DIAMETER supports HTTP Digest authentication,
o use TLS for server authentication and plaintext passwords (Basic)
for client authentication, which can be done with standard RADIUS,
o upgrade their existing RADIUS servers with the functionality
described in this document
PKI solutions only cover authentication, not authorization (EAP could
change this, but its use with SIP is not standardized). TLS / Basic
authentication works only with the limited number of SIP devices that
implement TLS. Basic authentication has been deprecated for SIP in
[RFC3261].
Current RADIUS-based AAA infrastructures have been built and debugged
over years. Deficiencies of RADIUS have been mitigated with
proprietary (ie costly) extensions. Operators are therefore reluctant
to replace their RADIUS infrastructure in order to enable a single
Sterman, et al. Expires August 6, 2004 [Page 3]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
new authentication mechanism.
Given the complexity of S/MIME, simple clients will continue to
support HTTP digest authentication only. Its interopability with a
back-end authentication protocol such as RADIUS is needed.
Operators that are about to replace their RADIUS-based AAA
infrastructure are strongly recommended to use DIAMETER.
1.3 Scenario
Figure 1 depicts the scenario that is relevant for this document. It
shows a generic case where entities A and B communicate in the
front-end using protocols such as HTTP/SIP, while entities B and C
communicate in the back-end using RADIUS.
HTTP/SIP RADIUS
+-----+ (1) +-----+ +-----+
| |==========>| | | |
| | (2) | | | |
| |<==========| | | |
| | (3) | | | |
| |==========>| | | |
| A | | B | (4) | C |
| | | |---------->| |
| | | | (5) | |
| | | |<----------| |
| | (6) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
Figure 1: Overview of operation
The roles played by the entities in this scenario are as follows:
A: HTTP client / SIP UA
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
Sterman, et al. Expires August 6, 2004 [Page 4]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
acting also as a RADIUS NAS
C: RADIUS server
The relevant order of messages sent in this scenario is as
follows:
A sends B an HTTP/SIP request without authorization header (step 1).
B challenges A sending an HTTP/SIP "(Proxy) Authorization required"
response containing a locally generated nonce (step 2). A sends B
an HTTP/SIP request with authorization header (step 3). B sends C a
RADIUS Access-Request with attributes described in this document
(step 4). C responds to B with a RADIUS Access-Accept/Access-Reject
response (step 5). If credentials were accepted B receives an
Access-Accept response and the message sent from A is considered
authentic. If B receives an Access-Reject response, however, B then
responds to A with a "(Proxy) Authorization required" response (step
6).
1.4 Approach
The approach taken here is to extend RADIUS to support Digest
authentication by mimicking its native support for CHAP
authentication. According to [RFC2865], the RADIUS server
distinguishes between different authentication schemes by looking at
the presence of an attribute specific for that scheme. For the three
natively supported authentication schemes, these attributes are:
User-Password for PAP (or any other clear-text password scheme),
CHAP-Password for CHAP, and State + User- Password for
challenge-response scheme. This document adds another attribute to be
used in this role: Digest-Response. Also according to [RFC2865], "An
Access-Request packet MUST contain either a User-Password or a
CHAP-Password or a State. It MUST NOT contain both a User-Password
and a CHAP-Password. If future extensions allow other kinds of
authentication information to be conveyed, the attribute for that can
be used instead of User-Password or CHAP-Password." The
Digest-Response introduced here therefore can be used instead of
User-Password or CHAP-Password.
The HTTP Authentication parameters found in the Proxy-Authorization
or Authorization request header are mapped into two newly defined
RADIUS attributes. The Digest-Response attribute and the
Digest-Attributes attribute carrying multiple HTTP Digest parameters
as subattributes. These two new RADIUS attributes are defined in the
document together with some other information required for
calculating the correct digest response on the RADIUS server with
exception of the password, which the RADIUS server is assumed to be
able to retrieve from a data store given the username. The structure
Sterman, et al. Expires August 6, 2004 [Page 5]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
of Digest-Response, the structure of Digest-Attributes and the
mapping/meaning of its subattributes are described in the next
chapter.
Sterman, et al. Expires August 6, 2004 [Page 6]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
2. New RADIUS attributes
DIG-RES and DIG-ATTRS are placeholders for values that will be
assigned by IANA, if this specification becomes a working group
document.
2.1 Digest-Response attribute
If this attribute is present, the RADIUS server SHOULD view the
Access-Request as a Digest one. The following paragraphs apply for
RADIUS servers implementing this specification.
Access-Request packets MUST contain an Digest-Response attribute. In
Access-Request packets, this attribute contains the digest taken from
request-digest field in Digest (Proxy)Authorization header, as
received from the HTTP or SIP client.
Access-Accept packets MUST contain a Digest-Response attribute. In
Access-Accept packets, this attribute contains a digest that can be
used for generating Authentication-Info headers. The calculation of
this digest is described [RFC2617], section 3.2.3. A summary of the
Digest-Response attribute format is shown below. The fields are
transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DIG-RES for Digest-Response. Early implementations have used
the experimental type 206.
Length
34
String
Sterman, et al. Expires August 6, 2004 [Page 7]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
In Access-Requests, this string proves the user knows a
password. The String field is 32 octets long and contains
hexadecimal representation of 16 octet digest value as it was
calculated by the authenticated client. The String field
SHOULD be copied from request-digest of digest-response
([RFC2617]). In Access-Accepts, this string proves the RADIUS
server knows the password. The RADIUS server calculates a
digest according to section 3.2.3 of [RFC2617] and copies the
result into this string.
2.2 Digest-Attributes attribute
This attribute contains subattributes which indicate the values
contained in a Digest (Proxy)Authorization header and other
information necessary to calculate the correct digest response. It
is only used in Access- Request packets. There can be multiple
Digest-Attributes attributes contained in one Access-Request packet.
In this case RADIUS server MUST interpret a concatenation of their
values as if it came in one attribute.
A summary of the Digest-Attributes attribute format is shown below.
The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
DIG-ATTRS for Digest-Attributes. Early implementations have
used the experimental type 207.
Length
>= 5
String
Sterman, et al. Expires August 6, 2004 [Page 8]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
The String field is 3 or more octets and contains one or more
subattributes. Format of a subattribute is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Sub-Type | Sub-Length | Sub-Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Sub-Type
Subattribute type. Meanings of the following defined types
can be found in section Section 2.3
1 Realm
2 Nonce
3 Method
4 URI
5 QOP
6 Algorithm
7 Body-Digest
8 CNonce
9 Nonce-Count
10 User-Name
Sub-Length >= 3
Sub-Value Subattribute-specific value
2.3 Realm
Sterman, et al. Expires August 6, 2004 [Page 9]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Sub-Type
1
Sub-Length
>= 3
Sub-Value
String, copied from realm-value of digest-response ([RFC2617])
2.4 Nonce
Sub-Type
2
Sub-Length
>= 3
Sub-Value
String, copied from realm-value of digest-response ([RFC2617])
2.5 Method
Sub-Type
3
Sub-Length
>= 3
Sub-Value
String, copied from digest-response. Method is taken from HTTP
or SIP request ([RFC2616], [RFC3261])
2.6 URI
Sterman, et al. Expires August 6, 2004 [Page 10]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Sub-Type
4
Sub-Length
>= 3
Sub-Value
String, copied from digest-uri-value of digest-response
([RFC2617])
2.7 QOP
Sub-Type
5
Sub-Length
>= 3
Sub-Value
String, copied from qop-value of digest-response ([RFC2617])
2.8 Algorithm
Sub-Type
6
Sub-Length
>= 3
Sub-Value
String, "MD5" | "MD5-sess" | token, copied from of
digest-response ([RFC2617])
2.9 Body-Digest
Sterman, et al. Expires August 6, 2004 [Page 11]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Sub-Type
7
Sub-Length
34
Sub-Value
String, hexadecimal representation of a digest calculated over
entity-body of HTTP/SIP request ([RFC2616], [RFC3261]).
Computed by entity B in figure Figure 1. This attribute is not
part of the HTTP Digest response. See [RFC2617] section
3.2.2.3.
2.10 CNonce
Sub-Type
8
Sub-Length
>= 3
Sub-Value
String copied from cnonce-value of digest-response ([RFC2617])
2.11 Nonce-Count
Sub-Type
9
Sub-Length
10
Sub-Value
String, 8LHEX, copied from nc-value of digest-response
([RFC2617])
Sterman, et al. Expires August 6, 2004 [Page 12]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
2.12 User-Name
Sub-Type
10
Sub-Length
>= 3
Sub-Value
String copied from username-value of digest-response
([RFC2617]) the RADIUS server SHOULD NOT use this value for
password finding, but only for digest calculation purpose. In
order to find the user record containing password, the RADIUS
server SHOULD use the value of the User-Name _attribute_
Sterman, et al. Expires August 6, 2004 [Page 13]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
3. Detailed Description
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 SIP.
3.1 RADIUS Client Behaviour
A RADIUS client without an encrypted or otherwise secured connection
to its RADIUS server only accepts unsecured connections from its
HTTP-style clients (or else the clients would have a false sense of
security).
The RADIUS client examines the (Proxy-)Authorization header of an
incoming HTTP-style request message. If this header is present and
contains HTTP digest information, the RADIUS client checks the
'nonce' parameter. If the 'nonce' parameter has not been issued by
the RADIUS client, it responds with a 401 (Unauthorized) or 407
(Proxy Authentication Required) to the HTTP-style client. In this
error response, the RADIUS client issues a new nonce.
If the RADIUS client recognizes the nonce, it takes the header
parameters and puts them into a RADIUS Access-Request message. It
puts the 'response' parameter into a Digest-Response attribute and
the realm / nonce / qop / algorithm / cnonce / nc / username into a
Digest-Attributes attribute. The request URI and the request method
are put into the Digest-Attributes attribute, too. Now, the RADIUS
client sends the Access-Request message to the RADIUS server.
The RADIUS server processes the message and responds with an
Access-Accept or an Access-Reject. If the RADIUS client receives an
Access-Accept, it examines the Digest-Response attribute contained in
the message. It constructs an Authentication-Info header and puts the
contents of Digest-Response into the 'rspauth' header parameter. Now
it can send a HTTP-style response.
If the RADIUS client did not receive a (Proxy-)Authorization header
from its HTTP-style client, it generates a new nonce and sends an
error response (401 or 407) containing a (Proxy-)Authenticate header.
If the RADIUS client receives an Access-Reject or no response from
the RADIUS server, it sends an error response to the HTTP-style
request it has received.
3.2 RADIUS Server Behaviour
If the RADIUS server receives an Access-Request message containing a
Digest-Response attribute, it looks for the Digest-Attributes
Sterman, et al. Expires August 6, 2004 [Page 14]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
attribute. If it does not find this attribute, it responds with an
Access-Reject message. If the Digest-Attribute attribute is present,
the RADIUS server calculates the digest response as described in
[RFC2617]. To look up the password, the RADIUS server uses the RADIUS
User-Name attribute. All other values are taken from the
Digest-Attribute attribute. If the calculated digest response equals
the string received in the Digest-Response attribute, the
authentication was successful. If not, the RADIUS server responds
with an Access-Reject.
If the authentication was successful, the RADIUS server calculates a
Digest-Response attribute that can be used by the RADIUS client to
construct an Authentication-Info header. The calculation of this
response is described in [RFC2617], section 3.2.3. The
Digest-Response attribute is send to the RADIUS client in an
Access-Accept message.
Sterman, et al. Expires August 6, 2004 [Page 15]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
4. Security Considerations
The RADIUS extensions described in this document make RADIUS a
transport protocol for the data that is required to perform a digest
calculation. It adds the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or
here [1])).
If an attacker gets access to a RADIUS client, it can perform
man-in-the-middle attacks even if the connections between A, B and B,
C (Figure 1) have been secured with TLS or IPSec.
SIP or HTTP requests occur much more frequently than dial-in
requests. RADIUS servers implementing this specification must meet
that additional performance requirements. An attacker could try to
overload the RADIUS infrastructure by excessively sending SIP or HTTP
requests. This kind of attack was more difficult when RADIUS was just
used for dial-in authentication: the attacker could be identified by
the DSL / Cable interface or with some help of the PSTN provider.
To make simple denial of service attacks more difficult, RADIUS
clients MUST check if nonces received from a client have been issued
by them. This SHOULD be done statelessly. For example, a nonce could
consist of a cryptographically random part and some kind of signature
of the RADIUS client, as described in [RFC2617], section 3.2.1.
HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. IPSec can be used in a similar way.
TLS or IPSec secure the connection while Digest Authentication
authenticates the user. If a RADIUS client accepts such connections,
it MUST have a secure connection to the RADIUS server.
Sterman, et al. Expires August 6, 2004 [Page 16]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
5. Example
This is an example sniffed from the traffic between HearMe softphone
(A), Cisco Systems Proxy Server (B) and deltathree RADIUS server (C)
(The communication between Cisco Systems Proxy Server and a SIP PSTN
gateway is omitted for brevity):
A->B
INVITE sip:97226491335@213.137.69.38 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38
Contact: sip:12345678@213.137.67.67:5061
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
CSeq: 2544265 INVITE
Content-Length: 150
Content-Type: application/sdp
User-Agent: HearMe SoftPHONE
v=0
o=HearMe 2544265 2544265 IN IP4 213.137.67.67
s=HearMe
c=IN IP4 213.137.67.67
t=0 0
m=audio 8000 RTP/AVP 0 4
a=ptime:20
a=x-ssrc:009aa330
B->A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 213.137.67.67:5061
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38
CSeq: 2544265 INVITE
Content-Length: 0
B->A
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 213.137.67.67:5061
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
Sterman, et al. Expires August 6, 2004 [Page 17]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
CSeq: 2544265 INVITE
Proxy-Authenticate: DIGEST realm="deltathree"
,nonce="3bada1a0", algorithm="md5"
Content-Length: 0
A->B
ACK sip:97226491335@213.137.69.38 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=216ae97f
To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
CSeq: 2544265 ACK
Content-Length: 0
A->B
INVITE sip:97226491335@213.137.69.38 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38
Contact: sip:12345678@213.137.67.67:5061
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
CSeq: 2544266 INVITE
Content-Length: 150
Content-Type: application/sdp
User-Agent: HearMe SoftPHONE
Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0"
,opaque="",realm="deltathree"
,response="2ae133421cda65d67dc50d13ba0eb9bc"
,uri="sip:97226491335@213.137.69.38",username="12345678"
v=0
o=HearMe 2544265 2544265 IN IP4 213.137.67.67
s=HearMe
c=IN IP4 213.137.67.67
t=0 0
m=audio 8000 RTP/AVP 0 4
a=ptime:20
a=x-ssrc:009aa330
B->C
Sterman, et al. Expires August 6, 2004 [Page 18]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Code = 1 (Access-Request)
Identifier = 1
Length = 164
Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e
Attributes:
NAS-IP-Address = d5 89 45 26 (213.137.69.38)
NAS-Port-Type = 5 (Virtual)
User-Name = "12345678"
Digest-Response (206) = "2ae133421cda65d67dc50d13ba0eb9bc"
Digest-Attributes (207) = [Realm (1) = "deltathree"]
Digest-Attributes (207) = [Nonce (2) = "3bada1a0"]
Digest-Attributes (207) = [Method (3) = "INVITE"]
Digest-Attributes (207) =
[URI (4) = "sip:97226491335@213.137.69.38"]
Digest-Attributes (207) = [Algorithm (5) = "md5"]
Digest-Attributes (207) = [User-Name (10) = "12345678"]
C->B
Code = 2 (Access-Accept)
Identifier = 1
Length = 20
Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d
Attributes:
Digest-Response (206) = "6303c41b0e2c3e524e413cafe8cce954"
B->A
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
Date: Tue, 25 Jan 2000 03:41:00 gmt
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
Server: Cisco-SIPGateway/IOS-12.x
Record-Route: <sip:97226491335@213.137.69.38:5060
;maddr=213.137.69.38>
CSeq: 2544266 INVITE
Content-Length: 0
B->A
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
Sterman, et al. Expires August 6, 2004 [Page 19]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
Date: Tue, 25 Jan 2000 03:41:00 gmt
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
Authentication-Info: nextnonce="ef0189c5",
rspauth="6303c41b0e2c3e524e413cafe8cce954"
Server: Cisco-SIPGateway/IOS-12.x
Record-Route: <sip:97226491335@213.137.69.38:5060
;maddr=213.137.69.38>
CSeq: 2544266 INVITE
Contact: <sip:97226491335@213.137.69.36:5060;user=phone>
Content-Type: application/sdp
Content-Length: 158
v=0
o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36
s=SIP Call
c=IN IP4 213.137.69.36
t=0 0
m=audio 17724 RTP/AVP 0
a=rtpmap:0 PCMU/8000
A->B
ACK sip:97226491335@213.137.69.38:5060 SIP/2.0
Via: SIP/2.0/UDP 213.137.67.67:5061
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
CSeq: 2544266 ACK
Content-Length: 0
Route: <sip:97226491335@213.137.69.36:5060;user=phone>
Sterman, et al. Expires August 6, 2004 [Page 20]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
Sterman, et al. Expires August 6, 2004 [Page 21]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Informative References
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Sterman, et al. Expires August 6, 2004 [Page 22]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
URIs
[1] <http://www.untruth.org/~josh/security/radius/radius-auth.html>
Authors' Addresses
Baruch Sterman
Kayote Networks
P.O. Box 1373
Efrat 90435
Israel
EMail: baruch@kayote.com
Daniel Sadolevsky
SecureOL, Inc.
Jerusalem Technology Park
P.O. Box 16120
Jerusalem 91160
Israel
EMail: dscreat@dscreat.com
David Schwartz
Kayote Networks
P.O. Box 1373
Efrat 90435
Israel
EMail: david@kayote.com
David Williams
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
Research Triangle Park NC 27709
USA
EMail: dwilli@cisco.com
Sterman, et al. Expires August 6, 2004 [Page 23]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Wolfgang Beck
Deutsche Telekom AG
Am Kavalleriesand 3
Darmstadt 64295
Germany
EMail: beckw@t-systems.com
Sterman, et al. Expires August 6, 2004 [Page 24]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Appendix A. Acknowledgements
We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or
providing comments and experimental implementation.
Sterman, et al. Expires August 6, 2004 [Page 25]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Sterman, et al. Expires August 6, 2004 [Page 26]
Internet-Draft RADIUS Extension for Digest Authentication February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sterman, et al. Expires August 6, 2004 [Page 27]