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