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

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

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

McDonald, Ira imcdonald at sharplabs.com
Mon Oct 2 14:52:06 EDT 2000


Copies: IETF IPP WG <ipp at 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.

Cheers,
- 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
   printer.

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.

------------------------------------------------------------------------



More information about the Ipp mailing list