rfc2905.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,607 行 · 第 1/5 页

Vollbrecht, et al.           Informational                     [Page 23]

RFC 2905         AAA Authorization Application Examples      August 2000


   consistency with its own service level specifications and respond
   with Setup Answer message (SA) agreements. This message exchange
   confirms and identifies pre-established service authorization levels.

4.6.5.3.  Service Cancellation

   A Service Cancellation (SC) message may cancel a service
   authorization. This message may be initiated by the operator or by an
   expiration date. A Cancellation Answer (CA) is returned.

4.6.5.4.  Service Renegotiation

   An (optional) Service-Renegotiation message (SR) may allow a
   Bandwidth Broker to re-negotiate an existing service.  This message
   may be initiated by the operator or automatically when a certain
   threshold is reached.  Renegotiations happen within the margins of a
   pre-established authorization.

4.6.5.5.  Resource Allocation Request and Resource Allocation Answer

   An RAR allocates a requested level of service on behalf of the User
   and when available it will decide on the admittance of a certain User
   to the service. A Bandwidth Broker may receive an RAR via either the
   intra-domain or inter-domain interface.  The RAR must refer to the
   Service SetUp Identification (SSU_ID), which binds a request to a
   certain authorization. A Resource Allocation Answer (RAA) confirms or
   rejects a request or it may indicate an "in progress" state.

4.6.5.6.  Session Maintenance

   A certain level of session maintenance is required to keep Bandwidth
   Brokers aware of each other.  This must be implemented using time-
   outs and keep-alive messages.  This will help Bandwidth Brokers to
   notice when other Bandwidth Brokers disappear.

4.6.5.7.  Intra-domain Interface Protocol

   The Intra-domain interface protocol used between a Bandwidth Broker
   and the routers it controls may be COPS, SNMP, or Telnet Command Line
   Interface.

4.7.  Requirements

   From the above descriptions we derive the following requirements.







Vollbrecht, et al.           Informational                     [Page 24]

RFC 2905         AAA Authorization Application Examples      August 2000


   -  The Authorization mechanism may require trust relationships to be
      established before any requests can be made from the User to the
      Service Provider.  Currently trust relationship establishment is
      implicit.

   -  A confirmation of authorization is required in order to initialize
      the system.

   -  A negation of static authorization is required to shut down
      certain services.

   -  A renegotiation of static authorization is required to alter
      services (SLS's).

   -  Dynamic authorization requests (RAR) must fit into pre-established
      static authorizations (SLS's).

   -  Dynamic authorization requests (RAR) may be answered by an "in
      progress state" answer.

   -  Provisions must be made to allow reconstruction of authorization
      states after a Bandwidth Broker re-initializes.

5.  Internet Printing

   The Internet Printing Protocol, IPP [14], has some potentially
   complex authorization requirements, in particular with the "print-
   by-reference" model.  The following attempts to describe some
   possible ways in which an authorization solution for this aspect of
   IPP might work, and to relate these to the framework described in
   [2].  This is not a product of the IPP working group, and is meant
   only to illustrate some issues in authorization in order to establish
   requirements for a "generic" protocol to support AAA functions across
   many applications.

   IPP print-by-reference allows a user to request a print service to
   print a particular file.  The user creates a request to print a
   particular file on a printer (or one of a group of printers).  The
   key aspect is that the request includes only the file name and not
   the file content. The print service must then read the file from a
   file server prior to printing.  Both the file server and the print
   server must authorize the request.  Once initiated, printing will be
   done without intervention of the user; i.e., the file will be sent
   directly to the print service rather than through the user to the
   printer.






Vollbrecht, et al.           Informational                     [Page 25]

RFC 2905         AAA Authorization Application Examples      August 2000


5.1.  Trust Relationships

   The assumption is that the Printer and File Server may be owned and
   operated by different organizations.  There appear to be two models
   for how "agreements" can be set up.

   1. User has agreement with Print Server; Print Server has agreement
      with File Server.

   2. User has agreements with both File and Print Server directly.

   In case 1, the user has a trust relationship with the Print Service
   AAA Server.  The Printer forwards the request to the File Server. The
   File Server authorizes the Printer and determines if the Printer is
   allowed access to the file.  Note that while there may be some cases
   where a Print Server may on its own be allowed access to files
   (perhaps some "public files", or that can only be printed on certain
   "secure" printers), it is normally the case that files are associated
   with users and not with printers.  This is not a good "generic" model
   as it tends to make the print service an attractive point of attack.

            +------+       +----------------------+
            |      |       | File Service         |----+
            |      |       | AAA Server           |<-+ |
            |      |       +----------------------+  | |
            |      |       |                      |  | |
            |      |       | File Server          |  | |
            |      |       |                      |  | |
            | User |       +----------------------+  | |
            |      |                                 | |
            |      |                                 | |
            |      |                                 | |
            |      |       +----------------------+  | |
            |      |------>| Print Service        |--+ |
            |      |<------| AAA Server           |<---+
            |      |       +----------------------+
            |      |       | Print Server         |
            |      |       |  and Printer         |
            +------+       +----------------------+

          Fig. 12 -- Case 1
                     User authorizes with Print Service.
                     Printer authorizes with File Service.

   In case 2, the user must have a trust relationship with both the file
   and print services so that each can verify the service appropriate to
   the User.  In this case, the User first contacts the File Service AAA
   Server and requests that it enable authorization for the Print



Vollbrecht, et al.           Informational                     [Page 26]

RFC 2905         AAA Authorization Application Examples      August 2000


   Service to access the file.  This might be done in various ways, for
   example the File Service AAA Server may return a token to the User
   which can (via the Print Service) be presented to the File Server to
   enable access.

               +------+       +----------------------+
               |      |------>| File Service         |
               |      |<------| AAA Server           |
               |      |       +----------------------+
               |      |
               |      |       +----------------------+
               |      |       | File Server          |
               | User |       +----------------------+
               |      |              /|\  |
               |      |               |   |
               |      |               |  \|/
               |      |       +----------------------+
               |      |------>| Print Service        |
               |      |<------| AAA Server           |
               |      |       +----------------------+
               |      |       | Print Server         |
               |      |       |  and Printer         |
               +------+       +----------------------+

         Fig. 13 -- Case 2
                    User authorizes File and Print Service.
                    Must create binding for session between
                    Print Service and File Service.

5.2.  Use of Attribute Certificates in Print-by-Reference

   The print-by-reference case provides a good example of the use of
   attribute certificates as discussed in [2].  If we describe case 2
   above in terms of attribute certificates (ACs) we get the diagram
   shown in figure 14.
















Vollbrecht, et al.           Informational                     [Page 27]

RFC 2905         AAA Authorization Application Examples      August 2000


      +------+       +----------------------+
      |      |------>| File Service         |
      |      |<------| AAA Server           |
      |      |Get AC +----------------------+
      |      |
      |      |       +----------------------+
      |      |       | File Server          |----+
      |      |       |                      |<-+ |
      | User |       +----------------------+  | |
      |      |                                 | |
      |      |   +---authorize passing AC      | |<---Create session
      |      |   |                             | |    Using AC
      |      |   V   +----------------------+  | |
      |      |------>| Print Service        |  | |
      |      |<------| AAA Server           |  | |
      |      |       +----------------------+  | |
      |      |       | Print Server         |--+ |
      |      |       |  and Printer         |<---+
      +------+       +----------------------+

       Fig. 14 -- Using Attribute Certificates in IPP Authorization

   In this case, the User gets an AC from the File Service's AAA Server
   which is signed by the File Service AAA Server and contains a set of
   attributes describing what the holder of the AC is allowed to do. The
   User then authorizes with the Print Service AAA Server and passes the
   AC in the authorization request.  The Printer establishes a session
   with the File Server, passing it the AC.  The File Server trusts the
   AC because it is signed by the File Service AAA Server and allows (or
   disallows) the session.

   It is interesting to note that an AC could also be created and signed
   by the User, and passed from the Print Server to the File Server. The
   File Server would need to be able to recognize the User's signature.
   Yet another possibility is that the Print Service AAA Server could
   simply authenticate the User and then request an AC from the File
   Service AAA Server.

5.3.  IPP and the Authorization Descriptive Model

   The descriptive model presented in [2] includes four basic elements:
   User, User Home Organization, Service Provider AAA Server, and
   Service Equipment.

   Mapping these to IPP, the User is the same, the User Home
   Organization (if included) is the same.  The Service Provider AAA
   Server and the Service Equipment  are expected to be closely coupled
   on the same processor.  In other words, the interface between the



Vollbrecht, et al.           Informational                     [Page 28]

RFC 2905         AAA Authorization Application Examples      August 2000


   Print Service AAA Server and the Printer as well as that between the
   File Service AAA Server and the File Server is an internal one that
   will not require a formal protocol (although some standard API might
   be useful).

   The concept of a Resource Manager (see [2]) has some interesting
   twists relative to IPP.  Once started, the user is not involved in
   the service, but until printing is complete it seems useful that any
   of the parties in the authorization process be allowed to query for
   status or to cancel the print session.   The user needs a way to
   "bind" to a particular session, and may have to reauthorize to be
   allowed to access Resource Manager information.

6.  Electronic Commerce

   This section describes the authorization aspects of an e-commerce
   architecture typically used in Europe.  We will use this model to
   identify contractual and trust relationships and message exchanges.
   We will then identify a set of authorization requirements for e-
   commerce.

   Whereas most e-commerce protocols focus on authentication and message
   integrity, e-commerce exchanges as described by the Internet Open
   Trading Protocol (trade) Working Group in [15] also involve
   authorization.  This section will examine one e-commerce protocol
   called SET (Secure Electronic Transaction) that provides for credit
   and debit card payments.  We will analyze the authorization aspects
   from an architectural viewpoint.  We will apply concepts and terms
   defined in [2].

   We are not here proposing SET as a standard authorization protocol.
   Rather, we are examining the SET model as a way of understanding the
   e-commerce problem domain so that w