Ira,
Thanks for pointing this out. Indeed I initiated a request to the AAA people
some two years ago that this was a problem we wanted solved for IPP. Earlier
this year I was told that the subject had been taken off the AAA agenda, but
I am happy to learn that somebody has done something after all..
Carl-Uno
> -----Original Message-----
> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald,
> Ira
> Sent: Monday, October 02, 2000 11:52 AM
> To: 'ipp@pwg.org'
> Subject: 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.
>
> 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.
>
> ------------------------------------------------------------------------
>
This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 15:54:53 EDT