« back to all changes in this revision
Viewing changes to doc/rfc/rfc5090.txt
- browse files at revision 28
- compare with another revision
- download diff
- download tarball
- view history from revision 28
- Committer: Bazaar Package Importer
- Author(s): Chuck Short
- Date: 2010-01-04 21:40:02 UTC
- mfrom: (1.1.14 upstream) (4.1.5 sid)
- Revision ID: james.westby@ubuntu.com-20100104214002-41gcmr2dd7sebn58
Tags: 2.1.8+dfsg-1ubuntu1
Resynchronize with Debian.
- files added:
- .gitignore
- files removed:
- debian/TODO
- doc/rfc
- files modified:
- Make.inc.in
added
removed
doc/rfc/rfc5090.txt
1
2
3
4
5
6
7
Network Working Group B. Sterman
8
Request for Comments: 5090 Kayote Networks
9
Obsoletes: 4590 D. Sadolevsky
10
Category: Standards Track SecureOL, Inc.
11
D. Schwartz
12
Kayote Networks
13
D. Williams
14
Cisco Systems
15
W. Beck
16
Deutsche Telekom AG
17
February 2008
18
19
20
RADIUS Extension for Digest Authentication
21
22
Status of This Memo
23
24
This document specifies an Internet standards track protocol for the
25
Internet community, and requests discussion and suggestions for
26
improvements. Please refer to the current edition of the "Internet
27
Official Protocol Standards" (STD 1) for the standardization state
28
and status of this protocol. Distribution of this memo is unlimited.
29
30
Abstract
31
32
This document defines an extension to the Remote Authentication
33
Dial-In User Service (RADIUS) protocol to enable support of Digest
34
Authentication, for use with HTTP-style protocols like the Session
35
Initiation Protocol (SIP) and HTTP.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
Sterman, et al. Standards Track [Page 1]
59
60
RFC 5090 RADIUS Extension Digest Authentication February 2008
61
62
63
Table of Contents
64
65
1. Introduction ....................................................3
66
1.1. Motivation .................................................3
67
1.2. Terminology ................................................3
68
1.3. Overview ...................................................4
69
2. Detailed Description ............................................6
70
2.1. RADIUS Client Behavior .....................................6
71
2.2. RADIUS Server Behavior .....................................9
72
3. New RADIUS Attributes ..........................................12
73
3.1. Digest-Response Attribute .................................12
74
3.2. Digest-Realm Attribute ....................................13
75
3.3. Digest-Nonce Attribute ....................................13
76
3.4. Digest-Response-Auth Attribute ............................14
77
3.5. Digest-Nextnonce Attribute ................................14
78
3.6. Digest-Method Attribute ...................................15
79
3.7. Digest-URI Attribute ......................................15
80
3.8. Digest-Qop Attribute ......................................15
81
3.9. Digest-Algorithm Attribute ................................16
82
3.10. Digest-Entity-Body-Hash Attribute ........................16
83
3.11. Digest-CNonce Attribute ..................................17
84
3.12. Digest-Nonce-Count Attribute .............................17
85
3.13. Digest-Username Attribute ................................17
86
3.14. Digest-Opaque Attribute ..................................18
87
3.15. Digest-Auth-Param Attribute ..............................18
88
3.16. Digest-AKA-Auts Attribute ................................19
89
3.17. Digest-Domain Attribute ..................................19
90
3.18. Digest-Stale Attribute ...................................20
91
3.19. Digest-HA1 Attribute .....................................20
92
3.20. SIP-AOR Attribute ........................................21
93
4. Diameter Compatibility .........................................21
94
5. Table of Attributes ............................................21
95
6. Examples .......................................................23
96
7. IANA Considerations ............................................27
97
8. Security Considerations ........................................28
98
8.1. Denial of Service .........................................28
99
8.2. Confidentiality and Data Integrity ........................28
100
9. References .....................................................29
101
9.1. Normative References ......................................29
102
9.2. Informative References ....................................30
103
Appendix A - Changes from RFC 4590 ................................31
104
Acknowledgements ..................................................31
105
106
107
108
109
110
111
112
113
114
Sterman, et al. Standards Track [Page 2]
115
116
RFC 5090 RADIUS Extension Digest Authentication February 2008
117
118
119
1. Introduction
120
121
1.1. Motivation
122
123
The HTTP Digest Authentication mechanism, defined in [RFC2617], was
124
subsequently adapted for use with SIP [RFC3261]. Due to the
125
limitations and weaknesses of Digest Authentication (see [RFC2617],
126
Section 4), additional authentication and encryption mechanisms are
127
defined in SIP [RFC3261], including Transport Layer Security (TLS)
128
[RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest
129
Authentication support is mandatory in SIP implementations, and
130
Digest Authentication is the preferred way for a SIP UA to
131
authenticate itself to a proxy server. Digest Authentication is used
132
in other protocols as well.
133
134
To simplify the provisioning of users, there is a need to support
135
this authentication mechanism within Authentication, Authorization,
136
and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
137
[RFC3588].
138
139
This document defines an extension to the RADIUS protocol to enable
140
support of Digest Authentication for use with SIP, HTTP, and other
141
HTTP-style protocols using this authentication method. Support for
142
Digest mechanisms such as Authentication and Key Agreement (AKA)
143
[RFC3310] is also supported. A companion document [RFC4740] defines
144
support for Digest Authentication within Diameter.
145
146
1.2. Terminology
147
148
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
149
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
150
document are to be interpreted as described in [RFC2119].
151
152
The use of normative requirement key words in this document shall
153
apply only to RADIUS client and RADIUS server implementations that
154
include the features described in this document. This document
155
creates no normative requirements for existing implementations.
156
157
HTTP-style protocol
158
The term "HTTP-style" denotes any protocol that uses HTTP-like
159
headers and uses HTTP Digest Authentication as described in
160
[RFC2617]. Examples are HTTP and the Session Initiation Protocol
161
(SIP).
162
163
NAS (Network Access Server)
164
The RADIUS client.
165
166
167
168
169
170
Sterman, et al. Standards Track [Page 3]
171
172
RFC 5090 RADIUS Extension Digest Authentication February 2008
173
174
175
nonce
176
An unpredictable value used to prevent replay attacks. The nonce
177
generator may use cryptographic mechanisms to produce nonces it
178
can recognize without maintaining state.
179
180
protection space
181
HTTP-style protocols differ in their definition of the protection
182
space. For HTTP, it is defined as the combination of the realm
183
and canonical root URL of the requested resource for which the use
184
is authorized by the RADIUS server. In the case of SIP, the realm
185
string alone defines the protection space.
186
187
SIP UA (SIP User Agent)
188
An Internet endpoint that uses the Session Initiation Protocol.
189
190
SIP UAS (SIP User Agent Server)
191
A logical entity that generates a response to a SIP (Session
192
Initiation Protocol) request.
193
194
1.3. Overview
195
196
HTTP Digest is a challenge-response protocol used to authenticate a
197
client's request to access some resource on a server. Figure 1 shows
198
a single HTTP Digest transaction.
199
200
HTTP/SIP..
201
+------------+ (1) +------------+
202
| |--------->| |
203
| HTTP-style | (2) | HTTP-style |
204
| client |<---------| server |
205
| | (3) | |
206
| |--------->| |
207
| | (4) | |
208
| |<---------| |
209
+------------+ +------------+
210
211
Figure 1: Digest Operation without RADIUS
212
213
If the client sends a request without any credentials (1), the server
214
will reply with an error response (2) containing a nonce. The client
215
creates a cryptographic digest from parts of the request, from the
216
nonce it received from the server, and from a shared secret. The
217
client retransmits the request (3) to the server, but now includes
218
the digest within the packet. The server does the same digest
219
calculation as the client and compares the result with the digest it
220
received in (3). If the digest values are identical, the server
221
grants access to the resource and sends a positive response to the
222
223
224
225
226
Sterman, et al. Standards Track [Page 4]
227
228
RFC 5090 RADIUS Extension Digest Authentication February 2008
229
230
231
client (4). If the digest values differ, the server sends a negative
232
response to the client (4).
233
234
Instead of maintaining a local user database, the server could use
235
RADIUS to access a centralized user database. However, RADIUS
236
[RFC2865] does not include support for HTTP Digest Authentication.
237
The RADIUS client cannot use the User-Password Attribute, since it
238
does not receive a password from the HTTP-style client. The CHAP-
239
Challenge and CHAP-Password attributes described in [RFC1994] are
240
also not suitable since the Challenge Handshake Authentication
241
Protocol (CHAP) algorithm is not compatible with HTTP Digest.
242
243
This document defines new attributes that enable the RADIUS server to
244
perform the digest calculation defined in [RFC2617], providing
245
support for Digest Authentication as a native authentication
246
mechanism within RADIUS.
247
248
The nonces required by the digest algorithm are generated by the
249
RADIUS server. Generating them in the RADIUS client would save a
250
round-trip, but introduce security and operational issues. Some
251
digest algorithms -- e.g., AKA [RFC3310] -- would not work.
252
253
Figure 2 depicts a scenario in which the HTTP-style server defers
254
authentication to a RADIUS server. Entities A and B communicate
255
using HTTP or SIP, while entities B and C communicate using RADIUS.
256
257
HTTP/SIP RADIUS
258
259
+-----+ (1) +-----+ +-----+
260
| |==========>| | (2) | |
261
| | | |---------->| |
262
| | | | (3) | |
263
| | (4) | |<----------| |
264
| |<==========| | | |
265
| | (5) | | | |
266
| |==========>| | | |
267
| A | | B | (6) | C |
268
| | | |---------->| |
269
| | | | (7) | |
270
| | | |<----------| |
271
| | (8) | | | |
272
| |<==========| | | |
273
+-----+ +-----+ +-----+
274
275
====> HTTP/SIP
276
----> RADIUS
277
278
Figure 2: HTTP Digest over RADIUS
279
280
281
282
Sterman, et al. Standards Track [Page 5]
283
284
RFC 5090 RADIUS Extension Digest Authentication February 2008
285
286
287
The entities have the following roles:
288
289
A: HTTP client / SIP UA
290
291
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
292
acting also as a RADIUS NAS
293
294
C: RADIUS server
295
296
The following messages are sent in this scenario:
297
298
A sends B an HTTP/SIP request without an Authorization header (step
299
1). B sends an Access-Request packet with the newly defined Digest-
300
Method and Digest-URI attributes but without a Digest-Nonce Attribute
301
to the RADIUS server, C (step 2). C chooses a nonce and responds
302
with an Access-Challenge (step 3). This Access-Challenge contains
303
Digest attributes, from which B takes values to construct an HTTP/SIP
304
"(Proxy) Authorization required" response. B sends this response to
305
A (step 4). A resends its request with its credentials (step 5). B
306
sends an Access-Request to C (step 6). C checks the credentials and
307
replies with Access-Accept or Access-Reject (step 7). Depending on
308
C's result, B processes A's request or rejects it with a "(Proxy)
309
Authorization required" response (step 8).
310
311
2. Detailed Description
312
313
2.1. RADIUS Client Behavior
314
315
The attributes described in this document are sent in cleartext.
316
Therefore, were a RADIUS client to accept secure connections (HTTPS
317
or SIPS) from HTTP-style clients, this could result in information
318
intentionally protected by HTTP-style clients being sent in the clear
319
during RADIUS exchange.
320
321
2.1.1. Credential Selection
322
323
On reception of an HTTP-style request message, the RADIUS client
324
checks whether it is authorized to authenticate the request. Where
325
an HTTP-style request traverses several proxies, and each of the
326
proxies requests to authenticate the HTTP-style client, the request
327
at the HTTP-style server may contain multiple credential sets.
328
329
The RADIUS client can use the realm directive in HTTP to determine
330
which credentials are applicable. Where none of the realms are of
331
interest, the RADIUS client MUST behave as though no relevant
332
credentials were sent. In all situations, the RADIUS client MUST
333
send zero or exactly one credential to the RADIUS server. The RADIUS
334
335
336
337
338
Sterman, et al. Standards Track [Page 6]
339
340
RFC 5090 RADIUS Extension Digest Authentication February 2008
341
342
343
client MUST choose the credential of the (Proxy-)Authorization header
344
if the realm directive matches its locally configured realm.
345
346
2.1.2. Constructing an Access-Request
347
348
If a matching (Proxy-)Authorization header is present and contains
349
HTTP Digest information, the RADIUS client checks the nonce
350
parameter.
351
352
If the RADIUS client recognizes the nonce, it takes the header
353
directives and puts them into a RADIUS Access-Request packet. It
354
puts the response directive into a Digest-Response Attribute and the
355
realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, and
356
opaque directives into the respective Digest-Realm, Digest-Nonce,
357
Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest-
358
Nonce-Count, Digest-Username, and Digest-Opaque attributes. The
359
RADIUS client puts the request method into the Digest-Method
360
Attribute.
361
362
Due to HTTP syntactic requirements, quoted strings found in HTTP
363
Digest directives may contain escaped quote and backslash characters.
364
When translating these directives into RADIUS attributes, the RADIUS
365
client only removes the leading and trailing quote characters which
366
surround the directive value, it does not unescape anything within
367
the string. See Section 3 for an example.
368
369
If the Quality of Protection (qop) directive's value is 'auth-int',
370
the RADIUS client calculates H(entity-body) as described in
371
[RFC2617], Section 3.2.1, and puts the result in a Digest-Entity-
372
Body-Hash Attribute.
373
374
The RADIUS client adds a Message-Authenticator Attribute, defined in
375
[RFC3579], and sends the Access-Request packet to the RADIUS server.
376
377
The RADIUS server processes the packet and responds with an Access-
378
Accept or an Access-Reject.
379
380
2.1.3. Constructing an Authentication-Info Header
381
382
After having received an Access-Accept from the RADIUS server, the
383
RADIUS client constructs an Authentication-Info header:
384
385
o If the Access-Accept packet contains a Digest-Response-Auth
386
Attribute, the RADIUS client checks the Digest-Qop Attribute:
387
388
* If the Digest-Qop Attribute's value is 'auth' or not specified,
389
the RADIUS client puts the Digest-Response-Auth Attribute's
390
391
392
393
394
Sterman, et al. Standards Track [Page 7]
395
396
RFC 5090 RADIUS Extension Digest Authentication February 2008
397
398
399
content into the Authentication-Info header's rspauth directive
400
of the HTTP-style response.
401
402
* If the Digest-Qop Attribute's value is 'auth-int', the RADIUS
403
client ignores the Access-Accept packet and behaves as if it
404
had received an Access-Reject packet (Digest-Response-Auth
405
can't be correct as the RADIUS server does not know the
406
contents of the HTTP-style response's body).
407
408
o If the Access-Accept packet contains a Digest-HA1 Attribute, the
409
RADIUS client checks the qop and algorithm directives in the
410
Authorization header of the HTTP-style request it wants to
411
authorize:
412
413
* If the qop directive is missing or its value is 'auth', the
414
RADIUS client ignores the Digest-HA1 Attribute. It does not
415
include an Authentication-Info header in its HTTP-style
416
response.
417
418
* If the qop directive's value is 'auth-int' and at least one of
419
the following conditions is true, the RADIUS client calculates
420
the contents of the HTTP-style response's rspauth directive:
421
422
+ The algorithm directive's value is 'MD5-sess' or 'AKAv1-
423
MD5-sess'.
424
425
+ IP Security (IPsec) is configured to protect traffic between
426
the RADIUS client and RADIUS server with IPsec (see Section
427
8).
428
429
The RADIUS client creates the HTTP-style response message and
430
calculates the hash of this message's body. It uses the result
431
and the Digest-URI Attribute's value of the corresponding
432
Access-Request packet to perform the H(A2) calculation. It
433
takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and
434
Digest-Qop values of the corresponding Access-Request and the
435
Digest-HA1 Attribute's value to finish the computation of the
436
rspauth value.
437
438
o If the Access-Accept packet contains neither a Digest-Response-
439
Auth nor a Digest-HA1 Attribute, the RADIUS client will not create
440
an Authentication-Info header for its HTTP-style response.
441
442
When the RADIUS server provides a Digest-Nextnonce Attribute in the
443
Access-Accept packet, the RADIUS client puts the contents of this
444
attribute into a nextnonce directive. Now it can send an HTTP-style
445
response.
446
447
448
449
450
Sterman, et al. Standards Track [Page 8]
451
452
RFC 5090 RADIUS Extension Digest Authentication February 2008
453
454
455
2.1.4. Failed Authentication
456
457
If the RADIUS client did receive an HTTP-style request without a
458
(Proxy-)Authorization header matching its locally configured realm
459
value, it obtains a new nonce and sends an error response (401 or
460
407) containing a (Proxy-)Authenticate header.
461
462
If the RADIUS client receives an Access-Challenge packet in response
463
to an Access-Request containing a Digest-Nonce Attribute, the RADIUS
464
server did not accept the nonce. If a Digest-Stale Attribute is
465
present in the Access-Challenge and has a value of 'true' (without
466
surrounding quotes), the RADIUS client sends an error response (401
467
or 407) containing a WWW-/Proxy-Authenticate header with the stale
468
directive set to 'true' and the digest directives derived from the
469
Digest-* attributes.
470
471
If the RADIUS client receives an Access-Reject from the RADIUS
472
server, it sends an error response to the HTTP-style request it has
473
received. If the RADIUS client does not receive a response, it
474
retransmits or fails over to another RADIUS server as described in
475
[RFC2865].
476
477
2.1.5. Obtaining Nonces
478
479
The RADIUS client has two ways to obtain nonces: it has received one
480
in a Digest-Nextnonce Attribute of a previously received Access-
481
Accept packet, or it asks the RADIUS server for one. To do the
482
latter, it sends an Access-Request containing a Digest-Method and a
483
Digest-URI Attribute, but without a Digest-Nonce Attribute. It adds
484
a Message-Authenticator (see [RFC3579]) Attribute to the Access-
485
Request packet. The RADIUS server chooses a nonce and responds with
486
an Access-Challenge containing a Digest-Nonce Attribute.
487
488
The RADIUS client constructs a (Proxy-)Authenticate header using the
489
received Digest-Nonce and Digest-Realm attributes to fill the nonce
490
and realm directives. The RADIUS server can send Digest-Qop,
491
Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the
492
Access-Challenge carrying the nonce. If these attributes are
493
present, the client MUST use them.
494
495
2.2. RADIUS Server Behavior
496
497
If the RADIUS server receives an Access-Request packet with a
498
Digest-Method and a Digest-URI Attribute but without a Digest-Nonce
499
Attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce
500
Attribute and sends it in an Access-Challenge packet to the RADIUS
501
client. The RADIUS server MUST add Digest-Realm, Message-
502
Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm and one or
503
504
505
506
Sterman, et al. Standards Track [Page 9]
507
508
RFC 5090 RADIUS Extension Digest Authentication February 2008
509
510
511
more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque
512
attributes to the Access-Challenge packet.
513
514
2.2.1. General Attribute Checks
515
516
If the RADIUS server receives an Access-Request packet containing a
517
Digest-Response Attribute, it looks for the following attributes:
518
519
Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
520
Digest-Algorithm, and Digest-Username. Depending on the content of
521
Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-
522
Hash, Digest-CNonce, and Digest-AKA-Auts, too. See [RFC2617] and
523
[RFC3310] for details. If the Digest-Algorithm Attribute is missing,
524
'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque
525
Attribute along with the nonce, the Access-Request MUST have a
526
matching Digest-Opaque Attribute.
527
528
If mandatory attributes are missing, it MUST respond with an Access-
529
Reject packet.
530
531
The RADIUS server removes '\' characters that escape quote and '\'
532
characters from the text values it has received in the Digest-*
533
attributes.
534
535
If the mandatory attributes are present, the RADIUS server MUST check
536
if the RADIUS client is authorized to serve users of the realm
537
mentioned in the Digest-Realm Attribute. If the RADIUS client is not
538
authorized, the RADIUS server MUST send an Access-Reject. The RADIUS
539
server SHOULD log the event so as to notify the operator, and MAY
540
take additional action such as sending an Access-Reject in response
541
to all future requests from this client, until this behavior is reset
542
by management action.
543
544
The RADIUS server determines the age of the nonce in the Digest-Nonce
545
by using an embedded timestamp or by looking it up in a local table.
546
The RADIUS server MUST check the integrity of the nonce if it embeds
547
the timestamp in the nonce. Section 2.2.2 describes how the server
548
handles old nonces.
549
550
2.2.2. Authentication
551
552
If the Access-Request message passes the checks described above, the
553
RADIUS server calculates the digest response as described in
554
[RFC2617]. To look up the password, the RADIUS server uses the
555
RADIUS User-Name Attribute. The RADIUS server MUST check if the user
556
identified by the User-Name Attribute:
557
558
o is authorized to access the protection space and
559
560
561
562
Sterman, et al. Standards Track [Page 10]
563
564
RFC 5090 RADIUS Extension Digest Authentication February 2008
565
566
567
o is authorized to use the URI included in the SIP-AOR Attribute, if
568
this attribute is present.
569
570
If any of those checks fails, the RADIUS server MUST send an Access-
571
Reject.
572
573
Correlation between User-Name and SIP-AOR AVP values is required just
574
to avoid any user from registering or misusing a SIP-AOR that has
575
been allocated to a different user.
576
577
All values required for the digest calculation are taken from the
578
Digest attributes described in this document. If the calculated
579
digest response equals the value received in the Digest-Response
580
Attribute, the authentication was successful.
581
582
If the response values match, but the RADIUS server considers the
583
nonce in the Digest-Nonce Attribute too old, it sends an Access-
584
Challenge packet containing a new nonce and a Digest-Stale Attribute
585
with a value of 'true' (without surrounding quotes).
586
587
If the response values don't match, the RADIUS server responds with
588
an Access-Reject.
589
590
2.2.3. Constructing the Reply
591
592
If the authentication was successful, the RADIUS server adds an
593
attribute to the Access-Accept packet that can be used by the RADIUS
594
client to construct an Authentication-Info header:
595
596
o If the Digest-Qop Attribute's value is 'auth' or unspecified, the
597
RADIUS server SHOULD put a Digest-Response-Auth Attribute into the
598
Access-Accept packet.
599
600
o If the Digest-Qop Attribute's value is 'auth-int' and at least one
601
of the following conditions is true, the RADIUS server SHOULD put
602
a Digest-HA1 Attribute into the Access-Accept packet:
603
604
* The Digest-Algorithm Attribute's value is 'MD5-sess' or
605
'AKAv1-MD5-sess'.
606
607
* IPsec is configured to protect traffic between the RADIUS
608
client and RADIUS server with IPsec (see Section 8).
609
610
In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
611
sent.
612
613
RADIUS servers MAY construct a Digest-Nextnonce Attribute and add it
614
to the Access-Accept packet. This is useful to limit the lifetime of
615
616
617
618
Sterman, et al. Standards Track [Page 11]
619
620
RFC 5090 RADIUS Extension Digest Authentication February 2008
621
622
623
a nonce and to save a round-trip in future requests (see nextnonce
624
discussion in [RFC2617], Section 3.2.3). The RADIUS server adds a
625
Message-Authenticator Attribute (see [RFC3579]) and sends the
626
Access-Accept packet to the RADIUS client.
627
628
If the RADIUS server does not accept the nonce received in an
629
Access-Request packet but authentication was successful, the RADIUS
630
server MUST send an Access-Challenge packet containing a Digest-Stale
631
Attribute set to 'true' (without surrounding quotes). The RADIUS
632
server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce,
633
Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-
634
Qops, and MAY add Digest-Domain or Digest-Opaque attributes to the
635
Access-Challenge packet.
636
637
3. New RADIUS Attributes
638
639
If not stated otherwise, the attributes have the following format:
640
641
0 1 2
642
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
643
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
644
| Type | Length | Text ...
645
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
646
647
Quote and backslash characters in Digest-* attributes representing
648
HTTP-style directives with a quoted-string syntax are escaped. The
649
surrounding quotes are removed. They are syntactical delimiters that
650
are redundant in RADIUS. For example, the directive
651
652
realm="the \"example\" value"
653
654
is represented as follows:
655
656
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
657
| Digest-Realm | 23 | the \"example\" value |
658
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
659
660
3.1. Digest-Response Attribute
661
662
Description
663
If this attribute is present in an Access-Request message, a
664
RADIUS server implementing this specification MUST treat the
665
Access-Request as a request for Digest Authentication. When a
666
RADIUS client receives a (Proxy-)Authorization header, it puts
667
the request-digest value into a Digest-Response Attribute.
668
This attribute (which enables the user to prove possession of
669
the password) MUST only be used in Access-Request packets.
670
671
672
673
674
Sterman, et al. Standards Track [Page 12]
675
676
RFC 5090 RADIUS Extension Digest Authentication February 2008
677
678
679
Type
680
103 for Digest-Response.
681
Length
682
>= 3
683
Text
684
When using HTTP Digest, the text field is 32 octets long and
685
contains a hexadecimal representation of a 16-octet digest
686
value as it was calculated by the authenticated client. Other
687
digest algorithms MAY define different digest lengths. The
688
text field MUST be copied from request-digest of digest-
689
response [RFC2617] without surrounding quotes.
690
691
3.2. Digest-Realm Attribute
692
693
Description
694
This attribute describes a protection space component of the
695
RADIUS server. HTTP-style protocols differ in their definition
696
of the protection space. See [RFC2617], Section 1.2, for
697
details. It MUST only be used in Access-Request, Access-
698
Challenge, and Accounting-Request packets.
699
Type
700
104 for Digest-Realm
701
Length
702
>= 3
703
Text
704
In Access-Requests, the RADIUS client takes the value of the
705
realm directive (realm-value according to [RFC2617]) without
706
surrounding quotes from the HTTP-style request it wants to
707
authenticate. In Access-Challenge packets, the RADIUS server
708
puts the expected realm value into this attribute.
709
710
3.3. Digest-Nonce Attribute
711
712
Description
713
This attribute holds a nonce to be used in the HTTP Digest
714
calculation. If the Access-Request had a Digest-Method and a
715
Digest-URI but no Digest-Nonce Attribute, the RADIUS server
716
MUST put a Digest-Nonce Attribute into its Access-Challenge
717
packet. This attribute MUST only be used in Access-Request and
718
Access-Challenge packets.
719
Type
720
105 for Digest-Nonce
721
Length
722
>= 3
723
724
725
726
727
728
729
730
Sterman, et al. Standards Track [Page 13]
731
732
RFC 5090 RADIUS Extension Digest Authentication February 2008
733
734
735
Text
736
In Access-Requests, the RADIUS client takes the value of the
737
nonce directive (nonce-value in [RFC2617]) without surrounding
738
quotes from the HTTP-style request it wants to authenticate.
739
In Access-Challenge packets, the attribute contains the nonce
740
selected by the RADIUS server.
741
742
3.4. Digest-Response-Auth Attribute
743
744
Description
745
This attribute enables the RADIUS server to prove possession of
746
the password. If the previously received Digest-Qop Attribute
747
was 'auth-int' (without surrounding quotes), the RADIUS server
748
MUST send a Digest-HA1 Attribute instead of a Digest-Response-
749
Auth Attribute. The Digest-Response-Auth Attribute MUST only
750
be used in Access-Accept packets. The RADIUS client puts the
751
attribute value without surrounding quotes into the rspauth
752
directive of the Authentication-Info header.
753
Type
754
106 for Digest-Response-Auth.
755
Length
756
>= 3
757
Text
758
The RADIUS server calculates a digest according to Section
759
3.2.3 of [RFC2617] and copies the result into this attribute.
760
Digest algorithms other than the one defined in [RFC2617] MAY
761
define digest lengths other than 32.
762
763
3.5. Digest-Nextnonce Attribute
764
765
This attribute holds a nonce to be used in the HTTP Digest
766
calculation.
767
768
Description
769
The RADIUS server MAY put a Digest-Nextnonce Attribute into an
770
Access-Accept packet. If this attribute is present, the RADIUS
771
client MUST put the contents of this attribute into the
772
nextnonce directive of an Authentication-Info header in its
773
HTTP-style response. This attribute MUST only be used in
774
Access-Accept packets.
775
Type
776
107 for Digest-Nextnonce
777
Length
778
>= 3
779
Text
780
It is recommended that this text be base64 or hexadecimal data.
781
782
783
784
785
786
Sterman, et al. Standards Track [Page 14]
787
788
RFC 5090 RADIUS Extension Digest Authentication February 2008
789
790
791
3.6. Digest-Method Attribute
792
793
Description
794
This attribute holds the method value to be used in the HTTP
795
Digest calculation. This attribute MUST only be used in
796
Access-Request and Accounting-Request packets.
797
Type
798
108 for Digest-Method
799
Length
800
>= 3
801
Text
802
In Access-Requests, the RADIUS client takes the value of the
803
request method from the HTTP-style request it wants to
804
authenticate.
805
806
3.7. Digest-URI Attribute
807
808
Description
809
This attribute is used to transport the contents of the
810
digest-uri directive or the URI of the HTTP-style request. It
811
MUST only be used in Access-Request and Accounting-Request
812
packets.
813
Type
814
109 for Digest-URI
815
Length
816
>= 3
817
Text
818
If the HTTP-style request has an Authorization header, the
819
RADIUS client puts the value of the uri directive found in the
820
HTTP-style request Authorization header (known as "digest-uri-
821
value" in Section 3.2.2 of [RFC2617]) without surrounding
822
quotes into this attribute. If there is no Authorization
823
header, the RADIUS client takes the value of the request URI
824
from the HTTP-style request it wants to authenticate.
825
826
3.8. Digest-Qop Attribute
827
828
Description
829
This attribute holds the Quality of Protection parameter that
830
influences the HTTP Digest calculation. This attribute MUST
831
only be used in Access-Request, Access-Challenge, and
832
Accounting-Request packets. A RADIUS client SHOULD insert one
833
of the Digest-Qop attributes it has received in a previous
834
Access-Challenge packet. RADIUS servers SHOULD insert at least
835
one Digest-Qop Attribute in an Access-Challenge packet.
836
Digest-Qop is optional in order to preserve backward
837
compatibility with a minimal implementation of [RFC2069].
838
839
840
841
842
Sterman, et al. Standards Track [Page 15]
843
844
RFC 5090 RADIUS Extension Digest Authentication February 2008
845
846
847
Type
848
110 for Digest-Qop
849
Length
850
>= 3
851
Text
852
In Access-Requests, the RADIUS client takes the value of the
853
qop directive (qop-value as described in [RFC2617]) from the
854
HTTP-style request it wants to authenticate. In Access-
855
Challenge packets, the RADIUS server puts a desired qop-value
856
into this attribute. If the RADIUS server supports more than
857
one "quality of protection" value, it puts each qop-value into
858
a separate Digest-Qop Attribute.
859
860
3.9. Digest-Algorithm Attribute
861
862
Description
863
This attribute holds the algorithm parameter that influences
864
the HTTP Digest calculation. It MUST only be used in Access-
865
Request, Access-Challenge and Accounting-Request packets. If
866
this attribute is missing, MD5 is assumed.
867
Type
868
111 for Digest-Algorithm
869
Length
870
>= 3
871
Text
872
In Access-Requests, the RADIUS client takes the value of the
873
algorithm directive (as described in [RFC2617], Section 3.2.1)
874
from the HTTP-style request it wants to authenticate. In
875
Access-Challenge packets, the RADIUS server SHOULD put the
876
desired algorithm into this attribute.
877
878
3.10. Digest-Entity-Body-Hash Attribute
879
880
Description
881
When using the qop-value 'auth-int', a hash of the HTTP-style
882
message body's contents is required for digest calculation.
883
Instead of sending the complete body of the message, only its
884
hash value is sent. This hash value can be used directly in
885
the digest calculation.
886
887
The clarifications described in section 22.4 of [RFC3261] about
888
the hash of empty entity bodies apply to the Digest-Entity-
889
Body-Hash Attribute. This attribute MUST only be sent in
890
Access-Request packets.
891
Type
892
112 for Digest-Entity-Body-Hash
893
Length
894
>= 3
895
896
897
898
Sterman, et al. Standards Track [Page 16]
899
900
RFC 5090 RADIUS Extension Digest Authentication February 2008
901
902
903
Text
904
The attribute holds the hexadecimal representation of
905
H(entity-body). This hash is required by certain
906
authentication mechanisms, such as HTTP Digest with quality of
907
protection set to 'auth-int'. RADIUS clients MUST use this
908
attribute to transport the hash of the entity body when HTTP
909
Digest is the authentication mechanism and the RADIUS server
910
requires that the integrity of the entity body (e.g., qop
911
parameter set to 'auth-int') be verified. Extensions to this
912
document may define support for authentication mechanisms other
913
than HTTP Digest.
914
915
3.11. Digest-CNonce Attribute
916
917
Description
918
This attribute holds the client nonce parameter that is used in
919
the HTTP Digest calculation. It MUST only be used in Access-
920
Request packets.
921
Type
922
113 for Digest-CNonce
923
Length
924
>= 3
925
Text
926
This attribute includes the value of the cnonce-value [RFC2617]
927
without surrounding quotes, taken from the HTTP-style request.
928
929
3.12. Digest-Nonce-Count Attribute
930
931
Description
932
This attribute includes the nonce count parameter that is used
933
to detect replay attacks. The attribute MUST only be used in
934
Access-Request packets.
935
Type
936
114 for Digest-Nonce-Count
937
Length
938
10
939
Text
940
In Access-Requests, the RADIUS client takes the value of the nc
941
directive (nc-value according to [RFC2617]) without surrounding
942
quotes from the HTTP-style request it wants to authenticate.
943
944
3.13. Digest-Username Attribute
945
946
Description
947
This attribute holds the user name used in the HTTP Digest
948
calculation. The RADIUS server MUST use this attribute only
949
for the purposes of calculating the digest. In order to
950
determine the appropriate user credentials, the RADIUS server
951
952
953
954
Sterman, et al. Standards Track [Page 17]
955
956
RFC 5090 RADIUS Extension Digest Authentication February 2008
957
958
959
MUST use the User-Name (1) Attribute, and MUST NOT use the
960
Digest-Username Attribute. This attribute MUST only be used in
961
Access-Request and Accounting-Request packets.
962
Type
963
115 for Digest-Username
964
Length
965
>= 3
966
Text
967
In Access-Requests, the RADIUS client takes the value of the
968
username directive (username-value according to [RFC2617])
969
without surrounding quotes from the HTTP-style request it wants
970
to authenticate.
971
972
3.14. Digest-Opaque Attribute
973
974
Description
975
This attribute holds the opaque parameter that is passed to the
976
HTTP-style client. The HTTP-style client will pass this value
977
back to the server (i.e., the RADIUS client) without
978
modification. This attribute MUST only be used in Access-
979
Request and Access-Challenge packets.
980
Type
981
116 for Digest-Opaque
982
Length
983
>= 3
984
Text
985
In Access-Requests, the RADIUS client takes the value of the
986
opaque directive (opaque-value according to [RFC2617]) without
987
surrounding quotes from the HTTP-style request it wants to
988
authenticate and puts it into this attribute. In Access-
989
Challenge packets, the RADIUS server MAY include this
990
attribute.
991
992
3.15. Digest-Auth-Param Attribute
993
994
Description
995
This attribute is a placeholder for future extensions and
996
corresponds to the auth-param parameter defined in Section
997
3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism
998
whereby the RADIUS client and RADIUS server can exchange auth-
999
param extension parameters contained within Digest headers that
1000
are not understood by the RADIUS client and for which there are
1001
no corresponding stand-alone attributes.
1002
1003
Unlike the previously listed Digest-* attributes, the Digest-
1004
Auth-Param contains not only the value but also the parameter
1005
name, since the parameter name is unknown to the RADIUS client.
1006
If the Digest header contains several unknown parameters, then
1007
1008
1009
1010
Sterman, et al. Standards Track [Page 18]
1011
1012
RFC 5090 RADIUS Extension Digest Authentication February 2008
1013
1014
1015
the RADIUS implementation MUST repeat this attribute, and each
1016
instance MUST contain one different unknown Digest
1017
parameter/value combination. This attribute MUST ONLY be used
1018
in Access-Request, Access-Challenge, Access-Accept, and
1019
Accounting-Request packets.
1020
Type
1021
117 for Digest-Auth-Param
1022
Length
1023
>= 3
1024
Text
1025
The text consists of the whole parameter, including its name,
1026
the equal sign ('='), and quotes.
1027
1028
3.16. Digest-AKA-Auts Attribute
1029
1030
Description
1031
This attribute holds the auts parameter that is used in the
1032
Digest AKA [RFC3310] calculation. It is only used if the
1033
algorithm of the digest-response denotes a version of AKA
1034
Digest [RFC3310]. This attribute MUST only be used in Access-
1035
Request packets.
1036
Type
1037
118 for Digest-AKA-Auts
1038
Length
1039
>= 3
1040
Text
1041
In Access-Requests, the RADIUS client takes the value of the
1042
auts directive (auts-param according to Section 3.4 of
1043
[RFC3310]) without surrounding quotes from the HTTP-style
1044
request it wants to authenticate.
1045
1046
3.17. Digest-Domain Attribute
1047
1048
Description
1049
When a RADIUS client has asked for a nonce, the RADIUS server
1050
MAY send one or more Digest-Domain attributes in its Access-
1051
Challenge packet. The RADIUS client puts them into the quoted,
1052
space-separated list of URIs of the domain directive of a WWW-
1053
Authenticate header. Together with Digest-Realm, the URIs in
1054
the list define the protection space (see [RFC2617], Section
1055
3.2.1) for some HTTP-style protocols. This attribute MUST only
1056
be used in Access-Challenge and Accounting-Request packets.
1057
Type
1058
119 for Digest-Domain
1059
Length
1060
3
1061
1062
1063
1064
1065
1066
Sterman, et al. Standards Track [Page 19]
1067
1068
RFC 5090 RADIUS Extension Digest Authentication February 2008
1069
1070
1071
Text
1072
This attribute consists of a single URI that defines a
1073
protection space component.
1074
1075
3.18. Digest-Stale Attribute
1076
1077
Description
1078
This attribute is sent by a RADIUS server in order to notify
1079
the RADIUS client whether it has accepted a nonce. If the
1080
nonce presented by the RADIUS client was stale, the value is
1081
'true' and is 'false' otherwise. The RADIUS client puts the
1082
content of this attribute into a stale directive of the WWW-
1083
Authenticate header in the HTTP-style response to the request
1084
it wants to authenticate. The attribute MUST only be used in
1085
Access-Challenge packets.
1086
Type
1087
120 for Digest-Stale
1088
Length
1089
3
1090
Text
1091
The attribute has either the value 'true' or 'false' (both
1092
values without surrounding quotes).
1093
1094
3.19. Digest-HA1 Attribute
1095
1096
Description
1097
This attribute is used to allow the generation of an
1098
Authentication-Info header, even if the HTTP-style response's
1099
body is required for the calculation of the rspauth value. It
1100
SHOULD be used in Access-Accept packets if the required quality
1101
of protection (qop) is 'auth-int'.
1102
1103
This attribute MUST NOT be sent if the qop parameter was not
1104
specified or has a value of 'auth' (in this case, use Digest-
1105
Response-Auth instead).
1106
1107
The Digest-HA1 Attribute MUST only be sent by the RADIUS server
1108
or processed by the RADIUS client if at least one of the
1109
following conditions is true:
1110
1111
+ The Digest-Algorithm Attribute's value is 'MD5-sess' or
1112
'AKAv1-MD5-sess'.
1113
1114
+ IPsec is configured to protect traffic between the RADIUS
1115
client and RADIUS server with IPsec (see Section 8).
1116
1117
This attribute MUST only be used in Access-Accept packets.
1118
1119
1120
1121
1122
Sterman, et al. Standards Track [Page 20]
1123
1124
RFC 5090 RADIUS Extension Digest Authentication February 2008
1125
1126
1127
Type
1128
121 for Digest-HA1
1129
Length
1130
>= 3
1131
Text
1132
This attribute contains the hexadecimal representation of H(A1)
1133
as described in [RFC2617], Sections 3.1.3, 3.2.1, and 3.2.2.2.
1134
1135
3.20. SIP-AOR Attribute
1136
1137
Description
1138
This attribute is used for the authorization of SIP messages.
1139
The SIP-AOR Attribute identifies the URI, the use of which must
1140
be authenticated and authorized. The RADIUS server uses this
1141
attribute to authorize the processing of the SIP request. The
1142
SIP-AOR can be derived from, for example, the To header field
1143
in a SIP REGISTER request (user under registration), or the
1144
From header field in other SIP requests. However, the exact
1145
mapping of this attribute to SIP can change due to new
1146
developments in the protocol. This attribute MUST only be used
1147
when the RADIUS client wants to authorize SIP users and MUST
1148
only be used in Access-Request packets.
1149
Type
1150
122 for SIP-AOR
1151
Length
1152
>= 3
1153
Text
1154
The syntax of this attribute corresponds either to a SIP URI
1155
(with the format defined in [RFC3261] or a tel URI (with the
1156
format defined in [RFC3966]).
1157
1158
The SIP-AOR Attribute holds the complete URI, including
1159
parameters and other parts. It is up to the RADIUS server as
1160
to which components of the URI are regarded in the
1161
authorization decision.
1162
1163
4. Diameter Compatibility
1164
1165
This document defines support for Digest Authentication in RADIUS. A
1166
companion document "Diameter Session Initiation Protocol (SIP)
1167
Application" [RFC4740] defines support for Digest Authentication in
1168
Diameter, and addresses compatibility issues between RADIUS and
1169
Diameter.
1170
1171
5. Table of Attributes
1172
1173
The following table provides a guide to which attributes may be found
1174
in which kinds of packets, and in what quantity.
1175
1176
1177
1178
Sterman, et al. Standards Track [Page 21]
1179
1180
RFC 5090 RADIUS Extension Digest Authentication February 2008
1181
1182
1183
Access- Access- Access- Access- Acct-
1184
Request Accept Reject Challenge Req # Attribute
1185
0-1 0 0 0 0-1 1 User-Name
1186
0-1 0 0 1 0 24 State [4]
1187
1 1 1 1 0-1 80 Message-Authenticator
1188
0-1 0 0 0 0 103 Digest-Response
1189
0-1 0 0 1 0-1 104 Digest-Realm
1190
0-1 0 0 1 0 105 Digest-Nonce
1191
0 0-1 0 0 0 106 Digest-Response-Auth [1][2]
1192
0 0-1 0 0 0 107 Digest-Nextnonce
1193
1 0 0 0 0-1 108 Digest-Method
1194
0-1 0 0 0 0-1 109 Digest-URI
1195
0-1 0 0 0+ 0-1 110 Digest-Qop
1196
0-1 0 0 0-1 0-1 111 Digest-Algorithm [3]
1197
0-1 0 0 0 0 112 Digest-Entity-Body-Hash
1198
0-1 0 0 0 0 113 Digest-CNonce
1199
0-1 0 0 0 0 114 Digest-Nonce-Count
1200
0-1 0 0 0 0-1 115 Digest-Username
1201
0-1 0 0 0-1 0 116 Digest-Opaque
1202
0+ 0+ 0 0+ 0+ 117 Digest-Auth-Param
1203
0-1 0 0 0 0 118 Digest-AKA-Auts
1204
0 0 0 0+ 0+ 119 Digest-Domain
1205
0 0 0 0-1 0 120 Digest-Stale
1206
0 0-1 0 0 0 121 Digest-HA1 [1][2]
1207
0-1 0 0 0 0 122 SIP-AOR
1208
1209
The following table defines the meaning of the above table entries.
1210
1211
0 This attribute MUST NOT be present in the packet.
1212
0+ Zero or more instances of this attribute MAY be
1213
present in the packet.
1214
0-1 Zero or one instance of this attribute MAY be
1215
present in the packet.
1216
1217
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
1218
Digest-Qop is 'auth-int'.
1219
1220
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
1221
Digest-Qop is 'auth'.
1222
1223
[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
1224
1225
[Note 4] An Access-Challenge MUST contain a State attribute, which is
1226
copied to the subsequent Access-Request. A server receiving
1227
an Access-Request that contains a State attribute MUST
1228
respond with either an Access-Accept or an Access-Reject;
1229
the server MUST NOT respond with an Access-Challenge.
1230
1231
1232
1233
1234
Sterman, et al. Standards Track [Page 22]
1235
1236
RFC 5090 RADIUS Extension Digest Authentication February 2008
1237
1238
1239
6. Examples
1240
1241
This is an example selected from the traffic between a softphone (A),
1242
a Proxy Server (B), and an example.com RADIUS server (C). The
1243
communication between the Proxy Server and a SIP Public Switched
1244
Telephone Network (PSTN) gateway is omitted for brevity. The SIP
1245
messages are not shown completely.
1246
1247
The password of user '12345678' is 'secret'. The shared secret
1248
between the RADIUS client and server is 'secret'. To ease testing,
1249
only the last byte of the RADIUS authenticator changes between
1250
requests. In a real implementation, this would be a serious flaw.
1251
1252
A->B
1253
1254
INVITE sip:97226491335@example.com SIP/2.0
1255
From: <sip:12345678@example.com>
1256
To: <sip:97226491335@example.com>
1257
1258
B->A
1259
1260
SIP/2.0 100 Trying
1261
1262
B->C
1263
1264
Code = Access-Request (1)
1265
Packet identifier = 0x7c (124)
1266
Length = 97
1267
Authenticator = F5E55840E324AA49D216D9DBD069807C
1268
NAS-IP-Address = 192.0.2.38
1269
NAS-Port = 5
1270
User-Name = 12345678
1271
Digest-Method = INVITE
1272
Digest-URI = sip:97226491335@example.com
1273
Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B
1274
1275
C->B
1276
1277
Code = Access-challenge (11)
1278
Packet identifier = 0x7c (124)
1279
Length = 72
1280
Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
1281
Digest-Nonce = 3bada1a0
1282
Digest-Realm = example.com
1283
Digest-Qop = auth
1284
Digest-Algorithm = MD5
1285
Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3
1286
1287
1288
1289
1290
Sterman, et al. Standards Track [Page 23]
1291
1292
RFC 5090 RADIUS Extension Digest Authentication February 2008
1293
1294
1295
B->A
1296
1297
SIP/2.0 407 Proxy Authentication Required
1298
Proxy-Authenticate: Digest realm="example.com"
1299
,nonce="3bada1a0",qop=auth,algorithm=MD5
1300
Content-Length: 0
1301
1302
A->B
1303
1304
ACK sip:97226491335@example.com SIP/2.0
1305
1306
A->B
1307
1308
INVITE sip:97226491335@example.com SIP/2.0
1309
Proxy-Authorization: Digest nonce="3bada1a0"
1310
,realm="example.com"
1311
,response="756933f735fcd93f90a4bbdd5467f263"
1312
,uri="sip:97226491335@example.com",username="12345678"
1313
,qop=auth,algorithm=MD5
1314
,cnonce="56593a80,nc="00000001"
1315
1316
From: <sip:12345678@example.com>
1317
To: <sip:97226491335@example.com>
1318
1319
B->C
1320
1321
Code = Access-Request (1)
1322
Packet identifier = 0x7d (125)
1323
Length = 221
1324
Authenticator = F5E55840E324AA49D216D9DBD069807D
1325
NAS-IP-Address = 192.0.2.38
1326
NAS-Port = 5
1327
User-Name = 12345678
1328
Digest-Method = INVITE
1329
Digest-URI = sip:97226491335@example.com
1330
Digest-Realm = example.com
1331
Digest-Qop = auth
1332
Digest-Algorithm = MD5
1333
Digest-CNonce = 56593a80
1334
Digest-Nonce = 3bada1a0
1335
Digest-Nonce-Count = 00000001
1336
Digest-Response = 756933f735fcd93f90a4bbdd5467f263
1337
Digest-Username = 12345678
1338
SIP-AOR = sip:12345678@example.com
1339
Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60
1340
1341
1342
1343
1344
1345
1346
Sterman, et al. Standards Track [Page 24]
1347
1348
RFC 5090 RADIUS Extension Digest Authentication February 2008
1349
1350
1351
C->B
1352
1353
Code = Access-Accept (2)
1354
Packet identifier = 0x7d (125)
1355
Length = 72
1356
Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2
1357
Digest-Response-Auth = f847de948d12285f8f4199e366f1af21
1358
Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E
1359
1360
B->A
1361
1362
SIP/2.0 180 Ringing
1363
1364
B->A
1365
1366
SIP/2.0 200 OK
1367
1368
A->B
1369
1370
ACK sip:97226491335@example.com SIP/2.0
1371
1372
A second example shows the traffic between a web browser (A), a web
1373
server (B), and a RADIUS server (C).
1374
1375
A->B
1376
1377
GET /index.html HTTP/1.1
1378
1379
B->C
1380
1381
Code = Access-Request (1)
1382
Packet identifier = 0x7e (126)
1383
Length = 68
1384
Authenticator = F5E55840E324AA49D216D9DBD069807E
1385
NAS-IP-Address = 192.0.2.38
1386
NAS-Port = 5
1387
Digest-Method = GET
1388
Digest-URI = /index.html
1389
Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
Sterman, et al. Standards Track [Page 25]
1403
1404
RFC 5090 RADIUS Extension Digest Authentication February 2008
1405
1406
1407
C->B
1408
1409
Code = Access-challenge (11)
1410
Packet identifier = 0x7e (126)
1411
Length = 72
1412
Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
1413
Digest-Nonce = a3086ac8
1414
Digest-Realm = example.com
1415
Digest-Qop = auth
1416
Digest-Algorithm = MD5
1417
Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A
1418
1419
B->A
1420
1421
HTTP/1.1 401 Authentication Required
1422
WWW-Authenticate: Digest realm="example.com",
1423
nonce="a3086ac8",qop=auth,algorithm=MD5
1424
Content-Length: 0
1425
1426
A->B
1427
1428
GET /index.html HTTP/1.1
1429
Authorization: Digest = algorithm=MD5,qop=auth,nonce="a3086ac8"
1430
,nc="00000001",cnonce="56593a80"
1431
,realm="example.com"
1432
,response="a4fac45c27a30f4f244c54a2e99fa117"
1433
,uri="/index.html",username="12345678"
1434
1435
B->C
1436
1437
Code = Access-Request (1)
1438
Packet identifier = 0x7f (127)
1439
Length = 176
1440
Authenticator = F5E55840E324AA49D216D9DBD069807F
1441
NAS-IP-Address = 192.0.2.38
1442
NAS-Port = 5
1443
User-Name = 12345678
1444
Digest-Method = GET
1445
Digest-URI = /index.html
1446
Digest-Realm = example.com
1447
Digest-Qop = auth
1448
Digest-Algorithm = MD5
1449
Digest-CNonce = 56593a80
1450
Digest-Nonce = a3086ac8
1451
Digest-Nonce-Count = 00000001
1452
Digest-Response = a4fac45c27a30f4f244c54a2e99fa117
1453
Digest-Username = 12345678
1454
Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821
1455
1456
1457
1458
Sterman, et al. Standards Track [Page 26]
1459
1460
RFC 5090 RADIUS Extension Digest Authentication February 2008
1461
1462
1463
C->B
1464
1465
Code = Access-Accept (2)
1466
Packet identifier = 0x7f (127)
1467
Length = 72
1468
Authenticator = 6364FA6ED66012847C05A0895607C694
1469
Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147
1470
Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56
1471
1472
B->A
1473
1474
HTTP/1.1 200 OK
1475
...
1476
1477
<html>
1478
...
1479
1480
7. IANA Considerations
1481
1482
The following values from the RADIUS Attribute Types number space
1483
were assigned in [RFC4590]. This document requests that the values
1484
in the table below be entered within the existing registry.
1485
1486
Attribute #
1487
--------------- ----
1488
Digest-Response 103
1489
Digest-Realm 104
1490
Digest-Nonce 105
1491
Digest-Response-Auth 106
1492
Digest-Nextnonce 107
1493
Digest-Method 108
1494
Digest-URI 109
1495
Digest-Qop 110
1496
Digest-Algorithm 111
1497
Digest-Entity-Body-Hash 112
1498
Digest-CNonce 113
1499
Digest-Nonce-Count 114
1500
Digest-Username 115
1501
Digest-Opaque 116
1502
Digest-Auth-Param 117
1503
Digest-AKA-Auts 118
1504
Digest-Domain 119
1505
Digest-Stale 120
1506
Digest-HA1 121
1507
SIP-AOR 122
1508
1509
1510
1511
1512
1513
1514
Sterman, et al. Standards Track [Page 27]
1515
1516
RFC 5090 RADIUS Extension Digest Authentication February 2008
1517
1518
1519
8. Security Considerations
1520
1521
The RADIUS extensions described in this document enable RADIUS to
1522
transport the data that is required to perform a digest calculation.
1523
As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
1524
[RFC2617], Section 4) in addition to RADIUS security vulnerabilities
1525
described in [RFC2865], Section 8, and [RFC3579], Section 4.
1526
1527
An attacker compromising a RADIUS client or proxy can carry out man-
1528
in-the-middle attacks even if the paths between A, B and B, C (Figure
1529
2) have been secured with TLS or IPsec.
1530
1531
The RADIUS server MUST check the Digest-Realm Attribute it has
1532
received from a client. If the RADIUS client is not authorized to
1533
serve HTTP-style clients of that realm, it might be compromised.
1534
1535
8.1. Denial of Service
1536
1537
RADIUS clients implementing the extension described in this document
1538
may authenticate HTTP-style requests received over the Internet. As
1539
compared with the use of RADIUS to authenticate link-layer network
1540
access, attackers may find it easier to cover their tracks in such a
1541
scenario.
1542
1543
An attacker can attempt a denial-of-service attack on one or more
1544
RADIUS servers by sending a large number of HTTP-style requests. To
1545
make simple denial-of-service attacks more difficult, the RADIUS
1546
server MUST check whether it has generated the nonce received from an
1547
HTTP-style client. This SHOULD be done statelessly. For example, a
1548
nonce could consist of a cryptographically random part and some kind
1549
of signature provided by the RADIUS client, as described in
1550
[RFC2617], Section 3.2.1.
1551
1552
8.2. Confidentiality and Data Integrity
1553
1554
The attributes described in this document are sent in cleartext.
1555
RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
1556
attributes in Access-Challenge messages. A man in the middle can
1557
modify or remove those attributes in a bidding down attack, causing
1558
the RADIUS client to use a weaker authentication scheme than
1559
intended.
1560
1561
The Message-Authenticator Attribute, described in [RFC3579], Section
1562
3.2 MUST be included in Access-Request, Access-Challenge, Access-
1563
Reject, and Access-Accept messages that contain attributes described
1564
in this specification.
1565
1566
1567
1568
1569
1570
Sterman, et al. Standards Track [Page 28]
1571
1572
RFC 5090 RADIUS Extension Digest Authentication February 2008
1573
1574
1575
The Digest-HA1 Attribute contains no random components if the
1576
algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
1577
attacks easier and enables replay attacks.
1578
1579
Some parameter combinations require the protection of RADIUS packets
1580
against eavesdropping and tampering. Implementations SHOULD try to
1581
determine automatically whether IPsec is configured to protect
1582
traffic between the RADIUS client and the RADIUS server. If this is
1583
not possible, the implementation checks a configuration parameter
1584
telling it whether IPsec will protect RADIUS traffic. The default
1585
value of this configuration parameter tells the implementation that
1586
RADIUS packets will not be protected.
1587
1588
HTTP-style clients can use TLS with server-side certificates together
1589
with HTTP-Digest Authentication. Instead of TLS, IPsec can be used,
1590
too. TLS or IPsec secure the connection while Digest Authentication
1591
authenticates the user. The RADIUS transaction can be regarded as
1592
one leg on the path between the HTTP-style client and the HTTP-style
1593
server. To prevent RADIUS from representing the weak link, a RADIUS
1594
client receiving an HTTP-style request via TLS or IPsec could use an
1595
equally secure connection to the RADIUS server. There are several
1596
ways to achieve this, for example:
1597
1598
o The RADIUS client may reject HTTP-style requests received over TLS
1599
or IPsec.
1600
1601
o The RADIUS client may require that traffic be sent and received
1602
over IPsec.
1603
1604
RADIUS over IPsec, if used, MUST conform to the requirements
1605
described in [RFC3579], Section 4.2.
1606
1607
9. References
1608
1609
9.1. Normative References
1610
1611
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1612
Requirement Levels", BCP 14, RFC 2119, March 1997.
1613
1614
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1615
Leach, P., Luotonen, A., and L. Stewart, "HTTP
1616
Authentication: Basic and Digest Access Authentication",
1617
RFC 2617, June 1999.
1618
1619
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1620
"Remote Authentication Dial In User Service (RADIUS)", RFC
1621
2865, June 2000.
1622
1623
1624
1625
1626
Sterman, et al. Standards Track [Page 29]
1627
1628
RFC 5090 RADIUS Extension Digest Authentication February 2008
1629
1630
1631
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1632
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
1633
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
1634
1635
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
1636
Dial In User Service) Support For Extensible Authentication
1637
Protocol (EAP)", RFC 3579, September 2003.
1638
1639
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
1640
3966, December 2004.
1641
1642
9.2. Informative References
1643
1644
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
1645
Protocol (CHAP)", RFC 1994, August 1996.
1646
1647
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
1648
Luotonen, A., Sink, E., and L. Stewart, "An Extension to
1649
HTTP : Digest Access Authentication", RFC 2069, January
1650
1997.
1651
1652
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
1653
Protocol (HTTP) Digest Authentication Using Authentication
1654
and Key Agreement (AKA)", RFC 3310, September 2002.
1655
1656
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
1657
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
1658
1659
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
1660
Extensions (S/MIME) Version 3.1 Message Specification", RFC
1661
3851, July 2004.
1662
1663
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1664
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
1665
1666
[RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D.,
1667
and W. Beck, "RADIUS Extension for Digest Authentication",
1668
RFC 4590, July 2006.
1669
1670
[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M.,
1671
Canales-Valenzuela, C., and K. Tammi, "Diameter Session
1672
Initiation Protocol (SIP) Application", RFC 4740, November
1673
2006.
1674
1675
1676
1677
1678
1679
1680
1681
1682
Sterman, et al. Standards Track [Page 30]
1683
1684
RFC 5090 RADIUS Extension Digest Authentication February 2008
1685
1686
1687
Appendix A - Changes from RFC 4590
1688
1689
This Appendix lists the major changes between [RFC4590] and this
1690
document. Minor changes, including style, grammar, spelling, and
1691
editorial changes are not mentioned here.
1692
1693
o The Table of Attributes (Section 5) now indicates that the
1694
Digest-Method Attribute is required within an Access-Request.
1695
Also, an entry has been added for the State attribute. The table
1696
also includes entries for Accounting-Request messages. As noted
1697
in the examples, the User-Name Attribute is not necessary when
1698
requesting a nonce.
1699
1700
o Two errors in attribute assignment have been corrected within the
1701
IANA Considerations (Section 7). Digest-Response-Auth is assigned
1702
attribute 106, and Digest-Nextnonce is assigned attribute 107.
1703
1704
o Several errors in the examples section have been corrected.
1705
1706
Acknowledgments
1707
1708
The authors would like to thank Mike McCauley for his help in working
1709
through the details of the examples.
1710
1711
We would like to acknowledge Kevin McDermott (Cisco Systems) for
1712
providing comments and experimental implementation.
1713
1714
Many thanks to all reviewers, especially to Miguel Garcia, Jari
1715
Arkko, Avi Lior, and Jun Wang.
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
Sterman, et al. Standards Track [Page 31]
1739
1740
RFC 5090 RADIUS Extension Digest Authentication February 2008
1741
1742
1743
Authors' Addresses
1744
1745
Baruch Sterman
1746
Kayote Networks
1747
P.O. Box 1373
1748
Efrat 90435
1749
Israel
1750
1751
EMail: baruch@kayote.com
1752
1753
Daniel Sadolevsky
1754
SecureOL, Inc.
1755
Jerusalem Technology Park
1756
P.O. Box 16120
1757
Jerusalem 91160
1758
Israel
1759
1760
EMail: dscreat@dscreat.com
1761
1762
David Schwartz
1763
Kayote Networks
1764
P.O. Box 1373
1765
Efrat 90435
1766
Israel
1767
1768
EMail: david@kayote.com
1769
1770
David Williams
1771
Cisco Systems
1772
7025 Kit Creek Road
1773
P.O. Box 14987
1774
Research Triangle Park NC 27709
1775
USA
1776
1777
EMail: dwilli@cisco.com
1778
1779
Wolfgang Beck
1780
Deutsche Telekom AG
1781
Deutsche Telekom Allee 7
1782
Darmstadt 64295
1783
Germany
1784
1785
EMail: beckw@t-systems.com
1786
1787
1788
1789
1790
1791
1792
1793
1794
Sterman, et al. Standards Track [Page 32]
1795
1796
RFC 5090 RADIUS Extension Digest Authentication February 2008
1797
1798
1799
Full Copyright Statement
1800
1801
Copyright (C) The IETF Trust (2008).
1802
1803
This document is subject to the rights, licenses and restrictions
1804
contained in BCP 78, and except as set forth therein, the authors
1805
retain all their rights.
1806
1807
This document and the information contained herein are provided on an
1808
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1809
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1810
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1811
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1812
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1813
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1814
1815
Intellectual Property
1816
1817
The IETF takes no position regarding the validity or scope of any
1818
Intellectual Property Rights or other rights that might be claimed to
1819
pertain to the implementation or use of the technology described in
1820
this document or the extent to which any license under such rights
1821
might or might not be available; nor does it represent that it has
1822
made any independent effort to identify any such rights. Information
1823
on the procedures with respect to rights in RFC documents can be
1824
found in BCP 78 and BCP 79.
1825
1826
Copies of IPR disclosures made to the IETF Secretariat and any
1827
assurances of licenses to be made available, or the result of an
1828
attempt made to obtain a general license or permission for the use of
1829
such proprietary rights by implementers or users of this
1830
specification can be obtained from the IETF on-line IPR repository at
1831
http://www.ietf.org/ipr.
1832
1833
The IETF invites any interested party to bring to its attention any
1834
copyrights, patents or patent applications, or other proprietary
1835
rights that may cover technology that may be required to implement
1836
this standard. Please address the information to the IETF at
1837
ietf-ipr@ietf.org.
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
Sterman, et al. Standards Track [Page 33]
1851
Loggerhead is a web-based interface for Breezy
Version: 2.0.1