rfc2906.txt

RFC 的详细文档！

2.1.18  A AAA protocol MUST allow authorization rules to be expressed in
   terms of combinations of other authorization rules which have been
   evaluated.

   For example, access may only be granted if the requestor is member of
   the backup users group and not a member of the administrator's group.
   Note that this requirement does not state which types of combinations
   are to be supported.





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


2.1.19  It SHOULD be possible to make authorization decisions based on
   the geographic location of a requestor, service or AAA entity.

   This is just an example of an authorization attribute type, notable
   because it requires different underlying implementation mechanisms.

2.1.20  It SHOULD be possible to make authorization decisions based on
   the identity or the equipment used by a requestor, service or AAA
   entity.

   This is just an example of an authorization attribute type, notable
   because it may require different underlying implementation mechanisms
   (if IPSec isn't available).

2.1.21  When there are multiple instances of a given attribute, there
   must be an unambiguous mechanism by which a receiving peer can
   determine the value of specified instance.

2.2 Security of authorization information

2.2.1   It MUST be possible for authorization information to be
   communicated securely in AAA and application protocols.  Mechanisms
   that preserve authenticity, integrity and privacy for this
   information MUST be specified.

   This states that there must be a well-defined method for securing
   authorization information, not that such methods must always be used.
   Whether support for these mechanisms is to be required for
   conformance is left open. In particular, mechanisms must be provided
   so that a service administrator in the middle of a chain cannot read
   or change authorization information being sent between other AAA
   entities.

2.2.2   AAA protocols MUST allow for use of an appropriate level of
   security for authorization information. AAA protocols MUST be able to
   support both highly secure and less secure mechanisms for data
   integrity/confidentiality etc.

   It is important that AAA protocols do not mandate too heavy a
   security overhead, thus the security mechanisms specified don't
   always need to be used (though not using them may affect the
   authorization decision).

2.2.3   The security requirements MAY differ between different parts of
   a package of authorization information.

   Some parts may require confidentiality and integrity, some may only
   require integrity. This effectively states that we require something



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


   like selective field security mechanisms. For example, information
   required to gain access to a network may have to be in clear, whilst
   information required for access to an application within that network
   may have to be encrypted in the AAA protocol.

2.2.4   AAA protocols MUST provide mechanisms that prevent intermediate
   administrators breaching security.

   This is a basic requirement to prevent man-in-the-middle attacks, for
   example where an intermediate administrator changes AAA messages on
   the fly.

2.2.5   AAA protocols MUST NOT open up replay attacks based on replay of
   the authorization information.

   For example, a AAA protocol should not allow flooding attacks where
   the attacker replays AAA messages that require the recipient to use a
   lot of CPU or communications before the replay is detected.

2.2.6   AAA protocols MUST be capable of leveraging any underlying peer
   entity authentication mechanisms that may have been applied - this
   MAY provide additional assurance that the owner of the authorization
   information is the same as the authenticated entity.  For example, if
   IPSec provides sufficient authentication, then it must be possible to
   omit AAA protocol authentication.

2.2.7   End-to-end confidentiality, integrity, peer-entity-
   authentication, or non-repudiation MAY be required for packages of
   authorization information.

   This states that confidentiality, (resp. the other security
   services), may have to be provided for parts of a AAA message, even
   where it is transmitted via other AAA entities. It does allow that
   such a AAA message may also contain non-confidential, resp. the other
   security services), parts. In addition, intermediate AAA entities may
   themselves be considered end-points for end-to-end security services
   applied to other parts of the AAA message.

2.2.8   AAA protocols MUST be usable even in environments where no peer
   entity authentication is required (e.g. a network address on a secure
   LAN may be enough to decide).

   This requirement (in a sense the opposite of 2.2.6), indicates the
   level of flexibility that is required in order to make the AAA
   protocol useful across a broad range of applications/services.






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


2.2.9   AAA protocols MUST specify "secure" defaults for all protocol
   options. Implementations of AAA entities MUST use these "secure"
   defaults unless otherwise configured/administered.

   This states that the out-of-the-box configuration must be "secure",
   for example, authorization decisions should result in denial of
   access until a AAA entity is configured. Note that the interpretation
   of "secure" will vary on a case-by-case basis, though the principle
   remains the same.

2.3 Time

2.3.1   Authorization information MUST be timely, which means that it
   MUST expire and in some cases MAY be revoked before expiry.

   This states that authorization information itself is never to be
   considered valid for all time, every piece of authorization
   information must have associated either an explicit or implicit
   validity period or time-to-live.

2.3.2   AAA protocols MUST provide mechanisms for revoking authorization
   information, in particular privileges.

   Where the validity or time-to-live is long, it may be necessary to
   revoke the authorization information, e.g. where someone leaves a
   company. Note that this requirement does not mandate a particular
   scheme for revocation, so that it is not a requirement for blacklists
   or CRLs.

2.3.3   A set of attributes MAY have an associated validity period -
   such that that the set MUST only be used for authorization decisions
   during that period. The validity period may be relatively long, (e.g.
   months) or short (hours, minutes).

   This states that explicit validity periods are, in some cases, needed
   at the field level.

2.3.4   Authorization decisions MAY be time sensitive. Support for e.g.
   "working hours" or equivalent MUST be possible.

   This states that the AAA protocol must be able to support the
   transmission of time control attributes, although it does not mandate
   that AAA protocols must include a standard way of expressing the
   "working hours" type constraint.







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


2.3.5   It MUST be possible to support authorization decisions that
   produce time dependent results.

   For example, an authorization result may be that service should be
   provided for a certain period. In such cases a AAA protocol must be
   able to transport this information, possibly as a specific result of
   the authorization decision, or, as an additional "termination of
   service" AAA message transmitted later.

2.3.6   It MUST be possible to support models where the authorization
   information is issued in well in advance of an authorization decision
   rather than near the time of the authorization decision.

   This is required in order to support pre-paid (as opposed to
   subscription) scenarios (e.g. for VoIP).

2.3.7   It SHOULD be possible to support models where the authorization
   decision is made in advance of a service request.

   This is for some applications such as backup, where actions are
   scheduled for future dates. It also covers applications that require
   reservation of resources.

2.3.8   A AAA mechanism must allow time stamp information to be carried
   along with authorization information (e.g. for non-repudiation).

   The PKIX WG is developing a time stamp protocol, which can be used as
   part of a non-repudiation solution. In some environments it may be
   necessary that certain AAA protocol messages are timestamped (by a
   trusted authority) and that the timestamps are forwarded within
   subsequent AAA messages.

2.4 Topology

2.4.1   AAA protocols MUST be able to support the use of the push, pull
   and agent models.

   This states that a protocol that only supported one model, say pull,
   would not meet the requirements of all the applications. The models
   are defined in [FRMW].

2.4.2   In transactions/sessions, which involve more than one AAA
   entity, each "hop" MAY use a different push/pull/agent model.

   For example, in the mobile IP case, a "foreign" AAA server might pull
   authorization information from a broker, whereas the broker might
   push some authorization information to a "home" AAA server.




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


2.4.3   AAA Protocols MUST cater for applications and services where the
   entities involved in the application or AAA protocols belong to
   different (security) domains.

   This states that it must be possible for any AAA protocol message to
   cross security or administrative domain boundaries. Typically, higher
   levels of security will be applied when crossing such boundaries, and
   accounting mechanisms may also have to be more stringent.

2.4.4   AAA protocols MUST support roaming.

   Roaming here may also be thought of as "away-from-home" operation.
   For example, this is a fundamental requirement for the mobile IP
   case.

2.4.5   AAA protocols SHOULD support dynamic mobility

   Dynamic mobility here means that a client moves from one domain to
   another, without having to completely re-establish e.g. whatever AAA
   session information is being maintained.

2.4.6   An authorization decision MAY have to be made before the
   requestor has any other connection to a network.

   For example, this means that the requestor can't go anywhere on the
   network to fetch anything and must do requests via an
   application/service or via an intermediate AAA entity. The AAA
   protocol should not overexpose such a server to denial-of-service
   attacks.

2.4.7   AAA protocols MUST support the use of intermediate AAA entities
   which take part in authorization transactions but which don't "own"
   any of the end entities or authorization data.

   In some environments (e.g. roamops), these entities are termed
   brokers (though these are not the same as bandwidth brokers in the
   QoS environment).

2.4.8   AAA protocols MAY support cases where an intermediate AAA entity
   returns a forwarding address to a requestor or AAA entity, in order
   that the requestor or originating AAA entity can contact another AAA
   entity.

   This requirement recognizes that there will be routing issues with
   AAA servers, and that this requires that AAA protocols are able to
   help with such routing. For example, in the mobile IP case, a broker
   may be required, in part to allow the foreign and home AAA servers to
   get in contact.



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


2.4.9   It MUST be possible for an access decision function to discover
   the AAA server of a requestor. If the requestor provides information
   used in this discovery process then the access decision function MUST
   be able to verify this information in a trusted manner.

   This states that not only do AAA servers have to be able to find one
   another, but that sometimes an application entity may have to find an
   appropriate AAA server.

2.5 Application Proxying

2.5.1   AAA protocols MUST support cases where applications use proxies,
   that is, an application entity (C), originates a service request to a
   peer (I) and this intermediary (I) also initiates a service request
   on behalf of the client (C) to a final target (T).  AAA protocols
   MUST be such that the authorization decision made at T, MAY depend on
   the authorization information associated with C and/or with I. This
   "application proxying" must not introduce new security weaknesses in
   the AAA protocols. There MAY be chains of application proxies of any
   length.

   Note that this requirement addresses application layer proxying - not
   chains of AAA servers. For example, a chain of HTTP proxies might
   each want to restrict the content they serve to the "outside".  As