rfc2906.txt

RFC 的详细文档！

2.11.1  AAA protocols MUST support the ability to refer to sets of
   authorization packages in order to allow peers negotiate a common
   set.

   Given that peers may support different combinations of authorization
   attribute types and packages, the requirement states that protocol
   support is required to ensure that the peers use packages supported
   by both peers.

2.11.2  It MUST be possible to negotiate authorization packages between
   AAA entities that are not in direct communication.

   This states that where, e.g. a broker is involved, the end AAA
   servers might still need to negotiate.

2.11.3  Where negotiation fails to produce an acceptable common
   supported set then access MUST be denied.

   For example, a server cannot grant access if it cannot understand the
   attributes of the requestor.

2.11.4  Where negotiation fails to produce an acceptable common
   supported set then it SHOULD be possible to generate an error
   indication to be sent to another AAA entity.

   If negotiation fails, then some administrator intervention is often
   required, and protocol support for this should be provided.

2.11.5  It MUST be possible to pre-provision the result of a
   negotiation, but in such cases, the AAA protocol MUST include a
   confirmation of the "negotiation result".

   Even if the supported packages of a peer are configured, this must be
   confirmed before assuming both sides are similarly configured.





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


2.11.6  For each application making use of a AAA protocol, there MUST be
   one inter-operable IETF standards-track specification of the
   authorization package types that are "mandatory to implement".

   This requirement assures that communicating peers can count on
   finding at least one IETF specified inter-operable AAA protocol
   dialect provided they are doing authorization for a common
   application specific problem domain. This does not preclude the
   negotiation of commonly understood but private AAA protocol
   authorization package types (e.g. vendor specific).

2.11.7  It SHOULD also be possible to rank AAA negotiation options in
   order of preference.

   This states that, when negotiating, peers must be able to indicate
   preferences as well as capabilities.

2.11.8  The negotiation mechanisms used by AAA protocols SHOULD NOT be
   vulnerable to a "bidding-down" attack.

   A "bidding-down" attack is where an attacker forces the negotiating
   parties to choose the "weakest" option available. This is analogous
   to forcing 40-bit encryption on a link. The requirement highlights
   that protocol support is needed to prevent such attacks, for example
   by including the negotiation messages as part of a later MAC
   calculation, if authentication has produced a shared secret.

2.11.9  A peer MUST NOT send an attribute within an authorization
   package or attribute that was not agreed to by a prior successful
   negotiation. If this AAA protocol violation occurs, then it MUST be
   possible to send an error indication to the misbehaving peer, and
   generate an error indication to the network operator.

2.11.10 A peer MUST declare all of the sets of the authorization
   packages that it understands in its initial negotiation bid message.

3. Security Considerations

   This document includes specific security requirements.

   This document does not state any detailed requirements for the
   interplay with authentication, accounting or accountability (audit).
   A AAA protocol, which meets all of the above requirements, may still
   leave vulnerabilities due to such interactions. Such issues must be
   considered as part of AAA protocol design.






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


4. References

   [FRMW]     Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D.
              Spence, "AAA Authorization Framework", RFC 2904, August
              2000.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2138]  Rigney, C., Rubens, A., Simpson, W. and S. Willens,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2138, April 1997.

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", RFC 2277, January 1998.

   [SAMP]     Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D.
              Spence, "AAA Authorization Application Examples", RFC
              2905, August 2000.

Authors' Addresses

   Stephen Farrell
   Baltimore Technologies
   61/62 Fitzwilliam Lane
   Dublin 2,
   IRELAND

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   John R. Vollbrecht
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]




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


   Pat R. Calhoun
   Network and Security Research
   Center, Sun Labs
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park, California, 94025
   USA

   Phone:  [phone]
   Fax:  [phone]
   EMail:  [e-mail]


   Leon Gommans
   Enterasys Networks EMEA
   Kerkplein 24
   2841 XM  Moordrecht
   The Netherlands

   Phone: [phone]
   email: [e-mail]
          or at University of Utrecht:
          [e-mail]


   George M. Gross
   Lucent Technologies
   184 Liberty Corner Road, m.s.
   LC2N-D13
   Warren, NJ 07059
   USA

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]


   Betty de Bruijn
   Interpay Nederland B.V.
   Eendrachtlaan 315
   3526 LB Utrecht
   The Netherlands

   Phone: [phone]
   EMail: [e-mail]






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


   Cees T.A.M. de Laat
   Physics and Astronomy dept.
   Utrecht University
   Pincetonplein 5,
   3584CC Utrecht
   Netherlands
   Phone: [phone]
   Phone: [phone]
   EMail: [e-mail]


   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803

   EMail: [e-mail]


   David W. Spence
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]























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


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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Farrell, et al.              Informational                     [Page 23]