rfc2989.txt

RFC 的详细文档！

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 |
   |                           |         |         |         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+