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