7 Network Working Group C. Rigney
8 Request for Comments: 2058 Livingston
9 Category: Standards Track A. Rubens
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 1. Introduction .......................................... 3
38 1.1 Specification of Requirements ................... 4
39 1.2 Terminology ..................................... 4
40 2. Operation ............................................. 5
41 2.1 Challenge/Response .............................. 6
42 2.2 Interoperation with PAP and CHAP ................ 7
43 2.3 Why UDP? ........................................ 8
44 3. Packet Format ......................................... 9
45 4. Packet Types .......................................... 12
46 4.1 Access-Request .................................. 12
47 4.2 Access-Accept ................................... 14
48 4.3 Access-Reject ................................... 15
49 4.4 Access-Challenge ................................ 16
50 5. Attributes ............................................ 17
51 5.1 User-Name ....................................... 20
52 5.2 User-Password ................................... 21
53 5.3 CHAP-Password ................................... 22
54 5.4 NAS-IP-Address .................................. 23
58 Rigney, et. al. Informational [Page 1]
60 RFC 2058 RADIUS January 1997
63 5.5 NAS-Port ........................................ 24
64 5.6 Service-Type .................................... 25
65 5.7 Framed-Protocol ................................. 27
66 5.8 Framed-IP-Address ............................... 28
67 5.9 Framed-IP-Netmask ............................... 29
68 5.10 Framed-Routing .................................. 29
69 5.11 Filter-Id ....................................... 30
70 5.12 Framed-MTU ...................................... 31
71 5.13 Framed-Compression .............................. 32
72 5.14 Login-IP-Host ................................... 33
73 5.15 Login-Service ................................... 33
74 5.16 Login-TCP-Port .................................. 34
75 5.17 (unassigned) .................................... 35
76 5.18 Reply-Message ................................... 35
77 5.19 Callback-Number ................................. 36
78 5.20 Callback-Id ..................................... 37
79 5.21 (unassigned) .................................... 37
80 5.22 Framed-Route .................................... 38
81 5.23 Framed-IPX-Network .............................. 39
82 5.24 State ........................................... 39
83 5.25 Class ........................................... 40
84 5.26 Vendor-Specific ................................. 41
85 5.27 Session-Timeout ................................. 43
86 5.28 Idle-Timeout .................................... 44
87 5.29 Termination-Action .............................. 44
88 5.30 Called-Station-Id ............................... 45
89 5.31 Calling-Station-Id .............................. 46
90 5.32 NAS-Identifier .................................. 47
91 5.33 Proxy-State ..................................... 48
92 5.34 Login-LAT-Service ............................... 49
93 5.35 Login-LAT-Node .................................. 50
94 5.36 Login-LAT-Group ................................. 51
95 5.37 Framed-AppleTalk-Link ........................... 52
96 5.38 Framed-AppleTalk-Network ........................ 53
97 5.39 Framed-AppleTalk-Zone ........................... 53
98 5.40 CHAP-Challenge .................................. 54
99 5.41 NAS-Port-Type ................................... 55
100 5.42 Port-Limit ...................................... 56
101 5.43 Login-LAT-Port .................................. 57
102 5.44 Table of Attributes ............................. 58
103 6. Examples .............................................. 59
104 6.1 User Telnet to Specified Host ................... 59
105 6.2 Framed User Authenticating with CHAP ............ 60
106 6.3 User with Challenge-Response card ............... 61
107 SECURITY CONSIDERATIONS ...................................... 62
108 REFERENCES ................................................... 63
109 ACKNOWLEDGEMENTS ............................................. 63
110 CHAIR'S ADDRESS .............................................. 64
114 Rigney, et. al. Informational [Page 2]
116 RFC 2058 RADIUS January 1997
119 AUTHORS' ADDRESSES ........................................... 64
123 Managing dispersed serial line and modem pools for large numbers of
124 users can create the need for significant administrative support.
125 Since modem pools are by definition a link to the outside world, they
126 require careful attention to security, authorization and accounting.
127 This can be best achieved by managing a single "database" of users,
128 which allows for authentication (verifying user name and password) as
129 well as configuration information detailing the type of service to
130 deliver to the user (for example, SLIP, PPP, telnet, rlogin).
132 Key features of RADIUS are:
136 A Network Access Server (NAS) operates as a client of RADIUS. The
137 client is responsible for passing user information to designated
138 RADIUS servers, and then acting on the response which is returned.
140 RADIUS servers are responsible for receiving user connection
141 requests, authenticating the user, and then returning all
142 configuration information necessary for the client to deliver
145 A RADIUS server can act as a proxy client to other RADIUS servers
146 or other kinds of authentication servers.
150 Transactions between the client and RADIUS server are
151 authenticated through the use of a shared secret, which is never
152 sent over the network. In addition, any user passwords are sent
153 encrypted between the client and RADIUS server, to eliminate the
154 possibility that someone snooping on an unsecure network could
155 determine a user's password.
157 Flexible Authentication Mechanisms
159 The RADIUS server can support a variety of methods to authenticate
160 a user. When it is provided with the user name and original
161 password given by the user, it can support PPP PAP or CHAP, UNIX
162 login, and other authentication mechanisms.
170 Rigney, et. al. Informational [Page 3]
172 RFC 2058 RADIUS January 1997
177 All transactions are comprised of variable length Attribute-
178 Length-Value 3-tuples. New attribute values can be added without
179 disturbing existing implementations of the protocol.
181 1.1. Specification of Requirements
183 In this document, several words are used to signify the requirements
184 of the specification. These words are often capitalized.
186 MUST This word, or the adjective "required", means that the
187 definition is an absolute requirement of the specification.
189 MUST NOT This phrase means that the definition is an absolute
190 prohibition of the specification.
192 SHOULD This word, or the adjective "recommended", means that there
193 may exist valid reasons in particular circumstances to
194 ignore this item, but the full implications must be
195 understood and carefully weighed before choosing a
198 MAY This word, or the adjective "optional", means that this
199 item is one of an allowed set of alternatives. An
200 implementation which does not include this option MUST be
201 prepared to interoperate with another implementation which
202 does include the option.
206 This document frequently uses the following terms:
208 service The NAS provides a service to the dial-in user, such as PPP
211 session Each service provided by the NAS to a dial-in user
212 constitutes a session, with the beginning of the session
213 defined as the point where service is first provided and
214 the end of the session defined as the point where service
215 is ended. A user may have multiple sessions in parallel or
216 series if the NAS supports that.
219 This means the implementation discards the packet without
220 further processing. The implementation SHOULD provide the
221 capability of logging the error, including the contents of
222 the silently discarded packet, and SHOULD record the event
226 Rigney, et. al. Informational [Page 4]
228 RFC 2058 RADIUS January 1997
231 in a statistics counter.
235 When a client is configured to use RADIUS, any user of the client
236 presents authentication information to the client. This might be
237 with a customizable login prompt, where the user is expected to enter
238 their username and password. Alternatively, the user might use a
239 link framing protocol such as the Point-to-Point Protocol (PPP),
240 which has authentication packets which carry this information.
242 Once the client has obtained such information, it may choose to
243 authenticate using RADIUS. To do so, the client creates an "Access-
244 Request" containing such Attributes as the user's name, the user's
245 password, the ID of the client and the Port ID which the user is
246 accessing. When a password is present, it is hidden using a method
247 based on the RSA Message Digest Algorithm MD5 [1].
249 The Access-Request is submitted to the RADIUS server via the network.
250 If no response is returned within a length of time, the request is
251 re-sent a number of times. The client can also forward requests to
252 an alternate server or servers in the event that the primary server
253 is down or unreachable. An alternate server can be used either after
254 a number of tries to the primary server fail, or in a round-robin
255 fashion. Retry and fallback algorithms are the topic of current
256 research and are not specified in detail in this document.
258 Once the RADIUS server receives the request, it validates the sending
259 client. A request from a client for which the RADIUS server does not
260 have a shared secret should be silently discarded. If the client is
261 valid, the RADIUS server consults a database of users to find the
262 user whose name matches the request. The user entry in the database
263 contains a list of requirements which must be met to allow access for
264 the user. This always includes verification of the password, but can
265 also specify the client(s) or port(s) to which the user is allowed
268 The RADIUS server MAY make requests of other servers in order to
269 satisfy the request, in which case it acts as a client.
271 If any condition is not met, the RADIUS server sends an "Access-
272 Reject" response indicating that this user request is invalid. If
273 desired, the server MAY include a text message in the Access-Reject
274 which MAY be displayed by the client to the user. No other
275 Attributes are permitted in an Access-Reject.
277 If all conditions are met and the RADIUS server wishes to issue a
278 challenge to which the user must respond, the RADIUS server sends an
282 Rigney, et. al. Informational [Page 5]
284 RFC 2058 RADIUS January 1997
287 "Access-Challenge" response. It MAY include a text message to be
288 displayed by the client to the user prompting for a response to the
289 challenge, and MAY include a State attribute. If the client receives
290 an Access-Challenge and supports challenge/response it MAY display
291 the text message, if any, to the user, and then prompt the user for a
292 response. The client then re-submits its original Access-Request
293 with a new request ID, with the User-Password Attribute replaced by
294 the response (encrypted), and including the State Attribute from the
295 Access-Challenge, if any. Only 0 or 1 instances of the State
296 Attributes should be present in a request. The server can respond to
297 this new Access-Request with either an Access-Accept, an Access-
298 Reject, or another Access-Challenge.
300 If all conditions are met, the list of configuration values for the
301 user are placed into an "Access-Accept" response. These values
302 include the type of service (for example: SLIP, PPP, Login User) and
303 all necessary values to deliver the desired service. For SLIP and
304 PPP, this may include values such as IP address, subnet mask, MTU,
305 desired compression, and desired packet filter identifiers. For
306 character mode users, this may include values such as desired
309 2.1. Challenge/Response
311 In challenge/response authentication, the user is given an
312 unpredictable number and challenged to encrypt it and give back the
313 result. Authorized users are equipped with special devices such as
314 smart cards or software that facilitate calculation of the correct
315 response with ease. Unauthorized users, lacking the appropriate
316 device or software and lacking knowledge of the secret key necessary
317 to emulate such a device or software, can only guess at the response.
319 The Access-Challenge packet typically contains a Reply-Message
320 including a challenge to be displayed to the user, such as a numeric
321 value unlikely ever to be repeated. Typically this is obtained from
322 an external server that knows what type of authenticator should be in
323 the possession of the authorized user and can therefore choose a
324 random or non-repeating pseudorandom number of an appropriate radix
327 The user then enters the challenge into his device (or software) and
328 it calculates a response, which the user enters into the client which
329 forwards it to the RADIUS server via a second Access-Request. If the
330 response matches the expected response the RADIUS server replies with
331 an Access-Accept, otherwise an Access-Reject.
333 Example: The NAS sends an Access-Request packet to the RADIUS Server
334 with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
338 Rigney, et. al. Informational [Page 6]
340 RFC 2058 RADIUS January 1997
343 just be a fixed string like "challenge" or ignored). The server
344 sends back an Access-Challenge packet with State and a Reply-Message
345 along the lines of "Challenge 12345678, enter your response at the
346 prompt" which the NAS displays. The NAS prompts for the response and
347 sends a NEW Access-Request to the server (with a new ID) with NAS-
348 Identifier, NAS-Port, User-Name, User-Password (the response just
349 entered by the user, encrypted), and the same State Attribute that
350 came with the Access-Challenge. The server then sends back either an
351 Access-Accept or Access-Reject based on whether the response matches
352 what it should be, or it can even send another Access-Challenge.
354 2.2. Interoperation with PAP and CHAP
356 For PAP, the NAS takes the PAP ID and password and sends them in an
357 Access-Request packet as the User-Name and User-Password. The NAS MAY
358 include the Attributes Service-Type = Framed-User and Framed-Protocol
359 = PPP as a hint to the RADIUS server that PPP service is expected.
361 For CHAP, the NAS generates a random challenge (preferably 16 octets)
362 and sends it to the user, who returns a CHAP response along with a
363 CHAP ID and CHAP username. The NAS then sends an Access-Request
364 packet to the RADIUS server with the CHAP username as the User-Name
365 and with the CHAP ID and CHAP response as the CHAP-Password
366 (Attribute 3). The random challenge can either be included in the
367 CHAP-Challenge attribute or, if it is 16 octets long, it can be
368 placed in the Request Authenticator field of the Access-Request
369 packet. The NAS MAY include the Attributes Service-Type = Framed-
370 User and Framed-Protocol = PPP as a hint to the RADIUS server that
371 PPP service is expected.
373 The RADIUS server looks up a password based on the User-Name,
374 encrypts the challenge using MD5 on the CHAP ID octet, that password,
375 and the CHAP challenge (from the CHAP-Challenge attribute if present,
376 otherwise from the Request Authenticator), and compares that result
377 to the CHAP-Password. If they match, the server sends back an
378 Access-Accept, otherwise it sends back an Access-Reject.
380 If the RADIUS server is unable to perform the requested
381 authentication it should return an Access-Reject. For example, CHAP
382 requires that the user's password be available in cleartext to the
383 server so that it can encrypt the CHAP challenge and compare that to
384 the CHAP response. If the password is not available in cleartext to
385 the RADIUS server then the server MUST send an Access-Reject to the
394 Rigney, et. al. Informational [Page 7]
396 RFC 2058 RADIUS January 1997
401 A frequently asked question is why RADIUS uses UDP instead of TCP as
402 a transport protocol. UDP was chosen for strictly technical reasons.
404 There are a number of issues which must be understood. RADIUS is a
405 transaction based protocol which has several interesting
408 1. If the request to a primary Authentication server fails, a
409 secondary server must be queried.
411 To meet this requirement, a copy of the request must be kept
412 above the transport layer to allow for alternate transmission.
413 This means that retransmission timers are still required.
415 2. The timing requirements of this particular protocol are
416 significantly different than TCP provides.
418 At one extreme, RADIUS does not require a "responsive" detection
419 of lost data. The user is willing to wait several seconds for
420 the authentication to complete. The generally aggressive TCP
421 retransmission (based on average round trip time) is not
422 required, nor is the acknowledgement overhead of TCP.
424 At the other extreme, the user is not willing to wait several
425 minutes for authentication. Therefore the reliable delivery of
426 TCP data two minutes later is not useful. The faster use of an
427 alternate server allows the user to gain access before giving
430 3. The stateless nature of this protocol simplifies the use of UDP.
432 Clients and servers come and go. Systems are rebooted, or are
433 power cycled independently. Generally this does not cause a
434 problem and with creative timeouts and detection of lost TCP
435 connections, code can be written to handle anomalous events.
436 UDP however completely eliminates any of this special handling.
437 Each client and server can open their UDP transport just once
438 and leave it open through all types of failure events on the
441 4. UDP simplifies the server implementation.
443 In the earliest implementations of RADIUS, the server was single
444 threaded. This means that a single request was received,
445 processed, and returned. This was found to be unmanageable in
446 environments where the back-end security mechanism took real
450 Rigney, et. al. Informational [Page 8]
452 RFC 2058 RADIUS January 1997
455 time (1 or more seconds). The server request queue would fill
456 and in environments where hundreds of people were being
457 authenticated every minute, the request turn-around time
458 increased to longer that users were willing to wait (this was
459 especially severe when a specific lookup in a database or over
460 DNS took 30 or more seconds). The obvious solution was to make
461 the server multi-threaded. Achieving this was simple with UDP.
462 Separate processes were spawned to serve each request and these
463 processes could respond directly to the client NAS with a simple
464 UDP packet to the original transport of the client.
466 It's not all a panacea. As noted, using UDP requires one thing which
467 is built into TCP: with UDP we must artificially manage
468 retransmission timers to the same server, although they don't require
469 the same attention to timing provided by TCP. This one penalty is a
470 small price to pay for the advantages of UDP in this protocol.
472 Without TCP we would still probably be using tin cans connected by
473 string. But for this particular protocol, UDP is a better choice.
477 Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
478 where the UDP Destination Port field indicates 1812 (decimal).
480 When a reply is generated, the source and destination ports are
483 A summary of the RADIUS data format is shown below. The fields are
484 transmitted from left to right.
487 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
488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
489 | Code | Identifier | Length |
490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
497 +-+-+-+-+-+-+-+-+-+-+-+-+-
506 Rigney, et. al. Informational [Page 9]
508 RFC 2058 RADIUS January 1997
513 The Code field is one octet, and identifies the type of RADIUS
514 packet. When a packet is received with an invalid Code field, it is
517 RADIUS Codes (decimal) are assigned as follows:
523 5 Accounting-Response
525 12 Status-Server (experimental)
526 13 Status-Client (experimental)
529 Codes 4 and 5 will be covered in the RADIUS Accounting document [9],
530 and are not further mentioned here. Codes 12 and 13 are reserved for
531 possible use, but are not further mentioned here.
535 The Identifier field is one octet, and aids in matching requests and
540 The Length field is two octets. It indicates the length of the
541 packet including the Code, Identifier, Length, Authenticator and
542 Attribute fields. Octets outside the range of the Length field
543 should be treated as padding and should be ignored on reception. If
544 the packet is shorter than the Length field indicates, it should be
545 silently discarded. The minimum length is 20 and maximum length is
550 The Authenticator field is sixteen (16) octets. The most significant
551 octet is transmitted first. This value is used to authenticate the
552 reply from the RADIUS server, and is used in the password hiding
562 Rigney, et. al. Informational [Page 10]
564 RFC 2058 RADIUS January 1997
567 Request Authenticator
569 In Access-Request Packets, the Authenticator value is a 16 octet
570 random number, called the Request Authenticator. The value SHOULD be
571 unpredictable and unique over the lifetime of a secret (the password
572 shared between the client and the RADIUS server), since repetition of
573 a request value in conjunction with the same secret would permit an
574 attacker to reply with a previously intercepted response. Since it
575 is expected that the same secret MAY be used to authenticate with
576 servers in disparate geographic regions, the Request Authenticator
577 field SHOULD exhibit global and temporal uniqueness.
579 The Request Authenticator value in an Access-Request packet SHOULD
580 also be unpredictable, lest an attacker trick a server into
581 responding to a predicted future request, and then use the response
582 to masquerade as that server to a future Access-Request.
584 Although protocols such as RADIUS are incapable of protecting against
585 theft of an authenticated session via realtime active wiretapping
586 attacks, generation of unique unpredictable requests can protect
587 against a wide range of active attacks against authentication.
589 The NAS and RADIUS server share a secret. That shared secret
590 followed by the Request Authenticator is put through a one-way MD5
591 hash to create a 16 octet digest value which is xored with the
592 password entered by the user, and the xored result placed in the
593 User-Password attribute in the Access-Request packet. See the entry
594 for User-Password in the section on Attributes for a more detailed
597 Response Authenticator
599 The value of the Authenticator field in Access-Accept, Access-
600 Reject, and Access-Challenge packets is called the Response
601 Authenticator, and contains a one-way MD5 hash calculated over a
602 stream of octets consisting of: the RADIUS packet, beginning with
603 the Code field, including the Identifier, the Length, the Request
604 Authenticator field from the Access-Request packet, and the
605 response Attributes, followed by the shared secret. That is,
606 ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
607 where + denotes concatenation.
611 The secret (password shared between the client and the RADIUS server)
612 SHOULD be at least as large and unguessable as a well-chosen
613 password. It is preferred that the secret be at least 16 octets.
614 This is to ensure a sufficiently large range for the secret to
618 Rigney, et. al. Informational [Page 11]
620 RFC 2058 RADIUS January 1997
623 provide protection against exhaustive search attacks. A RADIUS
624 server SHOULD use the source IP address of the RADIUS UDP packet to
625 decide which shared secret to use, so that RADIUS requests can be
628 When using a forwarding proxy, the proxy must be able to alter the
629 packet as it passes through in each direction - when the proxy
630 forwards the request, the proxy can add a Proxy-State Attribute, and
631 when the proxy forwards a response, it removes the Proxy-State
632 Attribute. Since Access-Accept and Access-Reject replies are
633 authenticated on the entire packet contents, the stripping of the
634 Proxy-State attribute would invalidate the signature in the packet -
635 so the proxy has to re-sign it.
637 Further details of RADIUS proxy implementation are outside the scope
642 Many Attributes may have multiple instances, in such a case the order
643 of Attributes of the same Type SHOULD be preserved. The order of
644 Attributes of different Types is not required to be preserved.
646 In the section below on "Attributes" where the text refers to which
647 packets an attribute is allowed in, only packets with Codes 1, 2, 3
648 and 11 and attributes defined in this document are covered in this
649 document. A summary table is provided at the end of the "Attributes"
650 section. To determine which Attributes are allowed in packets with
651 codes 4 and 5 refer to the RADIUS Accounting document [9].
655 The RADIUS Packet type is determined by the Code field in the first
662 Access-Request packets are sent to a RADIUS server, and convey
663 information used to determine whether a user is allowed access to a
664 specific NAS, and any special services requested for that user. An
665 implementation wishing to authenticate a user MUST transmit a
666 RADIUS packet with the Code field set to 1 (Access-Request).
668 Upon receipt of an Access-Request from a valid client, an
669 appropriate reply MUST be transmitted.
674 Rigney, et. al. Informational [Page 12]
676 RFC 2058 RADIUS January 1997
679 An Access-Request MUST contain a User-Name attribute. It SHOULD
680 contain either a NAS-IP-Address attribute or NAS-Identifier
681 attribute (or both, although that is not recommended). It MUST
682 contain either a User-Password attribute or CHAP-Password
683 attribute. It SHOULD contain a NAS-Port or NAS-Port-Type attribute
684 or both unless the type of access being requested does not involve
685 a port or the NAS does not distinguish among its ports.
687 An Access-Request MAY contain additional attributes as a hint to
688 the server, but the server is not required to honor the hint.
690 When a User-Password is present, it is hidden using a method based
691 on the RSA Message Digest Algorithm MD5 [1].
693 A summary of the Access-Request packet format is shown below. The
694 fields are transmitted from left to right.
697 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
698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
699 | Code | Identifier | Length |
700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
702 | Request Authenticator |
705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
707 +-+-+-+-+-+-+-+-+-+-+-+-+-
712 1 for Access-Request.
716 The Identifier field MUST be changed whenever the content of the
717 Attributes field changes, and whenever a valid reply has been
718 received for a previous request. For retransmissions, the
719 Identifier MUST remain unchanged.
721 Request Authenticator
723 The Request Authenticator value MUST be changed each time a new
730 Rigney, et. al. Informational [Page 13]
732 RFC 2058 RADIUS January 1997
737 The Attribute field is variable in length, and contains the list
738 of Attributes that are required for the type of service, as well
739 as any desired optional Attributes.
745 Access-Accept packets are sent by the RADIUS server, and provide
746 specific configuration information necessary to begin delivery of
747 service to the user. If all Attribute values received in an
748 Access-Request are acceptable then the RADIUS implementation MUST
749 transmit a packet with the Code field set to 2 (Access-Accept). On
750 reception of an Access-Accept, the Identifier field is matched with
751 a pending Access-Request. Additionally, the Response Authenticator
752 field MUST contain the correct response for the pending Access-
753 Request. Invalid packets are silently discarded.
755 A summary of the Access-Accept packet format is shown below. The
756 fields are transmitted from left to right.
759 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
760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
761 | Code | Identifier | Length |
762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
764 | Response Authenticator |
767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
769 +-+-+-+-+-+-+-+-+-+-+-+-+-
778 The Identifier field is a copy of the Identifier field of the
779 Access-Request which caused this Access-Accept.
786 Rigney, et. al. Informational [Page 14]
788 RFC 2058 RADIUS January 1997
791 Response Authenticator
793 The Response Authenticator value is calculated from the Access-
794 Request value, as described earlier.
798 The Attribute field is variable in length, and contains a list of
799 zero or more Attributes.
805 If any value of the received Attributes is not acceptable, then the
806 RADIUS server MUST transmit a packet with the Code field set to 3
807 (Access-Reject). It MAY include one or more Reply-Message
808 Attributes with a text message which the NAS MAY display to the
811 A summary of the Access-Reject packet format is shown below. The
812 fields are transmitted from left to right.
815 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
816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
817 | Code | Identifier | Length |
818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
820 | Response Authenticator |
823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
825 +-+-+-+-+-+-+-+-+-+-+-+-+-
834 The Identifier field is a copy of the Identifier field of the
835 Access-Request which caused this Access-Reject.
842 Rigney, et. al. Informational [Page 15]
844 RFC 2058 RADIUS January 1997
847 Response Authenticator
849 The Response Authenticator value is calculated from the Access-
850 Request value, as described earlier.
854 The Attribute field is variable in length, and contains a list of
855 zero or more Attributes.
857 4.4. Access-Challenge
861 If the RADIUS server desires to send the user a challenge requiring
862 a response, then the RADIUS server MUST respond to the Access-
863 Request by transmitting a packet with the Code field set to 11
866 The Attributes field MAY have one or more Reply-Message Attributes,
867 and MAY have a single State Attribute, or none. No other
868 Attributes are permitted in an Access-Challenge.
870 On receipt of an Access-Challenge, the Identifier field is matched
871 with a pending Access-Request. Additionally, the Response
872 Authenticator field MUST contain the correct response for the
873 pending Access-Request. Invalid packets are silently discarded.
875 If the NAS does not support challenge/response, it MUST treat an
876 Access-Challenge as though it had received an Access-Reject
879 If the NAS supports challenge/response, receipt of a valid Access-
880 Challenge indicates that a new Access-Request SHOULD be sent. The
881 NAS MAY display the text message, if any, to the user, and then
882 prompt the user for a response. It then sends its original
883 Access-Request with a new request ID and Request Authenticator,
884 with the User-Password Attribute replaced by the user's response
885 (encrypted), and including the State Attribute from the Access-
886 Challenge, if any. Only 0 or 1 instances of the State Attribute
887 can be present in an Access-Request.
889 A NAS which supports PAP MAY forward the Reply-Message to the
890 dialin client and accept a PAP response which it can use as though
891 the user had entered the response. If the NAS cannot do so, it
892 should treat the Access-Challenge as though it had received an
893 Access-Reject instead.
898 Rigney, et. al. Informational [Page 16]
900 RFC 2058 RADIUS January 1997
903 A summary of the Access-Challenge packet format is shown below. The
904 fields are transmitted from left to right.
907 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
908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909 | Code | Identifier | Length |
910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
912 | Response Authenticator |
915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
917 +-+-+-+-+-+-+-+-+-+-+-+-+-
921 11 for Access-Challenge.
925 The Identifier field is a copy of the Identifier field of the
926 Access-Request which caused this Access-Challenge.
928 Response Authenticator
930 The Response Authenticator value is calculated from the Access-
931 Request value, as described earlier.
935 The Attributes field is variable in length, and contains a list of
936 zero or more Attributes.
940 RADIUS Attributes carry the specific authentication, authorization,
941 information and configuration details for the request and reply.
943 Some Attributes MAY be included more than once. The effect of this
944 is Attribute specific, and is specified in each Attribute
947 The end of the list of Attributes is indicated by the Length of the
954 Rigney, et. al. Informational [Page 17]
956 RFC 2058 RADIUS January 1997
959 A summary of the Attribute format is shown below. The fields are
960 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
964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
965 | Type | Length | Value ...
966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
970 The Type field is one octet. Up-to-date values of the RADIUS Type
971 field are specified in the most recent "Assigned Numbers" RFC [3].
972 Values 192-223 are reserved for experimental use, values 224-240
973 are reserved for implementation-specific use, and values 241-255
974 are reserved and should not be used. This specification concerns
975 the following values:
977 A RADIUS server MAY ignore Attributes with an unknown Type.
979 A RADIUS client MAY ignore Attributes with an unknown Type.
993 13 Framed-Compression
1003 23 Framed-IPX-Network
1010 Rigney, et. al. Informational [Page 18]
1012 RFC 2058 RADIUS January 1997
1017 29 Termination-Action
1018 30 Called-Station-Id
1019 31 Calling-Station-Id
1022 34 Login-LAT-Service
1025 37 Framed-AppleTalk-Link
1026 38 Framed-AppleTalk-Network
1027 39 Framed-AppleTalk-Zone
1028 40-59 (reserved for accounting)
1036 The Length field is one octet, and indicates the length of this
1037 Attribute including the Type, Length and Value fields. If an
1038 Attribute is received in an Access-Request but with an invalid
1039 Length, an Access-Reject SHOULD be transmitted. If an Attribute is
1040 received in an Access-Accept, Access-Reject or Access-Challenge
1041 packet with an invalid length, the packet MUST either be treated as
1042 an Access-Reject or else silently discarded.
1046 The Value field is zero or more octets and contains information
1047 specific to the Attribute. The format and length of the Value
1048 field is determined by the Type and Length fields.
1050 Note that a "string" in RADIUS does not require termination by an
1051 ASCII NUL because the Attribute already has a length field.
1053 The format of the value field is one of four data types.
1057 address 32 bit value, most significant octet first.
1059 integer 32 bit value, most significant octet first.
1066 Rigney, et. al. Informational [Page 19]
1068 RFC 2058 RADIUS January 1997
1071 time 32 bit value, most significant octet first -- seconds
1072 since 00:00:00 GMT, January 1, 1970. The standard
1073 Attributes do not use this data type but it is presented
1074 here for possible use within Vendor-Specific attributes.
1080 This Attribute indicates the name of the user to be authenticated.
1081 It is only used in Access-Request packets.
1083 A summary of the User-Name Attribute format is shown below. The
1084 fields are transmitted from left to right.
1087 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1089 | Type | Length | String ...
1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1102 The String field is one or more octets. The NAS may limit the
1103 maximum length of the User-Name but the ability to handle at least
1104 63 octets is recommended.
1122 Rigney, et. al. Informational [Page 20]
1124 RFC 2058 RADIUS January 1997
1127 The format of the username MAY be one of several forms:
1129 monolithic Consisting only of alphanumeric characters. This
1130 simple form might be used to locally manage a NAS.
1132 simple Consisting only of printable ASCII characters.
1134 name@fqdn SMTP address. The Fully Qualified Domain Name (with or
1135 without trailing dot) indicates the realm in which the
1139 A name in ASN.1 form used in Public Key authentication
1146 This Attribute indicates the password of the user to be
1147 authenticated, or the user's input following an Access-Challenge.
1148 It is only used in Access-Request packets.
1150 On transmission, the password is hidden. The password is first
1151 padded at the end with nulls to a multiple of 16 octets. A one-way
1152 MD5 hash is calculated over a stream of octets consisting of the
1153 shared secret followed by the Request Authenticator. This value is
1154 XORed with the first 16 octet segment of the password and placed in
1155 the first 16 octets of the String field of the User-Password
1158 If the password is longer than 16 characters, a second one-way MD5
1159 hash is calculated over a stream of octets consisting of the shared
1160 secret followed by the result of the first xor. That hash is XORed
1161 with the second 16 octet segment of the password and placed in the
1162 second 16 octets of the String field of the User-Password
1165 If necessary, this operation is repeated, with each xor result
1166 being used along with the shared secret to generate the next hash
1167 to xor the next segment of the password, to no more than 128
1170 The method is taken from the book "Network Security" by Kaufman,
1171 Perlman and Speciner [4] pages 109-110. A more precise explanation
1172 of the method follows:
1178 Rigney, et. al. Informational [Page 21]
1180 RFC 2058 RADIUS January 1997
1183 Call the shared secret S and the pseudo-random 128-bit Request
1184 Authenticator RA. Break the password into 16-octet chunks p1, p2,
1185 etc. with the last one padded at the end with nulls to a 16-octet
1186 boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
1187 intermediate values b1, b2, etc.
1189 b1 = MD5(S + RA) c(1) = p1 xor b1
1190 b2 = MD5(S + c(1)) c(2) = p2 xor b2
1194 bi = MD5(S + c(i-1)) c(i) = pi xor bi
1197 The String will contain c(1)+c(2)+...+c(i) where + denotes
1200 On receipt, the process is reversed to yield the original password.
1202 A summary of the User-Password Attribute format is shown below. The
1203 fields are transmitted from left to right.
1206 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1208 | Type | Length | String ...
1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1213 2 for User-Password.
1217 At least 18 and no larger than 130.
1221 The String field is between 16 and 128 octets long, inclusive.
1227 This Attribute indicates the response value provided by a PPP
1228 Challenge-Handshake Authentication Protocol (CHAP) user in response
1229 to the challenge. It is only used in Access-Request packets.
1234 Rigney, et. al. Informational [Page 22]
1236 RFC 2058 RADIUS January 1997
1239 The CHAP challenge value is found in the CHAP-Challenge Attribute
1240 (60) if present in the packet, otherwise in the Request
1241 Authenticator field.
1243 A summary of the CHAP-Password Attribute format is shown below. The
1244 fields are transmitted from left to right.
1247 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
1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1249 | Type | Length | CHAP Ident | String ...
1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1255 3 for CHAP-Password.
1263 This field is one octet, and contains the CHAP Identifier from the
1264 user's CHAP Response.
1268 The String field is 16 octets, and contains the CHAP Response from
1276 This Attribute indicates the identifying IP Address of the NAS
1277 which is requesting authentication of the user. It is only used in
1278 Access-Request packets. Either NAS-IP-Address or NAS-Identifier
1279 SHOULD be present in an Access-Request packet.
1290 Rigney, et. al. Informational [Page 23]
1292 RFC 2058 RADIUS January 1997
1295 A summary of the NAS-IP-Address Attribute format is shown below. The
1296 fields are transmitted from left to right.
1299 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
1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1301 | Type | Length | Address
1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1309 4 for NAS-IP-Address.
1317 The Address field is four octets.
1323 This Attribute indicates the physical port number of the NAS which
1324 is authenticating the user. It is only used in Access-Request
1325 packets. Note that this is using "port" in its sense of a physical
1326 connection on the NAS, not in the sense of a TCP or UDP port
1327 number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be
1328 present in an Access-Request packet, if the NAS differentiates
1346 Rigney, et. al. Informational [Page 24]
1348 RFC 2058 RADIUS January 1997
1351 A summary of the NAS-Port 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 | Value
1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1372 The Value field is four octets. Despite the size of the field,
1373 values range from 0 to 65535.
1380 This Attribute indicates the type of service the user has
1381 requested, or the type of service to be provided. It MAY be used
1382 in both Access-Request and Access-Accept packets. A NAS is not
1383 required to implement all of these service types, and MUST treat
1384 unknown or unsupported Service-Types as though an Access-Reject had
1385 been received instead.
1387 A summary of the Service-Type Attribute format is shown below. The
1388 fields are transmitted from left to right.
1391 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
1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1393 | Type | Length | Value
1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1402 Rigney, et. al. Informational [Page 25]
1404 RFC 2058 RADIUS January 1997
1417 The Value field is four octets.
1427 9 Callback NAS Prompt
1429 The service types are defined as follows when used in an Access-
1430 Accept. When used in an Access-Request, they should be considered
1431 to be a hint to the RADIUS server that the NAS has reason to
1432 believe the user would prefer the kind of service indicated, but
1433 the server is not required to honor the hint.
1435 Login The user should be connected to a host.
1437 Framed A Framed Protocol should be started for the
1438 User, such as PPP or SLIP.
1440 Callback Login The user should be disconnected and called
1441 back, then connected to a host.
1443 Callback Framed The user should be disconnected and called
1444 back, then a Framed Protocol should be started
1445 for the User, such as PPP or SLIP.
1447 Outbound The user should be granted access to outgoing
1450 Administrative The user should be granted access to the
1451 administrative interface to the NAS from which
1452 privileged commands can be executed.
1458 Rigney, et. al. Informational [Page 26]
1460 RFC 2058 RADIUS January 1997
1463 NAS Prompt The user should be provided a command prompt
1464 on the NAS from which non-privileged commands
1467 Authenticate Only Only Authentication is requested, and no
1468 authorization information needs to be returned
1469 in the Access-Accept (typically used by proxy
1470 servers rather than the NAS itself).
1472 Callback NAS Prompt The user should be disconnected and called
1473 back, then provided a command prompt on the
1474 NAS from which non-privileged commands can be
1478 5.7. Framed-Protocol
1482 This Attribute indicates the framing to be used for framed access.
1483 It MAY be used in both Access-Request and Access-Accept packets.
1485 A summary of the Framed-Protocol Attribute format is shown below.
1486 The fields are transmitted from left to right.
1489 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
1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1491 | Type | Length | Value
1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1499 7 for Framed-Protocol.
1514 Rigney, et. al. Informational [Page 27]
1516 RFC 2058 RADIUS January 1997
1521 The Value field is four octets.
1525 3 AppleTalk Remote Access Protocol (ARAP)
1526 4 Gandalf proprietary SingleLink/MultiLink protocol
1527 5 Xylogics proprietary IPX/SLIP
1529 5.8. Framed-IP-Address
1533 This Attribute indicates the address to be configured for the
1534 user. It MAY be used in Access-Accept packets. It MAY be used in
1535 an Access-Request packet as a hint by the NAS to the server that
1536 it would prefer that address, but the server is not required to
1539 A summary of the Framed-IP-Address Attribute format is shown below.
1540 The fields are transmitted from left to right.
1543 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
1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545 | Type | Length | Address
1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1553 8 for Framed-IP-Address.
1561 The Address field is four octets. The value 0xFFFFFFFF indicates
1562 that the NAS should allow the user to select an address (e.g.
1563 Negotiated). The value 0xFFFFFFFE indicates that the NAS should
1564 select an address for the user (e.g. Assigned from a pool of
1565 addresses kept by the NAS). Other valid values indicate that the
1566 NAS should use that value as the user's IP address.
1570 Rigney, et. al. Informational [Page 28]
1572 RFC 2058 RADIUS January 1997
1575 5.9. Framed-IP-Netmask
1579 This Attribute indicates the IP netmask to be configured for the
1580 user when the user is a router to a network. It MAY be used in
1581 Access-Accept packets. It MAY be used in an Access-Request packet
1582 as a hint by the NAS to the server that it would prefer that
1583 netmask, but the server is not required to honor the hint.
1585 A summary of the Framed-IP-Netmask 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1599 9 for Framed-IP-Netmask.
1607 The Address field is four octets specifying the IP netmask of the
1610 5.10. Framed-Routing
1614 This Attribute indicates the routing method for the user, when the
1615 user is a router to a network. It is only used in Access-Accept
1626 Rigney, et. al. Informational [Page 29]
1628 RFC 2058 RADIUS January 1997
1631 A summary of the Framed-Routing Attribute format is shown below. The
1632 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 | Value
1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1644 10 for Framed-Routing.
1652 The Value field is four octets.
1655 1 Send routing packets
1656 2 Listen for routing packets
1663 This Attribute indicates the name of the filter list for this
1664 user. Zero or more Filter-Id attributes MAY be sent in an
1665 Access-Accept packet.
1667 Identifying a filter list by name allows the filter to be used on
1668 different NASes without regard to filter-list implementation
1671 A summary of the Filter-Id Attribute format is shown below. The
1672 fields are transmitted from left to right.
1675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1677 | Type | Length | String ...
1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1682 Rigney, et. al. Informational [Page 30]
1684 RFC 2058 RADIUS January 1997
1697 The String field is one or more octets, and its contents are
1698 implementation dependent. It is intended to be human readable and
1699 MUST NOT affect operation of the protocol. It is recommended that
1700 the message contain displayable ASCII characters from the range 32
1701 through 126 decimal.
1707 This Attribute indicates the Maximum Transmission Unit to be
1708 configured for the user, when it is not negotiated by some other
1709 means (such as PPP). It is only used in Access-Accept packets.
1711 A summary of the Framed-MTU Attribute format is shown below. The
1712 fields are transmitted from left to right.
1715 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
1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1717 | Type | Length | Value
1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1733 The Value field is four octets. Despite the size of the field,
1734 values range from 64 to 65535.
1738 Rigney, et. al. Informational [Page 31]
1740 RFC 2058 RADIUS January 1997
1743 5.13. Framed-Compression
1747 This Attribute indicates a compression protocol to be used for the
1748 link. It MAY be used in Access-Accept packets. It MAY be used in
1749 an Access-Request packet as a hint to the server that the NAS would
1750 prefer to use that compression, but the server is not required to
1753 More than one compression protocol Attribute MAY be sent. It is
1754 the responsibility of the NAS to apply the proper compression
1755 protocol to appropriate link traffic.
1757 A summary of the Framed-Compression Attribute format is shown below.
1758 The fields are transmitted from left to right.
1761 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
1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1763 | Type | Length | Value
1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1771 13 for Framed-Compression.
1779 The Value field is four octets.
1782 1 VJ TCP/IP header compression [5]
1783 2 IPX header compression
1794 Rigney, et. al. Informational [Page 32]
1796 RFC 2058 RADIUS January 1997
1803 This Attribute indicates the system with which to connect the
1804 user, when the Login-Service Attribute is included. It MAY be
1805 used in Access-Accept packets. It MAY be used in an Access-
1806 Request packet as a hint to the server that the NAS would prefer
1807 to use that host, but the server is not required to honor the
1810 A summary of the Login-IP-Host Attribute format is shown below. The
1811 fields are transmitted from left to right.
1814 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
1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1816 | Type | Length | Address
1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1824 14 for Login-IP-Host.
1832 The Address field is four octets. The value 0xFFFFFFFF indicates
1833 that the NAS SHOULD allow the user to select an address. The
1834 value 0 indicates that the NAS SHOULD select a host to connect the
1835 user to. Other values indicate the address the NAS SHOULD connect
1842 This Attribute indicates the service which should be used to
1843 connect the user to the login host. It is only used in Access-
1850 Rigney, et. al. Informational [Page 33]
1852 RFC 2058 RADIUS January 1997
1855 A summary of the Login-Service Attribute format is shown below. The
1856 fields are transmitted from left to right.
1859 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
1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1861 | Type | Length | Value
1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1869 15 for Login-Service.
1877 The Value field is four octets.
1882 3 PortMaster (proprietary)
1885 5.16. Login-TCP-Port
1889 This Attribute indicates the TCP port with which the user is to be
1890 connected, when the Login-Service Attribute is also present. It
1891 is only used in Access-Accept packets.
1893 A summary of the Login-TCP-Port Attribute format is shown below. The
1894 fields are transmitted from left to right.
1897 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
1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1899 | Type | Length | Value
1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1906 Rigney, et. al. Informational [Page 34]
1908 RFC 2058 RADIUS January 1997
1913 16 for Login-TCP-Port.
1921 The Value field is four octets. Despite the size of the field,
1922 values range from 0 to 65535.
1928 ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
1934 This Attribute indicates text which MAY be displayed to the user.
1936 When used in an Access-Accept, it is the success message.
1938 When used in an Access-Reject, it is the failure message. It MAY
1939 indicate a dialog message to prompt the user before another
1940 Access-Request attempt.
1942 When used in an Access-Challenge, it MAY indicate a dialog message
1943 to prompt the user for a response.
1945 Multiple Reply-Message's MAY be included and if any are displayed,
1946 they MUST be displayed in the same order as they appear in the
1949 A summary of the Reply-Message Attribute format is shown below. The
1950 fields are transmitted from left to right.
1953 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1955 | Type | Length | String ...
1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1962 Rigney, et. al. Informational [Page 35]
1964 RFC 2058 RADIUS January 1997
1969 18 for Reply-Message.
1977 The String field is one or more octets, and its contents are
1978 implementation dependent. It is intended to be human readable,
1979 and MUST NOT affect operation of the protocol. It is recommended
1980 that the message contain displayable ASCII characters from the
1981 range 10, 13, and 32 through 126 decimal. Mechanisms for
1982 extension to other character sets are beyond the scope of this
1985 5.19. Callback-Number
1989 This Attribute indicates a dialing string to be used for callback.
1990 It MAY be used in Access-Accept packets. It MAY be used in an
1991 Access-Request packet as a hint to the server that a Callback
1992 service is desired, but the server is not required to honor the
1995 A summary of the Callback-Number Attribute format is shown below.
1996 The fields are transmitted from left to right.
1999 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2001 | Type | Length | String ...
2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2007 19 for Callback-Number.
2018 Rigney, et. al. Informational [Page 36]
2020 RFC 2058 RADIUS January 1997
2025 The String field is one or more octets. The actual format of the
2026 information is site or application specific, and a robust
2027 implementation SHOULD support the field as undistinguished octets.
2029 The codification of the range of allowed usage of this field is
2030 outside the scope of this specification.
2036 This Attribute indicates the name of a place to be called, to be
2037 interpreted by the NAS. It MAY be used in Access-Accept packets.
2039 A summary of the Callback-Id Attribute format is shown below. The
2040 fields are transmitted from left to right.
2043 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2045 | Type | Length | String ...
2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2059 The String field is one or more octets. The actual format of the
2060 information is site or application specific, and a robust
2061 implementation SHOULD support the field as undistinguished octets.
2063 The codification of the range of allowed usage of this field is
2064 outside the scope of this specification.
2070 ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
2074 Rigney, et. al. Informational [Page 37]
2076 RFC 2058 RADIUS January 1997
2083 This Attribute provides routing information to be configured for
2084 the user on the NAS. It is used in the Access-Accept packet and
2085 can appear multiple times.
2087 A summary of the Framed-Route Attribute format is shown below. The
2088 fields are transmitted from left to right.
2091 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2093 | Type | Length | String...
2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2099 22 for Framed-Route.
2107 The String field is one or more octets, and its contents are
2108 implementation dependent. It is intended to be human readable and
2109 MUST NOT affect operation of the protocol. It is recommended that
2110 the message contain displayable ASCII characters from the range 32
2111 through 126 decimal.
2113 For IP routes, it SHOULD contain a destination prefix in dotted
2114 quad form optionally followed by a slash and a decimal length
2115 specifier stating how many high order bits of the prefix should
2116 be used. That is followed by a space, a gateway address in
2117 dotted quad form, a space, and one or more metrics separated by
2118 spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400".
2119 The length specifier may be omitted in which case it should
2120 default to 8 bits for class A prefixes, 16 bits for class B
2121 prefixes, and 24 bits for class C prefixes. For example,
2122 "192.168.1.0 192.168.1.1 1".
2124 Whenever the gateway address is specified as "0.0.0.0" the IP
2125 address of the user SHOULD be used as the gateway address.
2130 Rigney, et. al. Informational [Page 38]
2132 RFC 2058 RADIUS January 1997
2135 5.23. Framed-IPX-Network
2139 This Attribute indicates the IPX Network number to be configured
2140 for the user. It is used in Access-Accept packets.
2142 A summary of the Framed-IPX-Network Attribute format is shown below.
2143 The fields are transmitted from left to right.
2146 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
2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2148 | Type | Length | Value
2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2156 23 for Framed-IPX-Network.
2164 The Value field is four octets. The value 0xFFFFFFFE indicates
2165 that the NAS should select an IPX network for the user (e.g.
2166 assigned from a pool of one or more IPX networks kept by the NAS).
2167 Other values should be used as the IPX network for the link to the
2174 This Attribute is available to be sent by the server to the client
2175 in an Access-Challenge and MUST be sent unmodified from the client
2176 to the server in the new Access-Request reply to that challenge,
2179 This Attribute is available to be sent by the server to the client
2180 in an Access-Accept that also includes a Termination-Action
2181 Attribute with the value of RADIUS-Request. If the NAS performs
2182 the Termination-Action by sending a new Access-Request upon
2186 Rigney, et. al. Informational [Page 39]
2188 RFC 2058 RADIUS January 1997
2191 termination of the current session, it MUST include the State
2192 attribute unchanged in that Access-Request.
2194 In either usage, no interpretation by the client should be made.
2195 A packet may have only one State Attribute. Usage of the State
2196 Attribute is implementation dependent.
2198 A summary of the State Attribute format is shown below. The fields
2199 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
2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2204 | Type | Length | String ...
2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2218 The String field is one or more octets. The actual format of the
2219 information is site or application specific, and a robust
2220 implementation SHOULD support the field as undistinguished octets.
2222 The codification of the range of allowed usage of this field is
2223 outside the scope of this specification.
2229 This Attribute is available to be sent by the server to the client
2230 in an Access-Accept and should be sent unmodified by the client to
2231 the accounting server as part of the Accounting-Request packet if
2232 accounting is supported. No interpretation by the client should
2242 Rigney, et. al. Informational [Page 40]
2244 RFC 2058 RADIUS January 1997
2247 A summary of the Class Attribute format is shown below. The fields
2248 are transmitted from left to right.
2251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2253 | Type | Length | String ...
2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2266 The String field is one or more octets. The actual format of the
2267 information is site or application specific, and a robust
2268 implementation SHOULD support the field as undistinguished octets.
2269 The codification of the range of allowed usage of this field is
2270 outside the scope of this specification.
2272 5.26. Vendor-Specific
2276 This Attribute is available to allow vendors to support their own
2277 extended Attributes not suitable for general usage. It MUST not
2278 affect the operation of the RADIUS protocol.
2280 Servers not equipped to interpret the vendor-specific information
2281 sent by a client MUST ignore it (although it may be reported).
2282 Clients which do not receive desired vendor-specific information
2283 SHOULD make an attempt to operate without it, although they may do
2284 so (and report they are doing so) in a degraded mode.
2298 Rigney, et. al. Informational [Page 41]
2300 RFC 2058 RADIUS January 1997
2303 A summary of the Vendor-Specific Attribute format is shown below.
2304 The fields 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 2 3 4 5 6 7 8 9 0 1
2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2309 | Type | Length | Vendor-Id
2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2311 Vendor-Id (cont) | String...
2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2317 26 for Vendor-Specific.
2325 The high-order octet is 0 and the low-order 3 octets are the SMI
2326 Network Management Private Enterprise Code of the Vendor in
2327 network byte order, as defined in the Assigned Numbers RFC [2].
2331 The String field is one or more octets. The actual format of the
2332 information is site or application specific, and a robust
2333 implementation SHOULD support the field as undistinguished octets.
2335 The codification of the range of allowed usage of this field is
2336 outside the scope of this specification.
2354 Rigney, et. al. Informational [Page 42]
2356 RFC 2058 RADIUS January 1997
2359 It SHOULD be encoded as a sequence of vendor type / vendor length
2360 / value fields, as follows. The Attribute-Specific field is
2361 dependent on the vendor's definition of that attribute. An
2362 example encoding of the Vendor-Specific attribute using this
2366 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
2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2368 | Type | Length | Vendor-Id
2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2370 Vendor-Id (cont) | Vendor type | Vendor length |
2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2372 | Attribute-Specific...
2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2375 5.27. Session-Timeout
2379 This Attribute sets the maximum number of seconds of service to be
2380 provided to the user before termination of the session or prompt.
2381 This Attribute is available to be sent by the server to the client
2382 in an Access-Accept or Access-Challenge.
2384 A summary of the Session-Timeout Attribute format is shown below.
2385 The fields are transmitted from left to right.
2388 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
2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2390 | Type | Length | Value
2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2397 27 for Session-Timeout.
2410 Rigney, et. al. Informational [Page 43]
2412 RFC 2058 RADIUS January 1997
2417 The field is 4 octets, containing a 32-bit unsigned integer with
2418 the maximum number of seconds this user should be allowed to
2419 remain connected by the NAS.
2425 This Attribute sets the maximum number of consecutive seconds of
2426 idle connection allowed to the user before termination of the
2427 session or prompt. This Attribute is available to be sent by the
2428 server to the client in an Access-Accept or Access-Challenge.
2430 A summary of the Idle-Timeout Attribute format is shown below. The
2431 fields are transmitted from left to right.
2434 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
2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2436 | Type | Length | Value
2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2443 28 for Idle-Timeout.
2451 The field is 4 octets, containing a 32-bit unsigned integer with
2452 the maximum number of consecutive seconds of idle time this user
2453 should be permitted before being disconnected by the NAS.
2455 5.29. Termination-Action
2459 This Attribute indicates what action the NAS should take when the
2460 specified service is completed. It is only used in Access-Accept
2466 Rigney, et. al. Informational [Page 44]
2468 RFC 2058 RADIUS January 1997
2471 A summary of the Termination-Action Attribute format is shown below.
2472 The 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2485 29 for Termination-Action.
2493 The Value field is four octets.
2499 If the Value is set to RADIUS-Request, upon termination of the
2500 specified service the NAS MAY send a new Access-Request to the
2501 RADIUS server, including the State attribute if any.
2503 5.30. Called-Station-Id
2507 This Attribute allows the NAS to send in the Access-Request
2508 packet the phone number that the user called, using Dialed
2509 Number Identification (DNIS) or similar technology. Note that
2510 this may be different from the phone number the call comes in
2511 on. It is only used in Access-Request packets.
2522 Rigney, et. al. Informational [Page 45]
2524 RFC 2058 RADIUS January 1997
2527 A summary of the Called-Station-Id Attribute format is shown below.
2528 The fields are transmitted from left to right.
2531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2533 | Type | Length | String ...
2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2539 30 for Called-Station-Id.
2547 The String field is one or more octets, containing the phone
2548 number that the user's call came in on.
2550 The actual format of the information is site or application
2551 specific. Printable ASCII is recommended, but a robust
2552 implementation SHOULD support the field as undistinguished octets.
2554 The codification of the range of allowed usage of this field is
2555 outside the scope of this specification.
2557 5.31. Calling-Station-Id
2561 This Attribute allows the NAS to send in the Access-Request
2562 packet the phone number that the call came from, using Automatic
2563 Number Identification (ANI) or similar technology. It is only
2564 used in Access-Request packets.
2566 A summary of the Calling-Station-Id Attribute format is shown below.
2567 The fields are transmitted from left to right.
2570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2572 | Type | Length | String ...
2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2578 Rigney, et. al. Informational [Page 46]
2580 RFC 2058 RADIUS January 1997
2585 31 for Calling-Station-Id.
2593 The String field is one or more octets, containing the phone
2594 number that the user placed the call from.
2596 The actual format of the information is site or application
2597 specific. Printable ASCII is recommended, but a robust
2598 implementation SHOULD support the field as undistinguished octets.
2600 The codification of the range of allowed usage of this field is
2601 outside the scope of this specification.
2603 5.32. NAS-Identifier
2607 This Attribute contains a string identifying the NAS originating
2608 the Access-Request. It is only used in Access-Request packets.
2609 Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
2610 Access-Request packet.
2612 A summary of the NAS-Identifier Attribute format is shown below. The
2613 fields are transmitted from left to right.
2616 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2618 | Type | Length | String ...
2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2624 32 for NAS-Identifier.
2634 Rigney, et. al. Informational [Page 47]
2636 RFC 2058 RADIUS January 1997
2641 The String field is one or more octets, and should be unique to
2642 the NAS within the scope of the RADIUS server. For example, a
2643 fully qualified domain name would be suitable as a NAS-Identifier.
2645 The actual format of the information is site or application
2646 specific, and a robust implementation SHOULD support the field as
2647 undistinguished octets.
2649 The codification of the range of allowed usage of this field is
2650 outside the scope of this specification.
2656 This Attribute is available to be sent by a proxy server to
2657 another server when forwarding an Access-Request and MUST be
2658 returned unmodified in the Access-Accept, Access-Reject or
2659 Access-Challenge. This attribute should be removed by the proxy
2660 server before the response is forwarded to the NAS.
2662 Usage of the Proxy-State Attribute is implementation dependent. A
2663 description of its function is outside the scope of this
2666 A summary of the Proxy-State Attribute format is shown below. The
2667 fields are transmitted from left to right.
2670 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2672 | Type | Length | String ...
2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2690 Rigney, et. al. Informational [Page 48]
2692 RFC 2058 RADIUS January 1997
2697 The String field is one or more octets. The actual format of the
2698 information is site or application specific, and a robust
2699 implementation SHOULD support the field as undistinguished octets.
2701 The codification of the range of allowed usage of this field is
2702 outside the scope of this specification.
2704 5.34. Login-LAT-Service
2708 This Attribute indicates the system with which the user is to be
2709 connected by LAT. It MAY be used in Access-Accept packets, but
2710 only when LAT is specified as the Login-Service. It MAY be used
2711 in an Access-Request packet as a hint to the server, but the
2712 server is not required to honor the hint.
2714 Administrators use the service attribute when dealing with
2715 clustered systems, such as a VAX or Alpha cluster. In such an
2716 environment several different time sharing hosts share the same
2717 resources (disks, printers, etc.), and administrators often
2718 configure each to offer access (service) to each of the shared
2719 resources. In this case, each host in the cluster advertises its
2720 services through LAT broadcasts.
2722 Sophisticated users often know which service providers (machines)
2723 are faster and tend to use a node name when initiating a LAT
2724 connection. Alternately, some administrators want particular
2725 users to use certain machines as a primitive form of load
2726 balancing (although LAT knows how to do load balancing itself).
2728 A summary of the Login-LAT-Service Attribute format is shown below.
2729 The fields are transmitted from left to right.
2732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2734 | Type | Length | String ...
2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2740 34 for Login-LAT-Service.
2746 Rigney, et. al. Informational [Page 49]
2748 RFC 2058 RADIUS January 1997
2757 The String field is one or more octets, and contains the identity
2758 of the LAT service to use. The LAT Architecture allows this
2759 string to contain $ (dollar), - (hyphen), . (period), _
2760 (underscore), numerics, upper and lower case alphabetics, and the
2761 ISO Latin-1 character set extension [6]. All LAT string
2762 comparisons are case insensitive.
2764 5.35. Login-LAT-Node
2768 This Attribute indicates the Node with which the user is to be
2769 automatically connected by LAT. It MAY be used in Access-Accept
2770 packets, but only when LAT is specified as the Login-Service. It
2771 MAY be used in an Access-Request packet as a hint to the server,
2772 but the server is not required to honor the hint.
2774 A summary of the Login-LAT-Node Attribute format is shown below. The
2775 fields are transmitted from left to right.
2778 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2780 | Type | Length | String ...
2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2786 35 for Login-LAT-Node.
2802 Rigney, et. al. Informational [Page 50]
2804 RFC 2058 RADIUS January 1997
2809 The String field is one or more octets, and contains the identity
2810 of the LAT Node to connect the user to. The LAT Architecture
2811 allows this string to contain $ (dollar), - (hyphen), . (period),
2812 _ (underscore), numerics, upper and lower case alphabetics, and
2813 the ISO Latin-1 character set extension. All LAT string
2814 comparisons are case insensitive.
2816 5.36. Login-LAT-Group
2820 This Attribute contains a string identifying the LAT group codes
2821 which this user is authorized to use. It MAY be used in Access-
2822 Accept packets, but only when LAT is specified as the Login-
2823 Service. It MAY be used in an Access-Request packet as a hint to
2824 the server, but the server is not required to honor the hint.
2826 LAT supports 256 different group codes, which LAT uses as a form
2827 of access rights. LAT encodes the group codes as a 256 bit
2830 Administrators can assign one or more of the group code bits at
2831 the LAT service provider; it will only accept LAT connections that
2832 have these group codes set in the bit map. The administrators
2833 assign a bitmap of authorized group codes to each user; LAT gets
2834 these from the operating system, and uses these in its requests to
2835 the service providers.
2837 A summary of the Login-LAT-Group Attribute format is shown below.
2838 The fields are transmitted from left to right.
2841 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2843 | Type | Length | String ...
2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2849 36 for Login-LAT-Group.
2858 Rigney, et. al. Informational [Page 51]
2860 RFC 2058 RADIUS January 1997
2865 The String field is a 32 octet bit map, most significant octet
2866 first. A robust implementation SHOULD support the field as
2867 undistinguished octets.
2869 The codification of the range of allowed usage of this field is
2870 outside the scope of this specification.
2872 5.37. Framed-AppleTalk-Link
2876 This Attribute indicates the AppleTalk network number which should
2877 be used for the serial link to the user, which is another
2878 AppleTalk router. It is only used in Access-Accept packets. It
2879 is never used when the user is not another router.
2881 A summary of the Framed-AppleTalk-Link Attribute format is shown
2882 below. The fields are transmitted from left to right.
2885 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
2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2887 | Type | Length | Value
2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2894 37 for Framed-AppleTalk-Link.
2902 The Value field is four octets. Despite the size of the field,
2903 values range from 0 to 65535. The special value of 0 indicates
2904 that this is an unnumbered serial link. A value of 1-65535 means
2905 that the serial line between the NAS and the user should be
2906 assigned that value as an AppleTalk network number.
2914 Rigney, et. al. Informational [Page 52]
2916 RFC 2058 RADIUS January 1997
2919 5.38. Framed-AppleTalk-Network
2923 This Attribute indicates the AppleTalk Network number which the
2924 NAS should probe to allocate an AppleTalk node for the user. It
2925 is only used in Access-Accept packets. It is never used when the
2926 user is another router. Multiple instances of this Attribute
2927 indicate that the NAS may probe using any of the network numbers
2930 A summary of the Framed-AppleTalk-Network Attribute format is shown
2931 below. The fields are transmitted from left to right.
2934 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
2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2936 | Type | Length | Value
2937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2944 38 for Framed-AppleTalk-Network.
2952 The Value field is four octets. Despite the size of the field,
2953 values range from 0 to 65535. The special value 0 indicates that
2954 the NAS should assign a network for the user, using its default
2955 cable range. A value between 1 and 65535 (inclusive) indicates
2956 the AppleTalk Network the NAS should probe to find an address for
2959 5.39. Framed-AppleTalk-Zone
2963 This Attribute indicates the AppleTalk Default Zone to be used for
2964 this user. It is only used in Access-Accept packets. Multiple
2965 instances of this attribute in the same packet are not allowed.
2970 Rigney, et. al. Informational [Page 53]
2972 RFC 2058 RADIUS January 1997
2975 A summary of the Framed-AppleTalk-Zone Attribute format is shown
2976 below. The fields are transmitted from left to right.
2979 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
2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2981 | Type | Length | String ...
2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
2987 39 for Framed-AppleTalk-Zone.
2995 The name of the Default AppleTalk Zone to be used for this user.
2996 A robust implementation SHOULD support the field as
2997 undistinguished octets.
2999 The codification of the range of allowed usage of this field is
3000 outside the scope of this specification.
3002 5.40. CHAP-Challenge
3006 This Attribute contains the CHAP Challenge sent by the NAS to a
3007 PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
3008 is only used in Access-Request packets.
3010 If the CHAP challenge value is 16 octets long it MAY be placed in
3011 the Request Authenticator field instead of using this attribute.
3013 A summary of the CHAP-Challenge Attribute format is shown below. The
3014 fields are transmitted from left to right.
3017 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3019 | Type | Length | String...
3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3026 Rigney, et. al. Informational [Page 54]
3028 RFC 2058 RADIUS January 1997
3033 60 for CHAP-Challenge.
3041 The String field contains the CHAP Challenge.
3047 This Attribute indicates the type of the physical port of the NAS
3048 which is authenticating the user. It can be used instead of or in
3049 addition to the NAS-Port (5) attribute. It is only used in
3050 Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
3051 both SHOULD be present in an Access-Request packet, if the NAS
3052 differentiates among its ports.
3054 A summary of the NAS-Port-Type Attribute format is shown below. The
3055 fields are transmitted from left to right.
3058 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
3059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3060 | Type | Length | Value
3061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3068 61 for NAS-Port-Type.
3076 The Value field is four octets. "Virtual" refers to a connection
3077 to the NAS via some transport protocol, instead of through a
3078 physical port. For example, if a user telnetted into a NAS to
3082 Rigney, et. al. Informational [Page 55]
3084 RFC 2058 RADIUS January 1997
3087 authenticate himself as an Outbound-User, the Access-Request might
3088 include NAS-Port-Type = Virtual as a hint to the RADIUS server
3089 that the user was not on a physical port.
3102 This Attribute sets the maximum number of ports to be provided to
3103 the user by the NAS. This Attribute MAY be sent by the server to
3104 the client in an Access-Accept packet. It is intended for use in
3105 conjunction with Multilink PPP [7] or similar uses. It MAY also
3106 be sent by the NAS to the server as a hint that that many ports
3107 are desired for use, but the server is not required to honor the
3110 A summary of the Port-Limit Attribute format is shown below. The
3111 fields are transmitted from left to right.
3114 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
3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3116 | Type | Length | Value
3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3132 The field is 4 octets, containing a 32-bit unsigned integer with
3133 the maximum number of ports this user should be allowed to connect
3138 Rigney, et. al. Informational [Page 56]
3140 RFC 2058 RADIUS January 1997
3143 5.43. Login-LAT-Port
3147 This Attribute indicates the Port with which the user is to be
3148 connected by LAT. It MAY be used in Access-Accept packets, but
3149 only when LAT is specified as the Login-Service. It MAY be used
3150 in an Access-Request packet as a hint to the server, but the
3151 server is not required to honor the hint.
3153 A summary of the Login-LAT-Port Attribute format is shown below. The
3154 fields are transmitted from left to right.
3157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3159 | Type | Length | String ...
3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
3164 63 for Login-LAT-Port.
3172 The String field is one or more octets, and contains the identity
3173 of the LAT port to use. The LAT Architecture allows this string
3174 to contain $ (dollar), - (hyphen), . (period), _ (underscore),
3175 numerics, upper and lower case alphabetics, and the ISO Latin-1
3176 character set extension. All LAT string comparisons are case
3194 Rigney, et. al. Informational [Page 57]
3196 RFC 2058 RADIUS January 1997
3199 5.44. Table of Attributes
3201 The following table provides a guide to which attributes may be found
3202 in which kinds of packets, and in what quantity.
3204 Request Accept Reject Challenge # Attribute
3206 0-1 0 0 0 2 User-Password [Note 1]
3207 0-1 0 0 0 3 CHAP-Password [Note 1]
3208 0-1 0 0 0 4 NAS-IP-Address
3209 0-1 0 0 0 5 NAS-Port
3210 0-1 0-1 0 0 6 Service-Type
3211 0-1 0-1 0 0 7 Framed-Protocol
3212 0-1 0-1 0 0 8 Framed-IP-Address
3213 0-1 0-1 0 0 9 Framed-IP-Netmask
3214 0 0-1 0 0 10 Framed-Routing
3215 0 0+ 0 0 11 Filter-Id
3216 0 0-1 0 0 12 Framed-MTU
3217 0+ 0+ 0 0 13 Framed-Compression
3218 0+ 0+ 0 0 14 Login-IP-Host
3219 0 0-1 0 0 15 Login-Service
3220 0 0-1 0 0 16 Login-TCP-Port
3221 0 0+ 0+ 0+ 18 Reply-Message
3222 0-1 0-1 0 0 19 Callback-Number
3223 0 0-1 0 0 20 Callback-Id
3224 0 0+ 0 0 22 Framed-Route
3225 0 0-1 0 0 23 Framed-IPX-Network
3226 0-1 0-1 0 0-1 24 State
3228 0+ 0+ 0 0+ 26 Vendor-Specific
3229 0 0-1 0 0-1 27 Session-Timeout
3230 0 0-1 0 0-1 28 Idle-Timeout
3231 0 0-1 0 0 29 Termination-Action
3232 0-1 0 0 0 30 Called-Station-Id
3233 0-1 0 0 0 31 Calling-Station-Id
3234 0-1 0 0 0 32 NAS-Identifier
3235 0+ 0+ 0+ 0+ 33 Proxy-State
3236 0-1 0-1 0 0 34 Login-LAT-Service
3237 0-1 0-1 0 0 35 Login-LAT-Node
3238 0-1 0-1 0 0 36 Login-LAT-Group
3239 0 0-1 0 0 37 Framed-AppleTalk-Link
3240 0 0+ 0 0 38 Framed-AppleTalk-Network
3241 0 0-1 0 0 39 Framed-AppleTalk-Zone
3242 0-1 0 0 0 60 CHAP-Challenge
3243 0-1 0 0 0 61 NAS-Port-Type
3244 0-1 0-1 0 0 62 Port-Limit
3245 0-1 0-1 0 0 63 Login-LAT-Port
3246 Request Accept Reject Challenge # Attribute
3250 Rigney, et. al. Informational [Page 58]
3252 RFC 2058 RADIUS January 1997
3255 [Note 1] An Access-Request MUST contain either a User-Password or a
3256 CHAP-Password, and MUST NOT contain both.
3258 The following table defines the meaning of the above table entries.
3260 0 This attribute MUST NOT be present in packet.
3261 0+ Zero or more instances of this attribute MAY be present in packet.
3262 0-1 Zero or one instance of this attribute MAY be present in packet.
3263 1 Exactly one instance of this attribute MUST be present in packet.
3267 A few examples are presented to illustrate the flow of packets and
3268 use of typical attributes. These examples are not intended to be
3269 exhaustive, many others are possible.
3271 6.1. User Telnet to Specified Host
3273 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3274 RADIUS Server for a user named nemo logging in on port 3.
3276 Code = 1 (Access-Request)
3278 Request Authenticator = {16 octet random number}
3281 User-Password = {16 octets of Password padded at end with nulls,
3282 XORed with MD5(shared secret|Request Authenticator)}
3283 NAS-IP-Address = 192.168.1.16
3287 The RADIUS server authenticates nemo, and sends an Access-Accept UDP
3288 packet to the NAS telling it to telnet nemo to host 192.168.1.3.
3290 Code = 2 (Access-Accept)
3291 ID = 0 (same as in Access-Request)
3292 Response Authenticator = {16-octet MD-5 checksum of the code (2),
3293 id (0), the Request Authenticator from above, the
3294 attributes in this reply, and the shared secret}
3296 Service-Type = Login-User
3297 Login-Service = Telnet
3298 Login-Host = 192.168.1.3
3306 Rigney, et. al. Informational [Page 59]
3308 RFC 2058 RADIUS January 1997
3311 6.2. Framed User Authenticating with CHAP
3313 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3314 RADIUS Server for a user named flopsy logging in on port 20 with PPP,
3315 authenticating using CHAP. The NAS sends along the Service-Type and
3316 Framed-Protocol attributes as a hint to the RADIUS server that this
3317 user is looking for PPP, although the NAS is not required to do so.
3319 Code = 1 (Access-Request)
3321 Request Authenticator = {16 octet random number also used as
3324 User-Name = "flopsy"
3325 CHAP-Password = {1 octet CHAP ID followed by 16 octet
3327 NAS-IP-Address = 192.168.1.16
3329 Service-Type = Framed-User
3330 Framed-Protocol = PPP
3332 The RADIUS server authenticates flopsy, and sends an Access-Accept
3333 UDP packet to the NAS telling it to start PPP service and assign an
3334 address for the user out of its dynamic address pool.
3336 Code = 2 (Access-Accept)
3337 ID = 1 (same as in Access-Request)
3338 Response Authenticator = {16-octet MD-5 checksum of the code (2),
3339 id (1), the Request Authenticator from above, the
3340 attributes in this reply, and the shared secret}
3342 Service-Type = Framed-User
3343 Framed-Protocol = PPP
3344 Framed-IP-Address = 255.255.255.254
3345 Framed-Routing = None
3346 Framed-Compression = 1 (VJ TCP/IP Header Compression)
3362 Rigney, et. al. Informational [Page 60]
3364 RFC 2058 RADIUS January 1997
3367 6.3. User with Challenge-Response card
3369 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
3370 RADIUS Server for a user named mopsy logging in on port 7.
3372 Code = 1 (Access-Request)
3374 Request Authenticator = {16 octet random number}
3377 User-Password = {16 octets of Password padded at end with nulls,
3378 XORed with MD5(shared secret|Request Authenticator)}
3379 NAS-IP-Address = 192.168.1.16
3382 The RADIUS server decides to challenge mopsy, sending back a
3383 challenge string and looking for a response. The RADIUS server
3384 therefore and sends an Access-Challenge UDP packet to the NAS.
3386 Code = 11 (Access-Challenge}
3387 ID = 2 (same as in Access-Request)
3388 Response Authenticator = {16-octet MD-5 checksum of the code (11),
3389 id (2), the Request Authenticator from above, the
3390 attributes in this reply, and the shared secret}
3392 Reply-Message = "Challenge 32769430. Enter response at prompt."
3393 State = {Magic Cookie to be returned along with user's response}
3395 The user enters his response, and the NAS send a new Access-Request
3396 with that response, and includes the State Attribute.
3398 Code = 1 (Access-Request)
3399 ID = 3 (Note that this changes)
3400 Request Authenticator = {NEW 16 octet random number}
3403 User-Password = {16 octets of Response padded at end with
3404 nulls, XORed with MD5 checksum of shared secret
3405 plus above Request Authenticator}
3406 NAS-IP-Address = 192.168.1.16
3408 State = {Magic Cookie from Access-Challenge packet, unchanged}
3418 Rigney, et. al. Informational [Page 61]
3420 RFC 2058 RADIUS January 1997
3423 The Response was incorrect, so the RADIUS server tells the NAS to
3424 reject the login attempt.
3426 Code = 3 (Access-Reject)
3427 ID = 3 (same as in Access-Request)
3428 Response Authenticator = {16-octet MD-5 checksum of the code (3),
3429 id (3), the Request Authenticator from above, the
3430 attributes in this reply if any, and the shared
3433 (none, although a Reply-Message could be sent)
3435 Security Considerations
3437 Security issues are the primary topic of this document.
3439 In practice, within or associated with each RADIUS server, there is a
3440 database which associates "user" names with authentication
3441 information ("secrets"). It is not anticipated that a particular
3442 named user would be authenticated by multiple methods. This would
3443 make the user vulnerable to attacks which negotiate the least secure
3444 method from among a set. Instead, for each named user there should
3445 be an indication of exactly one method used to authenticate that user
3446 name. If a user needs to make use of different authentication
3447 methods under different circumstances, then distinct user names
3448 SHOULD be employed, each of which identifies exactly one
3449 authentication method.
3451 Passwords and other secrets should be stored at the respective ends
3452 such that access to them is as limited as possible. Ideally, the
3453 secrets should only be accessible to the process requiring access in
3454 order to perform the authentication.
3456 The secrets should be distributed with a mechanism that limits the
3457 number of entities that handle (and thus gain knowledge of) the
3458 secret. Ideally, no unauthorized person should ever gain knowledge
3459 of the secrets. It is possible to achieve this with SNMP Security
3460 Protocols [8], but such a mechanism is outside the scope of this
3463 Other distribution methods are currently undergoing research and
3464 experimentation. The SNMP Security document [8] also has an
3465 excellent overview of threats to network protocols.
3474 Rigney, et. al. Informational [Page 62]
3476 RFC 2058 RADIUS January 1997
3481 [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
3482 RFC 1321, MIT Laboratory for Computer Science, RSA Data
3483 Security Inc., April 1992.
3485 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
3486 USC/Information Sciences Institute, August 1980.
3488 [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
3489 1700, USC/Information Sciences Institute, October 1994.
3491 [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
3492 Private Communications in a Public World", Prentice Hall, March
3493 1995, ISBN 0-13-061466-1.
3495 [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
3496 links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
3498 [6] ISO 8859. International Standard -- Information Processing --
3499 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
3500 Alphabet No. 1, ISO 8859-1:1987.
3501 <URL:http://www.iso.ch/cate/d16338.html>
3503 [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
3504 Multilink Protocol (MP)", RFC 1717, University of California
3505 Berkeley, Lloyd Internetworking, Newbridge Networks
3506 Corporation, November 1994.
3508 [8] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
3509 Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
3510 LAN Systems, Inc., MIT Laboratory for Computer Science, July
3513 [9] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997.
3517 RADIUS was originally developed by Livingston Enterprises for their
3518 PortMaster series of Network Access Servers.
3530 Rigney, et. al. Informational [Page 63]
3532 RFC 2058 RADIUS January 1997
3537 The working group can be contacted via the current chair:
3540 Livingston Enterprises
3541 6920 Koll Center Parkway, Suite 220
3542 Pleasanton, California 94566
3544 Phone: +1 510 426 0770
3545 EMail: cdr@livingston.com
3549 Questions about this memo can also be directed to:
3552 Livingston Enterprises
3553 6920 Koll Center Parkway, Suite 220
3554 Pleasanton, California 94566
3556 Phone: +1 510 426 0770
3557 EMail: cdr@livingston.com
3563 Ann Arbor, Michigan 48105-2785
3565 EMail: acr@merit.edu
3568 William Allen Simpson
3570 Computer Systems Consulting Services
3572 Madison Heights, Michigan 48071
3574 EMail: wsimpson@greendragon.com
3578 Livingston Enterprises
3579 6920 Koll Center Parkway, Suite 220
3580 Pleasanton, California 94566
3582 EMail: steve@livingston.com
3586 Rigney, et. al. Informational [Page 64]
projects / freeradius.git / blob