From: Alan T. DeKok Date: Mon, 7 Nov 2011 15:19:29 +0000 (+0100) Subject: Updated the NAI document X-Git-Tag: release_3_0_0_beta0~518 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ae1e940487c845b7fff8bf0f0adfd930eb819551;p=thirdparty%2Ffreeradius-server.git Updated the NAI document --- diff --git a/doc/rfc/rfc2882.txt b/doc/rfc/rfc2882.txt deleted file mode 100644 index f6b9535cfd5..00000000000 --- a/doc/rfc/rfc2882.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Mitton -Request for Comments: 2882 Nortel Networks -Category: Informational July 2000 - - - Network Access Servers Requirements: - Extended RADIUS Practices - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes current practices implemented in NAS products - that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The - purpose of this effort is to give examples that show the need for - addressing and standardizing these types of ad-hoc functions. Since - many of these features require a matching server support component, - the ability to deploy and manage interoperable NAS and AAA server - products is severely hindered. - - These practices are documented here to show functions that are - obviously desired in developing future AAA protocols for NAS - deployment. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Disclaimers . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Presentation . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Attribute Conflicts . . . . . . . . . . . . . . . . . . . 4 - 2.2. Attribute Value Conflicts . . . . . . . . . . . . . . . . 4 - 2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . 4 - 2.3 Vendor Specific Attribute Usage . . . . . . . . . . . . . 5 - 2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . 5 - 2.3.2 Clients that support multiple Vendors: . . . . . . . . . 5 - 3. Attribute Data Types . . . . . . . . . . . . . . . . . . . 6 - 4. New Messages . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. Additional Functions . . . . . . . . . . . . . . . . . . . 7 - 5.1 Password Change . . . . . . . . . . . . . . . . . . . . . 8 - - - -Mitton Informational [Page 1] - -RFC 2882 Extended RADIUS Practices July 2000 - - - 5.2 Authentication Modes . . . . . . . . . . . . . . . . . . . 8 - 5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.4 Pseudo Users . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Resource Management . . . . . . . . . . . . . . . . . . . . 9 - 6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . 9 - 6.2 Resource Management Messages . . . . . . . . . . . . . . . 10 - 6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10 - 6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11 - 7. Policy Services . . . . . . . . . . . . . . . . . . . . . . 11 - 8. Accounting Extensions . . . . . . . . . . . . . . . . . . . 12 - 8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12 - 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 - 11. Implementation Documents . . . . . . . . . . . . . . . . . 13 - 11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . 14 - 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 15 - 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 16 - -1. Introduction - - The RADIUS Working Group was formed in 1995 to document the protocol - of the same name, and was chartered to stay within a set of bounds - for dial-in terminal servers. Unfortunately the real world of - Network Access Servers (NASes) hasn't stayed that small and simple, - and continues to evolve at an amazing rate. - - This document shows some of the current implementations on the market - have already outstripped the capabilities of the RADIUS protocol. A - quite a few features have been developed completely outside the - protocol. These features use the RADIUS protocol structure and - format, but employ operations and semantics well beyond the RFC - documents. - - I learn of the details of these functions from reading industry - manuals and often have to respond to them in competive bid - specifications. As they become deployed in the field, they gather - the force of de-facto standards. - - Because they have been done outside scope of the RFCs, they are - vendor specific, and introduce significant problems in offering an - interoperable product. - - - - - - - - -Mitton Informational [Page 2] - -RFC 2882 Extended RADIUS Practices July 2000 - - -1.1. Disclaimers - - The data and numbers in this document have been gleaned from public - sources and vendor documents along the way. Actual implementation of - many these features and variation from the documentation has not been - confirmed. - - This document is a snapshot of known practices at the time of - writing. It is not intended to standardize these practices here, or - keep this document current, beyond initial publication. While some - detailed information is given, it is not the purpose of this document - to directly or sufficiently describe the functions mentioned to the - level of a complete functional specification. - - The author has not transcribed copyrighted material, and is not aware - of whether any of these practices have of intellectual property - restrictions. - - Any numeric assignments or functional operations are subject to - change by vendors without notice. I would appreciate any direct - input, preferably first hand, from implementors. - -1.2. Presentation - - Without any easy organization for the material, information is - arranged in a simple taxonomy from bottom-up complexity: - - - Attribute Usage - - - Attribute Data Types - - - Message Codes - - - New Operations - -2. Attribute Usage - - The RADIUS RFCs define attribute type ranges and specific attribute - definitions. - - - - There are about 70 defined RADIUS attributes: - - - Values 192-223 are reserved for experimental use - - - Values 224-240 are reserved for implementation-specific use - - - Values 241-255 are reserved and should not be used. - - - -Mitton Informational [Page 3] - -RFC 2882 Extended RADIUS Practices July 2000 - - - Attribute 26 was defined to be the Vendor Specific Attribute (VSA) - with further internal structure to allow vendor expansion. - -2.1. Attribute conflicts - - In practice attributes 92-255 are in use by a vendor. And another - vendor also use attributes in the 90-104 range and conflicts with - this usage. - - To deal with these issues, server vendors have added vendor specific - parameters to their client database files. The administrator has to - indicate the vendor type of NAS along with the client IP address and - secret, so that the server can disambiguate the attribute usage. - - One server has a single large vendors file to describe the mapping - all attributes to an internal format that retains the vendor id. - Another server implementation uses multiple dictionaries, each - indexed to a NAS and Vendor Model definition list. - -2.2. Attribute Value Conflicts - - Adding additional attributes may be more trouble than necessary for - simple features. Often existing RADIUS attributes could be extended - with additional values (particularly attributes that are enumerated - choices). But in doing such there is no way to guarantee not - conflicting with other vendor's extensions. - -2.2.1. Vendor Specific Enumerations proposal - - One proposed solution to this problem was Vendor Specific - Enumerations (VSEs). That is to imbed the vendor's management ID in - the numeric value (ala VSAs) which would to divide up the attribute - value space. This technique has not seen any acceptance by the - working group or other vendors, however, the vendor did accomplish - the goal of not conflicting with working group additions or other - vendor values. - - Example dictionary of VSE values: - - VALUE Service-Type VSE-Authorize-Only 0x06300001 - - VALUE Acct-Status-Type VSE-User-Reject 0x06300001 - VALUE Acct-Status-Type VSE-Call-Reject 0x06300002 - VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003 - VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004 - VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005 - VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006 - VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007 - - - -Mitton Informational [Page 4] - -RFC 2882 Extended RADIUS Practices July 2000 - - - VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008 - VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009 - VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a - VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b - VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c - VALUE Acct-Status-Type VSE-MP-Start 0x0630000d - VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e - VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f - VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010 - VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011 - -2.3. Vendor Specific Attribute Usage - - Because attribute 26 Vendor Specific Attributes (VSAs) came late in - the RADIUS working group development, there were some server - implementations that were late to support them. Today, there are - several leading implementations of clients that make extensive use of - VSAs. What's unfortunate is that there is also several different - formats of VSAs implemented. This is because the RFC suggested - format does not support more than 256 attributes. - -2.3.1. VSAs in use by some clients: - - At the time this document was written, the following had be observed: - - - Microsoft: several for MS-CHAP authentication support [9] - - - ACC: 42 [10] - - - Nortel(Bay): about 60 VSAs and 16 VSEs - - - Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header. - Aptis VSAs have shifted from a regular format to a 4-byte header - format, due to the large number of attributes implemented. - - - 3Com (USR): about 130 - USR VSAs are different than the format suggested in RFC 2138. - They have a 4 byte type field and have no internal length. - - Some vendors that did not initially use VSAs, have shifted in later - releases VSA usage as a configuration option. - -2.3.2. Clients that support Multiple Vendor Attributes - - Now that MS-CHAP RADIUS attributes have been published in RFC 2548 - [9] as Microsoft VSA attributes, it will become typical that for NAS - clients that support MS-CHAP authentication to process several - - - - -Mitton Informational [Page 5] - -RFC 2882 Extended RADIUS Practices July 2000 - - - different vendor VSA types. This has implications for RADIUS servers - that filter or "prune" return attributes based on the vendor - make/model of the NAS client. - - One NAS implementation can receive up to three different vendor - specific attribute sets, but will only send attributes according to - the "mode" that has been configured by the operator. This allows it - to fit into environments where the customer has become dependent on a - particular set of RADIUS attributes, and allows the NAS to "drop-in" - without server attribute changes. - - There is another NAS that supports 3 vendor attributes sets - concurrently. That is, it will normally use a combination of - different vendor VSAs in return profiles from the server. This was - done to support a superset of competing vendor's extensions, as well - as it's own, and include an extensions from a sister product. - -3. Attribute Data Types - - The base RFCs define only has 4 basic data types: - - - integer, 32 bit unsigned - - - string, 1-253 bytes, counted. - - - ipaddr, 32 bit IPv4 - - - date, 32 bit Unix format. - - Since then, various variations have been added: - - The tunnel authentication document [6] adds an optional compound - "tag" byte to tunnel attributes. These are a single byte prepended - to the data field in order to support sets of attributes to be - returned. The byte value must be in the range 01-3F hex or it is - considered to be data. - - Note that there is no native support for IPv6 addresses. In fact IPv6 - support is missing in some fixed message components too. - - There have been special attribute types created within servers. For - packet filters, the format called "abinary" was created. The user - enters an ASCII string filter description in the user profile, but - the server parses it into a binary string before passing it to the - NAS. This lowers the complexity of the NAS parser. Also a - "phonestring" server data type allows additional data type checking - at the entry application. - - - - -Mitton Informational [Page 6] - -RFC 2882 Extended RADIUS Practices July 2000 - - -4. New Messages - - A number of new message types have been introduced by various parties - over time. The base specification has 6, vendors have added 26. - - These fall into a number of categories which are described in the - next section below. Some of these messages are actually used between - the RADIUS server and some other resource server, using a RADIUS-like - protocol to implement new functions. - - 6 Accounting Status - (now Interim Accounting [5]) - 7 Password Request - 8 Password Ack - 9 Password Reject - 10 Accounting Message - - 21 Resource Free Request - 22 Resource Free Response - 23 Resource Query Request - 24 Resource Query Response - 25 Alternate Resource Reclaim Request - 26 NAS Reboot Request - 27 NAS Reboot Response - - 29 Next Passcode - 30 New Pin - 31 Terminate Session - 32 Password Expired - 33 Event Request - 34 Event Response - 40 Disconnect Request - 41 Disconnect Ack - 42 Disconnect Nak - 43 Change Filters Request - 44 Change Filters Ack - 45 Change Filters Nak - 50 IP Address Allocate - 51 IP Address Release - -5. Additional Functions - - These are operations performed using RADIUS extensions and additional - messages types. - - - - - - - -Mitton Informational [Page 7] - -RFC 2882 Extended RADIUS Practices July 2000 - - -5.1. Password Change - - Remotely requested password change operations were described and - proposed, but rejected by the working group. None the less, the - feature is still deployed in a number of products. - - Message types: - - - Password Request - - Password Ack or Reject - -5.2. Authentication Modes - - Additional message types have been added to negotiate passcode - changes for token card servers. - - - Next Passcode - - New PIN - - Password Expired - - They allow the NAS or RADIUS server negotiate passcode changes with - an external security server. - -5.3. Menus - - At least two vendors have built menuing interaction systems for use - with terminal dial-ins. - - One implementation uses the Reply-Message string as the menu text to - be displayed, and the State attribute to keep track of the place in - the menu. The menu is displayed using the Access-Challenge message. - The response is encoded in the User-Password field like an ordinary - challenge sequence would. - - Some RADIUS clients have problems with this because they cannot - handle long or multiple Reply-Message attributes that may have - embedded carriage returns and line-feeds. The new Echo attribute - should also control echo behavior on the menu response. Use of the - State attribute to keep track of a Challenge sequence is also - standard behavior. - - Another implementation uses two vendor attributes (VSA-Menu-Item, and - VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this - information. This implementation is vendor specific. - - - - - - - -Mitton Informational [Page 8] - -RFC 2882 Extended RADIUS Practices July 2000 - - -5.4. Pseudo Users - - One client implementation takes advantage of your vanilla RADIUS - server's ability to be used as a remote database server. By using - some well-known, implementation specific, strings for Username and - Password attributes, the NAS can request information from the server, - such as: Static IP routes, Static IPX routes, or the Message of the - Day. - - These are called pseudo-user requests, because they use a user entry - with this manufactured name, for purposes other than authentication. - - Another client also uses a pseudo-user technique for resolving - unknown Filter-ID(11) values. An Access-Request message is sent to - the RADIUS server with the Filter-ID as the Username value, the - password is a known string, and the Service-Type is VSE- - Authorization-Only. The response must also be of the same Service- - Type, or the response will be ignored. The responding profile should - contain the IP-Filter VSA attributes that will define the desired - filter. - - It should be noticed that pseudo-user profiles could be a security - problem if a specific or operationally invalid Service-Type is not - attached to the profile. The client should test for this returned - value, to prevent normal dial-in users from gaining access via this - profile. - -6. Resource Management - - Authorized sessions may need to be allocated additional dynamic - resources in order to perform their services. The most typical is IP - addresses. The allocation may want to be delayed until needed or - coordinated on a scale independent of the RADIUS server. Additional - messages may be used to allocate and free these resources. The - RADIUS server may proxy these requests to another server. - - Examples: Certain servers can allocate addresses local to the NAS or - use an outboard address server. Other servers have an internal - address pool capability, which will fill in the Framed-IP-Address - attribute with an assigned value based on pool selected. - -6.1. Managed Resources: - - Resources managed include: IP Addresses, Concurrent Logins, Dial-in - Port allocation policies, Tunnel limits and load distribution. - - - - - - -Mitton Informational [Page 9] - -RFC 2882 Extended RADIUS Practices July 2000 - - - There are several different types of implementation techniques: - - - Explicit request/free resource requests - - Monitor usage with deamons watching the state - - Explicit messages to a state deamon - - Monitor Accounting messages for state changes - -6.2. Resource Management Messages - - Messages used for resource management - - - IP Address Allocate - - IP Address Release - - - Resource Request - - Resource Response - - Resource Free Request - - Resource Free Response - - Resource Reclaim Request - - NAS Reboot Request/Response - - These messages are used to allocate and free resources for a NAS from - a centralized server. These mechanisms allows the service provider - better administrative control than some automated LAN services, which - don't have policy inputs or controls. - -6.3. Concurrent Logins - - The RADIUS protocol was designed to allow stateless servers. That - is, servers that don't know the status of the active sessions. - However, it is very important for many service providers to keep - track of how many sessions a given user may have open, and - accordingly disallow access. - - There are several different techniques used to implement login limits - on a RADIUS environment. Some vendors have build NAS monitoring - tools either into their RADIUS servers, either directly or as - auxiliary deamons, that can check the session status of the - controlled NASes by SNMP or proprietary methods. - - Other vendors monitor the RADIUS accesses and accounting messages and - derive state information from the requests. This monitoring is not - as reliable as directly auditing the NAS, but it is also less vendor - specific, and can work with any RADIUS NAS, provided it sends both - streams to the same server. - - Some of the approaches used: - - - - -Mitton Informational [Page 10] - -RFC 2882 Extended RADIUS Practices July 2000 - - - - SNMP commands - - Telnet monitor deamon - - Accounting monitor - -6.4. Authorization Changes: - - To implement an active changes to a running session, such as filter - changes or timeout and disconnect, at least one vendor has added a - RADIUS "server" to his NAS. This server accepts messages sent from an - application in the network, and upon matching some session - information, will perform such operations. - - Messages sent from Server to NAS - - - Change Filter Request - - Change Filter Ack / Nak - - Disconnect Request - - Disconnect Response - - Filters are used to limit the access the user has to the network by - restricting the systems and protocols he can send packets to. Upon - fulfilling some registration with an authorization server, the - service provider may wish to remove those restrictions, or disconnect - the user. - -7. Policy Services - - Some vendors have implemented policy servers using RADIUS as the - control protocol. Two prominent Policy Managers act as RADIUS proxy - filters and use RADIUS messages to deny access to new sessions that - exceed active policy limits. - - One implementation behaves like a RADIUS proxy server, but with a - policy process governing it's forward decisions. Typically a pre- - authentication message (like the new RADIUS draft Service-Type = - CallCheck) is emitted by the NAS upon call arrival. This message will - contain only the Dialed-Number information in the Username field. - The server receives the Access-Request messages and processes them - against it's knowledge of the network state and the provisioned - policies. - - An Access-Accept will be returned to the system to accept the call, - and many also contain dynamic policy information and Virtual POP - specific default parameters. When the real PPP authentication is - engaged, the proxy will forwards the Access-Request to a RADIUS - server, if this session was approved at pre-auth. It can also - process Access-Requests that were not preceded by a pre-auth - exchange, and use the Username field for information about the - - - -Mitton Informational [Page 11] - -RFC 2882 Extended RADIUS Practices July 2000 - - - desired realm, in it's policy evaluation. - - The other implementation performs a similar operations. It uses VSAs - in the Access-Request to distinguish pre-authentication message - types. - -8. Accounting Extensions - - Traditional Accounting only records session starts and stops which is - pretty boring. Additional session information reporting can be added - easily which gives a better picture of operation in use as they - happen. Some event types are listed below. - -8.1. Auditing/Activity - - - Call or Modem Starts, Stops - - Tunnel Starts, Stops - - Tunnel Link Starts & Stops - - Admin changes - - These events if monitored by a stateful server can be used to gather - information about the usage of the network on a user/session basis. - Information about when a particular user entered the network is more - relevant to network service management than attempting track - backwards from low level IP address flows. Useful information about - port usage across a range of NASes allows service provider to quickly - find problem areas or users. - - Information about call failures, successes, and quality are also - deemed important many service providers. - - Extending RADIUS accounting is easy, it's surprising that more - implementations have not been made in this area. - -9. Conclusions - - In real life RADIUS Servers are becoming rather complex software - implementations. They are often brokering authentication and - authorization to other authorities or repositories. Variants of - RADIUS protocol is often used as glue protocol for these type of - solutions. - - Some of the solutions are kludges that could be cleaned up by better - underlying services. - - What this means to the implementor is that RADIUS as the RFCs - describe it is becoming less relevant. Many additional features - require matching client and server processing message processing. - - - -Mitton Informational [Page 12] - -RFC 2882 Extended RADIUS Practices July 2000 - - - Without standardization of these functions we don't have much - interoperability in the field and much effort is spent in reverse - engineering and reaction to unknown areas. - - This memo is not a complete survey by any means. It is a - representative summary of practices that I am aware of at the time of - writing. I still appreciate input from vendors or users on practices - and details known, and particularly any reference material you can - pass me. - -10. Security Considerations - - This document documents known practices, and does not propose any - particular new protocols. Extensions to RADIUS protocols create new - security implications because of their functions go beyond those - considered in the RFCs. Some of these include: - - - The ability to change passwords via a RADIUS exchange was - deliberately left out of the protocol by the working group, - because of security concerns. - - The Pseudo-User profiles and the Call-Check operation may allow - unintended access if static and well-know account names and - passwords are allowed to be used by regular interactive accounts. - - Resource Management operations must be protected from denial of - service attacks. - - Client side authorization change exchanges need to be secured from - attacks that could disconnect or restrict user services. - -11. Implementation Documents - - Information about the following implementations can be obtained from - the respective owners. Most listed are available from the - manufacturer's web site. - -11.1. Clients: - - - 3Com(USR) Total Control Hub - - Ericsson(ACC) Tigris - draft-ilgun-radius-accvsa-01.txt, Dec 1998 - - Lucent(Ascend) MAX TNT - - Lucent(Livingston) Portmaster - - Nortel(Aptis) CVX 1800 - - Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller - - Intel(Shiva) - - - - - - - -Mitton Informational [Page 13] - -RFC 2882 Extended RADIUS Practices July 2000 - - -11.2. Servers: - - - Ericsson(ACC) Virtual Port Server Manager - - Funk Steel-Belted RADIUS - - Intel(Shiva) Access Manager - - Lucent(Ascend) Access Control - - Lucent(Ascend) NavisAccess - - Lucent(Ascend) Modified Livingston 1.16 - - Lucent(Livingston) V2.01 - - Lucent(Livingston) ABM - - Lucent Port Authority - - MERIT AAA Servers - - Nortel(Bay Networks) BaySecure Access Control - - Nortel Preside Radius - - Nortel CVX Policy Manager - -12. References - - [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote - Authentication Dial In User Service (RADIUS)", RFC 2138, April - 1997. - - [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. - - [3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote - Authentication Dial In User Service (RADIUS)", RFC 2865, June - 2000. - - [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. - - [5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC - 2869, June 2000. - - [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and - I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC - 2868, June 2000. - - [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting - Modifications for Tunnel Protocol Support", RFC 2867, June 2000. - - [8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory - Tunneling via RADIUS", RFC 2809, April 2000. - - [9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC - 2548, March 1999. - - [10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson - Datacom Access", Work in Progress. - - - -Mitton Informational [Page 14] - -RFC 2882 Extended RADIUS Practices July 2000 - - -13. Author's Address - - David Mitton - Nortel Networks - 880 Technology Park Drive - Billerica, MA 01821 - - Phone: 978-288-4570 - EMail: dmitton@nortelnetworks.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mitton Informational [Page 15] - -RFC 2882 Extended RADIUS Practices July 2000 - - -14. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Mitton Informational [Page 16] - diff --git a/doc/rfc/rfc4282.txt b/doc/rfc/rfc4282.txt new file mode 100644 index 00000000000..99fbb83e861 --- /dev/null +++ b/doc/rfc/rfc4282.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group B. Aboba +Request for Comments: 4282 Microsoft +Obsoletes: 2486 M. Beadles +Category: Standards Track ENDFORCE + J. Arkko + Ericsson + P. Eronen + Nokia + December 2005 + + + The Network Access Identifier + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In order to provide roaming services, it is necessary to have a + standardized method for identifying users. This document defines the + syntax for the Network Access Identifier (NAI), the user identity + submitted by the client during network authentication. "Roaming" may + be loosely defined as the ability to use any one of multiple Internet + Service Providers (ISPs), while maintaining a formal, customer-vendor + relationship with only one. Examples of where roaming capabilities + might be required include ISP "confederations" and ISP-provided + corporate network access support. This document is a revised version + of RFC 2486, which originally defined NAIs. Enhancements include + international character set and privacy support, as well as a number + of corrections to the original RFC. + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 1] + +RFC 4282 The Network Access Identifier December 2005 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Terminology ................................................3 + 1.2. Requirements Language ......................................4 + 1.3. Purpose ....................................................4 + 2. NAI Definition ..................................................4 + 2.1. Formal Syntax ..............................................4 + 2.2. NAI Length Considerations ..................................6 + 2.3. Support for Username Privacy ...............................6 + 2.4. International Character Sets ...............................7 + 2.5. Compatibility with E-Mail Usernames ........................8 + 2.6. Compatibility with DNS .....................................8 + 2.7. Realm Construction .........................................8 + 2.8. Examples ..................................................10 + 3. Security Considerations ........................................10 + 4. IANA Considerations ............................................11 + 5. References .....................................................11 + 5.1. Normative References ......................................11 + 5.2. Informative References ....................................12 + Appendix A. Changes from RFC 2486 ................................14 + Appendix B. Acknowledgements .....................................14 + +1. Introduction + + Considerable interest exists for a set of features that fit within + the general category of "roaming capability" for network access, + including dialup Internet users, Virtual Private Network (VPN) usage, + wireless LAN authentication, and other applications. Interested + parties have included the following: + + o Regional Internet Service Providers (ISPs) operating within a + particular state or province, looking to combine their efforts + with those of other regional providers to offer dialup service + over a wider area. + + o National ISPs wishing to combine their operations with those of + one or more ISPs in another nation to offer more comprehensive + dialup service in a group of countries or on a continent. + + o Wireless LAN hotspots providing service to one or more ISPs. + + o Businesses desiring to offer their employees a comprehensive + package of dialup services on a global basis. Those services may + include Internet access as well as secure access to corporate + intranets via a VPN, enabled by tunneling protocols such as the + + + + + +Aboba, et al. Standards Track [Page 2] + +RFC 4282 The Network Access Identifier December 2005 + + + Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 + Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling + Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC2401]. + + In order to enhance the interoperability of roaming services, it is + necessary to have a standardized method for identifying users. This + document defines syntax for the Network Access Identifier (NAI). + Examples of implementations that use the NAI, and descriptions of its + semantics, can be found in [RFC2194]. + + This document is a revised version of RFC 2486 [RFC2486], which + originally defined NAIs. Differences and enhancements compared to + RFC 2486 are listed in Appendix A. + +1.1. Terminology + + This document frequently uses the following terms: + + Network Access Identifier + + The Network Access Identifier (NAI) is the user identity submitted + by the client during network access authentication. In roaming, + the purpose of the NAI is to identify the user as well as to + assist in the routing of the authentication request. Please note + that the NAI may not necessarily be the same as the user's e-mail + address or the user identity submitted in an application layer + authentication. + + Network Access Server + + The Network Access Server (NAS) is the device that clients connect + to in order to get access to the network. In PPTP terminology, + this is referred to as the PPTP Access Concentrator (PAC), and in + L2TP terminology, it is referred to as the L2TP Access + Concentrator (LAC). In IEEE 802.11, it is referred to as an + Access Point. + + Roaming Capability + + Roaming capability can be loosely defined as the ability to use + any one of multiple Internet Service Providers (ISPs), while + maintaining a formal, customer-vendor relationship with only one. + Examples of cases where roaming capability might be required + include ISP "confederations" and ISP-provided corporate network + access support. + + + + + + +Aboba, et al. Standards Track [Page 3] + +RFC 4282 The Network Access Identifier December 2005 + + + Tunneling Service + + A tunneling service is any network service enabled by tunneling + protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One + example of a tunneling service is secure access to corporate + intranets via a Virtual Private Network (VPN). + +1.2. Requirements Language + + In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", + "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as + described in [RFC2119]. + +1.3. Purpose + + As described in [RFC2194], there are a number of providers offering + network access services, and the number of Internet Service Providers + involved in roaming consortia is increasing rapidly. + + In order to be able to offer roaming capability, one of the + requirements is to be able to identify the user's home authentication + server. For use in roaming, this function is accomplished via the + Network Access Identifier (NAI) submitted by the user to the NAS in + the initial network authentication. It is also expected that NASes + will use the NAI as part of the process of opening a new tunnel, in + order to determine the tunnel endpoint. + +2. NAI Definition + +2.1. Formal Syntax + + The grammar for the NAI is given below, described in Augmented + Backus-Naur Form (ABNF) as documented in [RFC4234]. The grammar for + the username is based on [RFC0821], and the grammar for the realm is + an updated version of [RFC1035]. + + nai = username + nai =/ "@" realm + nai =/ username "@" realm + + username = dot-string + dot-string = string + dot-string =/ dot-string "." string + string = char + string =/ string char + char = c + char =/ "\" x + + + + +Aboba, et al. Standards Track [Page 4] + +RFC 4282 The Network Access Identifier December 2005 + + + c = %x21 ; '!' allowed + ; '"' not allowed + c =/ %x23 ; '#' allowed + c =/ %x24 ; '$' allowed + c =/ %x25 ; '%' allowed + c =/ %x26 ; '&' allowed + c =/ %x27 ; ''' allowed + ; '(', ')' not allowed + c =/ %x2A ; '*' allowed + c =/ %x2B ; '+' allowed + ; ',' not allowed + c =/ %x2D ; '-' allowed + ; '.' not allowed + c =/ %x2F ; '/' allowed + c =/ %x30-39 ; '0'-'9' allowed + ; ';', ':', '<' not allowed + c =/ %x3D ; '=' allowed + ; '>' not allowed + c =/ %x3F ; '?' allowed + ; '@' not allowed + c =/ %x41-5a ; 'A'-'Z' allowed + ; '[', '\', ']' not allowed + c =/ %x5E ; '^' allowed + c =/ %x5F ; '_' allowed + c =/ %x60 ; '`' allowed + c =/ %x61-7A ; 'a'-'z' allowed + c =/ %x7B ; '{' allowed + c =/ %x7C ; '|' allowed + c =/ %x7D ; '}' allowed + c =/ %x7E ; '~' allowed + ; DEL not allowed + c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486) + ; Where UTF-8-octet is any octet in the + ; multi-octet UTF-8 representation of a + ; unicode codepoint above %x7F. + ; Note that c must also satisfy rules in + ; Section 2.4, including, for instance, + ; checking that no prohibited output is + ; used (see also Section 2.3 of + ; [RFC4013]). + x = %x00-FF ; all 128 ASCII characters, no exception; + ; as well as all UTF-8-octets as defined + ; above (this was not allowed in + ; RFC 2486). Note that x must nevertheless + ; again satisfy the Section 2.4 rules. + + realm = 1*( label "." ) label + label = let-dig *(ldh-str) + + + +Aboba, et al. Standards Track [Page 5] + +RFC 4282 The Network Access Identifier December 2005 + + + ldh-str = *( alpha / digit / "-" ) let-dig + let-dig = alpha / digit + alpha = %x41-5A ; 'A'-'Z' + alpha =/ %x61-7A ; 'a'-'z' + digit = %x30-39 ; '0'-'9' + +2.2. NAI Length Considerations + + Devices handling NAIs MUST support an NAI length of at least 72 + octets. Support for an NAI length of 253 octets is RECOMMENDED. + However, the following implementation issues should be considered: + + o NAIs are often transported in the User-Name attribute of the + Remote Authentication Dial-In User Service (RADIUS) protocol. + Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the + ability to handle at least 63 octets is recommended." As a + result, it may not be possible to transfer NAIs beyond 63 octets + through all devices. In addition, since only a single User-Name + attribute may be included in a RADIUS message and the maximum + attribute length is 253 octets; RADIUS is unable to support NAI + lengths beyond 253 octets. + + o NAIs can also be transported in the User-Name attribute of + Diameter [RFC3588], which supports content lengths up to 2^24 - 9 + octets. As a result, NAIs processed only by Diameter nodes can be + very long. Unfortunately, an NAI transported over Diameter may + eventually be translated to RADIUS, in which case the above + limitations apply. + +2.3. Support for Username Privacy + + Interpretation of the username part of the NAI depends on the realm + in question. Therefore, the "username" part SHOULD be treated as + opaque data when processed by nodes that are not a part of the + authoritative domain (in the sense of Section 4) for that realm. + + In some situations, NAIs are used together with a separate + authentication method that can transfer the username part in a more + secure manner to increase privacy. In this case, NAIs MAY be + provided in an abbreviated form by omitting the username part. + Omitting the username part is RECOMMENDED over using a fixed username + part, such as "anonymous", since it provides an unambiguous way to + determine whether the username is intended to uniquely identify a + single user. + + For roaming purposes, it is typically necessary to locate the + appropriate backend authentication server for the given NAI before + the authentication conversation can proceed. As a result, the realm + + + +Aboba, et al. Standards Track [Page 6] + +RFC 4282 The Network Access Identifier December 2005 + + + portion is typically required in order for the authentication + exchange to be routed to the appropriate server. + +2.4. International Character Sets + + This specification allows both international usernames and realms. + International usernames are based on the use of Unicode characters, + encoded as UTF-8 and processed with a certain algorithm to ensure a + canonical representation. Internationalization of the realm portion + of the NAI is based on "Internationalizing Domain Names in + Applications (IDNA)" [RFC3490]. + + In order to ensure a canonical representation, characters of the + username portion in an NAI MUST fulfill the ABNF in this + specification as well as the requirements specified in [RFC4013]. + These requirements consist of the following: + + o Mapping requirements, as specified in Section 2.1 of [RFC4013]. + Mapping consists of mapping certain characters to others (such as + SPACE) in order to increase the likelihood of correctly performed + comparisons. + + o Normalization requirements, as specified in Section 2.2 of + [RFC4013], are also designed to assist in comparisons. + + o Prohibited output. Certain characters are not permitted in + correctly formed strings that follow Section 2.3 of [RFC4013]. + Ensuring that NAIs conform to their ABNF is not sufficient; it is + also necessary to ensure that they do not contain prohibited + output. + + o Bidirectional characters are handled as specified in Section 2.4 + of [RFC4013]. + + o Unassigned code points are specified in Section 2.5 of [RFC4013]. + The use of unassigned code points is prohibited. + + The mapping, normalization, and bidirectional character processing + MUST be performed by end systems that take international text as + input. In a network access setting, such systems are typically the + client and the Authentication, Authorization, and Accounting (AAA) + server. NAIs are sent over the wire in their canonical form, and + tasks such as normalization do not typically need to be performed by + nodes that just pass NAIs around or receive them from the network. + End systems MUST also perform checking for prohibited output and + unassigned code points. Other systems MAY perform such checks, when + they know that a particular data item is an NAI. + + + + +Aboba, et al. Standards Track [Page 7] + +RFC 4282 The Network Access Identifier December 2005 + + + The realm name is an "IDN-unaware domain name slot" as defined in + [RFC3490]. That is, it can contain only ASCII characters. An + implementation MAY support Internationalized Domain Names (IDNs) + using the ToASCII operation; see [RFC3490] for more information. + + The responsibility for the conversion of internationalized domain + names to ASCII is left for the end systems, such as network access + clients and AAA servers. Similarly, we expect domain name + comparisons, matching, resolution, and AAA routing to be performed on + the ASCII versions of the internationalized domain names. This + provides a canonical representation, ensures that intermediate + systems such as AAA proxies do not need to perform translations, and + can be expected to work through systems that are unaware of + international character sets. + +2.5. Compatibility with E-Mail Usernames + + As proposed in this document, the Network Access Identifier is of the + form user@realm. Please note that while the user portion of the NAI + is based on the BNF described in [RFC0821], it has been extended for + internationalization support as well as for purposes of Section 2.7, + and is not necessarily compatible with the usernames used in e-mail. + Note also that the internationalization requirements for NAIs and + e-mail addresses are different, since the former need to be typed in + only by the user himself and his own operator, not by others. + +2.6. Compatibility with DNS + + The BNF of the realm portion allows the realm to begin with a digit, + which is not permitted by the BNF described in [RFC1035]. This + change was made to reflect current practice; although not permitted + by the BNF described in [RFC1035], Fully Qualified Domain Names + (FQDNs) such as 3com.com are commonly used and accepted by current + software. + +2.7. Realm Construction + + NAIs are used, among other purposes, for routing AAA transactions to + the user's home realm. Usually, the home realm appears in the realm + portion of the NAI, but in some cases a different realm can be used. + This may be useful, for instance, when the home realm is reachable + only via another mediating realm. + + Such usage may prevent interoperability unless the parties involved + have a mutual agreement that the usage is allowed. In particular, + NAIs MUST NOT use a different realm than the home realm unless the + sender has explicit knowledge that (a) the specified other realm is + available and (b) the other realm supports such usage. The sender + + + +Aboba, et al. Standards Track [Page 8] + +RFC 4282 The Network Access Identifier December 2005 + + + may determine the fulfillment of these conditions through a database, + dynamic discovery, or other means not specified here. Note that the + first condition is affected by roaming, as the availability of the + other realm may depend on the user's location or the desired + application. + + The use of the home realm MUST be the default unless otherwise + configured. + + Where these conditions are fulfilled, an NAI such as + + user@homerealm.example.net + + MAY be represented as in + + homerealm.example.net!user@otherrealm.example.net + + In this case, the part before the (non-escaped) '!' MUST be a realm + name as defined in the ABNF in Section 2.1. This realm name is an + "IDN-unaware domain name slot", just like the realm name after the + "@" character; see Section 2.4 for details. When receiving such an + NAI, the other realm MUST convert the format back to + "user@homerealm.example.net" when passing the NAI forward, as well as + applying appropriate AAA routing for the transaction. + + The conversion process may apply also recursively. That is, after + the conversion, the result may still have one or more '!' characters + in the username. For instance, the NAI + + other2.example.net!home.example.net!user@other1.example.net + + would first be converted in other1.example.net to + + home.example.net!user@other2.example.net + + and then at other2.example.net finally to + + user@homerealm.example.net + + Note that the syntax described in this section is optional and is not + a part of the ABNF. The '!' character may appear in the username + portion of an NAI for other purposes as well, and in those cases, the + rules outlined here do not apply; the interpretation of the username + is up to an agreement between the identified user and the realm given + after the '@' character. + + + + + + +Aboba, et al. Standards Track [Page 9] + +RFC 4282 The Network Access Identifier December 2005 + + +2.8. Examples + + Examples of valid Network Access Identifiers include the following: + + bob + joe@example.com + fred@foo-9.example.com + jack@3rd.depts.example.com + fred.smith@example.com + fred_smith@example.com + fred$@example.com + fred=?#$&*+-/^smith@example.com + nancy@eng.example.net + eng.example.net!nancy@example.net + eng%nancy@example.net + @privatecorp.example.net + \(user\)@example.net + alice@xn--tmonesimerkki-bfbb.example.net + + The last example uses an IDN converted into an ASCII representation. + + Examples of invalid Network Access Identifiers include the following: + + fred@example + fred@example_9.com + fred@example.net@example.net + fred.@example.net + eng:nancy@example.net + eng;nancy@example.net + (user)@example.net + @example.net + +3. Security Considerations + + Since an NAI reveals the home affiliation of a user, it may assist an + attacker in further probing the username space. Typically, this + problem is of most concern in protocols that transmit the username in + clear-text across the Internet, such as in RADIUS, described in + [RFC2865] and [RFC2866]. In order to prevent snooping of the + username, protocols may use confidentiality services provided by + protocols transporting them, such as RADIUS protected by IPsec + [RFC3579] or Diameter protected by TLS [RFC3588]. + + This specification adds the possibility of hiding the username part + in the NAI, by omitting it. As discussed in Section 2.3, this is + possible only when NAIs are used together with a separate + authentication method that can transfer the username in a secure + manner. In some cases, application-specific privacy mechanism have + + + +Aboba, et al. Standards Track [Page 10] + +RFC 4282 The Network Access Identifier December 2005 + + + also been used with NAIs. For instance, some Extensible + Authentication Protocol (EAP) methods apply method-specific + pseudonyms in the username part of the NAI [RFC3748]. While neither + of these approaches can protect the realm part, their advantage over + transport protection is that privacy of the username is protected, + even through intermediate nodes such as NASes. + +4. IANA Considerations + + In order to avoid creating any new administrative procedures, + administration of the NAI realm namespace piggybacks on the + administration of the DNS namespace. + + NAI realm names are required to be unique, and the rights to use a + given NAI realm for roaming purposes are obtained coincident with + acquiring the rights to use a particular Fully Qualified Domain Name + (FQDN). Those wishing to use an NAI realm name should first acquire + the rights to use the corresponding FQDN. Using an NAI realm without + ownership of the corresponding FQDN creates the possibility of + conflict and therefore is to be discouraged. + + Note that the use of an FQDN as the realm name does not require use + of the DNS for location of the authentication server. While Diameter + [RFC3588] supports the use of DNS for location of authentication + servers, existing RADIUS implementations typically use proxy + configuration files in order to locate authentication servers within + a domain and perform authentication routing. The implementations + described in [RFC2194] did not use DNS for location of the + authentication server within a domain. Similarly, existing + implementations have not found a need for dynamic routing protocols + or propagation of global routing information. Note also that there + is no requirement that the NAI represent a valid email address. + +5. References + +5.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October + 2005. + + + + + +Aboba, et al. Standards Track [Page 11] + +RFC 4282 The Network Access Identifier December 2005 + + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + +5.2. Informative References + + [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, + RFC 821, August 1982. + + [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, + "Review of Roaming Implementations", RFC 2194, + September 1997. + + [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco + Layer Two Forwarding (Protocol) "L2F"", RFC 2341, + May 1998. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC2486] Aboba, B. and M. Beadles, "The Network Access + Identifier", RFC 2486, January 1999. + + [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., + Little, W., and G. Zorn, "Point-to-Point Tunneling + Protocol", RFC 2637, July 1999. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., + Zorn, G., and B. Palter, "Layer Two Tunneling + Protocol "L2TP"", RFC 2661, August 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service + (RADIUS)", RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June + 2000. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC 3579, + September 2003. + + + + + + +Aboba, et al. Standards Track [Page 12] + +RFC 4282 The Network Access Identifier December 2005 + + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., + and J. Arkko, "Diameter Base Protocol", RFC 3588, + September 2003. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., + and H. Levkowetz, "Extensible Authentication + Protocol (EAP)", RFC 3748, June 2004. + + [netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and + Selection Problem", Work in Progress, October 2005. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 13] + +RFC 4282 The Network Access Identifier December 2005 + + +Appendix A. Changes from RFC 2486 + + This document contains the following updates with respect to the + original NAI definition in RFC 2486 [RFC2486]: + + o International character set support has been added for both + usernames and realms. Note that this implies character codes 128 + - 255 may be used in the username portion, which may be + unacceptable to nodes that only support RFC 2486. Many devices + already allow this behaviour, however. + + o Username privacy support has been added. Note that NAIs without a + username (for privacy) may not be acceptable to RFC 2486-compliant + nodes. Many devices already allow this behaviour, however. + + o A recommendation to support NAI length of at least 253 octets has + been added, and compatibility considerations among NAI lengths in + this specification and various AAA protocols are discussed. Note + that long NAIs may not be acceptable to RFC 2486-compliant nodes. + + o The mediating network syntax and its implications have been fully + described and not given only as an example. Note that this syntax + is not intended to be a full solution to network discovery and + selection needs as defined in [netsel-problem]. Rather, it is + intended as a clarification of RFC 2486. + + However, as discussed in Section 2.7, this specification requires + that this syntax be applied only when there is explicit knowledge + that the peer system supports such syntax. + + o The realm BNF entry definition has been changed to avoid an error + (infinite recursion) in the original specification. + + o Several clarifications and improvements have been incorporated + into the ABNF specification for NAIs. + +Appendix B. Acknowledgements + + Thanks to Glen Zorn for many useful discussions of this problem + space, and to Farid Adrangi for suggesting the representation of + mediating networks in NAIs. Jonathan Rosenberg reported the BNF + error. Dale Worley suggested clarifications of the x and special BNF + entries. Arne Norefors reported the length differences between RFC + 2486 and RFC 2865. Paul Hoffman helped with the international + character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi + Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, + John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam + Hartman, and Richard Perlman provided many useful comments on this + + + +Aboba, et al. Standards Track [Page 14] + +RFC 4282 The Network Access Identifier December 2005 + + + document. The ABNF validator at http://www.apps.ietf.org/abnf.html + was used to verify the syntactic correctness of the ABNF in + Section 2.1. + +Authors' Addresses + + Bernard Aboba + Microsoft + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: bernarda@microsoft.com + + + Mark A. Beadles + ENDFORCE + 565 Metro Place South Suite 300 + Dublin OH 43017 + USA + + EMail: mbeadles@endforce.com + + + Jari Arkko + Ericsson + Jorvas 02420 + Finland + + EMail: jari.arkko@ericsson.com + + + Pasi Eronen + Nokia Research Center + P.O. Box 407 + FIN-00045 Nokia Group + Finland + + EMail: pasi.eronen@nokia.com + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 15] + +RFC 4282 The Network Access Identifier December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Aboba, et al. Standards Track [Page 16] +