rfc2906.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        S. Farrell
Request for Comments: 2906                       Baltimore Technologies
Category: Informational                                   J. Vollbrecht
                                               Interlink Networks, Inc.
                                                             P. Calhoun
                                                 Sun Microsystems, Inc.
                                                             L. Gommans
                                                Enterasys Networks EMEA
                                                               G. Gross
                                                    Lucent Technologies
                                                           B. de Bruijn
                                                Interpay Nederland B.V.
                                                             C. de Laat
                                                     Utrecht University
                                                            M. Holdrege
                                                                ipVerse
                                                              D. Spence
                                               Interlink Networks, Inc.
                                                            August 2000


                     AAA Authorization Requirements

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 specifies the requirements that Authentication
   Authorization Accounting (AAA) protocols must meet in order to
   support authorization services in the Internet. The requirements have
   been elicited from a study of a range of applications including
   mobile-IP, roamops and others.











Farrell, et al.              Informational                      [Page 1]

RFC 2906             AAA Authorization Requirements          August 2000


Table Of Contents

   1. Introduction.................................................2
   2. Requirements.................................................3
       2.1  Authorization Information..............................3
       2.2  Security of authorization information..................7
       2.3  Time...................................................9
       2.4  Topology..............................................10
       2.5  Application Proxying..................................12
       2.6  Trust Model...........................................12
       2.7  Not just transactions.................................14
       2.8  Administration........................................15
       2.9  Bytes on-the-wire.....................................16
       2.10 Interfaces............................................17
       2.11 Negotiation...........................................18
   3. Security Considerations.....................................19
   4. References..................................................20
   Authors' Addresses.............................................20
   Full Copyright Statement.......................................23

1. Introduction

   This document is one of a series of three documents under
   consideration by the AAAarch RG dealing with the authorization
   requirements for AAA protocols.  The three documents are:

         AAA Authorization Framework [FRMW]
         AAA Authorization Requirements (this document)
         AAA Authorization Application Examples [SAMP]

   The work for this memo was done by a group that originally was the
   Authorization subgroup of the AAA Working Group of the IETF.  When
   the charter of the AAA working group was changed to focus on MobileIP
   and NAS requirements, the AAAarch Research Group was chartered within
   the IRTF to continue and expand the architectural work started by the
   Authorization subgroup.  This memo is one of four which were created
   by the subgroup.  This memo is a starting point for further work
   within the AAAarch Research Group.  It is still a work in progress
   and is published so that the work will be available for the AAAarch
   subgroup and others working in this area, not as a definitive
   description of architecture or requirements.

   The process followed in producing this document was to analyze the
   requirements from [SAMP] based on a common understanding of the AAA
   authorization framework [FRMW]. This document assumes familiarity
   with both the general issues involved in authorization and, in
   particular, the reader will benefit from a reading of [FRMW] where,
   for example, definitions of terms can be found.



Farrell, et al.              Informational                      [Page 2]

RFC 2906             AAA Authorization Requirements          August 2000


   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in [RFC2119].

2. Requirements

   Requirements are grouped under headings for convenience; this
   grouping is not significant.

   Definitions and explanations of some of the technical terms used in
   this document may be found in [FRMW].

   Each requirement is presented as a succinct (usually a sentence or
   two) statement. Most are followed by a paragraph of explanatory
   material, which sometimes contains an example. Fully described
   examples may be found in [SAMP].

   The requirements presented are not intended to be "orthogonal", that
   is, some of them repeat, or overlap, with others.

2.1 Authorization Information

2.1.1   Authorization decisions MUST be able to be based on information
   about the requestor, the service/method requested, and the operating
   environment (authorization information). AAA protocols are required
   to transport this information.

   This simply states the requirement for a protocol and an access
   decision function, which takes inputs, based on the requestor, the
   resource requested and the environment.

2.1.2   It MUST be possible to represent authorization information as
   sets of attributes. It MAY be possible to represent authorization
   information as objects.

   This states that authorization information must be decomposable into
   sets of attributes. It is not intended to imply any particular
   mechanism for representing attributes.

2.1.3   It MUST be possible to package authorization information so that
   the authorization information for multiple services or applications
   can be carried in a single message in a AAA or application protocol.

   This states that a protocol, which always required separate AAA
   messages/transactions for each service/application, would not meet
   the requirement. For example, it should be possible for a single AAA
   message/transaction to be sufficient to allow both network and
   application access.




Farrell, et al.              Informational                      [Page 3]

RFC 2906             AAA Authorization Requirements          August 2000


2.1.4   Standard attributes types SHOULD be defined which are relevant
   to many Internet applications/services (e.g.  identity information,
   group information, ...)

   There are many attributes that are used in lots of contexts, and
   these should only be defined once, in order to promote
   interoperability and prevent duplication of effort.

2.1.5   Authorization decisions MUST NOT be limited to being based on
   identity information, i.e. AAA protocols MUST support the use of
   non-identifying information, e.g. to support role based access
   control (RBAC).

   Authorization based on clearances, roles, groups or other information
   is required to be supported. A AAA protocol that only carried
   identity information would not meet the requirement.

2.1.6   Authorization data MAY include limits in addition to attributes
   which are directly "owned" by end entities.

   This states that some attributes do not simply represent attributes
   of an entity, for example a spending limit of IR 1,000 is not an
   intrinsic attribute of an entity. This also impacts on the access
   decision function, in that the comparison to be made is not a simple
   equality match.

2.1.7   It MUST be possible for other (non-AAA) protocols to define
   their own attribute types, which can then be carried within an
   authorization package in a AAA or application protocol.

   This states that the attributes that are significant in an
   authorization decision, may be application protocol dependent. For
   example, many attribute types are defined by [RFC2138] and support
   for the semantics of these attributes will be required. Of course,
   only AAA entities that are aware of the added attribute types can
   make use of them.

2.1.8   It SHOULD be possible for administrators of deployed systems to
   define their own attribute types, which can then be carried within an
   authorization package in a AAA or application protocol.

   This states that the attributes that are significant in an
   authorization decision, may be dependent on a closed environment.
   For example, many organizations have a well-defined scheme of
   seniority, which can be used to determine access levels. Of course,
   only AAA entities that are aware of the added attribute types can
   make use of them.




Farrell, et al.              Informational                      [Page 4]

RFC 2906             AAA Authorization Requirements          August 2000


2.1.9   It SHOULD be possible to define new attribute types without
   central administration and control of attribute name space.

   A centralized or distributed registration scheme of some sort is
   needed if collisions in attribute type allocations are to be avoided.
   However a AAA protocol which always requires use of such a
   centralized registration would not meet the requirement. Of course,
   collisions should be avoided where possible.

2.1.10  It MUST be possible to define attribute types so that an
   instance of an attribute in a single AAA message can have multiple
   values.

   This states that a protocol which does not allow multiple instances
   of an attribute in a message/transaction would not meet the
   requirement.  For example it should be possible to have a "group"
   attribute which contains more than one groupname (or number or
   whatever).

2.1.11  If MUST be possible to distinguish different instances of the
   same authorization attribute type or value, on the basis of "security
   domain" or "authority".

   This recognizes that it is important to be able to distinguish
   between attributes based not only on their value. For example, all NT
   domains (which use the English language) have an Administrators
   group, an access decision function has to be able to determine to
   which of these groups the requestor belongs.

2.1.12  AAA protocols MUST specify mechanisms for updating the rules
   which will be used to control authorization decisions.

   This states that a AAA protocol that cannot provide a mechanism for
   distributing authorization rules is not sufficient. For example, this
   could be used to download ACLs to a PDP.

   Note that this is not meant to mean that this AAA protocol mechanism
   must always be used, simply that it must be available for use. In
   particular, storing authorization rules in a trusted repository (in
   many cases an LDAP server) will in many cases be used instead of such
   a AAA protocol mechanism.  Neither does this requirement call for a
   standardized format for authorization rules, merely that there be a
   mechanism for transporting these.








Farrell, et al.              Informational                      [Page 5]

RFC 2906             AAA Authorization Requirements          August 2000


2.1.13  The AAA protocol MUST allow for chains of AAA entities to be
   involved in an authorization decision.

   This states that more than one AAA server may have to be involved in
   a single authorization decision. This may occur either due to a
   decision being spread across more than one "domain" or in order to
   distribute authorization within a single "domain".

2.1.14  The AAA protocol MUST allow for intermediate AAA entities to add
   their own local authorization information to a AAA request or
   response.

   This states that where more than one AAA entity is involved in an
   authorization decision each of the AAA entities may manipulate the
   AAA messages involved either by adding more information or by
   processing parts of the information.

2.1.15  AAA entities MAY be either be deployed independently or
   integrated with application entities.

   This states that the AAA entities may either be implemented as AAA
   servers or integrated with application entities.

2.1.16  The AAA protocol MUST support the creation and encoding of rules
   that are to be active inside one AAA server based on attributes
   published by another AAA server. The level of authorization of the
   requesting AAA Server MAY govern the view on attributes.

   This states that one AAA entity may have to distribute authorization
   rules to another, and that the AAA entity that receives the rules may
   only be seeing part of the story.

2.1.17  AAA protocols MAY have to support the idea of critical and non-
   critical attribute types.

   This is analogous to the use of the criticality flag in public key
   certificate extensions.