RFC 3169

Criteria for Evaluating Network Access Server Protocols 🦋

Part 1 of 3 🌈

Okay bestie, here's the header situation 🎀. This is RFC 3169, filed under the Network Working Group in September 2001. It's an Informational doc, which means it shares info with the community and isn't an Internet standard ✨. The authors are M. Beadles from SmartPipes, Inc. and D. Mitton from Nortel Networks 💜. The header doesn't list anything it obsoletes or updates, so it's totally standalone 🌸.

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 (2001). All Rights Reserved.

Abstract ✨

This document defines requirements for protocols used by Network Access Servers (NAS) 🦋.

1. Requirements language 🔥

Okay so the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are read the way [KEYWORDS] describes. Those are the official words that carry the weight in this doc, so watch for them 👀.

2. Introduction 🌸

This document defines requirements for protocols used by Network Access Servers (NAS). Protocols used by NAS's may be divided into four spaces: Access protocols, Network protocols, AAA protocols, and Device Management protocols. The primary focus of this document is on AAA protocols 💖.

The reference model of a NAS used by this document, and the analysis of the functions of a NAS which led to the development of these requirements, may be found in [NAS-MODEL] 🧚.

3. Access Protocol Requirements 🦋

There are three basic types of access protocols used by NAS's, and they're giving variety 🌈. First up are the traditional telephony-based access protocols, which hook up to the NAS through a modem, a terminal adapter, or something similar. These typically support asynchronous or synchronous PPP [PPP] carried over a telephony protocol 📞.

Second are broadband pseudo-telephony access protocols, which ride over xDSL or cable modems, for example. These typically support an encapsulation method such as PPP over Ethernet [PPPOE] ✨. Finally, there are the virtual access protocols used by NAS's that terminate tunnels. One example is L2TP [L2TP] 🫶.

It is a central assumption of the NAS model used here that a NAS accepts multiple point-to-point links via one of the above access protocols. So, at a minimum, any NAS access protocol MUST be able to carry PPP 🔥. The exception is for NAS's that support legacy text login methods such as telnet [TELNET], rlogin, or LAT. Only these access protocols are exempt from the requirement to support PPP 💀.

4. Network Protocol Requirements 🌸

The network protocols supported by a NAS depend entirely on the kind of network the NAS is giving access to 🌐. This document doesn't put any extra requirements on network protocols beyond the protocol specifications themselves. For example, if a NAS that serves a routed network includes internet routing functionality, then that NAS must adhere to [ROUTING-REQUIREMENTS]. But being a NAS doesn't add any extra protocol requirements on its own 💅.

5. AAA Protocol Requirements ✨

5.1. General protocol characteristics 💜

There are certain general characteristics that any AAA protocol used by NAS's has to meet 🎀. Heads up: the transport requirements for authentication/authorization aren't necessarily the same as the ones for accounting/auditing. An AAA protocol suite MAY use the same transport and protocol for both functions, but this is not strictly required 🦋.

5.1.1. Transport requirements 🌈

5.1.1.1. Transport independence 🔥

The design of the AAA protocol MUST be transport independent. Existing infrastructures use UDP-based protocols [RADIUS], and gateways to new protocols must be practical to encourage migration 🧚. The design MUST comply with congestion control recommendations in RFC 2914 [CONGEST] 💖.

5.1.1.2. Scalability 🌸

Very large scale NAS's that serve up to thousands of simultaneous sessions are now being deployed 📈. And a single server system may service a large number of ports. This means that, in the extreme, there may be an almost constant exchange of many small packets between the NASes and the AAA server 😭. An AAA protocol transport SHOULD support being optimized for a long-term exchange of small packets in a stream between a pair of hosts ✨.

The protocol MUST be designed to support a large number of ports, clients, and concurrent sessions. Examples of poor design would include:

• message identifiers whose values are so small that queues and reception windows wrap under load
• unique session identifier ranges that are so small that they wrap within the lifetime of potential long sessions
• counter values that cannot accommodate reasonable current and future bandwidth usage
• computational processes with high overhead that must be performed frequently

Those are all the no-go vibes 🙈.

5.1.1.3. Support for Multiple AAA Servers and Failure Recovery 🦋

In order to operationally support large loads, load balancing and fail-over to multiple AAA servers will be required 👑. The AAA protocol MUST provide for NAS's to balance individual AAA requests between two or more AAA servers. The load balancing mechanism SHOULD be built in to the AAA protocol itself 🫶.

The AAA protocol MUST be able to detect a failure of the transport protocol to deliver a message or messages within a known and controllable time period. That way it can kick off retransmission or server fail-over processes ⏱️. The reliability and robustness of authentication requests MUST be predictable and configurable 💜.

The AAA protocol design MUST NOT introduce a single point of failure during the AAA process 🚨. The AAA protocol MUST allow any sessions between a NAS and a given AAA server to fail-over to a secondary server without loss of state information. This fail-over mechanism SHOULD be built in to the AAA protocol itself 🌈.

5.1.1.4. Support for Multiple Administrative Domains 🌐

NAS's operated by one authority provide network access services for clients operated by another authority, to network destinations operated by yet another authority. This type of arrangement is becoming super important. For example, dial roaming is now a nearly ubiquitous service 📱. Therefore, the AAA protocol MUST support AAA services that travel between multiple domains of authority. The AAA protocol MUST NOT use a model that assumes a single domain of authority 🙅‍♀️.

The AAA protocol MUST NOT dictate particular business models for the relationship between the administrative domains. The AAA protocol MUST support proxy, and in addition SHOULD support other multi-domain relationships such as brokering and referral 🤝.

The AAA protocol MUST also meet the protocol requirements specified in [ROAMING-REQUIREMENTS] 🧚‍♀️.

5.1.2. Attribute-Value Protocol Model 💅

Years of operational experience with AAA protocols and NAS's has proven that the Attribute-Value protocol model is an optimal representation of AAA data 👑. The protocol SHOULD use an Attribute-Value representation for AAA data. This document will assume such a model. Even if the AAA protocol doesn't use this as an on-the-wire data representation, Attribute-Value can still serve as an abstraction for talking about AAA information 💖.

Experience has also shown that attribute space tends to run out quickly 😩. To leave room for expansion in the attribute space, the AAA protocol MUST support a minimum of 64K Attributes (16 bits), each with a minimum length of 64K (16 bits) ✨.

5.1.2.1. Attribute Data Types 🎀

The AAA protocol MUST support simple attribute data types, including integer, enumeration, text string, IP address, and date/time. The AAA protocol MUST also provide some support for complex structured data types 🧩. Wherever IP addresses are carried within the AAA protocol, the protocol MUST support both IPv4 and IPv6 [IPV6] addresses. Wherever text information is carried within the AAA protocol, the protocol MUST comply with the IETF Policy on Character Sets and Languages [RFC 2277] 🌍.

5.1.2.2. Minimum Set of Attributes 🦋

At a minimum, the AAA protocol MUST support, or be easily extended to support, the set of attributes supported by RADIUS [RADIUS] and RADIUS Accounting [RADIUS-ACCOUNTING]. If the base AAA protocol doesn't support this complete set of attributes, then an extension to that protocol MUST be defined which supports this set 🔥.

5.1.2.3. Attribute Extensibility 🌈

NAS and AAA development is always progressing 🚀. To keep the AAA protocol from being a bottleneck for NAS and AAA Server development, the AAA protocol MUST provide a built-in extensibility mechanism. That mechanism MUST include a means for adding new standard attribute extensions. It MUST also include a method for registering or requesting extensions through IANA, so that long-term working group involvement isn't required to create new attribute types 📋. Ideally, the AAA protocol SHOULD separate specification of the transport from specification of the attributes 🫶.

The AAA protocol MUST include a means for individual vendors to add value through vendor-specific attributes, and it SHOULD include support for vendor-specific data types 🏷️.

5.1.3. Security Requirements 🔐

5.1.3.1. Mutual Authentication 🛡️

It is poor security practice for a NAS to communicate with an AAA server that is not trusted, and vice versa. The AAA protocol MUST provide mutual authentication between AAA server and NAS 😤.

5.1.3.2. Shared Secrets 🤫

At a minimum, the AAA protocol SHOULD support use of a secret shared pairwise between each NAS and AAA server to mutually verify identity. This is intended for small-scale deployments. The protocol MAY provide stronger mutual security techniques 🔑.

5.1.3.3. Public Key Security 🗝️

AAA server/NAS identity verification based solely on shared secrets can be difficult to deploy properly at large scale. It can also be tempting for NAS operators to use a single shared secret (that rarely changes) across all NAS's. That can lead to an easy compromise of the secret 🚨. Therefore, the AAA protocol MUST also support mutual verification of identity using a public-key infrastructure that supports expiration and revocation of keys 🔒.

5.1.3.4. Encryption of Attributes 🙈

Some attributes are more operationally sensitive than others. Also, in a multi-domain scenario, attributes may be inserted by servers from different administrative domains. Therefore, the AAA protocol MUST support selective encryption of attributes on an attribute-by-attribute basis, even within the same message. This requirement applies equally to Authentication, Authorization, and Accounting data 🔐.

5.2. Authentication and User Security Requirements 👑

5.2.1. Authentication protocol requirements 🎀

End users who are requesting network access through a NAS will present various types of credentials. The purpose of the AAA protocol is to transport these credentials between the NAS and the AAA server 🧚.

5.2.1.1. Bi-directional Authentication 🦋

The AAA protocol MUST support transport of credentials from the AAA server to the NAS, between the User and the NAS, and between the NAS and the AAA server ↔️.

5.2.1.2. Periodic Re-Authentication 🌸

The AAA protocol MUST support re-authentication at any time during the course of a session, initiated from either the NAS or the AAA server. This is a requirement of CHAP [CHAP] 💖.

5.2.1.3. Multi-phase Authentication 🌀

okay so the AAA protocol MUST be able to handle multi-phase authentication methods, and that's not just one or two tricks, it's a whole vibe 💅 at minimum it needs to do all of this:

• Text prompting from the NAS to the user 💬
• A series of binary challenges and responses of arbitrary length 🔢
• An authentication failure reason sent from the NAS to the user ❌
• Callback to a pre-determined phone number 📞

5.2.1.4. Extensible Authentication Types 🔮

the security world is literally always changing 😭 new threats show up, people find better ways to crack things, and the method that feels bulletproof today could be cooked tomorrow. so the AAA protocol MUST provide some support for adding new authentication credential types. future-proofing is everything, bestie ✨

5.2.2. Authentication Attribute Requirements 🎀

in addition to the minimum attribute set, the AAA protocol must support and define attributes that provide the following functions:

5.2.2.1. PPP Authentication protocols 🦋

a lot of authentication protocols live inside the PPP framework, so the AAA protocol MUST be able to act as an intermediary between the authenticate and the authenticator for these:

• PPP Password Authentication Protocol [PPP]
• PPP Challenge Handshake Authentication Protocol [CHAP]
• PPP Extensible Authentication Protocol [EAP]

5.2.2.2. User Identification 🪪

these are the common kinds of credentials people use to identify themselves. the AAA protocol MUST be able to carry the following types of identity credentials:

• A user name in the form of a Network Access Identifier [NAI] 🧑‍💻
• An Extensible Authentication Protocol [EAP] Identity Request Type packet 📦
• Telephony dialing information such as Dialed Number Identification Service (DNIS) and Caller ID ☎️

here's the important part: if a particular type of authentication credential isn't needed for a user session, the AAA protocol MUST NOT require that dummy credentials get filled in. no fake passwords, no nonsense 🙅‍♀️ it MUST support authorization by identification or assertion only. main character energy for real 👑

5.2.2.3. Authentication Credentials 🔐

these are the common credential types used for authentication. at a minimum, the AAA protocol MUST be able to carry these:

• A secret or password 🤫
• A response to a challenge presented by the NAS to the user 🧩
• A one-time password ⏳
• An X.509 digital certificate [X.509] 📜
• A Kerberos v5 ticket [KERBEROS] 🎟️

5.2.3. Authentication Protocol Security Requirements 🛡️

5.2.3.1. End-to-End Hiding of Credentials 🙈

if passwords are being used as credentials, the AAA protocol MUST provide a secure way to hide the password from intermediates in the AAA conversation. the middlemen should never see it, full stop 😤 and where challenge/response mechanisms are used, the AAA protocol MUST also prevent replay attacks. nobody gets to just copy and reuse an old answer 🚫

---

5.3. Authorization, Policy, and Resource management 👑

5.3.1. Authorization Protocol Requirements 📋

in every case, the protocol MUST specify that authorization data sent from the NAS to the AAA server is treated as information or "hints," not as directives. it's just a suggestion, not a command 💁‍♀️ the AAA protocol MUST be designed so the AAA server makes all final authorization decisions, and it MUST NOT depend on a certain state being expected by the NAS. the server is the boss here 💅

5.3.1.1. Dynamic Authorization ⚡

the AAA protocol MUST support dynamic re-authorization at any time during a user session 🔄 this re-authorization may be started from either direction. and this dynamic re-authorization capability MUST include the ability to ask a NAS to disconnect a user on demand. instant kick, no questions asked 🚪

5.3.1.2. Resource Management 🧃

Resource Management MUST be available on demand from the NAS or AAA Server at any time during a user session 🙌 this is the ability for the NAS to allocate and deallocate shared resources from an AAA server that's serving multiple NASes. the resources can include, but aren't limited to, IP addresses, concurrent usage limits, port usage limits, and tunnel limits. this capability should have error detection and synchronization features that can recover state after network and system failures. that can be done with session information timeouts and explicit interim status and disconnect messages. and there should not be any dependencies on the Accounting message stream, as per current practices 🫶

this feature is mainly meant for NAS-local network resources. in a proxy or multi-domain environment, resource information should only be kept by the server doing the allocation, plus maybe its backups 🗂️ authorization resources in remote domains should use the dynamic authorization features to change and revoke authorization status. no reaching across domains to mess with each other's stuff 🚧

5.3.2. Authorization Attribute Requirements 🧾

5.3.2.1. Authorization Attribute Requirements - Access Restrictions 🚦

the AAA protocol is the main way to gather the data used to make policy decisions for network access. so the AAA protocol MUST allow network operators to make policy decisions based on these parameters:

• Time/day restrictions. The AAA protocol MUST be able to provide an unambiguous time stamp, NAS time zone indication, and date indication to the AAA server in the Authorization information ⏰
• Location restrictions. The AAA protocol MUST be able to provide an unambiguous location code that reflects the geographic location of the NAS 📍 note that this is NOT the same kind of thing as the dialing or dialed station, so don't mix them up 🙃
• Dialing restrictions. The AAA protocol MUST be able to provide accurate dialed and dialing station indications 📲
• Concurrent login limitations. The AAA protocol MUST allow an AAA Server to limit concurrent logins by a particular user or group of users 👯 this mechanism doesn't have to be built directly into the AAA protocol, but the AAA protocol must provide enough authorization information for an AAA server to make that call through an out-of-band mechanism.

5.3.2.2. Authorization Attribute Requirements - Authorization Profiles 🎨

the AAA protocol is used to enforce policy at the NAS. basically, once access is granted, a particular access profile gets applied to the user's session ✨ the AAA protocol MUST, at a minimum, provide a means of applying profiles containing these types of information:

• IP Address assignment. The AAA protocol MUST provide a means of assigning an IPv4 or IPv6 address to an incoming user 🌐
• Protocol Filter application. The AAA protocol MUST provide a means of applying IP protocol filters to user sessions 🧱 two different methods MUST be supported:
  • First, the AAA protocol MUST provide a means of selecting a protocol filter by reference to an identifier, with the details of the filter action specified out of band. The AAA protocol SHOULD define this out-of-band reference mechanism 🔖
  • Second, the AAA protocol MUST provide a means of passing a protocol filter by value. This means explicitly passing pass/block information by address range, TCP/UDP port number, and IP protocol number, at a minimum 🛂
• Compulsory Tunneling. The AAA protocol MUST provide a means of directing a NAS to build a tunnel or tunnels to a specified end-point 🚇 it MUST support creating multiple simultaneous tunnels in a specified order. At a minimum, the protocol MUST allow specifying the tunnel endpoints, tunneling protocol type, underlying tunnel media type, and tunnel authentication credentials (if the tunnel type requires them). The AAA protocol MUST support at least creating tunnels using the L2TP [L2TP], ESP [ESP], and AH [AH] protocols. The protocol MUST provide a means of adding new tunnel types as they get standardized 🧳
• Routing. The AAA protocol MUST provide a means of assigning a particular static route to an incoming user session 🛣️
• Expirations/timeouts. The AAA protocol MUST provide a means of communicating session expiration information to a NAS ⌛ the expirations that MUST be supported are: total session time, idle time, total bytes transmitted, and total bytes received.
• Quality of Service. The AAA protocol MUST provide a means of supplying Quality of Service parameters to the NAS for individual user sessions 🎀

5.3.2.3. Resource Management Requirements 📊

the AAA protocol is how network operators manage network resources 🛠️ so the AAA protocol MUST provide a means of collecting resource state information and controlling resource allocation for these types of network resources:

• Network bandwidth usage per session, including multilink sessions 📶
• Access port usage, including concurrent usage and usage pools 🔌
• Connect time ⏱️
• IP Addresses and pools 🏘️
• Compulsory tunnel limits 🚧

5.3.3. Authorization Protocol Security Requirements 🔒

5.3.3.1. Security of Compulsory Tunnel Credentials 🗝️

when an AAA protocol passes credentials that will be used to authenticate compulsory tunnels, the AAA protocol MUST provide a means of securing those credentials from end-to-end across the AAA conversation 🫣 the AAA protocol MUST also protect against replay attacks in this situation. no sneaky reuse, ever 💀

---

5.4. Accounting and Auditing Requirements 🧮

5.4.1. Accounting Protocol Requirements 📒

5.4.1.1. Guaranteed Delivery 📬

the accounting and auditing functions of the AAA protocol are used for network planning, resource management, policy decisions, and other stuff that needs accurate knowledge of the NAS state 🧠 NAS operators need to be able to engineer their network usage measurement systems to a predictable level of accuracy. so an AAA protocol MUST provide a means of guaranteed delivery of accounting information between the NAS and the AAA Server(s). no lost receipts 🧾✅

5.4.1.2. Real Time Accounting ⏩

NAS operators often want a real-time view of the sessions their NAS is serving 👀 so the AAA protocol MUST support real-time delivery of accounting and auditing information. in this context, real time means accounting information delivery begins within one second of the triggering event ⚡

5.4.1.3. Batch Accounting 📦

the AAA protocol SHOULD also support delivery of stored accounting and auditing information in batches (non-real time) 🗃️

5.4.1.4. Accounting Time Stamps 🕰️

there can be delays when accounting information gets delivered 🐌 the NAS operator will want to know when an event actually happened, not just when the notification of that event showed up. so the AAA protocol MUST carry an unambiguous time stamp with each accounting event, and this time stamp MUST be unambiguous with regard to time zone 🌍 note that this assumes the NAS has access to a reliable time source. timestamps are everything, periodt 💜

5.4.1.5. Accounting Events ✨

Okay so, at a bare minimum, the AAA protocol MUST be able to deliver accounting info for these moments 💅:

• Start of a user session 🎬
• End of a user session 🏁
• Expiration of a predetermined repeating time interval during a user session ⏰. The AAA protocol MUST provide a means for the AAA server to request that a NAS use a certain interval accounting time.
• Dynamic re-authorization during a user session (e.g., new resources being delivered to the user) 🎁
• Dynamic re-authentication during a user session 🔐

5.4.1.6. On-Demand Accounting 🙈

NAS operators need to keep an accurate view of the sessions a NAS is serving, even if an AAA server goes down 😭. That's why the AAA protocol MUST support a way to ask the NAS for current session state and accounting on demand. Main character energy for the operators, honestly 👑.

5.4.2. Accounting Attribute Requirements 📊

At a minimum, the AAA protocol MUST support delivery of the following accounting/auditing data:

• All parameters used to authenticate a session.
• Details of the authorization profile that was applied to the session.
• The duration of the session.
• The cumulative number of bytes sent by the user during the session.
• The cumulative number of bytes received by the user during the session.
• The cumulative number of packets sent by the user during the session.
• The cumulative number of packets received by the user during the session.
• Details of the access protocol used during the session (port type, connect speeds, etc.)

5.4.3. Accounting Protocol Security Requirements 🔒

5.4.3.1. Integrity and Confidentiality 🫶

Heads up, accounting and auditing data is operationally sensitive info, so it's giving serious. The AAA protocol MUST provide a means to assure end-to-end integrity of this data. The AAA protocol SHOULD provide a means of assuring the end-to-end confidentiality of this data. Protect it like it's your diary 📔.

5.4.3.2. Auditibility 🧐

Network operators use accounting data for network planning, resource management, and other business-critical stuff that needs real confidence in the data being correct 💼. The AAA protocol SHOULD provide a mechanism to ensure that the source of accounting data cannot easily repudiate this data after transmission. No "that wasn't me" energy allowed 🙅‍♀️.

6. Device Management Protocols 🛠️

This document does not specify any requirements for device management protocols. Not our department, bestie 💅.

7. Acknowledgments 💜

Lots of the requirements in this document first took shape in Glen Zorn's "Yet Another Authentication Protocol (YAAP)" document, and we're so grateful for it 🙌✨.

8. Security Considerations 🚨

See above for security requirements for the NAS AAA protocol. Seriously, go back and reread those, they matter 😭🔥.

Okay this part is important. Where an AAA architecture spans multiple domains of authority, AAA information may need to cross trust boundaries 🚧. In this situation, a NAS might operate as a shared device that services multiple administrative domains. Network operators are advised take this into consideration when deploying NAS's and AAA Servers. Think about the trust boundaries before you deploy anything, periodt 💀🫠.

9. IANA Considerations 📝

This document does not directly specify any IANA considerations. However, the following recommendations are made:

Future development and extension of an AAA protocol will be made way easier if new attributes and values can be requested or registered directly through IANA, rather than through an IETF Standardization process 🧚.

The AAA protocol might use enumerated values for some attributes, which enumerate already-defined IANA types (such as protocol number). In these cases, the AAA protocol SHOULD use the IANA assigned numbers as the enumerated values 🔢.

10. References 📚

[AH]                    Kent, S. and R. Atkinson, "IP Authentication
                        Header (AH)", RFC 2402, November 1998.

[CHAP]                  Simpson, J.,  "PPP Challenge Handshake
                        Authentication Protocol (CHAP)", RFC 1994,
                        August 1996.

[CONGEST]               Floyd, S., "Congestion Control Principles",
                        RFC 2914, Sept. 2000.

[EAP]                   Blunk, L. and J. Vollbrecht, "PPP Extensible
                        Authentication Protocol (EAP)", RFC 2284,
                        March 1998.

[ESP]                   Kent, S. and R. Atkinson, "IP Encapsulating
                        Security Payload (ESP)", RFC 2406, November
                        1998.

[KEYWORDS]              Bradner, S., "Key words for use in RFCs to
                        Indicate Requirement Levels", BCP 14, RFC
                        2119, March 1997.

[KERBEROS]              Kohl, J. and C. Neuman, "The Kerberos Network
                        Authentication Service (V5)", RFC 1510,
                        September 1993.

[IPV6]                  Deering, S. and R. Hinden, "Internet
                        Protocol, Version 6 (IPv6) Specification",
                        RFC 2460, December 1998.

[L2TP]                  Townsley, W., Valencia, A., Rubens, A., Pall,
                        G., Zorn, G. and B. Plater, "Layer Two
                        Tunneling Protocol (L2TP)", RFC 2661, August
                        1999.

[NAI]                   Aboba, B. and M. Beadles, "The Network Access
                        Identifier", RFC 2486, January 1999.

[NAS-MODEL]             Mitton, D. and M. Beadles, "Network Access
                        Server Requirements Next Generation
                        (NASREQNG) NAS Model", RFC 2881, July 2000.

[NAS-EXT]               Mitton, D., "Network Access Servers
                        Requirements: Extended RADIUS Practices", RFC
                        2882, July 2000.

[PPP]                   Simpson, W., "The Point-to-Point Protocol
                        (PPP)", STD 51, RFC 1661, July 1994.

[PPPOE]                 Mamakos, L., Lidl, K., Evarts, J., Carrel,
                        D., Simone, D. and R. Wheeler, "A Method for
                        Transmitting PPP Over Ethernet (PPPoE)", RFC
                        2516, February 1999.

[ROUTING-REQUIREMENTS]  Baker, F., "Requirements for IP Version 4
                        Routers", RFC 1812, June 1995.

[TELNET]                Postel, J. and J. Reynolds, "Telnet Protocol
                        Specification", STD 8, RFC 854, May 1983.

[RFC 2277]              Alvestrand, H., "IETF Policy on Character
                        Sets and Languages", BCP 18, RFC 2277,
                        January 1998.

[X.509]                 ITU-T Recommendation X.509 (1997 E):
                        Information Technology - Open Systems
                        Interconnection - The Directory:
                        Authentication Framework, June 1997.

[RADIUS]                Rigney, C., Rubens. A., Simpson, W. and S.
                        Willens, "Remote Authentication Dial In User
                        Service (RADIUS)", RFC 2138, April 1997.

[RADIUS-ACCOUNTING]     Rigney, C., "RADIUS Accounting", RFC 2139,
                        April 1997.

[ROAMING-REQUIREMENTS]  Aboba, B. and G. Zorn, "Criteria for
                        Evaluating Roaming Protocols", RFC 2477,
                        January 1999.

11. Authors' Addresses 🖋️

Mark Anthony Beadles
SmartPipes, Inc.
565 Metro Place South Suite 300
Dublin, OH 43017

Phone: 614-923-6200


David Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821

Phone: 978-288-4570
EMail: dmitton@nortelnetworks.com

12. Full Copyright Statement ⚖️

The legal stuff stays word-for-word, no edits, bestie 🫶:

Copyright (C) The Internet Society (2001).  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. Thank you, Internet Society 🦋✨.