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 <nas-req@merit.edu> in addition
to the old <auth-acct@merit.edu>
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