rfc2906.txt

RFC 的详细文档！

   the HTTP GET message goes from HTTP proxy to HTTP proxy, this
   requirement states that it must be possible that the authorization
   decisions made at each stage can depend on the user at the browser,
   and not say, solely on the previous HTTP proxy's identity. Of course
   there may only be a single AAA server involved, or there may be many.

2.5.2   Where there is a chain of application proxies, the AAA protocol
   flows at each stage MAY be independent, i.e. the first hop may use
   the push model, the second pull, the third the agent model.

   This simply restates a previous requirement (no. 2.4.7), to make it
   clear that this also applies when application proxying is being used.

2.6 Trust Model

2.6.1   AAA entities MUST be able to make decisions about which other
   AAA entities are trusted for which sorts of authorization
   information.

   This is analogous to a requirement in public key infrastructures:
   Just because someone can produce a cryptographically correct public
   key certificate does not mean that I should trust them for anything,
   in particular, I might trust the issuer for some purposes, but not
   for others.



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


2.6.2   AAA protocols MUST allow entities to be trusted for different
   purposes, trust MUST NOT be an all-or-nothing issue.

   This relates the packaging (no. 2.1.3) and trust (no. 2.6.1)
   requirements. For example, a AAA entity may trust some parts of an
   authorization package but not others.

2.6.3   A confirmation of authorization MAY be required in order to
   initialize or resynchronize a AAA entity.

   This states that a AAA entity may need to process some AAA protocol
   messages in order to initialize itself. In particular, a AAA entity
   may need to check that a previous AAA message remains "valid", e.g.
   at boot-time.

2.6.4   A negation of static authorization MAY be required to shut down
   certain services.

   This is the converse of 2.6.5 above. It means that a AAA entity may
   be "told" by another that a previous AAA message is no longer
   "valid". See also 2.3.2 and 2.7.6.

2.6.5   It MUST be possible to configure sets of AAA entities that
   belong to a local domain, so that they are mutually trusting, but so
   that any external trust MUST be via some nominated subset of AAA
   entities.

   This states that for efficiency or organizational reasons, it must be
   possible to set up some AAA servers through which all "external" AAA
   services are handled. It also states that it must be possible to do
   this without over-burdening the "internal-only" AAA servers with
   onerous security mechanisms, just because some AAA servers do handle
   external relations.

2.6.6   Intermediate AAA entities in a chain MUST be able to refuse a
   connection approved by an earlier entity in the chain.

   For example, in mobile IP the home network may authorize a
   connection, but the foreign network may refuse to allow the
   connection due to the settings chosen by the home network, say if the
   home network will refuse to pay.

2.6.7   It SHOULD be possible to modify authorization for resources
   while a session is in progress without destroying other session
   information.






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


   For example, a "parent" AAA server should be able to modify the
   authorization state of sessions managed by a "child" AAA server, say
   by changing the maximum number of simultaneous sessions which are
   allowed.

2.7 Not just transactions

2.7.1   Authorization decisions MAY be context sensitive, AAA protocols
   MUST enable such decisions.

   This states that AAA protocols need to support cases where the
   authorization depends, (perhaps even only depends), on the current
   state of the system, e.g. only seven sessions allowed, seventh
   decision depends on existence of six current sessions. Since the
   context might involve more than one service, the AAA protocol is
   likely to have to offer some support.

2.7.2   AAA protocols SHOULD support both the authorization of
   transactions and continuing authorization of sessions.

   This states that AAA entities may have to maintain state and act when
   the state indicates some condition has been met.

2.7.3   Within a single session or transaction, it MUST be possible to
   interleave authentication, authorization and accounting AAA messages.

   This states, that e.g. a session may have to use initial
   authentication, authorization and accounting AAA message(s), but also
   have to include e.g. re-authentication every 30 minutes, or a
   continuous "drip-drip" of accounting AAA messages.

2.7.4   Authorization decisions may result in a "not ready" answer.

   This states that yes and no are not the only outcomes of an
   authorization decision. In particular, if the AAA entity cannot yet
   give a decision, it might have to return such a result. This is
   analogous to how public key certification requests are sometimes
   handled in PKI management protocols.

2.7.5   A AAA entity MAY re-direct a AAA request that it has received.

   This states that if entity "a" asks "b", then "b" may say: "don't ask
   me, ask 'c'". This is analogous to HTTP re-direction (status code
   307).

2.7.6   AAA protocols SHOULD allow a AAA entity to "take back" an
   authorization.




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


   The expectation is that AAA protocols will support the ability of a
   AAA entity to signal an application or other AAA entity that an
   authorization (possibly previously granted by a third AAA entity) is
   no longer valid.

2.8 Administration

2.8.1   It MUST be possible for authorization data to be administered on
   behalf of the end entities and AAA entities.

   This requirement indicates that administration of AAA has to be
   considered as part of protocol design - a AAA protocol, which
   required all AAA entities act independent of all other AAA entities,
   would not meet the requirement.

2.8.2   Centralizable administration of all features SHOULD be
   supported.

   It should be possible (if it meets the domain requirements) to
   centralize or distribute the administration of AAA.

2.8.3   AAA protocols SHOULD support cases where the user (as opposed to
   an administrator) authorizes a transaction.

   For example, a user might want to control anti-spam measures or
   authorize things like a purchase. In such cases, the user is acting
   somewhat like an administrator.

2.8.4   One AAA entity MAY create authorization rules for another AAA
   entity.

   This is required to properly support delegation of authority, however
   when allowed, this must be able to be done in a secure fashion.

2.8.5   AAA protocols SHOULD support failure recovery when one AAA
   entity in a chain of AAA entities that maintain state about a session
   fails.

   For example, in a network access situation it may be required that a
   AAA server which has crashed be able to determine how many sessions
   are in progress, in order to make the "next" authorization decision.

2.8.6   It SHOULD be possible for a AAA entity to query the
   authorization state of another AAA entity.

   This may be required as part of a failure recovery procedure.





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


2.8.7   AAA protocols MUST be able to support "hot fail-over" for server
   components without loss of state information.

   This states that AAA protocols must be able to support cases where,
   when a server is no longer operable, a secondary server can
   automatically be brought "live" without losing important state
   information.

2.9 Bytes on-the-wire

2.9.1   Authorization separate from authentication SHOULD be allowed
   when necessary, but the AAA protocols MUST also allow for a single
   message to request both authentication and authorization.

   AAA protocols have to allow a split between authentication and
   authorization so that different mechanisms are used for each. This
   states that sometimes both types of information need to be carried in
   the same message.

2.9.2   In order to minimize resource usage (e.g. reduce roundtrips) it
   MUST be possible to embed AAA PDUs into other protocols.

   This states that the AAA protocol authorization packages must be
   defined so that they can also be carried in other protocols. For
   example, depending on AAA protocol header information in order to
   reference an authorization package could cause a protocol to fail to
   meet the requirement.

2.9.3   A AAA protocol MAY provide mechanisms for replication of state
   information.

   This can be required e.g. to support resiliency in cases where hot
   fail-over is required. Note that AAA protocols are of course, subject
   to normal protocol design requirements to do with reliability, no
   single-point-of-failure etc even though these are not all specified
   here.

2.9.4   A AAA protocol SHOULD allow the possibility for implementation
   of a gateway function between the AAA protocol and other legacy AAA
   related protocols.

   For example, some form of support for [RFC2138] as a legacy protocol
   is very likely to be required. Of course, the use of such a gateway
   is almost certain to mean not meeting some other requirements, (e.g.
   end-to-end security), for transactions routed through the gateway.
   There is no implication that such gateway functionality needs to be a
   separate server.




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


2.9.5   A AAA protocol MUST be able to support use of a wide range of
   primitive data types, including RFC2277.

   For example, various sized, signed and unsigned integers, possibly
   including multi-precision integers will almost certainly need to be
   transported. Floating point support according to ANSI IEEE 754-1985
   may also be required.

2.9.6   A AAA protocol transport SHOULD support being optimized for a
   long-term exchange of small packets in a stream between a pair of
   hosts.

   NASes typically have a high number of transactions/second, so the AAA
   protocol MUST allow the flow of requests to be controlled in order
   for the server to make efficient use of it's receive buffers.

2.9.7   A AAA protocol MUST provide support for load balancing.

   In the event that a peer's cannot receive any immediate requests, the
   AAA protocol MUST allow for an implementation to balance the load of
   requests among a set of peers.

2.10    Interfaces

2.10.1  It SHOULD be possible that authorization data can be used for
   application purposes.

   For example, in web access, if the authorization data includes a
   group name, mechanisms to make this data available to the application
   so that it can modify the URL originally requested are desirable.

2.10.2  It SHOULD be possible that authorization data can be used to
   mediate the response to a request.

   For example, with web access the clearance attribute value may affect
   the content of the HTTP response message.

2.10.3  AAA protocols SHOULD be able to operate in environments where
   requestors are not pre-registered (at least for authorization
   purposes, but possibly also for authentication purposes).

   This is necessary to be able to scale a AAA solution where there are
   many requestors.

2.10.4  AAA protocols MUST be able to support a linkage between
   authorization and accounting mechanisms.

   Motherhood and apple-pie.



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


2.10.5  AAA protocols MUST be able to support accountability
   (audit/non-repudiation) mechanisms.

   Sometimes, an authorization decision will be made where the requestor
   has not authenticated. In such cases, it must be possible that the
   authorization data used is linked to audit or other accountability
   mechanisms. Note that this requirement does not call for mandatory
   support for digital signatures, or other parts of a non-repudiation
   solution.

2.11    Negotiation