draft-sterman-aaa-sip-00.txt [plain text]
Internet Engineering Task Force B. Sterman
AAA Working Group D. Sadolevsky
Internet Draft D. Schwartz
draft-sterman-aaa-sip-00.txt deltathree, Inc.
Nov 12, 2001 D. Williams
Expires: Apr 12 2002 Cisco Systems
RADIUS Extension for Digest Authentication
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 Engií
neering 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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
Basic and Digest authentication schemes (RFC2617 [1]) are
widely used in protocols such as SIP (RFC2543 [2]) and HTTP
(RFC2616 [3]). RADIUS (RFC2865 [4]) 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 docuí
ment describes an extension to RADIUS for Digest authenticaí
tion and provides a scenario of Digest user authentication.
1 Introduction
1.1 Terminology
In this document, the key words "MUST", "MUST NOT", "REí
QUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMí
MENDED", "MAY", and "OPTIONAL" are to be interpreted as deí
scribed in RFC 2119.
1.2 Scenario
Figure 1 depicts the scenario that is relevant for this docuí
ment. It shows a generic case where entities A and B communií
cate 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: Scenario relevant to document
The roles played by the entities in this scenario are as folí
lows:
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 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) Authoí
rization required" response containing a locally generated
nonce (step 2). A sends B an HTTP/SIP request with authorizaí
tion 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 reí
sponse 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.3 Motivation
Basic and Digest authentication are used within protocols such
as HTTP and SIP. Recently, there have been efforts towards the
use of an Extensible Authentication Protocol (EAP) within proí
tocols such as HTTP and SIP. [5] is one such effort. The adí
vantage here is that, new authentication schemes may be used
without any modification to the SIP/HTTP protocol itself. This
is because the EAP packet for the particular authentication
scheme is carried transparently by the SIP/HTTP protocol.
However, the use of Basic and Digest authentication is likely
to continue to be used directly within protocols such as
SIP/HTTP in the near future, and hence their interoperability
with a back-end authentication protocol such as RADIUS is
needed.
There is also an ongoing effort to accomplish the same thing
as this document does in relation to DIAMETER [6], but DIAMEí
TER itself has not reached the RFC status as of the time of
writing this. When it happens and when [6] reaches the RFC
status too, implementers are encouraged to switch to [6].
1.4 Approach
The approach taken here is to extend RADIUS to support Digest
authentication by mimicking its native support for CHAP auí
thentication. According to [4], the RADIUS server distinguishí
es between different authentication schemes by looking at the
presence of an attribute specific for that scheme. For the
three natively supported authentication schemes, these atí
tributes 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 aní
other attribute to be used in this role: Digest-Response. Alí
so according to [4], "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 fuí
ture extensions allow other kinds of authentication informaí
tion to be conveyed, the attribute for that can be used iní
stead 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-Authoí
rization or Authorization request header are mapped into two
newly defined experimental RADIUS attributes. The Digest-Reí
sponse attribute and the Digest-Attributes attribute carrying
multiple HTTP Digest parameters as subattributes. These 2 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 reí
trieve from a data store given the username. The structure of
Digest-Response, the structure of Digest-Attributes and the
mapping/meaning of its subattributes are described in the next
chapter.
2 New RADIUS attributes
2.1 Digest-Response attribute
Description
This attribute contains the request-digest response value
contained in a Digest (Proxy)Authorization header. It is
only used in Access-Request packets. If this attribute is
present, the RADIUS server SHOULD view the Access-Request
as a Digest one.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
206(Experimental) for Digest-Response.
Length
34
String
String which proves the user knows a password. The String
field is 32 octets long and contains hexadecimal represení
tation 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 ([1]).
2.2 Digest-Attributes attribute
Description
This attribute contains subattributes which indicate the
values contained in a Digest (Proxy)Authorization header
together with other information necessary to calculate the
correct digest response value. 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
207(Experimental) for Digest-Attributes.
Length
>= 5
String
The String field is 3 or more octets and contains one or
more subattributes. Format of a subattribute is shown beí
low. 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 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.1 Realm
Sub-Type
1
Sub-Length
>= 3
Sub-Value
String, copied from realm-value of digest-response ([1])
2.3.2 Nonce
Sub-Type
2
Sub-Length
>= 3
Sub-Value
String, copied from nonce-value of digest-response ([1])
2.3.3 Method
Sub-Type
3
Sub-Length
>= 3
Sub-Value
String, copied from digest-response. Method is taken from
request-URI of message ([2/3])
2.3.4 URI
Sub-Type
4
Sub-Length
>= 3
Sub-Value
String, copied from digest-uri-value of digest-response
([1])
2.3.5 QOP
Sub-Type
5
Sub-Length
>= 3
Sub-Value
String, copied from qop-value of digest-response ([1])
2.3.6 Algorithm
Sub-Type
6
Sub-Length
>= 3
Sub-Value
String, "MD5" | "MD5-sess" | token, copied from algorithm
of digest-response ([1])
2.3.7 Body-Digest
Sub-Type
7
Sub-Length
34
Sub-Value
String, hexadecimal representation of a digest calculated
over entity-body of HTTP/SIP request ([1/2]). Computed by
entity B in figure 1. This attribute is not part of the
HTTP Digest response.
2.3.8 CNonce
Sub-Type
8
Sub-Length
>= 3
Sub-Value
String copied from cnonce-value of digest-response ([1])
2.3.9 Nonce-Count
Sub-Type
9
Sub-Length
= 10
Sub-Value
String, 8LHEX, copied from nc-value of digest-response
([1])
2.3.10 User-Name
Sub-Type
10
Sub-Length
>= 3
Sub-Value
String copied from username-value of digest-response ([1])
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_
3 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
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->A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 213.137.67.67:5061
Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
From: <sip:12345678@213.137.67.67>;tag=29e97f
To: sip:97226491335@213.137.69.38
CSeq: 2544266 INVITE
Content-Length: 0
B->C
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
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
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
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>
References
[1] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence,
P. Leach, A. Luotonen, L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June
1999.
[2] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
"SIP: Session Initiation Protocol",
draft-ietf-sip-rfc2543bis-03.txt, IETF work in progress,
May 2001.
[3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
L. Masinter, P. Leach, T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4] C. Rigney, S. Willens, Livingston, A. Rubens, Merit,
W. Simpson, Daydreamer, "Remote Authentication Dial In
User Service (RADIUS)", RFC 2865, June 2000
[5] J. Arkko, V. Torvinen, A. Niemi, "HTTP Authentication
with EAP", draft-http-eap-basic-04.txt, IETF work in
progress, June 2001.
[6] Srinivas, Chan, Sengodan, Costa-Requena, "Mapping of
Basic and Digest Authentication to DIAMETER AAA
Messages", draft-srinivas-aaa-basic-digest-00.txt,
IETF work in progress, July 2001
Acknowledgements
We would like to acknowledge Kevin Mcdermott (Cisco Systems)
for providing comments and experimental implementation.
Authors's Addresses
Baruch Sterman
Daniel Sadolevsky
David Schwartz
deltathree, Inc.
Jerusalem Technology Park
P.O. Box 48265
Jerusalem 91481 Israel
{baruch,daniels,davids}@deltathree.com
David Williams
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
Research Triangle Park, NC 27709
USA
Email: dwilli@cisco.com