AAA B. Natale Internet Draft ACE*COMM <draft-natale-aaa-snmpv3-comp-00.txt> June 2000 Comparison of SNMPv3 Against AAA Network Access Requirements 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 documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 material 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. 2. Abstract This document presents an overview of SNMPv3 compliance with the AAA protocol requirements for network access as stipulated in the "Network Access AAA Evaluation Criteria" Internet Draft dated April 26, 2000 [1]. SNMPv3 protocol features and capabilities directly support many of the AAA requirements. In addition, the more sophisticated management model (see Section 5, below) now underlying SNMP -- which has evolved from the original model introduced in the late 1980s under the guidance of extensive use in the field -- enables the design, development, and deployment of more sophisticated management applications geared to the overall body of AAA protocol requirements (or sub-sets thereof). 3. Change history 00 revision: Initial version, published for quick review and comment by interested parties to meet the AAA response deadline of June 1, 2000. 4. Introduction This document presents an overview of SNMPv3 compliance with the AAA protocol requirements for network access as stipulated in [1]. Natale Expires December 2000 1 INTERNET-DRAFT SNMPv3 for AAA June 2000 SNMPv3 protocol features and capabilities directly support many of the AAA requirements. In addition, the contemporary management model (see Section 5, below) now underlying SNMP -- which has evolved from the original model introduced in the late 1980s under the guidance of extensive use in the field -- enables the design, development, and deployment of more sophisticated management applications geared to the overall body of AAA protocol requirements (or sub-sets thereof). 4.1. Requirements language In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 4.2. Terminology This document describes the compliance status of version 3 of the Simple Network Management Protocol ("SNMPv3") with respect to the known AAA requirements as stated in [1] (aka [ACCT-RQTS], with relevant elaborations in [2] (aka [ROAMOPS]), [3] (aka [NASREQ]), [4], and [5] (aka [MOBILE IP]). SNMPv3 is defined by the following documents: RFC2570, "Introduction to Version 3 of the Internet-standard Network Management Framework". [6] RFC2571, "An Architecture for Describing SNMP Management Frameworks". [7] RFC2572, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)". [8] RFC2573, "SNMP Applications". [9] (aka [APPS]) RFC2574, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)". [10] (aka [USM]) RFC2575, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)". [11] (aka [VACM]) RFC2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework". [12] SNMPv3 is a protocol with which management entities communicate with each other about management operations performed on managed objects. Natale Expires December 2000 2 INTERNET-DRAFT SNMPv3 for AAA June 2000 The managed objects available for the set of management operations supported between a given pair of SNMPv3 entities logically reside in a virtual information store known as a management information base (MIB). The logical structure of the data store and the relevant attributes of the managed objects supported by it are defined using an adapted subset of the OSI ASN.1 specification language known as the Structure of Management Information (SMI). The current version of the SMI is version 2 ("SMIv2"). This is the version referenced by this document. SMIv2 is defined by the following documents: RFC2578, "Structure of Management Information Version 2 (SMIv2)". [13] RFC2579, "Textual Conventions for SMIv2". [14] RFC2580, "Conformance Statements for SMIv2". [15] For the purposes of this document, "SNMPv3" is intended to subsume "SMIv2". Furthermore, any otherwise unqualified references to "SNMP" in this document are intended to refer to "SNMPv3" only. That is, references to earlier versions of SNMP (i.e., SNMPv1 or SNMPv2c), will be made explicit by saying "SNMPv1" or "SNMPv2c", as the case may be. This is also true for the term "SMI" and its previous version, "SMIv1". The SNMPv3 AAA protocol submission consists of the ten RFCs identified above in this section. 5. Compliance Summary The compliance information provided in the following sections of this document maps directly to the tables of requirements presented in [1]. As a result, this compliance information represents a summary view of both AAA requirements statements and the corresponding SNMPv3 compliance statements. Substantial additional detail on both sides of the equations will likely be needed to form a precise operational understanding of the requirements and the role that SNMPv3 plays in satisfying them. However, the goal of this document is merely to establish the viability, validity, and value of SNMPv3 as a constituent element of an overall Internet standards based approach to meeting the stated AAA requirements. That is, the technologies and operations encompassed by the AAA triad -- authentication, authorization, and accounting -- cover a large span of multi-dimensional "problem space". Also, some of the stated requirements (aka, "evaluation criteria") seem to apply at a protocol level, while others seem to apply to a service level (i.e., a level which uses a protocol...e.g., as an SNMP "engine" uses the SNMPv3 protocol) and others yet to an application level (i.e., a Natale Expires December 2000 3 INTERNET-DRAFT SNMPv3 for AAA June 2000 level which uses such services...e.g., an SNMPv3 command generator entity). Therefore, it may be unrealistic to expect a single protocol to define the corresponding "solution space". This document takes the perspective that SNMPv3 can play a valuable role in defining such a solution space for AAA, but only in conjunction with a set (hopefully a small set) of other protocols which will provide compliant functionality in those areas where SNMPv3 either cannot (by virtue of its nature) or does not (by virtue of its details) do so. Furthermore, the role of SNMPv3 in the solution space for AAA must be seen as consisting of the following elements: - The SNMPv3 protocol itself. - SNMP management entities. - SNMP MIBs. - A physical model of an SNMP management network. - SNMP scalability mechanisms. - On-going SNMP network management research and development. The specific assessments made in the individual requirements compliance sections later in this document incorporate an expectation that all of the elements encompassed by the foregoing list -- and briefly described in the sub-sections which immediately follow this paragraph -- collaborate to define SNMPv3 compliance to the AAA requirements. By and large, we are talking about components and capabilities which exist today -- most of which have a long record of validation in the field -- although we may need to put some of the elements together in slightly different ways than we have in the past and some new derivations from model elements may need to be constructed from these components. 5.1. The SNMPv3 protocol itself Over and above the core operational capabilities of previous versions of SNMP, SNMPv3 provides for the following security services [USM]: - Data integrity: Assurance that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non- maliciously. - Data origin authentication: Assurance that the claimed identity of the user on whose behalf received data was originated is corroborated. Natale Expires December 2000 4 INTERNET-DRAFT SNMPv3 for AAA June 2000 - Data confidentiality: Assurance that information is not made available or disclosed to unauthorized individuals, entities, or processes. - Message timeliness and limited replay protection: Assurance that a message whose generation time is outside of a specified time window is not accepted. ...and data object security services [VACM]: - Access control: Assurance that a specific type of access (read, write, notify) to a particular object (instance) is authorized or is otherwise disallowed. 5.2. SNMP management entities [APPS] As opposed to the traditional view of SNMP management entities as either "agents" or "managers", SNMPv3 views an SNMP management entity as (among other things) any combination of the following types of application-layer functionality: - Command generators: Initiate read- and/or write-class messages. - Command responders: Respond to read- and/or write-class messages. - Notification originators: Originate notification-class messages. - Notification receivers: Receive notification-class messages. - Proxy forwarders: Forward SNMP messages. This refinement facilitates the design, development, and deployment of both more focused (e.g., notification receivers) and more complex (e.g., "dual-role entities", "mid-level managers") SNMP management entities, providing a richer set of solutions to the user community. This broader scope for application modeling serves to enlarge the range of AAA operational requirements that SNMPv3 can viably address. Furthermore, additional SNMP application types can be defined as well -- we are not limited to only the five types already defined. Thus, it is feasible to consider new SNMP application types corresponding to specialized AAA processes, as well as possible new SNMP PDU formats optimized for those processes. 5.3. SNMP MIBs As opposed to the traditional view of SNMP MIBs as consisting of primarily (to exclusively) atomic objects representing individual Natale Expires December 2000 5 INTERNET-DRAFT SNMPv3 for AAA June 2000 discrete data items (or collection of such items into conceptual rows and tables), a more current view of efficient and effective composition calls for the design and inclusion of higher-level objects that can represent aggregations of discrete data items, virtual objects, result sets, states, actions, and so forth. Such more powerful MIBs exhibit a symbiotic relationship with the more sophisticated SNMP applications architectures described above in that they are both enabled by those architectural possibilities and, in turn, drive the development of the more capable applications which implement such architectures. 5.4. A physical model of an SNMP management network The origins of SNMP -- and especially the original motivation for the "Simple" in its moniker -- can be traced directly to one of its underlying tenets...indeed, its "fundamental axiom" [ROSE, p. 71]: "The impact of adding network management to managed nodes must be minimal, reflecting a lowest common denominator." While arguably correct for its time, this axiom is no longer valid in its literal rendition for the general case. Managed nodes (now "managed elements", to reflect the more diverse range of things which can and/or should be managed via SNMP) have become more capable (CPU, memory, interface speeds, etc.). More significantly, the potential benefits (in terms of market share, payoff, ROI, and similar economic concepts) of adding management features to a managed element are now seen as being worth some degree of added cost (e.g., monetary and/or impact on other aspects of the element). Perhaps the following may be a valid re-statement of the axiom for current circumstances: "The total cost (economic and operational) of adding network management capabilities to managed elements must be appropriate, reflecting the expected benefits (direct and/or indirect)." By and large, this change in perspective mirrors changes in the larger economic, technological, and sociological landscape and does not imply any kind of flaw in the fundamental axiom for an earlier point in time. 5.5. SNMP scalability mechanisms The contemporary SNMP solutions framework includes multiple, non- exclusionary approaches to scalability, including: - An IETF standard for extensible SNMP agents ("AgentX") - A set of IETF standard MIBs for distributed management ("DISMAN") Natale Expires December 2000 6 INTERNET-DRAFT SNMPv3 for AAA June 2000 - Proxy applications 5.5.1. An IETF standard for extensible SNMP agents ("AgentX") An extensible SNMP agent environment is one in which an SNMP entity known as a "master agent" provides the external interface (for both in-coming and out-going SNMP messages) to other SNMP entities on behalf of a set of "sub-agents" that need not deal with SNMP directly. The purpose of an extensible SNMP agent environment is twofold: First, to provide the infrastructure for shared use of a well-known SNMP port by multiple, independently developed agent entities; and second, they make it technically easier and economically more viable for component suppliers to provide an SNMP management interface to those components. Extensible SNMP agent environments have been available for a long time from a number of suppliers and have played an important role in the broad deployment of SNMP solutions. However, the lack of an IETF standard protocol for agent extensibility was seen as a probable barrier to the widest possible deployment of such solutions. Hence, the IETF eventually standardized the "AgentX" protocol to fill this need. The relevant documents are: RFC2471, "Agent Extensibility (AgentX) Protocol Version 1". [16] (aka [AGENTX]) RFC2472, "Definitions of Managed Objects for Extensible SNMP Agents". [17] (aka [AGENTX-MIB]) Extensible SNMP agents can play important roles in the enabling of various kinds of important AAA applications, especially (but not only) those involved in data collection, filtering, aggregation, analysis, packaging, and forwarding. 5.5.2. DISMAN (distribution of management functionality) TBD. 5.5.3. SNMP Proxy TDB. 5.6. On-going SNMP network management research and development The IRTF NMRG has proposed a number of enhancements to SNMP to improve its suitability for certain AAA applications, especially in the area of accounting services. These are described and discussed in ample detail in Section 7.3 of [ACCT-MGMT]. Collectively, we will refer to them as "the NMRG extensions". They include: - an SNMP-over-TCP transport mapping [NMRG-1] Natale Expires December 2000 7 INTERNET-DRAFT SNMPv3 for AAA June 2000 - SNMP payload compression [NMRG-2] - addition of a "get subtree" retrieval capability [NMRG-3] Please note that these proposed changes are of an experimental nature at this time and, for some of them, active discussion within the SNMP community is underway. The present document takes the perspective that -- while some or all of the NMRG extensions may be beneficial in enhancing SNMP's role as an AAA protocol -- these changes are not *required* to qualify SNMP as an important protocol for use in the AAA solution set. Finally, it must be noted that this document (as of rev -00) is an initial draft. It has been authored by someone with far more knowledge (albeit imperfect) of SNMP than of the range of AAA requirements. And it has received helpful but limited prior review by others who are more knowledgeable with respect to those requirements. So, it is submitted in good faith as a working document and revisions -- perhaps including significant corrections -- are to be expected. 6. AAA/SNMPv3 Requirements/Compliance Tables The AAA protocol evaluation criteria for network access are summarized below in the following sub-sections, with the SNMPv3 compliance information reported for each one. Each criterion or requirement is presented with the following virtual table header in mind: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <Sub-section title> | NASREQ | ROAMOPS | MOBILE | SNMPv3 | | Requirements | | | IP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...where [NASREQ], [ROAMOPS], and [MOBILE IP] refer to the specific requirements documents noted in the References section of this document. Specific sections of the referenced documents are indicated via the bracketed footnote number(s) which appear in the cells and which correspond to the following list: Footnotes: [1] Section 4.2.1 of [ROAMOPS] [2] Section 4.2.2 of [ROAMOPS]. Also see [8]. [3] Section 4.2.3 of [ROAMOPS]. Also see [14]. [4] Section 4.2.4 of [ROAMOPS]. [5] Section 4.2.5 of [ROAMOPS]. [6] Section 4.2.6 of [ROAMOPS]. [7] Section 4.3 of [ROAMOPS]. [8] Section 6 of [NASREQ]. Also see [6]. [9] Section 8.2.2.2 of [NASREQ]. Also see [14]. [10] Section 8.2.2.1 of [NASREQ]. Also see [14]. [11] Section 8.3.2.2 of [NASREQ]. Also see [7]. Natale Expires December 2000 8 INTERNET-DRAFT SNMPv3 for AAA June 2000 [12] Section 8.1.1 of [NASREQ]. [13] Section 8.1.4.4 of [NASREQ]. [14] Section 8.4.1.2 of [NASREQ]. [15] Section 8.4.2 of [NASREQ]. [16] Section 8.1.3 of [NASREQ]. [17] Section 8.2.1.2 of [NASREQ]. [18] Section 8.3.1.1 of [NASREQ]. [19] Section 8.3.2.1 of [NASREQ]. Also see [7]. [20] Section 8.3.2.3 of [NASREQ]. Also see [6], [7]. [21] Section 8.4.1.3 of [NASREQ]. [22] Section 8.4.1.1 of [NASREQ]. [23] Section 8.4.1.4 of [NASREQ]. [24] Section 8.4.3.1 of [NASREQ]. [25] Section 8.4.3.2 of [NASREQ]. [26] Section 8.2.3.1 of [NASREQ]. [27] Section 8.3.3.1 of [NASREQ]. [28] Section 8.1.4.1 of [NASREQ]. [29] Refer [PPP-IPCP] [30] Section 3 of [MOBILE IP] [31] Section 3.1 of [MOBILE IP] [32] Section 4 of [MOBILE IP] [33] Section 5 of [MOBILE IP] [34] Section 5.1 of [MOBILE IP] [35] Section 5.2 of [MOBILE IP] [36] Section 5.3 of [MOBILE IP] [37] Section 5.4 of [MOBILE IP] [38] Section 5.5 of [MOBILE IP] [39] Section 6 of [MOBILE IP] [40] Section 3.1 of [TIA 45.6] [41] Section 3.2.2 of [TIA 45.6] [42] Section 8.2.2.2 of [NASREQ] [43] Section 8.1.2.3 of [NASREQ] [44] Section 8.1.2.2 of [NASREQ] [45] Section 3.4 of [TIA 45.6] [46] Section 4 of [TIA 45.6] The minimum compliance level for each requirement, for each source of the requirement, is shown in each cell in accordance with the following meanings: Key: M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT The SNMPv3 cell reports the summary status of SNMPv3 compliance with the requirement(s) associated with each row and a reference to the sub-section of this document where more details concerning this assessment are given. The summary status entry denotes whether the SNMPv3 protocol meets (T), partially meets (P), or does not meet (F) Natale Expires December 2000 9 INTERNET-DRAFT SNMPv3 for AAA June 2000 the stated requirement(s). A small number of entries have a status value of "?", indicating that the compliance or non-compliance of SNMPv3 with the requirement could not be determined at this time (mainly due to lack of understanding on the part of the author of the "-00" version!). It should be noted that the author of the "-00" version of this document cannot claim expertise in many of the specific AAA requirements listed in the following sections. Furthermore, the vision he has of how SNMPv3 can be used to help form a compliant AAA solution set requires sometimes creative use of all of the SNMPv3 dimensions discussed in Section 5, above. While the author has tried to make an honest judgment about SNMPv3 compliance with each requirement in the context of those considerations, the results clearly suggest that more errors were made on the side of compliance than of non-compliance. It is anticipated (and hoped for) that subsequent review and scrutiny by a wider audience of more expert readers will lead to proper adjustments in the text. 6.1. General requirements These requirements apply to all aspects of AAA and thus are considered general requirements. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | General | NASREQ | ROAMOPS | MOBILE | SNMPv3 | | Requirements | | | IP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scalability | M | M | M | T | | | | | | 6.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fail-over | M | | M | T | | | | | | 6.1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mutual auth | M | | M | T | | AAA client/server | | | | 6.1.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmission level | | M | S | T | | security | | | | 6.1.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data object | M | M | S | T | | Confidentiality | | | | 6.1.5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data object | M | M | M | P | | Integrity | | | | 6.1.6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate | M | | S | T | | Transport | | | | 6.1.7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliable AAA | M | | M | P | | transport mechanism | | | | 6.1.8 | Natale Expires December 2000 10 INTERNET-DRAFT SNMPv3 for AAA June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run Over IPv4 | M | M | M | T | | | | | | 6.1.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run Over IPv6 | M | | S | P | | | | | | 6.1.10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Support Proxy and | M | | M | P | | Routing Brokers | | | | 6.1.11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auditability | S | | | F | | | | | | 6.1.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared secret not | S | O | O/M | T | | required | | | | 6.1.13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ability to carry | M | | S | T | | service-specific attr.| | | | 6.1.14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.1. Scalability +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scalability | M | M | M | T | | | 12 | 3 | 30 39 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 satisfies this requirement. SNMP has existence proofs of| | supporting networks with tens of thousands of managed nodes. | | the text in the note (a) referring to "millions of users" and | | "tens of thousands of simultaneous requests" does not seem | | relevant to the envisioned role(s) for SNMPv3 in AAA, which will| | likely be tied to administrative and operating domains of | | smaller (yet large in an absolute sense) scope. | | | | To be sure these numbers do mean that distributed management | | facilities for collection, aggregation, filtering, analysis, | | packaging, forwarding, and so forth will be critical in such an | | environment. The DISMAN series of MIBs suggest that SNMP can be| | deployed in ways that will scale to meet the needs of networks | | of the sizes required for AAA. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.2. Fail-over +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fail-over | M | | M | T | | | 12 | | 31 | | Natale Expires December 2000 11 INTERNET-DRAFT SNMPv3 for AAA June 2000 |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMP satisfies this requirement via the application-layer | | timeout detection mechanisms normally built into SNMP engines | | and/or higher-|order SNMP entities. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.3. Mutual authentication +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mutual auth | M | | M | T | | AAA client/server | 16 | | 30 | | |-----------------------------------------------------------------| | [c] This requirement refers to the ability to support mutual | | authentication between the AAA client and server. | |-----------------------------------------------------------------| | SNMPv3 security features satisfy this requirement. | | The requirement is that a server can explicitly authenticate a | | client, and that a client can explicitly authenticate a server. | | SNMP does this in USM by the use of shared keys, timeliness | | checking, message IDs sequencing, etc. New security models may | | add new mechanisms as well. | | Also, the use of protocols and methods other than SNMPv3 by AAA | | clients and servers is not precluded by the envisioned use of | | SNMPv3 for AAA. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.4. Transmission level security +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmission level | | M | S | T | | security | | 6 | 31 39 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 security features satisfy this requirement. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.5. Data object confidentiality It is important to note that this draft (throughout) interprets the terms "data object" and "attribute" (as used in the AAA requirements documents) as more or less synonymous. Natale Expires December 2000 12 INTERNET-DRAFT SNMPv3 for AAA June 2000 In mapping such data objects/attributes to SNMPv3 concepts -- especially where protection (integrity and/or confidentiality) is required -- this draft envisions a corresponding set of SNMP "MIB objects". These may be thought of as something like: - a group of related MIB objects (e.g., MIB sub-tree branch) - a row of objects in a MIB table - an opaque structure-like object comprised of a set of MIB objects - ...or anything that works better. The key idea is that such an "AAA data object" is actually a fairly "complex" life form, not a simple single object with a name and a value. Furthermore, among the set of MIB objects comprising such an AAA data object would be the necessary security parameters to allow for integrity and confidentiality, including timeliness verification. The bottom line is that individual AAA data object security is independent from the overall SNMPv3 message security. An easy way to envision this is to imagine USM being applied to such a set of MIB objects with a different set of valid securityNames from those used at the message processing usmUserTable level. That is surely not the only way to implement this -- and not necessarily the one to be recommended -- but it might be the easiest to envision (and critique!) quickly. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data object | M | M | S/M | T | | Confidentiality | 26 | 6 | 33/40 | | |-----------------------------------------------------------------| | [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). | |-----------------------------------------------------------------| | SNMPv3 security features (including the use of VACM for the | | "attribute-by-attribute" stipulation in Sec. 4.2.6 of [ROAMOPS])| | satisfy this requirement. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.6. Data object integrity See explanatory comments in 6.1.5. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data object | M | M | M | P | Natale Expires December 2000 13 INTERNET-DRAFT SNMPv3 for AAA June 2000 | Integrity | 16 | 6 | 31 39 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | There appear to be at least two different requirements in this | | statement. On the one hand, SNMPv3 security features satisfy | | the requirement for protection against modification of object | | data by intermediate servers between two target end-points. On | | the other hand, SNMPv3 security features also provide for | | ensuring that object level authentication is persistent across | | one or more intermediate AAA entities. But SNMPv3 security | | would not, therefore, enable those intermediate AAA entities to | | directly verify the authentication. Such a capability could | | perhaps be enabled by wrapping an SNMPv3 payload inside another | | SNMPv3 message, with the "outer wrapper" message carrying | | authentication parameters verifiable by the next intermediate | | entity. This document does not propose such a solution, | | however, electing, instead, to leave SNMPv3 compliance with this| | partial requirement unclear. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.7. Certificate transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate | M | | S/M | T | | transport | 42 | |31,33/46 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | Given resolution of concerns about certificate sizes relative to| | SNMPv3 transport capacities and given the definition of MIB | | objects for certificate transport, SNMPv3 is capable of | | transporting certificate data. However, it is worth considering| | whether the potential cost of this optimization truly offsets | | the potential benefits of a specialized protocol or service to | | handle transport and other certificate-related operations. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.8. Reliable AAA transport mechanism +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliable AAA | M | | M | P | Natale Expires December 2000 14 INTERNET-DRAFT SNMPv3 for AAA June 2000 | transport mechanism | 22 | | 31 32 | | |-----------------------------------------------------------------| | [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. | | 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. | | 4. Piggy-backing of acknowledgments in AAA messages. | | 5. Timely delivery of AAA responses. | |-----------------------------------------------------------------| | Standard SNMPv3 over UDP meets some of these requirements; work | | outlined in the NMRG enhancements for running SNMP over TCP (and| | possibly other connection-oriented and/or "reliable" transports)| | may satisfy additional aspects of this set of requirements: | | | | 1. Unsure what this means exactly. SNMPv3 application level | | retransmission logic is typically end-to-end. | | 2. This requirement is typically met by SNMPv3 engines and/or | | application entities. | | 3. For standard SNMPv3 over UDP, successfully delivered request| | messages are "acknowledged" via a response message (where | | "successfully delivered" means that it was received, parsed,| | and authenticated without exception per the SNMPv3 elements | | of procedure). | | 4. SNMPv3 does not support piggy-backing of acknowledgements. | | Furthermore, SNMPv3 logic questions the value of message | | acknowledgment below the application level (i.e., what is | | the value of knowing that a message was received but perhaps| | not accepted or acted upon at the application level?). | | 5. SNMPv3 imposes only moderate average overhead on its | | payloads, and (based on extensive field experience with | | earlier versions of SNMP) would not likely introduce a | | performance bottleneck. The slowest part of a secure SNMPv3| | transaction is the security processing which is performed | | via protocols independent of SNMP (with the current defaults| | being MD5 or SHA for authentication and DES for encryption | | ...faster security models and/or protocols for use with | | SNMPv3 may be introduced in the future). | | | | Finally, since SNMPv3 messages exhibit no intrinsic dependency | | on the transport protocol used to carry them, SNMPv3 may be | | malleable to running over any more reliable/capable/faster | | transport layer protocol that the AAA standards may eventually | | mandate. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Natale Expires December 2000 15 INTERNET-DRAFT SNMPv3 for AAA June 2000 6.1.9. Run over IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run over IPv4 | M | M | M | T | | | 11 | 1 | 17 | | |-----------------------------------------------------------------| | SNMPv3 satisfies this requirement. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.10. Run over IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Run over IPv6 | M | | S | P | | | 11 | 1 | 18 | | |-----------------------------------------------------------------| | Experimental versions of SNMPv3 currently satisfy this | | requirement. Standardization of IPv6 support for SNMP is | | underway and is expected to be straightforward (via new textual | | conventions) for the protocol itself. SNMPv3 compliance with | | this requirement can be expected when needed. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.11. Support proxy and routing brokers +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Support proxy and | M | | M | P | | routing brokers | 12 | | 31 39 | | |-----------------------------------------------------------------| | [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). | |-----------------------------------------------------------------| | SNMPv3 proxy forwarding capabilities/applications appear to | | satisfy this requirement. However, the issues raised wrt | | authentication by intermediate AAA entities above (in Section | | 6.1.6) may negate this apparent degree of compliance. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.12. Auditability +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auditability | S | | | F | | | 25 | | | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 does not incorporate auditability in the protocol itself.| Natale Expires December 2000 16 INTERNET-DRAFT SNMPv3 for AAA June 2000 | SNMPv3 entities could satisfy this requirement in a variety of | | ways at the application level. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.13. Shared secret not required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared secret | S | O | O/M | T | | not required | 28 | 6 |34,39/40 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | Use of the security features of SNMPv3 is optional. | | | | Moreover, the structure of SNMPv3 messages enables them to be | | sent -- with or without using the security features -- over a | | secure lower-layer protocol (such as IPsec), given appropriate | | corresponding end-point security facilities. | | | | Use of the full intrinsic SNMPv3 security does require shared | | secrets between SNMPv3 end-point entities; however, the protocol| | incorporates a localization scheme which mitigates the | | scalability and management problems often associated with shared| | secret systems. | | | | In SNMPv3, USM is required for purposes of interoperability, | | especially for troubleshooting, and a shared secret is the | | standard approach for USM. For purposes other than | | troubleshooting, a shared secret would not necessarily be | | required. To put this another way, because SNMP would be | | serving purposes beyond AAA, and for those non-AAA purposes | | interoperability and availability are paramount, shared secrets | | are required for those other, non-AAA, purposes. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1.14. Ability to carry service-specific attributes See explanatory comments in 6.1.5. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ability to carry | M | | S | T | | service-specific attr.| 43 | | 31 33 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| Natale Expires December 2000 17 INTERNET-DRAFT SNMPv3 for AAA June 2000 | SNMPv3 satisfies this requirement via the use of MIBs. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2. Authentication Requirements Note several of the responses in this section assume that SNMPv3 will be used as a tool (e.g., for transport, management, etc.) to support out-of-band user authentication via other protocols (e.g., CHAP, EAP, PAP, etc.) in various AAA processes. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | NASREQ | ROAMOPS | MOBILE | SNMPv3 | | Requirements | | | IP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAI Support | M | M | S | T | | | | | | 6.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHAP Support | M | M | O | T | | | | | | 6.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Support | M | S | O | P | | | | | | 6.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAP/Clear-Text | M | B | O | T | | Support | | | | 6.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Re-authentication | M | | S | T | | on demand | | | | 6.2.5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authorization Only | M | | O | T | | w/o Authentication | | | | 6.2.6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.1. NAI support +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAI Support | M | M | S/M | | | | 9 | 2 |32,34,38/| T | | | | | 40 | | |-----------------------------------------------------------------| | [a] The AAA protocol MUST allow the use of Network Access | | Identifiers (NAI) [8] to identify users and/or devices. | |-----------------------------------------------------------------| | SNMPv3 supports this requirement via MIB objects which can be | | created for this purpose. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.2. CHAP support +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHAP Support | M | M | O | T | | | 10 | 3 | | | Natale Expires December 2000 18 INTERNET-DRAFT SNMPv3 for AAA June 2000 |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 supports this requirement via MIB objects which can be | | created for this purpose. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.3. EAP support +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Support | M | S | O | P | | | 10 | 3 | | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 partially supports this requirement via MIB objects which| | can be created for this purpose. A complete EAP-authentication | | scheme built around AAA use of SNMPv3 will likely require | | further analysis and design efforts, at a minimum. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.4. PAP/clear-text support +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAP/Clear-Text | M | B | O | T | | Support | 10 | 3 | | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | Given MIB objects designed for this purpose, SNMPv3 can carry | | clear-text passwords as message data objects. When such | | messages are sent using the privacy (encryption) facilities of | | SNMPv3, both the confidentiality of these passwords on-the-wire | | and protection from unauthorized disclosure of them at an end- | | point are ensured. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Natale Expires December 2000 19 INTERNET-DRAFT SNMPv3 for AAA June 2000 6.2.5. Re-authentication on demand +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Re-authentication | M | | S | T | | on demand | 17 | | 30 33 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 AAA applications interfaces can support re-authentication| | on demand by [re-]setting MIB objects designed to trigger agent | | processor to [re-]authenticate the user. Application interfaces| | of this nature may exist for users (via UIs), devices (via | | SNMPv3 protocol messages), or software entities (via APIs, for | | example). | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.6. Authorization only without authentication +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authorization Only | M | | O | T | | w/o Authentication | 9 | | 30 | | |-----------------------------------------------------------------| | [f] This requirement refers to the ability to authorize usage | | based on a user claim of identity, without requiring that the | | claim be authenticated. | |-----------------------------------------------------------------| | SNMPv3 supports this requirement by virtue of the independence | | of the View-based Access Control Model (VACM) from the security | | features. That is, an unauthenticated (noAuth/noPriv) SNMPv3 | | message is still subject to the access control (authorization) | | policy of the entity which instruments the objects of interest. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3. Authorization Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authorization | NASREQ | ROAMOPS | MOBILE | SNMPv3 | | Requirements | | | IP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Static and Dynamic | M | M | M | T | | IPv4/6 Addr. Assign.| | | | 6.3.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RADIUS gateway | M | M | O | T | | capability | | | | 6.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reject | M | M | M | T | | capability | | | | 6.3.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precludes layer 2 | N | N | | ? | Natale Expires December 2000 20 INTERNET-DRAFT SNMPv3 for AAA June 2000 | tunneling | | | | 6.3.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Re-Authorization on | M | | S | T | | demand | | | | 6.3.5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Support for Access | M | | O | T | | Rules, Restrictions, | | | | 6.3.6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State | M | | | T | | Reconciliation | | | | 6.3.7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unsolicited | M | | | T | | Disconnect | | | | 6.3.8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.1. Static and dynamic IPv4/6 address assignment +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Static and Dynamic | M | M | M | T | | IPv4/6 Addr. Assign.| 11 | 1 | 32 36 | | |-----------------------------------------------------------------| | [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. An address is considered static when a user requests a | | specific address, and it is present in the authorization | | request. An address is considered dynamic when the AAA server | | assigns an address to the user that is either defined in his | | profile, or from an address pool managed by the server. | |-----------------------------------------------------------------| | SNMPv3 can support both IPv4 and/or IPv6 MIB objects for use by | | AAA authorization processes. Whether values for such objects | | come from static or dynamic sources, as defined above, is | | immaterial to the SNMPv3 layer. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.2. RADIUS gateway capability +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RADIUS gateway | M | M | O/M | T | | capability | 44 | 3 | 30/45 | | |-----------------------------------------------------------------| | [b] This requirement refers to the ability of a new AAA | | protocol to 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. | |-----------------------------------------------------------------| | It is anticipated that all exiting RADIUS attributes can be | | modeled as MIB objects for transport and manipulation by SNMPv3-| | enabled AAA software processes which could then perform any | | necessary RADIUS gateway functions. | Natale Expires December 2000 21 INTERNET-DRAFT SNMPv3 for AAA June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.3. Reject capability +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reject | M | M | M | T | | capability | 12 | 4 | 39 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | The essence of this requirement seems external to SNMPv3 per se.| | Nothing in the SNMPv3 mapping to AAA requirements is known to | | preclude or impede implementation of such a reject capability | | in either proxy brokers or AAA servers. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.4. Precludes layer 2 tunneling +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precludes layer 2 | N | N | | ? | | tunneling | 11 | 5 | | | |-----------------------------------------------------------------| | Unclear about the meaning of this requirement at this time. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.5. Re-authorization on demand +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Re-authorization | M | | S | T | | on demand | 18 | | 30 33 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | The essence of this requirement seems external to SNMPv3 per se.| | MIB objects can be defined to represent the requisite states -- | | including time limits on authorizations -- and transported | | reliably via SNMPv3 messages to interested AAA processes. | | Nothing in the SNMPv3 mapping to AAA requirements is known to | | preclude or impede implementation of re-authorization by AAA | | clients and/or servers or the transmission of updated | Natale Expires December 2000 22 INTERNET-DRAFT SNMPv3 for AAA June 2000 | authorization information from AAA servers to AAA devices. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.6. Support for access rules, restrictions, filters +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Support for Access | M | | O | T | | Rules, Restrictions, | 11, 19 | | 30 37 | | |-----------------------------------------------------------------| | [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. Time/Day restrictions | | 2. Port location restrictions | | 3. Dialed/Dialing number | | 4. Concurrent login limits | | 5. Session expirations and Idle Timeouts | | 6. Packet filters | | 7. Static routes | | 8. QoS parameters | |-----------------------------------------------------------------| | MIB objects describing all of the access operational limitations| | and authorization restrictions listed in this requirement can be| | defined and then transported and manipulated by SNMPv3-enabled | | AAA software entities. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.7. State reconciliation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State | | M | | T | | reconciliation | | 20 | | | |-----------------------------------------------------------------| | [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. 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, the following capabilities are | | required: | | | | 1. Re-authorization capabilities | | 2. A session disconnect message | | 3. Transport and application-layer reliability | | 4. An interim message | | 5. A mechanism for the AAA server to retrieve state | | information from the NAS. This mechanism will provide | Natale Expires December 2000 23 INTERNET-DRAFT SNMPv3 for AAA June 2000 | timely information though a complete state dump may not be | | immediately available. | | 6. A device reboot message. | | 7. AAA On/Off messages. | | | | If non-volatile memory is present, it is believed that only | | elements 1 - 3 are needed. However, since this will not always | | be true, other mechanisms are also needed. Mechanism 4 provides | | recovery time on the order of the interim interval, and so may | | be too slow in many cases. Mechanisms 5-7 can be useful but are | | not implementable at Internet scale for use in applications such| | as roaming. | |-----------------------------------------------------------------| | The foregoing statement of this requirement is internally | | inconsistent -- if mechanisms 5-7 are not implementable at | | Internet scale how can they nonetheless be requirements? Be | | that as it may several of these mechanisms (e.g., 1 and 3) have | | been addressed (positively) in previous sections and all of | | them may be implemented| in an SNMPv3 environment via | | appropriate MIB and application-level support. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.8. Unsolicited disconnect +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unsolicited | M | | | T | | disconnect | 18 | | | | |-------------------=---------------------------------------------| | [g] This requirement refers to the ability of the AAA server to| | request the NAS to disconnect an active session for | | authorization policy reasons. | |-----------------------------------------------------------------| | Such a request can be conveyed readily via an SNMPv3 Set | | operation an appropriate MIB object. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4. Accounting Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accounting | NASREQ | ROAMOPS | MOBILE | SNMPv3 | | Requirements | | | IP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Real-time | M | M | M | T | | accounting | | | | 6.4.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Compact | | M | M | T | | Encoding | | | | 6.4.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accounting Record | M | M | M | T | | Extensibility | | | | 6.4.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Batch | S | | | T | Natale Expires December 2000 24 INTERNET-DRAFT SNMPv3 for AAA June 2000 | accounting | | | | 6.4.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed | M | | M | T | | delivery | | | | 6.4.5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accounting | M | | S | T | | Time Stamps | | | | 6.4.6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dynamic | M | | S | T | | accounting | | | | 6.4.7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.1. Real-time accounting +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Real-time | M | M | M | T | | accounting | 14 | 7 | 31 39 | | |-----------------------------------------------------------------| | [a] This requirement may be loosely defined as reporting | | synchronously with events. Typically the time window is on the | | order of seconds, not milliseconds. | |-----------------------------------------------------------------| | SNMPv3 solutions can support the real-time accounting | | requirements by, for example, permitting Sets of MIB objects | | designed to govern the timely transfer of accumulated accounting| | data (perhaps via out-of-band means) and/or via the use of | | InformRequest PDUs to send "real-time" accounting records. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.2. Mandatory compact encoding +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory compact | | M | M | T | | encoding | | 7 | 33 | | |-----------------------------------------------------------------| | [b] The AAA protocol's Accounting data format MUST NOT be | | bloated, imposing a large overhead for one or more accounting | | data elements. | |-----------------------------------------------------------------| | In general, SNMPv3 solutions will not impose any format | | requirements on accounting data. In cases where large amounts | | of accounting data are to be transmitted, this process will | | likely be *managed* via SNMPv3 MIB objects, but actually | | executed via some external protocol (e.g., FTP, HTTP) which may | | or may not impose format requirements on the data. In cases | | where smaller amounts of accounting data are to be transferred | | via SNMPv3 messages -- as in the real-time accounting | | requirements covered above -- a variety of appropriate MIB | | object definitions will be available (e.g., perhaps | | corresponding to [ADIF] specifications), some of which may | | optimize for size while others may optimize for other factors, | | depending upon the relevant AAA application(s). | Natale Expires December 2000 25 INTERNET-DRAFT SNMPv3 for AAA June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.3. Accounting record extensibility +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accounting record | M | M | M | T | | extensibility | 15 | 7 | 33 | | |-----------------------------------------------------------------| | SNMPv3 MIB objects will be used to represent accounting records | | and other accounting data elements as may be required (e.g., | | perhaps corresponding to [ADIF] specifications). SNMP MIBs are | | extensible by definition. In cases of accounting data files, | | the SNMPv3 MIB representation may be completely opaque (e.g., | | OCTET_STRING type). | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.4. Batch accounting +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Batch | S | | | T | | accounting | 21 | | | | |-----------------------------------------------------------------| | [c] This requirement refers to the ability to buffer or store | | multiple accounting records, and send them together at some | | later time. | |-----------------------------------------------------------------| | SNMPv3 MIB objects will be used to control and schedule | | accounting data collection (e.g., bucket size, time span) and | | transfer (e.g., targets, protocol to be used, transmission | | parameters) allowing for batch accounting. Note that some SNMP | | MIBs (e.g., in the ATM space) already provide models for this | | form of accounting. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.5. Guaranteed delivery +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed | M | | M | T | | delivery | 22 | | 31 | | |-----------------------------------------------------------------| | [d] This is an application layer acknowledgment. This is sent | | when the receiving server is willing to take responsibility for | | the message data. | |-----------------------------------------------------------------| | For in-band transmission of accounting data (e.g., for real-time| | accounting records), an SNMPv3 InformRequest message (receipt of| | which will be acknowledged by the target entity) can be used to | | actually carry the accounting data. For out-of-band | | transmission of accounting data (e.g., batch file transfer), an | | InformRequest message can be used to notify an interested | | application that the data transfer has been initiated. In the | | out-of-band case, the transfer protocol itself will have to | Natale Expires December 2000 26 INTERNET-DRAFT SNMPv3 for AAA June 2000 | guarantee delivery, although SNMPv3 mechanisms (in-bound Gets | | for "pull" mode or out-bound InformRequests for "push" mode) may| | be used to check final delivery status at the receiving entity. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.6. Accounting time stamps +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accounting | M | | S/M | T | | time stamps | 23 | | 30/40 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | The SNMPv3 DateAndTime textual convention [RFC2579] can be used | | to define MIB objects that satisfy this requirement for use in | | AAA applications. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4.7. Dynamic accounting +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dynamic | M | | S | T | | accounting | 18 | | 30 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMPv3 facilities used in AAA applications will be agnostic to | | the number of accounting records generated for a single session.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.5. Unique Mobile IP requirements In addition to the above requirements, Mobile IP also has the following additional requirements: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | SNMPv3 | | Requirements | | | IP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding of Mobile IP| | | M | T | | registration messages| | | | 6.5.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Firewall | | | M | P | | friendly | | | | 6.5.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Allocation of | | | S/M | ? | | local Home agent | | | | 6.5.3 | Natale Expires December 2000 27 INTERNET-DRAFT SNMPv3 for AAA June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.5.1. Encoding of Mobile IP registration messages +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding of Mobile IP| | | M | T | | registration messages| | | 33 | | |-----------------------------------------------------------------| | Given that the Mobile IP registration message may be represented| | in an SNMPv3 solution as a set of one or more data objects then | | it could be encoded at the object level and/or at the SNMPv3 | | scopedPDU encryption level. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.5.2. Firewall friendly +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Firewall | | | M | P | | friendly | | | 35 | | |-----------------------------------------------------------------| | [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. | |-----------------------------------------------------------------| | SNMP over UDP is not generally considered firewall friendly. It| | is possible, however, that SNMPv3 messages will be looked upon | | more favorably by firewall administrators due to the advanced | | security features it offers. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.5.3. Allocation of local Home agent +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Allocation of | | | S/M | ? | | local Home agent | | | 37/41 | | |-----------------------------------------------------------------| | SNMPv3 compliance or non-compliance with this requirement is not| | determinable at this time (due to lack of understanding of the | | requirement on the part of this author!). | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Conclusion Based upon the foregoing caveats, explanations, analyses, and responses, it would appear that SNMPv3 is well prepared to play a significant role in an IETF standard AAA solution set. This role would involve the SNMPv3 protocol itself, SNMP MIBs, SNMP- enabled AAA applications, IETF-standard extensible SNMP agents, SNMP distributed management mechanisms, and other related components. So, while this draft does not propose a simple, Natale Expires December 2000 28 INTERNET-DRAFT SNMPv3 for AAA June 2000 monolithic SNMPv3 answer to all of the AAA requirements, it does hope to justify a significant role for SNMPv3 in the overall AAA solution set. 8. References [1] Aboba, B., et al., " Criteria for Evaluating AAA Protocols for Network Access", Internet draft (work in progress), draft-ietf-aaa-na-reqts-05.txt, April 2000. [2] Aboba, B., Zorn, G., "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [3] Beadles, M., Mitton, D. "Criteria for Evaluating Network Access Server Protocols", Internet draft (work in progress), draft-ietf-nasreq-criteria-04.txt, February 2000. [4] Hiller, T., et al., "Cdma2000 Wireless Data Requirements for AAA", Internet draft (work in progress), draft-hiller-cdma2000-AAA-00.txt, October 1999. [5] Glass, S., Hiller, T., Jacobs, S., Perkins, C., "Mobile IP Authentication, Authorization, and Accounting Requirements", Internet draft (work in progress), draft-ietf-mobileip-aaa-reqs-01.txt, January 2000. [6] Case, J., Mundy, R., Partain, D., Stewart, B., "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [8] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [9] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [10] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [11] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [12] Frye, R., Levi, D., Routhier, S., Wijnen, B., "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", Natale Expires December 2000 29 INTERNET-DRAFT SNMPv3 for AAA June 2000 RFC 2576, March 2000. [13] McCloghrie, K., Perkins, D., Schoenwaelder, J., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [14] McCloghrie, K., Perkins, D., Schoenwaelder, J., "Textual Conventions for SMIv2", RFC 2579, April 1999. [15] McCloghrie, K., Perkins, D., Schoenwaelder, J., "Conformance Statements for SMIv2", RFC 2580, April 1999. [16] Daniele, M., Wijnen, B., Ellison, M., Francisco, D., "Agent Extensibility (AgentX) Protocol Version 1", RFC 2471, January 2000. [17] Heintz, L., Gudur, S., Ellison, M., "Definitions of Managed Objects for Extensible SNMP Agents", RFC 2472, January 2000. TBD: [ACCT-MGMT] [NMRG-1] [NMRG-2] [NMRG-3] [PPP-ICP] [TIA 45.6] 9. Security Considerations This document, being a requirements comparison document, does not have any security concerns. The security requirements on protocols compared in this document are described in the referenced documents. 10. IANA Considerations This draft does not create any new number spaces for IANA administration. 11. Acknowledgments Thanks to Bernard Aboba, Wes Hardaker, and David Harrington for helpful feedback on version "-00" of this draft. 12. Author's Addresses Bob Natale ACE*COMM 704 Quince Orchard Rd Gaithersburg MD 20078 Natale Expires December 2000 30 INTERNET-DRAFT SNMPv3 for AAA June 2000 Phone: +1 (301) 721-3000 Fax: +1 (301) 721-3001 Email: bnatale@acecomm.com Natale Expires December 2000 31 INTERNET-DRAFT SNMPv3 for AAA June 2000 13. 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. Natale Expires December 2000 32 INTERNET-DRAFT SNMPv3 for AAA June 2000 14. 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." 15. Expiration Date This memo is filed as <draft-natale-snmpv3-comp-00.txt>, and expires December 1, 2000. Natale Expires December 2000 33