NASREQ Working Group M. Beadles
INTERNET-DRAFT UUNET, an MCI WorldCom Company
Category: Informational
<draft-ietf-nasreq-criteria-03.txt>
11 October 1999
Criteria for Evaluating Network Access Server Protocols
1.. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference mate-
rial or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this draft is unlimited. It is filed as
<draft-ietf-nasreq-criteria-03.txt> and expires April 11, 2000. Please
send comments to the author.
2. Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
3. Abstract
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
Management protocols. Primary attention is given to setting require-
ments for AAA protocols, since that space is currently the least well
defined.
Beadles Category: Informational [Page 1]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
4. 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 [KEYWORDS].
5. 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 develop-
ment of these requirements, may be found in [NAS-MODEL].
6. Access Protocol Requirements
There are three basic types of access protocols used by NAS's. First
are the telephony-based access protocols, which interface to the NAS
via a modem or terminal adapter or similar device. These protocols
typically support asynchronous or synchronous PPP [PPP] carried over a
telephony network. Included by extension are cellular telephony
access protocols. Second are broadband pseudo-telephony access proto-
cols, which are carried over xDSL or cable modems, for example. These
protocols typically support an encapsulation method such as PPP over
Ethernet [PPPOE]. Finally are the virtual access protocols used by
NAS's that terminate tunnels. One example of this type of protocol 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 pro-
tocols. Therefore, at a minimum, any NAS access protocol MUST be able
to carry PPP. The exception to this requirement 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.
7. Network Protocol Requirements
The network protocols supported by a NAS depend entirely on the kind
of network to which a NAS is providing access. This document does not
impose any additional 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 there are no additional
protocol requirements imposed by virtue of the device being a NAS.
Beadles Category: Informational [Page 2]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
8. AAA Protocol Requirements
8.1. General protocol characteristics
There are certain general characteristics that any AAA protocol used
by NAS's must meet. Note that the transport requirements for authen-
tication/authorization are not necessarily the same as those for
accounting/auditing. An AAA protocol suite MAY use the same transport
and protocol for both functions, but this is not strictly required.
8.1.1. RADIUS Compatibility
It is operationally very important to support the many thousands of
devices making up the Internet today, which speak RADIUS. Therefore,
devices which implement the AAA protocol SHOULD support some means of
compatibility with devices that implement RADIUS. This requirement
MAY be met by simply listening on the same port as RADIUS; note that
in this case the AAA and RADIUS protocols might be quite different.
Alternatively, the requirement MAY be met by creating a gateway
between RADIUS and the AAA protocol. Other alternatives are possible;
the intent is to ensure the continued operation of the currently-
deployed RADIUS infrastructure during deployment of the AAA protocol.
8.1.2. Transport requirements
8.1.2.1. Fast Fail-over
The transport for the AAA protocol MUST support fast (within a matter
of milliseconds) fail-over for authentication and authorization
requests.
8.1.2.2. Reliable Accounting
The transport for the accounting data in the AAA protocol MUST be
reliable.
Beadles Category: Informational [Page 3]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
8.1.2.3. Long-term exchange of small packets
Very large scale NAS's that serve up to thousands of simultaneous ses-
sions are now being deployed. This means that, in the extreme, there
may be an almost constant exchange of many small packets between the
NAS 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.
8.1.2.4. Support for multiple AAA servers
In order to operationally support large loads, load balancing to mul-
tiple AAA servers will be required. The AAA protocol MUST provide for
NAS's to balance AAA sessions between two or more AAA servers. The
load balancing mechanism SHOULD be built in to the AAA protocol
itself. The AAA protocol design MUST NOT introduce a single point of
failure during the AAA process. The AAA protocol MUST allow any ses-
sions 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.
8.1.2.5. Flow control
In order to support the previous two requirements, the AAA protocol
MUST provide a flow control mechanism to avoid flooding a busy server.
8.1.2.6. Support for Multiple Administrative Domains
NAS's operated by one authority provide network access services for
clients operated by another authority, to network destinations oper-
ated by yet another authority. This type of arrangement is of growing
importance; for example, dial roaming is now a nearly ubiquitous ser-
vice. 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 relation-
ship between the administrative domains. The AAA protocol MUST sup-
port proxy, and in addition SHOULD support other multi-domain rela-
tionships such as brokering and referral.
The AAA protocol MUST also meet the protocol requirements specified in
[ROAMING-REQUIREMENTS].
Beadles Category: Informational [Page 4]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
8.1.3. 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 represen-
tation of AAA data. The protocol SHOULD use an Attribute-Value repre-
sentation for AAA data. This document will assume such a model. Even
if the AAA protocol does not use this as an on-the-wire data represen-
tation, Attribute-Value can serve as abstraction for discussing AAA
information.
Experience has also shown that attribute space tends to run out
quickly. In order to provide room for expansion in the attribute
space, the AAA protocol MUST support a minimum of 64K Attributes (MIN-
IMUM 16 bits), each with a minimum length of 64K (MINIMUM 16 bits).
8.1.3.1. Attribute Data Types
The AAA protocol MUST support simple attribute data types, including
integer, enumeration, text string, raw octet series, 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 proto-
col, the protocol MUST comply with the IETF Policy on Character Sets
and Languages [RFC 2277].
8.1.3.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 does not
support this complete set of attributes, then an extension to that
protocol MUST be defined which supports this set.
8.1.3.3. Attribute Extensibility
NAS and AAA development is always progressing. In order to prevent
the AAA protocol from being a limiting factor in NAS and AAA Server
development, the AAA protocol MUST provide a built-in extensibility
mechanism, which MUST include a means for adding new standard
attribute extensions. This MUST include a method for registering or
requesting extensions through IANA, so that long-term working group
involvement is not required to create new attribute types. Ideally,
the AAA protocol SHOULD separate specification of the transport from
specificatoin of the attributes.
The AAA protocol MUST include a means for individual vendors to add
Beadles Category: Informational [Page 5]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
value through vendor-specific attributes and SHOULD include support
for vendor-specific data types and vendor-specific commands.
8.1.4. Security Requirements
8.1.4.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. If a net-
work operator has deployed IP Security [IPSEC], the AAA protocol
SHOULD allow its use.
8.1.4.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.
8.1.4.3. Public Key Security
AAA server/NAS identity verification based solely on shared secrets
can be difficult to deploy properly at large scale, and it can be
tempting for NAS operators to use a single shared secret (that rarely
changes) across all NAS's. This can lead to easy compromise of the
secret. Therefore, the AAA protocol MUST also support mutual verifi-
cation of identity using a public-key infrastructure that supports
expiration and revocation of keys.
8.1.4.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.
8.2. Authentication and User Security Requirements
Beadles Category: Informational [Page 6]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
8.2.1. Authentication protocol requirements
End users who are requesting network access through a NAS will present
various types of credentials. It is the purpose of the AAA protocol
to transport these credentials between the NAS and the AAA server.
8.2.1.1. Bi-directional Authentication
The AAA protocol MUST support transport of credentials from the AAA
server to the NAS for the purpose of mutual (bi-directional) authenti-
cation between the User and the NAS, and between the NAS and the AAA
server.
8.2.1.2. Dynamic Authentication
The AAA protocol MUST support re-authentication at any time during the
course of a session, initiated from either end of the user session.
8.2.1.3. Multi-phase Authentication
The AAA protocol MUST be able to support multi-phase authentication
methods, including but not limited to support for:
-Text prompting from the NAS to the user
-A series of binary challenges and responses of arbitrary length
-An authentication failure reason to be transmitted from the NAS
to the user
-Callback to a pre-determined phone number
8.2.1.4. Extensible Authentication Types
Security protocol development is going on constantly as new threats
are identified and better cracking methods are developed. Today's
secure authentication methods may be proven insecure tomorrow. The
AAA protocol MUST provide some support for addition of new authentica-
tion credential types. EAP SHOULD be the supported mechanism.
8.2.2. Authentication Attribute Requirements
In addition to the minimum attribute set, the AAA protocol must sup-
port and define attributes that provide the following functions:
Beadles Category: Informational [Page 7]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
8.2.2.1. PPP Authentication protocols
Many authentication protocols are defined within the framework of PPP.
The AAA protocol MUST be able to act as an intermediary protocol
between the authenticatee and the authenticator for the following
authentication protocols:
-PPP Password Authentication Protocol [PPP]
-PPP Challenge Handshake Authentication Protocol [CHAP]
-PPP Extensible Authentication Protocol [EAP]
8.2.2.2. User Identitification
The following are common types of credentials used for user identifi-
cation. 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 Identifica-
tion Service (DNIS) and Caller ID.
If a particular type of identity credential is not needed for a par-
ticular user session, the AAA protocol MUST NOT require that dummy
credentials be filled in. That is, the AAA protocol MUST support
identification without authentication (and vice versa).
8.2.2.3. Authentication Credentials
The following are common types of credentials used for authentication.
The AAA protocol MUST be able to carry the following types of authen-
ticating credentials at a minimum:
-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]
Beadles Category: Informational [Page 8]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
8.2.3. Authentication Protocol Security Requirements
8.2.3.1. End-to-End Hiding of Credentials
Where passwords are used as authentication credentials, the AAA proto-
col MUST provide a secure means of hiding the password from end to end
of the AAA conversation, or directly perform end-to-end authentica-
tion. Where challenge/response mechanisms are used, the AAA protocol
MUST also prevent against replay attacks.
8.3. Authorization, Policy, and Resource management
8.3.1. Authorization Protocol Requirements
In all cases, the protocol MUST specify that authorization data sent
from the NAS to the AAA server is to be regarded as information or
"hints", and not directives. The AAA protocol MUST be designed so
that the AAA server makes all final authorization decisions and does
not depend on a certain state being expected by the NAS.
8.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 initiated in
either direction. This dynamic re-authorization capability MUST
include the capability to request a NAS to disconnect a user on
demand.
8.3.1.2. Resource Management
Resource management MUST be supported on demand by the NAS or AAA
Server at any time during the course of a user session.
8.3.2. Authorization Attribute Requirements
8.3.2.1. Authorization Attribute Requirements - Access Restrictions
The AAA protocol serves as a primary means of gathering data used for
making Policy decisions for network access. Therefore, the AAA
Beadles Category: Informational [Page 9]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
protocol MUST allow network operators to make policy decisions based
on the following 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 loca-
tion of the NAS (not the user). Note that this is not the same
type of thing as either the dialing or dialed station.
-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 does not need to be explicitly
built into the AAA protocol, but the AAA protocol must provide
sufficient authorization information for an AAA server to make
that determination through an out-of-band mechanism.
8.3.2.2. Authorization Attribute Requirements - Authorization Pro-
files
The AAA protocol is used to enforce policy at the NAS. Essentially,
on granting of access, a particular access profile is applied to the
user's session. The AAA protocol MUST at a minimum provide a means of
applying profiles containing the following 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 dif-
ferent methods MUST be supported.
First, the AAA protocol MUST provide a means of selecting a pro-
tocol filter by reference to an identifier, with the details of
the filter action being specified out of band. The AAA protocol
MAY define this out-of-band reference mechanism.
Second, the AAA protocol MUST provide a means of passing a proto-
col filter by value. This means explicit passing of pass/block
information by address range, TCP/UDP port number, and IP proto-
col 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 creation of multiple simultaneous tunnels
in a specified order. The protocol MUST allow, at a minimum,
specification of the tunnel endpoints, tunneling protocol type,
Beadles Category: Informational [Page 10]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
underlying tunnel media type, and tunnel authentication creden-
tials (if required by the tunnel type). The AAA protocol MUST
support at least the creation of tunnels using the L2TP [L2TP],
ESP [ESP], and AH [AH] protocols. The protocol MUST provide
means of adding new tunnel types as they are 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
communication session expiration information to a NAS. Types of
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
applying Quality of Service parameters to individual user ses-
sions.
8.3.2.3. Resource Management Requirements
The AAA protocol is one means for network operators to perform manage-
ment of network resources consumed by users. However, it has been
difficult to perform resource management on NAS's with existing SNMP
implementations, which are often used for this purpose. The AAA pro-
tocol MUST support transmission of large amounts of data in order to
support resource management on large-scale NAS's providing complex
user services. The AAA protocol MUST provide a means of collecting
resource state information, and controlling resource allocation for
the following types of network resources.
-Network bandwidth usage per user session, including multilink
sessions.
-Access port usage by users, including concurrent usage and usage
pools.
-Connect time for individual users.
-IP Addresses and pool utilization by users.
-Compulsory tunnel limits for users.
8.3.3. Authorization Protocol Security Requirements
8.3.3.1. Security of Compulsory Tunnel Credentials
When an AAA protocol passes a set of credentials that will be used to
Beadles Category: Informational [Page 11]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
authenticate compulsory tunnels, the AAA protocol MUST provide a means
of securing these credentials from end to end of the AAA conversation.
The AAA protocol MUST also provide protection against replay attacks
in this situation.
8.4. Accounting and Auditing Requirements
8.4.1. Accounting Protocol Requirements
8.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
functions that require accurate knowledge of the state of the NAS.
NAS operators need to be able to engineer their network usage measure-
ment systems to a predictable level of accuracy. Therefore, an AAA
protocol MUST provide a means of guaranteed delivery of accounting
information between the NAS and the AAA Server(s). Note that the
requirement for guaranteed delivery is not only a protocol requirement
- NAS's might be required to implement certain practices (e.g. non-
volatile storage of accounting data) in order to support guaranteed
delivery.
8.4.1.2. Real Time Accounting
NAS operators often require a real time view onto the status of ses-
sions served by a NAS. Therefore, the AAA protocol MUST support real-
time delivery of accounting and auditing information. In this con-
text, real time is defined as accounting information delivery begin-
ning within one second of the triggering event.
8.4.1.3. Batch Accounting
The AAA protocol SHOULD also support delivery of stored accounting and
auditing information in batches (non-real time).
8.4.1.4. Accounting Time Stamps
There may be delays associated with the delivery of accounting infor-
mation. The NAS operator will desire to know the time an event actu-
ally occurred, rather than simply the time when notification of the
event was received. Therefore, the AAA protocol MUST carry an
Beadles Category: Informational [Page 12]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
unambiguous time stamp associated with each accounting event. This
time stamp MUST be unambiguous with regard to time zone. Note that
this assumes that the NAS has access to a correct time source.
8.4.1.5. Accounting Events
At a minimum, the AAA protocol MUST support delivery of accounting
information triggered by the following events:
-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
8.4.1.6. On-demand Accounting
NAS operators need to maintain an accurate view onto the status of
sessions served by a NAS, even through failure of the NA or AAA
server. Therefore, the AAA protocol MUST support a means of request-
ing current session state and accounting from the NAS on demand. The
intention is to provide for recovery if, for whatever reason, the nor-
mal flow of accounting data is interrupted.
8.4.2. Accounting attribute requirements
At a minimum, the AAA protocol MUST support delivery of the following
types of 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 ses-
sion.
-The cumulative number of bytes received by the user during the
session.
Beadles Category: Informational [Page 13]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
-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.)
-Reason for termination of the session.
-Error or diagnostic information on the session.
8.4.3. Accounting Protocol Security Requirements
8.4.3.1. Integrity and Confidentiality
Note that accounting and auditing data are operationally sensitive
information. 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.
8.4.3.2. Non-repudiation
Network operators use accounting data for network planning, resource
management, and other business-critical functions that require confi-
dence in the correctness of this data. The AAA protocol SHOULD provide
a mechanism to ensure that the source and destination of Accounting
data cannot repudiate this data after transmission.
9. Device Management Protocols
This document does not specify any requirements for device management
protocols.
10. Acknowledgments
Many of the requirements in this document first took form in Glen
Zorn's "Yet Another Authentication Protocol (YAAP)" document, for
which grateful acknowledgment is made. The author would also like to
thank Bernard Aboba and Pat Calhoun for their contributions.
Beadles Category: Informational [Page 14]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
11. Security considerations
See above for security requirements for the NAS AAA protocol.
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 adminis-
trative domains. Network operators are advised take this into consid-
eration when deploying NAS's and AAA Servers.
12. IANA Considerations
This document does not directly specify any IANA considerations. How-
ever, the following recommendations are made:
Future development and extension of an AAA protocol will be made much
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.
13. References
[KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate
Requirement Levels." RFC 2119, Harvard University, March 1997.
[NAS-MODEL] D. Mitton, M. Beadles. "Network Access Server Require-
ments Next Generation (NASREQNG) NAS Model." Work in progress.
[PPPOE] L. Mamakos et al. "A Method for Transmitting PPP Over Ether-
net (PPPoE)." RFC 2516, UUNET Technologies, Inc., February 1999.
[L2TP] W. M. Townsley, et al. "Layer Two Tunneling Protocol (L2TP)."
RFC 2661, IBM, Cisco, Ascend, Microsoft, August 1999.
[PPP] W. Simpson. "The Point-to-Point Protocol (PPP)." RFC 1661,
Daydreamer, July 1994.
[TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specification."
STD 8, RFC 854, ISI, May 1983.
[ROUTING-REQUIREMENTS] F. Baker. "Requirements for IP Version 4
Routers." RFC 1812, Cisco Systems, June 1995.
Beadles Category: Informational [Page 15]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
[IPV6] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6)
Specification." RFC 2460, Cisco, Nokia, December 1998.
[RFC 2277] H. Alvestrand. "IETF Policy on Character Sets and Lan-
guages." RFC 2277, UNINETT, January 1998.
[CHAP] W. Simpson. "PPP Challenge Handshake Authentication Protocol
(CHAP)." RFC 1994, Daydreamer, August 1996.
[EAP] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto-
col (EAP)." RFC 2284, Merit Network, Inc., March 1998.
[NAI] B. Aboba, M. Beadles. "The Network Access Identifier." RFC
2486, Microsoft, WorldCom Advanced Networks, January 1999.
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - The Directory: Authentication Frame-
work, June 1997.
[KERBEROS] J. Kohl, C. Neuman. "The Kerberos Network Authentication
Service (V5)." RFC 1510, Digital Equipment Corporation, ISI, Septem-
ber 1993.
[ESP] S. Kent, R. Atkinson. "IP Encapsulating Security Payload
(ESP)." RFC 2406, BBN Corp, @Home Network, November 1998.
[AH] S. Kent, R. Atkinson. "IP Authentication Header (AH)." RFC
2402, BBN Corp, @Home Network, November 1998.
[ROAMING-REQUIREMENTS] B. Aboba, G. Zorn. "Criteria for Evaluating
Roaming Protocols." RFC 2477, Microsoft, January 1999.
[RADIUS]
[RADIUS-ACCOUNTING]
14. Author's Address
Mark Anthony Beadles
UUNET, an MCI WorldCom Company
5000 Britton Rd.
Hilliard, OH 43026
Phone: 614-723-1941
EMail: mbeadles@wcom.net
Beadles Category: Informational [Page 16]
INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 implmentation 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 docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other Inter-
net 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 permis-
sions 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 WAR-
RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
16. Expiration Date
This document is filed as <draft-ietf-nasreq-criteria-03.txt>, and
expires April 11, 2000.
Beadles Category: Informational [Page 17]
