+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+ <nancy>@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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / freeradius.git / commitdiff