idnits 2.17.1 draft-ietf-radius-radius-v2-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 11 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A forwarding server MAY need to modify attributes to enforce local policy. Such policy is outside the scope of this document, with the following restrictions. A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This Attribute is available to allow vendors to support their own extended Attributes not suitable for general usage. It MUST not affect the operation of the RADIUS protocol. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Note 1' on line 2948 -- Looks like a reference, but probably isn't: 'Note 2' on line 2927 ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2279 (ref. '7') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2434 (ref. '13') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Historic RFC: RFC 1352 (ref. '14') -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RADIUS Working Group C Rigney 2 INTERNET-DRAFT Livingston 3 A Rubens 4 Merit 5 W A Simpson 6 Daydreamer 7 S Willens 8 Livingston 9 expires August 2000 February 2000 11 Remote Authentication Dial In User Service (RADIUS) 12 draft-ietf-radius-radius-v2-05.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. 19 This document obsoletes RFC 2138 [1]. A summary of the changes 20 between this document and RFC 2138 is available in the "Change Log" 21 appendix. 23 This document is a submission to the RADIUS Working Group of the 24 Internet Engineering Task Force (IETF). Comments should be submitted 25 to the ietf-radius@livingston.com mailing list. 27 Distribution of this memo is unlimited. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet- Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Copyright Notice 47 Copyright (C) The Internet Society (2000). All Rights Reserved. 49 Abstract 51 This document describes a protocol for carrying authentication, 52 authorization, and configuration information between a Network Access 53 Server which desires to authenticate its links and a shared 54 Authentication Server. 56 Implementation Note 58 This memo documents the RADIUS protocol. The early deployment of 59 RADIUS was done using UDP port number 1645, which conflicts with the 60 "datametrics" service. The officially assigned port number for 61 RADIUS is 1812. 63 Table of Contents 65 1. Introduction .......................................... 5 66 1.1 Specification of Requirements ................... 6 67 1.2 Terminology ..................................... 6 69 2. Operation ............................................. 7 70 2.1 Challenge/Response .............................. 8 71 2.2 Interoperation with PAP and CHAP ................ 9 72 2.3 Proxy ........................................... 10 73 2.4 Why UDP? ........................................ 12 74 2.5 Retransmission Hints ............................ 14 75 2.6 Keep-Alives Considered Harmful .................. 14 77 3. Packet Format ......................................... 14 79 4. Packet Types .......................................... 17 80 4.1 Access-Request .................................. 18 81 4.2 Access-Accept ................................... 19 82 4.3 Access-Reject ................................... 20 83 4.4 Access-Challenge ................................ 21 85 5. Attributes ............................................ 23 86 5.1 User-Name ....................................... 26 87 5.2 User-Password ................................... 27 88 5.3 CHAP-Password ................................... 29 89 5.4 NAS-IP-Address .................................. 30 90 5.5 NAS-Port ........................................ 31 91 5.6 Service-Type .................................... 32 92 5.7 Framed-Protocol ................................. 34 93 5.8 Framed-IP-Address ............................... 35 94 5.9 Framed-IP-Netmask ............................... 35 95 5.10 Framed-Routing .................................. 36 96 5.11 Filter-Id ....................................... 37 97 5.12 Framed-MTU ...................................... 38 98 5.13 Framed-Compression .............................. 39 99 5.14 Login-IP-Host ................................... 40 100 5.15 Login-Service ................................... 40 101 5.16 Login-TCP-Port .................................. 41 102 5.17 (unassigned) .................................... 42 103 5.18 Reply-Message ................................... 42 104 5.19 Callback-Number ................................. 43 105 5.20 Callback-Id ..................................... 44 106 5.21 (unassigned) .................................... 45 107 5.22 Framed-Route .................................... 45 108 5.23 Framed-IPX-Network .............................. 46 109 5.24 State ........................................... 47 110 5.25 Class ........................................... 48 111 5.26 Vendor-Specific ................................. 49 112 5.27 Session-Timeout ................................. 50 113 5.28 Idle-Timeout .................................... 51 114 5.29 Termination-Action .............................. 52 115 5.30 Called-Station-Id ............................... 52 116 5.31 Calling-Station-Id .............................. 53 117 5.32 NAS-Identifier .................................. 54 118 5.33 Proxy-State ..................................... 55 119 5.34 Login-LAT-Service ............................... 56 120 5.35 Login-LAT-Node .................................. 57 121 5.36 Login-LAT-Group ................................. 58 122 5.37 Framed-AppleTalk-Link ........................... 59 123 5.38 Framed-AppleTalk-Network ........................ 60 124 5.39 Framed-AppleTalk-Zone ........................... 61 125 5.40 CHAP-Challenge .................................. 62 126 5.41 NAS-Port-Type ................................... 63 127 5.42 Port-Limit ...................................... 64 128 5.43 Login-LAT-Port .................................. 65 129 5.44 Table of Attributes ............................. 66 131 6. IANA Considerations ................................... 67 132 6.1 Definition of Terms ............................. 68 133 6.2 Recommended Registration Policies ............... 68 135 7. Examples .............................................. 69 136 7.1 User Telnet to Specified Host ................... 69 137 7.2 Framed User Authenticating with CHAP ............ 70 138 7.3 User with Challenge-Response card ............... 72 140 8. Security Considerations ............................... 74 141 9. Change Log ............................................ 75 143 10. References ............................................ 76 145 11. Acknowledgements ...................................... 77 147 12. Chair's Address ....................................... 77 149 13. Author's Address ...................................... 78 151 14. Full Copyright Statement .............................. 78 153 1. Introduction 155 This document obsoletes RFC 2138 [1]. A summary of the changes 156 between this document and RFC 2138 is available in the "Change Log" 157 appendix. 159 Managing dispersed serial line and modem pools for large numbers of 160 users can create the need for significant administrative support. 161 Since modem pools are by definition a link to the outside world, they 162 require careful attention to security, authorization and accounting. 163 This can be best achieved by managing a single "database" of users, 164 which allows for authentication (verifying user name and password) as 165 well as configuration information detailing the type of service to 166 deliver to the user (for example, SLIP, PPP, telnet, rlogin). 168 Key features of RADIUS are: 170 Client/Server Model 172 A Network Access Server (NAS) operates as a client of RADIUS. The 173 client is responsible for passing user information to designated 174 RADIUS servers, and then acting on the response which is returned. 176 RADIUS servers are responsible for receiving user connection 177 requests, authenticating the user, and then returning all 178 configuration information necessary for the client to deliver 179 service to the user. 181 A RADIUS server can act as a proxy client to other RADIUS servers 182 or other kinds of authentication servers. 184 Network Security 186 Transactions between the client and RADIUS server are 187 authenticated through the use of a shared secret, which is never 188 sent over the network. In addition, any user passwords are sent 189 encrypted between the client and RADIUS server, to eliminate the 190 possibility that someone snooping on an unsecure network could 191 determine a user's password. 193 Flexible Authentication Mechanisms 195 The RADIUS server can support a variety of methods to authenticate 196 a user. When it is provided with the user name and original 197 password given by the user, it can support PPP PAP or CHAP, UNIX 198 login, and other authentication mechanisms. 200 Extensible Protocol 202 All transactions are comprised of variable length Attribute- 203 Length-Value 3-tuples. New attribute values can be added without 204 disturbing existing implementations of the protocol. 206 1.1. Specification of Requirements 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in BCP 14 [2]. These key 211 words mean the same thing whether capitalized or not. 213 An implementation is not compliant if it fails to satisfy one or more 214 of the must or must not requirements for the protocols it implements. 215 An implementation that satisfies all the must, must not, should and 216 should not requirements for its protocols is said to be 217 "unconditionally compliant"; one that satisfies all the must and must 218 not requirements but not all the should or should not requirements 219 for its protocols is said to be "conditionally compliant." 221 A NAS that does not implement a given service MUST NOT implement the 222 RADIUS attributes for that service. For example, a NAS that is 223 unable to offer ARAP service MUST NOT implement the RADIUS attributes 224 for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an 225 unavailable service as an access-reject instead. 227 1.2. Terminology 229 This document frequently uses the following terms: 231 service The NAS provides a service to the dial-in user, such as PPP 232 or Telnet. 234 session Each service provided by the NAS to a dial-in user 235 constitutes a session, with the beginning of the session 236 defined as the point where service is first provided and 237 the end of the session defined as the point where service 238 is ended. A user may have multiple sessions in parallel or 239 series if the NAS supports that. 241 silently discard 242 This means the implementation discards the packet without 243 further processing. The implementation SHOULD provide the 244 capability of logging the error, including the contents of 245 the silently discarded packet, and SHOULD record the event 246 in a statistics counter. 248 2. Operation 250 When a client is configured to use RADIUS, any user of the client 251 presents authentication information to the client. This might be 252 with a customizable login prompt, where the user is expected to enter 253 their username and password. Alternatively, the user might use a 254 link framing protocol such as the Point-to-Point Protocol (PPP), 255 which has authentication packets which carry this information. 257 Once the client has obtained such information, it may choose to 258 authenticate using RADIUS. To do so, the client creates an "Access- 259 Request" containing such Attributes as the user's name, the user's 260 password, the ID of the client and the Port ID which the user is 261 accessing. When a password is present, it is hidden using a method 262 based on the RSA Message Digest Algorithm MD5 [3]. 264 The Access-Request is submitted to the RADIUS server via the network. 265 If no response is returned within a length of time, the request is 266 re-sent a number of times. The client can also forward requests to 267 an alternate server or servers in the event that the primary server 268 is down or unreachable. An alternate server can be used either after 269 a number of tries to the primary server fail, or in a round-robin 270 fashion. Retry and fallback algorithms are the topic of current 271 research and are not specified in detail in this document. 273 Once the RADIUS server receives the request, it validates the sending 274 client. A request from a client for which the RADIUS server does not 275 have a shared secret MUST be silently discarded. If the client is 276 valid, the RADIUS server consults a database of users to find the 277 user whose name matches the request. The user entry in the database 278 contains a list of requirements which must be met to allow access for 279 the user. This always includes verification of the password, but can 280 also specify the client(s) or port(s) to which the user is allowed 281 access. 283 The RADIUS server MAY make requests of other servers in order to 284 satisfy the request, in which case it acts as a client. 286 If any Proxy-State attributes were present in the Access-Request, 287 they MUST be copied unmodified and in order into the response packet. 288 Other Attributes can be placed before, after, or even between the 289 Proxy-State attributes. 291 If any condition is not met, the RADIUS server sends an "Access- 292 Reject" response indicating that this user request is invalid. If 293 desired, the server MAY include a text message in the Access-Reject 294 which MAY be displayed by the client to the user. No other 295 Attributes (except Proxy-State) are permitted in an Access-Reject. 297 If all conditions are met and the RADIUS server wishes to issue a 298 challenge to which the user must respond, the RADIUS server sends an 299 "Access-Challenge" response. It MAY include a text message to be 300 displayed by the client to the user prompting for a response to the 301 challenge, and MAY include a State attribute. 303 If the client receives an Access-Challenge and supports 304 challenge/response it MAY display the text message, if any, to the 305 user, and then prompt the user for a response. The client then 306 re-submits its original Access-Request with a new request ID, with 307 the User-Password Attribute replaced by the response (encrypted), 308 and including the State Attribute from the Access-Challenge, if 309 any. Only 0 or 1 instances of the State Attribute SHOULD be 310 present in a request. The server can respond to this new Access- 311 Request with either an Access-Accept, an Access-Reject, or another 312 Access-Challenge. 314 If all conditions are met, the list of configuration values for the 315 user are placed into an "Access-Accept" response. These values 316 include the type of service (for example: SLIP, PPP, Login User) and 317 all necessary values to deliver the desired service. For SLIP and 318 PPP, this may include values such as IP address, subnet mask, MTU, 319 desired compression, and desired packet filter identifiers. For 320 character mode users, this may include values such as desired 321 protocol and host. 323 2.1. Challenge/Response 325 In challenge/response authentication, the user is given an 326 unpredictable number and challenged to encrypt it and give back the 327 result. Authorized users are equipped with special devices such as 328 smart cards or software that facilitate calculation of the correct 329 response with ease. Unauthorized users, lacking the appropriate 330 device or software and lacking knowledge of the secret key necessary 331 to emulate such a device or software, can only guess at the response. 333 The Access-Challenge packet typically contains a Reply-Message 334 including a challenge to be displayed to the user, such as a numeric 335 value unlikely ever to be repeated. Typically this is obtained from 336 an external server that knows what type of authenticator is in the 337 possession of the authorized user and can therefore choose a random 338 or non-repeating pseudorandom number of an appropriate radix and 339 length. 341 The user then enters the challenge into his device (or software) and 342 it calculates a response, which the user enters into the client which 343 forwards it to the RADIUS server via a second Access-Request. If the 344 response matches the expected response the RADIUS server replies with 345 an Access-Accept, otherwise an Access-Reject. 347 Example: The NAS sends an Access-Request packet to the RADIUS Server 348 with NAS-Identifier, NAS-Port, User-Name, User-Password (which may 349 just be a fixed string like "challenge" or ignored). The server 350 sends back an Access-Challenge packet with State and a Reply-Message 351 along the lines of "Challenge 12345678, enter your response at the 352 prompt" which the NAS displays. The NAS prompts for the response and 353 sends a NEW Access-Request to the server (with a new ID) with NAS- 354 Identifier, NAS-Port, User-Name, User-Password (the response just 355 entered by the user, encrypted), and the same State Attribute that 356 came with the Access-Challenge. The server then sends back either an 357 Access-Accept or Access-Reject based on whether the response matches 358 the required value, or it can even send another Access-Challenge. 360 2.2. Interoperation with PAP and CHAP 362 For PAP, the NAS takes the PAP ID and password and sends them in an 363 Access-Request packet as the User-Name and User-Password. The NAS MAY 364 include the Attributes Service-Type = Framed-User and Framed-Protocol 365 = PPP as a hint to the RADIUS server that PPP service is expected. 367 For CHAP, the NAS generates a random challenge (preferably 16 octets) 368 and sends it to the user, who returns a CHAP response along with a 369 CHAP ID and CHAP username. The NAS then sends an Access-Request 370 packet to the RADIUS server with the CHAP username as the User-Name 371 and with the CHAP ID and CHAP response as the CHAP-Password 372 (Attribute 3). The random challenge can either be included in the 373 CHAP-Challenge attribute or, if it is 16 octets long, it can be 374 placed in the Request Authenticator field of the Access-Request 375 packet. The NAS MAY include the Attributes Service-Type = Framed- 376 User and Framed-Protocol = PPP as a hint to the RADIUS server that 377 PPP service is expected. 379 The RADIUS server looks up a password based on the User-Name, 380 encrypts the challenge using MD5 on the CHAP ID octet, that password, 381 and the CHAP challenge (from the CHAP-Challenge attribute if present, 382 otherwise from the Request Authenticator), and compares that result 383 to the CHAP-Password. If they match, the server sends back an 384 Access-Accept, otherwise it sends back an Access-Reject. 386 If the RADIUS server is unable to perform the requested 387 authentication it MUST return an Access-Reject. For example, CHAP 388 requires that the user's password be available in cleartext to the 389 server so that it can encrypt the CHAP challenge and compare that to 390 the CHAP response. If the password is not available in cleartext to 391 the RADIUS server then the server MUST send an Access-Reject to the 392 client. 394 2.3. Proxy 396 With proxy RADIUS, one RADIUS server recieves an authentication (or 397 accounting) request from a RADIUS client (such as a NAS), forwards 398 the request to a remote RADIUS server, receives the reply from the 399 remote server, and sends that reply to the client, possibly with 400 changes to reflect local administrative policy. A common use for 401 proxy RADIUS is roaming. Roaming permits two or more administrative 402 entities to allow each other's users to dial in to either entity's 403 network for service. 405 The NAS sends its RADIUS access-request to the "forwarding server" 406 which forwards it to the "remote server." The remote server sends a 407 response (Access-Accept, Access-Reject, or Access-Challenge) back to 408 the forwarding server, which sends it back to the NAS. The User-Name 409 attribute MAY contain a Network Access Identifier [8] for RADIUS 410 Proxy operations. The choice of which server receives the forwarded 411 request SHOULD be based on the authentication "realm." The 412 authentication realm MAY be the realm part of a Network Access 413 Identifier (a "named realm"). Alternatively, the choice of which 414 server receives the forwarded request MAY be based on whatever other 415 criteria the forwarding server is configured to use, such as Called- 416 Station-Id (a "numbered realm"). 418 A RADIUS server can function as both a forwarding server and a remote 419 server, serving as a forwarding server for some realms and a remote 420 server for other realms. One forwarding server can act as a 421 forwarder for any number of remote servers. A remote server can have 422 any number of servers forwarding to it and can provide authentication 423 for any number of realms. One forwarding server can forward to 424 another forwarding server to create a chain of proxies, although care 425 must be taken to avoid introducing loops. 427 The following scenario illustrates a proxy RADIUS communication 428 between a NAS and the forwarding and remote RADIUS servers: 430 1. A NAS sends its access-request to the forwarding server. 432 2. The forwarding server forwards the access-request to the remote 433 server. 435 3. The remote server sends an access-accept, access-reject or 436 access-challenge back to the forwarding server. For this 437 example, an access-accept is sent. 439 4. The forwarding server sends the access-accept to the NAS. 441 The forwarding server MUST treat any Proxy-State attributes already 442 in the packet as opaque data. Its operation MUST NOT depend on the 443 content of Proxy-State attributes added by previous servers. 445 If there are any Proxy-State attributes in the request received from 446 the client, the forwarding server MUST include those Proxy-State 447 attributes in its reply to the client. The forwarding server MAY 448 include the Proxy-State attributes in the access-request when it 449 forwards the request, or MAY omit them in the forwarded request. If 450 the forwarding server omits the Proxy-State attributes in the 451 forwarded access-request, it MUST attach them to the response before 452 sending it to the client. 454 We now examine each step in more detail. 456 1. A NAS sends its access-request to the forwarding server. The 457 forwarding server decrypts the User-Password, if present, using 458 the shared secret it knows for the NAS. If a CHAP-Password 459 attribute is present in the packet and no CHAP-Challenge 460 attribute is present, the forwarding server MUST leave the 461 Request-Authenticator untouched or copy it to a CHAP-Challenge 462 attribute. 464 '' The forwarding server MAY add one Proxy-State attribute to the 465 packet. (It MUST NOT add more than one.) If it adds a Proxy- 466 State, the Proxy-State MUST appear after any other Proxy-States 467 in the packet. The forwarding server MUST NOT modify any other 468 Proxy-States that were in the packet (it may choose not to 469 forward them, but it MUST NOT change their contents). The 470 forwarding server MUST NOT change the order of any attributes 471 of the same type, including Proxy-State. 473 2. The forwarding server encrypts the User-Password, if present, 474 using the secret it shares with the remote server, sets the 475 Identifier as needed, and forwards the access-request to the 476 remote server. 478 3. The remote server (if the final destination) verifies the user 479 using User-Password, CHAP-Password, or such method as future 480 extensions may dictate, and returns an access-accept, access- 481 reject or access-challenge back to the forwarding server. For 482 this example, an access-accept is sent. The remote server MUST 483 copy all Proxy-State attributes (and only the Proxy-State 484 attributes) in order from the access-request to the response 485 packet, without modifying them. 487 4. The forwarding server verifies the Response Authenticator using 488 the secret it shares with the remote server, and silently 489 discards the packet if it fails verification. If the packet 490 passes verification, the forwarding server removes the last 491 Proxy-State (if it attached one), signs the Response 492 Authenticator using the secret it shares with the NAS, restores 493 the Identifier to match the one in the original request by the 494 NAS, and sends the access-accept to the NAS. 496 A forwarding server MAY need to modify attributes to enforce local 497 policy. Such policy is outside the scope of this document, with the 498 following restrictions. A forwarding server MUST not modify existing 499 Proxy-State, State, or Class attributes present in the packet. 501 Implementors of forwarding servers should consider carefully which 502 values it is willing to accept for Service-Type. Careful 503 consideration must be given to the effects of passing along Service- 504 Types of NAS-Prompt or Administrative in a proxied Access-Accept, and 505 implementors may wish to provide mechanisms to block those or other 506 service types, or other attributes. Such mechanisms are outside the 507 scope of this document. 509 2.4. Why UDP? 511 A frequently asked question is why RADIUS uses UDP instead of TCP as 512 a transport protocol. UDP was chosen for strictly technical reasons. 514 There are a number of issues which must be understood. RADIUS is a 515 transaction based protocol which has several interesting 516 characteristics: 518 1. If the request to a primary Authentication server fails, a 519 secondary server must be queried. 521 To meet this requirement, a copy of the request must be kept 522 above the transport layer to allow for alternate transmission. 523 This means that retransmission timers are still required. 525 2. The timing requirements of this particular protocol are 526 significantly different than TCP provides. 528 At one extreme, RADIUS does not require a "responsive" detection 529 of lost data. The user is willing to wait several seconds for 530 the authentication to complete. The generally aggressive TCP 531 retransmission (based on average round trip time) is not 532 required, nor is the acknowledgement overhead of TCP. 534 At the other extreme, the user is not willing to wait several 535 minutes for authentication. Therefore the reliable delivery of 536 TCP data two minutes later is not useful. The faster use of an 537 alternate server allows the user to gain access before giving 538 up. 540 3. The stateless nature of this protocol simplifies the use of UDP. 542 Clients and servers come and go. Systems are rebooted, or are 543 power cycled independently. Generally this does not cause a 544 problem and with creative timeouts and detection of lost TCP 545 connections, code can be written to handle anomalous events. 546 UDP however completely eliminates any of this special handling. 547 Each client and server can open their UDP transport just once 548 and leave it open through all types of failure events on the 549 network. 551 4. UDP simplifies the server implementation. 553 In the earliest implementations of RADIUS, the server was single 554 threaded. This means that a single request was received, 555 processed, and returned. This was found to be unmanageable in 556 environments where the back-end security mechanism took real 557 time (1 or more seconds). The server request queue would fill 558 and in environments where hundreds of people were being 559 authenticated every minute, the request turn-around time 560 increased to longer than users were willing to wait (this was 561 especially severe when a specific lookup in a database or over 562 DNS took 30 or more seconds). The obvious solution was to make 563 the server multi-threaded. Achieving this was simple with UDP. 564 Separate processes were spawned to serve each request and these 565 processes could respond directly to the client NAS with a simple 566 UDP packet to the original transport of the client. 568 It's not all a panacea. As noted, using UDP requires one thing which 569 is built into TCP: with UDP we must artificially manage 570 retransmission timers to the same server, although they don't require 571 the same attention to timing provided by TCP. This one penalty is a 572 small price to pay for the advantages of UDP in this protocol. 574 Without TCP we would still probably be using tin cans connected by 575 string. But for this particular protocol, UDP is a better choice. 577 2.5. Retransmission Hints 579 If the RADIUS server and alternate RADIUS server share the same 580 shared secret, it is OK to retransmit the packet to the alternate 581 RADIUS server with the same ID and Request Authenticator, because the 582 content of the attributes haven't changed. If you want to use a new 583 Request Authenticator when sending to the alternate server, you may. 585 If you change the contents of the User-Password attribute (or any 586 other attribute), you need a new Request Authenticator and therefore 587 a new ID. 589 If the NAS is retransmitting a RADIUS request to the same server as 590 before, and the attributes haven't changed, you MUST use the same 591 Request Authenticator, ID, and source port. If any attributes have 592 changed, you MUST use a new Request Authenticator and ID. 594 A NAS MAY use the same ID across all servers, or MAY keep track of 595 IDs seperately for each server, it is up to the implementer. If a 596 NAS needs more than 256 IDs for outstanding requests, it MAY use 597 additional source ports to send requests from, and keep track of IDs 598 for each source port. This allows up to 16 million or so outstanding 599 requests at one time to a single server. 601 2.6. Keep-Alives Considered Harmful 603 Some implementers have adopted the practice of sending test RADIUS 604 requests to see if a server is alive. This practice is strongly 605 discouraged, since it adds to load and harms scalability without 606 providing any additional useful information. Since a RADIUS request 607 is contained in a single datagram, in the time it would take you to 608 send a ping you could just send the RADIUS request, and getting a 609 reply tells you that the RADIUS server is up. If you do not have a 610 RADIUS request to send, it does not matter if the server is up or 611 not, because you are not using it. 613 If you want to monitor your RADIUS server, use SNMP. That's what 614 SNMP is for. 616 3. Packet Format 618 Exactly one RADIUS packet is encapsulated in the UDP Data field [4], 619 where the UDP Destination Port field indicates 1812 (decimal). 621 When a reply is generated, the source and destination ports are 622 reversed. 624 This memo documents the RADIUS protocol. The early deployment of 625 RADIUS was done using UDP port number 1645, which conflicts with the 626 "datametrics" service. The officially assigned port number for 627 RADIUS is 1812. 629 A summary of the RADIUS data format is shown below. The fields are 630 transmitted from left to right. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Code | Identifier | Length | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 | Authenticator | 639 | | 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Attributes ... 643 +-+-+-+-+-+-+-+-+-+-+-+-+- 645 Code 647 The Code field is one octet, and identifies the type of RADIUS 648 packet. When a packet is received with an invalid Code field, it is 649 silently discarded. 651 RADIUS Codes (decimal) are assigned as follows: 653 1 Access-Request 654 2 Access-Accept 655 3 Access-Reject 656 4 Accounting-Request 657 5 Accounting-Response 658 11 Access-Challenge 659 12 Status-Server (experimental) 660 13 Status-Client (experimental) 661 255 Reserved 663 Codes 4 and 5 are covered in the RADIUS Accounting document [5]. 664 Codes 12 and 13 are reserved for possible use, but are not further 665 mentioned here. 667 Identifier 669 The Identifier field is one octet, and aids in matching requests and 670 replies. The RADIUS server can detect a duplicate request if it has 671 the same client source IP address and source UDP port and Identifier 672 within a short span of time. 674 Length 676 The Length field is two octets. It indicates the length of the 677 packet including the Code, Identifier, Length, Authenticator and 678 Attribute fields. Octets outside the range of the Length field MUST 679 be treated as padding and ignored on reception. If the packet is 680 shorter than the Length field indicates, it MUST be silently 681 discarded. The minimum length is 20 and maximum length is 4096. 683 Authenticator 685 The Authenticator field is sixteen (16) octets. The most significant 686 octet is transmitted first. This value is used to authenticate the 687 reply from the RADIUS server, and is used in the password hiding 688 algorithm. 690 Request Authenticator 692 In Access-Request Packets, the Authenticator value is a 16 octet 693 random number, called the Request Authenticator. The value SHOULD 694 be unpredictable and unique over the lifetime of a secret (the 695 password shared between the client and the RADIUS server), since 696 repetition of a request value in conjunction with the same secret 697 would permit an attacker to reply with a previously intercepted 698 response. Since it is expected that the same secret MAY be used 699 to authenticate with servers in disparate geographic regions, the 700 Request Authenticator field SHOULD exhibit global and temporal 701 uniqueness. 703 The Request Authenticator value in an Access-Request packet SHOULD 704 also be unpredictable, lest an attacker trick a server into 705 responding to a predicted future request, and then use the 706 response to masquerade as that server to a future Access-Request. 708 Although protocols such as RADIUS are incapable of protecting 709 against theft of an authenticated session via realtime active 710 wiretapping attacks, generation of unique unpredictable requests 711 can protect against a wide range of active attacks against 712 authentication. 714 The NAS and RADIUS server share a secret. That shared secret 715 followed by the Request Authenticator is put through a one-way MD5 716 hash to create a 16 octet digest value which is xored with the 717 password entered by the user, and the xored result placed in the 718 User-Password attribute in the Access-Request packet. See the 719 entry for User-Password in the section on Attributes for a more 720 detailed description. 722 Response Authenticator 724 The value of the Authenticator field in Access-Accept, Access- 725 Reject, and Access-Challenge packets is called the Response 726 Authenticator, and contains a one-way MD5 hash calculated over a 727 stream of octets consisting of: the RADIUS packet, beginning with 728 the Code field, including the Identifier, the Length, the Request 729 Authenticator field from the Access-Request packet, and the 730 response Attributes, followed by the shared secret. That is, 731 ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) 732 where + denotes concatenation. 734 Administrative Note 736 The secret (password shared between the client and the RADIUS server) 737 SHOULD be at least as large and unguessable as a well-chosen 738 password. It is preferred that the secret be at least 16 octets. 739 This is to ensure a sufficiently large range for the secret to 740 provide protection against exhaustive search attacks. The secret 741 MUST NOT be empty (length 0) since this would allow packets to be 742 trivially forged. 744 A RADIUS server MUST use the source IP address of the RADIUS UDP 745 packet to decide which shared secret to use, so that RADIUS requests 746 can be proxied. 748 When using a forwarding proxy, the proxy must be able to alter the 749 packet as it passes through in each direction - when the proxy 750 forwards the request, the proxy MAY add a Proxy-State Attribute, and 751 when the proxy forwards a response, it MUST remove its Proxy-State 752 Attribute if it added one. Proxy-State is always added or removed 753 after any other Proxy-States, but no other assumptions regarding its 754 location within the list of attributes can be made. Since Access- 755 Accept and Access-Reject replies are authenticated on the entire 756 packet contents, the stripping of the Proxy-State attribute 757 invalidates the signature in the packet - so the proxy has to re-sign 758 it. 760 Further details of RADIUS proxy implementation are outside the scope 761 of this document. 763 4. Packet Types 765 The RADIUS Packet type is determined by the Code field in the first 766 octet of the Packet. 768 4.1. Access-Request 770 Description 772 Access-Request packets are sent to a RADIUS server, and convey 773 information used to determine whether a user is allowed access to 774 a specific NAS, and any special services requested for that user. 775 An implementation wishing to authenticate a user MUST transmit a 776 RADIUS packet with the Code field set to 1 (Access-Request). 778 Upon receipt of an Access-Request from a valid client, an 779 appropriate reply MUST be transmitted. 781 An Access-Request SHOULD contain a User-Name attribute. It MUST 782 contain either a NAS-IP-Address attribute or a NAS-Identifier 783 attribute (or both). 785 An Access-Request MUST contain either a User-Password or a CHAP- 786 Password or a State. An Access-Request MUST NOT contain both a 787 User-Password and a CHAP-Password. If future extensions allow 788 other kinds of authentication information to be conveyed, the 789 attribute for that can be used in an Access-Request instead of 790 User-Password or CHAP-Password. 792 An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type 793 attribute or both unless the type of access being requested does 794 not involve a port or the NAS does not distinguish among its 795 ports. 797 An Access-Request MAY contain additional attributes as a hint to 798 the server, but the server is not required to honor the hint. 800 When a User-Password is present, it is hidden using a method based 801 on the RSA Message Digest Algorithm MD5 [3]. 803 A summary of the Access-Request packet format is shown below. The 804 fields are transmitted from left to right. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Code | Identifier | Length | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | | 812 | Request Authenticator | 813 | | 814 | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Attributes ... 817 +-+-+-+-+-+-+-+-+-+-+-+-+- 819 Code 821 1 for Access-Request. 823 Identifier 825 The Identifier field MUST be changed whenever the content of the 826 Attributes field changes, and whenever a valid reply has been 827 received for a previous request. For retransmissions, the 828 Identifier MUST remain unchanged. 830 Request Authenticator 832 The Request Authenticator value MUST be changed each time a new 833 Identifier is used. 835 Attributes 837 The Attribute field is variable in length, and contains the list 838 of Attributes that are required for the type of service, as well 839 as any desired optional Attributes. 841 4.2. Access-Accept 843 Description 845 Access-Accept packets are sent by the RADIUS server, and provide 846 specific configuration information necessary to begin delivery of 847 service to the user. If all Attribute values received in an 848 Access-Request are acceptable then the RADIUS implementation MUST 849 transmit a packet with the Code field set to 2 (Access-Accept). 851 On reception of an Access-Accept, the Identifier field is matched 852 with a pending Access-Request. The Response Authenticator field 853 MUST contain the correct response for the pending Access-Request. 854 Invalid packets are silently discarded. 856 A summary of the Access-Accept packet format is shown below. The 857 fields are transmitted from left to right. 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Code | Identifier | Length | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | | 865 | Response Authenticator | 866 | | 867 | | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Attributes ... 870 +-+-+-+-+-+-+-+-+-+-+-+-+- 872 Code 874 2 for Access-Accept. 876 Identifier 878 The Identifier field is a copy of the Identifier field of the 879 Access-Request which caused this Access-Accept. 881 Response Authenticator 883 The Response Authenticator value is calculated from the Access- 884 Request value, as described earlier. 886 Attributes 888 The Attribute field is variable in length, and contains a list of 889 zero or more Attributes. 891 4.3. Access-Reject 893 Description 895 If any value of the received Attributes is not acceptable, then 896 the RADIUS server MUST transmit a packet with the Code field set 897 to 3 (Access-Reject). It MAY include one or more Reply-Message 898 Attributes with a text message which the NAS MAY display to the 899 user. 901 A summary of the Access-Reject packet format is shown below. The 902 fields are transmitted from left to right. 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Code | Identifier | Length | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | | 910 | Response Authenticator | 911 | | 912 | | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Attributes ... 915 +-+-+-+-+-+-+-+-+-+-+-+-+- 917 Code 919 3 for Access-Reject. 921 Identifier 923 The Identifier field is a copy of the Identifier field of the 924 Access-Request which caused this Access-Reject. 926 Response Authenticator 928 The Response Authenticator value is calculated from the Access- 929 Request value, as described earlier. 931 Attributes 933 The Attribute field is variable in length, and contains a list of 934 zero or more Attributes. 936 4.4. Access-Challenge 938 Description 940 If the RADIUS server desires to send the user a challenge 941 requiring a response, then the RADIUS server MUST respond to the 942 Access-Request by transmitting a packet with the Code field set to 943 11 (Access-Challenge). 945 The Attributes field MAY have one or more Reply-Message 946 Attributes, and MAY have a single State Attribute, or none. 947 Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State 948 attributes MAY also be included. No other Attributes defined in 949 this document are permitted in an Access-Challenge. 951 On receipt of an Access-Challenge, the Identifier field is matched 952 with a pending Access-Request. Additionally, the Response 953 Authenticator field MUST contain the correct response for the 954 pending Access-Request. Invalid packets are silently discarded. 956 If the NAS does not support challenge/response, it MUST treat an 957 Access-Challenge as though it had received an Access-Reject 958 instead. 960 If the NAS supports challenge/response, receipt of a valid 961 Access-Challenge indicates that a new Access-Request SHOULD be 962 sent. The NAS MAY display the text message, if any, to the user, 963 and then prompt the user for a response. It then sends its 964 original Access-Request with a new request ID and Request 965 Authenticator, with the User-Password Attribute replaced by the 966 user's response (encrypted), and including the State Attribute 967 from the Access-Challenge, if any. Only 0 or 1 instances of the 968 State Attribute can be present in an Access-Request. 970 A NAS which supports PAP MAY forward the Reply-Message to the 971 dialin client and accept a PAP response which it can use as though 972 the user had entered the response. If the NAS cannot do so, it 973 MUST treat the Access-Challenge as though it had received an 974 Access-Reject instead. 976 A summary of the Access-Challenge packet format is shown below. The 977 fields are transmitted from left to right. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Code | Identifier | Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 | Response Authenticator | 986 | | 987 | | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Attributes ... 990 +-+-+-+-+-+-+-+-+-+-+-+-+- 992 Code 994 11 for Access-Challenge. 996 Identifier 998 The Identifier field is a copy of the Identifier field of the 999 Access-Request which caused this Access-Challenge. 1001 Response Authenticator 1003 The Response Authenticator value is calculated from the Access- 1004 Request value, as described earlier. 1006 Attributes 1008 The Attributes field is variable in length, and contains a list of 1009 zero or more Attributes. 1011 5. Attributes 1013 RADIUS Attributes carry the specific authentication, authorization, 1014 information and configuration details for the request and reply. 1016 The end of the list of Attributes is indicated by the Length of the 1017 RADIUS packet. 1019 Some Attributes MAY be included more than once. The effect of this 1020 is Attribute specific, and is specified in each Attribute 1021 description. A summary table is provided at the end of the 1022 "Attributes" section. 1024 If multiple Attributes with the same Type are present, the order of 1025 Attributes with the same Type MUST be preserved by any proxies. The 1026 order of Attributes of different Types is not required to be 1027 preserved. A RADIUS server or client MUST NOT have any dependencies 1028 on the order of attributes of different types. A RADIUS server or 1029 client MUST NOT require attributes of the same type to be contiguous. 1031 Where an Attribute's description limits which kinds of packet it can 1032 be contained in, this applies only to the packet types defined in 1033 this document, namely Access-Request, Access-Accept, Access-Reject 1034 and Access-Challenge (Codes 1, 2, 3, and 11). Other documents 1035 defining other packet types may also use Attributes described here. 1036 To determine which Attributes are allowed in Accounting-Request and 1037 Accounting-Response packets (Codes 4 and 5) refer to the RADIUS 1038 Accounting document [5]. 1040 Likewise where packet types defined here state that only certain 1041 Attributes are permissible in them, future memos defining new 1042 Attributes should indicate which packet types the new Attributes may 1043 be present in. 1045 A summary of the Attribute format is shown below. The fields are 1046 transmitted from left to right. 1048 0 1 2 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1051 | Type | Length | Value ... 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1054 Type 1056 The Type field is one octet. Up-to-date values of the RADIUS Type 1057 field are specified in the most recent "Assigned Numbers" RFC [6]. 1058 Values 192-223 are reserved for experimental use, values 224-240 1059 are reserved for implementation-specific use, and values 241-255 1060 are reserved and should not be used. 1062 A RADIUS server MAY ignore Attributes with an unknown Type. 1064 A RADIUS client MAY ignore Attributes with an unknown Type. 1066 This specification concerns the following values: 1068 1 User-Name 1069 2 User-Password 1070 3 CHAP-Password 1071 4 NAS-IP-Address 1072 5 NAS-Port 1073 6 Service-Type 1074 7 Framed-Protocol 1075 8 Framed-IP-Address 1076 9 Framed-IP-Netmask 1077 10 Framed-Routing 1078 11 Filter-Id 1079 12 Framed-MTU 1080 13 Framed-Compression 1081 14 Login-IP-Host 1082 15 Login-Service 1083 16 Login-TCP-Port 1084 17 (unassigned) 1085 18 Reply-Message 1086 19 Callback-Number 1087 20 Callback-Id 1088 21 (unassigned) 1089 22 Framed-Route 1090 23 Framed-IPX-Network 1091 24 State 1092 25 Class 1093 26 Vendor-Specific 1094 27 Session-Timeout 1095 28 Idle-Timeout 1096 29 Termination-Action 1097 30 Called-Station-Id 1098 31 Calling-Station-Id 1099 32 NAS-Identifier 1100 33 Proxy-State 1101 34 Login-LAT-Service 1102 35 Login-LAT-Node 1103 36 Login-LAT-Group 1104 37 Framed-AppleTalk-Link 1105 38 Framed-AppleTalk-Network 1106 39 Framed-AppleTalk-Zone 1107 40-59 (reserved for accounting) 1108 60 CHAP-Challenge 1109 61 NAS-Port-Type 1110 62 Port-Limit 1111 63 Login-LAT-Port 1113 Length 1115 The Length field is one octet, and indicates the length of this 1116 Attribute including the Type, Length and Value fields. If an 1117 Attribute is received in an Access-Request but with an invalid 1118 Length, an Access-Reject SHOULD be transmitted. If an Attribute 1119 is received in an Access-Accept, Access-Reject or Access-Challenge 1120 packet with an invalid length, the packet MUST either be treated 1121 as an Access-Reject or else silently discarded. 1123 Value 1125 The Value field is zero or more octets and contains information 1126 specific to the Attribute. The format and length of the Value 1127 field is determined by the Type and Length fields. 1129 Note that a "string" in RADIUS does not terminate with a NUL (hex 1130 00). The Attribute has a length field and does not use a 1131 terminator. Strings may contain UTF-8 characters or 8-bit binary 1132 data and servers and servers and clients MUST be able to deal with 1133 embedded nulls. RADIUS implementers using C are cautioned not to 1134 use strcpy() when handling strings. 1136 The format of the value field is one of four data types. 1138 string 1-253 octets. Strings of length zero (0) MUST NOT be 1139 sent; omit the entire attribute instead. 1141 address 32 bit value, most significant octet first. 1143 integer 32 bit unsigned value, most significant octet first. 1145 time 32 bit unsigned value, most significant octet first -- 1146 seconds since 00:00:00 UTC, January 1, 1970. The 1147 standard Attributes do not use this data type but it is 1148 presented here for possible use within future 1149 attributes. 1151 5.1. User-Name 1153 Description 1155 This Attribute indicates the name of the user to be authenticated. 1156 It MUST be sent in Access-Request packets if available. 1158 It MAY be sent in an Access-Accept packet, in which case the 1159 client SHOULD use the name returned in the Access-Accept packet in 1160 all Accounting-Request packets for this session. If the Access- 1161 Accept includes Service-Type = Rlogin and the User-Name attribute, 1162 a NAS MAY use the returned User-Name when performing the Rlogin 1163 function. 1165 A summary of the User-Name Attribute format is shown below. The 1166 fields are transmitted from left to right. 1168 0 1 2 1169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1171 | Type | Length | String ... 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1174 Type 1176 1 for User-Name. 1178 Length 1180 >= 3 1182 String 1184 The String field is one or more octets. The NAS may limit the 1185 maximum length of the User-Name but the ability to handle at least 1186 63 octets is recommended. 1188 The format of the username MAY be one of several forms: 1190 monolithic Consisting only of alphanumeric characters. 1192 simple Consisting only of printable UTF-8 [7] characters. 1194 network access identifier 1195 A Network Access Identifier as described in RFC 2486 1196 [8]. 1198 distinguished name 1199 A name in ASN.1 form used in Public Key authentication 1200 systems. 1202 5.2. User-Password 1204 Description 1206 This Attribute indicates the password of the user to be 1207 authenticated, or the user's input following an Access-Challenge. 1208 It is only used in Access-Request packets. 1210 On transmission, the password is hidden. The password is first 1211 padded at the end with nulls to a multiple of 16 octets. A one- 1212 way MD5 hash is calculated over a stream of octets consisting of 1213 the shared secret followed by the Request Authenticator. This 1214 value is XORed with the first 16 octet segment of the password and 1215 placed in the first 16 octets of the String field of the User- 1216 Password Attribute. 1218 If the password is longer than 16 characters, a second one-way MD5 1219 hash is calculated over a stream of octets consisting of the 1220 shared secret followed by the result of the first xor. That hash 1221 is XORed with the second 16 octet segment of the password and 1222 placed in the second 16 octets of the String field of the User- 1223 Password Attribute. 1225 If necessary, this operation is repeated, with each xor result 1226 being used along with the shared secret to generate the next hash 1227 to xor the next segment of the password, to no more than 128 1228 characters. 1230 The method is taken from the book "Network Security" by Kaufman, 1231 Perlman and Speciner [9] pages 109-110. A more precise 1232 explanation of the method follows: 1234 Call the shared secret S and the pseudo-random 128-bit Request 1235 Authenticator RA. Break the password into 16-octet chunks p1, p2, 1236 etc. with the last one padded at the end with nulls to a 16-octet 1237 boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need 1238 intermediate values b1, b2, etc. 1240 b1 = MD5(S + RA) c(1) = p1 xor b1 1241 b2 = MD5(S + c(1)) c(2) = p2 xor b2 1242 . . 1243 . . 1244 . . 1245 bi = MD5(S + c(i-1)) c(i) = pi xor bi 1247 The String will contain c(1)+c(2)+...+c(i) where + denotes 1248 concatenation. 1250 On receipt, the process is reversed to yield the original 1251 password. 1253 A summary of the User-Password Attribute format is shown below. The 1254 fields are transmitted from left to right. 1256 0 1 2 1257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1259 | Type | Length | String ... 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1262 Type 1264 2 for User-Password. 1266 Length 1268 At least 18 and no larger than 130. 1270 String 1272 The String field is between 16 and 128 octets long, inclusive. 1274 5.3. CHAP-Password 1276 Description 1278 This Attribute indicates the response value provided by a PPP 1279 Challenge-Handshake Authentication Protocol (CHAP) user in 1280 response to the challenge. It is only used in Access-Request 1281 packets. 1283 The CHAP challenge value is found in the CHAP-Challenge Attribute 1284 (60) if present in the packet, otherwise in the Request 1285 Authenticator field. 1287 A summary of the CHAP-Password Attribute format is shown below. The 1288 fields are transmitted from left to right. 1290 0 1 2 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1293 | Type | Length | CHAP Ident | String ... 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1296 Type 1298 3 for CHAP-Password. 1300 Length 1302 19 1304 CHAP Ident 1306 This field is one octet, and contains the CHAP Identifier from the 1307 user's CHAP Response. 1309 String 1311 The String field is 16 octets, and contains the CHAP Response from 1312 the user. 1314 5.4. NAS-IP-Address 1316 Description 1318 This Attribute indicates the identifying IP Address of the NAS 1319 which is requesting authentication of the user, and SHOULD be 1320 unique to the NAS within the scope of the RADIUS server. NAS-IP- 1321 Address is only used in Access-Request packets. Either NAS-IP- 1322 Address or NAS-Identifier MUST be present in an Access-Request 1323 packet. 1325 Note that NAS-IP-Address MUST NOT be used to select the shared 1326 secret used to authenticate the request. The source IP address of 1327 the Access-Request packet MUST be used to select the shared 1328 secret. 1330 A summary of the NAS-IP-Address Attribute format is shown below. The 1331 fields are transmitted from left to right. 1333 0 1 2 3 1334 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 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Type | Length | Address 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 Address (cont) | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 Type 1343 4 for NAS-IP-Address. 1345 Length 1347 6 1349 Address 1351 The Address field is four octets. 1353 5.5. NAS-Port 1355 Description 1357 This Attribute indicates the physical port number of the NAS which 1358 is authenticating the user. It is only used in Access-Request 1359 packets. Note that this is using "port" in its sense of a 1360 physical connection on the NAS, not in the sense of a TCP or UDP 1361 port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD 1362 be present in an Access-Request packet, if the NAS differentiates 1363 among its ports. 1365 A summary of the NAS-Port Attribute format is shown below. The 1366 fields are transmitted from left to right. 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Type | Length | Value 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Value (cont) | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 Type 1378 5 for NAS-Port. 1380 Length 1382 6 1384 Value 1386 The Value field is four octets. 1388 5.6. Service-Type 1390 Description 1392 This Attribute indicates the type of service the user has 1393 requested, or the type of service to be provided. It MAY be used 1394 in both Access-Request and Access-Accept packets. A NAS is not 1395 required to implement all of these service types, and MUST treat 1396 unknown or unsupported Service-Types as though an Access-Reject 1397 had been received instead. 1399 A summary of the Service-Type Attribute format is shown below. The 1400 fields are transmitted from left to right. 1402 0 1 2 3 1403 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 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Type | Length | Value 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 Value (cont) | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 Type 1412 6 for Service-Type. 1414 Length 1416 6 1418 Value 1420 The Value field is four octets. 1422 1 Login 1423 2 Framed 1424 3 Callback Login 1425 4 Callback Framed 1426 5 Outbound 1427 6 Administrative 1428 7 NAS Prompt 1429 8 Authenticate Only 1430 9 Callback NAS Prompt 1431 10 Call Check 1432 11 Callback Administrative 1433 The service types are defined as follows when used in an Access- 1434 Accept. When used in an Access-Request, they MAY be considered to 1435 be a hint to the RADIUS server that the NAS has reason to believe 1436 the user would prefer the kind of service indicated, but the 1437 server is not required to honor the hint. 1439 Login The user should be connected to a host. 1441 Framed A Framed Protocol should be started for the 1442 User, such as PPP or SLIP. 1444 Callback Login The user should be disconnected and called 1445 back, then connected to a host. 1447 Callback Framed The user should be disconnected and called 1448 back, then a Framed Protocol should be started 1449 for the User, such as PPP or SLIP. 1451 Outbound The user should be granted access to outgoing 1452 devices. 1454 Administrative The user should be granted access to the 1455 administrative interface to the NAS from which 1456 privileged commands can be executed. 1458 NAS Prompt The user should be provided a command prompt 1459 on the NAS from which non-privileged commands 1460 can be executed. 1462 Authenticate Only Only Authentication is requested, and no 1463 authorization information needs to be returned 1464 in the Access-Accept (typically used by proxy 1465 servers rather than the NAS itself). 1467 Callback NAS Prompt The user should be disconnected and called 1468 back, then provided a command prompt on the 1469 NAS from which non-privileged commands can be 1470 executed. 1472 Call Check Used by the NAS in an Access-Request packet to 1473 indicate that a call is being received and 1474 that the RADIUS server should send back an 1475 Access-Accept to answer the call, or an 1476 Access-Reject to not accept the call, 1477 typically based on the Called-Station-Id or 1478 Calling-Station-Id attributes. It is 1479 recommended that such Access-Requests use the 1480 value of Calling-Station-Id as the value of 1481 the User-Name. 1483 Callback Administrative 1484 The user should be disconnected and called 1485 back, then granted access to the 1486 administrative interface to the NAS from which 1487 privileged commands can be executed. 1489 5.7. Framed-Protocol 1491 Description 1493 This Attribute indicates the framing to be used for framed access. 1494 It MAY be used in both Access-Request and Access-Accept packets. 1496 A summary of the Framed-Protocol Attribute format is shown below. 1497 The fields are transmitted from left to right. 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Type | Length | Value 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 Value (cont) | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 Type 1509 7 for Framed-Protocol. 1511 Length 1513 6 1515 Value 1517 The Value field is four octets. 1519 1 PPP 1520 2 SLIP 1521 3 AppleTalk Remote Access Protocol (ARAP) 1522 4 Gandalf proprietary SingleLink/MultiLink protocol 1523 5 Xylogics proprietary IPX/SLIP 1524 6 X.75 Synchronous 1526 5.8. Framed-IP-Address 1528 Description 1530 This Attribute indicates the address to be configured for the 1531 user. It MAY be used in Access-Accept packets. It MAY be used in 1532 an Access-Request packet as a hint by the NAS to the server that 1533 it would prefer that address, but the server is not required to 1534 honor the hint. 1536 A summary of the Framed-IP-Address Attribute format is shown below. 1537 The fields are transmitted from left to right. 1539 0 1 2 3 1540 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Type | Length | Address 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 Address (cont) | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 Type 1549 8 for Framed-IP-Address. 1551 Length 1553 6 1555 Address 1557 The Address field is four octets. The value 0xFFFFFFFF indicates 1558 that the NAS Should allow the user to select an address (e.g. 1559 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 1560 select an address for the user (e.g. Assigned from a pool of 1561 addresses kept by the NAS). Other valid values indicate that the 1562 NAS should use that value as the user's IP address. 1564 5.9. Framed-IP-Netmask 1566 Description 1568 This Attribute indicates the IP netmask to be configured for the 1569 user when the user is a router to a network. It MAY be used in 1570 Access-Accept packets. It MAY be used in an Access-Request packet 1571 as a hint by the NAS to the server that it would prefer that 1572 netmask, but the server is not required to honor the hint. 1574 A summary of the Framed-IP-Netmask Attribute format is shown below. 1575 The fields are transmitted from left to right. 1577 0 1 2 3 1578 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 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Type | Length | Address 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 Address (cont) | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 Type 1587 9 for Framed-IP-Netmask. 1589 Length 1591 6 1593 Address 1595 The Address field is four octets specifying the IP netmask of the 1596 user. 1598 5.10. Framed-Routing 1600 Description 1602 This Attribute indicates the routing method for the user, when the 1603 user is a router to a network. It is only used in Access-Accept 1604 packets. 1606 A summary of the Framed-Routing Attribute format is shown below. The 1607 fields are transmitted from left to right. 1609 0 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Type | Length | Value 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 Value (cont) | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 Type 1618 10 for Framed-Routing. 1620 Length 1622 6 1624 Value 1626 The Value field is four octets. 1628 0 None 1629 1 Send routing packets 1630 2 Listen for routing packets 1631 3 Send and Listen 1633 5.11. Filter-Id 1635 Description 1637 This Attribute indicates the name of the filter list for this 1638 user. Zero or more Filter-Id attributes MAY be sent in an 1639 Access-Accept packet. 1641 Identifying a filter list by name allows the filter to be used on 1642 different NASes without regard to filter-list implementation 1643 details. 1645 A summary of the Filter-Id Attribute format is shown below. The 1646 fields are transmitted from left to right. 1648 0 1 2 1649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1651 | Type | Length | String ... 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1654 Type 1656 11 for Filter-Id. 1658 Length 1660 >= 3 1662 String 1664 The String field is one or more octets, and its contents are 1665 implementation dependent. It is intended to be human readable and 1666 MUST NOT affect operation of the protocol. It is recommended that 1667 the message contain displayable UTF-8 characters. 1669 5.12. Framed-MTU 1671 Description 1673 This Attribute indicates the Maximum Transmission Unit to be 1674 configured for the user, when it is not negotiated by some other 1675 means (such as PPP). It MAY be used in Access-Accept packets. It 1676 MAY be used in an Access-Request packet as a hint by the NAS to 1677 the server that it would prefer that value, but the server is not 1678 required to honor the hint. 1680 A summary of the Framed-MTU Attribute format is shown below. The 1681 fields are transmitted from left to right. 1683 0 1 2 3 1684 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 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | Type | Length | Value 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 Value (cont) | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 Type 1693 12 for Framed-MTU. 1695 Length 1697 6 1699 Value 1701 The Value field is four octets. Despite the size of the field, 1702 values range from 64 to 65535. 1704 5.13. Framed-Compression 1706 Description 1708 This Attribute indicates a compression protocol to be used for the 1709 link. It MAY be used in Access-Accept packets. It MAY be used in 1710 an Access-Request packet as a hint to the server that the NAS 1711 would prefer to use that compression, but the server is not 1712 required to honor the hint. 1714 More than one compression protocol Attribute MAY be sent. It is 1715 the responsibility of the NAS to apply the proper compression 1716 protocol to appropriate link traffic. 1718 A summary of the Framed-Compression Attribute format is shown below. 1719 The fields are transmitted from left to right. 1721 0 1 2 3 1722 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 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Type | Length | Value 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 Value (cont) | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 Type 1731 13 for Framed-Compression. 1733 Length 1735 6 1737 Value 1739 The Value field is four octets. 1741 0 None 1742 1 VJ TCP/IP header compression [10] 1743 2 IPX header compression 1744 3 Stac-LZS compression 1746 5.14. Login-IP-Host 1748 Description 1750 This Attribute indicates the system with which to connect the 1751 user, when the Login-Service Attribute is included. It MAY be 1752 used in Access-Accept packets. It MAY be used in an Access- 1753 Request packet as a hint to the server that the NAS would prefer 1754 to use that host, but the server is not required to honor the 1755 hint. 1757 A summary of the Login-IP-Host Attribute format is shown below. The 1758 fields are transmitted from left to right. 1760 0 1 2 3 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 | Address 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 Address (cont) | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 Type 1770 14 for Login-IP-Host. 1772 Length 1774 6 1776 Address 1778 The Address field is four octets. The value 0xFFFFFFFF indicates 1779 that the NAS SHOULD allow the user to select an address. The 1780 value 0 indicates that the NAS SHOULD select a host to connect the 1781 user to. Other values indicate the address the NAS SHOULD connect 1782 the user to. 1784 5.15. Login-Service 1786 Description 1788 This Attribute indicates the service to use to connect the user to 1789 the login host. It is only used in Access-Accept packets. 1791 A summary of the Login-Service Attribute format is shown below. The 1792 fields are transmitted from left to right. 1794 0 1 2 3 1795 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 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Type | Length | Value 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Value (cont) | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 Type 1804 15 for Login-Service. 1806 Length 1808 6 1810 Value 1812 The Value field is four octets. 1814 0 Telnet 1815 1 Rlogin 1816 2 TCP Clear 1817 3 PortMaster (proprietary) 1818 4 LAT 1819 5 X25-PAD 1820 6 X25-T3POS 1821 8 TCP Clear Quiet (suppresses any NAS-generated connect string) 1823 5.16. Login-TCP-Port 1825 Description 1827 This Attribute indicates the TCP port with which the user is to be 1828 connected, when the Login-Service Attribute is also present. It 1829 is only used in Access-Accept packets. 1831 A summary of the Login-TCP-Port Attribute format is shown below. The 1832 fields are transmitted from left to right. 1834 0 1 2 3 1835 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 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Type | Length | Value 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 Value (cont) | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 Type 1844 16 for Login-TCP-Port. 1846 Length 1848 6 1850 Value 1852 The Value field is four octets. Despite the size of the field, 1853 values range from 0 to 65535. 1855 5.17. (unassigned) 1857 Description 1859 ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. 1861 5.18. Reply-Message 1863 Description 1865 This Attribute indicates text which MAY be displayed to the user. 1867 When used in an Access-Accept, it is the success message. 1869 When used in an Access-Reject, it is the failure message. It MAY 1870 indicate a dialog message to prompt the user before another 1871 Access-Request attempt. 1873 When used in an Access-Challenge, it MAY indicate a dialog message 1874 to prompt the user for a response. 1876 Multiple Reply-Message's MAY be included and if any are displayed, 1877 they MUST be displayed in the same order as they appear in the 1878 packet. 1880 A summary of the Reply-Message Attribute format is shown below. The 1881 fields are transmitted from left to right. 1883 0 1 2 1884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1886 | Type | Length | String ... 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1889 Type 1891 18 for Reply-Message. 1893 Length 1895 >= 3 1897 String 1899 The String field is one or more octets, and its contents are 1900 implementation dependent. It is intended to be human readable, 1901 and MUST NOT affect operation of the protocol. It is recommended 1902 that the message contain displayable UTF-8 characters. 1904 5.19. Callback-Number 1906 Description 1908 This Attribute indicates a dialing string to be used for callback. 1909 It MAY be used in Access-Accept packets. It MAY be used in an 1910 Access-Request packet as a hint to the server that a Callback 1911 service is desired, but the server is not required to honor the 1912 hint. 1914 A summary of the Callback-Number Attribute format is shown below. 1915 The fields are transmitted from left to right. 1917 0 1 2 1918 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1920 | Type | Length | String ... 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1923 Type 1925 19 for Callback-Number. 1927 Length 1929 >= 3 1931 String 1933 The String field is one or more octets. The actual format of the 1934 information is site or application specific, and a robust 1935 implementation SHOULD support the field as undistinguished octets. 1937 The codification of the range of allowed usage of this field is 1938 outside the scope of this specification. 1940 5.20. Callback-Id 1942 Description 1944 This Attribute indicates the name of a place to be called, to be 1945 interpreted by the NAS. It MAY be used in Access-Accept packets. 1947 A summary of the Callback-Id Attribute format is shown below. The 1948 fields are transmitted from left to right. 1950 0 1 2 1951 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1953 | Type | Length | String ... 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1956 Type 1958 20 for Callback-Id. 1960 Length 1962 >= 3 1964 String 1966 The String field is one or more octets. The actual format of the 1967 information is site or application specific, and a robust 1968 implementation SHOULD support the field as undistinguished octets. 1970 The codification of the range of allowed usage of this field is 1971 outside the scope of this specification. 1973 5.21. (unassigned) 1975 Description 1977 ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. 1979 5.22. Framed-Route 1981 Description 1983 This Attribute provides routing information to be configured for 1984 the user on the NAS. It is used in the Access-Accept packet and 1985 can appear multiple times. 1987 A summary of the Framed-Route Attribute format is shown below. The 1988 fields are transmitted from left to right. 1990 0 1 2 1991 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1993 | Type | Length | String... 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1996 Type 1998 22 for Framed-Route. 2000 Length 2002 >= 3 2004 String 2006 The String field is one or more octets, and its contents are 2007 implementation dependent. It is intended to be human readable and 2008 MUST NOT affect operation of the protocol. It is recommended that 2009 the message contain displayable UTF-8 characters. 2011 For IP routes, it SHOULD contain a destination prefix in dotted 2012 quad form optionally followed by a slash and a decimal length 2013 specifier stating how many high order bits of the prefix to use. 2014 That is followed by a space, a gateway address in dotted quad 2015 form, a space, and one or more metrics separated by spaces. For 2016 example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length 2017 specifier may be omitted, in which case it defaults to 8 bits for 2018 class A prefixes, 16 bits for class B prefixes, and 24 bits for 2019 class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 2021 Whenever the gateway address is specified as "0.0.0.0" the IP 2022 address of the user SHOULD be used as the gateway address. 2024 5.23. Framed-IPX-Network 2026 Description 2028 This Attribute indicates the IPX Network number to be configured 2029 for the user. It is used in Access-Accept packets. 2031 A summary of the Framed-IPX-Network Attribute format is shown below. 2032 The fields are transmitted from left to right. 2034 0 1 2 3 2035 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 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Type | Length | Value 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 Value (cont) | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 Type 2044 23 for Framed-IPX-Network. 2046 Length 2048 6 2050 Value 2052 The Value field is four octets. The value 0xFFFFFFFE indicates 2053 that the NAS should select an IPX network for the user (e.g. 2054 assigned from a pool of one or more IPX networks kept by the NAS). 2055 Other values should be used as the IPX network for the link to the 2056 user. 2058 5.24. State 2060 Description 2062 This Attribute is available to be sent by the server to the client 2063 in an Access-Challenge and MUST be sent unmodified from the client 2064 to the server in the new Access-Request reply to that challenge, 2065 if any. 2067 This Attribute is available to be sent by the server to the client 2068 in an Access-Accept that also includes a Termination-Action 2069 Attribute with the value of RADIUS-Request. If the NAS performs 2070 the Termination-Action by sending a new Access-Request upon 2071 termination of the current session, it MUST include the State 2072 attribute unchanged in that Access-Request. 2074 In either usage, the client MUST NOT interpret the attribute 2075 locally. A packet must have only zero or one State Attribute. 2076 Usage of the State Attribute is implementation dependent. 2078 A summary of the State Attribute format is shown below. The fields 2079 are transmitted from left to right. 2081 0 1 2 2082 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2084 | Type | Length | String ... 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2087 Type 2089 24 for State. 2091 Length 2093 >= 3 2095 String 2097 The String field is one or more octets. The actual format of the 2098 information is site or application specific, and a robust 2099 implementation SHOULD support the field as undistinguished octets. 2101 The codification of the range of allowed usage of this field is 2102 outside the scope of this specification. 2104 5.25. Class 2106 Description 2108 This Attribute is available to be sent by the server to the client 2109 in an Access-Accept and SHOULD be sent unmodified by the client to 2110 the accounting server as part of the Accounting-Request packet if 2111 accounting is supported. The client MUST NOT interpret the 2112 attribute locally. 2114 A summary of the Class Attribute format is shown below. The fields 2115 are transmitted from left to right. 2117 0 1 2 2118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2120 | Type | Length | String ... 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2123 Type 2125 25 for Class. 2127 Length 2129 >= 3 2131 String 2133 The String field is one or more octets. The actual format of the 2134 information is site or application specific, and a robust 2135 implementation SHOULD support the field as undistinguished octets. 2137 The codification of the range of allowed usage of this field is 2138 outside the scope of this specification. 2140 5.26. Vendor-Specific 2142 Description 2144 This Attribute is available to allow vendors to support their own 2145 extended Attributes not suitable for general usage. It MUST not 2146 affect the operation of the RADIUS protocol. 2148 Servers not equipped to interpret the vendor-specific information 2149 sent by a client MUST ignore it (although it may be reported). 2150 Clients which do not receive desired vendor-specific information 2151 SHOULD make an attempt to operate without it, although they may do 2152 so (and report they are doing so) in a degraded mode. 2154 A summary of the Vendor-Specific Attribute format is shown below. 2155 The fields are transmitted from left to right. 2157 0 1 2 3 2158 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 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Type | Length | Vendor-Id 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 Vendor-Id (cont) | String... 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2165 Type 2167 26 for Vendor-Specific. 2169 Length 2171 >= 7 2173 Vendor-Id 2175 The high-order octet is 0 and the low-order 3 octets are the SMI 2176 Network Management Private Enterprise Code of the Vendor in 2177 network byte order, as defined in the "Assigned Numbers" RFC [11]. 2179 String 2181 The String field is one or more octets. The actual format of the 2182 information is site or application specific, and a robust 2183 implementation SHOULD support the field as undistinguished octets. 2185 The codification of the range of allowed usage of this field is 2186 outside the scope of this specification. 2188 It SHOULD be encoded as a sequence of vendor type / vendor length 2189 / value fields, as follows. The Attribute-Specific field is 2190 dependent on the vendor's definition of that attribute. An 2191 example encoding of the Vendor-Specific attribute using this 2192 method follows: 2194 0 1 2 3 2195 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 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | Type | Length | Vendor-Id 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 Vendor-Id (cont) | Vendor type | Vendor length | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | Attribute-Specific... 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2204 Multiple subattributes MAY be encoded within a single Vendor- 2205 Specific attribute, although they do not have to be. 2207 5.27. Session-Timeout 2209 Description 2211 This Attribute sets the maximum number of seconds of service to be 2212 provided to the user before termination of the session or prompt. 2213 This Attribute is available to be sent by the server to the client 2214 in an Access-Accept or Access-Challenge. 2216 A summary of the Session-Timeout Attribute format is shown below. 2217 The fields are transmitted from left to right. 2219 0 1 2 3 2220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Type | Length | Value 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 Value (cont) | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 Type 2229 27 for Session-Timeout. 2231 Length 2233 6 2235 Value 2237 The field is 4 octets, containing a 32-bit unsigned integer with 2238 the maximum number of seconds this user should be allowed to 2239 remain connected by the NAS. 2241 5.28. Idle-Timeout 2243 Description 2245 This Attribute sets the maximum number of consecutive seconds of 2246 idle connection allowed to the user before termination of the 2247 session or prompt. This Attribute is available to be sent by the 2248 server to the client in an Access-Accept or Access-Challenge. 2250 A summary of the Idle-Timeout Attribute format is shown below. The 2251 fields are transmitted from left to right. 2253 0 1 2 3 2254 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 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | Type | Length | Value 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 Value (cont) | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 Type 2263 28 for Idle-Timeout. 2265 Length 2267 6 2269 Value 2271 The field is 4 octets, containing a 32-bit unsigned integer with 2272 the maximum number of consecutive seconds of idle time this user 2273 should be permitted before being disconnected by the NAS. 2275 5.29. Termination-Action 2277 Description 2279 This Attribute indicates what action the NAS should take when the 2280 specified service is completed. It is only used in Access-Accept 2281 packets. 2283 A summary of the Termination-Action Attribute format is shown below. 2284 The fields are transmitted from left to right. 2286 0 1 2 3 2287 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 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | Type | Length | Value 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 Value (cont) | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 Type 2296 29 for Termination-Action. 2298 Length 2300 6 2302 Value 2304 The Value field is four octets. 2306 0 Default 2307 1 RADIUS-Request 2309 If the Value is set to RADIUS-Request, upon termination of the 2310 specified service the NAS MAY send a new Access-Request to the 2311 RADIUS server, including the State attribute if any. 2313 5.30. Called-Station-Id 2315 Description 2317 This Attribute allows the NAS to send in the Access-Request packet 2318 the phone number that the user called, using Dialed Number 2319 Identification (DNIS) or similar technology. Note that this may 2320 be different from the phone number the call comes in on. It is 2321 only used in Access-Request packets. 2323 A summary of the Called-Station-Id Attribute format is shown below. 2324 The fields are transmitted from left to right. 2326 0 1 2 2327 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2329 | Type | Length | String ... 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2332 Type 2334 30 for Called-Station-Id. 2336 Length 2338 >= 3 2340 String 2342 The String field is one or more octets, containing the phone 2343 number that the user's call came in on. 2345 The actual format of the information is site or application 2346 specific. Printable UTF-8 is recommended, but a robust 2347 implementation SHOULD support the field as undistinguished octets. 2349 The codification of the range of allowed usage of this field is 2350 outside the scope of this specification. 2352 5.31. Calling-Station-Id 2354 Description 2356 This Attribute allows the NAS to send in the Access-Request packet 2357 the phone number that the call came from, using Automatic Number 2358 Identification (ANI) or similar technology. It is only used in 2359 Access-Request packets. 2361 A summary of the Calling-Station-Id Attribute format is shown below. 2362 The fields are transmitted from left to right. 2364 0 1 2 2365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2367 | Type | Length | String ... 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2370 Type 2372 31 for Calling-Station-Id. 2374 Length 2376 >= 3 2378 String 2380 The String field is one or more octets, containing the phone 2381 number that the user placed the call from. 2383 The actual format of the information is site or application 2384 specific. Printable UTF-8 is recommended, but a robust 2385 implementation SHOULD support the field as undistinguished octets. 2387 The codification of the range of allowed usage of this field is 2388 outside the scope of this specification. 2390 5.32. NAS-Identifier 2392 Description 2394 This Attribute contains a string identifying the NAS originating 2395 the Access-Request. It is only used in Access-Request packets. 2396 Either NAS-IP-Address or NAS-Identifier MUST be present in an 2397 Access-Request packet. 2399 Note that NAS-Identifier MUST NOT be used to select the shared 2400 secret used to authenticate the request. The source IP address of 2401 the Access-Request packet MUST be used to select the shared 2402 secret. 2404 A summary of the NAS-Identifier Attribute format is shown below. The 2405 fields are transmitted from left to right. 2407 0 1 2 2408 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2410 | Type | Length | String ... 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2413 Type 2415 32 for NAS-Identifier. 2417 Length 2419 >= 3 2421 String 2423 The String field is one or more octets, and should be unique to 2424 the NAS within the scope of the RADIUS server. For example, a 2425 fully qualified domain name would be suitable as a NAS-Identifier. 2427 The actual format of the information is site or application 2428 specific, and a robust implementation SHOULD support the field as 2429 undistinguished octets. 2431 The codification of the range of allowed usage of this field is 2432 outside the scope of this specification. 2434 5.33. Proxy-State 2436 Description 2438 This Attribute is available to be sent by a proxy server to 2439 another server when forwarding an Access-Request and MUST be 2440 returned unmodified in the Access-Accept, Access-Reject or 2441 Access-Challenge. When the proxy server receives the response to 2442 its request, it MUST remove its own Proxy-State (the last Proxy- 2443 State in the packet) before forwarding the response to the NAS. 2445 If a Proxy-State Attribute is added to a packet when forwarding 2446 the packet, the Proxy-State Attribute MUST be added after any 2447 existing Proxy-State attributes. 2449 The content of any Proxy-State other than the one added by the 2450 current server should be treated as opaque octets and MUST NOT 2451 affect operation of the protocol. 2453 Usage of the Proxy-State Attribute is implementation dependent. A 2454 description of its function is outside the scope of this 2455 specification. 2457 A summary of the Proxy-State Attribute format is shown below. The 2458 fields are transmitted from left to right. 2460 0 1 2 2461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2463 | Type | Length | String ... 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2466 Type 2468 33 for Proxy-State. 2470 Length 2472 >= 3 2474 String 2476 The String field is one or more octets. The actual format of the 2477 information is site or application specific, and a robust 2478 implementation SHOULD support the field as undistinguished octets. 2480 The codification of the range of allowed usage of this field is 2481 outside the scope of this specification. 2483 5.34. Login-LAT-Service 2485 Description 2487 This Attribute indicates the system with which the user is to be 2488 connected by LAT. It MAY be used in Access-Accept packets, but 2489 only when LAT is specified as the Login-Service. It MAY be used 2490 in an Access-Request packet as a hint to the server, but the 2491 server is not required to honor the hint. 2493 Administrators use the service attribute when dealing with 2494 clustered systems, such as a VAX or Alpha cluster. In such an 2495 environment several different time sharing hosts share the same 2496 resources (disks, printers, etc.), and administrators often 2497 configure each to offer access (service) to each of the shared 2498 resources. In this case, each host in the cluster advertises its 2499 services through LAT broadcasts. 2501 Sophisticated users often know which service providers (machines) 2502 are faster and tend to use a node name when initiating a LAT 2503 connection. Alternately, some administrators want particular 2504 users to use certain machines as a primitive form of load 2505 balancing (although LAT knows how to do load balancing itself). 2507 A summary of the Login-LAT-Service Attribute format is shown below. 2508 The fields are transmitted from left to right. 2510 0 1 2 2511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2513 | Type | Length | String ... 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2516 Type 2518 34 for Login-LAT-Service. 2520 Length 2522 >= 3 2524 String 2526 The String field is one or more octets, and contains the identity 2527 of the LAT service to use. The LAT Architecture allows this 2528 string to contain $ (dollar), - (hyphen), . (period), _ 2529 (underscore), numerics, upper and lower case alphabetics, and the 2530 ISO Latin-1 character set extension [11]. All LAT string 2531 comparisons are case insensitive. 2533 5.35. Login-LAT-Node 2535 Description 2537 This Attribute indicates the Node with which the user is to be 2538 automatically connected by LAT. It MAY be used in Access-Accept 2539 packets, but only when LAT is specified as the Login-Service. It 2540 MAY be used in an Access-Request packet as a hint to the server, 2541 but the server is not required to honor the hint. 2543 A summary of the Login-LAT-Node Attribute format is shown below. The 2544 fields are transmitted from left to right. 2546 0 1 2 2547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2549 | Type | Length | String ... 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2552 Type 2554 35 for Login-LAT-Node. 2556 Length 2558 >= 3 2560 String 2562 The String field is one or more octets, and contains the identity 2563 of the LAT Node to connect the user to. The LAT Architecture 2564 allows this string to contain $ (dollar), - (hyphen), . (period), 2565 _ (underscore), numerics, upper and lower case alphabetics, and 2566 the ISO Latin-1 character set extension. All LAT string 2567 comparisons are case insensitive. 2569 5.36. Login-LAT-Group 2571 Description 2573 This Attribute contains a string identifying the LAT group codes 2574 which this user is authorized to use. It MAY be used in Access- 2575 Accept packets, but only when LAT is specified as the Login- 2576 Service. It MAY be used in an Access-Request packet as a hint to 2577 the server, but the server is not required to honor the hint. 2579 LAT supports 256 different group codes, which LAT uses as a form 2580 of access rights. LAT encodes the group codes as a 256 bit 2581 bitmap. 2583 Administrators can assign one or more of the group code bits at 2584 the LAT service provider; it will only accept LAT connections that 2585 have these group codes set in the bit map. The administrators 2586 assign a bitmap of authorized group codes to each user; LAT gets 2587 these from the operating system, and uses these in its requests to 2588 the service providers. 2590 A summary of the Login-LAT-Group Attribute format is shown below. 2591 The fields are transmitted from left to right. 2593 0 1 2 2594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2596 | Type | Length | String ... 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2599 Type 2601 36 for Login-LAT-Group. 2603 Length 2605 34 2607 String 2609 The String field is a 32 octet bit map, most significant octet 2610 first. A robust implementation SHOULD support the field as 2611 undistinguished octets. 2613 The codification of the range of allowed usage of this field is 2614 outside the scope of this specification. 2616 5.37. Framed-AppleTalk-Link 2618 Description 2620 This Attribute indicates the AppleTalk network number which should 2621 be used for the serial link to the user, which is another 2622 AppleTalk router. It is only used in Access-Accept packets. It 2623 is never used when the user is not another router. 2625 A summary of the Framed-AppleTalk-Link Attribute format is shown 2626 below. The fields are transmitted from left to right. 2628 0 1 2 3 2629 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 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | Type | Length | Value 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 Value (cont) | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 Type 2638 37 for Framed-AppleTalk-Link. 2640 Length 2642 6 2644 Value 2646 The Value field is four octets. Despite the size of the field, 2647 values range from 0 to 65535. The special value of 0 indicates 2648 that this is an unnumbered serial link. A value of 1-65535 means 2649 that the serial line between the NAS and the user should be 2650 assigned that value as an AppleTalk network number. 2652 5.38. Framed-AppleTalk-Network 2654 Description 2656 This Attribute indicates the AppleTalk Network number which the 2657 NAS should probe to allocate an AppleTalk node for the user. It 2658 is only used in Access-Accept packets. It is never used when the 2659 user is another router. Multiple instances of this Attribute 2660 indicate that the NAS may probe using any of the network numbers 2661 specified. 2663 A summary of the Framed-AppleTalk-Network Attribute format is shown 2664 below. The fields are transmitted from left to right. 2666 0 1 2 3 2667 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 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | Type | Length | Value 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 Value (cont) | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 Type 2676 38 for Framed-AppleTalk-Network. 2678 Length 2680 6 2682 Value 2684 The Value field is four octets. Despite the size of the field, 2685 values range from 0 to 65535. The special value 0 indicates that 2686 the NAS should assign a network for the user, using its default 2687 cable range. A value between 1 and 65535 (inclusive) indicates 2688 the AppleTalk Network the NAS should probe to find an address for 2689 the user. 2691 5.39. Framed-AppleTalk-Zone 2693 Description 2695 This Attribute indicates the AppleTalk Default Zone to be used for 2696 this user. It is only used in Access-Accept packets. Multiple 2697 instances of this attribute in the same packet are not allowed. 2699 A summary of the Framed-AppleTalk-Zone Attribute format is shown 2700 below. The fields are transmitted from left to right. 2702 0 1 2 2703 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 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2705 | Type | Length | String ... 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2707 Type 2709 39 for Framed-AppleTalk-Zone. 2711 Length 2713 >= 3 2715 String 2717 The name of the Default AppleTalk Zone to be used for this user. 2718 A robust implementation SHOULD support the field as 2719 undistinguished octets. 2721 The codification of the range of allowed usage of this field is 2722 outside the scope of this specification. 2724 5.40. CHAP-Challenge 2726 Description 2728 This Attribute contains the CHAP Challenge sent by the NAS to a 2729 PPP Challenge-Handshake Authentication Protocol (CHAP) user. It 2730 is only used in Access-Request packets. 2732 If the CHAP challenge value is 16 octets long it MAY be placed in 2733 the Request Authenticator field instead of using this attribute. 2735 A summary of the CHAP-Challenge Attribute format is shown below. The 2736 fields are transmitted from left to right. 2738 0 1 2 2739 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2741 | Type | Length | String... 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2744 Type 2746 60 for CHAP-Challenge. 2748 Length 2750 >= 7 2752 String 2754 The String field contains the CHAP Challenge. 2756 5.41. NAS-Port-Type 2758 Description 2760 This Attribute indicates the type of the physical port of the NAS 2761 which is authenticating the user. It can be used instead of or in 2762 addition to the NAS-Port (5) attribute. It is only used in 2763 Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or 2764 both SHOULD be present in an Access-Request packet, if the NAS 2765 differentiates among its ports. 2767 A summary of the NAS-Port-Type Attribute format is shown below. The 2768 fields are transmitted from left to right. 2770 0 1 2 3 2771 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 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 | Type | Length | Value 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 Value (cont) | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 Type 2780 61 for NAS-Port-Type. 2782 Length 2784 6 2786 Value 2788 The Value field is four octets. "Virtual" refers to a connection 2789 to the NAS via some transport protocol, instead of through a 2790 physical port. For example, if a user telnetted into a NAS to 2791 authenticate himself as an Outbound-User, the Access-Request might 2792 include NAS-Port-Type = Virtual as a hint to the RADIUS server 2793 that the user was not on a physical port. 2795 0 Async 2796 1 Sync 2797 2 ISDN Sync 2798 3 ISDN Async V.120 2799 4 ISDN Async V.110 2800 5 Virtual 2801 6 PIAFS 2802 7 HDLC Clear Channel 2803 8 X.25 2804 9 X.75 2805 10 G.3 Fax 2806 11 SDSL - Symmetric DSL 2807 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 2808 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 2809 14 IDSL - ISDN Digital Subscriber Line 2810 15 Ethernet 2811 16 xDSL - Digital Subscriber Line of unknown type 2812 17 Cable 2813 18 Wireless - Other 2814 19 Wireless - IEEE 802.11 2816 PIAFS is a form of wireless ISDN commonly used in Japan, and 2817 stands for PHS (Personal Handyphone System) Internet Access Forum 2818 Standard (PIAFS). 2820 5.42. Port-Limit 2822 Description 2824 This Attribute sets the maximum number of ports to be provided to 2825 the user by the NAS. This Attribute MAY be sent by the server to 2826 the client in an Access-Accept packet. It is intended for use in 2827 conjunction with Multilink PPP [12] or similar uses. It MAY also 2828 be sent by the NAS to the server as a hint that that many ports 2829 are desired for use, but the server is not required to honor the 2830 hint. 2832 A summary of the Port-Limit Attribute format is shown below. The 2833 fields are transmitted from left to right. 2835 0 1 2 3 2836 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 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 | Type | Length | Value 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 Value (cont) | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 Type 2845 62 for Port-Limit. 2847 Length 2849 6 2851 Value 2853 The field is 4 octets, containing a 32-bit unsigned integer with 2854 the maximum number of ports this user should be allowed to connect 2855 to on the NAS. 2857 5.43. Login-LAT-Port 2859 Description 2861 This Attribute indicates the Port with which the user is to be 2862 connected by LAT. It MAY be used in Access-Accept packets, but 2863 only when LAT is specified as the Login-Service. It MAY be used 2864 in an Access-Request packet as a hint to the server, but the 2865 server is not required to honor the hint. 2867 A summary of the Login-LAT-Port Attribute format is shown below. The 2868 fields are transmitted from left to right. 2870 0 1 2 2871 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2873 | Type | Length | String ... 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2875 Type 2877 63 for Login-LAT-Port. 2879 Length 2881 >= 3 2883 String 2885 The String field is one or more octets, and contains the identity 2886 of the LAT port to use. The LAT Architecture allows this string 2887 to contain $ (dollar), - (hyphen), . (period), _ (underscore), 2888 numerics, upper and lower case alphabetics, and the ISO Latin-1 2889 character set extension. All LAT string comparisons are case 2890 insensitive. 2892 5.44. Table of Attributes 2894 The following table provides a guide to which attributes may be found 2895 in which kinds of packets, and in what quantity. 2897 Request Accept Reject Challenge # Attribute 2898 0-1 0-1 0 0 1 User-Name 2899 0-1 0 0 0 2 User-Password [Note 1] 2900 0-1 0 0 0 3 CHAP-Password [Note 1] 2901 0-1 0 0 0 4 NAS-IP-Address [Note 2] 2902 0-1 0 0 0 5 NAS-Port 2903 0-1 0-1 0 0 6 Service-Type 2904 0-1 0-1 0 0 7 Framed-Protocol 2905 0-1 0-1 0 0 8 Framed-IP-Address 2906 0-1 0-1 0 0 9 Framed-IP-Netmask 2907 0 0-1 0 0 10 Framed-Routing 2908 0 0+ 0 0 11 Filter-Id 2909 0-1 0-1 0 0 12 Framed-MTU 2910 0+ 0+ 0 0 13 Framed-Compression 2911 0+ 0+ 0 0 14 Login-IP-Host 2912 0 0-1 0 0 15 Login-Service 2913 0 0-1 0 0 16 Login-TCP-Port 2914 0 0+ 0+ 0+ 18 Reply-Message 2915 0-1 0-1 0 0 19 Callback-Number 2916 0 0-1 0 0 20 Callback-Id 2917 0 0+ 0 0 22 Framed-Route 2918 0 0-1 0 0 23 Framed-IPX-Network 2919 0-1 0-1 0 0-1 24 State [Note 1] 2920 0 0+ 0 0 25 Class 2921 0+ 0+ 0 0+ 26 Vendor-Specific 2922 0 0-1 0 0-1 27 Session-Timeout 2923 0 0-1 0 0-1 28 Idle-Timeout 2924 0 0-1 0 0 29 Termination-Action 2925 0-1 0 0 0 30 Called-Station-Id 2926 0-1 0 0 0 31 Calling-Station-Id 2927 0-1 0 0 0 32 NAS-Identifier [Note 2] 2928 0+ 0+ 0+ 0+ 33 Proxy-State 2929 0-1 0-1 0 0 34 Login-LAT-Service 2930 0-1 0-1 0 0 35 Login-LAT-Node 2931 0-1 0-1 0 0 36 Login-LAT-Group 2932 0 0-1 0 0 37 Framed-AppleTalk-Link 2933 0 0+ 0 0 38 Framed-AppleTalk-Network 2934 0 0-1 0 0 39 Framed-AppleTalk-Zone 2935 0-1 0 0 0 60 CHAP-Challenge 2936 0-1 0 0 0 61 NAS-Port-Type 2937 0-1 0-1 0 0 62 Port-Limit 2938 0-1 0-1 0 0 63 Login-LAT-Port 2939 Request Accept Reject Challenge # Attribute 2941 [Note 1] An Access-Request MUST contain either a User-Password or a 2942 CHAP-Password or State. An Access-Request MUST NOT contain both a 2943 User-Password and a CHAP-Password. If future extensions allow other 2944 kinds of authentication information to be conveyed, the attribute for 2945 that can be used in an Access-Request instead of User-Password or 2946 CHAP-Password. 2948 [Note 1] An Access-Request MUST contain either a NAS-IP-Address or a 2949 NAS-Identifier (or both). 2951 The following table defines the meaning of the above table entries. 2953 0 This attribute MUST NOT be present in packet. 2954 0+ Zero or more instances of this attribute MAY be present in packet. 2955 0-1 Zero or one instance of this attribute MAY be present in packet. 2956 1 Exactly one instance of this attribute MUST be present in packet. 2958 6. IANA Considerations 2960 This section provides guidance to the Internet Assigned Numbers 2961 Authority (IANA) regarding registration of values related to the 2962 RADIUS protocol, in accordance with BCP 26 [13]. 2964 There are three name spaces in RADIUS that require registration: 2965 Packet Type Codes, Attribute Types, and Attribute Values (for certain 2966 Attributes). 2968 RADIUS is not intended as a general-purpose Network Access Server 2969 (NAS) management protocol, and allocations should not be made for 2970 purposes unrelated to Authentication, Authorization or Accounting. 2972 6.1. Definition of Terms 2974 The following terms are used here with the meanings defined in BCP 2975 26: "name space", "assigned value", "registration". 2977 The following policies are used here with the meanings defined in BCP 2978 26: "Private Use", "First Come First Served", "Expert Review", 2979 "Specification Required", "IETF Consensus", "Standards Action." 2981 6.2. Recommended Registration Policies 2983 For registration requests where a Designated Expert should be 2984 consulted, the IESG Area Director for Operations should appoint the 2985 Designated Expert. 2987 For registration requests requiring Expert Review, the ietf-radius 2988 mailing list should be consulted. 2990 Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have 2991 been allocated. Because a new Packet Type has considerable impact on 2992 interoperability, a new Packet Type Code requires Standards Action, 2993 and should be allocated starting at 14. 2995 Attribute Types have a range from 1 to 255, and are the scarcest 2996 resource in RADIUS, thus must be allocated with care. Attributes 1- 2997 53,55,60-88,90-91 have been allocated, with 17 and 21 available for 2998 re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated 2999 following Expert Review, with Specification Required. Release of 3000 blocks of Attribute Types (more than 3 at a time for a given purpose) 3001 should require IETF Consensus. It is recommended that attributes 17 3002 and 21 be used only after all others are exhausted. 3004 Note that RADIUS defines a mechanism for Vendor-Specific extensions 3005 (Attribute 26) and the use of that should be encouraged instead of 3006 allocation of global attribute types, for functions specific only to 3007 one vendor's implementation of RADIUS, where no interoperability is 3008 deemed useful. 3010 As stated in the "Attributes" section above: 3012 "[Attribute Type] Values 192-223 are reserved for experimental 3013 use, values 224-240 are reserved for implementation-specific use, 3014 and values 241-255 are reserved and should not be used." 3016 Therefore Attribute values 192-240 are considered Private Use, and 3017 values 241-255 require Standards Action. 3019 Certain attributes (for example, NAS-Port-Type) in RADIUS define a 3020 list of values to correspond with various meanings. There can be 4 3021 billion (2^32) values for each attribute. Adding additional values to 3022 the list can be done on a First Come, First Served basis by the IANA. 3024 7. Examples 3026 A few examples are presented to illustrate the flow of packets and 3027 use of typical attributes. These examples are not intended to be 3028 exhaustive, many others are possible. Hexadecimal dumps of the 3029 example packets are given in network byte order, using the shared 3030 secret "xyzzy5461". 3032 7.1. User Telnet to Specified Host 3034 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the 3035 RADIUS Server for a user named nemo logging in on port 3 with 3036 password "arctangent". 3038 The Request Authenticator is a 16 octet random number generated by 3039 the NAS. 3041 The User-Password is 16 octets of password padded at end with nulls, 3042 XORed with MD5(shared secret|Request Authenticator). 3044 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb 3045 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d 3046 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 3047 01 10 05 06 00 00 00 03 3048 1 Code = Access-Request (1) 3049 1 ID = 0 3050 2 Length = 56 3051 16 Request Authenticator 3053 Attributes: 3054 6 User-Name = "nemo" 3055 18 User-Password 3056 6 NAS-IP-Address = 192.168.1.16 3057 6 NAS-Port = 3 3059 The RADIUS server authenticates nemo, and sends an Access-Accept UDP 3060 packet to the NAS telling it to telnet nemo to host 192.168.1.3. 3062 The Response Authenticator is a 16-octet MD-5 checksum of the code 3063 (2), id (0), Length (38), the Request Authenticator from above, the 3064 attributes in this reply, and the shared secret. 3066 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf 3067 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 3068 0e 06 c0 a8 01 03 3070 1 Code = Access-Accept (2) 3071 1 ID = 0 (same as in Access-Request) 3072 2 Length = 38 3073 16 Response Authenticator 3075 Attributes: 3076 6 Service-Type (6) = Login (1) 3077 6 Login-Service (15) = Telnet (0) 3078 6 Login-IP-Host (14) = 192.168.1.3 3080 7.2. Framed User Authenticating with CHAP 3082 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the 3083 RADIUS Server for a user named flopsy logging in on port 20 with PPP, 3084 authenticating using CHAP. The NAS sends along the Service-Type and 3085 Framed-Protocol attributes as a hint to the RADIUS server that this 3086 user is looking for PPP, although the NAS is not required to do so. 3088 The Request Authenticator is a 16 octet random number generated by 3089 the NAS, and is also used as the CHAP Challenge. 3091 The CHAP-Password consists of a 1 octet CHAP ID, in this case 22, 3092 followed by the 16 octet CHAP response. 3094 01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e 3095 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9 3096 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04 3097 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00 3098 02 07 06 00 00 00 01 3100 1 Code = 1 (Access-Request) 3101 1 ID = 1 3102 2 Length = 71 3103 16 Request Authenticator 3105 Attributes: 3106 8 User-Name (1) = "flopsy" 3107 19 CHAP-Password (3) 3108 6 NAS-IP-Address (4) = 192.168.1.16 3109 6 NAS-Port (5) = 20 3110 6 Service-Type (6) = Framed (2) 3111 6 Framed-Protocol (7) = PPP (1) 3113 The RADIUS server authenticates flopsy, and sends an Access-Accept 3114 UDP packet to the NAS telling it to start PPP service and assign an 3115 address for the user out of its dynamic address pool. 3117 The Response Authenticator is a 16-octet MD-5 checksum of the code 3118 (2), id (1), Length (56), the Request Authenticator from above, the 3119 attributes in this reply, and the shared secret. 3121 02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0 3122 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01 3123 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00 3124 00 01 0c 06 00 00 05 dc 3125 1 Code = Access-Accept (2) 3126 1 ID = 1 (same as in Access-Request) 3127 2 Length = 56 3128 16 Response Authenticator 3130 Attributes: 3131 6 Service-Type (6) = Framed (2) 3132 6 Framed-Protocol (7) = PPP (1) 3133 6 Framed-IP-Address (8) = 255.255.255.254 3134 6 Framed-Routing (10) = None (0) 3135 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1) 3136 6 Framed-MTU (12) = 1500 3138 7.3. User with Challenge-Response card 3140 The NAS at 192.168.1.16 sends an Access-Request UDP packet to the 3141 RADIUS Server for a user named mopsy logging in on port 7. The user 3142 enters the dummy password "challenge" in this example. The challenge 3143 and response generated by the smart card for this example are 3144 "32769430" and "99101462". 3146 The Request Authenticator is a 16 octet random number generated by 3147 the NAS. 3149 The User-Password is 16 octets of password, in this case "challenge", 3150 padded at the end with nulls, XORed with MD5(shared secret|Request 3151 Authenticator). 3153 01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9 3154 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75 3155 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0 3156 a8 01 10 05 06 00 00 00 07 3158 1 Code = Access-Request (1) 3159 1 ID = 2 3160 2 Length = 57 3161 16 Request Authenticator 3163 Attributes: 3164 7 User-Name (1) = "mopsy" 3165 18 User-Password (2) 3166 6 NAS-IP-Address (4) = 192.168.1.16 3167 6 NAS-Port (5) = 7 3169 The RADIUS server decides to challenge mopsy, sending back a 3170 challenge string and looking for a response. The RADIUS server 3171 therefore and sends an Access-Challenge UDP packet to the NAS. 3173 The Response Authenticator is a 16-octet MD-5 checksum of the code 3174 (11), id (2), length (78), the Request Authenticator from above, the 3175 attributes in this reply, and the shared secret. 3177 The Reply-Message is "Challenge 32769430. Enter response at prompt." 3179 The State is a magic cookie to be returned along with user's 3180 response; in this example 8 octets of data (33 32 37 36 39 34 33 30 3181 in hex). 3183 0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c 3184 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20 3185 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72 3186 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f 3187 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30 3189 1 Code = Access-Challenge (11) 3190 1 ID = 2 (same as in Access-Request) 3191 2 Length = 78 3192 16 Response Authenticator 3194 Attributes: 3195 48 Reply-Message (18) 3196 10 State (24) 3198 The user enters his response, and the NAS send a new Access-Request 3199 with that response, and includes the State Attribute. 3201 The Request Authenticator is a new 16 octet random number. 3203 The User-Password is 16 octets of the user's response, in this case 3204 "99101462", padded at the end with nulls, XORed with MD5(shared 3205 secret|Request Authenticator). 3207 The state is the magic cookie from the Access-Challenge packet, 3208 unchanged. 3210 01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07 3211 c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f 3212 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0 3213 a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39 3214 34 33 30 3215 1 Code = Access-Request (1) 3216 1 ID = 3 (Note that this changes.) 3217 2 Length = 67 3218 16 Request Authenticator 3220 Attributes: 3221 7 User-Name = "mopsy" 3222 18 User-Password 3223 6 NAS-IP-Address (4) = 192.168.1.16 3224 6 NAS-Port (5) = 7 3225 10 State (24) 3227 The Response was incorrect (for the sake of example), so the RADIUS 3228 server tells the NAS to reject the login attempt. 3230 The Response Authenticator is a 16 octet MD-5 checksum of the code 3231 (3), id (3), length(20), the Request Authenticator from above, the 3232 attributes in this reply (in this case, none), and the shared secret. 3234 03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f 3235 9e 74 6a a0 3237 1 Code = Access-Reject (3) 3238 1 ID = 3 (same as in Access-Request) 3239 2 Length = 20 3240 16 Response Authenticator 3242 Attributes: 3243 (none, although a Reply-Message could be sent) 3245 8. Security Considerations 3247 Security issues are the primary topic of this document. 3249 In practice, within or associated with each RADIUS server, there is a 3250 database which associates "user" names with authentication 3251 information ("secrets"). It is not anticipated that a particular 3252 named user would be authenticated by multiple methods. This would 3253 make the user vulnerable to attacks which negotiate the least secure 3254 method from among a set. Instead, for each named user there should 3255 be an indication of exactly one method used to authenticate that user 3256 name. If a user needs to make use of different authentication 3257 methods under different circumstances, then distinct user names 3258 SHOULD be employed, each of which identifies exactly one 3259 authentication method. 3261 Passwords and other secrets should be stored at the respective ends 3262 such that access to them is as limited as possible. Ideally, the 3263 secrets should only be accessible to the process requiring access in 3264 order to perform the authentication. 3266 The secrets should be distributed with a mechanism that limits the 3267 number of entities that handle (and thus gain knowledge of) the 3268 secret. Ideally, no unauthorized person should ever gain knowledge 3269 of the secrets. It is possible to achieve this with SNMP Security 3270 Protocols [14], but such a mechanism is outside the scope of this 3271 specification. 3273 Other distribution methods are currently undergoing research and 3274 experimentation. The SNMP Security document [14] also has an 3275 excellent overview of threats to network protocols. 3277 The User-Password hiding mechanism described in Section 5.2 has not 3278 been subjected to significant amounts of cryptanalysis in the 3279 published literature. Some in the IETF community are concerned that 3280 this method might not provide sufficient confidentiality protection 3281 [15] to passwords transmitted using RADIUS. Users should evaluate 3282 their threat environment and consider whether additional security 3283 mechanisms should be employed. 3285 9. Change Log 3287 The following changes have been made from RFC 2138: 3289 Strings should use UTF-8 instead of US-ASCII and should be handled as 3290 8-bit data. 3292 Integers and dates are now defined as 32 bit unsigned values. 3294 Updated list of attributes that can be included in Access-Challenge 3295 to be consistent with the table of attributes. 3297 User-Name mentions Network Access Identifiers. 3299 User-Name may now be sent in Access-Accept for use with accounting 3300 and Rlogin. 3302 Values added for Service-Type, Login-Service, Framed-Protocol, 3303 Framed-Compression, and NAS-Port-Type. 3305 NAS-Port can now use all 32 bits. 3307 Examples now include hexadecimal displays of the packets. 3309 Source UDP port must be used in conjunction with the Request 3310 Identifier when identifying duplicates. 3312 Multiple subattributes may be allowed in a Vendor-Specific attribute. 3314 An Access-Request is now required to contain either a NAS-IP-Address 3315 or NAS-Identifier (or may contain both). 3317 Added notes under "Operations" with more information on proxy, 3318 retransmissions, and keep-alives. 3320 If multiple Attributes with the same Type are present, the order of 3321 Attributes with the same Type MUST be preserved by any proxies. 3323 Clarified Proxy-State. 3325 Clarified that Attributes must not depend on position within the 3326 packet, as long as Attributes of the same type are kept in order. 3328 Added IANA Considerations section. 3330 Updated section on "Proxy" under "Operations". 3332 Framed-MTU can now be sent in Access-Request as a hint. 3334 Updated Security Considerations. 3336 10. References 3338 References 3340 [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 3341 Authentication Dial In User Service (RADIUS)", RFC 2138, April 3342 1997. 3344 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3345 Levels." BCP 14, RFC 2119, March, 1997. 3347 [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 3348 RFC 1321, April 1992. 3350 [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 3351 1980. 3353 [5] Rigney, C., "RADIUS Accounting", RFC yyyy, February 2000. 3355 [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 3356 1700, October 1994. 3358 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3359 2279, January 1998. 3361 [8] Aboba, B., Beadles, M., "The Network Access Identifier", RFC 3362 2486, January 1999. 3364 [9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: 3365 Private Communications in a Public World", Prentice Hall, March 3366 1995, ISBN 0-13-061466-1. 3368 [10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial 3369 links", RFC 1144, February 1990. 3371 [11] ISO 8859. International Standard -- Information Processing -- 3372 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 3373 Alphabet No. 1, ISO 8859-1:1987. 3375 [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and Coradetti, 3376 T., "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 3378 [13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 3379 Considerations Section in RFCs", BCP 26, RFC 2434, October 3380 1998. 3382 [14] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security 3383 Protocols", RFC 1352, July 1992. 3385 [15] Dobbertin, H., "The Status of MD5 After a Recent Attack." 3386 CryptoBytes Vol.2 No.2, Summer 1996. 3388 11. Acknowledgements 3390 RADIUS was originally developed by Steve Willens of Livingston 3391 Enterprises for their PortMaster series of Network Access Servers. 3393 12. Chair's Address 3395 The working group can be contacted via the current chair: 3397 Carl Rigney 3398 Livingston Enterprises 3399 4464 Willow Road 3400 Pleasanton, California 94588 3401 Phone: +1 925 737 2100 3402 EMail: cdr@livingston.com 3404 13. Author's Address 3406 Questions about this memo can also be directed to: 3408 Carl Rigney 3409 Livingston Enterprises 3410 4464 Willow Road 3411 Pleasanton, California 94588 3413 Phone: +1 925 737 2100 3414 EMail: cdr@livingston.com 3416 Allan C. Rubens 3417 Merit Network, Inc. 3418 4251 Plymouth Road 3419 Ann Arbor, Michigan 48105-2785 3421 EMail: acr@merit.edu 3423 William Allen Simpson 3424 Daydreamer 3425 Computer Systems Consulting Services 3426 1384 Fontaine 3427 Madison Heights, Michigan 48071 3429 E-Mail: wsimpson@greendragon.com 3431 Steve Willens 3432 Livingston Enterprises 3433 4464 Willow Road 3434 Pleasanton, California 94588 3436 E-Mail: steve@livingston.com 3438 14. Full Copyright Statement 3440 Copyright (C) The Internet Society (2000). All Rights Reserved. 3442 This document and translations of it may be copied and furnished to 3443 others, and derivative works that comment on or otherwise explain it 3444 or assist in its implmentation may be prepared, copied, published and 3445 distributed, in whole or in part, without restriction of any kind, 3446 provided that the above copyright notice and this paragraph are 3447 included on all such copies and derivative works. However, this 3448 document itself may not be modified in any way, such as by removing 3449 the copyright notice or references to the Internet Society or other 3450 Internet organizations, except as needed for the purpose of 3451 developing Internet standards in which case the procedures for 3452 copyrights defined in the Internet Standards process must be 3453 followed, or as required to translate it into languages other than 3454 English. 3456 The limited permissions granted above are perpetual and will not be 3457 revoked by the Internet Society or its successors or assigns. 3459 This document and the information contained herein is provided on an 3460 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3461 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3462 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3463 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3464 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."