rfc2903.txt

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

3.5.  AAA-TSM Service Layer Program Interface Primitives

   The AAA-TSM service layer and its adjacent presentation service layer
   communicate across their boundary through a set of program interface
   primitives.  A key design goal is to keep these primitives the same
   regardless of the higher level AAA application, analogous to a
   callable "plug-in".  The two service layers are responsible for
   coordinating their state information.  This responsibility includes
   all of the pending Authorization requests and the Authorization
   Sessions that they are both controlling and monitoring.  The initial
   contact between these two layers is through an abstract object that
   is called an AAA-TSM Service Access Point (SAP).  A particular
   service instance between these two layers is realized in an abstract
   object that is called an Authorized Session.  The presentation
   service layer invokes AAA-TSM interface primitives against an AAA-TSM
   SAP.

   The AAA-TSM service layer interface primitives can be broadly
   characterized as follows:

   -  Register a presentation end point address identifier and its
      associated set of attributes to a service access point.




de Laat, et al.               Experimental                     [Page 20]

RFC 2903                Generic AAA Architecture             August 2000


   -  Send a presentation layer message to a specified destination
      presentation layer peer end point address.

   -  Receive a presentation layer message from another presentation
      layer end point address.  A receive operation may select a
      specific originating presentation layer end point address from
      which the message is expected, or receive a message from any
      presentation layer peer.

   -  The AAA-TSM service layer calls an application specific
      authorization decision function, which returns a condition code
      expressing an approval, denial, or partially approves with a
      referral to another AAA Server.

   -  AAA-TSM service layer tells the presentation layer to commit an
      earlier partially approved authorization request.

   -  Cancel an earlier partially approved authorization request (i.e.
      rollback).

   -  The presentation service layer notifies the AAA-TSM service layer
      that it has terminated an in-progress Authorized Session.

   -  AAA-TSM service layer notifies the presentation service layer that
      another presentation service layer peer has terminated an
      Authorized Session.

   -  Un-register a presentation service layer end point address.

3.6.  AAA-TSM Layer End Point Name Space

   The AAA-TSM service layer end point name space is the N-tuple formed
   by concatenating the following components:

   -  AAA Server's Reliable/Secure Transport layer end point address

   -  AAA-TSM authorization request serial number, a unique durable
      unsigned integer generated by the AAA Server who first receives
      the User's authorization request.

   Some AAA applications may require that each assigned AAA-TSM
   transaction serial number be stored in persistent storage, and
   require that it be recoverable across AAA Server system re-boots.
   The serial number generation algorithm must be guaranteed unique even
   if the AAA Server does a re-boot.






de Laat, et al.               Experimental                     [Page 21]

RFC 2903                Generic AAA Architecture             August 2000


3.7.  Protocol Stack Examples

   The layering paradigm makes it possible to use the most appropriate
   syntax for each application for encoding the Application Specific
   Information units of that application.  This encoding would take
   place at the presentation layer.  Similarly the application layer can
   recognize the semantics specific to each application.  Figure 6
   illustrates some possible AAA protocol stacks.

   +------------++------------++-----------++-----------++----------+
   |            || Application|| E-Commerce|| Bandwidth || Roaming &|
   |    AAA     ||  specific  || Internet  ||  Broker   || mobile IP|
   | Application||object class||   Open    ||cross-admin||  remote  |
   |  Service   || interface  ||  Trading  ||  domain   ||  access  |
   |   Layer    ||specified in|| Protocol  ||   COPS    ||   AVP    |
   |            || CORBA IDL  ||  (IOTP)   || extensions|| lexicons |
   +------------++------------++-----------++-----------++----------+
   |            ||   CORBA    ||Extensible ||  Common   || DIAMETER |
   |Presentation||  Generic   ||  Markup   ||   Open    ||    or    |
   |  Service   || Inter-ORB  || Language  ||  Policy   ||  RADIUS  |
   |   Layer    ||  Protocol  ||   (XML)   ||Specificatn||Attribute |
   |            ||   (GIOP)   ||           ||  (COPS)   ||Value/Pair|
   +------------++------------++-----------++-----------++----------+
   |   AAA-TSM Service Layer Application Program Interface (API)    |
   +----------------------------------------------------------------+
   |   AAA Transaction/Session Management (AAA-TSM) Service Layer   |
   +----------------------------------------------------------------+
   |                Reliable Secure Transport Layer                 |
   +----------------------------------------------------------------+

                 Fig. 6 -- Possible AAA Protocol Stacks

4.  Security Considerations

   Security considerations for the framework on which the work described
   in this memo is based are discussed in [2].  Security requirements
   for authorization are listed in section 2.2 of [3].

   This memo identifies a basic set of AAA functions that are general in
   nature and common to many different AAA applications.  We propose
   that a standard set of security mechanisms should be defined as part
   of a base AAA protocol which would include such things as public key
   encryption and digital signatures that could be applied to individual
   information units within an AAA message.  Security with this
   granularity is needed to meet the end-to-end security requirement
   specified in section 2.2.7 of [3] because a single AAA message may





de Laat, et al.               Experimental                     [Page 22]

RFC 2903                Generic AAA Architecture             August 2000


   contain multiple information units each generated by AAA servers from
   different administrative domains and destined to AAA servers in
   different domains.

   In addition, it may be necessary to encrypt or sign an entire AAA
   message on a hop-by-hop basis.  This could be handled by a standard,
   lower layer protocol such as IPSEC.  If so, then certain auditing
   requirements will have to be met so that it can be established later
   that the messages relative to some specific session ID were, in fact,
   protected in a particular way.  Alternatively, hop-by-hop security
   mechanisms may be built into the base AAA protocol itself.

Glossary

   Application Specific Information (ASI) -- information in an AAA
      protocol message that is specific to a particular application.

   Application Specific Module (ASM) -- a software module that
      implements a program interface to a generic AAA server which
      handles application specific functionality for an AAA protocol
      message.

   Service Provider -- an organization which provides a service.

   User -- the entity seeking authorization to use a resource or a
      service.

   User Home Organization (UHO) -- An organization with whom the User
      has a contractual relationship which can authenticate the User and
      may be able to authorize access to resources or services.





















de Laat, et al.               Experimental                     [Page 23]

RFC 2903                Generic AAA Architecture             August 2000


References

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

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

   [3]  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.

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

   [5]  Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis, "The
        KeyNote Trust-Management System Version 2", RFC 2704, September
        1999.

Authors' Addresses

   Cees T.A.M. de Laat
   Physics and Astronomy dept.
   Utrecht University
   Pincetonplein 5,
   3584CC Utrecht
   Netherlands

   Phone: [phone]
   Phone: [phone]
   EMail: [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]







de Laat, et al.               Experimental                     [Page 24]

RFC 2903                Generic AAA Architecture             August 2000


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

   Phone: [phone]
   email: [e-mail]
          or at University of Utrecht:
          [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]


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

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



















de Laat, et al.               Experimental                     [Page 25]

RFC 2903                Generic AAA Architecture             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.



















de Laat, et al.               Experimental                     [Page 26]