Criteria for Evaluating AAA Protocols for Network Access
RFC 2989

Document Type RFC - Informational (November 2000; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2989 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.
Show full document text