CURRENT_MEETING_REPORT_ Reported by Larry Blunk/Merit, Allan Rubens/Merit and John Vollbrecht/Merit Minutes of the Network Access Server Requirements Working Group (NASREQ) Agenda o Quick Introduction and Review. o User/NAS Authentication Issues. Review of Write Ups. o Server Requirements Discussion. o NAS/AAA Architecture Options Vendor Presentations/discussions. o Plan for Future Work. Review The meeting started out with a review of what this Group is trying to accomplish. Its primary purpose is to establish a set of requirements for authentication, authorization, and accounting (AAA) capabilities in a network access server (NAS). This has been difficult because standards to address the required interfaces are not well defined. The focus has shifted to outlining requirements for standards that need to be developed. This meeting attempted to focus on the NAC/NAS interface and the NAS/AAA server interface separately. It was pointed out that all parts of the authentication process need to be considered when evaluating a particular scheme, so such a distinction needed to be made carefully. The term NAC (Network Access Client) was suggested quite early in the meeting to replace the term ``user'' in order to prevent confusion about the problem being addressed. A NAC is as a device such as a workstation or router that wishes to attach to the NAS. NAC/NAS Authentication John Vollbrecht presented three models for NAC/NAS authentication which he has described in postings to the nasreq mailing list. The models presented were: 1. NAC id and password in the clear. 2. One way authentication of NAC to NAS, password not in clear. 3. Mutual authentication of NAC and NAS, again no password in the clear. There was some discussion of whether the first approach was desirable 1 since it puts the user password in the clear. It was pointed out that this is the predominant way of doing authentication at this time. It was also pointed out that the connection between NAC and NAS would be coming under more serious attacks as time goes on and technology becomes more dispersed and better understood. Jeff Schiller pointed out, and the Group endorsed, that any authentication methods or protocols adopted by this Group need to preserve the same degree of security provided by the underlying authentication mechanism. That is, inserting a NAS should not make the process more vulnerable than it was without a NAS. There was some concern that the NAS needs to be an identifiable entity to prevent spoofing. There was a question as to whether mutual NAS/NAC authentication is necessary. One might be willing to trust that the connection is being made to the phone number being called. Although many people at the meeting thought that it wasn't really necessary at this time, there still may be a need in the larger community. It is not the role of the Group to decide what level of security is needed but to provide for mechanisms to achieve various levels of security that can be selected by the NAS providers. Jeff Shiller noted that it is not very difficult to provide mutual authentication, so it should be provided for. Another question that arose was ``Even after you mutually authenticate with the NAS, how can you be assured that the NAS really is one provided by the network you think you're calling into?'' One could envision someone advertising a phone number to use that is really connected to a machine that picks up user ids and passwords or logs all data. To avoid this, you may want to know that the particular NAS you've called into is really a NAS provided by the administrator of the network the NAS resides on. Using the concept of Group membership for this problem makes it addressable as an authorization (as opposed to authentication) issue. It was also pointed out during this discussion that only NAC/NAS authentication is being considered here. While the same mechanisms might be used between a host system or a server and the authentication server, this would be done separately from the NAC/NAS authentication. The NAS is not meant to act as a security front end for a set of servers. Jeff Schiller agreed to review the proposed authentication mechanisms and provide a set of specifications. Bill Simpson said that he would insure that those authentication requirements that impact PPP authentication protocols are addressed by the PPP Working Group. NAS/AAA Interface Requirements John Vollbrecht then opened discussion of the NAS/AAA interface. The environment that a NAS works in may be quite complex. The MichNet environment is one where several institutions provide dialup NAS service 2 and allow the others to share usage of the NAS. In this environment it is necessary for a NAS to be able to authenticate a user at the user's home authentication server. The home authentication servers may be quite diverse, including Kerberos, Unix pw/id, MTS, etc. The NAS would also need to interface to multiple authorization and accounting servers. In this environment it seems that architecturally a common AAA server that interfaces to the NAS and then to all the servers would be appropriate - a ``helper''. The interface to the common AAA server could be some existing standard, if one existed, that would serve the purpose. The Group had some discussion of whether such a standard did exist. No standard appeared to be appropriate. John next presented in greater detail, the idea of the helper and the potential benefits of having a standard protocol between the NAS and the helper. The helper is a process that interfaces with other servers for the NAS. A standard NAS/helper interface is then required. This approach could benefit NAS purchasers, vendors, and users. The NAS/helper concept allows NAS vendors to implement a standard protocol for interfacing with AAA rather than implementing a separate interface for each type of server to be supported. Users, or third party implementors, could then provide the special interfaces to AAA servers in stand alone packages that could augment or replace vendor implementations. The hope is that the NAS/helper protocol could be defined in a manner that provides enough functionality and expandability to allow adaptation to evolving AAA standards. Network providers could base their choice of NAS on factors other than the AAA server types supported. NAS/helper Proposal Steve Willens then presented Livingston's RADIUS implementation. RADIUS is a system recently developed by Livingston that parallels the NAS/helper model. Livingston is willing to make code supporting this available as part of a NAS/helper standard if the Group thinks that would be a good idea. Steve described the protocol used and the functions provided by this system. He also described how MD5 is used to pass unencrypted passwords securely from the NAS to the helper. This allows authentication systems that need to receive an unencrypted password to be used for the NAC/NAS authentication. It was suggested that the entire data stream be encrypted, not just the packet containing the id and password. There are problems with this due to PPP and also due to the extra processing load or cost that would be imposed on the typically inexpensive NAS. It would be unreasonable to require sending all PPP data encrypted. It also would require DES or something which has much tighter export controls. 3 Representatives from PSI and JVNCnet saw a real need for a mechanism like Radius. Steve offered to make both the RADIUS client and server software available to others, including other vendors. Plan for Future Work Allan Rubens reminded the Group that there are still a few other issues that need to be addressed. One issue deals with how the per port packet filters are specified and updated. One proposal was that there should be a standard MIB for packet filters and that the filters should be updated using SNMP. There's also the issue of how a NAC specifies what authentication domain an id belongs to. It was pointed out that Kerberos provides for this capability. There are still major accounting issues that need to be investigated and discussed. Steve Kent thought that the issue of distributed names could be significant. Allan Rubens proposed that the Group attempt to finish up the ``Requirements Document'' by November. Some thought that it was too early. Others thought that we needed an ``Architecture Document'' first to clarify what a NAS is and the environment in which it is expected to operate. There was some concern that protocols were being defined by a requirements Group. Action Items Steve Willens Agreed to head up an effort to define a NAS-``helper'' protocol as an RFC. Representatives from at least two other vendors volunteered to help with this effort. The NASREQ Charter will be updated to reflect the current goals of this Group and discussions will take place to determine if this protocol should be defined as a product of this Working Group. It was pointed out that the NAS-helper model is just one way of addressing NAS AAA issues and that the Group needs to still be open to other approaches. Steve will publish the names of people participating in the Protocol definition and invites participation from anyone else interested. A goal is to have some working documents available for the Amsterdam IETF and a Draft RFC for November. Steve will advise if these goals are realistic. Jeff Schiller Volunteered to describe a set of NAC/NAS authentication protocols. Hopefully these will be available by the Amsterdam IETF so they can be passed to the PPP Working Group. Bill Simpson Agreed to take the descriptions that Jeff works up 4 to the PPP Working Group. Rubens or Vollbrecht Will rework the Working Group Charter to include the possibility of coming up with an RFC for a NAS/helper interface protocol. Jim Barnes Has volunteered to Chair a meeting of this Working Group at the next IETF in Amsterdam. A meeting had not been scheduled earlier because neither of the Chairs was able to commit to being at the meeting. It seems that it would be good to have a meeting there, if only to allow more people to hear about what we are doing and to get more input from a European view. Unless there are strong objections we will schedule a meeting in Amsterdam with Jim chairing it. Attendees Vikas Aggarwal aggarwal@jvnc.net Jim Barnes barnes@xylogics.com Ed Brencovich edb@dss.com Sandy Bryant slb@virginia.edu John Campbell jrcamp@nosc.mil John Chang changj@ralvm6.vnet.ibm.com David Conrad davidc@iij.ad.jp Avi Elenko avi@dss.com Jonathan Fellows jonf@gdstech.grumman.com Antonio Fernandez afa@thumper.bellcore.com Jisoo Geiter geiter@mitre.org Richard Graveman rfg@ctt.bellcore.com Terry Gray gray@cac.washington.edu Richard Harris rharris@atc.boeing.com Susan Harris srh@umich.edu Frank Heath heath@cmc.com David Katinsky dmk@pilot.njin.net Charles Kaufman kaufman@zk3.dec.com Stephen Kent kent@bbn.com Hock-Koon Lim lim@po.cwru.edu John Linn linn@gza.com Steven Lunt lunt@bellcore.com Cynthia Mills cmills@bbn.com Bob Morgan morgan@networking.stanford.edu Clifford Neuman bcn@isi.edu David O'Leary doleary@cisco.com Brad Parker brad@fcr.com Brad Passwaters bjp@sura.net April Richstein amr@tycho.ncsc.mil Allan Rubens acr@merit.edu Jeffrey Schiller jis@mit.edu William Simpson Bill.Simpson@um.cc.umich.edu Bob Stewart rlstewart@eng.xyplex.com 5 Theodore Ts'o tytso@mit.edu John Vollbrecht jrv@merit.edu Richard Warwick richard@dss.com James Weatherford weatherf@nosc.mil Steve Willens steve@livingston.com Cathy Wittbrodt cjw@barrnet.net 6