doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc2989.txt b/doc/rfc/rfc2989.txt
new file mode 100644
index 0000000..4d50f60
--- /dev/null
+++ b/doc/rfc/rfc2989.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                 B. Aboba, Microsoft
+Request for Comments: 2989   P. Calhoun, S. Glass, Sun Microsystems, Inc.
+Category: Informational T. Hiller, P. McCann, H. Shiino, P. Walsh, Lucent
+                                 G. Zorn, G. Dommety, Cisco Systems, Inc.
+                           C. Perkins, B. Patil, Nokia Telecommunications
+                                   D. Mitton, S. Manning, Nortel Networks
+                                              M. Beadles, SmartPipes Inc.
+                                                         X. Chen, Alcatel
+                         S. Sivalingham, Ericsson Wireless Communications
+                                                       A. Hameed, Fujitsu
+                                                  M. Munson, GTE Wireless
+                                              S. Jacobs, GTE Laboratories
+                            B. Lim, LG Information & Communications, Ltd.
+                                                   B. Hirschman, Motorola
+                                                   R. Hsu, Qualcomm, Inc.
+                         H. Koo, Samsung Telecommunications America, Inc.
+                                                   M. Lipford, Sprint PCS
+                                            E. Campbell, 3Com Corporation
+                                                Y. Xu, Watercove Networks
+                                  S. Baba, Toshiba America Research, Inc.
+                                            E. Jaques, Vodaphone Airtouch
+                                                            November 2000
+
+
+        Criteria for Evaluating AAA Protocols for Network Access
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document represents a summary of Authentication, Authorization,
+   Accounting (AAA) protocol requirements for network access.  In
+   creating this document, inputs were taken from documents produced by
+   the Network Access Server Requirements Next Generation (NASREQ),
+   Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as
+   from TIA 45.6.
+
+
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 1]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   This document summarizes the requirements collected from those
+   sources, separating requirements for authentication, authorization
+   and accounting.  Details on the requirements are available in the
+   original documents.
+
+1.  Introduction
+
+   This document represents a summary of AAA protocol requirements for
+   network access.  In creating this documents, inputs were taken from
+   documents produced by the NASREQ [3], ROAMOPS [2], and MOBILEIP [5]
+   working groups, as well as from TIA 45.6 [4].  This document
+   summarizes the requirements collected from those sources, separating
+   requirements for authentication, authorization and accounting.
+   Details on the requirements are available in the original documents.
+
+1.1.  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 [1].
+
+   Please note that the requirements specified in this document are to
+   be used in evaluating AAA protocol submissions.  As such, the
+   requirements language refers to capabilities of these protocols; the
+   protocol documents will specify whether these features are required,
+   recommended, or optional.  For example, requiring that a protocol
+   support confidentiality is NOT the same thing as requiring that all
+   protocol traffic be encrypted.
+
+   A protocol submission is not compliant if it fails to satisfy one or
+   more of the MUST or MUST NOT requirements for the capabilities that
+   it implements.  A protocol submission that satisfies all the MUST,
+   MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
+   said to be "unconditionally compliant"; one that satisfies all the
+   MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
+   requirements for its protocols is said to be "conditionally
+   compliant."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 2]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+1.2.  Terminology
+
+   Accounting
+             The act of collecting information on resource usage for the
+             purpose of trend analysis, auditing, billing, or cost
+             allocation.
+
+   Administrative Domain
+             An internet, or a collection of networks, computers, and
+             databases under a common administration.  Computer entities
+             operating in a common administration may be assumed to
+             share administratively created security associations.
+
+   Attendant A node designed to provide the service interface between a
+             client and the local domain.
+
+   Authentication
+             The act of verifying a claimed identity, in the form of a
+             pre-existing label from a mutually known name space, as the
+             originator of a message (message authentication) or as the
+             end-point of a channel (entity authentication).
+
+   Authorization
+             The act of determining if a particular right, such as
+             access to some resource, can be granted to the presenter of
+             a particular credential.
+
+   Billing   The act of preparing an invoice.
+
+   Broker    A Broker is an entity that is in a different administrative
+             domain from both the home AAA server and the local ISP, and
+             which provides services, such as facilitating payments
+             between the local ISP and home administrative entities.
+             There are two different types of brokers; proxy and
+             routing.
+
+   Client    A node wishing to obtain service from an attendant within
+             an administrative domain.
+
+   End-to-End
+             End-to-End is the security model that requires that
+             security information be able to traverse, and be validated
+             even when an AAA message is processed by intermediate nodes
+             such as proxies, brokers, etc.
+
+
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 3]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Foreign Domain
+             An administrative domain, visited by a Mobile IP client,
+             and containing the AAA infrastructure needed to carry out
+             the necessary operations enabling Mobile IP registrations.
+             From the point of view of the foreign agent, the foreign
+             domain is the local domain.
+
+   Home Domain
+             An administrative domain, containing the network whose
+             prefix matches that of a mobile node's home address, and
+             containing the AAA infrastructure needed to carry out the
+             necessary operations enabling Mobile IP registrations.
+             From the point of view of the home agent, the home domain
+             is the local domain.
+
+   Hop-by-hop
+             Hop-by-hop is the security model that requires that each
+             direct set of peers in a proxy network share a security
+             association, and the security information does not traverse
+             a AAA entity.
+
+   Inter-domain Accounting
+             Inter-domain accounting is the collection of information on
+             resource usage of an entity within an administrative
+             domain, for use within another administrative domain.  In
+             inter-domain accounting, accounting packets and session
+             records will typically cross administrative boundaries.
+
+   Intra-domain Accounting
+             Intra-domain accounting is the collection of information on
+             resource within an administrative domain, for use within
+             that domain.  In intra-domain accounting, accounting
+             packets and session records typically do not cross
+             administrative boundaries.
+
+   Local Domain
+             An administrative domain containing the AAA infrastructure
+             of immediate interest to a Mobile IP client when it is away
+             from home.
+
+   Proxy     A AAA proxy is an entity that acts as both a client and a
+             server.  When a request is received from a client, the
+             proxy acts as a AAA server.  When the same request needs to
+             be forwarded to another AAA entity, the proxy acts as a AAA
+             client.
+
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 4]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Local Proxy
+             A Local Proxy is a AAA server that satisfies the definition
+             of a Proxy, and exists within the same administrative
+             domain as the network device (e.g., NAS) that issued the
+             AAA request.  Typically, a local proxy will enforce local
+             policies prior to forwarding responses to the network
+             devices, and are generally used to multiplex AAA messages
+             from a large number of network devices.
+
+   Network Access Identifier
+             The Network Access Identifier (NAI) is the userID submitted
+             by the client during network access authentication.  In
+             roaming, the purpose of the NAI is to identify the user as
+             well as to assist in the routing of the authentication
+             request.  The NAI may not necessarily be the same as the
+             user's e-mail address or the user-ID submitted in an
+             application layer authentication.
+
+   Routing Broker
+             A Routing Broker is a AAA entity that satisfies the
+             definition of a Broker, but is NOT in the transmission path
+             of AAA messages between the local ISP and the home domain's
+             AAA servers.  When a request is received by a Routing
+             Broker, information is returned to the AAA requester that
+             includes the information necessary for it to be able to
+             contact the Home AAA server directly.  Certain
+             organizations providing Routing Broker services MAY also
+             act as a Certificate Authority, allowing the Routing Broker
+             to return the certificates necessary for the local ISP and
+             the home AAA servers to communicate securely.
+
+   Non-Proxy Broker
+             A Routing Broker is occasionally referred to as a Non-Proxy
+             Broker.
+
+   Proxy Broker
+             A Proxy Broker is a AAA entity that satisfies the
+             definition of a Broker, and acts as a Transparent Proxy by
+             acting as the forwarding agent for all AAA messages between
+             the local ISP and the home domain's AAA servers.
+
+   Real-time Accounting
+             Real-time accounting involves the processing of information
+             on resource usage within a defined time window.  Time
+             constraints are typically imposed in order to limit
+             financial risk.
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 5]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Roaming Capability
+             Roaming capability can be loosely defined as the ability to
+             use any one of multiple Internet service providers (ISPs),
+             while maintaining a formal, customer-vendor relationship
+             with only one.  Examples of cases where roaming capability
+             might be required include ISP "confederations" and ISP-
+             provided corporate network access support.
+
+   Session record
+             A session record represents a summary of the resource
+             consumption of a user over the entire session.  Accounting
+             gateways creating the session record may do so by
+             processing interim accounting events.
+
+   Transparent Proxy
+             A Transparent Proxy is a AAA server that satisfies the
+             definition of a Proxy, but does not enforce any local
+             policies (meaning that it does not add, delete or modify
+             attributes or modify information within messages it
+             forwards).
+
+2.  Requirements Summary
+
+   The AAA protocol evaluation criteria for network access are
+   summarized below.  For details on the requirements, please consult
+   the documents referenced in the footnotes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 6]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+2.1.  General requirements
+
+   These requirements apply to all aspects of AAA and thus are
+   considered general requirements.
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  General                  | NASREQ  | ROAMOPS | MOBILE  |
+   |  Reqts.                   |         |         |   IP    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Scalability             |    M    |   M     |    M    |
+   |      a                    |   12    |   3     |  30 39  |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Fail-over               |    M    |         |    M    |
+   |      b                    |   12    |         |   31    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Mutual auth             |    M    |         |    M    |
+   |   AAA client/server       |   16    |         |   30    |
+   |      c                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Transmission level      |         |   M     |    S    |
+   |   security                |         |   6     |  31 39  |
+   |      d                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Data object              |    M    |   M     |    M    |
+   |  Confidentiality          |   26    |   6     |   40    |
+   |      e                    |         |         |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Data object              |    M    |   M     |    M    |
+   |  Integrity                |   16    |   6     |  31 39  |
+   |      f                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Certificate transport    |    M    |         |  S/M    |
+   |      g                    |   42    |         |31,33/46 |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Aboba, et al.                Informational                      [Page 7]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Reliable AAA transport   |    M    |         |    M    |
+   |  mechanism                |   22    |         |  31 32  |
+   |      h                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Run Over IPv4           |    M    |   M     |    M    |
+   |                           |   11    |   1     |   33    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Run Over IPv6           |    M    |         |    S    |
+   |                           |   11    |   1     |   47    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Support Proxy and        |    M    |         |    M    |
+   |  Routing Brokers          |   12    |         |  31 39  |
+   |      i                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Auditability             |    S    |         |         |
+   |      j                    |   25    |         |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Dual App and Transport  |         |   O     |     M   |
+   |    Security not required  |         |   6     |    40   |
+   |      k                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Ability to carry         |    M    |         |    S    |
+   |  service-specific attr.   |   43    |         |  31 33  |
+   |      l                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Key
+   M = MUST
+   S = SHOULD
+   O = MAY
+   N = MUST NOT
+   B = SHOULD NOT
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                      [Page 8]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Clarifications
+
+   [a]  The AAA protocol must be capable of supporting millions of users
+        and tens of thousands of simultaneous requests.  The AAA
+        architecture and protocol MUST be capable of supporting tens of
+        thousands of devices, AAA servers, proxies and brokers.
+
+   [b]  In the event of failure to communicate with a given server, the
+        protocol must provide a mechanism to change service to another
+        backup or secondary server.
+
+   [c]  This requirement refers to the ability to support mutual
+        authentication between the AAA client and server.
+
+   [d]  The AAA protocol requires authentication, integrity protection
+        and confidentiality at the transmission layer.  This security
+        model is also referred to as hop-by-hop security, whereas the
+        security is established between two communicating peers.  All of
+        the security is removed when the AAA message is processed by a
+        receiving AAA entity.
+
+   [e]  The AAA protocol requires confidentiality at the object level,
+        where an object consists of one or more attributes.  Object
+        level confidentiality implies that only the target AAA entity
+        for whom the data is ultimately destined may decrypt the data,
+        regardless of the fact that the message may traverse one or more
+        intermediate AAA entities (e.g., proxies, brokers).
+
+   [f]  The AAA protocol requires authentication and integrity
+        protection at the object level, which consists of one or more
+        attributes.  Object level authentication must be persistent
+        across one or more intermediate AAA entity (e.g., proxy, broker,
+        etc), meaning that any AAA entity in a proxy chain may verify
+        the authentication.  This implies that data that is covered by
+        object level security CANNOT be modified by intermediate
+        servers.
+
+   [g]  The AAA protocol MUST be capable of transporting certificates.
+        This requirement is intended as an optimization, in lieu of
+        requiring that an out-of-band protocol be used to fetch
+        certificates.
+
+   [h]  This requirement refers to resilience against packet loss,
+        including:
+
+        1. Hop-by-hop retransmission and fail-over so that reliability
+           does not solely depend on single hop transport
+           retransmission.
+
+
+
+Aboba, et al.                Informational                      [Page 9]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+        2. Control of the retransmission mechanism by the AAA
+           application.
+        3. Acknowledgment by the transport that a message was delivered
+           successfully, separate from message semantics or syntax
+           evaluation.
+        5. Piggy-backing of acknowledgments in AAA messages.
+        6. Timely delivery of AAA responses.
+
+   [i]  In the Mobile IP AAA architecture, brokers can be in the
+        forwarding path, in which case they act as transparent proxies
+        (proxy brokers).  Alternatively, it is also possible to conceive
+        of brokers operating as certifying authorities outside of the
+        forwarding path (routing brokers).
+
+   [j]  An auditable process is one in which it is possible to
+        definitively determine what actions have been performed on AAA
+        packets as they travel from the home AAA server to the network
+        device and back.
+
+   [k]  The AAA protocol MUST allow communication to be secured.
+        However, the AAA protocol MUST also allow an underlying security
+        service (e.g., IP Security) to be used.  When the latter is
+        used, the former MUST NOT be required.
+
+   [l]  The AAA protocol MUST be extensible by third parties (e.g.,
+        other IETF Working Groups), in order to define attributes that
+        are specific to the service being defined.  This requirement
+        simply means that the AAA protocol MUST allow groups other than
+        the AAA WG to define standard attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 10]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+2.2.  Authentication Requirements
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   | Authentication            | NASREQ  | ROAMOPS | MOBILE  |
+   | Reqts.                    |         |         |   IP    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   NAI Support             |    M    |   M     |   S/M   |
+   |      a                    |    9    |   2     |32,34,39/|
+   |                           |         |         |   40    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   CHAP Support            |    M    |   M     |         |
+   |      b                    |   10    |   3     |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   EAP Support             |    M    |   S     |         |
+   |      c                    |   10    |   3     |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   PAP/Clear-Text Support  |    M    |   B     |         |
+   |      d                    |   26    |   3     |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Re-authentication       |    M    |         |    S    |
+   |   on demand               |   17    |         |   33    |
+   |      e                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Authorization Only      |    M    |         |         |
+   |   without Authentication  |    9    |         |         |
+   |      f                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Key
+   M = MUST
+   S = SHOULD
+   O = MAY
+   N = MUST NOT
+   B = SHOULD NOT
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 11]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Clarifications
+
+   [a]  The AAA protocol MUST allow the use of Network Access
+        Identifiers (NAI) [8] to identify users and/or devices.
+
+   [b]  The AAA protocol MUST allow CHAP [20] authentication information
+        to be transported.  This is commonly used by Network Access
+        Servers that request authentication of a PPP user.
+
+   [c]  The AAA protocol MUST allow for Extensible Authentication
+        Protocol (EAP) [14] payload to be transported.  Since some EAP
+        authentication mechanisms require more than one round trip, the
+        AAA protocol must allow for such authentication mechanisms to be
+        used.  The actual EAP authentication mechanism negotiated MUST
+        be transparent to the AAA protocol.  When EAP is used,
+        authentication typically occurs between the user being
+        authenticated and his/her home AAA server.
+
+   [d]  While PAP is deprecated, it is still in widespread use for its
+        original intended purpose, which is support of clear-text
+        passwords.  As a result, a AAA protocol will need to be able to
+        securely transport clear-text passwords.  This includes
+        providing for confidentiality of clear-text passwords traveling
+        over the wire, as well as protecting against disclosure of
+        clear-text passwords to proxies in the forwarding path.
+
+   [e]  The AAA protocol MUST allow for a user to be re-authenticated
+        on-demand.  The protocol MUST allow for this event to be
+        triggered by either the user, access device (AAA client), or the
+        home or visited AAA server.
+
+   [f]  The AAA protocol MUST NOT require that credentials of the user
+        be provided during authorization.  The AAA protocol supports
+        authorization by identification or assertion only.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 12]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+2.3.  Authorization Requirements
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   | Authorization             | NASREQ  | ROAMOPS | MOBILE  |
+   | Reqts.                    |         |         |   IP    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Static and Dynamic      |         |         |         |
+   |   IPv4/6 Address Assign.  |    M    |   M     |   M     |
+   |      a                    |   11    |   5     | 32 36   |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   RADIUS gateway          |    M    |   M     |    M    |
+   |   capability              |   44    |   3     |    45   |
+   |      b                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Reject                  |    M    |   M     |   M     |
+   |   capability              |   12    |   4     |  39     |
+   |      c                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Precludes layer 2       |    N    |   N     |         |
+   |   tunneling               |   11    |   5     |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Re-Authorization on      |    M    |         |   S     |
+   |   demand                  |   18    |         | 30 33   |
+   |      d                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Support for Access Rules,|    M    |         |         |
+   |  Restrictions, Filters    | 11, 19  |         |         |
+   |      e                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  State Reconciliation     |    M    |         |         |
+   |      f                    |   20    |         |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Unsolicited Disconnect   |    M    |         |         |
+   |      g                    |   18    |         |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Aboba, et al.                Informational                     [Page 13]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Key
+   M = MUST
+   S = SHOULD
+   O = MAY
+   N = MUST NOT
+   B = SHOULD NOT
+
+   Clarifications
+
+   [a]  The AAA protocol MUST allow a server to provide a static or
+        dynamic address during the authorization phase of a user and/or
+        device.  The address assigned MUST be either of type IPv4 or
+        IPv6.  If both the client AND the server are aware of a pre-
+        configured address, then it is considered static.  Anything else
+        is dynamic.
+
+   [b]  This requirement refers to the ability of a new AAA protocol be
+        sufficiently compatible with the large installed base of
+        attributes for existing approaches (RADIUS), such that a server
+        implementation could speak both protocols, or translate between
+        them.
+
+   [c]  This requirement refers to the ability of a proxy broker to deny
+        access without forwarding the access request to the AAA server,
+        or to deny access after receiving an access accept from the AAA
+        server.
+
+   [d]  This requirement refers to the ability of the AAA client or
+        server to trigger re-authorization, or to the ability of the
+        server to send updated authorization information to the device,
+        such as "stop service."  Authorization can allow for a time
+        period, then additional authorization can be sought to continue.
+        A server can initially authorize a user to connect and receive
+        services, but later decide the user is no longer allowed use of
+        the service, for example after N minutes.  Authorizations can
+        have a time limit.  Re-authorization does not necessarily imply
+        re-authentication.
+
+   [e]  This requirement refers to the ability to of the protocol to
+        describe access operational limitations and authorization
+        restrictions to usage to the NAS which includes (but is not
+        limited to):
+
+        1. Session expirations and Idle Timeouts
+        2. Packet filters
+        3. Static routes
+        4. QoS parameters
+
+
+
+
+Aboba, et al.                Informational                     [Page 14]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   [f]  This requirement refers to the ability of the NAS to use the AAA
+        server to manage resource allocation state.  This capability can
+        assist with, but it is not synonymous with, simultaneous user
+        login control, port usage limitations, or IP address pooling.
+
+        The design must provide for recovery from data loss due to a
+        variety of faults, including NAS and AAA server reboots, and
+        NAS/AAA server communication outages, and MUST be independent of
+        the accounting stream.  The granularity of the recovery of state
+        information after an outage may be on the order of a fraction of
+        a minute.  In order to provide for state recovery, explicit
+        session/resource status and update and disconnect messages will
+        be required.
+
+        Because of potential multi-domain issues, only systems that
+        allocate or use a resource should track its state.
+
+   [g]  This requirement refers to the ability of the AAA server to
+        request the NAS to disconnect an active session for
+        authorization policy reasons.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 15]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+2.4.  Accounting Requirements
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   | Accounting                | NASREQ  | ROAMOPS | MOBILE  |
+   | Reqts.                    |         |         |   IP    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Real-time accounting    |    M    |    M    |   M     |
+   |      a                    |   14    |    7    |  31     |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Mandatory Compact       |         |    M    |         |
+   |    Encoding               |         |    7    |         |
+   |      b                    |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Accounting Record       |         |    M    |   M     |
+   |    Extensibility          |         |    7    |  33     |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Batch Accounting        |    S    |         |         |
+   |      c                    |   21    |         |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Guaranteed Delivery     |    M    |         |    M    |
+   |      d                    |   22    |         |   31    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |   Accounting Time Stamps  |    M    |         |    M    |
+   |      e                    |   23    |         |   40    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Dynamic Accounting       |    M    |         |         |
+   |      f                    |   48    |         |         |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 16]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Key
+   M = MUST
+   S = SHOULD
+   O = MAY
+   N = MUST NOT
+   B = SHOULD NOT
+
+   Clarifications
+
+   [a]  This requirement may be loosely defined as reporting
+        synchronously with events.  Typically the time window is on the
+        order of seconds, not milliseconds.
+
+   [b]  The AAA protocol's Accounting data format MUST NOT be bloated,
+        imposing a large overhead for one or more accounting data
+        elements.
+
+   [c]  This requirement refers to the ability to buffer or store
+        multiple accounting records, and send them together at some
+        later time.
+
+   [d]  This is an application layer acknowledgment.  This is sent when
+        the receiving server is willing to take responsibility for the
+        message data.
+
+   [e]  This requirement refers to the ability to reflect the time of
+        occurrence of events such as log-on, logoff, authentication,
+        authorization and interim accounting.  It also implies the
+        ability to provide for unambiguous time-stamps.
+
+   [f]  This requirement refers to the ability to account for dynamic
+        authentication and authorization.  To support this, there can be
+        multiple accounting records for a single session.
+
+2.5.  Unique Mobile IP requirements
+
+   In addition to the above requirements, Mobile IP also has the
+   following additional requirements:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 17]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Encoding of Mobile IP    |         |         |   M     |
+   |  registration messages    |         |         |   33    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Firewall friendly        |         |         |   M     |
+   |      a                    |         |         |   35    |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           |         |         |         |
+   |  Allocation of local Home |         |         |   S/M   |
+   |  agent                    |         |         |  37/41  |
+   |                           |         |         |         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Key
+   M = MUST
+   S = SHOULD
+   O = MAY
+   N = MUST NOT
+   B = SHOULD NOT
+
+   Clarifications
+
+   [a]  A firewall friendly protocol is one which is designed to
+        accommodate a firewall acting as a proxy.  For example, this
+        would permit a Home Agent AAA server situated behind a firewall
+        to be reachable from the Internet for the purposes of providing
+        AAA services to a Mobile IP Foreign Agent.
+
+        Notes
+
+        [1] Section 4.2.1 of [2]
+        [2] Section 4.2.2 of [2]. Also see [8].
+        [3] Section 4.2.3 of [2]. Also see [14].
+        [4] Section 4.2.4 of [2].
+        [5] Section 4.2.5 of [2].
+        [6] Section 4.2.6 of [2].
+        [7] Section 4.3 of [2].
+        [8] Section 6 of [3].  Also see [6].
+        [9] Section 8.2.2.2 of [3].  Also see [14].
+        [10] Section 8.2.2.1 of [3].  Also see [14].
+        [11] Section 8.3.2.2 of [3].  Also see [7].
+        [12] Section 8.1.1 of [3].
+        [13] Section 8.1.4.4 of [3].
+        [14] Section 8.4.1.2 of [3].
+
+
+
+Aboba, et al.                Informational                     [Page 18]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+        [15] Section 8.4.2 of [3].
+        [16] Section 8.1.3 of [3].
+        [17] Section 8.2.1.2 of [3].
+        [18] Section 8.3.1.1 of [3].
+        [19] Section 8.3.2.1 of [3].  Also see [7].
+        [20] Section 8.3.2.3 of [3].  Also see [6], [7].
+        [21] Section 8.4.1.3 of [3].
+        [22] Section 8.4.1.1 of [3].
+        [23] Section 8.4.1.4 of [3].
+        [24] Section 8.4.3.1 of [3].
+        [25] Section 8.4.3.2 of [3].
+        [26] Section 8.2.3.1 of [3].
+        [27] Section 8.3.3.1 of [3].
+        [28] Section 8.1.4.1 of [3].
+        [29] Refer [15]
+        [30] Section 3 of [5]
+        [31] Section 3.1 of [5]
+        [32] Section 4 of [5]
+        [33] Section 5 of [5]
+        [34] Section 5.1 of [5]
+        [35] Section 5.2 of [5]
+        [36] Section 5.3 of [5]
+        [37] Section 5.4 of [5]
+        [38] Section 5.5 of [5]
+        [39] Section 6 of [5]
+        [40] Section 5.1 of [4]
+        [41] Section 5.2.2 of [4]
+        [42] Section 8.2.2.2 of [3]
+        [43] Section 8.1.2.3 of [3]
+        [44] Section 8.1.2.2 of [3]
+        [45] Section 5.4 of [4]
+        [46] Section 7 of [4]
+        [47] Section 8 of [5]
+        [48] Section 8.4.1.5 of [3]
+
+3.  References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
+        Protocols", RFC 2477, January 1999.
+
+   [3]  Beadles, M. and D. Mitton, "Criteria for Evaluating Network
+        Access Server Protocols", Work in Progress.
+
+   [4]  Hiller, T., et al., "Cdma2000 Wireless Data Requirements for
+        AAA", Work in Progress.
+
+
+
+Aboba, et al.                Informational                     [Page 19]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   [5]  Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
+        Authentication, Authorization, and Accounting Requirements", RFC
+        2977, October 2000.
+
+   [6]  Mitton, D., Beadles, M., "Network Access Server Requirements
+        Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
+
+   [7]  Mitton, D., "Network Access Server Requirements: Extended RADIUS
+        Practices", RFC 2882, July 2000.
+
+   [8]  Aboba,  B. and M. Beadles, "The Network Access Identifier", RFC
+        2486, January 1999.
+
+   [9]  Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2865, June
+        2000.
+
+   [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [11] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+        51, RFC 1661, July 1994.
+
+   [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
+        "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
+
+   [13] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
+        1994.
+
+   [14] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+        Protocol (EAP)", RFC 2284, March 1998.
+
+   [15] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
+        PPP IPCP", RFC 2290, Feb 1998
+
+   [16] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
+        Extension for IPv4", RFC 2794, March 2000.
+
+   [17] Perkins, C., "IP Mobility Support", RFC 2002, Oct 1996.
+
+   [18] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
+        Progress.
+
+   [19] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+        Implementation in Roaming", RFC 2607, June 1999.
+
+   [20] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+        (CHAP)", RFC 1994, August 1996.
+
+
+
+
+Aboba, et al.                Informational                     [Page 20]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+4.  Security Considerations
+
+   This document, being a requirements document, does not have any
+   security concerns.  The security requirements on protocols to be
+   evaluated using this document are described in the referenced
+   documents.
+
+5.  IANA Considerations
+
+   This memo does not create any new number spaces for IANA
+   administration.
+
+6.  Acknowledgments
+
+   Thanks to the members of the Mobile IP, AAA, and NASREQ working
+   groups who have discussed and commented on these requirements. We
+   would also like to thank the members of the AAA evaluation team, Mike
+   St. Johns, Barney Wolf, Mark Stevens, David Nelson, Dave Mitton,
+   Basavaraj Patil and Stuart Barkley for their thorough review of this
+   document.
+
+7.  Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425-936-6605
+   Fax:   +1 425-936-7329
+   EMail: bernarda@microsoft.com
+
+
+   Pat R. Calhoun
+   Network and Security Research Center, Sun Labs
+   Sun Microsystems, Inc.
+   15 Network Circle
+   Menlo Park, CA 94025
+
+   Phone: +1 650-786-7733
+   EMail: pcalhoun@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 21]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Steven M. Glass
+   Sun Microsystems
+   1 Network Drive
+   Burlington, MA 01845
+
+   Phone: +1 781-442-0504
+   Fax:   +1 781-442-1677
+   EMail: steven.glass@sun.com
+
+
+   Tom Hiller
+   Wireless Data Standards & Architectures
+   Lucent Technologies
+   263 Shuman Drive
+   Room 1HP2F-218
+   Naperville, IL 60563
+
+   Phone: +1 630-976-7673
+   EMail: tom.hiller@lucent.com
+
+
+   Peter J. McCann
+   Lucent Technologies
+   Rm 2Z-305
+   263 Shuman Blvd
+   Naperville, IL  60566
+
+   Phone: +1 630-713 9359
+   EMail: mccap@lucent.com
+
+
+   Hajime Shiino
+   Lucent Technologies Japan Ltd.
+   25 Mori Bldg. 1-4-30 Roppongi,
+   Minato-ku Tokyo
+   Japan
+
+   Phone: +81-3-5561-3695
+   EMail: hshiino@lucent.com
+
+   Glen Zorn
+   Cisco Systems, Inc.
+   500 108th Avenue N.E., Suite 500
+   Bellevue, WA 98004
+
+   Phone: +1 425-468-0955
+   EMail: gwz@cisco.com
+
+
+
+
+Aboba, et al.                Informational                     [Page 22]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Gopal Dommety
+   IOS Network Protocols
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+
+   Phone: +1 408-525-1404
+   Fax:   +1 408-526-4952
+   EMail: gdommety@cisco.com
+
+
+   Charles E. Perkins
+   Communications Systems Lab
+   Nokia Research Center
+   313 Fairchild Drive
+   Mountain View, CA
+
+   Phone: +1 650-625-2986
+   Fax:   +1-650-625-2502
+   EMail: charliep@iprg.nokia.com
+
+
+   Basavaraj Patil
+   Nokia Networks
+   6000 Connection Dr.
+   Irving, TX 75039
+
+   Phone: +1 972-894-6709
+   Fax:   +1 972-894-5349
+   EMail: Basavaraj.Patil@nokia.com
+
+
+   David Mitton
+   Nortel Networks
+   880 Technology Park Drive
+   Billerica, MA 01821
+
+   Phone: +1 978-288-4570
+   EMail: dmitton@nortelnetworks.com
+
+
+   Serge Manning
+   Nortel Networks
+   2201 Lakeside Blvd
+   Richardson, TX  75082-4399
+
+   Phone: +1 972-684-7277
+   EMail: smanning@nortelnetworks.com
+
+
+
+Aboba, et al.                Informational                     [Page 23]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Mark Anthony Beadles
+   SmartPipes, Inc.
+   565 Metro Place South
+   Suite 300
+   Dublin, OH 43017
+
+   Phone: +1 614-923-5657
+   EMail: mbeadles@smartpipes.com
+
+
+   Pat Walsh
+   Lucent Technologies
+   263 Shuman Blvd.
+   1F-545
+   Naperville, IL
+
+   Phone: +1 630-713-5063
+   EMail: walshp@lucent.com
+
+
+   Xing Chen
+   Alcatel USA
+   1000 Coit Road
+   Plano, TX 75075
+
+   Phone: +1 972-519-4142
+   Fax:   +1 972-519-3300
+   EMail: xing.chen@usa.alcatel.com
+
+
+   Sanjeevan Sivalingham
+   Ericsson Wireless Communications Inc.,
+   Rm Q-356C
+   6455 Lusk Blvd
+   San Diego, CA 92126
+
+   Phone: +1 858-332-5670
+   EMail: s.sivalingham@ericsson.com
+
+
+   Alan Hameed
+   Fujitsu
+   2801 Telecom Parkway
+   Richardson, TX 75082
+
+   Phone: +1 972-479-2089
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 24]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Mark Munson
+   GTE Wireless
+   One GTE Place
+   Alpharetta, GA  30004
+
+   Phone: +1 678-339-4439
+   EMail: mmunson@mobilnet.gte.com
+
+
+   Stuart Jacobs
+   Secure Systems Department
+   GTE Laboratories
+   40 Sylvan Road,
+   Waltham, MA 02451-1128
+
+   Phone: +1 781-466-3076
+   Fax:   +1 781-466-2838
+   EMail: sjacobs@gte.com
+
+
+   Byung-Keun Lim
+   LG Electronics, Ltd.
+   533, Hogye-dong, Dongan-ku, Anyang-shi,
+   Kyungki-do,431-080
+   Korea
+
+   Phone: +82-31-450-7199
+   Fax:   +82-31-450-7050
+   EMail: bklim@lgic.co.kr
+
+
+   Brent Hirschman
+   1501 Shure Dr.
+   Arlington Hieghts, IL 60006
+
+   Phone: +1 847-632-1563
+   EMail: qa4053@email.mot.com
+
+
+   Raymond T. Hsu
+   Qualcomm Inc.
+   6455 Lusk Blvd.
+   San Diego, CA 92121
+
+   Phone: +1 619-651-3623
+   EMail: rhsu@qualcomm.com
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 25]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Haeng S. Koo
+   Samsung Telecommunications America, Inc.
+   1130 E. Arapaho Road
+   Richardson, TX 75081
+
+   Phone: +1 972-761-7755
+   EMail: hskoo@sta.samsung.com
+
+
+   Mark A. Lipford
+   Sprint PCS
+   8001 College Blvd.; Suite 210
+   Overland Park, KS  66210
+
+   Phone: +1 913-664-8335
+   EMail: mlipfo01@sprintspectrum.com
+
+
+   Ed Campbell
+   3Com Corporation
+   1800 W. Central Rd.
+   Mount Prospect, IL 60056
+
+   Phone: +1 847-342-6769
+   EMail: ed_campbell@3com.com
+
+
+   Name: Yingchun Xu
+   WaterCove Networks
+   One Century Centre, Suite 550
+   1750 E. Golf Road
+   Schaumburg, IL
+
+   Phone: +1 847-477-9280
+   EMail: yxu@watercove.com
+
+
+   Shinichi Baba
+   Toshiba America Research, Inc.
+   PO Box 136,
+   Convent Station, NJ 07961-0136
+
+   Phone: +1 973-829-4795
+   EMail: sbaba@tari.toshiba.com
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 26]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+   Eric Jaques
+   Vodafone AirTouch
+   2999 Oak Road, MS-750
+   Walnut Creek, CA 94596
+
+   Phone: +1 925-279-6142
+   EMail: ejaques@akamail.com
+
+8.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 27]
+
+RFC 2989         Network Access AAA Evaluation Criteria    November 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 implementation 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
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet 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 permissions 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 WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Informational                     [Page 28]
+