RFC 2989 (rfc2989) - Page 2 of 28
Criteria for Evaluating AAA Protocols for Network Access
Alternative Format: Original Text Document
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
