← Back to branch summary

~ubuntu-branches/ubuntu/utopic/strongswan/utopic

« back to all changes in this revision

Viewing changes to doc/standards/rfc2865.txt

  • Committer: Package Import Robot
  • Author(s): Jonathan Davies
  • Date: 2014-01-20 19:00:59 UTC
  • mfrom: (1.2.6)
  • Revision ID: package-import@ubuntu.com-20140120190059-z8e4dl3g8cd09yi5
Tags: 5.1.2~dr3+git20130120-0ubuntu1
* Upstream Git snapshot for build fixes with regards to entropy.
* debian/rules:
  - Enforcing DEB_BUILD_OPTIONS=nostrip for library integrity checking.
  - Set TESTS_REDUCED_KEYLENGTHS to one generate smallest key-lengths in
    tests.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/standards/rfc2865.txt
 
1
 
 
2
 
 
3
 
 
4
 
 
5
 
 
6
 
 
7
Network Working Group                                          C. Rigney
 
8
Request for Comments: 2865                                    S. Willens
 
9
Obsoletes: 2138                                               Livingston
 
10
Category: Standards Track                                      A. Rubens
 
11
                                                                   Merit
 
12
                                                              W. Simpson
 
13
                                                              Daydreamer
 
14
                                                               June 2000
 
15
 
 
16
 
 
17
          Remote Authentication Dial In User Service (RADIUS)
 
18
 
 
19
Status of this Memo
 
20
 
 
21
   This document specifies an Internet standards track protocol for the
 
22
   Internet community, and requests discussion and suggestions for
 
23
   improvements.  Please refer to the current edition of the "Internet
 
24
   Official Protocol Standards" (STD 1) for the standardization state
 
25
   and status of this protocol.  Distribution of this memo is unlimited.
 
26
 
 
27
Copyright Notice
 
28
 
 
29
   Copyright (C) The Internet Society (2000).  All Rights Reserved.
 
30
 
 
31
IESG Note:
 
32
 
 
33
   This protocol is widely implemented and used.  Experience has shown
 
34
   that it can suffer degraded performance and lost data when used in
 
35
   large scale systems, in part because it does not include provisions
 
36
   for congestion control.  Readers of this document may find it
 
37
   beneficial to track the progress of the IETF's AAA working group,
 
38
   which may develop a successor protocol that better addresses the
 
39
   scaling and congestion control issues.
 
40
 
 
41
Abstract
 
42
 
 
43
   This document describes a protocol for carrying authentication,
 
44
   authorization, and configuration information between a Network Access
 
45
   Server which desires to authenticate its links and a shared
 
46
   Authentication Server.
 
47
 
 
48
Implementation Note
 
49
 
 
50
   This memo documents the RADIUS protocol.  The early deployment of
 
51
   RADIUS was done using UDP port number 1645, which conflicts with the
 
52
   "datametrics" service.  The officially assigned port number for
 
53
   RADIUS is 1812.
 
54
 
 
55
 
 
56
 
 
57
 
 
58
Rigney, et al.              Standards Track                     [Page 1]
 
59
 
 
60
RFC 2865                         RADIUS                        June 2000
 
61
 
 
62
 
 
63
Table of Contents
 
64
 
 
65
   1.     Introduction ..........................................    3
 
66
      1.1       Specification of Requirements ...................    4
 
67
      1.2       Terminology .....................................    5
 
68
   2.     Operation .............................................    5
 
69
      2.1       Challenge/Response ..............................    7
 
70
      2.2       Interoperation with PAP and CHAP ................    8
 
71
      2.3       Proxy ...........................................    8
 
72
      2.4       Why UDP? ........................................   11
 
73
      2.5       Retransmission Hints ............................   12
 
74
      2.6       Keep-Alives Considered Harmful ..................   13
 
75
   3.     Packet Format .........................................   13
 
76
   4.     Packet Types ..........................................   17
 
77
      4.1       Access-Request ..................................   17
 
78
      4.2       Access-Accept ...................................   18
 
79
      4.3       Access-Reject ...................................   20
 
80
      4.4       Access-Challenge ................................   21
 
81
   5.     Attributes ............................................   22
 
82
      5.1       User-Name .......................................   26
 
83
      5.2       User-Password ...................................   27
 
84
      5.3       CHAP-Password ...................................   28
 
85
      5.4       NAS-IP-Address ..................................   29
 
86
      5.5       NAS-Port ........................................   30
 
87
      5.6       Service-Type ....................................   31
 
88
      5.7       Framed-Protocol .................................   33
 
89
      5.8       Framed-IP-Address ...............................   34
 
90
      5.9       Framed-IP-Netmask ...............................   34
 
91
      5.10      Framed-Routing ..................................   35
 
92
      5.11      Filter-Id .......................................   36
 
93
      5.12      Framed-MTU ......................................   37
 
94
      5.13      Framed-Compression ..............................   37
 
95
      5.14      Login-IP-Host ...................................   38
 
96
      5.15      Login-Service ...................................   39
 
97
      5.16      Login-TCP-Port ..................................   40
 
98
      5.17      (unassigned) ....................................   41
 
99
      5.18      Reply-Message ...................................   41
 
100
      5.19      Callback-Number .................................   42
 
101
      5.20      Callback-Id .....................................   42
 
102
      5.21      (unassigned) ....................................   43
 
103
      5.22      Framed-Route ....................................   43
 
104
      5.23      Framed-IPX-Network ..............................   44
 
105
      5.24      State ...........................................   45
 
106
      5.25      Class ...........................................   46
 
107
      5.26      Vendor-Specific .................................   47
 
108
      5.27      Session-Timeout .................................   48
 
109
      5.28      Idle-Timeout ....................................   49
 
110
      5.29      Termination-Action ..............................   49
 
111
 
 
112
 
 
113
 
 
114
Rigney, et al.              Standards Track                     [Page 2]
 
115
 
 
116
RFC 2865                         RADIUS                        June 2000
 
117
 
 
118
 
 
119
      5.30      Called-Station-Id ...............................   50
 
120
      5.31      Calling-Station-Id ..............................   51
 
121
      5.32      NAS-Identifier ..................................   52
 
122
      5.33      Proxy-State .....................................   53
 
123
      5.34      Login-LAT-Service ...............................   54
 
124
      5.35      Login-LAT-Node ..................................   55
 
125
      5.36      Login-LAT-Group .................................   56
 
126
      5.37      Framed-AppleTalk-Link ...........................   57
 
127
      5.38      Framed-AppleTalk-Network ........................   58
 
128
      5.39      Framed-AppleTalk-Zone ...........................   58
 
129
      5.40      CHAP-Challenge ..................................   59
 
130
      5.41      NAS-Port-Type ...................................   60
 
131
      5.42      Port-Limit ......................................   61
 
132
      5.43      Login-LAT-Port ..................................   62
 
133
      5.44      Table of Attributes .............................   63
 
134
   6.     IANA Considerations ...................................   64
 
135
      6.1       Definition of Terms .............................   64
 
136
      6.2       Recommended Registration Policies ...............   65
 
137
   7.     Examples ..............................................   66
 
138
      7.1       User Telnet to Specified Host ...................   66
 
139
      7.2       Framed User Authenticating with CHAP ............   67
 
140
      7.3       User with Challenge-Response card ...............   68
 
141
   8.     Security Considerations ...............................   71
 
142
   9.     Change Log ............................................   71
 
143
   10.    References ............................................   73
 
144
   11.    Acknowledgements ......................................   74
 
145
   12.    Chair's Address .......................................   74
 
146
   13.    Authors' Addresses ....................................   75
 
147
   14.    Full Copyright Statement ..............................   76
 
148
 
 
149
1.  Introduction
 
150
 
 
151
   This document obsoletes RFC 2138 [1].  A summary of the changes
 
152
   between this document and RFC 2138 is available in the "Change Log"
 
153
   appendix.
 
154
 
 
155
   Managing dispersed serial line and modem pools for large numbers of
 
156
   users can create the need for significant administrative support.
 
157
   Since modem pools are by definition a link to the outside world, they
 
158
   require careful attention to security, authorization and accounting.
 
159
   This can be best achieved by managing a single "database" of users,
 
160
   which allows for authentication (verifying user name and password) as
 
161
   well as configuration information detailing the type of service to
 
162
   deliver to the user (for example, SLIP, PPP, telnet, rlogin).
 
163
 
 
164
 
 
165
 
 
166
 
 
167
 
 
168
 
 
169
 
 
170
Rigney, et al.              Standards Track                     [Page 3]
 
171
 
 
172
RFC 2865                         RADIUS                        June 2000
 
173
 
 
174
 
 
175
   Key features of RADIUS are:
 
176
 
 
177
   Client/Server Model
 
178
 
 
179
      A Network Access Server (NAS) operates as a client of RADIUS.  The
 
180
      client is responsible for passing user information to designated
 
181
      RADIUS servers, and then acting on the response which is returned.
 
182
 
 
183
      RADIUS servers are responsible for receiving user connection
 
184
      requests, authenticating the user, and then returning all
 
185
      configuration information necessary for the client to deliver
 
186
      service to the user.
 
187
 
 
188
      A RADIUS server can act as a proxy client to other RADIUS servers
 
189
      or other kinds of authentication servers.
 
190
 
 
191
   Network Security
 
192
 
 
193
      Transactions between the client and RADIUS server are
 
194
      authenticated through the use of a shared secret, which is never
 
195
      sent over the network.  In addition, any user passwords are sent
 
196
      encrypted between the client and RADIUS server, to eliminate the
 
197
      possibility that someone snooping on an unsecure network could
 
198
      determine a user's password.
 
199
 
 
200
   Flexible Authentication Mechanisms
 
201
 
 
202
      The RADIUS server can support a variety of methods to authenticate
 
203
      a user.  When it is provided with the user name and original
 
204
      password given by the user, it can support PPP PAP or CHAP, UNIX
 
205
      login, and other authentication mechanisms.
 
206
 
 
207
   Extensible Protocol
 
208
 
 
209
      All transactions are comprised of variable length Attribute-
 
210
      Length-Value 3-tuples.  New attribute values can be added without
 
211
      disturbing existing implementations of the protocol.
 
212
 
 
213
1.1.  Specification of Requirements
 
214
 
 
215
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 
216
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 
217
   document are to be interpreted as described in BCP 14 [2].  These key
 
218
   words mean the same thing whether capitalized or not.
 
219
 
 
220
   An implementation is not compliant if it fails to satisfy one or more
 
221
   of the must or must not requirements for the protocols it implements.
 
222
   An implementation that satisfies all the must, must not, should and
 
223
 
 
224
 
 
225
 
 
226
Rigney, et al.              Standards Track                     [Page 4]
 
227
 
 
228
RFC 2865                         RADIUS                        June 2000
 
229
 
 
230
 
 
231
   should not requirements for its protocols is said to be
 
232
   "unconditionally compliant"; one that satisfies all the must and must
 
233
   not requirements but not all the should or should not requirements
 
234
   for its protocols is said to be "conditionally compliant".
 
235
 
 
236
   A NAS that does not implement a given service MUST NOT implement the
 
237
   RADIUS attributes for that service.  For example, a NAS that is
 
238
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
 
239
   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
 
240
   unavailable service as an access-reject instead.
 
241
 
 
242
1.2.  Terminology
 
243
 
 
244
   This document frequently uses the following terms:
 
245
 
 
246
   service   The NAS provides a service to the dial-in user, such as PPP
 
247
             or Telnet.
 
248
 
 
249
   session   Each service provided by the NAS to a dial-in user
 
250
             constitutes a session, with the beginning of the session
 
251
             defined as the point where service is first provided and
 
252
             the end of the session defined as the point where service
 
253
             is ended.  A user may have multiple sessions in parallel or
 
254
             series if the NAS supports that.
 
255
 
 
256
   silently discard
 
257
             This means the implementation discards the packet without
 
258
             further processing.  The implementation SHOULD provide the
 
259
             capability of logging the error, including the contents of
 
260
             the silently discarded packet, and SHOULD record the event
 
261
             in a statistics counter.
 
262
 
 
263
2.  Operation
 
264
 
 
265
   When a client is configured to use RADIUS, any user of the client
 
266
   presents authentication information to the client.  This might be
 
267
   with a customizable login prompt, where the user is expected to enter
 
268
   their username and password.  Alternatively, the user might use a
 
269
   link framing protocol such as the Point-to-Point Protocol (PPP),
 
270
   which has authentication packets which carry this information.
 
271
 
 
272
   Once the client has obtained such information, it may choose to
 
273
   authenticate using RADIUS.  To do so, the client creates an "Access-
 
274
   Request" containing such Attributes as the user's name, the user's
 
275
   password, the ID of the client and the Port ID which the user is
 
276
   accessing.  When a password is present, it is hidden using a method
 
277
   based on the RSA Message Digest Algorithm MD5 [3].
 
278
 
 
279
 
 
280
 
 
281
 
 
282
Rigney, et al.              Standards Track                     [Page 5]
 
283
 
 
284
RFC 2865                         RADIUS                        June 2000
 
285
 
 
286
 
 
287
   The Access-Request is submitted to the RADIUS server via the network.
 
288
   If no response is returned within a length of time, the request is
 
289
   re-sent a number of times.  The client can also forward requests to
 
290
   an alternate server or servers in the event that the primary server
 
291
   is down or unreachable.  An alternate server can be used either after
 
292
   a number of tries to the primary server fail, or in a round-robin
 
293
   fashion.  Retry and fallback algorithms are the topic of current
 
294
   research and are not specified in detail in this document.
 
295
 
 
296
   Once the RADIUS server receives the request, it validates the sending
 
297
   client.  A request from a client for which the RADIUS server does not
 
298
   have a shared secret MUST be silently discarded.  If the client is
 
299
   valid, the RADIUS server consults a database of users to find the
 
300
   user whose name matches the request.  The user entry in the database
 
301
   contains a list of requirements which must be met to allow access for
 
302
   the user.  This always includes verification of the password, but can
 
303
   also specify the client(s) or port(s) to which the user is allowed
 
304
   access.
 
305
 
 
306
   The RADIUS server MAY make requests of other servers in order to
 
307
   satisfy the request, in which case it acts as a client.
 
308
 
 
309
   If any Proxy-State attributes were present in the Access-Request,
 
310
   they MUST be copied unmodified and in order into the response packet.
 
311
   Other Attributes can be placed before, after, or even between the
 
312
   Proxy-State attributes.
 
313
 
 
314
   If any condition is not met, the RADIUS server sends an "Access-
 
315
   Reject" response indicating that this user request is invalid.  If
 
316
   desired, the server MAY include a text message in the Access-Reject
 
317
   which MAY be displayed by the client to the user.  No other
 
318
   Attributes (except Proxy-State) are permitted in an Access-Reject.
 
319
 
 
320
   If all conditions are met and the RADIUS server wishes to issue a
 
321
   challenge to which the user must respond, the RADIUS server sends an
 
322
   "Access-Challenge" response.  It MAY include a text message to be
 
323
   displayed by the client to the user prompting for a response to the
 
324
   challenge, and MAY include a State attribute.
 
325
 
 
326
   If the client receives an Access-Challenge and supports
 
327
   challenge/response it MAY display the text message, if any, to the
 
328
   user, and then prompt the user for a response.  The client then re-
 
329
   submits its original Access-Request with a new request ID, with the
 
330
   User-Password Attribute replaced by the response (encrypted), and
 
331
   including the State Attribute from the Access-Challenge, if any.
 
332
   Only 0 or 1 instances of the State Attribute SHOULD be
 
333
 
 
334
 
 
335
 
 
336
 
 
337
 
 
338
Rigney, et al.              Standards Track                     [Page 6]
 
339
 
 
340
RFC 2865                         RADIUS                        June 2000
 
341
 
 
342
 
 
343
   present in a request.  The server can respond to this new Access-
 
344
   Request with either an Access-Accept, an Access-Reject, or another
 
345
   Access-Challenge.
 
346
 
 
347
   If all conditions are met, the list of configuration values for the
 
348
   user are placed into an "Access-Accept" response.  These values
 
349
   include the type of service (for example: SLIP, PPP, Login User) and
 
350
   all necessary values to deliver the desired service.  For SLIP and
 
351
   PPP, this may include values such as IP address, subnet mask, MTU,
 
352
   desired compression, and desired packet filter identifiers.  For
 
353
   character mode users, this may include values such as desired
 
354
   protocol and host.
 
355
 
 
356
2.1.  Challenge/Response
 
357
 
 
358
   In challenge/response authentication, the user is given an
 
359
   unpredictable number and challenged to encrypt it and give back the
 
360
   result. Authorized users are equipped with special devices such as
 
361
   smart cards or software that facilitate calculation of the correct
 
362
   response with ease. Unauthorized users, lacking the appropriate
 
363
   device or software and lacking knowledge of the secret key necessary
 
364
   to emulate such a device or software, can only guess at the response.
 
365
 
 
366
   The Access-Challenge packet typically contains a Reply-Message
 
367
   including a challenge to be displayed to the user, such as a numeric
 
368
   value unlikely ever to be repeated. Typically this is obtained from
 
369
   an external server that knows what type of authenticator is in the
 
370
   possession of the authorized user and can therefore choose a random
 
371
   or non-repeating pseudorandom number of an appropriate radix and
 
372
   length.
 
373
 
 
374
   The user then enters the challenge into his device (or software) and
 
375
   it calculates a response, which the user enters into the client which
 
376
   forwards it to the RADIUS server via a second Access-Request.  If the
 
377
   response matches the expected response the RADIUS server replies with
 
378
   an Access-Accept, otherwise an Access-Reject.
 
379
 
 
380
   Example: The NAS sends an Access-Request packet to the RADIUS Server
 
381
   with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
 
382
   just be a fixed string like "challenge" or ignored).  The server
 
383
   sends back an Access-Challenge packet with State and a Reply-Message
 
384
   along the lines of "Challenge 12345678, enter your response at the
 
385
   prompt" which the NAS displays.  The NAS prompts for the response and
 
386
   sends a NEW Access-Request to the server (with a new ID) with NAS-
 
387
   Identifier, NAS-Port, User-Name, User-Password (the response just
 
388
   entered by the user, encrypted), and the same State Attribute that
 
389
 
 
390
 
 
391
 
 
392
 
 
393
 
 
394
Rigney, et al.              Standards Track                     [Page 7]
 
395
 
 
396
RFC 2865                         RADIUS                        June 2000
 
397
 
 
398
 
 
399
   came with the Access-Challenge.  The server then sends back either an
 
400
   Access-Accept or Access-Reject based on whether the response matches
 
401
   the required value, or it can even send another Access-Challenge.
 
402
 
 
403
2.2.  Interoperation with PAP and CHAP
 
404
 
 
405
   For PAP, the NAS takes the PAP ID and password and sends them in an
 
406
   Access-Request packet as the User-Name and User-Password. The NAS MAY
 
407
   include the Attributes Service-Type = Framed-User and Framed-Protocol
 
408
   = PPP as a hint to the RADIUS server that PPP service is expected.
 
409
 
 
410
   For CHAP, the NAS generates a random challenge (preferably 16 octets)
 
411
   and sends it to the user, who returns a CHAP response along with a
 
412
   CHAP ID and CHAP username.  The NAS then sends an Access-Request
 
413
   packet to the RADIUS server with the CHAP username as the User-Name
 
414
   and with the CHAP ID and CHAP response as the CHAP-Password
 
415
   (Attribute 3).  The random challenge can either be included in the
 
416
   CHAP-Challenge attribute or, if it is 16 octets long, it can be
 
417
   placed in the Request Authenticator field of the Access-Request
 
418
   packet.  The NAS MAY include the Attributes Service-Type = Framed-
 
419
   User and Framed-Protocol = PPP as a hint to the RADIUS server that
 
420
   PPP service is expected.
 
421
 
 
422
   The RADIUS server looks up a password based on the User-Name,
 
423
   encrypts the challenge using MD5 on the CHAP ID octet, that password,
 
424
   and the CHAP challenge (from the CHAP-Challenge attribute if present,
 
425
   otherwise from the Request Authenticator), and compares that result
 
426
   to the CHAP-Password.  If they match, the server sends back an
 
427
   Access-Accept, otherwise it sends back an Access-Reject.
 
428
 
 
429
   If the RADIUS server is unable to perform the requested
 
430
   authentication it MUST return an Access-Reject.  For example, CHAP
 
431
   requires that the user's password be available in cleartext to the
 
432
   server so that it can encrypt the CHAP challenge and compare that to
 
433
   the CHAP response.  If the password is not available in cleartext to
 
434
   the RADIUS server then the server MUST send an Access-Reject to the
 
435
   client.
 
436
 
 
437
2.3.  Proxy
 
438
 
 
439
   With proxy RADIUS, one RADIUS server receives an authentication (or
 
440
   accounting) request from a RADIUS client (such as a NAS), forwards
 
441
   the request to a remote RADIUS server, receives the reply from the
 
442
   remote server, and sends that reply to the client, possibly with
 
443
   changes to reflect local administrative policy.  A common use for
 
444
   proxy RADIUS is roaming.  Roaming permits two or more administrative
 
445
   entities to allow each other's users to dial in to either entity's
 
446
   network for service.
 
447
 
 
448
 
 
449
 
 
450
Rigney, et al.              Standards Track                     [Page 8]
 
451
 
 
452
RFC 2865                         RADIUS                        June 2000
 
453
 
 
454
 
 
455
   The NAS sends its RADIUS access-request to the "forwarding server"
 
456
   which forwards it to the "remote server".  The remote server sends a
 
457
   response (Access-Accept, Access-Reject, or Access-Challenge) back to
 
458
   the forwarding server, which sends it back to the NAS.  The User-Name
 
459
   attribute MAY contain a Network Access Identifier [8] for RADIUS
 
460
   Proxy operations.  The choice of which server receives the forwarded
 
461
   request SHOULD be based on the authentication "realm". The
 
462
   authentication realm MAY be the realm part of a Network Access
 
463
   Identifier (a "named realm").  Alternatively, the choice of which
 
464
   server receives the forwarded request MAY be based on whatever other
 
465
   criteria the forwarding server is configured to use, such as Called-
 
466
   Station-Id (a "numbered realm").
 
467
 
 
468
   A RADIUS server can function as both a forwarding server and a remote
 
469
   server, serving as a forwarding server for some realms and a remote
 
470
   server for other realms.  One forwarding server can act as a
 
471
   forwarder for any number of remote servers.  A remote server can have
 
472
   any number of servers forwarding to it and can provide authentication
 
473
   for any number of realms.  One forwarding server can forward to
 
474
   another forwarding server to create a chain of proxies, although care
 
475
   must be taken to avoid introducing loops.
 
476
 
 
477
   The following scenario illustrates a proxy RADIUS communication
 
478
   between a NAS and the forwarding and remote RADIUS servers:
 
479
 
 
480
   1. A NAS sends its access-request to the forwarding server.
 
481
 
 
482
   2. The forwarding server forwards the access-request to the remote
 
483
      server.
 
484
 
 
485
   3. The remote server sends an access-accept, access-reject or
 
486
      access-challenge back to the forwarding server.  For this example,
 
487
      an access-accept is sent.
 
488
 
 
489
   4. The forwarding server sends the access-accept to the NAS.
 
490
 
 
491
   The forwarding server MUST treat any Proxy-State attributes already
 
492
   in the packet as opaque data.  Its operation MUST NOT depend on the
 
493
   content of Proxy-State attributes added by previous servers.
 
494
 
 
495
   If there are any Proxy-State attributes in the request received from
 
496
   the client, the forwarding server MUST include those Proxy-State
 
497
   attributes in its reply to the client.  The forwarding server MAY
 
498
   include the Proxy-State attributes in the access-request when it
 
499
   forwards the request, or MAY omit them in the forwarded request.  If
 
500
   the forwarding server omits the Proxy-State attributes in the
 
501
   forwarded access-request, it MUST attach them to the response before
 
502
   sending it to the client.
 
503
 
 
504
 
 
505
 
 
506
Rigney, et al.              Standards Track                     [Page 9]
 
507
 
 
508
RFC 2865                         RADIUS                        June 2000
 
509
 
 
510
 
 
511
   We now examine each step in more detail.
 
512
 
 
513
   1. A NAS sends its access-request to the forwarding server.  The
 
514
      forwarding server decrypts the User-Password, if present, using
 
515
      the shared secret it knows for the NAS.  If a CHAP-Password
 
516
      attribute is present in the packet and no CHAP-Challenge attribute
 
517
      is present, the forwarding server MUST leave the Request-
 
518
      Authenticator untouched or copy it to a CHAP-Challenge attribute.
 
519
 
 
520
   '' The forwarding server MAY add one Proxy-State attribute to the
 
521
      packet.  (It MUST NOT add more than one.)  If it adds a Proxy-
 
522
      State, the Proxy-State MUST appear after any other Proxy-States in
 
523
      the packet.  The forwarding server MUST NOT modify any other
 
524
      Proxy-States that were in the packet (it may choose not to forward
 
525
      them, but it MUST NOT change their contents).  The forwarding
 
526
      server MUST NOT change the order of any attributes of the same
 
527
      type, including Proxy-State.
 
528
 
 
529
   2. The forwarding server encrypts the User-Password, if present,
 
530
      using the secret it shares with the remote server, sets the
 
531
      Identifier as needed, and forwards the access-request to the
 
532
      remote server.
 
533
 
 
534
   3. The remote server (if the final destination) verifies the user
 
535
      using User-Password, CHAP-Password, or such method as future
 
536
      extensions may dictate, and returns an access-accept, access-
 
537
      reject or access-challenge back to the forwarding server.  For
 
538
      this example, an access-accept is sent.  The remote server MUST
 
539
      copy all Proxy-State attributes (and only the Proxy-State
 
540
      attributes) in order from the access-request to the response
 
541
      packet, without modifying them.
 
542
 
 
543
   4. The forwarding server verifies the Response Authenticator using
 
544
      the secret it shares with the remote server, and silently discards
 
545
      the packet if it fails verification.  If the packet passes
 
546
      verification, the forwarding server removes the last Proxy-State
 
547
      (if it attached one), signs the Response Authenticator using the
 
548
      secret it shares with the NAS, restores the Identifier to match
 
549
      the one in the original request by the NAS, and sends the access-
 
550
      accept to the NAS.
 
551
 
 
552
   A forwarding server MAY need to modify attributes to enforce local
 
553
   policy.  Such policy is outside the scope of this document, with the
 
554
   following restrictions.  A forwarding server MUST not modify existing
 
555
   Proxy-State, State, or Class attributes present in the packet.
 
556
 
 
557
 
 
558
 
 
559
 
 
560
 
 
561
 
 
562
Rigney, et al.              Standards Track                    [Page 10]
 
563
 
 
564
RFC 2865                         RADIUS                        June 2000
 
565
 
 
566
 
 
567
   Implementers of forwarding servers should consider carefully which
 
568
   values it is willing to accept for Service-Type.  Careful
 
569
   consideration must be given to the effects of passing along Service-
 
570
   Types of NAS-Prompt or Administrative in a proxied Access-Accept, and
 
571
   implementers may wish to provide mechanisms to block those or other
 
572
   service types, or other attributes.  Such mechanisms are outside the
 
573
   scope of this document.
 
574
 
 
575
2.4.  Why UDP?
 
576
 
 
577
   A frequently asked question is why RADIUS uses UDP instead of TCP as
 
578
   a transport protocol.  UDP was chosen for strictly technical reasons.
 
579
 
 
580
   There are a number of issues which must be understood.  RADIUS is a
 
581
   transaction based protocol which has several interesting
 
582
   characteristics:
 
583
 
 
584
   1. If the request to a primary Authentication server fails, a
 
585
      secondary server must be queried.
 
586
 
 
587
      To meet this requirement, a copy of the request must be kept above
 
588
      the transport layer to allow for alternate transmission.  This
 
589
      means that retransmission timers are still required.
 
590
 
 
591
   2. The timing requirements of this particular protocol are
 
592
      significantly different than TCP provides.
 
593
 
 
594
      At one extreme, RADIUS does not require a "responsive" detection
 
595
      of lost data.  The user is willing to wait several seconds for the
 
596
      authentication to complete.  The generally aggressive TCP
 
597
      retransmission (based on average round trip time) is not required,
 
598
      nor is the acknowledgement overhead of TCP.
 
599
 
 
600
      At the other extreme, the user is not willing to wait several
 
601
      minutes for authentication.  Therefore the reliable delivery of
 
602
      TCP data two minutes later is not useful.  The faster use of an
 
603
      alternate server allows the user to gain access before giving up.
 
604
 
 
605
   3. The stateless nature of this protocol simplifies the use of UDP.
 
606
 
 
607
      Clients and servers come and go.  Systems are rebooted, or are
 
608
      power cycled independently.  Generally this does not cause a
 
609
      problem and with creative timeouts and detection of lost TCP
 
610
      connections, code can be written to handle anomalous events.  UDP
 
611
      however completely eliminates any of this special handling.  Each
 
612
      client and server can open their UDP transport just once and leave
 
613
      it open through all types of failure events on the network.
 
614
 
 
615
 
 
616
 
 
617
 
 
618
Rigney, et al.              Standards Track                    [Page 11]
 
619
 
 
620
RFC 2865                         RADIUS                        June 2000
 
621
 
 
622
 
 
623
   4. UDP simplifies the server implementation.
 
624
 
 
625
      In the earliest implementations of RADIUS, the server was single
 
626
      threaded.  This means that a single request was received,
 
627
      processed, and returned.  This was found to be unmanageable in
 
628
      environments where the back-end security mechanism took real time
 
629
      (1 or more seconds).  The server request queue would fill and in
 
630
      environments where hundreds of people were being authenticated
 
631
      every minute, the request turn-around time increased to longer
 
632
      than users were willing to wait (this was especially severe when a
 
633
      specific lookup in a database or over DNS took 30 or more
 
634
      seconds).  The obvious solution was to make the server multi-
 
635
      threaded.  Achieving this was simple with UDP.  Separate processes
 
636
      were spawned to serve each request and these processes could
 
637
      respond directly to the client NAS with a simple UDP packet to the
 
638
      original transport of the client.
 
639
 
 
640
   It's not all a panacea.  As noted, using UDP requires one thing which
 
641
   is built into TCP: with UDP we must artificially manage
 
642
   retransmission timers to the same server, although they don't require
 
643
   the same attention to timing provided by TCP.  This one penalty is a
 
644
   small price to pay for the advantages of UDP in this protocol.
 
645
 
 
646
   Without TCP we would still probably be using tin cans connected by
 
647
   string.  But for this particular protocol, UDP is a better choice.
 
648
 
 
649
2.5.  Retransmission Hints
 
650
 
 
651
   If the RADIUS server and alternate RADIUS server share the same
 
652
   shared secret, it is OK to retransmit the packet to the alternate
 
653
   RADIUS server with the same ID and Request Authenticator, because the
 
654
   content of the attributes haven't changed.  If you want to use a new
 
655
   Request Authenticator when sending to the alternate server, you may.
 
656
 
 
657
   If you change the contents of the User-Password attribute (or any
 
658
   other attribute), you need a new Request Authenticator and therefore
 
659
   a new ID.
 
660
 
 
661
   If the NAS is retransmitting a RADIUS request to the same server as
 
662
   before, and the attributes haven't changed, you MUST use the same
 
663
   Request Authenticator, ID, and source port.  If any attributes have
 
664
   changed, you MUST use a new Request Authenticator and ID.
 
665
 
 
666
   A NAS MAY use the same ID across all servers, or MAY keep track of
 
667
   IDs separately for each server, it is up to the implementer.  If a
 
668
   NAS needs more than 256 IDs for outstanding requests, it MAY use
 
669
 
 
670
 
 
671
 
 
672
 
 
673
 
 
674
Rigney, et al.              Standards Track                    [Page 12]
 
675
 
 
676
RFC 2865                         RADIUS                        June 2000
 
677
 
 
678
 
 
679
   additional source ports to send requests from, and keep track of IDs
 
680
   for each source port.  This allows up to 16 million or so outstanding
 
681
   requests at one time to a single server.
 
682
 
 
683
2.6.  Keep-Alives Considered Harmful
 
684
 
 
685
   Some implementers have adopted the practice of sending test RADIUS
 
686
   requests to see if a server is alive.  This practice is strongly
 
687
   discouraged, since it adds to load and harms scalability without
 
688
   providing any additional useful information.  Since a RADIUS request
 
689
   is contained in a single datagram, in the time it would take you to
 
690
   send a ping you could just send the RADIUS request, and getting a
 
691
   reply tells you that the RADIUS server is up.  If you do not have a
 
692
   RADIUS request to send, it does not matter if the server is up or
 
693
   not, because you are not using it.
 
694
 
 
695
   If you want to monitor your RADIUS server, use SNMP.  That's what
 
696
   SNMP is for.
 
697
 
 
698
3.  Packet Format
 
699
 
 
700
   Exactly one RADIUS packet is encapsulated in the UDP Data field [4],
 
701
   where the UDP Destination Port field indicates 1812 (decimal).
 
702
 
 
703
   When a reply is generated, the source and destination ports are
 
704
   reversed.
 
705
 
 
706
   This memo documents the RADIUS protocol.  The early deployment of
 
707
   RADIUS was done using UDP port number 1645, which conflicts with the
 
708
   "datametrics" service.  The officially assigned port number for
 
709
   RADIUS is 1812.
 
710
 
 
711
 
 
712
 
 
713
 
 
714
 
 
715
 
 
716
 
 
717
 
 
718
 
 
719
 
 
720
 
 
721
 
 
722
 
 
723
 
 
724
 
 
725
 
 
726
 
 
727
 
 
728
 
 
729
 
 
730
Rigney, et al.              Standards Track                    [Page 13]
 
731
 
 
732
RFC 2865                         RADIUS                        June 2000
 
733
 
 
734
 
 
735
   A summary of the RADIUS data format is shown below.  The fields are
 
736
   transmitted from left to right.
 
737
 
 
738
    0                   1                   2                   3
 
739
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
740
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
741
   |     Code      |  Identifier   |            Length             |
 
742
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
743
   |                                                               |
 
744
   |                         Authenticator                         |
 
745
   |                                                               |
 
746
   |                                                               |
 
747
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
748
   |  Attributes ...
 
749
   +-+-+-+-+-+-+-+-+-+-+-+-+-
 
750
 
 
751
   Code
 
752
 
 
753
      The Code field is one octet, and identifies the type of RADIUS
 
754
      packet.  When a packet is received with an invalid Code field, it
 
755
      is silently discarded.
 
756
 
 
757
      RADIUS Codes (decimal) are assigned as follows:
 
758
 
 
759
        1       Access-Request
 
760
        2       Access-Accept
 
761
        3       Access-Reject
 
762
        4       Accounting-Request
 
763
        5       Accounting-Response
 
764
       11       Access-Challenge
 
765
       12       Status-Server (experimental)
 
766
       13       Status-Client (experimental)
 
767
      255       Reserved
 
768
 
 
769
   Codes 4 and 5 are covered in the RADIUS Accounting document [5].
 
770
   Codes 12 and 13 are reserved for possible use, but are not further
 
771
   mentioned here.
 
772
 
 
773
   Identifier
 
774
 
 
775
      The Identifier field is one octet, and aids in matching requests
 
776
      and replies.  The RADIUS server can detect a duplicate request if
 
777
      it has the same client source IP address and source UDP port and
 
778
      Identifier within a short span of time.
 
779
 
 
780
 
 
781
 
 
782
 
 
783
 
 
784
 
 
785
 
 
786
Rigney, et al.              Standards Track                    [Page 14]
 
787
 
 
788
RFC 2865                         RADIUS                        June 2000
 
789
 
 
790
 
 
791
   Length
 
792
 
 
793
      The Length field is two octets.  It indicates the length of the
 
794
      packet including the Code, Identifier, Length, Authenticator and
 
795
      Attribute fields.  Octets outside the range of the Length field
 
796
      MUST be treated as padding and ignored on reception.  If the
 
797
      packet is shorter than the Length field indicates, it MUST be
 
798
      silently discarded.  The minimum length is 20 and maximum length
 
799
      is 4096.
 
800
 
 
801
   Authenticator
 
802
 
 
803
      The Authenticator field is sixteen (16) octets.  The most
 
804
      significant octet is transmitted first.  This value is used to
 
805
      authenticate the reply from the RADIUS server, and is used in the
 
806
      password hiding algorithm.
 
807
 
 
808
      Request Authenticator
 
809
 
 
810
         In Access-Request Packets, the Authenticator value is a 16
 
811
         octet random number, called the Request Authenticator.  The
 
812
         value SHOULD be unpredictable and unique over the lifetime of a
 
813
         secret (the password shared between the client and the RADIUS
 
814
         server), since repetition of a request value in conjunction
 
815
         with the same secret would permit an attacker to reply with a
 
816
         previously intercepted response.  Since it is expected that the
 
817
         same secret MAY be used to authenticate with servers in
 
818
         disparate geographic regions, the Request Authenticator field
 
819
         SHOULD exhibit global and temporal uniqueness.
 
820
 
 
821
         The Request Authenticator value in an Access-Request packet
 
822
         SHOULD also be unpredictable, lest an attacker trick a server
 
823
         into responding to a predicted future request, and then use the
 
824
         response to masquerade as that server to a future Access-
 
825
         Request.
 
826
 
 
827
         Although protocols such as RADIUS are incapable of protecting
 
828
         against theft of an authenticated session via realtime active
 
829
         wiretapping attacks, generation of unique unpredictable
 
830
         requests can protect against a wide range of active attacks
 
831
         against authentication.
 
832
 
 
833
         The NAS and RADIUS server share a secret.  That shared secret
 
834
         followed by the Request Authenticator is put through a one-way
 
835
         MD5 hash to create a 16 octet digest value which is xored with
 
836
         the password entered by the user, and the xored result placed
 
837
 
 
838
 
 
839
 
 
840
 
 
841
 
 
842
Rigney, et al.              Standards Track                    [Page 15]
 
843
 
 
844
RFC 2865                         RADIUS                        June 2000
 
845
 
 
846
 
 
847
         in the User-Password attribute in the Access-Request packet.
 
848
         See the entry for User-Password in the section on Attributes
 
849
         for a more detailed description.
 
850
 
 
851
      Response Authenticator
 
852
 
 
853
         The value of the Authenticator field in Access-Accept, Access-
 
854
         Reject, and Access-Challenge packets is called the Response
 
855
         Authenticator, and contains a one-way MD5 hash calculated over
 
856
         a stream of octets consisting of: the RADIUS packet, beginning
 
857
         with the Code field, including the Identifier, the Length, the
 
858
         Request Authenticator field from the Access-Request packet, and
 
859
         the response Attributes, followed by the shared secret.  That
 
860
         is, ResponseAuth =
 
861
         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
 
862
         denotes concatenation.
 
863
 
 
864
   Administrative Note
 
865
 
 
866
      The secret (password shared between the client and the RADIUS
 
867
      server) SHOULD be at least as large and unguessable as a well-
 
868
      chosen password.  It is preferred that the secret be at least 16
 
869
      octets.  This is to ensure a sufficiently large range for the
 
870
      secret to provide protection against exhaustive search attacks.
 
871
      The secret MUST NOT be empty (length 0) since this would allow
 
872
      packets to be trivially forged.
 
873
 
 
874
      A RADIUS server MUST use the source IP address of the RADIUS UDP
 
875
      packet to decide which shared secret to use, so that RADIUS
 
876
      requests can be proxied.
 
877
 
 
878
      When using a forwarding proxy, the proxy must be able to alter the
 
879
      packet as it passes through in each direction - when the proxy
 
880
      forwards the request, the proxy MAY add a Proxy-State Attribute,
 
881
      and when the proxy forwards a response, it MUST remove its Proxy-
 
882
      State Attribute if it added one.  Proxy-State is always added or
 
883
      removed after any other Proxy-States, but no other assumptions
 
884
      regarding its location within the list of attributes can be made.
 
885
      Since Access-Accept and Access-Reject replies are authenticated on
 
886
      the entire packet contents, the stripping of the Proxy-State
 
887
      attribute invalidates the signature in the packet - so the proxy
 
888
      has to re-sign it.
 
889
 
 
890
      Further details of RADIUS proxy implementation are outside the
 
891
      scope of this document.
 
892
 
 
893
 
 
894
 
 
895
 
 
896
 
 
897
 
 
898
Rigney, et al.              Standards Track                    [Page 16]
 
899
 
 
900
RFC 2865                         RADIUS                        June 2000
 
901
 
 
902
 
 
903
4.  Packet Types
 
904
 
 
905
   The RADIUS Packet type is determined by the Code field in the first
 
906
   octet of the Packet.
 
907
 
 
908
4.1.  Access-Request
 
909
 
 
910
   Description
 
911
 
 
912
      Access-Request packets are sent to a RADIUS server, and convey
 
913
      information used to determine whether a user is allowed access to
 
914
      a specific NAS, and any special services requested for that user.
 
915
      An implementation wishing to authenticate a user MUST transmit a
 
916
      RADIUS packet with the Code field set to 1 (Access-Request).
 
917
 
 
918
      Upon receipt of an Access-Request from a valid client, an
 
919
      appropriate reply MUST be transmitted.
 
920
 
 
921
      An Access-Request SHOULD contain a User-Name attribute.  It MUST
 
922
      contain either a NAS-IP-Address attribute or a NAS-Identifier
 
923
      attribute (or both).
 
924
 
 
925
      An Access-Request MUST contain either a User-Password or a CHAP-
 
926
      Password or a State.  An Access-Request MUST NOT contain both a
 
927
      User-Password and a CHAP-Password.  If future extensions allow
 
928
      other kinds of authentication information to be conveyed, the
 
929
      attribute for that can be used in an Access-Request instead of
 
930
      User-Password or CHAP-Password.
 
931
 
 
932
      An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
 
933
      attribute or both unless the type of access being requested does
 
934
      not involve a port or the NAS does not distinguish among its
 
935
      ports.
 
936
 
 
937
      An Access-Request MAY contain additional attributes as a hint to
 
938
      the server, but the server is not required to honor the hint.
 
939
 
 
940
      When a User-Password is present, it is hidden using a method based
 
941
      on the RSA Message Digest Algorithm MD5 [3].
 
942
 
 
943
 
 
944
 
 
945
 
 
946
 
 
947
 
 
948
 
 
949
 
 
950
 
 
951
 
 
952
 
 
953
 
 
954
Rigney, et al.              Standards Track                    [Page 17]
 
955
 
 
956
RFC 2865                         RADIUS                        June 2000
 
957
 
 
958
 
 
959
   A summary of the Access-Request packet format is shown below.  The
 
960
   fields are transmitted from left to right.
 
961
 
 
962
    0                   1                   2                   3
 
963
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
964
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
965
   |     Code      |  Identifier   |            Length             |
 
966
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
967
   |                                                               |
 
968
   |                     Request Authenticator                     |
 
969
   |                                                               |
 
970
   |                                                               |
 
971
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
972
   |  Attributes ...
 
973
   +-+-+-+-+-+-+-+-+-+-+-+-+-
 
974
 
 
975
   Code
 
976
 
 
977
      1 for Access-Request.
 
978
 
 
979
   Identifier
 
980
 
 
981
      The Identifier field MUST be changed whenever the content of the
 
982
      Attributes field changes, and whenever a valid reply has been
 
983
      received for a previous request.  For retransmissions, the
 
984
      Identifier MUST remain unchanged.
 
985
 
 
986
   Request Authenticator
 
987
 
 
988
      The Request Authenticator value MUST be changed each time a new
 
989
      Identifier is used.
 
990
 
 
991
   Attributes
 
992
 
 
993
      The Attribute field is variable in length, and contains the list
 
994
      of Attributes that are required for the type of service, as well
 
995
      as any desired optional Attributes.
 
996
 
 
997
4.2.  Access-Accept
 
998
 
 
999
   Description
 
1000
 
 
1001
      Access-Accept packets are sent by the RADIUS server, and provide
 
1002
      specific configuration information necessary to begin delivery of
 
1003
      service to the user.  If all Attribute values received in an
 
1004
      Access-Request are acceptable then the RADIUS implementation MUST
 
1005
      transmit a packet with the Code field set to 2 (Access-Accept).
 
1006
 
 
1007
 
 
1008
 
 
1009
 
 
1010
Rigney, et al.              Standards Track                    [Page 18]
 
1011
 
 
1012
RFC 2865                         RADIUS                        June 2000
 
1013
 
 
1014
 
 
1015
      On reception of an Access-Accept, the Identifier field is matched
 
1016
      with a pending Access-Request.  The Response Authenticator field
 
1017
      MUST contain the correct response for the pending Access-Request.
 
1018
      Invalid packets are silently discarded.
 
1019
 
 
1020
   A summary of the Access-Accept packet format is shown below.  The
 
1021
   fields are transmitted from left to right.
 
1022
 
 
1023
    0                   1                   2                   3
 
1024
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1025
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1026
   |     Code      |  Identifier   |            Length             |
 
1027
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1028
   |                                                               |
 
1029
   |                     Response Authenticator                    |
 
1030
   |                                                               |
 
1031
   |                                                               |
 
1032
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1033
   |  Attributes ...
 
1034
   +-+-+-+-+-+-+-+-+-+-+-+-+-
 
1035
 
 
1036
   Code
 
1037
 
 
1038
      2 for Access-Accept.
 
1039
 
 
1040
   Identifier
 
1041
 
 
1042
      The Identifier field is a copy of the Identifier field of the
 
1043
      Access-Request which caused this Access-Accept.
 
1044
 
 
1045
   Response Authenticator
 
1046
 
 
1047
      The Response Authenticator value is calculated from the Access-
 
1048
      Request value, as described earlier.
 
1049
 
 
1050
   Attributes
 
1051
 
 
1052
      The Attribute field is variable in length, and contains a list of
 
1053
      zero or more Attributes.
 
1054
 
 
1055
 
 
1056
 
 
1057
 
 
1058
 
 
1059
 
 
1060
 
 
1061
 
 
1062
 
 
1063
 
 
1064
 
 
1065
 
 
1066
Rigney, et al.              Standards Track                    [Page 19]
 
1067
 
 
1068
RFC 2865                         RADIUS                        June 2000
 
1069
 
 
1070
 
 
1071
4.3.  Access-Reject
 
1072
 
 
1073
   Description
 
1074
 
 
1075
      If any value of the received Attributes is not acceptable, then
 
1076
      the RADIUS server MUST transmit a packet with the Code field set
 
1077
      to 3 (Access-Reject).  It MAY include one or more Reply-Message
 
1078
      Attributes with a text message which the NAS MAY display to the
 
1079
      user.
 
1080
 
 
1081
   A summary of the Access-Reject packet format is shown below.  The
 
1082
   fields are transmitted from left to right.
 
1083
 
 
1084
    0                   1                   2                   3
 
1085
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1086
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1087
   |     Code      |  Identifier   |            Length             |
 
1088
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1089
   |                                                               |
 
1090
   |                     Response Authenticator                    |
 
1091
   |                                                               |
 
1092
   |                                                               |
 
1093
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1094
   |  Attributes ...
 
1095
   +-+-+-+-+-+-+-+-+-+-+-+-+-
 
1096
 
 
1097
   Code
 
1098
 
 
1099
      3 for Access-Reject.
 
1100
 
 
1101
   Identifier
 
1102
 
 
1103
      The Identifier field is a copy of the Identifier field of the
 
1104
      Access-Request which caused this Access-Reject.
 
1105
 
 
1106
   Response Authenticator
 
1107
 
 
1108
      The Response Authenticator value is calculated from the Access-
 
1109
      Request value, as described earlier.
 
1110
 
 
1111
   Attributes
 
1112
 
 
1113
      The Attribute field is variable in length, and contains a list of
 
1114
      zero or more Attributes.
 
1115
 
 
1116
 
 
1117
 
 
1118
 
 
1119
 
 
1120
 
 
1121
 
 
1122
Rigney, et al.              Standards Track                    [Page 20]
 
1123
 
 
1124
RFC 2865                         RADIUS                        June 2000
 
1125
 
 
1126
 
 
1127
4.4.  Access-Challenge
 
1128
 
 
1129
   Description
 
1130
 
 
1131
      If the RADIUS server desires to send the user a challenge
 
1132
      requiring a response, then the RADIUS server MUST respond to the
 
1133
      Access-Request by transmitting a packet with the Code field set to
 
1134
      11 (Access-Challenge).
 
1135
 
 
1136
      The Attributes field MAY have one or more Reply-Message
 
1137
      Attributes, and MAY have a single State Attribute, or none.
 
1138
      Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State
 
1139
      attributes MAY also be included.  No other Attributes defined in
 
1140
      this document are permitted in an Access-Challenge.
 
1141
 
 
1142
      On receipt of an Access-Challenge, the Identifier field is matched
 
1143
      with a pending Access-Request.  Additionally, the Response
 
1144
      Authenticator field MUST contain the correct response for the
 
1145
      pending Access-Request.  Invalid packets are silently discarded.
 
1146
 
 
1147
      If the NAS does not support challenge/response, it MUST treat an
 
1148
      Access-Challenge as though it had received an Access-Reject
 
1149
      instead.
 
1150
 
 
1151
      If the NAS supports challenge/response, receipt of a valid
 
1152
      Access-Challenge indicates that a new Access-Request SHOULD be
 
1153
      sent.  The NAS MAY display the text message, if any, to the user,
 
1154
      and then prompt the user for a response.  It then sends its
 
1155
      original Access-Request with a new request ID and Request
 
1156
      Authenticator, with the User-Password Attribute replaced by the
 
1157
      user's response (encrypted), and including the State Attribute
 
1158
      from the Access-Challenge, if any.  Only 0 or 1 instances of the
 
1159
      State Attribute can be present in an Access-Request.
 
1160
 
 
1161
      A NAS which supports PAP MAY forward the Reply-Message to the
 
1162
      dialing client and accept a PAP response which it can use as
 
1163
      though the user had entered the response.  If the NAS cannot do
 
1164
      so, it MUST treat the Access-Challenge as though it had received
 
1165
      an Access-Reject instead.
 
1166
 
 
1167
 
 
1168
 
 
1169
 
 
1170
 
 
1171
 
 
1172
 
 
1173
 
 
1174
 
 
1175
 
 
1176
 
 
1177
 
 
1178
Rigney, et al.              Standards Track                    [Page 21]
 
1179
 
 
1180
RFC 2865                         RADIUS                        June 2000
 
1181
 
 
1182
 
 
1183
   A summary of the Access-Challenge packet format is shown below.  The
 
1184
   fields are transmitted from left to right.
 
1185
 
 
1186
    0                   1                   2                   3
 
1187
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1188
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1189
   |     Code      |  Identifier   |            Length             |
 
1190
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1191
   |                                                               |
 
1192
   |                     Response Authenticator                    |
 
1193
   |                                                               |
 
1194
   |                                                               |
 
1195
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1196
   |  Attributes ...
 
1197
   +-+-+-+-+-+-+-+-+-+-+-+-+-
 
1198
 
 
1199
   Code
 
1200
 
 
1201
      11 for Access-Challenge.
 
1202
 
 
1203
   Identifier
 
1204
 
 
1205
      The Identifier field is a copy of the Identifier field of the
 
1206
      Access-Request which caused this Access-Challenge.
 
1207
 
 
1208
   Response Authenticator
 
1209
 
 
1210
      The Response Authenticator value is calculated from the Access-
 
1211
      Request value, as described earlier.
 
1212
 
 
1213
   Attributes
 
1214
 
 
1215
      The Attributes field is variable in length, and contains a list of
 
1216
      zero or more Attributes.
 
1217
 
 
1218
5.  Attributes
 
1219
 
 
1220
   RADIUS Attributes carry the specific authentication, authorization,
 
1221
   information and configuration details for the request and reply.
 
1222
 
 
1223
   The end of the list of Attributes is indicated by the Length of the
 
1224
   RADIUS packet.
 
1225
 
 
1226
   Some Attributes MAY be included more than once.  The effect of this
 
1227
   is Attribute specific, and is specified in each Attribute
 
1228
   description.  A summary table is provided at the end of the
 
1229
   "Attributes" section.
 
1230
 
 
1231
 
 
1232
 
 
1233
 
 
1234
Rigney, et al.              Standards Track                    [Page 22]
 
1235
 
 
1236
RFC 2865                         RADIUS                        June 2000
 
1237
 
 
1238
 
 
1239
   If multiple Attributes with the same Type are present, the order of
 
1240
   Attributes with the same Type MUST be preserved by any proxies.  The
 
1241
   order of Attributes of different Types is not required to be
 
1242
   preserved.  A RADIUS server or client MUST NOT have any dependencies
 
1243
   on the order of attributes of different types.  A RADIUS server or
 
1244
   client MUST NOT require attributes of the same type to be contiguous.
 
1245
 
 
1246
   Where an Attribute's description limits which kinds of packet it can
 
1247
   be contained in, this applies only to the packet types defined in
 
1248
   this document, namely Access-Request, Access-Accept, Access-Reject
 
1249
   and Access-Challenge (Codes 1, 2, 3, and 11).  Other documents
 
1250
   defining other packet types may also use Attributes described here.
 
1251
   To determine which Attributes are allowed in Accounting-Request and
 
1252
   Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
 
1253
   Accounting document [5].
 
1254
 
 
1255
   Likewise where packet types defined here state that only certain
 
1256
   Attributes are permissible in them, future memos defining new
 
1257
   Attributes should indicate which packet types the new Attributes may
 
1258
   be present in.
 
1259
 
 
1260
   A summary of the Attribute format is shown below.  The fields are
 
1261
   transmitted from left to right.
 
1262
 
 
1263
    0                   1                   2
 
1264
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
 
1265
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1266
   |     Type      |    Length     |  Value ...
 
1267
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1268
 
 
1269
   Type
 
1270
 
 
1271
      The Type field is one octet.  Up-to-date values of the RADIUS Type
 
1272
      field are specified in the most recent "Assigned Numbers" RFC [6].
 
1273
      Values 192-223 are reserved for experimental use, values 224-240
 
1274
      are reserved for implementation-specific use, and values 241-255
 
1275
      are reserved and should not be used.
 
1276
 
 
1277
      A RADIUS server MAY ignore Attributes with an unknown Type.
 
1278
 
 
1279
      A RADIUS client MAY ignore Attributes with an unknown Type.
 
1280
 
 
1281
 
 
1282
 
 
1283
 
 
1284
 
 
1285
 
 
1286
 
 
1287
 
 
1288
 
 
1289
 
 
1290
Rigney, et al.              Standards Track                    [Page 23]
 
1291
 
 
1292
RFC 2865                         RADIUS                        June 2000
 
1293
 
 
1294
 
 
1295
      This specification concerns the following values:
 
1296
 
 
1297
          1      User-Name
 
1298
          2      User-Password
 
1299
          3      CHAP-Password
 
1300
          4      NAS-IP-Address
 
1301
          5      NAS-Port
 
1302
          6      Service-Type
 
1303
          7      Framed-Protocol
 
1304
          8      Framed-IP-Address
 
1305
          9      Framed-IP-Netmask
 
1306
         10      Framed-Routing
 
1307
         11      Filter-Id
 
1308
         12      Framed-MTU
 
1309
         13      Framed-Compression
 
1310
         14      Login-IP-Host
 
1311
         15      Login-Service
 
1312
         16      Login-TCP-Port
 
1313
         17      (unassigned)
 
1314
         18      Reply-Message
 
1315
         19      Callback-Number
 
1316
         20      Callback-Id
 
1317
         21      (unassigned)
 
1318
         22      Framed-Route
 
1319
         23      Framed-IPX-Network
 
1320
         24      State
 
1321
         25      Class
 
1322
         26      Vendor-Specific
 
1323
         27      Session-Timeout
 
1324
         28      Idle-Timeout
 
1325
         29      Termination-Action
 
1326
         30      Called-Station-Id
 
1327
         31      Calling-Station-Id
 
1328
         32      NAS-Identifier
 
1329
         33      Proxy-State
 
1330
         34      Login-LAT-Service
 
1331
         35      Login-LAT-Node
 
1332
         36      Login-LAT-Group
 
1333
         37      Framed-AppleTalk-Link
 
1334
         38      Framed-AppleTalk-Network
 
1335
         39      Framed-AppleTalk-Zone
 
1336
         40-59   (reserved for accounting)
 
1337
         60      CHAP-Challenge
 
1338
         61      NAS-Port-Type
 
1339
         62      Port-Limit
 
1340
         63      Login-LAT-Port
 
1341
 
 
1342
 
 
1343
 
 
1344
 
 
1345
 
 
1346
Rigney, et al.              Standards Track                    [Page 24]
 
1347
 
 
1348
RFC 2865                         RADIUS                        June 2000
 
1349
 
 
1350
 
 
1351
   Length
 
1352
 
 
1353
      The Length field is one octet, and indicates the length of this
 
1354
      Attribute including the Type, Length and Value fields.  If an
 
1355
      Attribute is received in an Access-Request but with an invalid
 
1356
      Length, an Access-Reject SHOULD be transmitted.  If an Attribute
 
1357
      is received in an Access-Accept, Access-Reject or Access-Challenge
 
1358
      packet with an invalid length, the packet MUST either be treated
 
1359
      as an Access-Reject or else silently discarded.
 
1360
 
 
1361
   Value
 
1362
 
 
1363
      The Value field is zero or more octets and contains information
 
1364
      specific to the Attribute.  The format and length of the Value
 
1365
      field is determined by the Type and Length fields.
 
1366
 
 
1367
      Note that none of the types in RADIUS terminate with a NUL (hex
 
1368
      00).  In particular, types "text" and "string" in RADIUS do not
 
1369
      terminate with a NUL (hex 00).  The Attribute has a length field
 
1370
      and does not use a terminator.  Text contains UTF-8 encoded 10646
 
1371
      [7] characters and String contains 8-bit binary data.  Servers and
 
1372
      servers and clients MUST be able to deal with embedded nulls.
 
1373
      RADIUS implementers using C are cautioned not to use strcpy() when
 
1374
      handling strings.
 
1375
 
 
1376
      The format of the value field is one of five data types.  Note
 
1377
      that type "text" is a subset of type "string".
 
1378
 
 
1379
      text      1-253 octets containing UTF-8 encoded 10646 [7]
 
1380
                characters.  Text of length zero (0) MUST NOT be sent;
 
1381
                omit the entire attribute instead.
 
1382
 
 
1383
      string    1-253 octets containing binary data (values 0 through
 
1384
                255 decimal, inclusive).  Strings of length zero (0)
 
1385
                MUST NOT be sent; omit the entire attribute instead.
 
1386
 
 
1387
      address   32 bit value, most significant octet first.
 
1388
 
 
1389
      integer   32 bit unsigned value, most significant octet first.
 
1390
 
 
1391
      time      32 bit unsigned value, most significant octet first --
 
1392
                seconds since 00:00:00 UTC, January 1, 1970.  The
 
1393
                standard Attributes do not use this data type but it is
 
1394
                presented here for possible use in future attributes.
 
1395
 
 
1396
 
 
1397
 
 
1398
 
 
1399
 
 
1400
 
 
1401
 
 
1402
Rigney, et al.              Standards Track                    [Page 25]
 
1403
 
 
1404
RFC 2865                         RADIUS                        June 2000
 
1405
 
 
1406
 
 
1407
5.1.  User-Name
 
1408
 
 
1409
   Description
 
1410
 
 
1411
      This Attribute indicates the name of the user to be authenticated.
 
1412
      It MUST be sent in Access-Request packets if available.
 
1413
 
 
1414
      It MAY be sent in an Access-Accept packet, in which case the
 
1415
      client SHOULD use the name returned in the Access-Accept packet in
 
1416
      all Accounting-Request packets for this session.  If the Access-
 
1417
      Accept includes Service-Type = Rlogin and the User-Name attribute,
 
1418
      a NAS MAY use the returned User-Name when performing the Rlogin
 
1419
      function.
 
1420
 
 
1421
   A summary of the User-Name Attribute format is shown below.  The
 
1422
   fields are transmitted from left to right.
 
1423
 
 
1424
    0                   1                   2
 
1425
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1426
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1427
   |     Type      |    Length     |  String ...
 
1428
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1429
 
 
1430
   Type
 
1431
 
 
1432
      1 for User-Name.
 
1433
 
 
1434
   Length
 
1435
 
 
1436
      >= 3
 
1437
 
 
1438
   String
 
1439
 
 
1440
      The String field is one or more octets.  The NAS may limit the
 
1441
      maximum length of the User-Name but the ability to handle at least
 
1442
      63 octets is recommended.
 
1443
 
 
1444
      The format of the username MAY be one of several forms:
 
1445
 
 
1446
      text      Consisting only of UTF-8 encoded 10646 [7] characters.
 
1447
 
 
1448
      network access identifier
 
1449
                A Network Access Identifier as described in RFC 2486
 
1450
                [8].
 
1451
 
 
1452
      distinguished name
 
1453
                A name in ASN.1 form used in Public Key authentication
 
1454
                systems.
 
1455
 
 
1456
 
 
1457
 
 
1458
Rigney, et al.              Standards Track                    [Page 26]
 
1459
 
 
1460
RFC 2865                         RADIUS                        June 2000
 
1461
 
 
1462
 
 
1463
5.2.  User-Password
 
1464
 
 
1465
   Description
 
1466
 
 
1467
      This Attribute indicates the password of the user to be
 
1468
      authenticated, or the user's input following an Access-Challenge.
 
1469
      It is only used in Access-Request packets.
 
1470
 
 
1471
      On transmission, the password is hidden.  The password is first
 
1472
      padded at the end with nulls to a multiple of 16 octets.  A one-
 
1473
      way MD5 hash is calculated over a stream of octets consisting of
 
1474
      the shared secret followed by the Request Authenticator.  This
 
1475
      value is XORed with the first 16 octet segment of the password and
 
1476
      placed in the first 16 octets of the String field of the User-
 
1477
      Password Attribute.
 
1478
 
 
1479
      If the password is longer than 16 characters, a second one-way MD5
 
1480
      hash is calculated over a stream of octets consisting of the
 
1481
      shared secret followed by the result of the first xor.  That hash
 
1482
      is XORed with the second 16 octet segment of the password and
 
1483
      placed in the second 16 octets of the String field of the User-
 
1484
      Password Attribute.
 
1485
 
 
1486
      If necessary, this operation is repeated, with each xor result
 
1487
      being used along with the shared secret to generate the next hash
 
1488
      to xor the next segment of the password, to no more than 128
 
1489
      characters.
 
1490
 
 
1491
      The method is taken from the book "Network Security" by Kaufman,
 
1492
      Perlman and Speciner [9] pages 109-110.  A more precise
 
1493
      explanation of the method follows:
 
1494
 
 
1495
      Call the shared secret S and the pseudo-random 128-bit Request
 
1496
      Authenticator RA.  Break the password into 16-octet chunks p1, p2,
 
1497
      etc.  with the last one padded at the end with nulls to a 16-octet
 
1498
      boundary.  Call the ciphertext blocks c(1), c(2), etc.  We'll need
 
1499
      intermediate values b1, b2, etc.
 
1500
 
 
1501
         b1 = MD5(S + RA)       c(1) = p1 xor b1
 
1502
         b2 = MD5(S + c(1))     c(2) = p2 xor b2
 
1503
                .                       .
 
1504
                .                       .
 
1505
                .                       .
 
1506
         bi = MD5(S + c(i-1))   c(i) = pi xor bi
 
1507
 
 
1508
      The String will contain c(1)+c(2)+...+c(i) where + denotes
 
1509
      concatenation.
 
1510
 
 
1511
 
 
1512
 
 
1513
 
 
1514
Rigney, et al.              Standards Track                    [Page 27]
 
1515
 
 
1516
RFC 2865                         RADIUS                        June 2000
 
1517
 
 
1518
 
 
1519
      On receipt, the process is reversed to yield the original
 
1520
      password.
 
1521
 
 
1522
   A summary of the User-Password Attribute format is shown below.  The
 
1523
   fields are transmitted from left to right.
 
1524
 
 
1525
    0                   1                   2
 
1526
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1527
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1528
   |     Type      |    Length     |  String ...
 
1529
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1530
 
 
1531
   Type
 
1532
 
 
1533
      2 for User-Password.
 
1534
 
 
1535
   Length
 
1536
 
 
1537
      At least 18 and no larger than 130.
 
1538
 
 
1539
   String
 
1540
 
 
1541
      The String field is between 16 and 128 octets long, inclusive.
 
1542
 
 
1543
5.3.  CHAP-Password
 
1544
 
 
1545
   Description
 
1546
 
 
1547
      This Attribute indicates the response value provided by a PPP
 
1548
      Challenge-Handshake Authentication Protocol (CHAP) user in
 
1549
      response to the challenge.  It is only used in Access-Request
 
1550
      packets.
 
1551
 
 
1552
      The CHAP challenge value is found in the CHAP-Challenge Attribute
 
1553
      (60) if present in the packet, otherwise in the Request
 
1554
      Authenticator field.
 
1555
 
 
1556
   A summary of the CHAP-Password Attribute format is shown below.  The
 
1557
   fields are transmitted from left to right.
 
1558
 
 
1559
    0                   1                   2
 
1560
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
 
1561
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1562
   |     Type      |    Length     |  CHAP Ident   |  String ...
 
1563
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1564
 
 
1565
 
 
1566
 
 
1567
 
 
1568
 
 
1569
 
 
1570
Rigney, et al.              Standards Track                    [Page 28]
 
1571
 
 
1572
RFC 2865                         RADIUS                        June 2000
 
1573
 
 
1574
 
 
1575
   Type
 
1576
 
 
1577
      3 for CHAP-Password.
 
1578
 
 
1579
   Length
 
1580
 
 
1581
      19
 
1582
 
 
1583
   CHAP Ident
 
1584
 
 
1585
      This field is one octet, and contains the CHAP Identifier from the
 
1586
      user's CHAP Response.
 
1587
 
 
1588
   String
 
1589
 
 
1590
      The String field is 16 octets, and contains the CHAP Response from
 
1591
      the user.
 
1592
 
 
1593
5.4.  NAS-IP-Address
 
1594
 
 
1595
   Description
 
1596
 
 
1597
      This Attribute indicates the identifying IP Address of the NAS
 
1598
      which is requesting authentication of the user, and SHOULD be
 
1599
      unique to the NAS within the scope of the RADIUS server. NAS-IP-
 
1600
      Address is only used in Access-Request packets.  Either NAS-IP-
 
1601
      Address or NAS-Identifier MUST be present in an Access-Request
 
1602
      packet.
 
1603
 
 
1604
      Note that NAS-IP-Address MUST NOT be used to select the shared
 
1605
      secret used to authenticate the request.  The source IP address of
 
1606
      the Access-Request packet MUST be used to select the shared
 
1607
      secret.
 
1608
 
 
1609
   A summary of the NAS-IP-Address Attribute format is shown below.  The
 
1610
   fields are transmitted from left to right.
 
1611
 
 
1612
    0                   1                   2                   3
 
1613
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1614
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1615
   |     Type      |    Length     |            Address
 
1616
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1617
            Address (cont)         |
 
1618
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1619
 
 
1620
   Type
 
1621
 
 
1622
      4 for NAS-IP-Address.
 
1623
 
 
1624
 
 
1625
 
 
1626
Rigney, et al.              Standards Track                    [Page 29]
 
1627
 
 
1628
RFC 2865                         RADIUS                        June 2000
 
1629
 
 
1630
 
 
1631
   Length
 
1632
 
 
1633
      6
 
1634
 
 
1635
   Address
 
1636
 
 
1637
      The Address field is four octets.
 
1638
 
 
1639
5.5.  NAS-Port
 
1640
 
 
1641
   Description
 
1642
 
 
1643
      This Attribute indicates the physical port number of the NAS which
 
1644
      is authenticating the user.  It is only used in Access-Request
 
1645
      packets.  Note that this is using "port" in its sense of a
 
1646
      physical connection on the NAS, not in the sense of a TCP or UDP
 
1647
      port number.  Either NAS-Port or NAS-Port-Type (61) or both SHOULD
 
1648
      be present in an Access-Request packet, if the NAS differentiates
 
1649
      among its ports.
 
1650
 
 
1651
   A summary of the NAS-Port Attribute format is shown below.  The
 
1652
   fields are transmitted from left to right.
 
1653
 
 
1654
    0                   1                   2                   3
 
1655
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1656
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1657
   |     Type      |    Length     |             Value
 
1658
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1659
              Value (cont)         |
 
1660
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1661
 
 
1662
   Type
 
1663
 
 
1664
      5 for NAS-Port.
 
1665
 
 
1666
   Length
 
1667
 
 
1668
      6
 
1669
 
 
1670
   Value
 
1671
 
 
1672
      The Value field is four octets.
 
1673
 
 
1674
 
 
1675
 
 
1676
 
 
1677
 
 
1678
 
 
1679
 
 
1680
 
 
1681
 
 
1682
Rigney, et al.              Standards Track                    [Page 30]
 
1683
 
 
1684
RFC 2865                         RADIUS                        June 2000
 
1685
 
 
1686
 
 
1687
5.6.  Service-Type
 
1688
 
 
1689
   Description
 
1690
 
 
1691
      This Attribute indicates the type of service the user has
 
1692
      requested, or the type of service to be provided.  It MAY be used
 
1693
      in both Access-Request and Access-Accept packets.  A NAS is not
 
1694
      required to implement all of these service types, and MUST treat
 
1695
      unknown or unsupported Service-Types as though an Access-Reject
 
1696
      had been received instead.
 
1697
 
 
1698
   A summary of the Service-Type Attribute format is shown below.  The
 
1699
   fields are transmitted from left to right.
 
1700
 
 
1701
    0                   1                   2                   3
 
1702
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1703
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1704
   |     Type      |    Length     |             Value
 
1705
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1706
              Value (cont)         |
 
1707
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1708
 
 
1709
   Type
 
1710
 
 
1711
      6 for Service-Type.
 
1712
 
 
1713
   Length
 
1714
 
 
1715
      6
 
1716
 
 
1717
   Value
 
1718
 
 
1719
      The Value field is four octets.
 
1720
 
 
1721
       1      Login
 
1722
       2      Framed
 
1723
       3      Callback Login
 
1724
       4      Callback Framed
 
1725
       5      Outbound
 
1726
       6      Administrative
 
1727
       7      NAS Prompt
 
1728
       8      Authenticate Only
 
1729
       9      Callback NAS Prompt
 
1730
      10      Call Check
 
1731
      11      Callback Administrative
 
1732
 
 
1733
 
 
1734
 
 
1735
 
 
1736
 
 
1737
 
 
1738
Rigney, et al.              Standards Track                    [Page 31]
 
1739
 
 
1740
RFC 2865                         RADIUS                        June 2000
 
1741
 
 
1742
 
 
1743
      The service types are defined as follows when used in an Access-
 
1744
      Accept.  When used in an Access-Request, they MAY be considered to
 
1745
      be a hint to the RADIUS server that the NAS has reason to believe
 
1746
      the user would prefer the kind of service indicated, but the
 
1747
      server is not required to honor the hint.
 
1748
 
 
1749
      Login               The user should be connected to a host.
 
1750
 
 
1751
      Framed              A Framed Protocol should be started for the
 
1752
                          User, such as PPP or SLIP.
 
1753
 
 
1754
      Callback Login      The user should be disconnected and called
 
1755
                          back, then connected to a host.
 
1756
 
 
1757
      Callback Framed     The user should be disconnected and called
 
1758
                          back, then a Framed Protocol should be started
 
1759
                          for the User, such as PPP or SLIP.
 
1760
 
 
1761
      Outbound            The user should be granted access to outgoing
 
1762
                          devices.
 
1763
 
 
1764
      Administrative      The user should be granted access to the
 
1765
                          administrative interface to the NAS from which
 
1766
                          privileged commands can be executed.
 
1767
 
 
1768
      NAS Prompt          The user should be provided a command prompt
 
1769
                          on the NAS from which non-privileged commands
 
1770
                          can be executed.
 
1771
 
 
1772
      Authenticate Only   Only Authentication is requested, and no
 
1773
                          authorization information needs to be returned
 
1774
                          in the Access-Accept (typically used by proxy
 
1775
                          servers rather than the NAS itself).
 
1776
 
 
1777
      Callback NAS Prompt The user should be disconnected and called
 
1778
                          back, then provided a command prompt on the
 
1779
                          NAS from which non-privileged commands can be
 
1780
                          executed.
 
1781
 
 
1782
      Call Check          Used by the NAS in an Access-Request packet to
 
1783
                          indicate that a call is being received and
 
1784
                          that the RADIUS server should send back an
 
1785
                          Access-Accept to answer the call, or an
 
1786
                          Access-Reject to not accept the call,
 
1787
                          typically based on the Called-Station-Id or
 
1788
                          Calling-Station-Id attributes.  It is
 
1789
 
 
1790
 
 
1791
 
 
1792
 
 
1793
 
 
1794
Rigney, et al.              Standards Track                    [Page 32]
 
1795
 
 
1796
RFC 2865                         RADIUS                        June 2000
 
1797
 
 
1798
 
 
1799
                          recommended that such Access-Requests use the
 
1800
                          value of Calling-Station-Id as the value of
 
1801
                          the User-Name.
 
1802
 
 
1803
      Callback Administrative
 
1804
                          The user should be disconnected and called
 
1805
                          back, then granted access to the
 
1806
                          administrative interface to the NAS from which
 
1807
                          privileged commands can be executed.
 
1808
 
 
1809
5.7.  Framed-Protocol
 
1810
 
 
1811
   Description
 
1812
 
 
1813
      This Attribute indicates the framing to be used for framed access.
 
1814
      It MAY be used in both Access-Request and Access-Accept packets.
 
1815
 
 
1816
   A summary of the Framed-Protocol Attribute format is shown below.
 
1817
   The fields are transmitted from left to right.
 
1818
 
 
1819
    0                   1                   2                   3
 
1820
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1821
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1822
   |     Type      |    Length     |             Value
 
1823
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1824
              Value (cont)         |
 
1825
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1826
 
 
1827
   Type
 
1828
 
 
1829
      7 for Framed-Protocol.
 
1830
 
 
1831
   Length
 
1832
 
 
1833
      6
 
1834
 
 
1835
   Value
 
1836
 
 
1837
      The Value field is four octets.
 
1838
 
 
1839
      1      PPP
 
1840
      2      SLIP
 
1841
      3      AppleTalk Remote Access Protocol (ARAP)
 
1842
      4      Gandalf proprietary SingleLink/MultiLink protocol
 
1843
      5      Xylogics proprietary IPX/SLIP
 
1844
      6      X.75 Synchronous
 
1845
 
 
1846
 
 
1847
 
 
1848
 
 
1849
 
 
1850
Rigney, et al.              Standards Track                    [Page 33]
 
1851
 
 
1852
RFC 2865                         RADIUS                        June 2000
 
1853
 
 
1854
 
 
1855
5.8.  Framed-IP-Address
 
1856
 
 
1857
   Description
 
1858
 
 
1859
      This Attribute indicates the address to be configured for the
 
1860
      user.  It MAY be used in Access-Accept packets.  It MAY be used in
 
1861
      an Access-Request packet as a hint by the NAS to the server that
 
1862
      it would prefer that address, but the server is not required to
 
1863
      honor the hint.
 
1864
 
 
1865
   A summary of the Framed-IP-Address Attribute format is shown below.
 
1866
   The fields are transmitted from left to right.
 
1867
 
 
1868
    0                   1                   2                   3
 
1869
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1870
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1871
   |     Type      |    Length     |            Address
 
1872
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1873
            Address (cont)         |
 
1874
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1875
 
 
1876
   Type
 
1877
 
 
1878
      8 for Framed-IP-Address.
 
1879
 
 
1880
   Length
 
1881
 
 
1882
      6
 
1883
 
 
1884
   Address
 
1885
 
 
1886
      The Address field is four octets.  The value 0xFFFFFFFF indicates
 
1887
      that the NAS Should allow the user to select an address (e.g.
 
1888
      Negotiated).  The value 0xFFFFFFFE indicates that the NAS should
 
1889
      select an address for the user (e.g. Assigned from a pool of
 
1890
      addresses kept by the NAS).  Other valid values indicate that the
 
1891
      NAS should use that value as the user's IP address.
 
1892
 
 
1893
5.9.  Framed-IP-Netmask
 
1894
 
 
1895
   Description
 
1896
 
 
1897
      This Attribute indicates the IP netmask to be configured for the
 
1898
      user when the user is a router to a network.  It MAY be used in
 
1899
      Access-Accept packets.  It MAY be used in an Access-Request packet
 
1900
      as a hint by the NAS to the server that it would prefer that
 
1901
      netmask, but the server is not required to honor the hint.
 
1902
 
 
1903
 
 
1904
 
 
1905
 
 
1906
Rigney, et al.              Standards Track                    [Page 34]
 
1907
 
 
1908
RFC 2865                         RADIUS                        June 2000
 
1909
 
 
1910
 
 
1911
   A summary of the Framed-IP-Netmask Attribute format is shown below.
 
1912
   The fields are transmitted from left to right.
 
1913
 
 
1914
    0                   1                   2                   3
 
1915
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1916
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1917
   |     Type      |    Length     |            Address
 
1918
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1919
            Address (cont)         |
 
1920
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1921
 
 
1922
   Type
 
1923
 
 
1924
      9 for Framed-IP-Netmask.
 
1925
 
 
1926
   Length
 
1927
 
 
1928
      6
 
1929
 
 
1930
   Address
 
1931
 
 
1932
      The Address field is four octets specifying the IP netmask of the
 
1933
      user.
 
1934
 
 
1935
5.10.  Framed-Routing
 
1936
 
 
1937
   Description
 
1938
 
 
1939
      This Attribute indicates the routing method for the user, when the
 
1940
      user is a router to a network.  It is only used in Access-Accept
 
1941
      packets.
 
1942
 
 
1943
   A summary of the Framed-Routing Attribute format is shown below.  The
 
1944
   fields are transmitted from left to right.
 
1945
 
 
1946
    0                   1                   2                   3
 
1947
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1948
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1949
   |     Type      |    Length     |             Value
 
1950
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1951
              Value (cont)         |
 
1952
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
1953
 
 
1954
   Type
 
1955
 
 
1956
      10 for Framed-Routing.
 
1957
 
 
1958
 
 
1959
 
 
1960
 
 
1961
 
 
1962
Rigney, et al.              Standards Track                    [Page 35]
 
1963
 
 
1964
RFC 2865                         RADIUS                        June 2000
 
1965
 
 
1966
 
 
1967
   Length
 
1968
 
 
1969
      6
 
1970
 
 
1971
   Value
 
1972
 
 
1973
      The Value field is four octets.
 
1974
 
 
1975
       0      None
 
1976
       1      Send routing packets
 
1977
       2      Listen for routing packets
 
1978
       3      Send and Listen
 
1979
 
 
1980
5.11.  Filter-Id
 
1981
 
 
1982
   Description
 
1983
 
 
1984
      This Attribute indicates the name of the filter list for this
 
1985
      user.  Zero or more Filter-Id attributes MAY be sent in an
 
1986
      Access-Accept packet.
 
1987
 
 
1988
      Identifying a filter list by name allows the filter to be used on
 
1989
      different NASes without regard to filter-list implementation
 
1990
      details.
 
1991
 
 
1992
   A summary of the Filter-Id Attribute format is shown below.  The
 
1993
   fields are transmitted from left to right.
 
1994
 
 
1995
    0                   1                   2
 
1996
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
1997
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
1998
   |     Type      |    Length     |  Text ...
 
1999
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2000
 
 
2001
   Type
 
2002
 
 
2003
      11 for Filter-Id.
 
2004
 
 
2005
   Length
 
2006
 
 
2007
      >= 3
 
2008
 
 
2009
   Text
 
2010
 
 
2011
      The Text field is one or more octets, and its contents are
 
2012
      implementation dependent.  It is intended to be human readable and
 
2013
      MUST NOT affect operation of the protocol.  It is recommended that
 
2014
      the message contain UTF-8 encoded 10646 [7] characters.
 
2015
 
 
2016
 
 
2017
 
 
2018
Rigney, et al.              Standards Track                    [Page 36]
 
2019
 
 
2020
RFC 2865                         RADIUS                        June 2000
 
2021
 
 
2022
 
 
2023
5.12.  Framed-MTU
 
2024
 
 
2025
   Description
 
2026
 
 
2027
      This Attribute indicates the Maximum Transmission Unit to be
 
2028
      configured for the user, when it is not negotiated by some other
 
2029
      means (such as PPP).  It MAY be used in Access-Accept packets.  It
 
2030
      MAY be used in an Access-Request packet as a hint by the NAS to
 
2031
      the server that it would prefer that value, but the server is not
 
2032
      required to honor the hint.
 
2033
 
 
2034
   A summary of the Framed-MTU Attribute format is shown below.  The
 
2035
   fields are transmitted from left to right.
 
2036
 
 
2037
    0                   1                   2                   3
 
2038
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2039
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2040
   |     Type      |    Length     |             Value
 
2041
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2042
              Value (cont)         |
 
2043
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2044
 
 
2045
   Type
 
2046
 
 
2047
      12 for Framed-MTU.
 
2048
 
 
2049
   Length
 
2050
 
 
2051
      6
 
2052
 
 
2053
   Value
 
2054
 
 
2055
      The Value field is four octets.  Despite the size of the field,
 
2056
      values range from 64 to 65535.
 
2057
 
 
2058
5.13.  Framed-Compression
 
2059
 
 
2060
   Description
 
2061
 
 
2062
      This Attribute indicates a compression protocol to be used for the
 
2063
      link.  It MAY be used in Access-Accept packets.  It MAY be used in
 
2064
      an Access-Request packet as a hint to the server that the NAS
 
2065
      would prefer to use that compression, but the server is not
 
2066
      required to honor the hint.
 
2067
 
 
2068
      More than one compression protocol Attribute MAY be sent.  It is
 
2069
      the responsibility of the NAS to apply the proper compression
 
2070
      protocol to appropriate link traffic.
 
2071
 
 
2072
 
 
2073
 
 
2074
Rigney, et al.              Standards Track                    [Page 37]
 
2075
 
 
2076
RFC 2865                         RADIUS                        June 2000
 
2077
 
 
2078
 
 
2079
   A summary of the Framed-Compression Attribute format is shown below.
 
2080
   The fields are transmitted from left to right.
 
2081
 
 
2082
    0                   1                   2                   3
 
2083
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2084
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2085
   |     Type      |    Length     |             Value
 
2086
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2087
              Value (cont)         |
 
2088
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2089
 
 
2090
   Type
 
2091
 
 
2092
      13 for Framed-Compression.
 
2093
 
 
2094
   Length
 
2095
 
 
2096
      6
 
2097
 
 
2098
   Value
 
2099
 
 
2100
      The Value field is four octets.
 
2101
 
 
2102
       0      None
 
2103
       1      VJ TCP/IP header compression [10]
 
2104
       2      IPX header compression
 
2105
       3      Stac-LZS compression
 
2106
 
 
2107
5.14.  Login-IP-Host
 
2108
 
 
2109
   Description
 
2110
 
 
2111
      This Attribute indicates the system with which to connect the user,
 
2112
      when the Login-Service Attribute is included.  It MAY be used in
 
2113
      Access-Accept packets.  It MAY be used in an Access-Request packet as
 
2114
      a hint to the server that the NAS would prefer to use that host, but
 
2115
      the server is not required to honor the hint.
 
2116
 
 
2117
   A summary of the Login-IP-Host Attribute format is shown below.  The
 
2118
   fields are transmitted from left to right.
 
2119
 
 
2120
 
 
2121
 
 
2122
 
 
2123
 
 
2124
 
 
2125
 
 
2126
 
 
2127
 
 
2128
 
 
2129
 
 
2130
Rigney, et al.              Standards Track                    [Page 38]
 
2131
 
 
2132
RFC 2865                         RADIUS                        June 2000
 
2133
 
 
2134
 
 
2135
    0                   1                   2                   3
 
2136
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2137
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2138
   |     Type      |    Length     |            Address
 
2139
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2140
            Address (cont)         |
 
2141
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2142
 
 
2143
   Type
 
2144
 
 
2145
      14 for Login-IP-Host.
 
2146
 
 
2147
   Length
 
2148
 
 
2149
      6
 
2150
 
 
2151
   Address
 
2152
 
 
2153
      The Address field is four octets.  The value 0xFFFFFFFF indicates
 
2154
      that the NAS SHOULD allow the user to select an address.  The
 
2155
      value 0 indicates that the NAS SHOULD select a host to connect the
 
2156
      user to.  Other values indicate the address the NAS SHOULD connect
 
2157
      the user to.
 
2158
 
 
2159
5.15.  Login-Service
 
2160
 
 
2161
   Description
 
2162
 
 
2163
      This Attribute indicates the service to use to connect the user to
 
2164
      the login host.  It is only used in Access-Accept packets.
 
2165
 
 
2166
   A summary of the Login-Service Attribute format is shown below.  The
 
2167
   fields are transmitted from left to right.
 
2168
 
 
2169
    0                   1                   2                   3
 
2170
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2171
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2172
   |     Type      |    Length     |             Value
 
2173
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2174
              Value (cont)         |
 
2175
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2176
 
 
2177
   Type
 
2178
 
 
2179
      15 for Login-Service.
 
2180
 
 
2181
 
 
2182
 
 
2183
 
 
2184
 
 
2185
 
 
2186
Rigney, et al.              Standards Track                    [Page 39]
 
2187
 
 
2188
RFC 2865                         RADIUS                        June 2000
 
2189
 
 
2190
 
 
2191
   Length
 
2192
 
 
2193
      6
 
2194
 
 
2195
   Value
 
2196
 
 
2197
      The Value field is four octets.
 
2198
 
 
2199
       0   Telnet
 
2200
       1   Rlogin
 
2201
       2   TCP Clear
 
2202
       3   PortMaster (proprietary)
 
2203
       4   LAT
 
2204
       5   X25-PAD
 
2205
       6   X25-T3POS
 
2206
       8   TCP Clear Quiet (suppresses any NAS-generated connect string)
 
2207
 
 
2208
5.16.  Login-TCP-Port
 
2209
 
 
2210
   Description
 
2211
 
 
2212
      This Attribute indicates the TCP port with which the user is to be
 
2213
      connected, when the Login-Service Attribute is also present.  It
 
2214
      is only used in Access-Accept packets.
 
2215
 
 
2216
   A summary of the Login-TCP-Port Attribute format is shown below.  The
 
2217
   fields are transmitted from left to right.
 
2218
 
 
2219
    0                   1                   2                   3
 
2220
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2221
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2222
   |     Type      |    Length     |             Value
 
2223
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2224
              Value (cont)         |
 
2225
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2226
 
 
2227
   Type
 
2228
 
 
2229
      16 for Login-TCP-Port.
 
2230
 
 
2231
   Length
 
2232
 
 
2233
      6
 
2234
 
 
2235
   Value
 
2236
 
 
2237
      The Value field is four octets.  Despite the size of the field,
 
2238
      values range from 0 to 65535.
 
2239
 
 
2240
 
 
2241
 
 
2242
Rigney, et al.              Standards Track                    [Page 40]
 
2243
 
 
2244
RFC 2865                         RADIUS                        June 2000
 
2245
 
 
2246
 
 
2247
5.17.  (unassigned)
 
2248
 
 
2249
   Description
 
2250
 
 
2251
      ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
 
2252
 
 
2253
5.18.  Reply-Message
 
2254
 
 
2255
   Description
 
2256
 
 
2257
      This Attribute indicates text which MAY be displayed to the user.
 
2258
 
 
2259
      When used in an Access-Accept, it is the success message.
 
2260
 
 
2261
      When used in an Access-Reject, it is the failure message.  It MAY
 
2262
      indicate a dialog message to prompt the user before another
 
2263
      Access-Request attempt.
 
2264
 
 
2265
      When used in an Access-Challenge, it MAY indicate a dialog message
 
2266
      to prompt the user for a response.
 
2267
 
 
2268
      Multiple Reply-Message's MAY be included and if any are displayed,
 
2269
      they MUST be displayed in the same order as they appear in the
 
2270
      packet.
 
2271
 
 
2272
   A summary of the Reply-Message Attribute format is shown below.  The
 
2273
   fields are transmitted from left to right.
 
2274
 
 
2275
    0                   1                   2
 
2276
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2277
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2278
   |     Type      |    Length     |  Text ...
 
2279
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2280
 
 
2281
   Type
 
2282
 
 
2283
      18 for Reply-Message.
 
2284
 
 
2285
   Length
 
2286
 
 
2287
      >= 3
 
2288
 
 
2289
   Text
 
2290
 
 
2291
      The Text field is one or more octets, and its contents are
 
2292
      implementation dependent.  It is intended to be human readable,
 
2293
      and MUST NOT affect operation of the protocol.  It is recommended
 
2294
      that the message contain UTF-8 encoded 10646 [7] characters.
 
2295
 
 
2296
 
 
2297
 
 
2298
Rigney, et al.              Standards Track                    [Page 41]
 
2299
 
 
2300
RFC 2865                         RADIUS                        June 2000
 
2301
 
 
2302
 
 
2303
5.19.  Callback-Number
 
2304
 
 
2305
   Description
 
2306
 
 
2307
      This Attribute indicates a dialing string to be used for callback.
 
2308
      It MAY be used in Access-Accept packets.  It MAY be used in an
 
2309
      Access-Request packet as a hint to the server that a Callback
 
2310
      service is desired, but the server is not required to honor the
 
2311
      hint.
 
2312
 
 
2313
   A summary of the Callback-Number Attribute format is shown below.
 
2314
   The fields are transmitted from left to right.
 
2315
 
 
2316
    0                   1                   2
 
2317
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2318
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2319
   |     Type      |    Length     |  String ...
 
2320
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2321
 
 
2322
   Type
 
2323
 
 
2324
      19 for Callback-Number.
 
2325
 
 
2326
   Length
 
2327
 
 
2328
      >= 3
 
2329
 
 
2330
   String
 
2331
 
 
2332
      The String field is one or more octets.  The actual format of the
 
2333
      information is site or application specific, and a robust
 
2334
      implementation SHOULD support the field as undistinguished octets.
 
2335
 
 
2336
      The codification of the range of allowed usage of this field is
 
2337
      outside the scope of this specification.
 
2338
 
 
2339
5.20.  Callback-Id
 
2340
 
 
2341
   Description
 
2342
 
 
2343
      This Attribute indicates the name of a place to be called, to be
 
2344
      interpreted by the NAS.  It MAY be used in Access-Accept packets.
 
2345
 
 
2346
 
 
2347
 
 
2348
 
 
2349
 
 
2350
 
 
2351
 
 
2352
 
 
2353
 
 
2354
Rigney, et al.              Standards Track                    [Page 42]
 
2355
 
 
2356
RFC 2865                         RADIUS                        June 2000
 
2357
 
 
2358
 
 
2359
   A summary of the Callback-Id Attribute format is shown below.  The
 
2360
   fields are transmitted from left to right.
 
2361
 
 
2362
    0                   1                   2
 
2363
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2364
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2365
   |     Type      |    Length     |  String ...
 
2366
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2367
 
 
2368
   Type
 
2369
 
 
2370
      20 for Callback-Id.
 
2371
 
 
2372
   Length
 
2373
 
 
2374
      >= 3
 
2375
 
 
2376
   String
 
2377
 
 
2378
      The String field is one or more octets.  The actual format of the
 
2379
      information is site or application specific, and a robust
 
2380
      implementation SHOULD support the field as undistinguished octets.
 
2381
 
 
2382
      The codification of the range of allowed usage of this field is
 
2383
      outside the scope of this specification.
 
2384
 
 
2385
5.21.  (unassigned)
 
2386
 
 
2387
   Description
 
2388
 
 
2389
      ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
 
2390
 
 
2391
5.22.  Framed-Route
 
2392
 
 
2393
   Description
 
2394
 
 
2395
      This Attribute provides routing information to be configured for
 
2396
      the user on the NAS.  It is used in the Access-Accept packet and
 
2397
      can appear multiple times.
 
2398
 
 
2399
   A summary of the Framed-Route Attribute format is shown below.  The
 
2400
   fields are transmitted from left to right.
 
2401
 
 
2402
    0                   1                   2
 
2403
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 
2404
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2405
   |     Type      |    Length     |  Text ...
 
2406
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2407
 
 
2408
 
 
2409
 
 
2410
Rigney, et al.              Standards Track                    [Page 43]
 
2411
 
 
2412
RFC 2865                         RADIUS                        June 2000
 
2413
 
 
2414
 
 
2415
   Type
 
2416
 
 
2417
      22 for Framed-Route.
 
2418
 
 
2419
   Length
 
2420
 
 
2421
      >= 3
 
2422
 
 
2423
   Text
 
2424
 
 
2425
      The Text field is one or more octets, and its contents are
 
2426
      implementation dependent.  It is intended to be human readable and
 
2427
      MUST NOT affect operation of the protocol.  It is recommended that
 
2428
      the message contain UTF-8 encoded 10646 [7] characters.
 
2429
 
 
2430
      For IP routes, it SHOULD contain a destination prefix in dotted
 
2431
      quad form optionally followed by a slash and a decimal length
 
2432
      specifier stating how many high order bits of the prefix to use.
 
2433
      That is followed by a space, a gateway address in dotted quad
 
2434
      form, a space, and one or more metrics separated by spaces.  For
 
2435
      example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
 
2436
      specifier may be omitted, in which case it defaults to 8 bits for
 
2437
      class A prefixes, 16 bits for class B prefixes, and 24 bits for
 
2438
      class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".
 
2439
 
 
2440
      Whenever the gateway address is specified as "0.0.0.0" the IP
 
2441
      address of the user SHOULD be used as the gateway address.
 
2442
 
 
2443
5.23.  Framed-IPX-Network
 
2444
 
 
2445
   Description
 
2446
 
 
2447
      This Attribute indicates the IPX Network number to be configured
 
2448
      for the user.  It is used in Access-Accept packets.
 
2449
 
 
2450
   A summary of the Framed-IPX-Network Attribute format is shown below.
 
2451
   The fields are transmitted from left to right.
 
2452
 
 
2453
    0                   1                   2                   3
 
2454
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2455
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2456
   |     Type      |    Length     |             Value
 
2457
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2458
              Value (cont)         |
 
2459
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2460
 
 
2461
 
 
2462
 
 
2463
 
 
2464
 
 
2465
 
 
2466
Rigney, et al.              Standards Track                    [Page 44]
 
2467
 
 
2468
RFC 2865                         RADIUS                        June 2000
 
2469
 
 
2470
 
 
2471
   Type
 
2472
 
 
2473
      23 for Framed-IPX-Network.
 
2474
 
 
2475
   Length
 
2476
 
 
2477
      6
 
2478
 
 
2479
   Value
 
2480
 
 
2481
      The Value field is four octets.  The value 0xFFFFFFFE indicates
 
2482
      that the NAS should select an IPX network for the user (e.g.
 
2483
      assigned from a pool of one or more IPX networks kept by the NAS).
 
2484
      Other values should be used as the IPX network for the link to the
 
2485
      user.
 
2486
 
 
2487
5.24.  State
 
2488
 
 
2489
   Description
 
2490
 
 
2491
      This Attribute is available to be sent by the server to the client
 
2492
      in an Access-Challenge and MUST be sent unmodified from the client
 
2493
      to the server in the new Access-Request reply to that challenge,
 
2494
      if any.
 
2495
 
 
2496
      This Attribute is available to be sent by the server to the client
 
2497
      in an Access-Accept that also includes a Termination-Action
 
2498
      Attribute with the value of RADIUS-Request.  If the NAS performs
 
2499
      the Termination-Action by sending a new Access-Request upon
 
2500
      termination of the current session, it MUST include the State
 
2501
      attribute unchanged in that Access-Request.
 
2502
 
 
2503
      In either usage, the client MUST NOT interpret the attribute
 
2504
      locally.  A packet must have only zero or one State Attribute.
 
2505
      Usage of the State Attribute is implementation dependent.
 
2506
 
 
2507
   A summary of the State Attribute format is shown below.  The fields
 
2508
   are transmitted from left to right.
 
2509
 
 
2510
    0                   1                   2
 
2511
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2512
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2513
   |     Type      |    Length     |  String ...
 
2514
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2515
 
 
2516
   Type
 
2517
 
 
2518
      24 for State.
 
2519
 
 
2520
 
 
2521
 
 
2522
Rigney, et al.              Standards Track                    [Page 45]
 
2523
 
 
2524
RFC 2865                         RADIUS                        June 2000
 
2525
 
 
2526
 
 
2527
   Length
 
2528
 
 
2529
      >= 3
 
2530
 
 
2531
   String
 
2532
 
 
2533
      The String field is one or more octets.  The actual format of the
 
2534
      information is site or application specific, and a robust
 
2535
      implementation SHOULD support the field as undistinguished octets.
 
2536
 
 
2537
      The codification of the range of allowed usage of this field is
 
2538
      outside the scope of this specification.
 
2539
 
 
2540
5.25.  Class
 
2541
 
 
2542
   Description
 
2543
 
 
2544
      This Attribute is available to be sent by the server to the client
 
2545
      in an Access-Accept and SHOULD be sent unmodified by the client to
 
2546
      the accounting server as part of the Accounting-Request packet if
 
2547
      accounting is supported.  The client MUST NOT interpret the
 
2548
      attribute locally.
 
2549
 
 
2550
   A summary of the Class Attribute format is shown below.  The fields
 
2551
   are transmitted from left to right.
 
2552
 
 
2553
    0                   1                   2
 
2554
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2555
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2556
   |     Type      |    Length     |  String ...
 
2557
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2558
 
 
2559
   Type
 
2560
 
 
2561
      25 for Class.
 
2562
 
 
2563
   Length
 
2564
 
 
2565
      >= 3
 
2566
 
 
2567
   String
 
2568
 
 
2569
      The String field is one or more octets.  The actual format of the
 
2570
      information is site or application specific, and a robust
 
2571
      implementation SHOULD support the field as undistinguished octets.
 
2572
 
 
2573
      The codification of the range of allowed usage of this field is
 
2574
      outside the scope of this specification.
 
2575
 
 
2576
 
 
2577
 
 
2578
Rigney, et al.              Standards Track                    [Page 46]
 
2579
 
 
2580
RFC 2865                         RADIUS                        June 2000
 
2581
 
 
2582
 
 
2583
5.26.  Vendor-Specific
 
2584
 
 
2585
   Description
 
2586
 
 
2587
      This Attribute is available to allow vendors to support their own
 
2588
      extended Attributes not suitable for general usage.  It MUST not
 
2589
      affect the operation of the RADIUS protocol.
 
2590
 
 
2591
      Servers not equipped to interpret the vendor-specific information
 
2592
      sent by a client MUST ignore it (although it may be reported).
 
2593
      Clients which do not receive desired vendor-specific information
 
2594
      SHOULD make an attempt to operate without it, although they may do
 
2595
      so (and report they are doing so) in a degraded mode.
 
2596
 
 
2597
   A summary of the Vendor-Specific Attribute format is shown below.
 
2598
   The fields are transmitted from left to right.
 
2599
 
 
2600
    0                   1                   2                   3
 
2601
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2602
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2603
   |     Type      |  Length       |            Vendor-Id
 
2604
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2605
        Vendor-Id (cont)           |  String...
 
2606
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2607
 
 
2608
   Type
 
2609
 
 
2610
      26 for Vendor-Specific.
 
2611
 
 
2612
   Length
 
2613
 
 
2614
      >= 7
 
2615
 
 
2616
   Vendor-Id
 
2617
 
 
2618
      The high-order octet is 0 and the low-order 3 octets are the SMI
 
2619
      Network Management Private Enterprise Code of the Vendor in
 
2620
      network byte order, as defined in the "Assigned Numbers" RFC [6].
 
2621
 
 
2622
   String
 
2623
 
 
2624
      The String field is one or more octets.  The actual format of the
 
2625
      information is site or application specific, and a robust
 
2626
      implementation SHOULD support the field as undistinguished octets.
 
2627
 
 
2628
      The codification of the range of allowed usage of this field is
 
2629
      outside the scope of this specification.
 
2630
 
 
2631
 
 
2632
 
 
2633
 
 
2634
Rigney, et al.              Standards Track                    [Page 47]
 
2635
 
 
2636
RFC 2865                         RADIUS                        June 2000
 
2637
 
 
2638
 
 
2639
      It SHOULD be encoded as a sequence of vendor type / vendor length
 
2640
      / value fields, as follows.  The Attribute-Specific field is
 
2641
      dependent on the vendor's definition of that attribute.  An
 
2642
      example encoding of the Vendor-Specific attribute using this
 
2643
      method follows:
 
2644
 
 
2645
       0                   1                   2                   3
 
2646
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2647
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2648
      |     Type      |  Length       |            Vendor-Id
 
2649
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2650
           Vendor-Id (cont)           | Vendor type   | Vendor length |
 
2651
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2652
      |    Attribute-Specific...
 
2653
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2654
 
 
2655
      Multiple subattributes MAY be encoded within a single Vendor-
 
2656
      Specific attribute, although they do not have to be.
 
2657
 
 
2658
5.27.  Session-Timeout
 
2659
 
 
2660
   Description
 
2661
 
 
2662
      This Attribute sets the maximum number of seconds of service to be
 
2663
      provided to the user before termination of the session or prompt.
 
2664
      This Attribute is available to be sent by the server to the client
 
2665
      in an Access-Accept or Access-Challenge.
 
2666
 
 
2667
   A summary of the Session-Timeout Attribute format is shown below.
 
2668
   The fields are transmitted from left to right.
 
2669
 
 
2670
    0                   1                   2                   3
 
2671
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2672
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2673
   |     Type      |    Length     |             Value
 
2674
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2675
              Value (cont)         |
 
2676
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2677
 
 
2678
   Type
 
2679
 
 
2680
      27 for Session-Timeout.
 
2681
 
 
2682
   Length
 
2683
 
 
2684
      6
 
2685
 
 
2686
 
 
2687
 
 
2688
 
 
2689
 
 
2690
Rigney, et al.              Standards Track                    [Page 48]
 
2691
 
 
2692
RFC 2865                         RADIUS                        June 2000
 
2693
 
 
2694
 
 
2695
   Value
 
2696
 
 
2697
      The field is 4 octets, containing a 32-bit unsigned integer with
 
2698
      the maximum number of seconds this user should be allowed to
 
2699
      remain connected by the NAS.
 
2700
 
 
2701
5.28.  Idle-Timeout
 
2702
 
 
2703
   Description
 
2704
 
 
2705
      This Attribute sets the maximum number of consecutive seconds of
 
2706
      idle connection allowed to the user before termination of the
 
2707
      session or prompt.  This Attribute is available to be sent by the
 
2708
      server to the client in an Access-Accept or Access-Challenge.
 
2709
 
 
2710
   A summary of the Idle-Timeout Attribute format is shown below.  The
 
2711
   fields are transmitted from left to right.
 
2712
 
 
2713
    0                   1                   2                   3
 
2714
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2715
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2716
   |     Type      |    Length     |             Value
 
2717
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2718
              Value (cont)         |
 
2719
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2720
 
 
2721
   Type
 
2722
 
 
2723
      28 for Idle-Timeout.
 
2724
 
 
2725
   Length
 
2726
 
 
2727
      6
 
2728
 
 
2729
   Value
 
2730
 
 
2731
      The field is 4 octets, containing a 32-bit unsigned integer with
 
2732
      the maximum number of consecutive seconds of idle time this user
 
2733
      should be permitted before being disconnected by the NAS.
 
2734
 
 
2735
5.29.  Termination-Action
 
2736
 
 
2737
   Description
 
2738
 
 
2739
      This Attribute indicates what action the NAS should take when the
 
2740
      specified service is completed.  It is only used in Access-Accept
 
2741
      packets.
 
2742
 
 
2743
 
 
2744
 
 
2745
 
 
2746
Rigney, et al.              Standards Track                    [Page 49]
 
2747
 
 
2748
RFC 2865                         RADIUS                        June 2000
 
2749
 
 
2750
 
 
2751
   A summary of the Termination-Action Attribute format is shown below.
 
2752
   The fields are transmitted from left to right.
 
2753
 
 
2754
    0                   1                   2                   3
 
2755
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2756
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2757
   |     Type      |    Length     |             Value
 
2758
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2759
              Value (cont)         |
 
2760
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
2761
 
 
2762
   Type
 
2763
 
 
2764
      29 for Termination-Action.
 
2765
 
 
2766
   Length
 
2767
 
 
2768
      6
 
2769
 
 
2770
   Value
 
2771
 
 
2772
      The Value field is four octets.
 
2773
 
 
2774
       0      Default
 
2775
       1      RADIUS-Request
 
2776
 
 
2777
      If the Value is set to RADIUS-Request, upon termination of the
 
2778
      specified service the NAS MAY send a new Access-Request to the
 
2779
      RADIUS server, including the State attribute if any.
 
2780
 
 
2781
5.30.  Called-Station-Id
 
2782
 
 
2783
   Description
 
2784
 
 
2785
      This Attribute allows the NAS to send in the Access-Request packet
 
2786
      the phone number that the user called, using Dialed Number
 
2787
      Identification (DNIS) or similar technology.  Note that this may
 
2788
      be different from the phone number the call comes in on.  It is
 
2789
      only used in Access-Request packets.
 
2790
 
 
2791
   A summary of the Called-Station-Id Attribute format is shown below.
 
2792
   The fields are transmitted from left to right.
 
2793
 
 
2794
    0                   1                   2
 
2795
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2796
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2797
   |     Type      |    Length     |  String ...
 
2798
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2799
 
 
2800
 
 
2801
 
 
2802
Rigney, et al.              Standards Track                    [Page 50]
 
2803
 
 
2804
RFC 2865                         RADIUS                        June 2000
 
2805
 
 
2806
 
 
2807
   Type
 
2808
 
 
2809
      30 for Called-Station-Id.
 
2810
 
 
2811
   Length
 
2812
 
 
2813
      >= 3
 
2814
 
 
2815
   String
 
2816
 
 
2817
      The String field is one or more octets, containing the phone
 
2818
      number that the user's call came in on.
 
2819
 
 
2820
      The actual format of the information is site or application
 
2821
      specific.  UTF-8 encoded 10646 [7] characters are recommended, but
 
2822
      a robust implementation SHOULD support the field as
 
2823
      undistinguished octets.
 
2824
 
 
2825
      The codification of the range of allowed usage of this field is
 
2826
      outside the scope of this specification.
 
2827
 
 
2828
5.31.  Calling-Station-Id
 
2829
 
 
2830
   Description
 
2831
 
 
2832
      This Attribute allows the NAS to send in the Access-Request packet
 
2833
      the phone number that the call came from, using Automatic Number
 
2834
      Identification (ANI) or similar technology.  It is only used in
 
2835
      Access-Request packets.
 
2836
 
 
2837
   A summary of the Calling-Station-Id Attribute format is shown below.
 
2838
   The fields are transmitted from left to right.
 
2839
 
 
2840
    0                   1                   2
 
2841
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2842
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2843
   |     Type      |    Length     |  String ...
 
2844
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2845
 
 
2846
   Type
 
2847
 
 
2848
      31 for Calling-Station-Id.
 
2849
 
 
2850
   Length
 
2851
 
 
2852
      >= 3
 
2853
 
 
2854
 
 
2855
 
 
2856
 
 
2857
 
 
2858
Rigney, et al.              Standards Track                    [Page 51]
 
2859
 
 
2860
RFC 2865                         RADIUS                        June 2000
 
2861
 
 
2862
 
 
2863
   String
 
2864
 
 
2865
      The String field is one or more octets, containing the phone
 
2866
      number that the user placed the call from.
 
2867
 
 
2868
      The actual format of the information is site or application
 
2869
      specific.  UTF-8 encoded 10646 [7] characters are recommended, but
 
2870
      a robust implementation SHOULD support the field as
 
2871
      undistinguished octets.
 
2872
 
 
2873
      The codification of the range of allowed usage of this field is
 
2874
      outside the scope of this specification.
 
2875
 
 
2876
5.32.  NAS-Identifier
 
2877
 
 
2878
   Description
 
2879
 
 
2880
      This Attribute contains a string identifying the NAS originating
 
2881
      the Access-Request.  It is only used in Access-Request packets.
 
2882
      Either NAS-IP-Address or NAS-Identifier MUST be present in an
 
2883
      Access-Request packet.
 
2884
 
 
2885
      Note that NAS-Identifier MUST NOT be used to select the shared
 
2886
      secret used to authenticate the request.  The source IP address of
 
2887
      the Access-Request packet MUST be used to select the shared
 
2888
      secret.
 
2889
 
 
2890
   A summary of the NAS-Identifier Attribute format is shown below.  The
 
2891
   fields are transmitted from left to right.
 
2892
 
 
2893
    0                   1                   2
 
2894
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2895
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2896
   |     Type      |    Length     |  String ...
 
2897
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2898
 
 
2899
   Type
 
2900
 
 
2901
      32 for NAS-Identifier.
 
2902
 
 
2903
   Length
 
2904
 
 
2905
      >= 3
 
2906
 
 
2907
 
 
2908
 
 
2909
 
 
2910
 
 
2911
 
 
2912
 
 
2913
 
 
2914
Rigney, et al.              Standards Track                    [Page 52]
 
2915
 
 
2916
RFC 2865                         RADIUS                        June 2000
 
2917
 
 
2918
 
 
2919
   String
 
2920
 
 
2921
      The String field is one or more octets, and should be unique to
 
2922
      the NAS within the scope of the RADIUS server.  For example, a
 
2923
      fully qualified domain name would be suitable as a NAS-Identifier.
 
2924
 
 
2925
      The actual format of the information is site or application
 
2926
      specific, and a robust implementation SHOULD support the field as
 
2927
      undistinguished octets.
 
2928
 
 
2929
      The codification of the range of allowed usage of this field is
 
2930
      outside the scope of this specification.
 
2931
 
 
2932
5.33.  Proxy-State
 
2933
 
 
2934
   Description
 
2935
 
 
2936
      This Attribute is available to be sent by a proxy server to
 
2937
      another server when forwarding an Access-Request and MUST be
 
2938
      returned unmodified in the Access-Accept, Access-Reject or
 
2939
      Access-Challenge.  When the proxy server receives the response to
 
2940
      its request, it MUST remove its own Proxy-State (the last Proxy-
 
2941
      State in the packet) before forwarding the response to the NAS.
 
2942
 
 
2943
      If a Proxy-State Attribute is added to a packet when forwarding
 
2944
      the packet, the Proxy-State Attribute MUST be added after any
 
2945
      existing Proxy-State attributes.
 
2946
 
 
2947
      The content of any Proxy-State other than the one added by the
 
2948
      current server should be treated as opaque octets and MUST NOT
 
2949
      affect operation of the protocol.
 
2950
 
 
2951
      Usage of the Proxy-State Attribute is implementation dependent.  A
 
2952
      description of its function is outside the scope of this
 
2953
      specification.
 
2954
 
 
2955
   A summary of the Proxy-State Attribute format is shown below.  The
 
2956
   fields are transmitted from left to right.
 
2957
 
 
2958
    0                   1                   2
 
2959
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
2960
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2961
   |     Type      |    Length     |  String ...
 
2962
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
2963
 
 
2964
   Type
 
2965
 
 
2966
      33 for Proxy-State.
 
2967
 
 
2968
 
 
2969
 
 
2970
Rigney, et al.              Standards Track                    [Page 53]
 
2971
 
 
2972
RFC 2865                         RADIUS                        June 2000
 
2973
 
 
2974
 
 
2975
   Length
 
2976
 
 
2977
      >= 3
 
2978
 
 
2979
   String
 
2980
 
 
2981
      The String field is one or more octets.  The actual format of the
 
2982
      information is site or application specific, and a robust
 
2983
      implementation SHOULD support the field as undistinguished octets.
 
2984
 
 
2985
      The codification of the range of allowed usage of this field is
 
2986
      outside the scope of this specification.
 
2987
 
 
2988
5.34.  Login-LAT-Service
 
2989
 
 
2990
   Description
 
2991
 
 
2992
      This Attribute indicates the system with which the user is to be
 
2993
      connected by LAT.  It MAY be used in Access-Accept packets, but
 
2994
      only when LAT is specified as the Login-Service.  It MAY be used
 
2995
      in an Access-Request packet as a hint to the server, but the
 
2996
      server is not required to honor the hint.
 
2997
 
 
2998
      Administrators use the service attribute when dealing with
 
2999
      clustered systems, such as a VAX or Alpha cluster. In such an
 
3000
      environment several different time sharing hosts share the same
 
3001
      resources (disks, printers, etc.), and administrators often
 
3002
      configure each to offer access (service) to each of the shared
 
3003
      resources. In this case, each host in the cluster advertises its
 
3004
      services through LAT broadcasts.
 
3005
 
 
3006
      Sophisticated users often know which service providers (machines)
 
3007
      are faster and tend to use a node name when initiating a LAT
 
3008
      connection.  Alternately, some administrators want particular
 
3009
      users to use certain machines as a primitive form of load
 
3010
      balancing (although LAT knows how to do load balancing itself).
 
3011
 
 
3012
   A summary of the Login-LAT-Service Attribute format is shown below.
 
3013
   The fields are transmitted from left to right.
 
3014
 
 
3015
    0                   1                   2
 
3016
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3017
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3018
   |     Type      |    Length     |  String ...
 
3019
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3020
 
 
3021
 
 
3022
 
 
3023
 
 
3024
 
 
3025
 
 
3026
Rigney, et al.              Standards Track                    [Page 54]
 
3027
 
 
3028
RFC 2865                         RADIUS                        June 2000
 
3029
 
 
3030
 
 
3031
   Type
 
3032
 
 
3033
      34 for Login-LAT-Service.
 
3034
 
 
3035
   Length
 
3036
 
 
3037
      >= 3
 
3038
 
 
3039
   String
 
3040
 
 
3041
      The String field is one or more octets, and contains the identity
 
3042
      of the LAT service to use.  The LAT Architecture allows this
 
3043
      string to contain $ (dollar), - (hyphen), . (period), _
 
3044
      (underscore), numerics, upper and lower case alphabetics, and the
 
3045
      ISO Latin-1 character set extension [11].  All LAT string
 
3046
      comparisons are case insensitive.
 
3047
 
 
3048
5.35.  Login-LAT-Node
 
3049
 
 
3050
   Description
 
3051
 
 
3052
      This Attribute indicates the Node with which the user is to be
 
3053
      automatically connected by LAT.  It MAY be used in Access-Accept
 
3054
      packets, but only when LAT is specified as the Login-Service.  It
 
3055
      MAY be used in an Access-Request packet as a hint to the server,
 
3056
      but the server is not required to honor the hint.
 
3057
 
 
3058
   A summary of the Login-LAT-Node Attribute format is shown below.  The
 
3059
   fields are transmitted from left to right.
 
3060
 
 
3061
    0                   1                   2
 
3062
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3063
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3064
   |     Type      |    Length     |  String ...
 
3065
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3066
 
 
3067
   Type
 
3068
 
 
3069
      35 for Login-LAT-Node.
 
3070
 
 
3071
   Length
 
3072
 
 
3073
      >= 3
 
3074
 
 
3075
 
 
3076
 
 
3077
 
 
3078
 
 
3079
 
 
3080
 
 
3081
 
 
3082
Rigney, et al.              Standards Track                    [Page 55]
 
3083
 
 
3084
RFC 2865                         RADIUS                        June 2000
 
3085
 
 
3086
 
 
3087
   String
 
3088
 
 
3089
      The String field is one or more octets, and contains the identity
 
3090
      of the LAT Node to connect the user to.  The LAT Architecture
 
3091
      allows this string to contain $ (dollar), - (hyphen), . (period),
 
3092
      _ (underscore), numerics, upper and lower case alphabetics, and
 
3093
      the ISO Latin-1 character set extension.  All LAT string
 
3094
      comparisons are case insensitive.
 
3095
 
 
3096
5.36.  Login-LAT-Group
 
3097
 
 
3098
   Description
 
3099
 
 
3100
      This Attribute contains a string identifying the LAT group codes
 
3101
      which this user is authorized to use.  It MAY be used in Access-
 
3102
      Accept packets, but only when LAT is specified as the Login-
 
3103
      Service.  It MAY be used in an Access-Request packet as a hint to
 
3104
      the server, but the server is not required to honor the hint.
 
3105
 
 
3106
      LAT supports 256 different group codes, which LAT uses as a form
 
3107
      of access rights.  LAT encodes the group codes as a 256 bit
 
3108
      bitmap.
 
3109
 
 
3110
      Administrators can assign one or more of the group code bits at
 
3111
      the LAT service provider; it will only accept LAT connections that
 
3112
      have these group codes set in the bit map. The administrators
 
3113
      assign a bitmap of authorized group codes to each user; LAT gets
 
3114
      these from the operating system, and uses these in its requests to
 
3115
      the service providers.
 
3116
 
 
3117
   A summary of the Login-LAT-Group Attribute format is shown below.
 
3118
   The fields are transmitted from left to right.
 
3119
 
 
3120
    0                   1                   2
 
3121
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3122
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3123
   |     Type      |    Length     |  String ...
 
3124
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3125
 
 
3126
   Type
 
3127
 
 
3128
      36 for Login-LAT-Group.
 
3129
 
 
3130
   Length
 
3131
 
 
3132
      34
 
3133
 
 
3134
 
 
3135
 
 
3136
 
 
3137
 
 
3138
Rigney, et al.              Standards Track                    [Page 56]
 
3139
 
 
3140
RFC 2865                         RADIUS                        June 2000
 
3141
 
 
3142
 
 
3143
   String
 
3144
 
 
3145
      The String field is a 32 octet bit map, most significant octet
 
3146
      first.  A robust implementation SHOULD support the field as
 
3147
      undistinguished octets.
 
3148
 
 
3149
      The codification of the range of allowed usage of this field is
 
3150
      outside the scope of this specification.
 
3151
 
 
3152
5.37.  Framed-AppleTalk-Link
 
3153
 
 
3154
   Description
 
3155
 
 
3156
      This Attribute indicates the AppleTalk network number which should
 
3157
      be used for the serial link to the user, which is another
 
3158
      AppleTalk router.  It is only used in Access-Accept packets.  It
 
3159
      is never used when the user is not another router.
 
3160
 
 
3161
   A summary of the Framed-AppleTalk-Link Attribute format is shown
 
3162
   below.  The fields are transmitted from left to right.
 
3163
 
 
3164
    0                   1                   2                   3
 
3165
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3166
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3167
   |     Type      |    Length     |             Value
 
3168
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3169
              Value (cont)         |
 
3170
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3171
 
 
3172
   Type
 
3173
 
 
3174
      37 for Framed-AppleTalk-Link.
 
3175
 
 
3176
   Length
 
3177
 
 
3178
      6
 
3179
 
 
3180
   Value
 
3181
 
 
3182
      The Value field is four octets.  Despite the size of the field,
 
3183
      values range from 0 to 65535.  The special value of 0 indicates
 
3184
      that this is an unnumbered serial link.  A value of 1-65535 means
 
3185
      that the serial line between the NAS and the user should be
 
3186
      assigned that value as an AppleTalk network number.
 
3187
 
 
3188
 
 
3189
 
 
3190
 
 
3191
 
 
3192
 
 
3193
 
 
3194
Rigney, et al.              Standards Track                    [Page 57]
 
3195
 
 
3196
RFC 2865                         RADIUS                        June 2000
 
3197
 
 
3198
 
 
3199
5.38.  Framed-AppleTalk-Network
 
3200
 
 
3201
   Description
 
3202
 
 
3203
      This Attribute indicates the AppleTalk Network number which the
 
3204
      NAS should probe to allocate an AppleTalk node for the user.  It
 
3205
      is only used in Access-Accept packets.  It is never used when the
 
3206
      user is another router.  Multiple instances of this Attribute
 
3207
      indicate that the NAS may probe using any of the network numbers
 
3208
      specified.
 
3209
 
 
3210
   A summary of the Framed-AppleTalk-Network Attribute format is shown
 
3211
   below.  The fields are transmitted from left to right.
 
3212
 
 
3213
    0                   1                   2                   3
 
3214
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3215
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3216
   |     Type      |    Length     |             Value
 
3217
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3218
              Value (cont)         |
 
3219
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3220
 
 
3221
   Type
 
3222
 
 
3223
      38 for Framed-AppleTalk-Network.
 
3224
 
 
3225
   Length
 
3226
 
 
3227
      6
 
3228
 
 
3229
   Value
 
3230
 
 
3231
      The Value field is four octets.  Despite the size of the field,
 
3232
      values range from 0 to 65535.  The special value 0 indicates that
 
3233
      the NAS should assign a network for the user, using its default
 
3234
      cable range.  A value between 1 and 65535 (inclusive) indicates
 
3235
      the AppleTalk Network the NAS should probe to find an address for
 
3236
      the user.
 
3237
 
 
3238
5.39.  Framed-AppleTalk-Zone
 
3239
 
 
3240
   Description
 
3241
 
 
3242
      This Attribute indicates the AppleTalk Default Zone to be used for
 
3243
      this user.  It is only used in Access-Accept packets.  Multiple
 
3244
      instances of this attribute in the same packet are not allowed.
 
3245
 
 
3246
 
 
3247
 
 
3248
 
 
3249
 
 
3250
Rigney, et al.              Standards Track                    [Page 58]
 
3251
 
 
3252
RFC 2865                         RADIUS                        June 2000
 
3253
 
 
3254
 
 
3255
   A summary of the Framed-AppleTalk-Zone Attribute format is shown
 
3256
   below.  The fields are transmitted from left to right.
 
3257
 
 
3258
    0                   1                   2
 
3259
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
 
3260
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3261
   |     Type      |    Length     |  String ...
 
3262
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3263
 
 
3264
   Type
 
3265
 
 
3266
      39 for Framed-AppleTalk-Zone.
 
3267
 
 
3268
   Length
 
3269
 
 
3270
      >= 3
 
3271
 
 
3272
   String
 
3273
 
 
3274
      The name of the Default AppleTalk Zone to be used for this user.
 
3275
      A robust implementation SHOULD support the field as
 
3276
      undistinguished octets.
 
3277
 
 
3278
      The codification of the range of allowed usage of this field is
 
3279
      outside the scope of this specification.
 
3280
 
 
3281
5.40.  CHAP-Challenge
 
3282
 
 
3283
   Description
 
3284
 
 
3285
      This Attribute contains the CHAP Challenge sent by the NAS to a
 
3286
      PPP Challenge-Handshake Authentication Protocol (CHAP) user.  It
 
3287
      is only used in Access-Request packets.
 
3288
 
 
3289
      If the CHAP challenge value is 16 octets long it MAY be placed in
 
3290
      the Request Authenticator field instead of using this attribute.
 
3291
 
 
3292
   A summary of the CHAP-Challenge Attribute format is shown below.  The
 
3293
   fields are transmitted from left to right.
 
3294
 
 
3295
    0                   1                   2
 
3296
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 
3297
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3298
   |     Type      |    Length     |    String...
 
3299
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3300
 
 
3301
 
 
3302
 
 
3303
 
 
3304
 
 
3305
 
 
3306
Rigney, et al.              Standards Track                    [Page 59]
 
3307
 
 
3308
RFC 2865                         RADIUS                        June 2000
 
3309
 
 
3310
 
 
3311
   Type
 
3312
 
 
3313
      60 for CHAP-Challenge.
 
3314
 
 
3315
   Length
 
3316
 
 
3317
      >= 7
 
3318
 
 
3319
   String
 
3320
 
 
3321
      The String field contains the CHAP Challenge.
 
3322
 
 
3323
5.41.  NAS-Port-Type
 
3324
 
 
3325
   Description
 
3326
 
 
3327
      This Attribute indicates the type of the physical port of the NAS
 
3328
      which is authenticating the user.  It can be used instead of or in
 
3329
      addition to the NAS-Port (5) attribute.  It is only used in
 
3330
      Access-Request packets.  Either NAS-Port (5) or NAS-Port-Type or
 
3331
      both SHOULD be present in an Access-Request packet, if the NAS
 
3332
      differentiates among its ports.
 
3333
 
 
3334
   A summary of the NAS-Port-Type Attribute format is shown below.  The
 
3335
   fields are transmitted from left to right.
 
3336
 
 
3337
    0                   1                   2                   3
 
3338
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3339
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3340
   |     Type      |    Length     |             Value
 
3341
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3342
              Value (cont)         |
 
3343
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3344
 
 
3345
   Type
 
3346
 
 
3347
      61 for NAS-Port-Type.
 
3348
 
 
3349
   Length
 
3350
 
 
3351
      6
 
3352
 
 
3353
   Value
 
3354
 
 
3355
      The Value field is four octets.  "Virtual" refers to a connection
 
3356
      to the NAS via some transport protocol, instead of through a
 
3357
      physical port.  For example, if a user telnetted into a NAS to
 
3358
 
 
3359
 
 
3360
 
 
3361
 
 
3362
Rigney, et al.              Standards Track                    [Page 60]
 
3363
 
 
3364
RFC 2865                         RADIUS                        June 2000
 
3365
 
 
3366
 
 
3367
      authenticate himself as an Outbound-User, the Access-Request might
 
3368
      include NAS-Port-Type = Virtual as a hint to the RADIUS server
 
3369
      that the user was not on a physical port.
 
3370
 
 
3371
      0       Async
 
3372
      1       Sync
 
3373
      2       ISDN Sync
 
3374
      3       ISDN Async V.120
 
3375
      4       ISDN Async V.110
 
3376
      5       Virtual
 
3377
      6       PIAFS
 
3378
      7       HDLC Clear Channel
 
3379
      8       X.25
 
3380
      9       X.75
 
3381
      10      G.3 Fax
 
3382
      11      SDSL - Symmetric DSL
 
3383
      12      ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
 
3384
              Modulation
 
3385
      13      ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
 
3386
      14      IDSL - ISDN Digital Subscriber Line
 
3387
      15      Ethernet
 
3388
      16      xDSL - Digital Subscriber Line of unknown type
 
3389
      17      Cable
 
3390
      18      Wireless - Other
 
3391
      19      Wireless - IEEE 802.11
 
3392
 
 
3393
      PIAFS is a form of wireless ISDN commonly used in Japan, and
 
3394
      stands for PHS (Personal Handyphone System) Internet Access Forum
 
3395
      Standard (PIAFS).
 
3396
 
 
3397
5.42.  Port-Limit
 
3398
 
 
3399
   Description
 
3400
 
 
3401
      This Attribute sets the maximum number of ports to be provided to
 
3402
      the user by the NAS.  This Attribute MAY be sent by the server to
 
3403
      the client in an Access-Accept packet.  It is intended for use in
 
3404
      conjunction with Multilink PPP [12] or similar uses.  It MAY also
 
3405
      be sent by the NAS to the server as a hint that that many ports
 
3406
      are desired for use, but the server is not required to honor the
 
3407
      hint.
 
3408
 
 
3409
   A summary of the Port-Limit Attribute format is shown below.  The
 
3410
   fields are transmitted from left to right.
 
3411
 
 
3412
 
 
3413
 
 
3414
 
 
3415
 
 
3416
 
 
3417
 
 
3418
Rigney, et al.              Standards Track                    [Page 61]
 
3419
 
 
3420
RFC 2865                         RADIUS                        June 2000
 
3421
 
 
3422
 
 
3423
    0                   1                   2                   3
 
3424
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3425
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3426
   |     Type      |    Length     |             Value
 
3427
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3428
              Value (cont)         |
 
3429
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
3430
 
 
3431
   Type
 
3432
 
 
3433
      62 for Port-Limit.
 
3434
 
 
3435
   Length
 
3436
 
 
3437
      6
 
3438
 
 
3439
   Value
 
3440
 
 
3441
      The field is 4 octets, containing a 32-bit unsigned integer with
 
3442
      the maximum number of ports this user should be allowed to connect
 
3443
      to on the NAS.
 
3444
 
 
3445
5.43.  Login-LAT-Port
 
3446
 
 
3447
   Description
 
3448
 
 
3449
      This Attribute indicates the Port with which the user is to be
 
3450
      connected by LAT.  It MAY be used in Access-Accept packets, but
 
3451
      only when LAT is specified as the Login-Service.  It MAY be used
 
3452
      in an Access-Request packet as a hint to the server, but the
 
3453
      server is not required to honor the hint.
 
3454
 
 
3455
   A summary of the Login-LAT-Port Attribute format is shown below.  The
 
3456
   fields are transmitted from left to right.
 
3457
 
 
3458
    0                   1                   2
 
3459
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 
3460
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3461
   |     Type      |    Length     |  String ...
 
3462
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 
3463
 
 
3464
   Type
 
3465
 
 
3466
      63 for Login-LAT-Port.
 
3467
 
 
3468
   Length
 
3469
 
 
3470
      >= 3
 
3471
 
 
3472
 
 
3473
 
 
3474
Rigney, et al.              Standards Track                    [Page 62]
 
3475
 
 
3476
RFC 2865                         RADIUS                        June 2000
 
3477
 
 
3478
 
 
3479
   String
 
3480
 
 
3481
      The String field is one or more octets, and contains the identity
 
3482
      of the LAT port to use.  The LAT Architecture allows this string
 
3483
      to contain $ (dollar), - (hyphen), . (period), _ (underscore),
 
3484
      numerics, upper and lower case alphabetics, and the ISO Latin-1
 
3485
      character set extension.  All LAT string comparisons are case
 
3486
      insensitive.
 
3487
 
 
3488
5.44.  Table of Attributes
 
3489
 
 
3490
   The following table provides a guide to which attributes may be found
 
3491
   in which kinds of packets, and in what quantity.
 
3492
 
 
3493
   Request   Accept   Reject   Challenge   #    Attribute
 
3494
   0-1       0-1      0        0            1   User-Name
 
3495
   0-1       0        0        0            2   User-Password [Note 1]
 
3496
   0-1       0        0        0            3   CHAP-Password [Note 1]
 
3497
   0-1       0        0        0            4   NAS-IP-Address [Note 2]
 
3498
   0-1       0        0        0            5   NAS-Port
 
3499
   0-1       0-1      0        0            6   Service-Type
 
3500
   0-1       0-1      0        0            7   Framed-Protocol
 
3501
   0-1       0-1      0        0            8   Framed-IP-Address
 
3502
   0-1       0-1      0        0            9   Framed-IP-Netmask
 
3503
   0         0-1      0        0           10   Framed-Routing
 
3504
   0         0+       0        0           11   Filter-Id
 
3505
   0-1       0-1      0        0           12   Framed-MTU
 
3506
   0+        0+       0        0           13   Framed-Compression
 
3507
   0+        0+       0        0           14   Login-IP-Host
 
3508
   0         0-1      0        0           15   Login-Service
 
3509
   0         0-1      0        0           16   Login-TCP-Port
 
3510
   0         0+       0+       0+          18   Reply-Message
 
3511
   0-1       0-1      0        0           19   Callback-Number
 
3512
   0         0-1      0        0           20   Callback-Id
 
3513
   0         0+       0        0           22   Framed-Route
 
3514
   0         0-1      0        0           23   Framed-IPX-Network
 
3515
   0-1       0-1      0        0-1         24   State [Note 1]
 
3516
   0         0+       0        0           25   Class
 
3517
   0+        0+       0        0+          26   Vendor-Specific
 
3518
   0         0-1      0        0-1         27   Session-Timeout
 
3519
   0         0-1      0        0-1         28   Idle-Timeout
 
3520
   0         0-1      0        0           29   Termination-Action
 
3521
   0-1       0        0        0           30   Called-Station-Id
 
3522
   0-1       0        0        0           31   Calling-Station-Id
 
3523
   0-1       0        0        0           32   NAS-Identifier [Note 2]
 
3524
   0+        0+       0+       0+          33   Proxy-State
 
3525
   0-1       0-1      0        0           34   Login-LAT-Service
 
3526
   0-1       0-1      0        0           35   Login-LAT-Node
 
3527
 
 
3528
 
 
3529
 
 
3530
Rigney, et al.              Standards Track                    [Page 63]
 
3531
 
 
3532
RFC 2865                         RADIUS                        June 2000
 
3533
 
 
3534
 
 
3535
   0-1       0-1      0        0           36   Login-LAT-Group
 
3536
   0         0-1      0        0           37   Framed-AppleTalk-Link
 
3537
   0         0+       0        0           38   Framed-AppleTalk-Network
 
3538
   0         0-1      0        0           39   Framed-AppleTalk-Zone
 
3539
   0-1       0        0        0           60   CHAP-Challenge
 
3540
   0-1       0        0        0           61   NAS-Port-Type
 
3541
   0-1       0-1      0        0           62   Port-Limit
 
3542
   0-1       0-1      0        0           63   Login-LAT-Port
 
3543
   Request   Accept   Reject   Challenge   #    Attribute
 
3544
 
 
3545
   [Note 1] An Access-Request MUST contain either a User-Password or a
 
3546
   CHAP-Password or State.  An Access-Request MUST NOT contain both a
 
3547
   User-Password and a CHAP-Password.  If future extensions allow other
 
3548
   kinds of authentication information to be conveyed, the attribute for
 
3549
   that can be used in an Access-Request instead of User-Password or
 
3550
   CHAP-Password.
 
3551
 
 
3552
   [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
 
3553
   NAS-Identifier (or both).
 
3554
 
 
3555
   The following table defines the meaning of the above table entries.
 
3556
 
 
3557
0     This attribute MUST NOT be present in packet.
 
3558
0+    Zero or more instances of this attribute MAY be present in packet.
 
3559
0-1   Zero or one instance of this attribute MAY be present in packet.
 
3560
1     Exactly one instance of this attribute MUST be present in packet.
 
3561
 
 
3562
6.  IANA Considerations
 
3563
 
 
3564
   This section provides guidance to the Internet Assigned Numbers
 
3565
   Authority (IANA) regarding registration of values related to the
 
3566
   RADIUS protocol, in accordance with BCP 26 [13].
 
3567
 
 
3568
   There are three name spaces in RADIUS that require registration:
 
3569
   Packet Type Codes, Attribute Types, and Attribute Values (for certain
 
3570
   Attributes).
 
3571
 
 
3572
   RADIUS is not intended as a general-purpose Network Access Server
 
3573
   (NAS) management protocol, and allocations should not be made for
 
3574
   purposes unrelated to Authentication, Authorization or Accounting.
 
3575
 
 
3576
6.1.  Definition of Terms
 
3577
 
 
3578
   The following terms are used here with the meanings defined in
 
3579
   BCP 26: "name space", "assigned value", "registration".
 
3580
 
 
3581
 
 
3582
 
 
3583
 
 
3584
 
 
3585
 
 
3586
Rigney, et al.              Standards Track                    [Page 64]
 
3587
 
 
3588
RFC 2865                         RADIUS                        June 2000
 
3589
 
 
3590
 
 
3591
   The following policies are used here with the meanings defined in
 
3592
   BCP 26: "Private Use", "First Come First Served", "Expert Review",
 
3593
   "Specification Required", "IETF Consensus", "Standards Action".
 
3594
 
 
3595
6.2.  Recommended Registration Policies
 
3596
 
 
3597
   For registration requests where a Designated Expert should be
 
3598
   consulted, the IESG Area Director for Operations should appoint the
 
3599
   Designated Expert.
 
3600
 
 
3601
   For registration requests requiring Expert Review, the ietf-radius
 
3602
   mailing list should be consulted.
 
3603
 
 
3604
   Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
 
3605
   been allocated.  Because a new Packet Type has considerable impact on
 
3606
   interoperability, a new Packet Type Code requires Standards Action,
 
3607
   and should be allocated starting at 14.
 
3608
 
 
3609
   Attribute Types have a range from 1 to 255, and are the scarcest
 
3610
   resource in RADIUS, thus must be allocated with care.  Attributes
 
3611
   1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
 
3612
   re-use.  Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
 
3613
   following Expert Review, with Specification Required.  Release of
 
3614
   blocks of Attribute Types (more than 3 at a time for a given purpose)
 
3615
   should require IETF Consensus.  It is recommended that attributes 17
 
3616
   and 21 be used only after all others are exhausted.
 
3617
 
 
3618
   Note that RADIUS defines a mechanism for Vendor-Specific extensions
 
3619
   (Attribute 26) and the use of that should be encouraged instead of
 
3620
   allocation of global attribute types, for functions specific only to
 
3621
   one vendor's implementation of RADIUS, where no interoperability is
 
3622
   deemed useful.
 
3623
 
 
3624
   As stated in the "Attributes" section above:
 
3625
 
 
3626
      "[Attribute Type] Values 192-223 are reserved for experimental
 
3627
      use, values 224-240 are reserved for implementation-specific use,
 
3628
      and values 241-255 are reserved and should not be used."
 
3629
 
 
3630
   Therefore Attribute values 192-240 are considered Private Use, and
 
3631
   values 241-255 require Standards Action.
 
3632
 
 
3633
   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
 
3634
   list of values to correspond with various meanings.  There can be 4
 
3635
   billion (2^32) values for each attribute. Adding additional values to
 
3636
   the list can be done on a First Come, First Served basis by the IANA.
 
3637
 
 
3638
 
 
3639
 
 
3640
 
 
3641
 
 
3642
Rigney, et al.              Standards Track                    [Page 65]
 
3643
 
 
3644
RFC 2865                         RADIUS                        June 2000
 
3645
 
 
3646
 
 
3647
7.  Examples
 
3648
 
 
3649
   A few examples are presented to illustrate the flow of packets and
 
3650
   use of typical attributes.  These examples are not intended to be
 
3651
   exhaustive, many others are possible.  Hexadecimal dumps of the
 
3652
   example packets are given in network byte order, using the shared
 
3653
   secret "xyzzy5461".
 
3654
 
 
3655
7.1.  User Telnet to Specified Host
 
3656
 
 
3657
   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
 
3658
   RADIUS Server for a user named nemo logging in on port 3 with
 
3659
   password "arctangent".
 
3660
 
 
3661
   The Request Authenticator is a 16 octet random number generated by
 
3662
   the NAS.
 
3663
 
 
3664
   The User-Password is 16 octets of password padded at end with nulls,
 
3665
   XORed with MD5(shared secret|Request Authenticator).
 
3666
 
 
3667
      01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
 
3668
      98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
 
3669
      93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
 
3670
      01 10 05 06 00 00 00 03
 
3671
 
 
3672
       1 Code = Access-Request (1)
 
3673
       1 ID = 0
 
3674
       2 Length = 56
 
3675
      16 Request Authenticator
 
3676
 
 
3677
      Attributes:
 
3678
       6  User-Name = "nemo"
 
3679
      18  User-Password
 
3680
       6  NAS-IP-Address = 192.168.1.16
 
3681
       6  NAS-Port = 3
 
3682
 
 
3683
   The RADIUS server authenticates nemo, and sends an Access-Accept UDP
 
3684
   packet to the NAS telling it to telnet nemo to host 192.168.1.3.
 
3685
 
 
3686
   The Response Authenticator is a 16-octet MD5 checksum of the code
 
3687
   (2), id (0), Length (38), the Request Authenticator from above, the
 
3688
   attributes in this reply, and the shared secret.
 
3689
 
 
3690
 
 
3691
 
 
3692
 
 
3693
 
 
3694
 
 
3695
 
 
3696
 
 
3697
 
 
3698
Rigney, et al.              Standards Track                    [Page 66]
 
3699
 
 
3700
RFC 2865                         RADIUS                        June 2000
 
3701
 
 
3702
 
 
3703
      02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
 
3704
      9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
 
3705
      0e 06 c0 a8 01 03
 
3706
 
 
3707
       1 Code = Access-Accept (2)
 
3708
       1 ID = 0 (same as in Access-Request)
 
3709
       2 Length = 38
 
3710
      16 Response Authenticator
 
3711
 
 
3712
      Attributes:
 
3713
       6  Service-Type (6) = Login (1)
 
3714
       6  Login-Service (15) = Telnet (0)
 
3715
       6  Login-IP-Host (14) = 192.168.1.3
 
3716
 
 
3717
7.2.  Framed User Authenticating with CHAP
 
3718
 
 
3719
   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
 
3720
   RADIUS Server for a user named flopsy logging in on port 20 with PPP,
 
3721
   authenticating using CHAP.  The NAS sends along the Service-Type and
 
3722
   Framed-Protocol attributes as a hint to the RADIUS server that this
 
3723
   user is looking for PPP, although the NAS is not required to do so.
 
3724
 
 
3725
   The Request Authenticator is a 16 octet random number generated by
 
3726
   the NAS, and is also used as the CHAP Challenge.
 
3727
 
 
3728
   The CHAP-Password consists of a 1 octet CHAP ID, in this case 22,
 
3729
   followed by the 16 octet CHAP response.
 
3730
 
 
3731
      01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e
 
3732
      0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9
 
3733
      75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04
 
3734
      06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00
 
3735
      02 07 06 00 00 00 01
 
3736
 
 
3737
       1 Code = 1     (Access-Request)
 
3738
       1 ID = 1
 
3739
       2 Length = 71
 
3740
      16 Request Authenticator
 
3741
 
 
3742
      Attributes:
 
3743
       8  User-Name (1) = "flopsy"
 
3744
      19  CHAP-Password (3)
 
3745
       6  NAS-IP-Address (4) = 192.168.1.16
 
3746
       6  NAS-Port (5) = 20
 
3747
       6  Service-Type (6) = Framed (2)
 
3748
       6  Framed-Protocol (7) = PPP (1)
 
3749
 
 
3750
 
 
3751
 
 
3752
 
 
3753
 
 
3754
Rigney, et al.              Standards Track                    [Page 67]
 
3755
 
 
3756
RFC 2865                         RADIUS                        June 2000
 
3757
 
 
3758
 
 
3759
   The RADIUS server authenticates flopsy, and sends an Access-Accept
 
3760
   UDP packet to the NAS telling it to start PPP service and assign an
 
3761
   address for the user out of its dynamic address pool.
 
3762
 
 
3763
   The Response Authenticator is a 16-octet MD5 checksum of the code
 
3764
   (2), id (1), Length (56), the Request Authenticator from above, the
 
3765
   attributes in this reply, and the shared secret.
 
3766
 
 
3767
      02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
 
3768
      3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
 
3769
      08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
 
3770
      00 01 0c 06 00 00 05 dc
 
3771
 
 
3772
       1 Code = Access-Accept (2)
 
3773
       1 ID = 1 (same as in Access-Request)
 
3774
       2 Length = 56
 
3775
      16 Response Authenticator
 
3776
 
 
3777
      Attributes:
 
3778
       6  Service-Type (6) = Framed (2)
 
3779
       6  Framed-Protocol (7) = PPP (1)
 
3780
       6  Framed-IP-Address (8) = 255.255.255.254
 
3781
       6  Framed-Routing (10) = None (0)
 
3782
       6  Framed-Compression (13) = VJ TCP/IP Header Compression (1)
 
3783
       6  Framed-MTU (12) = 1500
 
3784
 
 
3785
7.3.  User with Challenge-Response card
 
3786
 
 
3787
   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
 
3788
   RADIUS Server for a user named mopsy logging in on port 7.  The user
 
3789
   enters the dummy password "challenge" in this example.  The challenge
 
3790
   and response generated by the smart card for this example are
 
3791
   "32769430" and "99101462".
 
3792
 
 
3793
   The Request Authenticator is a 16 octet random number generated by
 
3794
   the NAS.
 
3795
 
 
3796
   The User-Password is 16 octets of password, in this case "challenge",
 
3797
   padded at the end with nulls, XORed with MD5(shared secret|Request
 
3798
   Authenticator).
 
3799
 
 
3800
      01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9
 
3801
      30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75
 
3802
      73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0
 
3803
      a8 01 10 05 06 00 00 00 07
 
3804
 
 
3805
 
 
3806
 
 
3807
 
 
3808
 
 
3809
 
 
3810
Rigney, et al.              Standards Track                    [Page 68]
 
3811
 
 
3812
RFC 2865                         RADIUS                        June 2000
 
3813
 
 
3814
 
 
3815
       1 Code = Access-Request (1)
 
3816
       1 ID = 2
 
3817
       2 Length = 57
 
3818
      16 Request Authenticator
 
3819
 
 
3820
      Attributes:
 
3821
       7 User-Name (1) = "mopsy"
 
3822
      18 User-Password (2)
 
3823
       6  NAS-IP-Address (4) = 192.168.1.16
 
3824
       6  NAS-Port (5) = 7
 
3825
 
 
3826
   The RADIUS server decides to challenge mopsy, sending back a
 
3827
   challenge string and looking for a response.  The RADIUS server
 
3828
   therefore and sends an Access-Challenge UDP packet to the NAS.
 
3829
 
 
3830
   The Response Authenticator is a 16-octet MD5 checksum of the code
 
3831
   (11), id (2), length (78), the Request Authenticator from above, the
 
3832
   attributes in this reply, and the shared secret.
 
3833
 
 
3834
   The Reply-Message is "Challenge 32769430.  Enter response at prompt."
 
3835
 
 
3836
   The State is a magic cookie to be returned along with user's
 
3837
   response; in this example 8 octets of data (33 32 37 36 39 34 33 30
 
3838
   in hex).
 
3839
 
 
3840
      0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c
 
3841
      71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20
 
3842
      33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72
 
3843
      20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f
 
3844
      6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
 
3845
 
 
3846
       1 Code = Access-Challenge (11)
 
3847
       1 ID = 2 (same as in Access-Request)
 
3848
       2 Length = 78
 
3849
      16 Response Authenticator
 
3850
 
 
3851
      Attributes:
 
3852
      48  Reply-Message (18)
 
3853
      10  State (24)
 
3854
 
 
3855
   The user enters his response, and the NAS send a new Access-Request
 
3856
   with that response, and includes the State Attribute.
 
3857
 
 
3858
   The Request Authenticator is a new 16 octet random number.
 
3859
 
 
3860
   The User-Password is 16 octets of the user's response, in this case
 
3861
   "99101462", padded at the end with nulls, XORed with MD5(shared
 
3862
   secret|Request Authenticator).
 
3863
 
 
3864
 
 
3865
 
 
3866
Rigney, et al.              Standards Track                    [Page 69]
 
3867
 
 
3868
RFC 2865                         RADIUS                        June 2000
 
3869
 
 
3870
 
 
3871
   The state is the magic cookie from the Access-Challenge packet,
 
3872
   unchanged.
 
3873
 
 
3874
      01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
 
3875
      c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
 
3876
      20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
 
3877
      a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
 
3878
      34 33 30
 
3879
 
 
3880
       1 Code = Access-Request (1)
 
3881
       1 ID = 3 (Note that this changes.)
 
3882
       2 Length = 67
 
3883
      16 Request Authenticator
 
3884
 
 
3885
      Attributes:
 
3886
       7  User-Name = "mopsy"
 
3887
      18  User-Password
 
3888
       6  NAS-IP-Address (4) = 192.168.1.16
 
3889
       6  NAS-Port (5) = 7
 
3890
      10  State (24)
 
3891
 
 
3892
   The Response was incorrect (for the sake of example), so the RADIUS
 
3893
   server tells the NAS to reject the login attempt.
 
3894
 
 
3895
   The Response Authenticator is a 16 octet MD5 checksum of the code
 
3896
   (3), id (3), length(20), the Request Authenticator from above, the
 
3897
   attributes in this reply (in this case, none), and the shared secret.
 
3898
 
 
3899
      03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f
 
3900
      9e 74 6a a0
 
3901
 
 
3902
       1 Code = Access-Reject (3)
 
3903
       1 ID = 3 (same as in Access-Request)
 
3904
       2 Length = 20
 
3905
      16 Response Authenticator
 
3906
 
 
3907
      Attributes:
 
3908
         (none, although a Reply-Message could be sent)
 
3909
 
 
3910
 
 
3911
 
 
3912
 
 
3913
 
 
3914
 
 
3915
 
 
3916
 
 
3917
 
 
3918
 
 
3919
 
 
3920
 
 
3921
 
 
3922
Rigney, et al.              Standards Track                    [Page 70]
 
3923
 
 
3924
RFC 2865                         RADIUS                        June 2000
 
3925
 
 
3926
 
 
3927
8.  Security Considerations
 
3928
 
 
3929
   Security issues are the primary topic of this document.
 
3930
 
 
3931
   In practice, within or associated with each RADIUS server, there is a
 
3932
   database which associates "user" names with authentication
 
3933
   information ("secrets").  It is not anticipated that a particular
 
3934
   named user would be authenticated by multiple methods.  This would
 
3935
   make the user vulnerable to attacks which negotiate the least secure
 
3936
   method from among a set.  Instead, for each named user there should
 
3937
   be an indication of exactly one method used to authenticate that user
 
3938
   name.  If a user needs to make use of different authentication
 
3939
   methods under different circumstances, then distinct user names
 
3940
   SHOULD be employed, each of which identifies exactly one
 
3941
   authentication method.
 
3942
 
 
3943
   Passwords and other secrets should be stored at the respective ends
 
3944
   such that access to them is as limited as possible.  Ideally, the
 
3945
   secrets should only be accessible to the process requiring access in
 
3946
   order to perform the authentication.
 
3947
 
 
3948
   The secrets should be distributed with a mechanism that limits the
 
3949
   number of entities that handle (and thus gain knowledge of) the
 
3950
   secret.  Ideally, no unauthorized person should ever gain knowledge
 
3951
   of the secrets.  It is possible to achieve this with SNMP Security
 
3952
   Protocols [14], but such a mechanism is outside the scope of this
 
3953
   specification.
 
3954
 
 
3955
   Other distribution methods are currently undergoing research and
 
3956
   experimentation.  The SNMP Security document [14] also has an
 
3957
   excellent overview of threats to network protocols.
 
3958
 
 
3959
   The User-Password hiding mechanism described in Section 5.2 has not
 
3960
   been subjected to significant amounts of cryptanalysis in the
 
3961
   published literature.  Some in the IETF community are concerned that
 
3962
   this method might not provide sufficient confidentiality protection
 
3963
   [15] to passwords transmitted using RADIUS.  Users should evaluate
 
3964
   their threat environment and consider whether additional security
 
3965
   mechanisms should be employed.
 
3966
 
 
3967
9.  Change Log
 
3968
 
 
3969
   The following changes have been made from RFC 2138:
 
3970
 
 
3971
   Strings should use UTF-8 instead of US-ASCII and should be handled as
 
3972
   8-bit data.
 
3973
 
 
3974
   Integers and dates are now defined as 32 bit unsigned values.
 
3975
 
 
3976
 
 
3977
 
 
3978
Rigney, et al.              Standards Track                    [Page 71]
 
3979
 
 
3980
RFC 2865                         RADIUS                        June 2000
 
3981
 
 
3982
 
 
3983
   Updated list of attributes that can be included in Access-Challenge
 
3984
   to be consistent with the table of attributes.
 
3985
 
 
3986
   User-Name mentions Network Access Identifiers.
 
3987
 
 
3988
   User-Name may now be sent in Access-Accept for use with accounting
 
3989
   and Rlogin.
 
3990
 
 
3991
   Values added for Service-Type, Login-Service, Framed-Protocol,
 
3992
   Framed-Compression, and NAS-Port-Type.
 
3993
 
 
3994
   NAS-Port can now use all 32 bits.
 
3995
 
 
3996
   Examples now include hexadecimal displays of the packets.
 
3997
 
 
3998
   Source UDP port must be used in conjunction with the Request
 
3999
   Identifier when identifying duplicates.
 
4000
 
 
4001
   Multiple subattributes may be allowed in a Vendor-Specific attribute.
 
4002
 
 
4003
   An Access-Request is now required to contain either a NAS-IP-Address
 
4004
   or NAS-Identifier (or may contain both).
 
4005
 
 
4006
   Added notes under "Operations" with more information on proxy,
 
4007
   retransmissions, and keep-alives.
 
4008
 
 
4009
   If multiple Attributes with the same Type are present, the order of
 
4010
   Attributes with the same Type MUST be preserved by any proxies.
 
4011
 
 
4012
   Clarified Proxy-State.
 
4013
 
 
4014
   Clarified that Attributes must not depend on position within the
 
4015
   packet, as long as Attributes of the same type are kept in order.
 
4016
 
 
4017
   Added IANA Considerations section.
 
4018
 
 
4019
   Updated section on "Proxy" under "Operations".
 
4020
 
 
4021
   Framed-MTU can now be sent in Access-Request as a hint.
 
4022
 
 
4023
   Updated Security Considerations.
 
4024
 
 
4025
   Text strings identified as a subset of string, to clarify use of
 
4026
   UTF-8.
 
4027
 
 
4028
 
 
4029
 
 
4030
 
 
4031
 
 
4032
 
 
4033
 
 
4034
Rigney, et al.              Standards Track                    [Page 72]
 
4035
 
 
4036
RFC 2865                         RADIUS                        June 2000
 
4037
 
 
4038
 
 
4039
10.  References
 
4040
 
 
4041
   [1]   Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
 
4042
         Authentication Dial In User Service (RADIUS)", RFC 2138, April
 
4043
         1997.
 
4044
 
 
4045
   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
 
4046
         Levels", BCP 14, RFC 2119, March, 1997.
 
4047
 
 
4048
   [3]   Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
 
4049
         RFC 1321, April 1992.
 
4050
 
 
4051
   [4]   Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
 
4052
         1980.
 
4053
 
 
4054
   [5]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 
4055
 
 
4056
   [6]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
 
4057
         1700, October 1994.
 
4058
 
 
4059
   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
 
4060
         2279, January 1998.
 
4061
 
 
4062
   [8]   Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
 
4063
         2486, January 1999.
 
4064
 
 
4065
   [9]   Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
 
4066
         Private Communications in a Public World", Prentice Hall, March
 
4067
         1995, ISBN 0-13-061466-1.
 
4068
 
 
4069
   [10]  Jacobson, V., "Compressing TCP/IP headers for low-speed serial
 
4070
         links", RFC 1144, February 1990.
 
4071
 
 
4072
   [11]  ISO 8859. International Standard -- Information Processing --
 
4073
         8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
 
4074
         Alphabet No. 1, ISO 8859-1:1987.
 
4075
 
 
4076
   [12]  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
 
4077
         Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
 
4078
         1996.
 
4079
 
 
4080
   [13]  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
 
4081
         Considerations Section in RFCs", BCP 26, RFC 2434, October
 
4082
         1998.
 
4083
 
 
4084
   [14]  Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security
 
4085
         Protocols", RFC 1352, July 1992.
 
4086
 
 
4087
 
 
4088
 
 
4089
 
 
4090
Rigney, et al.              Standards Track                    [Page 73]
 
4091
 
 
4092
RFC 2865                         RADIUS                        June 2000
 
4093
 
 
4094
 
 
4095
   [15]  Dobbertin, H., "The Status of MD5 After a Recent Attack",
 
4096
         CryptoBytes Vol.2 No.2, Summer 1996.
 
4097
 
 
4098
11.  Acknowledgements
 
4099
 
 
4100
   RADIUS was originally developed by Steve Willens of Livingston
 
4101
   Enterprises for their PortMaster series of Network Access Servers.
 
4102
 
 
4103
12.  Chair's Address
 
4104
 
 
4105
   The working group can be contacted via the current chair:
 
4106
 
 
4107
   Carl Rigney
 
4108
   Livingston Enterprises
 
4109
   4464 Willow Road
 
4110
   Pleasanton, California  94588
 
4111
 
 
4112
   Phone: +1 925 737 2100
 
4113
   EMail: cdr@telemancy.com
 
4114
 
 
4115
 
 
4116
 
 
4117
 
 
4118
 
 
4119
 
 
4120
 
 
4121
 
 
4122
 
 
4123
 
 
4124
 
 
4125
 
 
4126
 
 
4127
 
 
4128
 
 
4129
 
 
4130
 
 
4131
 
 
4132
 
 
4133
 
 
4134
 
 
4135
 
 
4136
 
 
4137
 
 
4138
 
 
4139
 
 
4140
 
 
4141
 
 
4142
 
 
4143
 
 
4144
 
 
4145
 
 
4146
Rigney, et al.              Standards Track                    [Page 74]
 
4147
 
 
4148
RFC 2865                         RADIUS                        June 2000
 
4149
 
 
4150
 
 
4151
13.  Authors' Addresses
 
4152
 
 
4153
   Questions about this memo can also be directed to:
 
4154
 
 
4155
   Carl Rigney
 
4156
   Livingston Enterprises
 
4157
   4464 Willow Road
 
4158
   Pleasanton, California  94588
 
4159
 
 
4160
   Phone: +1 925 737 2100
 
4161
   EMail: cdr@telemancy.com
 
4162
 
 
4163
 
 
4164
   Allan C. Rubens
 
4165
   Merit Network, Inc.
 
4166
   4251 Plymouth Road
 
4167
   Ann Arbor, Michigan  48105-2785
 
4168
 
 
4169
   EMail: acr@merit.edu
 
4170
 
 
4171
 
 
4172
   William Allen Simpson
 
4173
   Daydreamer
 
4174
   Computer Systems Consulting Services
 
4175
   1384 Fontaine
 
4176
   Madison Heights, Michigan  48071
 
4177
 
 
4178
   EMail: wsimpson@greendragon.com
 
4179
 
 
4180
 
 
4181
   Steve Willens
 
4182
   Livingston Enterprises
 
4183
   4464 Willow Road
 
4184
   Pleasanton, California  94588
 
4185
 
 
4186
   EMail: steve@livingston.com
 
4187
 
 
4188
 
 
4189
 
 
4190
 
 
4191
 
 
4192
 
 
4193
 
 
4194
 
 
4195
 
 
4196
 
 
4197
 
 
4198
 
 
4199
 
 
4200
 
 
4201
 
 
4202
Rigney, et al.              Standards Track                    [Page 75]
 
4203
 
 
4204
RFC 2865                         RADIUS                        June 2000
 
4205
 
 
4206
 
 
4207
14.  Full Copyright Statement
 
4208
 
 
4209
   Copyright (C) The Internet Society (2000).  All Rights Reserved.
 
4210
 
 
4211
   This document and translations of it may be copied and furnished to
 
4212
   others, and derivative works that comment on or otherwise explain it
 
4213
   or assist in its implementation may be prepared, copied, published
 
4214
   and distributed, in whole or in part, without restriction of any
 
4215
   kind, provided that the above copyright notice and this paragraph are
 
4216
   included on all such copies and derivative works.  However, this
 
4217
   document itself may not be modified in any way, such as by removing
 
4218
   the copyright notice or references to the Internet Society or other
 
4219
   Internet organizations, except as needed for the purpose of
 
4220
   developing Internet standards in which case the procedures for
 
4221
   copyrights defined in the Internet Standards process must be
 
4222
   followed, or as required to translate it into languages other than
 
4223
   English.
 
4224
 
 
4225
   The limited permissions granted above are perpetual and will not be
 
4226
   revoked by the Internet Society or its successors or assigns.
 
4227
 
 
4228
   This document and the information contained herein is provided on an
 
4229
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 
4230
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 
4231
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 
4232
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 
4233
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
4234
 
 
4235
Acknowledgement
 
4236
 
 
4237
   Funding for the RFC Editor function is currently provided by the
 
4238
   Internet Society.
 
4239
 
 
4240
 
 
4241
 
 
4242
 
 
4243
 
 
4244
 
 
4245
 
 
4246
 
 
4247
 
 
4248
 
 
4249
 
 
4250
 
 
4251
 
 
4252
 
 
4253
 
 
4254
 
 
4255
 
 
4256
 
 
4257
 
 
4258
Rigney, et al.              Standards Track                    [Page 76]
 
4259