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