IPP Mail Archive: IPP> IPP Authorization Models - excerpt fr

IPP Mail Archive: IPP> IPP Authorization Models - excerpt fr

IPP> IPP Authorization Models - excerpt from RFC 2905 - please review

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Oct 02 2000 - 14:52:06 EDT

  • Next message: Carl-Uno Manros: "RE: IPP> IPP Authorization Models - excerpt from RFC 2905 - please review"

    Copies: IETF IPP WG <ipp@pwg.org>

    Hi folks, Monday (2 October 2000)

    I found this interesting section on possible IPP authorization models
    in 'AAA Authorization Application Examples', RFC 2905, August 2000.
    It addresses IPP print-by-reference (the Print-URI operation).

    Feedback to the IRTF (Internet Research Task Force) AAAarch RG (Research
    Group) from IPP designers and implementors would be timely.

    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc


    [from 'ftp://ftp.isi.edu/in-notes/rfc2905.txt', pages 25-28]

    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

    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
       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.

          +------+ +----------------------+
          | |------>| 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
       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.


    This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 15:01:46 EDT