Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/nasreq/nasreq-minutes-93mar.txt

Text File | 1993-04-30 | 13KB | 307 lines

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           [e-mail]
Jim Barnes               [e-mail]
Ed Brencovich            [e-mail]
Sandy Bryant             [e-mail]
John Campbell            [e-mail]
John Chang               [e-mail]
David Conrad             [e-mail]
Avi Elenko               [e-mail]
Jonathan Fellows         [e-mail]
Antonio Fernandez        [e-mail]
Jisoo Geiter             [e-mail]
Richard Graveman         [e-mail]
Terry Gray               [e-mail]
Richard Harris           [e-mail]
Susan Harris             [e-mail]
Frank Heath              [e-mail]
David Katinsky           [e-mail]
Charles Kaufman          [e-mail]
Stephen Kent             [e-mail]
Hock-Koon Lim            [e-mail]
John Linn                [e-mail]
Steven Lunt              [e-mail]
Cynthia Mills            [e-mail]
Bob Morgan               [e-mail]
Clifford Neuman          [e-mail]
David O'Leary            [e-mail]
Brad Parker              [e-mail]
Brad Passwaters          [e-mail]
April Richstein          [e-mail]
Allan Rubens             [e-mail]
Jeffrey Schiller         [e-mail]
William Simpson          [e-mail]
Bob Stewart              [e-mail]

                                   5





Theodore Ts'o            [e-mail]
John Vollbrecht          [e-mail]
Richard Warwick          [e-mail]
James Weatherford        [e-mail]
Steve Willens            [e-mail]
Cathy Wittbrodt          [e-mail]



                                   6