📄 rfc2906.txt
字号:
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -