[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc3169                                  
     NASREQ Working Group                              M. Beadles
     INTERNET-DRAFT                UUNET, an MCI WorldCom Company
     Category: Informational
     <draft-ietf-nasreq-criteria-03.txt>
     11 October 1999
     
     
            Criteria for Evaluating Network Access Server Protocols
     
     
     1..  Status of this Memo
     
     
     This document is an Internet-Draft and is in full conformance with all
     provisions of Section 10 of RFC2026.  Internet-Drafts are working doc-
     uments  of  the Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also distribute  work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts  are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents  at  any
     time.   It is inappropriate to use Internet- Drafts as reference mate-
     rial or to cite them other than as "work in progress."
     
     The   list   of   current   Internet-Drafts   can   be   accessed   at
     http://www.ietf.org/ietf/1id-abstracts.txt
     
     The  list  of  Internet-Draft  Shadow  Directories  can be accessed at
     http://www.ietf.org/shadow.html.
     
     The  distribution  of  this  draft  is  unlimited.   It  is  filed  as
     <draft-ietf-nasreq-criteria-03.txt> and expires April 11, 2000. Please
     send comments to the author.
     
     
     2.  Copyright Statement
     
     
     Copyright   (C) The Internet Society 1999.  All Rights Reserved.
     
     
     3.  Abstract
     
     
     This document defines  requirements  for  protocols  used  by  Network
     Access  Servers  (NAS).   Protocols  used by NAS's may be divided into
     four spaces:  Access protocols, Network protocols, AAA protocols,  and
     Management  protocols.  Primary attention is given to setting require-
     ments for AAA protocols, since that space is currently the least  well
     defined.
     
     
     
     
     
     
     
     Beadles                 Category: Informational               [Page 1]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     4.  Requirements language
     
     
     In  this document, the key words "MAY", "MUST, "MUST NOT", "optional",
     "recommended", "SHOULD", and "SHOULD NOT", are to  be  interpreted  as
     described in [KEYWORDS].
     
     
     5.  Introduction
     
     
     This  document  defines  requirements  for  protocols  used by Network
     Access Servers (NAS).  Protocols used by NAS's  may  be  divided  into
     four  spaces:  Access protocols, Network protocols, AAA protocols, and
     Device Management protocols.  The primary focus of this document is on
     AAA  protocols.   The  reference model of a NAS used by this document,
     and the analysis of the functions of a NAS which led to  the  develop-
     ment of these requirements, may be found in [NAS-MODEL].
     
     
     6.  Access Protocol Requirements
     
     
     There  are three basic types of access protocols used by NAS's.  First
     are the telephony-based access protocols, which interface to  the  NAS
     via  a  modem  or  terminal adapter or similar device. These protocols
     typically support asynchronous or synchronous PPP [PPP] carried over a
     telephony  network.   Included  by  extension  are  cellular telephony
     access protocols.  Second are broadband pseudo-telephony access proto-
     cols, which are carried over xDSL or cable modems, for example.  These
     protocols typically support an encapsulation method such as  PPP  over
     Ethernet  [PPPOE].   Finally  are the virtual access protocols used by
     NAS's that terminate tunnels.  One example of this type of protocol is
     L2TP [L2TP].
     
     It  is  a  central  assumption  of  the NAS model used here that a NAS
     accepts multiple point-to-point links via one of the above access pro-
     tocols.  Therefore, at a minimum, any NAS access protocol MUST be able
     to carry PPP.  The exception to this requirement  is  for  NAS's  that
     support  legacy text login methods such as telnet [TELNET], rlogin, or
     LAT.  Only these access protocols are exempt from the  requirement  to
     support PPP.
     
     
     7.  Network Protocol Requirements
     
     
     The  network  protocols supported by a NAS depend entirely on the kind
     of network to which a NAS is providing access.  This document does not
     impose  any  additional  requirements  on network protocols beyond the
     protocol specifications themselves.  For example, if a NAS that serves
     a  routed  network  includes internet routing functionality, then that
     NAS must adhere to [ROUTING-REQUIREMENTS], but there are no additional
     protocol  requirements  imposed  by  virtue of the device being a NAS.
     
     
     
     Beadles                 Category: Informational               [Page 2]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     
     
     8.  AAA Protocol Requirements
     
     
     
     8.1.  General protocol characteristics
     
     
     There are certain general characteristics that any AAA  protocol  used
     by  NAS's must meet.  Note that the transport requirements for authen-
     tication/authorization are not  necessarily  the  same  as  those  for
     accounting/auditing.  An AAA protocol suite MAY use the same transport
     and protocol for both functions, but this is not strictly required.
     
     
     8.1.1.  RADIUS Compatibility
     
     
     It is operationally very important to support the  many  thousands  of
     devices making up the Internet today, which speak RADIUS.   Therefore,
     devices which implement the AAA protocol SHOULD support some means  of
     compatibility  with  devices  that implement RADIUS.  This requirement
     MAY be met by simply listening on the same port as RADIUS;  note  that
     in  this  case  the AAA and RADIUS protocols might be quite different.
     Alternatively, the requirement  MAY  be  met  by  creating  a  gateway
     between RADIUS and the AAA protocol.  Other alternatives are possible;
     the intent is to ensure the  continued  operation  of  the  currently-
     deployed  RADIUS infrastructure during deployment of the AAA protocol.
     
     
     
     8.1.2.  Transport requirements
     
     
     
     8.1.2.1.  Fast Fail-over
     
     
     The transport for the AAA protocol MUST support fast (within a  matter
     of   milliseconds)  fail-over  for  authentication  and  authorization
     requests.
     
     
     8.1.2.2.  Reliable Accounting
     
     
     The transport for the accounting data in  the  AAA  protocol  MUST  be
     reliable.
     
     
     
     
     
     
     
     
     Beadles                 Category: Informational               [Page 3]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     8.1.2.3.  Long-term exchange of small packets
     
     
     Very large scale NAS's that serve up to thousands of simultaneous ses-
     sions are now being deployed.  This means that, in the extreme,  there
     may  be  an almost constant exchange of many small packets between the
     NAS and the AAA server.  An  AAA  protocol  transport  SHOULD  support
     being  optimized for a long-term exchange of small packets in a stream
     between a pair of hosts.
     
     
     8.1.2.4.  Support for multiple AAA servers
     
     
     In order to operationally support large loads, load balancing to  mul-
     tiple AAA servers will be required.  The AAA protocol MUST provide for
     NAS's to balance AAA sessions between two or more  AAA  servers.   The
     load  balancing  mechanism  SHOULD  be  built  in  to the AAA protocol
     itself.  The AAA protocol design MUST NOT introduce a single point  of
     failure  during the AAA process.  The AAA protocol MUST allow any ses-
     sions between a NAS and a given AAA server to fail over to a secondary
     server  without  loss  of state information.  This fail-over mechanism
     SHOULD be built in to the AAA protocol itself.
     
     
     8.1.2.5.  Flow control
     
     
     In order to support the previous two requirements,  the  AAA  protocol
     MUST provide a flow control mechanism to avoid flooding a busy server.
     
     
     8.1.2.6.  Support for Multiple Administrative Domains
     
     
     NAS's operated by one authority provide network  access  services  for
     clients  operated  by another authority, to network destinations oper-
     ated by yet another authority.  This type of arrangement is of growing
     importance;  for example, dial roaming is now a nearly ubiquitous ser-
     vice.  Therefore, the AAA protocol  MUST  support  AAA  services  that
     travel  between  multiple domains of authority.  The AAA protocol MUST
     NOT use a model that assumes a single domain of  authority.   The  AAA
     protocol MUST NOT dictate particular business models for the relation-
     ship between the administrative domains.  The AAA protocol  MUST  sup-
     port  proxy,  and  in addition SHOULD support other multi-domain rela-
     tionships such as brokering and referral.
     
     The AAA protocol MUST also meet the protocol requirements specified in
     [ROAMING-REQUIREMENTS].
     
     
     
     
     
     
     
     
     Beadles                 Category: Informational               [Page 4]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     8.1.3.  Attribute-Value Protocol Model
     
     
     Years  of  operational  experience  with  AAA  protocols and NAS's has
     proven that the Attribute-Value protocol model is an optimal represen-
     tation of AAA data.  The protocol SHOULD use an Attribute-Value repre-
     sentation for AAA data.  This document will assume such a model.  Even
     if the AAA protocol does not use this as an on-the-wire data represen-
     tation, Attribute-Value can serve as abstraction  for  discussing  AAA
     information.
     
     Experience  has  also  shown  that  attribute  space  tends to run out
     quickly. In order to provide  room  for  expansion  in  the  attribute
     space, the AAA protocol MUST support a minimum of 64K Attributes (MIN-
     IMUM 16 bits), each with a minimum length of 64K (MINIMUM 16 bits).
     
     
     8.1.3.1.  Attribute Data Types
     
     
     The AAA protocol MUST support simple attribute data  types,  including
     integer,  enumeration,  text string, raw octet series, IP address, and
     date/time. The AAA protocol MUST also provide some support for complex
     structured  data  types.  Wherever IP addresses are carried within the
     AAA protocol, the protocol MUST support  both  IPv4  and  IPv6  [IPV6]
     addresses.  Wherever text information is carried within the AAA proto-
     col, the protocol MUST comply with the IETF Policy on  Character  Sets
     and Languages [RFC 2277].
     
     
     8.1.3.2.  Minimum Set of Attributes
     
     
     At  a minimum, the AAA protocol MUST support, or be easily extended to
     support, the set of attributes supported by RADIUS [RADIUS] and RADIUS
     Accounting  [RADIUS-ACCOUNTING].   If  the  base AAA protocol does not
     support this complete set of attributes, then  an  extension  to  that
     protocol MUST be defined which supports this set.
     
     
     8.1.3.3.  Attribute Extensibility
     
     
     NAS  and  AAA  development is always progressing.  In order to prevent
     the AAA protocol from being a limiting factor in NAS  and  AAA  Server
     development,  the  AAA  protocol MUST provide a built-in extensibility
     mechanism,  which  MUST  include  a  means  for  adding  new  standard
     attribute  extensions.   This MUST include a method for registering or
     requesting extensions through IANA, so that  long-term  working  group
     involvement  is  not required to create new attribute types.  Ideally,
     the AAA protocol SHOULD separate specification of the  transport  from
     specificatoin of the attributes.
     
     The  AAA  protocol  MUST include a means for individual vendors to add
     
     
     
     Beadles                 Category: Informational               [Page 5]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     value through vendor-specific attributes and  SHOULD  include  support
     for vendor-specific data types and vendor-specific commands.
     
     
     8.1.4.  Security Requirements
     
     
     
     8.1.4.1.  Mutual Authentication
     
     
     It  is  poor  security  practice  for a NAS to communicate with an AAA
     server that is not trusted, and vice versa.   The  AAA  protocol  MUST
     provide  mutual authentication between AAA server and NAS.   If a net-
     work operator has deployed  IP  Security  [IPSEC],  the  AAA  protocol
     SHOULD allow its use.
     
     
     8.1.4.2.  Shared Secrets
     
     
     At  a  minimum, the AAA protocol SHOULD support use of a secret shared
     pairwise between each NAS and AAA server to mutually verify  identity.
     This is intended for small-scale deployments.
     
     
     8.1.4.3.  Public Key Security
     
     
     AAA  server/NAS  identity  verification based solely on shared secrets
     can be difficult to deploy properly at large  scale,  and  it  can  be
     tempting  for NAS operators to use a single shared secret (that rarely
     changes) across all NAS's.  This can lead to easy  compromise  of  the
     secret.   Therefore, the AAA protocol MUST also support mutual verifi-
     cation of identity using a  public-key  infrastructure  that  supports
     expiration and revocation of keys.
     
     
     8.1.4.4.  Encryption of Attributes
     
     
     Some  attributes  are more operationally sensitive than others.  Also,
     in a multi-domain scenario, attributes may be inserted by servers from
     different  administrative  domains.  Therefore,  the AAA protocol MUST
     support  selective  encryption  of  attributes  on  an   attribute-by-
     attribute  basis,  even  within  the  same  message.  This requirement
     applies equally to Authentication, Authorization, and Accounting data.
     
     
     8.2.  Authentication and User Security Requirements
     
     
     
     
     
     
     
     Beadles                 Category: Informational               [Page 6]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     8.2.1.  Authentication protocol requirements
     
     
     End users who are requesting network access through a NAS will present
     various types of credentials.  It is the purpose of the  AAA  protocol
     to transport these credentials between the NAS and the AAA server.
     
     
     8.2.1.1.  Bi-directional Authentication
     
     
     The  AAA  protocol  MUST support transport of credentials from the AAA
     server to the NAS for the purpose of mutual (bi-directional) authenti-
     cation  between  the User and the NAS, and between the NAS and the AAA
     server.
     
     
     8.2.1.2.  Dynamic Authentication
     
     
     The AAA protocol MUST support re-authentication at any time during the
     course of a session, initiated from either end of the user session.
     
     
     8.2.1.3.  Multi-phase Authentication
     
     
     The  AAA  protocol  MUST be able to support multi-phase authentication
     methods, including but not limited to support for:
          -Text prompting from the NAS to the user
     
          -A series of binary challenges and responses of arbitrary length
     
          -An authentication failure reason to be transmitted from the  NAS
          to the user
     
          -Callback to a pre-determined phone number
     
     
     8.2.1.4.  Extensible Authentication Types
     
     
     Security  protocol  development  is going on constantly as new threats
     are identified and better cracking  methods  are  developed.   Today's
     secure  authentication  methods  may be proven insecure tomorrow.  The
     AAA protocol MUST provide some support for addition of new authentica-
     tion credential types.  EAP SHOULD be the supported mechanism.
     
     
     8.2.2.  Authentication Attribute Requirements
     
     
     In  addition  to the minimum attribute set, the AAA protocol must sup-
     port and define attributes that provide the following functions:
     
     
     
     Beadles                 Category: Informational               [Page 7]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     8.2.2.1.  PPP Authentication protocols
     
     
     Many authentication protocols are defined within the framework of PPP.
     The  AAA  protocol  MUST  be  able  to act as an intermediary protocol
     between the authenticatee and  the  authenticator  for  the  following
     authentication protocols:
     
          -PPP Password Authentication Protocol [PPP]
     
          -PPP Challenge Handshake Authentication Protocol [CHAP]
     
          -PPP Extensible Authentication Protocol [EAP]
     
     
     8.2.2.2.  User Identitification
     
     
     The  following are common types of credentials used for user identifi-
     cation.  The AAA protocol MUST be able to carry the following types of
     identity credentials:
          -A user name in the form of a Network Access Identifier [NAI].
     
          -An  Extensible  Authentication  Protocol  [EAP] Identity Request
          Type packet.
     
          -Telephony dialing information such as Dialed Number  Identifica-
          tion Service (DNIS) and Caller ID.
     If  a  particular type of identity credential is not needed for a par-
     ticular user session, the AAA protocol MUST  NOT  require  that  dummy
     credentials  be  filled  in.   That  is, the AAA protocol MUST support
     identification without authentication (and vice versa).
     
     
     8.2.2.3.  Authentication Credentials
     
     
     The following are common types of credentials used for authentication.
     The  AAA protocol MUST be able to carry the following types of authen-
     ticating credentials at a minimum:
          -A secret or password.
     
          -A response to a challenge presented by the NAS to the user
     
          -A one-time password
     
          -An X.509 digital certificate [X.509]
     
          -A Kerberos v5 ticket [KERBEROS]
     
     
     
     
     
     
     
     
     Beadles                 Category: Informational               [Page 8]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     8.2.3.  Authentication Protocol Security Requirements
     
     
     
     8.2.3.1.  End-to-End Hiding of Credentials
     
     
     Where passwords are used as authentication credentials, the AAA proto-
     col MUST provide a secure means of hiding the password from end to end
     of the AAA conversation, or directly  perform  end-to-end  authentica-
     tion.   Where challenge/response mechanisms are used, the AAA protocol
     MUST also prevent against replay attacks.
     
     
     8.3.  Authorization, Policy, and Resource management
     
     
     
     8.3.1.  Authorization Protocol Requirements
     
     
     In all cases, the protocol MUST specify that authorization  data  sent
     from  the  NAS  to  the AAA server is to be regarded as information or
     "hints", and not directives.   The AAA protocol MUST  be  designed  so
     that  the  AAA server makes all final authorization decisions and does
     not depend on a certain state being expected by the NAS.
     
     
     8.3.1.1.  Dynamic Authorization
     
     
     The AAA protocol MUST support dynamic  re-authorization  at  any  time
     during  a  user  session.   This  re-authorization may be initiated in
     either  direction.   This  dynamic  re-authorization  capability  MUST
     include  the  capability  to  request  a  NAS  to disconnect a user on
     demand.
     
     
     8.3.1.2.  Resource Management
     
     
     Resource management MUST be supported on demand  by  the  NAS  or  AAA
     Server at any time during the course of a user session.
     
     
     8.3.2.  Authorization Attribute Requirements
     
     
     
     8.3.2.1.  Authorization Attribute Requirements - Access Restrictions
     
     
     The  AAA protocol serves as a primary means of gathering data used for
     making Policy  decisions  for  network  access.   Therefore,  the  AAA
     
     
     
     Beadles                 Category: Informational               [Page 9]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     protocol  MUST  allow network operators to make policy decisions based
     on the following parameters:
     
          -Time/day restrictions.  The AAA protocol MUST be able to provide
          an  unambiguous  time  stamp,  NAS time zone indication, and date
          indication to the AAA server in the Authorization information.
     
          -Location restrictions:  The AAA protocol MUST be able to provide
          an  unambiguous  location code that reflects the geographic loca-
          tion of the NAS (not the user).  Note that this is not  the  same
          type of thing as either the dialing or dialed station.
     
          -Dialing  restrictions:  The AAA protocol MUST be able to provide
          accurate dialed and dialing station indications.
     
          -Concurrent login limitations:  The AAA protocol  MUST  allow  an
          AAA  Server  to  limit  concurrent logins by a particular user or
          group of users.  This mechanism does not need  to  be  explicitly
          built  into  the  AAA protocol, but the AAA protocol must provide
          sufficient authorization information for an AAA  server  to  make
          that determination through an out-of-band mechanism.
     
     
     8.3.2.2.   Authorization  Attribute  Requirements - Authorization Pro-
     files
     
     
     The AAA protocol is used to enforce policy at the  NAS.   Essentially,
     on  granting  of access, a particular access profile is applied to the
     user's session.  The AAA protocol MUST at a minimum provide a means of
     applying profiles containing the following types of information:
     
          -IP  Address assignment: The AAA protocol MUST provide a means of
          assigning an IPv4 or IPv6 address to an incoming user.
     
          -Protocol Filter application:  The AAA protocol  MUST  provide  a
          means of applying IP protocol filters to user sessions.  Two dif-
          ferent methods MUST be supported.
     
          First, the AAA protocol MUST provide a means of selecting a  pro-
          tocol  filter  by reference to an identifier, with the details of
          the filter action being specified out of band.  The AAA  protocol
          MAY define this out-of-band reference mechanism.
     
          Second, the AAA protocol MUST provide a means of passing a proto-
          col filter by value.  This means explicit passing  of  pass/block
          information  by address range, TCP/UDP port number, and IP proto-
          col number at a minimum.
     
          -Compulsory Tunneling:  The AAA protocol MUST provide a means  of
          directing  a NAS to build a tunnel or tunnels to a specified end-
          point.  It MUST support creation of multiple simultaneous tunnels
          in  a  specified  order.   The protocol MUST allow, at a minimum,
          specification of the tunnel endpoints, tunneling  protocol  type,
     
     
     
     Beadles                 Category: Informational              [Page 10]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
          underlying  tunnel  media type, and tunnel authentication creden-
          tials (if required by the tunnel type).  The  AAA  protocol  MUST
          support  at  least the creation of tunnels using the L2TP [L2TP],
          ESP [ESP], and AH [AH]  protocols.   The  protocol  MUST  provide
          means of adding new tunnel types as they are standardized.
     
          -Routing:   The  AAA protocol MUST provide a means of assigning a
          particular static route to an incoming user session.
     
          -Expirations/timeouts:  The AAA protocol MUST provide a means  of
          communication  session expiration information to a NAS.  Types of
          expirations that MUST be supported are:  total session time, idle
          time, total bytes transmitted, and total bytes received.
     
          -Quality  of  Service:   The AAA protocol MUST provide a means of
          applying Quality of Service parameters to  individual  user  ses-
          sions.
     
     
     8.3.2.3.  Resource Management Requirements
     
     
     The AAA protocol is one means for network operators to perform manage-
     ment of network resources consumed by users.   However,  it  has  been
     difficult  to  perform resource management on NAS's with existing SNMP
     implementations, which are often used for this purpose.  The AAA  pro-
     tocol  MUST  support transmission of large amounts of data in order to
     support resource management on  large-scale  NAS's  providing  complex
     user  services.   The  AAA protocol MUST provide a means of collecting
     resource state information, and controlling  resource  allocation  for
     the following types of network resources.
     
     
          -Network  bandwidth  usage  per user session, including multilink
          sessions.
     
          -Access port usage by users, including concurrent usage and usage
          pools.
     
          -Connect time for individual users.
     
          -IP Addresses and pool utilization by users.
     
          -Compulsory tunnel limits for users.
     
     
     8.3.3.  Authorization Protocol Security Requirements
     
     
     
     8.3.3.1.  Security of Compulsory Tunnel Credentials
     
     
     When  an AAA protocol passes a set of credentials that will be used to
     
     
     
     Beadles                 Category: Informational              [Page 11]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     authenticate compulsory tunnels, the AAA protocol MUST provide a means
     of securing these credentials from end to end of the AAA conversation.
     The AAA protocol MUST also provide protection against  replay  attacks
     in this situation.
     
     
     8.4.  Accounting and Auditing Requirements
     
     
     
     8.4.1.  Accounting Protocol Requirements
     
     
     
     8.4.1.1.  Guaranteed Delivery
     
     
     The accounting and auditing functions of the AAA protocol are used for
     network planning, resource management,  policy  decisions,  and  other
     functions  that  require  accurate  knowledge of the state of the NAS.
     NAS operators need to be able to engineer their network usage measure-
     ment  systems  to  a predictable level of accuracy.  Therefore, an AAA
     protocol MUST provide a means of  guaranteed  delivery  of  accounting
     information  between  the  NAS  and  the AAA Server(s).  Note that the
     requirement for guaranteed delivery is not only a protocol requirement
     -  NAS's  might  be required to implement certain practices (e.g. non-
     volatile storage of accounting data) in order  to  support  guaranteed
     delivery.
     
     
     8.4.1.2.  Real Time Accounting
     
     
     NAS  operators  often require a real time view onto the status of ses-
     sions served by a NAS.  Therefore, the AAA protocol MUST support real-
     time  delivery  of  accounting and auditing information.  In this con-
     text, real time is defined as accounting information  delivery  begin-
     ning within one second of the triggering event.
     
     
     8.4.1.3.  Batch Accounting
     
     
     The AAA protocol SHOULD also support delivery of stored accounting and
     auditing information in batches (non-real time).
     
     
     8.4.1.4.  Accounting Time Stamps
     
     
     There may be delays associated with the delivery of accounting  infor-
     mation.   The NAS operator will desire to know the time an event actu-
     ally occurred, rather than simply the time when  notification  of  the
     event  was  received.   Therefore,  the  AAA  protocol  MUST  carry an
     
     
     
     Beadles                 Category: Informational              [Page 12]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     unambiguous time stamp associated with each  accounting  event.   This
     time  stamp  MUST  be unambiguous with regard to time zone.  Note that
     this assumes that the  NAS  has  access  to  a  correct  time  source.
     
     
     8.4.1.5.  Accounting Events
     
     
     At a minimum, the AAA protocol MUST  support  delivery  of  accounting
     information triggered by the following events:
          -Start of a user session
     
          -End of a user session
     
          -Expiration  of  a predetermined repeating time interval during a
          user session.  The AAA protocol MUST provide a means for the  AAA
          server  to  request  that a NAS use a certain interval accounting
          time.
     
          -Dynamic  re-authorization  during  a  user  session  (e.g.,  new
          resources being delivered to the user)
     
          -Dynamic re-authentication during a user session
     
     
     8.4.1.6.  On-demand Accounting
     
     
     NAS  operators  need  to  maintain an accurate view onto the status of
     sessions served by a NAS, even  through  failure  of  the  NA  or  AAA
     server.   Therefore, the AAA protocol MUST support a means of request-
     ing current session state and accounting from the NAS on demand.   The
     intention is to provide for recovery if, for whatever reason, the nor-
     mal flow of accounting data is interrupted.
     
     
     8.4.2.  Accounting attribute requirements
     
     
     At a minimum, the AAA protocol MUST support delivery of the  following
     types of accounting/auditing data:
          -All parameters used to authenticate a session.
     
          -Details  of  the  authorization  profile that was applied to the
          session.
     
          -The duration of the session.
     
          -The cumulative number of bytes sent by the user during the  ses-
          sion.
     
          -The  cumulative  number of bytes received by the user during the
          session.
     
     
     
     
     Beadles                 Category: Informational              [Page 13]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
          -The cumulative number of packets sent by  the  user  during  the
          session.
     
          -The cumulative number of packets received by the user during the
          session.
     
          -Details of the access protocol used  during  the  session  (port
          type, connect speeds, etc.)
     
          -Reason for termination of the session.
     
          -Error or diagnostic information on the session.
     
     
     8.4.3.  Accounting Protocol Security Requirements
     
     
     
     8.4.3.1.  Integrity and Confidentiality
     
     
     Note  that  accounting  and  auditing data are operationally sensitive
     information.  The AAA protocol MUST provide a means to assure  end-to-
     end  integrity  of this data.  The AAA protocol SHOULD provide a means
     of assuring the end-to-end confidentiality of this data.
     
     
     8.4.3.2.  Non-repudiation
     
     
     Network operators use accounting data for network  planning,  resource
     management,  and other business-critical functions that require confi-
     dence in the correctness of this data. The AAA protocol SHOULD provide
     a  mechanism  to  ensure that the source and destination of Accounting
     data cannot repudiate this data after transmission.
     
     
     9.  Device Management Protocols
     
     
     This document does not specify any requirements for device  management
     protocols.
     
     
     10.  Acknowledgments
     
     Many  of  the  requirements  in  this document first took form in Glen
     Zorn's "Yet Another  Authentication  Protocol  (YAAP)"  document,  for
     which  grateful acknowledgment is made.  The author would also like to
     thank Bernard Aboba and Pat Calhoun for their contributions.
     
     
     
     
     
     
     
     Beadles                 Category: Informational              [Page 14]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     11.  Security considerations
     
     
     See above for security requirements for the NAS AAA protocol.
     
     Where an AAA architecture spans multiple  domains  of  authority,  AAA
     information  may need to cross trust boundaries.  In this situation, a
     NAS might operate as a shared device that services  multiple  adminis-
     trative domains.  Network operators are advised take this into consid-
     eration when deploying NAS's and AAA Servers.
     
     
     12.  IANA Considerations
     
     
     This document does not directly specify any IANA considerations.  How-
     ever, the following recommendations are made:
     
     Future  development and extension of an AAA protocol will be made much
     easier if new attributes and values can  be  requested  or  registered
     directly  through  IANA,  rather  than through an IETF Standardization
     process.
     
     The AAA protocol might use  enumerated  values  for  some  attributes,
     which  enumerate already-defined IANA types (such as protocol number).
     In these cases, the AAA protocol SHOULD use the IANA assigned  numbers
     as the enumerated values.
     
     
     
     13.  References
     
     
     [KEYWORDS]  S.  Bradner.    "Key  words  for  use  in RFCs to Indicate
     Requirement Levels."  RFC 2119, Harvard University, March 1997.
     
     [NAS-MODEL] D. Mitton, M. Beadles.  "Network  Access  Server  Require-
     ments Next Generation (NASREQNG) NAS Model."  Work in progress.
     
     [PPPOE]  L. Mamakos et al.  "A Method for Transmitting PPP Over Ether-
     net (PPPoE)."  RFC 2516, UUNET Technologies, Inc., February 1999.
     
     [L2TP] W. M. Townsley, et al.  "Layer Two Tunneling Protocol  (L2TP)."
     RFC 2661, IBM, Cisco, Ascend, Microsoft, August 1999.
     
     [PPP]  W.   Simpson.   "The Point-to-Point Protocol (PPP)."  RFC 1661,
     Daydreamer, July 1994.
     
     [TELNET] J. Postel, J.  Reynolds.   "Telnet  Protocol  Specification."
     STD 8, RFC 854, ISI, May 1983.
     
     [ROUTING-REQUIREMENTS]  F.   Baker.    "Requirements  for IP Version 4
     Routers."  RFC 1812, Cisco Systems, June 1995.
     
     
     
     
     Beadles                 Category: Informational              [Page 15]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     [IPV6] S. Deering, R. Hinden.  "Internet Protocol,  Version  6  (IPv6)
     Specification."  RFC 2460, Cisco, Nokia, December 1998.
     
     [RFC  2277]  H.  Alvestrand.   "IETF Policy on Character Sets and Lan-
     guages."  RFC 2277, UNINETT, January 1998.
     
     [CHAP] W. Simpson.  "PPP Challenge Handshake  Authentication  Protocol
     (CHAP)."  RFC 1994, Daydreamer, August 1996.
     
     [EAP]  L. Blunk, J. Vollbrecht.  "PPP Extensible Authentication Proto-
     col (EAP)."  RFC 2284, Merit Network, Inc., March 1998.
     
     [NAI] B.  Aboba, M. Beadles.  "The Network  Access  Identifier."   RFC
     2486, Microsoft, WorldCom Advanced Networks, January 1999.
     
     [X.509]  ITU-T Recommendation X.509 (1997 E): Information Technology -
     Open Systems Interconnection - The  Directory:  Authentication  Frame-
     work, June 1997.
     
     [KERBEROS]  J.  Kohl, C. Neuman.  "The Kerberos Network Authentication
     Service (V5)."  RFC 1510, Digital Equipment Corporation, ISI,  Septem-
     ber 1993.
     
     [ESP]  S.  Kent,  R.  Atkinson.   "IP  Encapsulating  Security Payload
     (ESP)."  RFC 2406, BBN Corp, @Home Network, November 1998.
     
     [AH] S. Kent, R. Atkinson.   "IP  Authentication  Header  (AH)."   RFC
     2402, BBN Corp, @Home Network, November 1998.
     
     [ROAMING-REQUIREMENTS]  B.  Aboba, G. Zorn.   "Criteria for Evaluating
     Roaming Protocols."  RFC 2477, Microsoft, January 1999.
     
     [RADIUS]
     
     [RADIUS-ACCOUNTING]
     
     
     
     14.  Author's Address
     
     
     
     Mark Anthony Beadles
     UUNET, an MCI WorldCom Company
     5000 Britton Rd.
     Hilliard, OH 43026
     
     Phone: 614-723-1941
     EMail: mbeadles@wcom.net
     
     
     
     
     
     
     
     
     Beadles                 Category: Informational              [Page 16]


     INTERNET-DRAFT        Criteria for NAS Protocols       11 October 1999
     
     
     15.  Full Copyright Statement
     
     
     Copyright (C) The Internet Society (1999).  All Rights Reserved.
     
     This document and translations of it may be copied  and  furnished  to
     others,  and  derivative works that comment on or otherwise explain it
     or assist in its implmentation may be prepared, copied, published  and
     distributed,  in  whole  or  in part, without restriction of any kind,
     provided that the  above  copyright  notice  and  this  paragraph  are
     included on all such copies and derivative works.  However, this docu-
     ment itself may not be modified in any way, such as  by  removing  the
     copyright notice or references to the Internet Society or other Inter-
     net organizations, except as needed  for  the  purpose  of  developing
     Internet standards in which case the procedures for copyrights defined
     in the Internet Standards process must be followed, or as required  to
     translate it into languages other than   English.  The limited permis-
     sions granted above are perpetual and  will  not  be  revoked  by  the
     Internet  Society or its successors or assigns.  This document and the
     information contained herein is provided on an "AS IS" basis  and  THE
     INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
     WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY  WAR-
     RANTY  THAT  THE  USE  OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
     RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS  FOR  A
     PARTICULAR PURPOSE."
     
     
     16.  Expiration Date
     
     
     This  document  is  filed  as <draft-ietf-nasreq-criteria-03.txt>, and
     expires April 11, 2000.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Beadles                 Category: Informational              [Page 17]