7 Network Working Group C. Rigney
8 Request for Comments: 2138 Livingston
9 Obsoletes: 2058 A. Rubens
10 Category: Standards Track Merit
18 Remote Authentication Dial In User Service (RADIUS)
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 This document describes a protocol for carrying authentication,
31 authorization, and configuration information between a Network Access
32 Server which desires to authenticate its links and a shared
33 Authentication Server.
37 This memo documents the RADIUS protocol. There has been some
38 confusion in the assignment of port numbers for this protocol. The
39 early deployment of RADIUS was done using the erroneously chosen port
40 number 1645, which conflicts with the "datametrics" service. The
41 officially assigned port number for RADIUS is 1812.
45 1. Introduction .......................................... 3
46 1.1 Specification of Requirements ................... 4
47 1.2 Terminology ..................................... 5
48 2. Operation ............................................. 5
49 2.1 Challenge/Response .............................. 7
50 2.2 Interoperation with PAP and CHAP ................ 7
51 2.3 Why UDP? ........................................ 8
52 3. Packet Format ......................................... 10
53 4. Packet Types .......................................... 13
54 4.1 Access-Request .................................. 13
58 Rigney, et. al. Standards Track [Page 1]
60 RFC 2138 RADIUS April 1997
63 4.2 Access-Accept ................................... 14
64 4.3 Access-Reject ................................... 15
65 4.4 Access-Challenge ................................ 17
66 5. Attributes ............................................ 18
67 5.1 User-Name ....................................... 21
68 5.2 User-Password ................................... 22
69 5.3 CHAP-Password ................................... 23
70 5.4 NAS-IP-Address .................................. 24
71 5.5 NAS-Port ........................................ 25
72 5.6 Service-Type .................................... 26
73 5.7 Framed-Protocol ................................. 28
74 5.8 Framed-IP-Address ............................... 29
75 5.9 Framed-IP-Netmask ............................... 29
76 5.10 Framed-Routing .................................. 30
77 5.11 Filter-Id ....................................... 31
78 5.12 Framed-MTU ...................................... 32
79 5.13 Framed-Compression .............................. 33
80 5.14 Login-IP-Host ................................... 33
81 5.15 Login-Service ................................... 34
82 5.16 Login-TCP-Port .................................. 35
83 5.17 (unassigned) .................................... 36
84 5.18 Reply-Message ................................... 36
85 5.19 Callback-Number ................................. 37
86 5.20 Callback-Id ..................................... 38
87 5.21 (unassigned) .................................... 38
88 5.22 Framed-Route .................................... 39
89 5.23 Framed-IPX-Network .............................. 40
90 5.24 State ........................................... 40
91 5.25 Class ........................................... 41
92 5.26 Vendor-Specific ................................. 42
93 5.27 Session-Timeout ................................. 44
94 5.28 Idle-Timeout .................................... 44
95 5.29 Termination-Action .............................. 45
96 5.30 Called-Station-Id ............................... 46
97 5.31 Calling-Station-Id .............................. 47
98 5.32 NAS-Identifier .................................. 48
99 5.33 Proxy-State ..................................... 48
100 5.34 Login-LAT-Service ............................... 49
101 5.35 Login-LAT-Node .................................. 50
102 5.36 Login-LAT-Group ................................. 51
103 5.37 Framed-AppleTalk-Link ........................... 52
104 5.38 Framed-AppleTalk-Network ........................ 53
105 5.39 Framed-AppleTalk-Zone ........................... 54
106 5.40 CHAP-Challenge .................................. 55
107 5.41 NAS-Port-Type ................................... 55
108 5.42 Port-Limit ...................................... 56
109 5.43 Login-LAT-Port .................................. 57
110 5.44 Table of Attributes ............................. 58
114 Rigney, et. al. Standards Track [Page 2]
116 RFC 2138 RADIUS April 1997
119 6. Examples .............................................. 59
120 6.1 User Telnet to Specified Host ................... 60
121 6.2 Framed User Authenticating with CHAP ............ 60
122 6.3 User with Challenge-Response card ............... 61
123 Security Considerations ...................................... 63
124 References ................................................... 64
125 Acknowledgements ............................................. 64
126 Chair's Address .............................................. 65
127 Author's Addresses ........................................... 65
131 Managing dispersed serial line and modem pools for large numbers of
132 users can create the need for significant administrative support.
133 Since modem pools are by definition a link to the outside world, they
134 require careful attention to security, authorization and accounting.
135 This can be best achieved by managing a single "database" of users,
136 which allows for authentication (verifying user name and password) as
137 well as configuration information detailing the type of service to
138 deliver to the user (for example, SLIP, PPP, telnet, rlogin).
140 Key features of RADIUS are:
144 A Network Access Server (NAS) operates as a client of RADIUS. The
145 client is responsible for passing user information to designated
146 RADIUS servers, and then acting on the response which is returned.
148 RADIUS servers are responsible for receiving user connection
149 requests, authenticating the user, and then returning all
150 configuration information necessary for the client to deliver
153 A RADIUS server can act as a proxy client to other RADIUS servers
154 or other kinds of authentication servers.
158 Transactions between the client and RADIUS server are
159 authenticated through the use of a shared secret, which is never
160 sent over the network. In addition, any user passwords are sent
161 encrypted between the client and RADIUS server, to eliminate the
162 possibility that someone snooping on an unsecure network could
163 determine a user's password.
170 Rigney, et. al. Standards Track [Page 3]
172 RFC 2138 RADIUS April 1997
175 Flexible Authentication Mechanisms
177 The RADIUS server can support a variety of methods to authenticate
178 a user. When it is provided with the user name and original
179 password given by the user, it can support PPP PAP or CHAP, UNIX
180 login, and other authentication mechanisms.
184 All transactions are comprised of variable length Attribute-
185 Length-Value 3-tuples. New attribute values can be added without
186 disturbing existing implementations of the protocol.
188 1.1. Specification of Requirements
190 In this document, several words are used to signify the requirements
191 of the specification. These words are often capitalized.
193 MUST This word, or the adjective "required", means that the
194 definition is an absolute requirement of the specification.
196 MUST NOT This phrase means that the definition is an absolute
197 prohibition of the specification.
199 SHOULD This word, or the adjective "recommended", means that there
200 may exist valid reasons in particular circumstances to
201 ignore this item, but the full implications must be
202 understood and carefully weighed before choosing a
205 MAY This word, or the adjective "optional", means that this
206 item is one of an allowed set of alternatives. An
207 implementation which does not include this option MUST be
208 prepared to interoperate with another implementation which
209 does include the option.
226 Rigney, et. al. Standards Track [Page 4]
228 RFC 2138 RADIUS April 1997
233 This document frequently uses the following terms:
235 service The NAS provides a service to the dial-in user, such as PPP
238 session Each service provided by the NAS to a dial-in user
239 constitutes a session, with the beginning of the session
240 defined as the point where service is first provided and
241 the end of the session defined as the point where service
242 is ended. A user may have multiple sessions in parallel or
243 series if the NAS supports that.
246 This means the implementation discards the packet without
247 further processing. The implementation SHOULD provide the
248 capability of logging the error, including the contents of
249 the silently discarded packet, and SHOULD record the event
250 in a statistics counter.
254 When a client is configured to use RADIUS, any user of the client
255 presents authentication information to the client. This might be
256 with a customizable login prompt, where the user is expected to enter
257 their username and password. Alternatively, the user might use a
258 link framing protocol such as the Point-to-Point Protocol (PPP),
259 which has authentication packets which carry this information.
261 Once the client has obtained such information, it may choose to
262 authenticate using RADIUS. To do so, the client creates an "Access-
263 Request" containing such Attributes as the user's name, the user's
264 password, the ID of the client and the Port ID which the user is
265 accessing. When a password is present, it is hidden using a method
266 based on the RSA Message Digest Algorithm MD5 [1].
268 The Access-Request is submitted to the RADIUS server via the network.
269 If no response is returned within a length of time, the request is
270 re-sent a number of times. The client can also forward requests to
271 an alternate server or servers in the event that the primary server
272 is down or unreachable. An alternate server can be used either after
273 a number of tries to the primary server fail, or in a round-robin
274 fashion. Retry and fallback algorithms are the topic of current
275 research and are not specified in detail in this document.
282 Rigney, et. al. Standards Track [Page 5]
284 RFC 2138 RADIUS April 1997
287 Once the RADIUS server receives the request, it validates the sending
288 client. A request from a client for which the RADIUS server does not
289 have a shared secret should be silently discarded. If the client is
290 valid, the RADIUS server consults a database of users to find the
291 user whose name matches the request. The user entry in the database
292 contains a list of requirements which must be met to allow access for
293 the user. This always includes verification of the password, but can
294 also specify the client(s) or port(s) to which the user is allowed
297 The RADIUS server MAY make requests of other servers in order to
298 satisfy the request, in which case it acts as a client.
300 If any condition is not met, the RADIUS server sends an "Access-
301 Reject" response indicating that this user request is invalid. If
302 desired, the server MAY include a text message in the Access-Reject
303 which MAY be displayed by the client to the user. No other
304 Attributes are permitted in an Access-Reject.
306 If all conditions are met and the RADIUS server wishes to issue a
307 challenge to which the user must respond, the RADIUS server sends an
308 "Access-Challenge" response. It MAY include a text message to be
309 displayed by the client to the user prompting for a response to the
310 challenge, and MAY include a State attribute. If the client receives
311 an Access-Challenge and supports challenge/response it MAY display
312 the text message, if any, to the user, and then prompt the user for a
313 response. The client then re-submits its original Access-Request
314 with a new request ID, with the User-Password Attribute replaced by
315 the response (encrypted), and including the State Attribute from the
316 Access-Challenge, if any. Only 0 or 1 instances of the State
317 Attributes should be present in a request. The server can respond to
318 this new Access-Request with either an Access-Accept, an Access-
319 Reject, or another Access-Challenge.
321 If all conditions are met, the list of configuration values for the
322 user are placed into an "Access-Accept" response. These values
323 include the type of service (for example: SLIP, PPP, Login User) and
324 all necessary values to deliver the desired service. For SLIP and
325 PPP, this may include values such as IP address, subnet mask, MTU,
326 desired compression, and desired packet filter identifiers. For
327 character mode users, this may include values such as desired
338 Rigney, et. al. Standards Track [Page 6]
340 RFC 2138 RADIUS April 1997
343 2.1. Challenge/Response
345 In challenge/response authentication, the user is given an
346 unpredictable number and challenged to encrypt it and give back the
347 result. Authorized users are equipped with special devices such as
348 smart cards or software that facilitate calculation of the correct
349 response with ease. Unauthorized users, lacking the appropriate
350 device or software and lacking knowledge of the secret key necessary
351 to emulate such a device or software, can only guess at the response.
353 The Access-Challenge packet typically contains a Reply-Message
354 including a challenge to be displayed to the user, such as a numeric
355 value unlikely ever to be repeated. Typically this is obtained from
356 an external server that knows what type of authenticator should be in
357 the possession of the authorized user and can therefore choose a
358 random or non-repeating pseudorandom number of an appropriate radix
361 The user then enters the challenge into his device (or software) and
362 it calculates a response, which the user enters into the client which
363 forwards it to the RADIUS server via a second Access-Request. If the
364 response matches the expected response the RADIUS server replies with
365 an Access-Accept, otherwise an Access-Reject.
367 Example: The NAS sends an Access-Request packet to the RADIUS Server
368 with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
369 just be a fixed string like "challenge" or ignored). The server
370 sends back an Access-Challenge packet with State and a Reply-Message
371 along the lines of "Challenge 12345678, enter your response at the
372 prompt" which the NAS displays. The NAS prompts for the response and
373 sends a NEW Access-Request to the server (with a new ID) with NAS-
374 Identifier, NAS-Port, User-Name, User-Password (the response just
375 entered by the user, encrypted), and the same State Attribute that
376 came with the Access-Challenge. The server then sends back either an
377 Access-Accept or Access-Reject based on whether the response matches
378 what it should be, or it can even send another Access-Challenge.
380 2.2. Interoperation with PAP and CHAP
382 For PAP, the NAS takes the PAP ID and password and sends them in an
383 Access-Request packet as the User-Name and User-Password. The NAS MAY
384 include the Attributes Service-Type = Framed-User and Framed-Protocol
385 = PPP as a hint to the RADIUS server that PPP service is expected.
387 For CHAP, the NAS generates a random challenge (preferably 16 octets)
388 and sends it to the user, who returns a CHAP response along with a
389 CHAP ID and CHAP username. The NAS then sends an Access-Request
390 packet to the RADIUS server with the CHAP username as the User-Name
394 Rigney, et. al. Standards Track [Page 7]
396 RFC 2138 RADIUS April 1997
399 and with the CHAP ID and CHAP response as the CHAP-Password
400 (Attribute 3). The random challenge can either be included in the
401 CHAP-Challenge attribute or, if it is 16 octets long, it can be
402 placed in the Request Authenticator field of the Access-Request
403 packet. The NAS MAY include the Attributes Service-Type = Framed-
404 User and Framed-Protocol = PPP as a hint to the RADIUS server that
405 PPP service is expected.
407 The RADIUS server looks up a password based on the User-Name,
408 encrypts the challenge using MD5 on the CHAP ID octet, that password,
409 and the CHAP challenge (from the CHAP-Challenge attribute if present,
410 otherwise from the Request Authenticator), and compares that result
411 to the CHAP-Password. If they match, the server sends back an
412 Access-Accept, otherwise it sends back an Access-Reject.
414 If the RADIUS server is unable to perform the requested
415 authentication it should return an Access-Reject. For example, CHAP
416 requires that the user's password be available in cleartext to the
417 server so that it can encrypt the CHAP challenge and compare that to
418 the CHAP response. If the password is not available in cleartext to
419 the RADIUS server then the server MUST send an Access-Reject to the
424 A frequently asked question is why RADIUS uses UDP instead of TCP as
425 a transport protocol. UDP was chosen for strictly technical reasons.
427 There are a number of issues which must be understood. RADIUS is a
428 transaction based protocol which has several interesting
431 1. If the request to a primary Authentication server fails, a
432 secondary server must be queried.
434 To meet this requirement, a copy of the request must be kept
435 above the transport layer to allow for alternate transmission.
436 This means that retransmission timers are still required.
438 2. The timing requirements of this particular protocol are
439 significantly different than TCP provides.
441 At one extreme, RADIUS does not require a "responsive"
442 detection of lost data. The user is willing to wait several
443 seconds for the authentication to complete. The generally
444 aggressive TCP retransmission (based on average round trip
445 time) is not required, nor is the acknowledgement overhead of
450 Rigney, et. al. Standards Track [Page 8]
452 RFC 2138 RADIUS April 1997
455 At the other extreme, the user is not willing to wait several
456 minutes for authentication. Therefore the reliable delivery of
457 TCP data two minutes later is not useful. The faster use of an
458 alternate server allows the user to gain access before giving
461 3. The stateless nature of this protocol simplifies the use of UDP.
463 Clients and servers come and go. Systems are rebooted, or are
464 power cycled independently. Generally this does not cause a
465 problem and with creative timeouts and detection of lost TCP
466 connections, code can be written to handle anomalous events.
467 UDP however completely eliminates any of this special handling.
468 Each client and server can open their UDP transport just once
469 and leave it open through all types of failure events on the
472 4. UDP simplifies the server implementation.
474 In the earliest implementations of RADIUS, the server was
475 single threaded. This means that a single request was
476 received, processed, and returned. This was found to be
477 unmanageable in environments where the back-end security
478 mechanism took real time (1 or more seconds). The server
479 request queue would fill and in environments where hundreds of
480 people were being authenticated every minute, the request
481 turn-around time increased to longer that users were willing to
482 wait (this was especially severe when a specific lookup in a
483 database or over DNS took 30 or more seconds). The obvious
484 solution was to make the server multi-threaded. Achieving this
485 was simple with UDP. Separate processes were spawned to serve
486 each request and these processes could respond directly to the
487 client NAS with a simple UDP packet to the original transport
490 It's not all a panacea. As noted, using UDP requires one thing
491 which is built into TCP: with UDP we must artificially manage
492 retransmission timers to the same server, although they don't
493 require the same attention to timing provided by TCP. This one
494 penalty is a small price to pay for the advantages of UDP in
497 Without TCP we would still probably be using tin cans connected
498 by string. But for this particular protocol, UDP is a better
506 Rigney, et. al. Standards Track [Page 9]
508 RFC 2138 RADIUS April 1997
513 Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
514 where the UDP Destination Port field indicates 1812 (decimal).
516 When a reply is generated, the source and destination ports are
519 This memo documents the RADIUS protocol. There has been some
520 confusion in the assignment of port numbers for this protocol. The
521 early deployment of RADIUS was done using the erroneously chosen port
522 number 1645, which conflicts with the "datametrics" service. The
523 officially assigned port number for RADIUS is 1812.
525 A summary of the RADIUS data format is shown below. The fields are
526 transmitted from left to right.
529 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
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531 | Code | Identifier | Length |
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
539 +-+-+-+-+-+-+-+-+-+-+-+-+-
543 The Code field is one octet, and identifies the type of RADIUS
544 packet. When a packet is received with an invalid Code field, it is
547 RADIUS Codes (decimal) are assigned as follows:
553 5 Accounting-Response
555 12 Status-Server (experimental)
556 13 Status-Client (experimental)
562 Rigney, et. al. Standards Track [Page 10]
564 RFC 2138 RADIUS April 1997
567 Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
568 are not further mentioned here. Codes 12 and 13 are reserved for
569 possible use, but are not further mentioned here.
573 The Identifier field is one octet, and aids in matching requests and
578 The Length field is two octets. It indicates the length of the
579 packet including the Code, Identifier, Length, Authenticator and
580 Attribute fields. Octets outside the range of the Length field
581 should be treated as padding and should be ignored on reception. If
582 the packet is shorter than the Length field indicates, it should be
583 silently discarded. The minimum length is 20 and maximum length is
588 The Authenticator field is sixteen (16) octets. The most significant
589 octet is transmitted first. This value is used to authenticate the
590 reply from the RADIUS server, and is used in the password hiding
593 Request Authenticator
595 In Access-Request Packets, the Authenticator value is a 16 octet
596 random number, called the Request Authenticator. The value SHOULD
597 be unpredictable and unique over the lifetime of a secret (the
598 password shared between the client and the RADIUS server), since
599 repetition of a request value in conjunction with the same secret
600 would permit an attacker to reply with a previously intercepted
601 response. Since it is expected that the same secret MAY be used
602 to authenticate with servers in disparate geographic regions, the
603 Request Authenticator field SHOULD exhibit global and temporal
606 The Request Authenticator value in an Access-Request packet SHOULD
607 also be unpredictable, lest an attacker trick a server into
608 responding to a predicted future request, and then use the
609 response to masquerade as that server to a future Access-Request.
618 Rigney, et. al. Standards Track [Page 11]
620 RFC 2138 RADIUS April 1997
623 Although protocols such as RADIUS are incapable of protecting
624 against theft of an authenticated session via realtime active
625 wiretapping attacks, generation of unique unpredictable requests
626 can protect against a wide range of active attacks against
629 The NAS and RADIUS server share a secret. That shared secret
630 followed by the Request Authenticator is put through a one-way MD5
631 hash to create a 16 octet digest value which is xored with the
632 password entered by the user, and the xored result placed in the
633 User-Password attribute in the Access-Request packet. See the
634 entry for User-Password in the section on Attributes for a more
635 detailed description.
637 Response Authenticator
639 The value of the Authenticator field in Access-Accept, Access-
640 Reject, and Access-Challenge packets is called the Response
641 Authenticator, and contains a one-way MD5 hash calculated over a
642 stream of octets consisting of: the RADIUS packet, beginning with
643 the Code field, including the Identifier, the Length, the Request
644 Authenticator field from the Access-Request packet, and the
645 response Attributes, followed by the shared secret. That is,
646 ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
647 where + denotes concatenation.
651 The secret (password shared between the client and the RADIUS server)
652 SHOULD be at least as large and unguessable as a well-chosen
653 password. It is preferred that the secret be at least 16 octets.
654 This is to ensure a sufficiently large range for the secret to
655 provide protection against exhaustive search attacks. A RADIUS
656 server SHOULD use the source IP address of the RADIUS UDP packet to
657 decide which shared secret to use, so that RADIUS requests can be
660 When using a forwarding proxy, the proxy must be able to alter the
661 packet as it passes through in each direction - when the proxy
662 forwards the request, the proxy can add a Proxy-State Attribute, and
663 when the proxy forwards a response, it removes the Proxy-State
664 Attribute. Since Access-Accept and Access-Reject replies are
665 authenticated on the entire packet contents, the stripping of the
666 Proxy-State attribute would invalidate the signature in the packet -
667 so the proxy has to re-sign it.
669 Further details of RADIUS proxy implementation are outside the scope
674 Rigney, et. al. Standards Track [Page 12]
676 RFC 2138 RADIUS April 1997
681 Many Attributes may have multiple instances, in such a case the order
682 of Attributes of the same Type SHOULD be preserved. The order of
683 Attributes of different Types is not required to be preserved.
685 In the section below on "Attributes" where the text refers to which
686 packets an attribute is allowed in, only packets with Codes 1, 2, 3
687 and 11 and attributes defined in this document are covered in this
688 document. A summary table is provided at the end of the "Attributes"
689 section. To determine which Attributes are allowed in packets with
690 codes 4 and 5 refer to the RADIUS Accounting document [9].
694 The RADIUS Packet type is determined by the Code field in the first
701 Access-Request packets are sent to a RADIUS server, and convey
702 information used to determine whether a user is allowed access to
703 a specific NAS, and any special services requested for that user.
704 An implementation wishing to authenticate a user MUST transmit a
705 RADIUS packet with the Code field set to 1 (Access-Request).
707 Upon receipt of an Access-Request from a valid client, an
708 appropriate reply MUST be transmitted.
710 An Access-Request MUST contain a User-Name attribute. It SHOULD
711 contain either a NAS-IP-Address attribute or NAS-Identifier
712 attribute (or both, although that is not recommended). It MUST
713 contain either a User-Password attribute or CHAP-Password
714 attribute. It SHOULD contain a NAS-Port or NAS-Port-Type
715 attribute or both unless the type of access being requested does
716 not involve a port or the NAS does not distinguish among its
719 An Access-Request MAY contain additional attributes as a hint to
720 the server, but the server is not required to honor the hint.
722 When a User-Password is present, it is hidden using a method based
723 on the RSA Message Digest Algorithm MD5 [1].
725 A summary of the Access-Request packet format is shown below. The
726 fields are transmitted from left to right.
730 Rigney, et. al. Standards Track [Page 13]
732 RFC 2138 RADIUS April 1997
736 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
737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
738 | Code | Identifier | Length |
739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
741 | Request Authenticator |
744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
746 +-+-+-+-+-+-+-+-+-+-+-+-+-
750 1 for Access-Request.
754 The Identifier field MUST be changed whenever the content of the
755 Attributes field changes, and whenever a valid reply has been
756 received for a previous request. For retransmissions, the
757 Identifier MUST remain unchanged.
759 Request Authenticator
761 The Request Authenticator value MUST be changed each time a new
766 The Attribute field is variable in length, and contains the list
767 of Attributes that are required for the type of service, as well
768 as any desired optional Attributes.
774 Access-Accept packets are sent by the RADIUS server, and provide
775 specific configuration information necessary to begin delivery of
776 service to the user. If all Attribute values received in an
777 Access-Request are acceptable then the RADIUS implementation MUST
778 transmit a packet with the Code field set to 2 (Access-Accept).
786 Rigney, et. al. Standards Track [Page 14]
788 RFC 2138 RADIUS April 1997
791 On reception of an Access-Accept, the Identifier field is matched
792 with a pending Access-Request. Additionally, the Response
793 Authenticator field MUST contain the correct response for the
794 pending Access-Request. Invalid packets are silently discarded.
796 A summary of the Access-Accept packet format is shown below. The
797 fields are transmitted from left to right.
800 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
801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 | Code | Identifier | Length |
803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
805 | Response Authenticator |
808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
810 +-+-+-+-+-+-+-+-+-+-+-+-+-
818 The Identifier field is a copy of the Identifier field of the
819 Access-Request which caused this Access-Accept.
821 Response Authenticator
823 The Response Authenticator value is calculated from the Access-
824 Request value, as described earlier.
828 The Attribute field is variable in length, and contains a list of
829 zero or more Attributes.
842 Rigney, et. al. Standards Track [Page 15]
844 RFC 2138 RADIUS April 1997
851 If any value of the received Attributes is not acceptable, then
852 the RADIUS server MUST transmit a packet with the Code field set
853 to 3 (Access-Reject). It MAY include one or more Reply-Message
854 Attributes with a text message which the NAS MAY display to the
857 A summary of the Access-Reject packet format is shown below. The
858 fields are transmitted from left to right.
861 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
862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
863 | Code | Identifier | Length |
864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866 | Response Authenticator |
869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
871 +-+-+-+-+-+-+-+-+-+-+-+-+-
879 The Identifier field is a copy of the Identifier field of the
880 Access-Request which caused this Access-Reject.
882 Response Authenticator
884 The Response Authenticator value is calculated from the Access-
885 Request value, as described earlier.
889 The Attribute field is variable in length, and contains a list of
890 zero or more Attributes.
898 Rigney, et. al. Standards Track [Page 16]
900 RFC 2138 RADIUS April 1997
903 4.4. Access-Challenge
907 If the RADIUS server desires to send the user a challenge
908 requiring a response, then the RADIUS server MUST respond to the
909 Access-Request by transmitting a packet with the Code field set to
910 11 (Access-Challenge).
912 The Attributes field MAY have one or more Reply-Message
913 Attributes, and MAY have a single State Attribute, or none. No
914 other Attributes are permitted in an Access-Challenge.
916 On receipt of an Access-Challenge, the Identifier field is matched
917 with a pending Access-Request. Additionally, the Response
918 Authenticator field MUST contain the correct response for the
919 pending Access-Request. Invalid packets are silently discarded.
921 If the NAS does not support challenge/response, it MUST treat an
922 Access-Challenge as though it had received an Access-Reject
925 If the NAS supports challenge/response, receipt of a valid
926 Access-Challenge indicates that a new Access-Request SHOULD be
927 sent. The NAS MAY display the text message, if any, to the user,
928 and then prompt the user for a response. It then sends its
929 original Access-Request with a new request ID and Request
930 Authenticator, with the User-Password Attribute replaced by the
931 user's response (encrypted), and including the State Attribute
932 from the Access-Challenge, if any. Only 0 or 1 instances of the
933 State Attribute can be present in an Access-Request.
935 A NAS which supports PAP MAY forward the Reply-Message to the
936 dialin client and accept a PAP response which it can use as though
937 the user had entered the response. If the NAS cannot do so, it
938 should treat the Access-Challenge as though it had received an
939 Access-Reject instead.
954 Rigney, et. al. Standards Track [Page 17]
956 RFC 2138 RADIUS April 1997
959 A summary of the Access-Challenge packet format is shown below. The
960 fields are transmitted from left to right.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
968 | Response Authenticator |
971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
973 +-+-+-+-+-+-+-+-+-+-+-+-+-
977 11 for Access-Challenge.
981 The Identifier field is a copy of the Identifier field of the
982 Access-Request which caused this Access-Challenge.
984 Response Authenticator
986 The Response Authenticator value is calculated from the Access-
987 Request value, as described earlier.
991 The Attributes field is variable in length, and contains a list of
992 zero or more Attributes.
996 RADIUS Attributes carry the specific authentication, authorization,
997 information and configuration details for the request and reply.
999 Some Attributes MAY be included more than once. The effect of this
1000 is Attribute specific, and is specified in each Attribute
1003 The end of the list of Attributes is indicated by the Length of the
1010 Rigney, et. al. Standards Track [Page 18]
1012 RFC 2138 RADIUS April 1997
1015 A summary of the Attribute format is shown below. The fields are
1016 transmitted from left to right.
1019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1021 | Type | Length | Value ...
1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1026 The Type field is one octet. Up-to-date values of the RADIUS Type
1027 field are specified in the most recent "Assigned Numbers" RFC [3].
1028 Values 192-223 are reserved for experimental use, values 224-240
1029 are reserved for implementation-specific use, and values 241-255
1030 are reserved and should not be used. This specification concerns
1031 the following values:
1033 A RADIUS server MAY ignore Attributes with an unknown Type.
1035 A RADIUS client MAY ignore Attributes with an unknown Type.
1049 13 Framed-Compression
1059 23 Framed-IPX-Network
1066 Rigney, et. al. Standards Track [Page 19]
1068 RFC 2138 RADIUS April 1997
1073 29 Termination-Action
1074 30 Called-Station-Id
1075 31 Calling-Station-Id
1078 34 Login-LAT-Service
1081 37 Framed-AppleTalk-Link
1082 38 Framed-AppleTalk-Network
1083 39 Framed-AppleTalk-Zone
1084 40-59 (reserved for accounting)
1092 The Length field is one octet, and indicates the length of this
1093 Attribute including the Type, Length and Value fields. If an
1094 Attribute is received in an Access-Request but with an invalid
1095 Length, an Access-Reject SHOULD be transmitted. If an Attribute
1096 is received in an Access-Accept, Access-Reject or Access-Challenge
1097 packet with an invalid length, the packet MUST either be treated
1098 an Access-Reject or else silently discarded.
1102 The Value field is zero or more octets and contains information
1103 specific to the Attribute. The format and length of the Value
1104 field is determined by the Type and Length fields.
1106 Note that a "string" in RADIUS does not require termination by an
1107 ASCII NUL because the Attribute already has a length field.
1122 Rigney, et. al. Standards Track [Page 20]
1124 RFC 2138 RADIUS April 1997
1127 The format of the value field is one of four data types.
1131 address 32 bit value, most significant octet first.
1133 integer 32 bit value, most significant octet first.
1135 time 32 bit value, most significant octet first -- seconds
1136 since 00:00:00 GMT, January 1, 1970. The standard
1137 Attributes do not use this data type but it is presented
1138 here for possible use within Vendor-Specific attributes.
1145 This Attribute indicates the name of the user to be authenticated.
1146 It is only used in Access-Request packets.
1148 A summary of the User-Name Attribute format is shown below. The
1149 fields are transmitted from left to right.
1152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1154 | Type | Length | String ...
1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1167 The String field is one or more octets. The NAS may limit the
1168 maximum length of the User-Name but the ability to handle at least
1169 63 octets is recommended.
1178 Rigney, et. al. Standards Track [Page 21]
1180 RFC 2138 RADIUS April 1997
1183 The format of the username MAY be one of several forms:
1185 monolithic Consisting only of alphanumeric characters. This
1186 simple form might be used to locally manage a NAS.
1188 simple Consisting only of printable ASCII characters.
1190 name@fqdn SMTP address. The Fully Qualified Domain Name (with or
1191 without trailing dot) indicates the realm in which the
1195 A name in ASN.1 form used in Public Key authentication
1202 This Attribute indicates the password of the user to be
1203 authenticated, or the user's input following an Access-Challenge.
1204 It is only used in Access-Request packets.
1206 On transmission, the password is hidden. The password is first
1207 padded at the end with nulls to a multiple of 16 octets. A one-
1208 way MD5 hash is calculated over a stream of octets consisting of
1209 the shared secret followed by the Request Authenticator. This
1210 value is XORed with the first 16 octet segment of the password and
1211 placed in the first 16 octets of the String field of the User-
1214 If the password is longer than 16 characters, a second one-way MD5
1215 hash is calculated over a stream of octets consisting of the
1216 shared secret followed by the result of the first xor. That hash
1217 is XORed with the second 16 octet segment of the password and
1218 placed in the second 16 octets of the String field of the User-
1221 If necessary, this operation is repeated, with each xor result
1222 being used along with the shared secret to generate the next hash
1223 to xor the next segment of the password, to no more than 128
1226 The method is taken from the book "Network Security" by Kaufman,
1227 Perlman and Speciner [4] pages 109-110. A more precise
1228 explanation of the method follows:
1234 Rigney, et. al. Standards Track [Page 22]
1236 RFC 2138 RADIUS April 1997
1239 Call the shared secret S and the pseudo-random 128-bit Request
1240 Authenticator RA. Break the password into 16-octet chunks p1, p2,
1241 etc. with the last one padded at the end with nulls to a 16-octet
1242 boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
1243 intermediate values b1, b2, etc.
1245 b1 = MD5(S + RA) c(1) = p1 xor b1
1246 b2 = MD5(S + c(1)) c(2) = p2 xor b2
1250 bi = MD5(S + c(i-1)) c(i) = pi xor bi
1252 The String will contain c(1)+c(2)+...+c(i) where + denotes
1255 On receipt, the process is reversed to yield the original
1258 A summary of the User-Password Attribute format is shown below. The
1259 fields are transmitted from left to right.
1262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1264 | Type | Length | String ...
1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1269 2 for User-Password.
1273 At least 18 and no larger than 130.
1277 The String field is between 16 and 128 octets long, inclusive.
1283 This Attribute indicates the response value provided by a PPP
1284 Challenge-Handshake Authentication Protocol (CHAP) user in
1285 response to the challenge. It is only used in Access-Request
1290 Rigney, et. al. Standards Track [Page 23]
1292 RFC 2138 RADIUS April 1997
1295 The CHAP challenge value is found in the CHAP-Challenge Attribute
1296 (60) if present in the packet, otherwise in the Request
1297 Authenticator field.
1299 A summary of the CHAP-Password Attribute format is shown below. The
1300 fields are transmitted from left to right.
1303 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
1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1305 | Type | Length | CHAP Ident | String ...
1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1310 3 for CHAP-Password.
1318 This field is one octet, and contains the CHAP Identifier from the
1319 user's CHAP Response.
1323 The String field is 16 octets, and contains the CHAP Response from
1330 This Attribute indicates the identifying IP Address of the NAS
1331 which is requesting authentication of the user. It is only used
1332 in Access-Request packets. Either NAS-IP-Address or NAS-
1333 Identifier SHOULD be present in an Access-Request packet.
1346 Rigney, et. al. Standards Track [Page 24]
1348 RFC 2138 RADIUS April 1997
1351 A summary of the NAS-IP-Address Attribute format is shown below. The
1352 fields are transmitted from left to right.
1355 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
1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1357 | Type | Length | Address
1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1364 4 for NAS-IP-Address.
1372 The Address field is four octets.
1378 This Attribute indicates the physical port number of the NAS which
1379 is authenticating the user. It is only used in Access-Request
1380 packets. Note that this is using "port" in its sense of a
1381 physical connection on the NAS, not in the sense of a TCP or UDP
1382 port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
1383 be present in an Access-Request packet, if the NAS differentiates
1386 A summary of the NAS-Port Attribute format is shown below. The
1387 fields are transmitted from left to right.
1402 Rigney, et. al. Standards Track [Page 25]
1404 RFC 2138 RADIUS April 1997
1408 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
1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1410 | Type | Length | Value
1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1425 The Value field is four octets. Despite the size of the field,
1426 values range from 0 to 65535.
1432 This Attribute indicates the type of service the user has
1433 requested, or the type of service to be provided. It MAY be used
1434 in both Access-Request and Access-Accept packets. A NAS is not
1435 required to implement all of these service types, and MUST treat
1436 unknown or unsupported Service-Types as though an Access-Reject
1437 had been received instead.
1439 A summary of the Service-Type Attribute format is shown below. The
1440 fields are transmitted from left to right.
1443 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
1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1445 | Type | Length | Value
1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1458 Rigney, et. al. Standards Track [Page 26]
1460 RFC 2138 RADIUS April 1997
1469 The Value field is four octets.
1479 9 Callback NAS Prompt
1482 The service types are defined as follows when used in an Access-
1483 Accept. When used in an Access-Request, they should be considered
1484 to be a hint to the RADIUS server that the NAS has reason to
1485 believe the user would prefer the kind of service indicated, but
1486 the server is not required to honor the hint.
1488 Login The user should be connected to a host.
1490 Framed A Framed Protocol should be started for the
1491 User, such as PPP or SLIP.
1493 Callback Login The user should be disconnected and called
1494 back, then connected to a host.
1496 Callback Framed The user should be disconnected and called
1497 back, then a Framed Protocol should be started
1498 for the User, such as PPP or SLIP.
1500 Outbound The user should be granted access to outgoing
1503 Administrative The user should be granted access to the
1504 administrative interface to the NAS from which
1505 privileged commands can be executed.
1507 NAS Prompt The user should be provided a command prompt
1508 on the NAS from which non-privileged commands
1514 Rigney, et. al. Standards Track [Page 27]
1516 RFC 2138 RADIUS April 1997
1519 Authenticate Only Only Authentication is requested, and no
1520 authorization information needs to be returned
1521 in the Access-Accept (typically used by proxy
1522 servers rather than the NAS itself).
1524 Callback NAS Prompt The user should be disconnected and called
1525 back, then provided a command prompt on the
1526 NAS from which non-privileged commands can be
1529 5.7. Framed-Protocol
1533 This Attribute indicates the framing to be used for framed access.
1534 It MAY be used in both Access-Request and Access-Accept packets.
1536 A summary of the Framed-Protocol Attribute format is shown below.
1537 The fields are transmitted from left to right.
1540 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
1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1542 | Type | Length | Value
1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1549 7 for Framed-Protocol.
1557 The Value field is four octets.
1561 3 AppleTalk Remote Access Protocol (ARAP)
1562 4 Gandalf proprietary SingleLink/MultiLink protocol
1563 5 Xylogics proprietary IPX/SLIP
1570 Rigney, et. al. Standards Track [Page 28]
1572 RFC 2138 RADIUS April 1997
1575 5.8. Framed-IP-Address
1579 This Attribute indicates the address to be configured for the
1580 user. It MAY be used in Access-Accept packets. It MAY be used in
1581 an Access-Request packet as a hint by the NAS to the server that
1582 it would prefer that address, but the server is not required to
1585 A summary of the Framed-IP-Address Attribute format is shown below.
1586 The fields are transmitted from left to right.
1589 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
1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1591 | Type | Length | Address
1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1598 8 for Framed-IP-Address.
1606 The Address field is four octets. The value 0xFFFFFFFF indicates
1607 that the NAS should allow the user to select an address (e.g.
1608 Negotiated). The value 0xFFFFFFFE indicates that the NAS should
1609 select an address for the user (e.g. Assigned from a pool of
1610 addresses kept by the NAS). Other valid values indicate that the
1611 NAS should use that value as the user's IP address.
1613 5.9. Framed-IP-Netmask
1617 This Attribute indicates the IP netmask to be configured for the
1618 user when the user is a router to a network. It MAY be used in
1619 Access-Accept packets. It MAY be used in an Access-Request packet
1620 as a hint by the NAS to the server that it would prefer that
1621 netmask, but the server is not required to honor the hint.
1626 Rigney, et. al. Standards Track [Page 29]
1628 RFC 2138 RADIUS April 1997
1631 A summary of the Framed-IP-Netmask Attribute format is shown below.
1632 The fields are transmitted from left to right.
1635 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
1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1637 | Type | Length | Address
1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1644 9 for Framed-IP-Netmask.
1652 The Address field is four octets specifying the IP netmask of the
1655 5.10. Framed-Routing
1659 This Attribute indicates the routing method for the user, when the
1660 user is a router to a network. It is only used in Access-Accept
1663 A summary of the Framed-Routing Attribute format is shown below. The
1664 fields are transmitted from left to right.
1667 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
1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1669 | Type | Length | Value
1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1676 10 for Framed-Routing.
1682 Rigney, et. al. Standards Track [Page 30]
1684 RFC 2138 RADIUS April 1997
1693 The Value field is four octets.
1696 1 Send routing packets
1697 2 Listen for routing packets
1704 This Attribute indicates the name of the filter list for this
1705 user. Zero or more Filter-Id attributes MAY be sent in an
1706 Access-Accept packet.
1708 Identifying a filter list by name allows the filter to be used on
1709 different NASes without regard to filter-list implementation
1712 A summary of the Filter-Id Attribute format is shown below. The
1713 fields are transmitted from left to right.
1716 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1718 | Type | Length | String ...
1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1738 Rigney, et. al. Standards Track [Page 31]
1740 RFC 2138 RADIUS April 1997
1745 The String field is one or more octets, and its contents are
1746 implementation dependent. It is intended to be human readable and
1747 MUST NOT affect operation of the protocol. It is recommended that
1748 the message contain displayable ASCII characters from the range 32
1749 through 126 decimal.
1755 This Attribute indicates the Maximum Transmission Unit to be
1756 configured for the user, when it is not negotiated by some other
1757 means (such as PPP). It is only used in Access-Accept packets.
1759 A summary of the Framed-MTU Attribute format is shown below. The
1760 fields are transmitted from left to right.
1763 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
1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1765 | Type | Length | Value
1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1780 The Value field is four octets. Despite the size of the field,
1781 values range from 64 to 65535.
1794 Rigney, et. al. Standards Track [Page 32]
1796 RFC 2138 RADIUS April 1997
1799 5.13. Framed-Compression
1803 This Attribute indicates a compression protocol to be used for the
1804 link. It MAY be used in Access-Accept packets. It MAY be used in
1805 an Access-Request packet as a hint to the server that the NAS
1806 would prefer to use that compression, but the server is not
1807 required to honor the hint.
1809 More than one compression protocol Attribute MAY be sent. It is
1810 the responsibility of the NAS to apply the proper compression
1811 protocol to appropriate link traffic.
1813 A summary of the Framed-Compression Attribute format is shown below.
1814 The fields are transmitted from left to right.
1817 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
1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1819 | Type | Length | Value
1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1826 13 for Framed-Compression.
1834 The Value field is four octets.
1837 1 VJ TCP/IP header compression [5]
1838 2 IPX header compression
1844 This Attribute indicates the system with which to connect the
1845 user, when the Login-Service Attribute is included. It MAY be
1846 used in Access-Accept packets. It MAY be used in an Access-
1850 Rigney, et. al. Standards Track [Page 33]
1852 RFC 2138 RADIUS April 1997
1855 Request packet as a hint to the server that the NAS would prefer
1856 to use that host, but the server is not required to honor the
1859 A summary of the Login-IP-Host Attribute format is shown below. The
1860 fields are transmitted from left to right.
1863 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
1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1865 | Type | Length | Address
1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1872 14 for Login-IP-Host.
1880 The Address field is four octets. The value 0xFFFFFFFF indicates
1881 that the NAS SHOULD allow the user to select an address. The
1882 value 0 indicates that the NAS SHOULD select a host to connect the
1883 user to. Other values indicate the address the NAS SHOULD connect
1890 This Attribute indicates the service which should be used to
1891 connect the user to the login host. It is only used in Access-
1894 A summary of the Login-Service Attribute format is shown below. The
1895 fields are transmitted from left to right.
1906 Rigney, et. al. Standards Track [Page 34]
1908 RFC 2138 RADIUS April 1997
1912 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
1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1914 | Type | Length | Value
1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1921 15 for Login-Service.
1929 The Value field is four octets.
1934 3 PortMaster (proprietary)
1937 5.16. Login-TCP-Port
1941 This Attribute indicates the TCP port with which the user is to be
1942 connected, when the Login-Service Attribute is also present. It
1943 is only used in Access-Accept packets.
1945 A summary of the Login-TCP-Port Attribute format is shown below. The
1946 fields are transmitted from left to right.
1949 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
1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1951 | Type | Length | Value
1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1958 16 for Login-TCP-Port.
1962 Rigney, et. al. Standards Track [Page 35]
1964 RFC 2138 RADIUS April 1997
1973 The Value field is four octets. Despite the size of the field,
1974 values range from 0 to 65535.
1980 ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
1986 This Attribute indicates text which MAY be displayed to the user.
1988 When used in an Access-Accept, it is the success message.
1990 When used in an Access-Reject, it is the failure message. It MAY
1991 indicate a dialog message to prompt the user before another
1992 Access-Request attempt.
1994 When used in an Access-Challenge, it MAY indicate a dialog message
1995 to prompt the user for a response.
1997 Multiple Reply-Message's MAY be included and if any are displayed,
1998 they MUST be displayed in the same order as they appear in the
2001 A summary of the Reply-Message Attribute format is shown below. The
2002 fields are transmitted from left to right.
2005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2007 | Type | Length | String ...
2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2013 18 for Reply-Message.
2018 Rigney, et. al. Standards Track [Page 36]
2020 RFC 2138 RADIUS April 1997
2029 The String field is one or more octets, and its contents are
2030 implementation dependent. It is intended to be human readable,
2031 and MUST NOT affect operation of the protocol. It is recommended
2032 that the message contain displayable ASCII characters from the
2033 range 10, 13, and 32 through 126 decimal. Mechanisms for
2034 extension to other character sets are beyond the scope of this
2037 5.19. Callback-Number
2041 This Attribute indicates a dialing string to be used for callback.
2042 It MAY be used in Access-Accept packets. It MAY be used in an
2043 Access-Request packet as a hint to the server that a Callback
2044 service is desired, but the server is not required to honor the
2047 A summary of the Callback-Number Attribute format is shown below.
2048 The fields are transmitted from left to right.
2051 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2053 | Type | Length | String ...
2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2058 19 for Callback-Number.
2074 Rigney, et. al. Standards Track [Page 37]
2076 RFC 2138 RADIUS April 1997
2081 The String field is one or more octets. The actual format of the
2082 information is site or application specific, and a robust
2083 implementation SHOULD support the field as undistinguished octets.
2085 The codification of the range of allowed usage of this field is
2086 outside the scope of this specification.
2092 This Attribute indicates the name of a place to be called, to be
2093 interpreted by the NAS. It MAY be used in Access-Accept packets.
2095 A summary of the Callback-Id Attribute format is shown below. The
2096 fields are transmitted from left to right.
2099 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2101 | Type | Length | String ...
2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2114 The String field is one or more octets. The actual format of the
2115 information is site or application specific, and a robust
2116 implementation SHOULD support the field as undistinguished octets.
2117 The codification of the range of allowed usage of this field is
2118 outside the scope of this specification.
2124 ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
2130 Rigney, et. al. Standards Track [Page 38]
2132 RFC 2138 RADIUS April 1997
2139 This Attribute provides routing information to be configured for
2140 the user on the NAS. It is used in the Access-Accept packet and
2141 can appear multiple times.
2143 A summary of the Framed-Route Attribute format is shown below. The
2144 fields are transmitted from left to right.
2147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2149 | Type | Length | String...
2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2154 22 for Framed-Route.
2162 The String field is one or more octets, and its contents are
2163 implementation dependent. It is intended to be human readable and
2164 MUST NOT affect operation of the protocol. It is recommended that
2165 the message contain displayable ASCII characters from the range 32
2166 through 126 decimal.
2168 For IP routes, it SHOULD contain a destination prefix in dotted
2169 quad form optionally followed by a slash and a decimal length
2170 specifier stating how many high order bits of the prefix should be
2171 used. That is followed by a space, a gateway address in dotted
2172 quad form, a space, and one or more metrics separated by spaces.
2173 For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
2174 specifier may be omitted in which case it should default to 8 bits
2175 for class A prefixes, 16 bits for class B prefixes, and 24 bits
2176 for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
2178 Whenever the gateway address is specified as "0.0.0.0" the IP
2179 address of the user SHOULD be used as the gateway address.
2186 Rigney, et. al. Standards Track [Page 39]
2188 RFC 2138 RADIUS April 1997
2191 5.23. Framed-IPX-Network
2195 This Attribute indicates the IPX Network number to be configured
2196 for the user. It is used in Access-Accept packets.
2198 A summary of the Framed-IPX-Network Attribute format is shown below.
2199 The fields are transmitted from left to right.
2202 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
2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2204 | Type | Length | Value
2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2211 23 for Framed-IPX-Network.
2219 The Value field is four octets. The value 0xFFFFFFFE indicates
2220 that the NAS should select an IPX network for the user (e.g.
2221 assigned from a pool of one or more IPX networks kept by the NAS).
2222 Other values should be used as the IPX network for the link to the
2229 This Attribute is available to be sent by the server to the client
2230 in an Access-Challenge and MUST be sent unmodified from the client
2231 to the server in the new Access-Request reply to that challenge,
2242 Rigney, et. al. Standards Track [Page 40]
2244 RFC 2138 RADIUS April 1997
2247 This Attribute is available to be sent by the server to the client
2248 in an Access-Accept that also includes a Termination-Action
2249 Attribute with the value of RADIUS-Request. If the NAS performs
2250 the Termination-Action by sending a new Access-Request upon
2251 termination of the current session, it MUST include the State
2252 attribute unchanged in that Access-Request.
2254 In either usage, no interpretation by the client should be made.
2255 A packet may have only one State Attribute. Usage of the State
2256 Attribute is implementation dependent.
2258 A summary of the State Attribute format is shown below. The fields
2259 are transmitted from left to right.
2262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2264 | Type | Length | String ...
2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2277 The String field is one or more octets. The actual format of the
2278 information is site or application specific, and a robust
2279 implementation SHOULD support the field as undistinguished octets.
2281 The codification of the range of allowed usage of this field is
2282 outside the scope of this specification.
2288 This Attribute is available to be sent by the server to the client
2289 in an Access-Accept and should be sent unmodified by the client to
2290 the accounting server as part of the Accounting-Request packet if
2291 accounting is supported. No interpretation by the client should
2298 Rigney, et. al. Standards Track [Page 41]
2300 RFC 2138 RADIUS April 1997
2303 A summary of the Class Attribute format is shown below. The fields
2304 are transmitted from left to right.
2307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2309 | Type | Length | String ...
2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2322 The String field is one or more octets. The actual format of the
2323 information is site or application specific, and a robust
2324 implementation SHOULD support the field as undistinguished octets.
2326 The codification of the range of allowed usage of this field is
2327 outside the scope of this specification.
2329 5.26. Vendor-Specific
2333 This Attribute is available to allow vendors to support their own
2334 extended Attributes not suitable for general usage. It MUST not
2335 affect the operation of the RADIUS protocol.
2337 Servers not equipped to interpret the vendor-specific information
2338 sent by a client MUST ignore it (although it may be reported).
2339 Clients which do not receive desired vendor-specific information
2340 SHOULD make an attempt to operate without it, although they may do
2341 so (and report they are doing so) in a degraded mode.
2343 A summary of the Vendor-Specific Attribute format is shown below.
2344 The fields are transmitted from left to right.
2354 Rigney, et. al. Standards Track [Page 42]
2356 RFC 2138 RADIUS April 1997
2360 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
2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2362 | Type | Length | Vendor-Id
2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2364 Vendor-Id (cont) | String...
2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2369 26 for Vendor-Specific.
2377 The high-order octet is 0 and the low-order 3 octets are the SMI
2378 Network Management Private Enterprise Code of the Vendor in
2379 network byte order, as defined in the Assigned Numbers RFC [3].
2383 The String field is one or more octets. The actual format of the
2384 information is site or application specific, and a robust
2385 implementation SHOULD support the field as undistinguished octets.
2387 The codification of the range of allowed usage of this field is
2388 outside the scope of this specification.
2390 It SHOULD be encoded as a sequence of vendor type / vendor length
2391 / value fields, as follows. The Attribute-Specific field is
2392 dependent on the vendor's definition of that attribute. An
2393 example encoding of the Vendor-Specific attribute using this
2397 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
2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2399 | Type | Length | Vendor-Id
2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2401 Vendor-Id (cont) | Vendor type | Vendor length |
2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2403 | Attribute-Specific...
2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2410 Rigney, et. al. Standards Track [Page 43]
2412 RFC 2138 RADIUS April 1997
2415 5.27. Session-Timeout
2419 This Attribute sets the maximum number of seconds of service to be
2420 provided to the user before termination of the session or prompt.
2421 This Attribute is available to be sent by the server to the client
2422 in an Access-Accept or Access-Challenge.
2424 A summary of the Session-Timeout Attribute format is shown below.
2425 The fields are transmitted from left to right.
2428 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
2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2430 | Type | Length | Value
2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2437 27 for Session-Timeout.
2445 The field is 4 octets, containing a 32-bit unsigned integer with
2446 the maximum number of seconds this user should be allowed to
2447 remain connected by the NAS.
2453 This Attribute sets the maximum number of consecutive seconds of
2454 idle connection allowed to the user before termination of the
2455 session or prompt. This Attribute is available to be sent by the
2456 server to the client in an Access-Accept or Access-Challenge.
2466 Rigney, et. al. Standards Track [Page 44]
2468 RFC 2138 RADIUS April 1997
2471 A summary of the Idle-Timeout Attribute format is shown below. The
2472 fields are transmitted from left to right.
2475 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
2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2477 | Type | Length | Value
2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2484 28 for Idle-Timeout.
2492 The field is 4 octets, containing a 32-bit unsigned integer with
2493 the maximum number of consecutive seconds of idle time this user
2494 should be permitted before being disconnected by the NAS.
2496 5.29. Termination-Action
2500 This Attribute indicates what action the NAS should take when the
2501 specified service is completed. It is only used in Access-Accept
2504 A summary of the Termination-Action Attribute format is shown below.
2505 The fields are transmitted from left to right.
2508 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
2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2510 | Type | Length | Value
2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2517 29 for Termination-Action.
2522 Rigney, et. al. Standards Track [Page 45]
2524 RFC 2138 RADIUS April 1997
2533 The Value field is four octets.
2538 If the Value is set to RADIUS-Request, upon termination of the
2539 specified service the NAS MAY send a new Access-Request to the
2540 RADIUS server, including the State attribute if any.
2542 5.30. Called-Station-Id
2546 This Attribute allows the NAS to send in the Access-Request packet
2547 the phone number that the user called, using Dialed Number
2548 Identification (DNIS) or similar technology. Note that this may be
2549 different from the phone number the call comes in on. It is only
2550 used in Access-Request packets.
2552 A summary of the Called-Station-Id Attribute format is shown below.
2553 The fields are transmitted from left to right.
2556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2558 | Type | Length | String ...
2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2564 30 for Called-Station-Id.
2572 The String field is one or more octets, containing the phone
2573 number that the user's call came in on.
2578 Rigney, et. al. Standards Track [Page 46]
2580 RFC 2138 RADIUS April 1997
2583 The actual format of the information is site or application
2584 specific. Printable ASCII is recommended, but a robust
2585 implementation SHOULD support the field as undistinguished octets.
2587 The codification of the range of allowed usage of this field is
2588 outside the scope of this specification.
2590 5.31. Calling-Station-Id
2594 This Attribute allows the NAS to send in the Access-Request packet
2595 the phone number that the call came from, using Automatic Number
2596 Identification (ANI) or similar technology. It is only used in
2597 Access-Request packets.
2599 A summary of the Calling-Station-Id Attribute format is shown below.
2600 The fields are transmitted from left to right.
2603 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2605 | Type | Length | String ...
2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2610 31 for Calling-Station-Id.
2618 The String field is one or more octets, containing the phone
2619 number that the user placed the call from.
2621 The actual format of the information is site or application
2622 specific. Printable ASCII is recommended, but a robust
2623 implementation SHOULD support the field as undistinguished octets.
2625 The codification of the range of allowed usage of this field is
2626 outside the scope of this specification.
2634 Rigney, et. al. Standards Track [Page 47]
2636 RFC 2138 RADIUS April 1997
2639 5.32. NAS-Identifier
2643 This Attribute contains a string identifying the NAS originating
2644 the Access-Request. It is only used in Access-Request packets.
2645 Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
2646 Access-Request packet.
2648 A summary of the NAS-Identifier Attribute format is shown below. The
2649 fields are transmitted from left to right.
2652 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2654 | Type | Length | String ...
2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2659 32 for NAS-Identifier.
2667 The String field is one or more octets, and should be unique to
2668 the NAS within the scope of the RADIUS server. For example, a
2669 fully qualified domain name would be suitable as a NAS-Identifier.
2671 The actual format of the information is site or application
2672 specific, and a robust implementation SHOULD support the field as
2673 undistinguished octets.
2675 The codification of the range of allowed usage of this field is
2676 outside the scope of this specification.
2682 This Attribute is available to be sent by a proxy server to
2683 another server when forwarding an Access-Request and MUST be
2684 returned unmodified in the Access-Accept, Access-Reject or
2685 Access-Challenge. This attribute should be removed by the proxy
2686 server before the response is forwarded to the NAS.
2690 Rigney, et. al. Standards Track [Page 48]
2692 RFC 2138 RADIUS April 1997
2695 Usage of the Proxy-State Attribute is implementation dependent. A
2696 description of its function is outside the scope of this
2699 A summary of the Proxy-State Attribute format is shown below. The
2700 fields are transmitted from left to right.
2703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2705 | Type | Length | String ...
2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2718 The String field is one or more octets. The actual format of the
2719 information is site or application specific, and a robust
2720 implementation SHOULD support the field as undistinguished octets.
2722 The codification of the range of allowed usage of this field is
2723 outside the scope of this specification.
2725 5.34. Login-LAT-Service
2729 This Attribute indicates the system with which the user is to be
2730 connected by LAT. It MAY be used in Access-Accept packets, but
2731 only when LAT is specified as the Login-Service. It MAY be used
2732 in an Access-Request packet as a hint to the server, but the
2733 server is not required to honor the hint.
2735 Administrators use the service attribute when dealing with
2736 clustered systems, such as a VAX or Alpha cluster. In such an
2737 environment several different time sharing hosts share the same
2738 resources (disks, printers, etc.), and administrators often
2739 configure each to offer access (service) to each of the shared
2740 resources. In this case, each host in the cluster advertises its
2741 services through LAT broadcasts.
2746 Rigney, et. al. Standards Track [Page 49]
2748 RFC 2138 RADIUS April 1997
2751 Sophisticated users often know which service providers (machines)
2752 are faster and tend to use a node name when initiating a LAT
2753 connection. Alternately, some administrators want particular
2754 users to use certain machines as a primitive form of load
2755 balancing (although LAT knows how to do load balancing itself).
2757 A summary of the Login-LAT-Service Attribute format is shown below.
2758 The fields are transmitted from left to right.
2761 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2763 | Type | Length | String ...
2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2769 34 for Login-LAT-Service.
2777 The String field is one or more octets, and contains the identity
2778 of the LAT service to use. The LAT Architecture allows this
2779 string to contain $ (dollar), - (hyphen), . (period), _
2780 (underscore), numerics, upper and lower case alphabetics, and the
2781 ISO Latin-1 character set extension [6]. All LAT string
2782 comparisons are case insensitive.
2784 5.35. Login-LAT-Node
2788 This Attribute indicates the Node with which the user is to be
2789 automatically connected by LAT. It MAY be used in Access-Accept
2790 packets, but only when LAT is specified as the Login-Service. It
2791 MAY be used in an Access-Request packet as a hint to the server,
2792 but the server is not required to honor the hint.
2794 A summary of the Login-LAT-Node Attribute format is shown below. The
2795 fields are transmitted from left to right.
2802 Rigney, et. al. Standards Track [Page 50]
2804 RFC 2138 RADIUS April 1997
2808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2810 | Type | Length | String ...
2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2815 35 for Login-LAT-Node.
2823 The String field is one or more octets, and contains the identity
2824 of the LAT Node to connect the user to. The LAT Architecture
2825 allows this string to contain $ (dollar), - (hyphen), . (period),
2826 _ (underscore), numerics, upper and lower case alphabetics, and
2827 the ISO Latin-1 character set extension. All LAT string
2828 comparisons are case insensitive.
2830 5.36. Login-LAT-Group
2834 This Attribute contains a string identifying the LAT group codes
2835 which this user is authorized to use. It MAY be used in Access-
2836 Accept packets, but only when LAT is specified as the Login-
2837 Service. It MAY be used in an Access-Request packet as a hint to
2838 the server, but the server is not required to honor the hint.
2840 LAT supports 256 different group codes, which LAT uses as a form
2841 of access rights. LAT encodes the group codes as a 256 bit
2844 Administrators can assign one or more of the group code bits at
2845 the LAT service provider; it will only accept LAT connections that
2846 have these group codes set in the bit map. The administrators
2847 assign a bitmap of authorized group codes to each user; LAT gets
2848 these from the operating system, and uses these in its requests to
2849 the service providers.
2858 Rigney, et. al. Standards Track [Page 51]
2860 RFC 2138 RADIUS April 1997
2863 A summary of the Login-LAT-Group Attribute format is shown below.
2864 The fields are transmitted from left to right.
2867 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2869 | Type | Length | String ...
2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2874 36 for Login-LAT-Group.
2882 The String field is a 32 octet bit map, most significant octet
2883 first. A robust implementation SHOULD support the field as
2884 undistinguished octets.
2886 The codification of the range of allowed usage of this field is
2887 outside the scope of this specification.
2889 5.37. Framed-AppleTalk-Link
2893 This Attribute indicates the AppleTalk network number which should
2894 be used for the serial link to the user, which is another
2895 AppleTalk router. It is only used in Access-Accept packets. It
2896 is never used when the user is not another router.
2898 A summary of the Framed-AppleTalk-Link Attribute format is shown
2899 below. The fields are transmitted from left to right.
2902 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
2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2904 | Type | Length | Value
2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2914 Rigney, et. al. Standards Track [Page 52]
2916 RFC 2138 RADIUS April 1997
2921 37 for Framed-AppleTalk-Link.
2929 The Value field is four octets. Despite the size of the field,
2930 values range from 0 to 65535. The special value of 0 indicates
2931 that this is an unnumbered serial link. A value of 1-65535 means
2932 that the serial line between the NAS and the user should be
2933 assigned that value as an AppleTalk network number.
2935 5.38. Framed-AppleTalk-Network
2939 This Attribute indicates the AppleTalk Network number which the
2940 NAS should probe to allocate an AppleTalk node for the user. It
2941 is only used in Access-Accept packets. It is never used when the
2942 user is another router. Multiple instances of this Attribute
2943 indicate that the NAS may probe using any of the network numbers
2946 A summary of the Framed-AppleTalk-Network Attribute format is shown
2947 below. The fields are transmitted from left to right.
2950 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
2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2952 | Type | Length | Value
2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2959 38 for Framed-AppleTalk-Network.
2970 Rigney, et. al. Standards Track [Page 53]
2972 RFC 2138 RADIUS April 1997
2977 The Value field is four octets. Despite the size of the field,
2978 values range from 0 to 65535. The special value 0 indicates that
2979 the NAS should assign a network for the user, using its default
2980 cable range. A value between 1 and 65535 (inclusive) indicates
2981 the AppleTalk Network the NAS should probe to find an address for
2984 5.39. Framed-AppleTalk-Zone
2988 This Attribute indicates the AppleTalk Default Zone to be used for
2989 this user. It is only used in Access-Accept packets. Multiple
2990 instances of this attribute in the same packet are not allowed.
2992 A summary of the Framed-AppleTalk-Zone Attribute format is shown
2993 below. The fields are transmitted from left to right.
2996 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
2997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2998 | Type | Length | String ...
2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3003 39 for Framed-AppleTalk-Zone.
3011 The name of the Default AppleTalk Zone to be used for this user.
3012 A robust implementation SHOULD support the field as
3013 undistinguished octets.
3015 The codification of the range of allowed usage of this field is
3016 outside the scope of this specification.
3026 Rigney, et. al. Standards Track [Page 54]
3028 RFC 2138 RADIUS April 1997
3031 5.40. CHAP-Challenge
3035 This Attribute contains the CHAP Challenge sent by the NAS to a
3036 PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
3037 is only used in Access-Request packets.
3039 If the CHAP challenge value is 16 octets long it MAY be placed in
3040 the Request Authenticator field instead of using this attribute.
3042 A summary of the CHAP-Challenge Attribute format is shown below. The
3043 fields are transmitted from left to right.
3046 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
3047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3048 | Type | Length | String...
3049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3053 60 for CHAP-Challenge.
3061 The String field contains the CHAP Challenge.
3067 This Attribute indicates the type of the physical port of the NAS
3068 which is authenticating the user. It can be used instead of or in
3069 addition to the NAS-Port (5) attribute. It is only used in
3070 Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
3071 both SHOULD be present in an Access-Request packet, if the NAS
3072 differentiates among its ports.
3082 Rigney, et. al. Standards Track [Page 55]
3084 RFC 2138 RADIUS April 1997
3087 A summary of the NAS-Port-Type Attribute format is shown below. The
3088 fields are transmitted from left to right.
3091 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
3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3093 | Type | Length | Value
3094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3100 61 for NAS-Port-Type.
3108 The Value field is four octets. "Virtual" refers to a connection
3109 to the NAS via some transport protocol, instead of through a
3110 physical port. For example, if a user telnetted into a NAS to
3111 authenticate himself as an Outbound-User, the Access-Request might
3112 include NAS-Port-Type = Virtual as a hint to the RADIUS server
3113 that the user was not on a physical port.
3126 This Attribute sets the maximum number of ports to be provided to
3127 the user by the NAS. This Attribute MAY be sent by the server to
3128 the client in an Access-Accept packet. It is intended for use in
3129 conjunction with Multilink PPP [7] or similar uses. It MAY also
3130 be sent by the NAS to the server as a hint that that many ports
3131 are desired for use, but the server is not required to honor the
3138 Rigney, et. al. Standards Track [Page 56]
3140 RFC 2138 RADIUS April 1997
3143 A summary of the Port-Limit Attribute format is shown below. The
3144 fields are transmitted from left to right.
3147 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
3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3149 | Type | Length | Value
3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3164 The field is 4 octets, containing a 32-bit unsigned integer with
3165 the maximum number of ports this user should be allowed to connect
3168 5.43. Login-LAT-Port
3172 This Attribute indicates the Port with which the user is to be
3173 connected by LAT. It MAY be used in Access-Accept packets, but
3174 only when LAT is specified as the Login-Service. It MAY be used
3175 in an Access-Request packet as a hint to the server, but the
3176 server is not required to honor the hint.
3178 A summary of the Login-LAT-Port Attribute format is shown below. The
3179 fields are transmitted from left to right.
3182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3184 | Type | Length | String ...
3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3189 63 for Login-LAT-Port.
3194 Rigney, et. al. Standards Track [Page 57]
3196 RFC 2138 RADIUS April 1997
3205 The String field is one or more octets, and contains the identity
3206 of the LAT port to use. The LAT Architecture allows this string
3207 to contain $ (dollar), - (hyphen), . (period), _ (underscore),
3208 numerics, upper and lower case alphabetics, and the ISO Latin-1
3209 character set extension. All LAT string comparisons are case
3212 5.44. Table of Attributes
3214 The following table provides a guide to which attributes may be found
3215 in which kinds of packets, and in what quantity.
3217 Request Accept Reject Challenge # Attribute
3219 0-1 0 0 0 2 User-Password [Note 1]
3220 0-1 0 0 0 3 CHAP-Password [Note 1]
3221 0-1 0 0 0 4 NAS-IP-Address
3222 0-1 0 0 0 5 NAS-Port
3223 0-1 0-1 0 0 6 Service-Type
3224 0-1 0-1 0 0 7 Framed-Protocol
3225 0-1 0-1 0 0 8 Framed-IP-Address
3226 0-1 0-1 0 0 9 Framed-IP-Netmask
3227 0 0-1 0 0 10 Framed-Routing
3228 0 0+ 0 0 11 Filter-Id
3229 0 0-1 0 0 12 Framed-MTU
3230 0+ 0+ 0 0 13 Framed-Compression
3231 0+ 0+ 0 0 14 Login-IP-Host
3232 0 0-1 0 0 15 Login-Service
3233 0 0-1 0 0 16 Login-TCP-Port
3234 0 0+ 0+ 0+ 18 Reply-Message
3235 0-1 0-1 0 0 19 Callback-Number
3236 0 0-1 0 0 20 Callback-Id
3237 0 0+ 0 0 22 Framed-Route
3238 0 0-1 0 0 23 Framed-IPX-Network
3239 0-1 0-1 0 0-1 24 State
3241 0+ 0+ 0 0+ 26 Vendor-Specific
3242 0 0-1 0 0-1 27 Session-Timeout
3243 0 0-1 0 0-1 28 Idle-Timeout
3244 0 0-1 0 0 29 Termination-Action
3245 0-1 0 0 0 30 Called-Station-Id
3246 0-1 0 0 0 31 Calling-Station-Id
3250 Rigney, et. al. Standards Track [Page 58]
3252 RFC 2138 RADIUS April 1997
3255 0-1 0 0 0 32 NAS-Identifier
3256 0+ 0+ 0+ 0+ 33 Proxy-State
3257 0-1 0-1 0 0 34 Login-LAT-Service
3258 0-1 0-1 0 0 35 Login-LAT-Node
3259 0-1 0-1 0 0 36 Login-LAT-Group
3260 0 0-1 0 0 37 Framed-AppleTalk-Link
3261 0 0+ 0 0 38 Framed-AppleTalk-Network
3262 0 0-1 0 0 39 Framed-AppleTalk-Zone
3263 0-1 0 0 0 60 CHAP-Challenge
3264 0-1 0 0 0 61 NAS-Port-Type
3265 0-1 0-1 0 0 62 Port-Limit
3266 0-1 0-1 0 0 63 Login-LAT-Port
3269 Request Accept Reject Challenge # Attribute
3272 [Note 1] An Access-Request MUST contain either a User-Password or a
3273 CHAP-Password, and MUST NOT contain both.
3275 The following table defines the meaning of the above table entries.
3277 0 This attribute MUST NOT be present in packet.
3278 0+ Zero or more instances of this attribute MAY be present in packet.
3279 0-1 Zero or one instance of this attribute MAY be present in packet.
3280 1 Exactly one instance of this attribute MUST be present in packet.
3284 A few examples are presented to illustrate the flow of packets and
3285 use of typical attributes. These examples are not intended to be
3286 exhaustive, many others are possible.
3306 Rigney, et. al. Standards Track [Page 59]
3308 RFC 2138 RADIUS April 1997
3311 6.1. User Telnet to Specified Host
3313 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3314 RADIUS Server for a user named nemo logging in on port 3.
3316 Code = 1 (Access-Request)
3319 Request Authenticator = {16 octet random number}
3322 User-Password = {16 octets of Password padded at end with nulls,
3323 XORed with MD5(shared secret|Request Authenticator)}
3324 NAS-IP-Address = 192.168.1.16
3327 The RADIUS server authenticates nemo, and sends an Access-Accept UDP
3328 packet to the NAS telling it to telnet nemo to host 192.168.1.3.
3330 Code = 2 (Access-Accept)
3331 ID = 0 (same as in Access-Request)
3333 Response Authenticator = {16-octet MD-5 checksum of the code (2),
3334 id (0), Length (38), the Request Authenticator from
3335 above, the attributes in this reply, and the shared
3338 Service-Type = Login-User
3339 Login-Service = Telnet
3340 Login-Host = 192.168.1.3
3342 6.2. Framed User Authenticating with CHAP
3344 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3345 RADIUS Server for a user named flopsy logging in on port 20 with PPP,
3346 authenticating using CHAP. The NAS sends along the Service-Type and
3347 Framed-Protocol attributes as a hint to the RADIUS server that this
3348 user is looking for PPP, although the NAS is not required to do so.
3362 Rigney, et. al. Standards Track [Page 60]
3364 RFC 2138 RADIUS April 1997
3367 Code = 1 (Access-Request)
3370 Request Authenticator = {16 octet random number also used as
3373 User-Name = "flopsy"
3374 CHAP-Password = {1 octet CHAP ID followed by 16 octet
3376 NAS-IP-Address = 192.168.1.16
3378 Service-Type = Framed-User
3379 Framed-Protocol = PPP
3381 The RADIUS server authenticates flopsy, and sends an Access-Accept
3382 UDP packet to the NAS telling it to start PPP service and assign an
3383 address for the user out of its dynamic address pool.
3385 Code = 2 (Access-Accept)
3386 ID = 1 (same as in Access-Request)
3388 Response Authenticator = {16-octet MD-5 checksum of the code (2),
3389 id (1), Length (56), the Request Authenticator from
3390 above, the attributes in this reply, and the shared
3393 Service-Type = Framed-User
3394 Framed-Protocol = PPP
3395 Framed-IP-Address = 255.255.255.254
3396 Framed-Routing = None
3397 Framed-Compression = 1 (VJ TCP/IP Header Compression)
3400 6.3. User with Challenge-Response card
3402 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3403 RADIUS Server for a user named mopsy logging in on port 7.
3405 Code = 1 (Access-Request)
3408 Request Authenticator = {16 octet random number}
3411 User-Password = {16 octets of Password padded at end with nulls,
3412 XORed with MD5(shared secret|Request Authenticator)}
3413 NAS-IP-Address = 192.168.1.16
3418 Rigney, et. al. Standards Track [Page 61]
3420 RFC 2138 RADIUS April 1997
3423 The RADIUS server decides to challenge mopsy, sending back a
3424 challenge string and looking for a response. The RADIUS server
3425 therefore and sends an Access-Challenge UDP packet to the NAS.
3427 Code = 11 (Access-Challenge}
3428 ID = 2 (same as in Access-Request)
3430 Response Authenticator = {16-octet MD-5 checksum of the code (11),
3431 id (2), length (78), the Request Authenticator from
3432 above, the attributes in this reply, and the shared
3435 Reply-Message = "Challenge 32769430. Enter response at prompt."
3436 State = {Magic Cookie to be returned along with user's response;
3437 in this example 8 octets of data}
3439 The user enters his response, and the NAS send a new Access-Request
3440 with that response, and includes the State Attribute.
3442 Code = 1 (Access-Request)
3443 ID = 3 (Note that this changes)
3445 Request Authenticator = {NEW 16 octet random number}
3448 User-Password = {16 octets of Response padded at end with
3449 nulls, XORed with MD5 checksum of shared secret
3450 plus above Request Authenticator}
3451 NAS-IP-Address = 192.168.1.16
3453 State = {Magic Cookie from Access-Challenge packet, unchanged}
3455 The Response was incorrect, so the RADIUS server tells the NAS to
3456 reject the login attempt.
3458 Code = 3 (Access-Reject)
3459 ID = 3 (same as in Access-Request)
3461 Response Authenticator = {16-octet MD-5 checksum of the code (3),
3462 id (3), length(20), the Request Authenticator from
3463 above, the attributes in this reply if any, and the
3466 (none, although a Reply-Message could be sent)
3474 Rigney, et. al. Standards Track [Page 62]
3476 RFC 2138 RADIUS April 1997
3479 Security Considerations
3481 Security issues are the primary topic of this document.
3483 In practice, within or associated with each RADIUS server, there is a
3484 database which associates "user" names with authentication
3485 information ("secrets"). It is not anticipated that a particular
3486 named user would be authenticated by multiple methods. This would
3487 make the user vulnerable to attacks which negotiate the least secure
3488 method from among a set. Instead, for each named user there should
3489 be an indication of exactly one method used to authenticate that user
3490 name. If a user needs to make use of different authentication
3491 methods under different circumstances, then distinct user names
3492 SHOULD be employed, each of which identifies exactly one
3493 authentication method.
3495 Passwords and other secrets should be stored at the respective ends
3496 such that access to them is as limited as possible. Ideally, the
3497 secrets should only be accessible to the process requiring access in
3498 order to perform the authentication.
3500 The secrets should be distributed with a mechanism that limits the
3501 number of entities that handle (and thus gain knowledge of) the
3502 secret. Ideally, no unauthorized person should ever gain knowledge
3503 of the secrets. It is possible to achieve this with SNMP Security
3504 Protocols [8], but such a mechanism is outside the scope of this
3507 Other distribution methods are currently undergoing research and
3508 experimentation. The SNMP Security document [8] also has an
3509 excellent overview of threats to network protocols.
3530 Rigney, et. al. Standards Track [Page 63]
3532 RFC 2138 RADIUS April 1997
3537 [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
3538 RFC 1321, MIT Laboratory for Computer Science, RSA Data
3539 Security Inc., April 1992.
3541 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
3542 USC/Information Sciences Institute, August 1980.
3544 [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
3545 1700, USC/Information Sciences Institute, October 1994.
3547 [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
3548 Private Communications in a Public World", Prentice Hall, March
3549 1995, ISBN 0-13-061466-1.
3551 [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
3552 links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
3554 [6] ISO 8859. International Standard -- Information Processing --
3555 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
3556 Alphabet No. 1, ISO 8859-1:1987.
3557 <URL:http://www.iso.ch/cate/d16338.html>
3559 [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
3560 Multilink Protocol (MP)", RFC 1717, University of California
3561 Berkeley, Lloyd Internetworking, Newbridge Networks
3562 Corporation, November 1994.
3564 [8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
3565 Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
3566 LAN Systems, Inc., MIT Laboratory for Computer Science, July
3569 [9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
3573 RADIUS was originally developed by Livingston Enterprises for their
3574 PortMaster series of Network Access Servers.
3586 Rigney, et. al. Standards Track [Page 64]
3588 RFC 2138 RADIUS April 1997
3593 The working group can be contacted via the current chair:
3596 Livingston Enterprises
3598 Pleasanton, California 94588
3600 Phone: +1 510 426 0770
3601 EMail: cdr@livingston.com
3605 Questions about this memo can also be directed to:
3608 Livingston Enterprises
3610 Pleasanton, California 94588
3612 Phone: +1 510 426 0770
3613 EMail: cdr@livingston.com
3618 Ann Arbor, Michigan 48105-2785
3620 EMail: acr@merit.edu
3622 William Allen Simpson
3624 Computer Systems Consulting Services
3626 Madison Heights, Michigan 48071
3628 EMail: wsimpson@greendragon.com
3631 Livingston Enterprises
3633 Pleasanton, California 94588
3635 EMail: steve@livingston.com
3642 Rigney, et. al. Standards Track [Page 65]
projects / freeradius.git / blob