| Req | Accept | Reject | Challenge | # | Attribute |
+-----+--------+--------+-----------+-----+-------------------------+
| 1 | 0 | 0 | 0 | 1 | User-Name |
| 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
| 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
| 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
| 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
| 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
| | | | | | (see Note 1, 2) |
| 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
| 0-1 | 0 | 0 | 0 | 108 | Digest-Method |
| 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
| 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
| 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
| | | | | | Note 3) |
| 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
| 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
| 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
| 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
| 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
| 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
| 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
| 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
| 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
| 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
| | | | | | 2) |
| 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
+-----+--------+--------+-----------+-----+-------------------------+
Table 1
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
Digest-Qop is ’auth-int’.
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
Digest-Qop is ’auth’.
[Note 3] If Digest-Algorithm is missing, ’MD5’ is assumed.
6. Examples
This is an example selected from the traffic between a softphone (A),
a Proxy Server (B), and an example.com RADIUS server (C). The
communication between the Proxy Server and a SIP Public Switched
Telephone Network (PSTN) gateway is omitted for brevity. The SIP
messages are not shown completely.
A->B
INVITE sip:97226491335@example.com SIP/2.0
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->A
SIP/2.0 100 Trying
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Message-Authenticator =
08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43
C->B
Code = 11 (Access-Challenge)
Attributes:
Digest-Nonce = 3bada1a0
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
B->A
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="example.com"
,nonce="3bada1a0",qop=auth,algorithm=MD5
Content-Length: 0
A->B
ACK sip:97226491335@example.com SIP/2.0
A->B
INVITE sip:97226491335@example.com SIP/2.0
Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
,realm="example.com"
,response="f3ce87e6984557cd0fecc26f3c5e97a4"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
Digest-Realm = example.com
Digest-Nonce = 3bada1a0
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Qop = auth
Digest-Algorithm = md5
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator =
ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff
C->B
Code = 2 (Access-Accept)
Attributes:
Digest-Response-Auth =
6303c41b0e2c3e524e413cafe8cce954
Message-Authenticator =
75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1
B->A
SIP/2.0 180 Ringing
B->A
SIP/2.0 200 OK
A->B
ACK sip:97226491335@example.com SIP/2.0
A second example shows the traffic between a web browser (A), web
server (B), and a RADIUS server (C).
A->B
GET /index.html HTTP/1.1
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
Digest-Method = GET
Digest-URI = /index.html
Message-Authenticator =
34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7
C->B
Code = 11 (Access-Challenge)
Attributes:
Digest-Nonce = a3086ac8
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
B->A
HTTP/1.1 401 Authentication Required
WWW-Authenticate: Digest realm="example.com",
nonce="a3086ac8",qop=auth,algorithm=MD5
Content-Length: 0
A->B
GET /index.html HTTP/1.1
Authorization: Digest algorithm=MD5,nonce="a3086ac8"
,realm="example.com"
,response="f052b68058b2987aba493857ae1ab002"
,uri="/index.html",username="12345678"
,qop=auth,algorithm=MD5
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f052b68058b2987aba493857ae1ab002
Digest-Realm = example.com
Digest-Nonce = a3086ac8
Digest-Method = GET
Digest-URI = /index.html
Digest-Username = 12345678
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b
C->B
Code = 2 (Access-Accept)
Attributes:
Digest-Response-Auth =
e644aa513effbfe1caff67103ff6433c
Message-Authenticator =
7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7
B->A
HTTP/1.1 200 OK
...
<html>
...
7. IANA Considerations
This document serves as an IANA registration request for a number of
values from the RADIUS attribute type number space. The IANA has
assigned the following:
+-------------------------+------------------------+
| placeholder | value assigned by IANA |
+-------------------------+------------------------+
| Digest-Response | 103 |
| Digest-Realm | 104 |
| Digest-Nonce | 105 |
| Digest-Nextnonce | 106 |
| Digest-Response-Auth | 107 |
| Digest-Method | 108 |
| Digest-URI | 109 |
| Digest-Qop | 110 |
| Digest-Algorithm | 111 |
| Digest-Entity-Body-Hash | 112 |
| Digest-CNonce | 113 |
| Digest-Nonce-Count | 114 |
| Digest-Username | 115 |
| Digest-Opaque | 116 |
| Digest-Auth-Param | 117 |
| Digest-AKA-Auts | 118 |
| Digest-Domain | 119 |
| Digest-Stale | 120 |
| Digest-HA1 | 121 |
| SIP-AOR | 122 |
+-------------------------+------------------------+
Table 2
8. Security Considerations
The RADIUS extensions described in this document enable RADIUS to
transport the data that is required to perform a digest calculation.
As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) in addition to RADIUS security vulnerabilities
described in [RFC2865], section 8, and [RFC3579], section 4.
An attacker compromising a RADIUS client or proxy can carry out
man-in-the-middle attacks even if the paths between A, B and B, C
(Figure 2) have been secured with TLS or IPsec.
The RADIUS server MUST check the Digest-Realm attribute it has
received from a client. If the RADIUS client is not authorized to
serve HTTP-style clients of that realm, it might be compromised.
8.1. Denial of Service
RADIUS clients implementing the extension described in this document
may authenticate HTTP-style requests received over the Internet. As
compared with the use of RADIUS to authenticate link-layer network
access, attackers may find it easier to cover their tracks in such a
scenario.
An attacker can attempt a denial-of-service attack on one or more
RADIUS servers by sending a large number of HTTP-style requests. To
make simple denial-of-service attacks more difficult, the RADIUS
server MUST check whether it has generated the nonce received from an
HTTP-style client. This SHOULD be done statelessly. For example, a
nonce could consist of a cryptographically random part and some kind
of signature provided by the RADIUS client, as described in
[RFC2617], section 3.2.1.
8.2. Confidentiality and Data Integrity
The attributes described in this document are sent in cleartext.
RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
attributes in Access-Challenge messages. A man in the middle can
modify or remove those attributes in a bidding down attack, causing
the RADIUS client to use a weaker authentication scheme than
intended.
The Message-Authenticator attribute, described in [RFC3579], section
3.2 MUST be included in Access-Request, Access-Challenge,
Access-Reject, and Access-Accept messages that contain attributes
described in this specification.
The Digest-HA1 attribute contains no random components if the
algorithm is ’MD5’ or ’AKAv1-MD5’. This makes offline dictionary
attacks easier and enables replay attacks.
Some parameter combinations require the protection of RADIUS packets
against eavesdropping and tampering. Implementations SHOULD try to
determine automatically whether IPsec is configured to protect
traffic between the RADIUS client and the RADIUS server. If this is
not possible, the implementation checks a configuration parameter
telling it whether IPsec will protect RADIUS traffic. The default
value of this configuration parameter tells the implementation that
RADIUS packets will not be protected.
HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest Authentication. Instead of TLS, IPsec can be used,
too. TLS or IPsec secure the connection while Digest Authentication
authenticates the user. The RADIUS transaction can be regarded as
one leg on the path between the HTTP-style client and the HTTP-style
server. To prevent RADIUS from representing the weak link, a RADIUS
client receiving an HTTP-style request via TLS or IPsec could use an
equally secure connection to the RADIUS server. There are several
ways to achieve this, for example:
o The RADIUS client may reject HTTP-style requests received over TLS
or IPsec.
o The RADIUS client may require that traffic be sent and received
over IPsec.
RADIUS over IPsec, if used, MUST conform to the requirements
described in [RFC3579], section 4.2.
9. Acknowledgements
We would like to acknowledge Kevin McDermott (Cisco Systems) for
providing comments and experimental implementation.
Many thanks to all reviewers, especially to Miguel Garcia, Jari
Arkko, Avi Lior, and Jun Wang.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004.
10.2. Informative References
[SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol
(SIP) Application", Work in Progress), April 2006.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E., and L. Stewart, "An Extension to
HTTP : Digest Access Authentication", RFC 2069, January
1997.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication
and Key Agreement (AKA)", RFC 3310, September 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
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
Wolfgang Beck
Deutsche Telekom AG
Deutsche Telekom Allee 7
Darmstadt 64295
Germany
EMail: beckw@t-systems.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).