Editor's Note: Minutes received 12/21/92 CURRENT_MEETING_REPORT_ Reported by John Vollbrecht/Merit Minutes of the Network Access Server Requirements Working Group (NASREQ) The NASREQ Working Group met on Wednesday afternoon at the Washington IETF meeting. Allan Rubens chaired the meeting. Allan announced that John Vollbrecht would be acting as co-Chair for the Group. Note that the mail Group for this has a new alias in addition to the old Agenda o Discuss the NAS Proposed Requirements Document (Internet-Draft). o Go over Jesse Walker's comments on the draft. o Plan next steps. Discussion of NAS Proposed Requirements Document Copies of the draft NAS requirements were available at the session. John Vollbrecht talked through the main points. A major change of focus between the draft and the previous draft is that the current draft considers the NAS to be a router which supports temporary connections to a net rather than as a terminal server which also supports framed access. Terminal support in a NAS (if available) is provided by a Character Stream client (e.g., Telnet) that converts the character stream to framed output. The output of the Character Stream client is then input to the router. The major thrust of the NASREQ Working Group is to define support requirements for systems providing temporary connections to a network. The main requirements were seen to be: 1. (Mutual) authentication of NAS and user. 2. Per user configuration of ports on the NAS and/or per user authorization of user for network access. 3. Per user session record keeping. Some discussion of the NAS model took place. Jeff Schiller asked if the ability to have character stream terminal sessions authenticate without sending passwords in the clear was being considered by this Working Group. The response was that so far this had been outside the area being considered, but perhaps could be included if standards for this 1 are developed. There was some question of the need to authenticate for access to the network at all. Presumably hosts and servers can demand authentication if they need to know who is using their system, and to monitori and control scarce resources (modems and phone lines). The response was that the NAS would authenticate in order to know who is using it. It is a special server that provides access to the network. Network providers use it to give their clients access to their network. A NAS may use the same or different authentication methods (and servers) as a file or print server. A good deal of discussion of authorization and per user configuration took place. The issue of whether the NAS would screen access to other services on the network was discussed. The concept in the draft document is that the NAS only controls NAS functions, and other hosts need to screen themselves. If one views what is required in NAS authorization as per user port configuration, then the concept becomes clearer. A user connects, gets authenticated, then has its port set up according to the user's preconfigured requirements. The authentication and authorization must be supported by (possibly) remote servers. A set of NAS's would be able to be authorized by a set of authorization servers. Bill Simpson asked if this was aimed at ultimately supporting a situation where a user could connect to a NAS on one network and get authenticated and authorized by another (connected) network. Indeed this is one of the goals. Some discussion of two approaches to multiple domain authorization took place. The first is a hierarchical approach where each NAS goes to a specific server (or backup). The server then talks with other servers if necessary to get authorization. The second is to have the NAS contact different authentication and authorization servers itself. This might be driven by having the user identify the server for the NAS to use as part of the connection sequence. This could be useful where a number of sites have independent authentication and configuration/authorization server. Both methods should be investigated. Authentication Issues The NAS provides access to the network to which the authentication server is connected. The user and authentication server must communicate before the user is formally connected to the NAS. This requirement means that the NAS must provide a capability at connection time for this communication to happen. Two possible approaches were discussed. 1. The user-NAS dialog includes PAP or some other sequence that provides an id/password combination. The NAS would then take the password/id and go to an authentication server (e.g., Kerberos) on 2 behalf of the user. It was pointed out that authentication will need to be done before the NAS knows the IP address of the user. This is because the IP address assignment may be based on the user id. It may be necessary to use a ``temporary'' ip address during the authentication phase. 2. The user-NAS dialog would use CHAP. In this case the NAS does not receive the id/password, so the most it seems is possible would be to have it act as a CHAP forwarder. The NAS would forward messages between the user and a remote CHAP server. In both these cases some additional issues need to be worked out. In the first case a question is whether the response from the authentication server will reach the user. The user would presumably get a ``ticket'' which it then passes to the NAS to request access. Alternatively the NAS could act as proxy for the user, which might be better in general since the user doesn't then need to support Kerberos or whatever authentication protocol is used. In the second case the question is how does the NAS get informed of the result of the CHAP exchange if all it does is act as a forwarding agent. Clearly it will need to interpret some of the exchange as well as forward so that it will know if the authentication succeeded. It may be that the remote CHAP server will need to have extensions to the protocol defined to allow it to communicate with the NAS as well as the user. Authorization/per User Configuration Issues Per user configuration requires that the port to which a user is attached be configured from that user's predefined setup. For the general case the port could be configured with route filters, an IP or other protocol address, static routes, routing protocols supported, and anything else that is needed to configure a router port. Authorization is implied by the configuration. Route filters act as restrictions, static routes are specific authorizations. In the discussion of how this fits in with the model of the Authorization and Access Control Group, Cliff Neuman suggested that this could be considered as a single ACL for network access with restrictions (filters) to provide finer grain control. The alternative would be to have an ACL for each address or network reachable via the NAS - a potentially very large number for a NAS connected to the Internet. Accounting Issues It would be good to use the work done by the Internet Accounting (ACCT) Working Group as the basis for what is required in a NAS. A couple of issues need to be sorted out to be sure this is workable. The ACCT Group does not seem to have a well described way to handle multiple sessions on the same port. This may be possible, but it needs 3 to be worked out. The method for collecting information being proposed by the ACCT Working Group is to use SNMP to query for information stored. The definition of MIB for multiple sessions per port needs to be clarified. It would seem reasonable to consider alternatives to SNMP (like an rpc) for passing accounting information to the remote collector. Review of Jesse Walker's Comments Allan went over a number of issues raised in Jesse's comments. We thought it was important to air these issues at this meeting to get input from others before making changes to the Requirements draft. Also, since many of the issues raised deal with the question of focus for this Working Group, it was beneficial to raise these issues in order to solicit input from the Group on directions that should be taken. Jesse's message containing the issues and a response generated by John are available in the auth-acctg archives. The resolution of the raised issues will be incorporated in the next Requirements draft, to the best of our ability. A few of the major points of contention are described briefly next. One of the issues raised was that security ultimately hinges upon secure loading and configuration of the NAS itself and this is not an issue being addressed as yet. There was no consensus as to what to do about this problem. It is definitely not within the bounds of this WG to solve this problem, but we should incorporate any solution as a NAS requirement. As far as Kerberos being sufficient to handle security, it may help but it doesn't completely solve the problem. As discussed above, it may be used with PAP, but it doesn't seem to be useful with CHAP. The issue of how long an authentication is valid was said to be a matter of policy, not an issue of concern to this Group. This is probably true, but it brings up a related matter - the issue of how to deal with inactive PPP sessions tying up NAS resources. This needs further discussion. The issue of a ``reliable'' transport mechanism for the collection of accounting information was brought up. It was explained that ``reliable'' was not intended to mean absolutely fail-safe, rather it meant that a best-effort mechanism was needed so that accounting/auditing information was not frequently lost. The NAS document will be modified to make this clear. Date and timestamping of accounting needs to optional as it requires clock sync mechanism. Again, this is not really the case because we're only talking about times corresponding within ``reasonable'' limits. The document will be changed to clarify this. The topic of Account limits was also discussed. One thing that was clear from this discussion was that this shouldn't just be written off 4 as being beyond the scope of the Group or of being a policy matter - at least not without further discussion. Plans for Future Action We discussed a number of possible next steps. Allan and John agreed to clean up the NAS document and resubmit it as an Internet-Draft. The changes will reflect discussion of the document and of Walker's specific comments. We would like to have more detailed requirements for how the NAS will do authentication. The PAP/Kerberos and CHAP/CHAP cases both should be defined in more detail. A number of people expressed some interest in this but no specific plan was made to do something. The configuration/authorization issues need further work. A specific proposal for how to manage per user configuration is needed. No specific plan for this was initiated. Finally, there needs to be some work with the ACCT Working Group to define how specific requirements for the NAS will fit. Some of the ACCT Group members showed a lot of interest in working on this, and John and Allan will follow up with them to come up with a proposal for inclusion in the NAS Requirements document. Attendees Jim Barnes barnes@xylogics.com Daniel Brennan dmb@teleoscom.com Vickie Brown brown@osi540sn.gsfc.nasa.gov J. Nevil Brownlee nevil@aukuni.ac.uz Richard Fisher rfisher@cdhf1.gsfc.nasa.gov Barbara Fraser byf@cert.org James Galvin galvin@tis.com Ken Hirata khirata@emulex.com Nat Howard nrh@bellcore.com Miriam Kadansky mckadansky@eng.xyplex.com John Linn linn@erlang.enet.dec.com Joshua Littlefield josh@cayman.com Steven Lunt lunt@bellcore.com Mohammad Mirhakkak mmirhakk@mitre.org Clifford Neuman bcn@isi.edu Hilarie Orman ho@cs.arizona.edu Brad Parker brad@fcr.com Drew Perkins ddp@andrew.cmu.edu Joseph Ramus ramus@nersc.gov Allan Rubens acr@merit.edu Jeffrey Schiller jis@mit.edu Tim Seaver tas@concert.net William Simpson Bill.Simpson@um.cc.umich.edu Brad Steinka brad@microcom.com 5 John Vollbrecht jrv@merit.edu 6