[613] in Enterprise Print Delivery Team
Kerberos, Desktops, and IPM
daemon@ATHENA.MIT.EDU (Rocklyn Clarke)
Tue Oct 24 15:46:20 2000
Date: Tue, 24 Oct 00 15:44:01 EDT
From: Rocklyn Clarke <RCLARKE@MIT.EDU>
To: Enterprise Print Delivery Team <PRINTDEL@MIT.EDU>
Message-Id: <001024.154608.EDT.RCLARKE@MIT.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Hi Team,
Here is an overview of the issues surrounding authenticating to InfoPrint
Manager:
Authentication is the process of verifying the identity of another entity.
Authentication is a separate logical step from authorization (although it
usually precedes the process of determining authorizations). Properly
speaking authentication is concerned with "who you are", not "what you are
allowed to do'. In general authentication is achieved by means of a secret
shared between the two parties who wish to perform authentication. A password
is a simple example of such a "shared secret".
At MIT we use Kerberos (or SSL which will not be discussed here) to provide
authentication for network applications. The heart of Kerberos is the Kerberos
server which is basically a repository of "shared secrets" - the kerberos
passwords for each user defined in the kerberos realm. The Kerberos server
uses the secret that the two of you share (your kerberos password) to create
and deliver to you more "shared secrets" (i.e. kerberos tickets) which you can
use to authenticate yourself to other network services and which they, in turn,
can use to authenticate themselves to you. This is possible because the
Kerberos server already shares secrets (i.e. the contents of the srvtabs) with
each of the network servers that participate in this security arrangement.
Suggested Reading:
http://web.mit.edu/kerberos/www/
http://web.mit.edu/kerberos/www/dialogue.html
Traditional Kerberized LPR
--------------------------
KLPR runs on the client desktop and performs authenticated transmission of
print files from the desktop machine to the print server. KLPR achieves
authentication by presenting to the print server (if required) an appropriate
kerberos ticket previously acquired by the client. KLPR understands how
to communicate with the Kerberos server if necessary (e.g. if the client has
not yet obtained kerberos tickets). It also passes the ticket information to
the printserver in the same data stream that it used to pass the print files
(i.e. same IP address, same port).
Traditional InfoPrint Manager
-----------------------------
InfoPrint Manager is a sophisticated print server which is capable of accepting
print jobs via its own proprietary interfaces (e.g InfoPrint Select & Submit)
as well as via tradition LPR. When accessed via LPR it receives print files
through the traditional well-defined LPR port. IPM depends on the underlying
operating system (AIX in our case) for security. If AIX is configured to
authenticate, then IPM will do so. Otherwise, IPM will accept print jobs from
all comers without asking any questions. In the AIX world, authentication is
handled via DCE, which included Kerberos (version 5) and some other stuff we
don't use. Whether or not DCE running under AIX can be made to interoperate
with MIT's Kerberos infrastructure remains an open question. I tend to believe
that this can be done, but there are others in IS who have their doubts.
With DCE turned off (our current situation), IPM cannot handle the ticket
presented to it by a Kerberized LPR client. IF we turn DCE on (and reinstall
IPM with security turned on) and IF its Kerberos interoperates with MIT's then
it SHOULD be possible to use an unmodified KLPR to provide authenticated
desktop print file submission.
IPM Port Monitor
----------------
The IPM Port Monitor was developed in association with a web interface to IPM.
It functions very much like KLPR in that it creates or uses existing kerberos
tickets to obtain the identity of the client. Instead of passing this data
to IPM directly however, it sends it (along with the print files) to the web
server interface. IBM didn't have to do things this way, but it turned out
to be politically easier to provide back-end support for traditional (i.e.
non-DCE) Kerberos in the web server than it was to retrofit the support into
the basic IPM server software. Essentially, because the web server interface
is a custom developed product, modifying it was an easier choice to make. The
web protocols (including SSL) also make the task of securely delivering a
print file to the web server pretty easy. The web server then delivers the
print file to IPM itself.
The Port Monitor is similar to KLPR in that their inputs (i.e. a print file
and a kerberos ticket) are the same. They are different, in that the Port
Monitor expects to "talk" HTTP or HTTPS to a web server whereas KLPR expects
to talk LPR to a traditional print server.
Our Options:
1. Reconfigure IPM with DCE turned on and get it to interoperate with our
Kerberos. KLPR should then be able to work with IPM in authenticated
mode (unauthenticated works fine now).
2. Use the Port Monitor for authenticated printing to IPM and KLPR for
authenticated printing to other print servers.
3. Incorporate the Port Monitor function into KLPR so that it recognizes
when it needs to deal with IPM and make the appropriate protocal change.
This requires a software development effort.
4. Based on a conversation with Dan Cogswell (IBM) today, it MAY be possible
to run a kerberized lpd on our AIX box that would accept authenticated
print files from KLPR and pass them to IPM. This is my next step for
investigation.
I hope this helps!
Rocklyn
