idnits 2.17.1 draft-ietf-nasreq-ext-radiuspract-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8563 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 647, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 653, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 660, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 663, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '2') (Obsoleted by RFC 2866) == Outdated reference: A later version (-05) exists of draft-ietf-radius-radius-v2-01 == Outdated reference: A later version (-04) exists of draft-ietf-radius-accounting-v2-01 == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-04 -- Unexpected draft version: The latest known version of draft-ietf-radius-tunnel-auth is -08, but you're referring to -09. == Outdated reference: A later version (-07) exists of draft-ietf-radius-tunnel-imp-05 == Outdated reference: A later version (-02) exists of draft-ilgun-radius-accvsa-01 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Access Servers Requirements D. Mitton 3 INTERNET-DRAFT Nortel Networks 4 Category: Informational May 2000 5 Expires November 2000 7 Network Access Servers Requirements: 8 Extended RADIUS Practices 9 draft-ietf-nasreq-ext-radiuspract-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 This memo provides information for the Internet community. This memo 17 does not specify an Internet standard of any kind. Distribution of this 18 memo is unlimited. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document is a product of the Network-Access-Server Requirements 36 (NASREQ), Next Generation, Working Group of the Internet Engineering 37 Task Force (IETF). Comments should be submitted to the mailing list 38 nasreq@tdmx.rutgers.edu. 40 Abstract 42 This document describes current practices implemented in NAS products 43 that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The pur- 44 pose of this effort is to give examples that show the need for address- 45 ing and standardizing these types of ad-hoc functions. Since many of 46 these features require a matching server support component, the ability 47 to deploy and manage interoperable NAS and AAA server products is 48 severely hindered. 50 These practices are documented here to show functions that are obviously 51 desired in developing future AAA protocols for NAS deployment. 53 This document is a draft submission of the Network Access Server 54 Requirements (NASREQ) Working Group of the Internet Engineering Task 55 Force (IETF). Comments should be submitted to the mailing list 56 nasreq@tdmx.rutgers.edu. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Attribute Conflicts . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Attribute Value Conflicts . . . . . . . . . . . . . . . . . . 6 65 2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . . . 6 66 2.3 Vendor Specific Attribute Usage . . . . . . . . . . . . . . . 6 67 2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . . . 7 68 2.3.2 Clients that support multiple Vendors: . . . . . . . . . . . 7 70 3. Attribute Data Types . . . . . . . . . . . . . . . . . . . . . 8 72 4. New Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Additional Functions . . . . . . . . . . . . . . . . . . . . . 9 75 5.1 Password Change . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2 Authentication Modes . . . . . . . . . . . . . . . . . . . . . 10 77 5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.4 Pseudo Users . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6. Resource Management . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.2 Resource Management Messages . . . . . . . . . . . . . . . . . 12 83 6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . . . 12 86 7. Policy Services . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8. Accounting Extentions . . . . . . . . . . . . . . . . . . . . . 14 89 8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . . . 14 91 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 15 95 11. Implementation Documents . . . . . . . . . . . . . . . . . . . 16 96 11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 102 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 The RADIUS Working Group was formed in 1995 to document the protocol of 106 the same name, and was chartered to stay within a set of bounds for 107 dial-in terminal servers. Unfortunately the real world of Network 108 Access Servers (NASes) hasn't stayed that small and simple, and contin- 109 ues to evolve at an amazing rate. 111 This document shows some of the current implementations on the market 112 have already outstripped the capabilities of the RADIUS protocol. A 113 quite a few features have been developed completely outside the proto- 114 col. These features use the RADIUS protocol struture and format, but 115 employ operations and semantics well beyond the RFC documents. 117 I learn of the details of these functions from reading industry manuals 118 and often have to respond to them in competive bid specifications. As 119 they become deployed in the field, they gather the force of de-facto 120 standards. 122 Because they have been done outside scope of the RFCs, they are vendor 123 specific, and introduce significant problems in offering an interoper- 124 able product. 126 1.1. Disclaimers 128 The data and numbers in this document have been gleaned from public 129 sources and vendor documents along the way. Actual implementation 130 of many these features and variation from the documentation has not been 131 confirmed. 133 This document is a snapshot of known practices at the time of writing. 134 It is not intended to standardize these practices here, or keep this 135 document current, beyond initial publication. While some detailed infor- 136 mation is given, it is not the purpose of this document to directly or 137 sufficently describe the functions mentioned to the level of a complete 138 functional specification. 140 The author has not transcribed copyrighted material, and is not aware of 141 whether any of these practices have of intellectual property restric- 142 tions. 144 Any numeric assignments or functional operations are subject to change 145 by vendors without notice. I would appreciate any direct input, prefer- 146 ably first hand, from implementors. 148 1.2. Presentation 150 Without any easy organization for the material, information is arranged 151 in a simple taxonomy from bottom-up complexity: 153 - Attribute Usage 155 - Attribute Data Types 157 - Message Codes 159 - New Operations 161 2. Attribute Usage 163 The RADIUS RFCs define attribute type ranges and specific attribute 164 definititions. 166 - There are about 70 defined RADIUS attributes: 168 - Values 192-223 are reserved for experimental use 170 - Values 224-240 are reserved for implementation-specific use 172 - Values 241-255 are reserved and should not be used. 174 Attribute 26 was defined to be the Vendor Specific Attribute (VSA) with 175 further internal structure to allow vendor expansion. 177 2.1. Attribute conflicts 179 In practice attributes 92-255 are in use by a vendor. And another vendor 180 also use attributes in the 90-104 range and conflicts with this usage. 182 To deal with these issues, server vendors have added vendor specific 183 parameters to their client database files. The administrator has to 184 indicate the vendor type of NAS along with the client IP address and 185 secret, so that the server can disambiguate the attribute usage. 187 One server has a single large vendors file to describe the mapping all 188 attributes to an internal format that retains the vendor id. Another 189 server implementation uses multiple dictionaries, each indexed to a NAS 190 and Vendor Model definition list. 192 2.2. Attribute Value Conflicts 194 Adding additional attributes may be more trouble than necessary for sim- 195 ple features. Often existing RADIUS attributes could be extended with 196 additional values (particularly attributes that are enumerated choices). 197 But in doing such there is no way to guarantee not conflicting with 198 other vendor's extentions. 200 2.2.1. Vendor Specific Enumerations proposal 202 One proposed solution to this problem was Vendor Specific Enumerations 203 (VSEs). That is to imbed the vendor's management ID in the numeric 204 value (ala VSAs) which would to divide up the attribute value space. 205 This technique has not seen any acceptance by the working group or other 206 vendors, however, the vendor did accomplish the goal of not conflicting 207 with working group additions or other vendor values. 209 Example dictionary of VSE values: 211 VALUE Service-Type VSE-Authorize-Only 0x06300001 213 VALUE Acct-Status-Type VSE-User-Reject 0x06300001 214 VALUE Acct-Status-Type VSE-Call-Reject 0x06300002 215 VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003 216 VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004 217 VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005 218 VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006 219 VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007 220 VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008 221 VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009 222 VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a 223 VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b 224 VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c 225 VALUE Acct-Status-Type VSE-MP-Start 0x0630000d 226 VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e 227 VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f 228 VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010 229 VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011 231 2.3. Vendor Specific Attribute Usage 233 Because attribute 26 Vendor Specific Attributes (VSAs) came late in the 234 RADIUS working group development, there were some server implementa- 235 tions that were late to support them. Today, there are several leading 236 implementations of clients that make extensive use of VSAs. What's 237 unfortunate is that there is also several different formats of VSAs 238 implemented. This is because the RFC suggested format does not support 239 more than 256 attributes. 241 2.3.1. VSAs in use by some clients: 243 At the time this document was written, the following had be observed: 245 - Microsoft: several for MS-CHAP authentication support [9] 247 - ACC: 42 [10] 249 - Nortel(Bay): about 60 VSAs and 16 VSEs 251 - Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header. 252 Aptis VSAs have shifted from a regular format to a 4-byte header 253 format, due to the large number of attributes implemented. 255 - 3Com (USR): about 130 256 USR VSAs are different than the format suggested in RFC 2138. They 257 have a 4 byte type field and have no internal length. 259 Some vendors that did not initially use VSAs, have shifted in later 260 releases VSA usage as a configuration option. 262 2.3.2. Clients that support Multiple Vendor Attributes 264 Now that MS-CHAP RADIUS attributes have been published in RFC 2548 [9] 265 as Microsoft VSA attributes, it will become typical that for NAS clients 266 that support MS-CHAP authentication to process several different vendor 267 VSA types. This has implications for RADIUS servers that filter or 268 "prune" return attributes based on the vendor make/model of the NAS 269 client. 271 One NAS implementation can receive up to three different vendor specific 272 attribute sets, but will only send attributes according to the "mode" 273 that has been configured by the operator. This allows it to fit into 274 environments where the customer has become dependent on a particular set 275 of RADIUS attributes, and allows the NAS to "drop-in" without server 276 attribute changes. 278 There is another NAS that supports 3 vendor attributes sets con- 279 currently. That is, it will normally use a combination of different 280 vendor VSAs in return profiles from the server. This was done to sup- 281 port a superset of competing vendor's extentions, as well as it's own, 282 and include an extentions from a sister product. 284 3. Attribute Data Types 286 The base RFCs define only has 4 basic data types: 288 - integer, 32 bit unsigned 290 - string, 1-253 bytes, counted. 292 - ipaddr, 32 bit IPv4 294 - date, 32 bit Unix format. 296 Since then, various variations have been added: 298 The tunnel authentication draft [6] adds an optional compound "tag" byte 299 to tunnel attributes. These are a single byte prepended to the data 300 field in order to support sets of attributes to be returned. The byte 301 value must be in the range 01-3F hex or it is considered to be data. 303 Note that there is no native support for IPv6 addresses. In fact IPv6 304 support is missing in some fixed message components too. 306 There have been special attribute types created within servers. For 307 packet filters, the format called "abinary" was created. The user 308 enters an ASCII string filter description in the user profile, but the 309 server parses it into a binary string before passing it to the NAS. 310 This lowers the complexity of the NAS parser. Also a "phonestring" 311 server data type allows additional data type checking at the entry 312 application. 314 4. New Messages 316 A number of new message types have been introduced by various parties 317 over time. The base specification has 6, vendors have added 26. 319 These fall into a number of categories which are described in the next 320 section below. Some of these messages are actually used between the 321 RADIUS server and some other resource server, using a RADIUS-like 322 protocol to implement new functions. 324 6 Accounting Status 325 (now Interim Accounting in draft-radius-ext-04.txt) 326 7 Password Request 327 8 Password Ack 328 9 Password Reject 329 10 Accounting Message 331 21 Resource Free Request 332 22 Resource Free Response 333 23 Resource Query Request 334 24 Resource Query Response 335 25 Alternate Resource Reclaim Request 336 26 NAS Reb Request 337 27 NAS Reb Response 339 29 Next Passcode 340 30 New Pin 341 31 Terminate Session 342 32 Password Expired 343 33 Event Request 344 34 Event Response 345 40 Disconnect Request 346 41 Disconnect Ack 347 42 Disconnect Nak 348 43 Change Filters Request 349 44 Change Filters Ack 350 45 Change Filters Nak 351 50 IP Address Allocate 352 51 IP Address Release 354 5. Additional Functions 356 These are operations performed using RADIUS extentions and additional 357 messages types. 359 5.1. Password Change 361 Remotely requested password change operations were described and pro- 362 posed, but rejected by the working group. None the less, the feature is 363 still deployed in a number of products. 365 Message types: 367 - Password Request 368 - Password Ack or Reject 370 5.2. Authentication Modes 372 Additional message types have been added to negotiate passcode changes 373 for token card servers. 374 - Next Passcode 375 - New PIN 376 - Password Expired 378 They allow the NAS or RADIUS server negotiate passcode changes with an 379 external security server. 381 5.3. Menus 383 At least two vendors have built menuing interaction systems for use with 384 terminal dial-ins. 386 One implementation uses the Reply-Message string as the menu text to be 387 displayed, and the State attribute to keep track of the place in the 388 menu. The menu is displayed using the Access-Challenge message. The 389 response is encoded in the User-Password field like an ordinary chal- 390 lenge sequence would. 392 Some RADIUS clients have problems with this because they cannot handle 393 long or multiple Reply-Message attributes that may have embedded car- 394 riage returns and line-feeds. The new Echo attribute should also con- 395 trol echo behavior on the menu response. Use of the State attribute to 396 keep track of a Challenge sequence is also standard behavior. 398 Another implementation uses two vendor attributes (VSA-Menu-Item, and 399 VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this informa- 400 tion. This implementation is vendor specific. 402 5.4. Pseudo Users 404 One client implementation takes advantage of your vanilla RADIUS 405 server's ability to be used as a remote database server. By using some 406 well-known, implementation specific, strings for Username and Password 407 attributes, the NAS can request information from the server, such as: 408 Static IP routes, Static IPX routes, or the Message of the Day. 410 These are called pseudo-user requests, because they use a user entry 411 with this manufactured name, for purposes other than authentication. 413 Another client also uses a pseudo-user technique for resolving unknown 414 Filter-ID(11) values. An Access-Request message is sent to the RADIUS 415 server with the Filter-ID as the Username value, the password is a known 416 string, and the Service-Type is VSE-Authorization-Only. The response 417 must also be of the same Service-Type, or the response will be ignored. 418 The responding profile should contain the IP-Filter VSA attributes that 419 will define the desired filter. 421 It should be noticed that pseudo-user profiles could be a security prob- 422 lem if a specific or operationally invalid Service-Type is not attached 423 to the profile. The client should test for this returned value, to 424 prevent normal dial-in users from gaining access via this profile. 426 6. Resource Management 428 Authorized sessions may need to be allocated additional dynamic 429 resources in order to preform their services. The most typical is IP 430 addresses. The allocation may want to be delayed until needed or coori- 431 dinated on a scale independent of the RADIUS server. Additional mes- 432 sages may be used to allocate and free these resources. The RADIUS 433 server may proxy these requests to another server. 435 Examples: Certain servers can allocate addresses local to the NAS or use 436 an outboard address server. Other servers have an internal address pool 437 capability, which will fill in the Framed-IP-Address attribute with an 438 assigned value based on pool selected. 440 6.1. Managed Resources: 442 Resources managed include: IP Addresses, Concurrent Logins, Dial-in Port 443 allocation policies, Tunnel limits and load distribution. 445 There are several different types of implementation techniques: 446 - Explicit request/free resource requests 447 - Monitor usage with deamons watching the state 448 - Explicit messages to a state deamon 449 - Monitor Accounting messages for state changes 451 6.2. Resource Management Messages 453 Messages used for resource management 454 - IP Address Allocate 455 - IP Address Release 457 - Resource Request 458 - Resource Response 459 - Resource Free Request 460 - Resource Free Response 461 - Resource Reclaim Request 462 - NAS Reboot Request/Reponse 464 These messages are used to allocate and free resources for a NAS from a 465 centralized server. These mechanisms allows the service provider better 466 administrative control than some automated LAN services, which don't 467 have policy inputs or controls. 469 6.3. Concurrent Logins 471 The RADIUS protocol was designed to allow stateless servers. That is, 472 servers that don't know the status of the active sessions. However, it 473 is very important for many service providers to keep track of how many 474 sessions a given user may have open, and accordingly disallow access. 476 There are several different techniques used to implement login limits on 477 a RADIUS enviroment. Some vendors have build NAS monitoring tools 478 either into their RADIUS servers, either directly or as auxiliary 479 deamons, that can check the session status of the controlled NASes by 480 SNMP or proprietary methods. 482 Other vendors monitor the RADIUS accesses and accounting messages and 483 derive state information from the requests. This monitoring is not as 484 reliable as directly auditing the NAS, but it is also less vendor 485 specific, and can work with any RADIUS NAS, provided it sends both 486 streams to the same server. 488 Some of the approaches used: 489 - SNMP commands 490 - Telnet monitor deamon 491 - Accounting monitor 493 6.4. Authorization Changes: 495 To implement an active changes to a running session, such as filter 496 changes or timeout and disconnect, at least one vendor has added a 497 RADIUS "server" to his NAS. This server accepts messages sent from an 498 application in the network, and upon matching some session information, 499 will perform such operations. 501 Messages sent from Server to NAS 503 - Change Filter Request 504 - Change Filter Ack / Nak 505 - Disconnect Request 506 - Disconnect Response 508 Filters are used to limit the access the user has to the network by res- 509 tricting the systems and protocols he can send packets to. Upon fulfil- 510 ling some registration with an authorization server, the service pro- 511 vider may wish to remove those restrictions, or disconnect the user. 513 7. Policy Services 515 Some vendors have implemented policy servers using RADIUS as the control 516 protocol. Two prominent Policy Managers act as RADIUS proxy filters and 517 use RADIUS messages to deny access to new sessions that exceed active 518 policy limits. 520 One implementation behaves like a RADIUS proxy server, but with a policy 521 process governing it's forward decisions. Typically a pre-authentication 522 message (like the new RADIUS draft Service-Type = CallCheck) is emitted 523 by the NAS upon call arrival. This message will contain only the 524 Dialed-Number information in the Username field. The server receives 525 the Access-Request messages and processes them against it's knowledge of 526 the network state and the provisioned policies. 528 An Access-Accept will be returned to the system to accept the call, and 529 many also contain dynamic policy information and Virtual POP specific 530 default parameters. When the real PPP authentication is engaged, the 531 proxy will forwards the Access-Request to a RADIUS server, if this ses- 532 sion was approved at pre-auth. It can also process Access-Requests that 533 were not preceded by a pre-auth exchange, and use the Username field for 534 information about the desired realm, in it's policy evaluation. 536 The other implementation performs a similar operations. It uses VSAs in 537 the Access-Request to distinguish pre-authentication message types. 539 8. Accounting Extentions 541 Traditional Accounting only records session starts and stops which is 542 pretty boring. Additional session information reporting can be added 543 easily which gives a better picture of operation in use as they happen. 544 Some event types are listed below. 546 8.1. Auditing/Activity 548 - Call or Modem Starts, Stops 549 - Tunnel Starts, Stops 550 - Tunnel Link Starts & Stops 551 - Admin changes 553 These events if monitored by a stateful server can be used to gather 554 information about the usage of the network on a user/session basis. 555 Information about when a particular user entered the network is more 556 relevant to network service management than attempting track backwards 557 from low level IP address flows. Useful information about port usage 558 across a range of NASes allows service provider to quickly find problem 559 areas or users. 561 Information about call failures, successes, and quality are also deemed 562 important many service providers. 564 Extending RADIUS accounting is easy, it's suprising that more implemen- 565 tations have not been made in this area. 567 9. Conclusions 569 In real life RADIUS Servers are becoming rather complex software imple- 570 mentations. They are often brokering authentication and authorization 571 to other authorities or repositories. Variants of RADIUS protocol is 572 often used as glue protocol for these type of solutions. 574 Some of the solutions are kludges that could be cleaned up by better 575 underlying services. 577 What this means to the implementor is that RADIUS as the RFCs describe 578 it is becoming less relevant. Many additional features require matching 579 client and server processing message processing. Without standardiza- 580 tion of these functions we don't have much interoperability in the field 581 and much effort is spent in reverse engineering and reaction to unknown 582 areas. 584 This draft is not a complete survey by any means. It is a representa- 585 tive summary of practices that I am aware of at the time of writing. I 586 still appreciate input from vendors or users on practices and details 587 known, and particularly any reference material you can pass me. 589 10. Security Considerations 591 This document documents known practices, and does not propose any par- 592 ticular new protocols. Extentions to RADIUS protocols create new secu- 593 rity implications because of their functions go beyond those considered 594 in the RFCs. Some of these include: 596 - The ability to change passwords via a RADIUS exchange was 597 deliberately left out of the protocol by the working group, because 598 of security concerns. 599 - The Pseudo-User profiles and the Call-Check operation may allow 600 unintended access if static and well-know account names and passwords 601 are allowed to be used by regular interactive accounts. 602 - Resource Management operations must be protected from denial of 603 service attacks. 604 - Client side authorization change exchanges need to be secured from 605 attacks that could disconnect or restrict user services. 607 11. Implementation Documents 609 Information about the following implementations can be obtained from the 610 respective owners. Most listed are availible from the manufacturer's 611 web site. 613 11.1. Clients: 615 - 3Com(USR) Total Control Hub 616 - Ericsson(ACC) Tigris 617 draft-ilgun-radius-accvsa-01.txt, Dec 1998 618 - Lucent(Ascend) MAX TNT 619 - Lucent(Livingston) Portmaster 620 - Nortel(Aptis) CVX 1800 621 - Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller 622 - Intel(Shiva) 624 11.2. Servers: 626 - Ericsson(ACC) Virtual Port Server Manager 627 - Funk Steel-Belted RADIUS 628 - Intel(Shiva) Access Manager 629 - Lucent(Ascend) Access Control 630 - Lucent(Ascend) NavisAccess 631 - Lucent(Ascend) Modified Livingston 1.16 632 - Lucent(Livingston) V2.01 633 - Lucent(Livingston) ABM 634 - Lucent Port Authority 635 - MERIT AAA Servers 636 - Nortel(Bay Networks) BaySecure Access Control 637 - Nortel Preside Radius 638 - Nortel CVX Policy Manager 640 12. References 642 [1] C. Rigney, et.al. "Remote Authentication Dial In User Service 643 (RADIUS)", RFC 2138, April 1977. 645 [2] C. Rigney, et.al. "RADIUS Accounting", RFC 2139, April 1977. 647 [3] C. Rigney, et.al. "Remote Authentication Dial In User Service 648 (RADIUS)", draft-ietf-radius-radius-v2-01.txt, May 1999 650 [4] C. Rigney, et.al. "RADIUS Accounting", draft-ietf-radius- 651 accounting-v2-01.txt, May 1999. 653 [5] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", draft-ietf- 654 radius-ext-04.txt, May 1999 656 [6] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for 657 Tunnel Protocol Support", draft-ietf-radius-tunnel-auth-09.txt, 658 August 1999 660 [7] G. Zorn, D. Mitton, "RADIUS Accounting Modifications for Tunnel Pro- 661 tocol Support",draft-ietf-radius-tunnel-acct-04.txt, August 1999 663 [8] Aboba, Zorn, "Implementation of PPTP/L2TP Compulsory Tunneling via 664 RADIUS", draft-ietf-radius-tunnel-imp-05.txt, August 1999. 666 [9] G. Zorn, "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, 667 March 1999 669 [10] K. Ilgun, "RADIUS Vendor Specific Attributes for ACC/Ericsson 670 Datacom Access", draft-ilgun-radius-accvsa-01.txt, December 1998 672 13. Author's Address 674 David Mitton 675 Nortel Networks 676 8 Federal St 677 Billerica, MA 01821 679 978-288-4570 680 dmitton@nortelnetworks.com 682 14. Full Copyright Statement 684 Copyright (C) The Internet Society (Feb 2000). All Rights Reserved. 686 This document and translations of it may be copied and furnished to oth- 687 ers, and derivative works that comment on or otherwise explain it or 688 assist in its implementation may be prepared, copied, published and dis- 689 tributed, in whole or in part, without restriction of any kind, provided 690 that the above copyright notice and this paragraph are included on all 691 such copies and derivative works. However, this document itself may not 692 be modified in any way, such as by removing the copyright notice or 693 references to the Internet Society or other Internet organizations, 694 except as needed for the purpose of developing Internet standards in 695 which case the procedures for copyrights defined in the Internet Stan- 696 dards process must be followed, or as required to translate it into 697 languages other than English. 699 The limited permissions granted above are perpetual and will not be 700 revoked by the Internet Society or its successors or assigns. 702 This document and the information contained herein is provided on an "AS 703 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 704 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 705 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 706 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- 707 NESS FOR A PARTICULAR PURPOSE."