One document matched: draft-ietf-nasreq-nasrequirements-00.txt
INTERNET-DRAFT John Vollbrecht
Allan Rubens
Glenn McGregor
Larry Blunk
Richard Conto
Merit Network, Inc.
October 1992
Expires April 1993
Network Access Server
Proposed Requirements Document
Status of this Memo
This document is written as input to the Network Access Server
Working Group. It describes a Network Access Server and its role in
providing temporary access to a network. The document focuses on
needs for authentication, authorization and accounting support. An
overview of these requirements is presented.
An initial set of specific requirements and issues is presentented
for review and discussion.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' Please check the 1id-
abstracts.txt listing contained in the internet-drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.
NAS Requirements [Page i]
INTERNET-DRAFT October 1992
1. Introduction
This document attempts to define a set of requirements for a class of
devices referred to as Network Access Servers (NAS's). The term
"Network Access Server" is used instead of the more conventional term
"Terminal Server" as it more accurately describes the devices of
interest. This is written as input to the NAS requirements working
group of the IETF.
A Network Access Server (NAS) is a router or terminal server which
provides temporary access to a network. It can provide access for
both traditional "dumb terminals" and terminal emulators as well as
workstations, PC's or routers utilizing a serial line framing
protocol such as PPP or SLIP. Thus a NAS can provide connections to a
single user, to a network or subnetwork, or to interconnected
networks.
The NAS may be a system dedicated to providing temporary network
access, or it may be a part of a system which has other capabilities
as well. For example a workstation with a set of dial in lines could
provide NAS functions.
The physical attachments to a NAS, which are used for temporary
connections, will typically be dial modems attached to local phone
lines, but could also be a connection supporting ISDN, frame relay,
or other switched (virtual) circuit service.
The purpose of this document is to define the requirements for
functions and services that a NAS should provide to both its
administrators (the people responsible for deploying and managing the
NAS) and its clients (the PCs, workstations and routers that connect
to the network through the NAS).
Many of the requirements of a NAS are identical to what is required
of a router. In fact a NAS can be viewed as a special class of
router, one in which the "neighbors" are not permanently attached.
When an attachment request is received, the NAS must insure that the
new "neighbor" is authorized to attach. This is contrasted with a
conventional router where a "neighbor" is permanently connected.
The application of this model to the character stream ("dumb
terminal") case requires that a "packetization" process convert
between the character stream and packet formats. In this case the
"neighbor" of the router is the packetizing client. A typical
packetizing client would be the Telnet client. The figure below
shows a model of this.
NAS Requirements [Page 1]
INTERNET-DRAFT October 1992
user network
attachment internal packet attachment
process(es) interfaces router(s) process
_______________________________________________________
| ________ |
| | | |
character | | Telnet | |
mode -----|-----| Client |\ |
| |________| \ |
| --() _____________ |
| \_____| | ________ |
| | | | | |
| | ROUTER |__|Ethernet|--|-
| ________ --()------| | |________| |
framed | | | / | | |
input ---|-----| PPP |/ |_____________| |
| |________| |
| |
| |
|________________________________________________________|
Figure 1 NAS structure
In the above model there are user attachment processes which are
responsible for handling incoming data. Not shown, but necessary for
dial-in async input, is a process which will switch input to the
appropriate input process (e.g. a way to distinguish between a
character stream input and PPP input at the time a connection is
initiated). The figure shows two user attachment processes, but
there could be many different ones to support SLIP, ISDN, etc.
The internal router interface is the point where service
authorization is implemented. Here routing configurations, packet
filters and such are applied. The implementation of these may be
different at a PPP interface than at a Telnet Client interface. For
example, a PPP interface would restrict packets by applying filters
to each packet, while the Telnet port would check only when it is
establishing a TCP connection.
The router process forwards packets. There may be several processes
which route packets, each using different routing protocols. It is
likely that a NAS will route other protocols, such as IPX or CLNP or
Appletalk, in addition to IP.
The network attachment process is similar to the framed input
attachment process, except that it is configured as part of the NAS,
and its capabilities are not modified with new connections. The
network attachment process could support an ethernet connection, as
NAS Requirements [Page 2]
INTERNET-DRAFT October 1992
shown in the figure, or a dial out PPP connection, or a synchronous
serial line, or some other network attachment mechanism.
This document attempts to define only requirements that are unique to
a NAS. As we see it, these lie in the operational areas of
authentication, authorization, and accounting (AAA).
Our goal is to identify requirements, not to define specific
standards. Our hope is that standards are (or will be) available to
satisfy these requirements. The next task of the WG will be to
identify protocols that can be used to satisfy these needs and to
specify which should be used, in what combinations, and in which
situations.
2. The Problem
Figure 2 (below) shows the general model we have used to describe the
problem we are addressing. The model shows a NAS which is part of a
network, and both NAS and network are part of the same administrative
domain (which could include multiple networks and/or NAS's). Servers
attached to the network provide AAA functions to the NAS. Physically
the servers may be coresident in the same system as the NAS, but they
need not be, and are logically distinct. In the figure they are
shown as separate boxes attached to the same net as the NAS.
The AAA servers are controlled by a network administrator. The
servers are used to authenticate users requesting access to the
network (who are you?), to authorize types of access (what network
services are you allowed to use?), and to track usage (what services
got used, how long, by who, who should be charged?).
NAS Requirements [Page 3]
INTERNET-DRAFT October 1992
_______________ _____________ __________
| authentication| |authorization| |accounting|
| server | |server | |server |
|_______________| |_____________| |__________|
\ | /
\ | /
_\___________|____________/____
/ \
/ \
/ \
________ \
| | \
_____ | | |
| | | | |
|User |-----| NAS | network(s)/administrative domain |
| | | | |
------ | | |
|________| /\
(terminal/ \ / \
workstation/ \ / \
router) \ / to other
\ / domains
\__________________________ /
/ | \
/ | \
___/__ __ |___ __\___
| | | | | |
| host | | host | | host |
|_______| |_______| |_______|
Figure 2 - NAS environment
In this model, the User (terminal, workstation or router) is the
client of the NAS. It requests to be connected to the network, and
the NAS accepts or rejects the request. The User must be
authenticated and authorized by servers which can typically only be
reached through the NAS.
Note that the AAA services described here are for the NAS only. If
the User were to connect to the NAS to gain access to a host that
also requires authentication, the User would first need to go through
authentication and authorization with the NAS to get access to the
network. The User would then need to authenticate and authorize a
second time to get access to the host. The second authentication and
authorization might be done with the same or different servers. The
two operations are independent.
NAS Requirements [Page 4]
INTERNET-DRAFT October 1992
Figure 3 illustrates an Authentication and Authorization process
controlling an internal interface. The user attachment process sends
packets to the internal interface when it is in the connected state.
When it is in a not-connected state it sends packets to the
Authentication and Authorization (AA) process. The user requests
services from the AA process, and may communicate with the (possibly
remote) Authentication and Authorization servers through the AA
process. If the AA process accepts the user request it sets the
internal interface according to the user request/authorization, and
then sets the user attachment interface to the connected state.
Again, this is not intended to define an implementation, but to show
some of the required NAS functions.
After the user attachment process is set to the connected state, it
sends packets directly through the internal interface and the
Authentication and Authorization process is not involved.
________________________________________________________________
| _______________ |
| | | |
| | Authentication| |
| | and | |
| | Authorization | |
| |_______________| |
| / || \ |
| / || \ |
| / ||set \ |
| / ||authorized \ |
| / ||functions \ |
| _____/_____ ___\/______ _\_____ ___________ |
| | | | | | | | | |
| | user | | | | | | network | |
---|---| attachment|---| internal |----| router|----| attachment|--|--
| | process | | interface| | | | process | |
| |___________| |___________| |_______| |___________| |
| |
| |
|________________________________________________________________|
Figure 3 Authentication and Authorization Process
Note that this model can be extended to allow a host on the network
side of the NAS to request, through the Authentication and
Authorization server, that a user attachment process initiate a
connection to a remote user. This paper does not discuss this
NAS Requirements [Page 5]
INTERNET-DRAFT October 1992
situation, but it should be included in the WG discussions.
3. Preliminary list of requirements
The following is a preliminary list of suggested AAA requirements and
issues for consideration by the WG. Requirements will be modified
and added as part of the WG process.
3.1. Authentication
Requirements
a secure authentication mechanism is a necessity. It needs to be
resistive to passive and active attacks.
the authentication mechanism should allow multiple NAS's in the
same administrative domain to access a common authentication
database. This database may be distributed.
some NAS ports may be configured to be implicitly authenticated
(e.g. hard-wired PC in private office).
a mechanism to allow a user to be authenticated by a server in a
cooperating administrative domain should be available.
authentication should be possible in character stream mode before
switching into framed mode.
Issues
Authentication will presumably use the client-server model, where
the User is the Client of the NAS. To be Authenticated the User
goes to an authentication server and gets an ok which the NAS will
accept. Since the authentication server is likely to be available
to the User only through the NAS, this will require a mechanism in
the NAS to allow the User to contact the server before it is
validated to use the NAS. This is illustrated in figure 3 above.
Is it practical to run an authentication system such as Kerberos on
a NAS?
How long is an authentication valid? How can use of a previous
user's authentication on a shared access device (e.g a workstation
NAS Requirements [Page 6]
INTERNET-DRAFT October 1992
in a public area) be prevented?
3.2. Authorization
Requirements
Authorization seems to imply configuration. For each User there will
be a port configuration. This would likely include some or all of the
following:
- route filters (by ports/ addresses)
- routing domain participation
- static routes
- routing peers
- network address/mask
- protocols supported (IP and CLNP)
- negotiable parameters (e.g. packet size, compression)
The Authorization server should interact with the Accounting server to
determine if appropriate account limit restrictions are met before
authorizing NAS access.
Issues
Does authorization by destination server potentially require access to
information that must be provided by the NAS? For example, how would
a remote server restrict access to connections from a specific set of
NAS ports?
Can Access Control Lists be used for the class of information to be
provided, or is the information too unstructured for ACLs?
For character stream Users additional information may also be required
to set up key mappings, and other environmental variables.
Is passing of configuration or authorization information as Access
Control Lists or with some other mechanism an ok thing to do from a
security standpoint?
How does this tie into the work presented at the Authorization and
Access control BOF?
Does this tie in with Mobile Hosts, in that:
NAS Requirements [Page 7]
INTERNET-DRAFT October 1992
1) IP addresses need to be authorized by NAS, and
2) a mechanism is needed to insure that an address is not
multiply assigned.
As with authentication, the authorization server is likely to be
available to the User only through the NAS. Thus the User must have
some way to get to the authentication server without being authorized.
4. Accounting
Requirements
Support collection of usage information by user session, including
date/time.
Send session information to remote server when sessions terminate,
and checkpoint sessions periodically.
Keep sufficient information for audit tracking.
Because charges may be involved, a reliable transport for
accounting information is required.
Need to be able to examine accounting/usage information on a timely
basis to enable problem tracking.
The accounting server must interact with the authorization server
to provide account limit information.
Information about access attempts, authentication or authorization
failures, etc. should be kept. This needs to be done in a secure
manner (e.g. it will not report the client-id when a password or
client id failure occurs since the client-id may actually be a
password from a user that has gotten out of sync with the
authentication process.)
Issues
How are charges monitored for active NAS access? Does a user get
disconnected when account balance goes to $0?
Should accounting policy (rates and charges) be implemented in the
NAS, the Accounting server, or shared by both? Can rate
NAS Requirements [Page 8]
INTERNET-DRAFT October 1992
determination and charging be deferred to post-processing?
Would it be reasonable to download an accounting algorithm in some
standard format to the NAS?
5. Multiple AAA domains
Another goal is to allow administrative domains to cooperate in
providing AAA services. Thus a user might dial into a NAS in one
domain but be authenticated/ authorized and have usage reported to
another domain.
This raises a number of issues which it would seem good to consider
as part of this WG process. Among these are trust between
distributed authentication and authorization servers, reporting
usage to multiple domains, and protocols to support distributed AAA
servers.
6. Relations to other working groups
The following is a list of working groups that seem to be related
to NAS requirements. This will probably be expanded.
Router Requirements
Security
PPP
Accounting
Authorization and Access Control
Telnet
NAS Requirements [Page 9]
INTERNET-DRAFT October 1992
7. Authors' Addresses
John Vollbrecht
email: jrv@merit.edu
Allan Rubens
email: acr@merit.edu
Glenn McGregor
email: ghm@merit.edu
Larry Blunk
email: ljb@merit.edu
Richard Conto
email: rsc@merit.edu
all Authors may be reached as follows
Merit Network, Inc.
1071 Beal Ave
Ann Arbor Mi. 48109
Phone: (313) 936-3000
| PAFTECH AB 2003-2026 | 2026-04-23 04:17:30 |