Context Navigation

source: trunk/third/lprng/doc/LPRng-HOWTO-16.html @ 13098

Visit:

Revision 13098, 30.9 KB checked in by danw, 26 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r13097, which included commits to RCS files with non-trunk default branches.

Line
1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2	<HTML>
3	<HEAD>
4	<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
5	<TITLE> LPRng-HOWTO: Authentication and Encryption</TITLE>
6	<LINK HREF="LPRng-HOWTO-17.html" REL=next>
7	<LINK HREF="LPRng-HOWTO-15.html" REL=previous>
8	<LINK HREF="LPRng-HOWTO.html#toc16" REL=contents>
9	</HEAD>
10	<BODY>
11	<A HREF="LPRng-HOWTO-17.html">Next</A>
12	<A HREF="LPRng-HOWTO-15.html">Previous</A>
13	<A HREF="LPRng-HOWTO.html#toc16">Contents</A>
14	<HR>
15	<H2><A NAME="authref"></A> <A NAME="s16">16. Authentication and Encryption</A></H2>
16
17	<P>One of the major problems in a print spooler system is providing
18	privacy and authentication services for users. One method is to
19	construct a specific set of protocols which will be used for
20	providing the privacy or authentication; another is to provide a
21	simple interface to a set of tools that will do the authentication
22	and/or encryption.
23	<P>LPRng provides native support for the LPR extensions used by MIT
24	and the Kerberos 4 implementation.
25	In addition,
26	it provides Kerberos 5 based authentication.
27	<P>LPRng also supports the use of the PGP (Pretty Good Privacy) program
28	and can sign and optionally encrypt command and reponses between servers
29	and clients.
30	<P>Finally,
31	LPRng provide a general purpose interface allowing users to insert their
32	own authentication methods,
33	either at the program level or at the code level.
34	<H2><A NAME="ss16.1">16.1 Authentication</A>
35	</H2>
36
37	<P>A careful study of the authentication problem shows that it should be done
38	during reception of commands and/or jobs from a remote user and/or
39	spooler. At this time the following must be done:
40	<OL>
41	<LI>The received command must be checked for consistency, and the
42	remote user and host must be determined.</LI>
43	<LI>The remote user and host must be authenticated.</LI>
44	<LI>The command and/or spooling operation must be carried out.</LI>
45	<LI>The results must be returned to the remote system.</LI>
46	</OL>
47	<P>
48	<H2><A NAME="ss16.2">16.2 Identifiers</A>
49	</H2>
50
51	<P>When a user logs into a system, they are assigned a user name
52	and a corresponding UserID. This user name is used by the LPRng
53	software when transferring jobs to identify the user.
54	<P>When we look into the problem of authentication, we will possibly
55	have a more global user identification to deal with, the
56	authentication identifier (AuthID). One way to deal with this problem is to
57	give LPRng intimate knowledge of the UserID and AuthID relationship.
58	While this is possible, it may be difficult to deal with in a
59	simple and extensible manner. An alternate solution is to provide
60	a mapping service, where the authentication procedure provides
61	a map between the UserID and AuthID.
62	<H2><A NAME="ss16.3">16.3 RFC1179 Protocol Extensions</A>
63	</H2>
64
65	<P>The RFC1179 protocol specifies that a LPD server command sent on
66	a connection has the form:
67	<BLOCKQUOTE><CODE>
68	<PRE>
69	\nnn[additional fields]\n
70	</PRE>
71	</CODE></BLOCKQUOTE>
72	<P><CODE>\nnn</CODE> is a one octet (byte) value with the following meaning:
73	<P>
74	<BLOCKQUOTE><CODE>
75	<PRE>
76	REQ_START 1 start printer
77	REQ_RECV 2 transfer a printer job
78	REQ_DSHORT 3 print short form of queue status
79	REQ_DLONG 4 print long form of queue status
80	REQ_REMOVE 5 remove jobs
81	</PRE>
82	</CODE></BLOCKQUOTE>
83	<P>The LPRng system extends the protocol with the following additional
84	types:
85	<BLOCKQUOTE><CODE>
86	<PRE>
87	REQ_CONTROL 6 do control operation
88	REQ_BLOCK 7 transfer a block format print job
89	REQ_SECURE 8 do operation with authentication
90	REQ_VERBOSE 9 verbose status information
91	REQ_LPSTAT 10 lpstat simulation
92	</PRE>
93	</CODE></BLOCKQUOTE>
94	<P>The REQ_CONTROL allows a remote user to send LPC commands to the
95	server. The REQ_BLOCK provides an alternate method to transfer a
96	job. Rather than transferring the control and data files individually,
97	this format transfers one file. The REQ_AUTH provides a mechanism
98	for providing an authentication mechanism and is described in this
99	document.
100	<H2><A NAME="authserverid"></A> <A NAME="authclientfilter"></A> <A NAME="auth"></A> <A NAME="ss16.4">16.4 Client Operations for Client To lpd Server Authentication</A>
101	</H2>
102
103	<P>Options used:
104	<UL>
105	<LI> <CODE>auth=</CODE><EM>client to server authentication type</EM></LI>
106	<LI> <CODE>auth_client_filter=</CODE><EM>client to server transfer program</EM></LI>
107	<LI> <CODE>auth_forward=</CODE><EM>server to server authentication type</EM></LI>
108	<LI> <CODE>auth_forward_filter=</CODE><EM>server to server transfer program</EM></LI>
109	<LI> <CODE>auth_forward_id=</CODE><EM>Server identification</EM></LI>
110	<LI> <CODE>auth_receive_filter=</CODE><EM>server to server transfer program</EM></LI>
111	<LI> <CODE>auth_server_id=</CODE><EM>server identification</EM></LI>
112	</UL>
113	<P>This section describes the general purpose interface used for
114	client to server authentication.
115	<P>The LPRng client will generate a set of commands and place them in a file.
116	The file is then encrypted and/or signed by the appropriate authentication
117	method,
118	and is transferred to the server.
119	The server will then decrypt and/or check the signature,
120	perform the requested actions,
121	and in turn generate a file of status information.
122	This file is encrypted and/or signed by the server,
123	and sent to the client,
124	where it is in turn decrypted and/or checked for correct signature.
125	These activities are controlled by the following printcap or configuration
126	options.
127	<OL>
128	<LI>The <CODE> auth </CODE> option specifies the authentication type to be used
129	for client to server transfers.
130	For example,
131	<CODE>auth=pgp</CODE> would specify PGP authentication,
132	<CODE>auth=kerberos5</CODE> would specify Kerberos 5 authentication,
133	<CODE>auth=kerberos4</CODE> would specify Kerberos 4 authentication,
134	and
135	<CODE>auth=user</CODE> would specify using user provided filters for authentication.</LI>
136	<LI>For client to server operations,
137	the server id is the value of the
138	<CODE>auth_server_id</CODE> option.</LI>
139	<LI>The <CODE>auth_forward</CODE>> option specifies the authentication type to be used
140	for server to server transfers.</LI>
141	<LI>For server to server operations,
142	the id of the originating server
143	is specified by
144	<CODE>auth_server_id</CODE>.
145	and the remote server by
146	<CODE>auth_forward_id</CODE>.</LI>
147	<LI>When doing client to server transfers,
148	the originating user is determined by using the current UID
149	of the program as the search value for <CODE>getpwuid()</CODE>.</LI>
150	</OL>
151	<P>The LPRng client will open a connection to the server
152	and send a command with the following format:
153	<BLOCKQUOTE><CODE>
154	<PRE>
155	\008printer C userid auth\n - for commands
156	\008printer C userid auth jobsize\n - for print jobs
157	</PRE>
158	</CODE></BLOCKQUOTE>
159	<P>Note that \008 is a one byte code indicating an authenticated
160	transfer. Printer is the spool queue name, C in the character 'C'
161	indicating a client request, userid is the login id of the user,
162	auth is the the value of the <CODE>auth</CODE> option,
163	and jobsize is the size of the job file to be printed.
164	<P>On reception of this command, the server will send a one byte
165	success code.
166	If an error is indicated by a non-zero response,
167	additional error status may follow
168	the non-zero success code byte. At the end of this information
169	the connection will be terminated.
170	The values used by LPRng are:
171	<BLOCKQUOTE><CODE>
172	<PRE>
173	ACK_SUCCESS 0 success
174	ACK_STOP_Q 1 failed; no spooling to the remote queue
175	ACK_RETRY 2 failed; retry later
176	ACK_FAIL 3 failed; job rejected, no retry
177	</PRE>
178	</CODE></BLOCKQUOTE>
179	<P>If the success code is zero,
180	client will use the <CODE>auth_client_filter</CODE> to encrypt and/or sign
181	a data file to be transferred to the server.
182	The authentication program will have the following IO assignments:
183	<BLOCKQUOTE><CODE>
184	<PRE>
185	FD Options Purpose
186	0 R/W connection to remote host
187	1 W output for returned status
188	2 W errors
189	</PRE>
190	</CODE></BLOCKQUOTE>
191	<P>Command line arguments:
192	<BLOCKQUOTE><CODE>
193	<PRE>
194	program -C -Pprinter -nuser -Aauth -Rauth_server_id -Ttempfile
195	</PRE>
196	</CODE></BLOCKQUOTE>
197	<P>The <CODE> tempfile </CODE> will contain either a command line as would be
198	transferred using the standard RFC1179 protocol,
199	or a print job in block format.
200	See
201	<A HREF="LPRng-HOWTO-18.html#rfc1179ref">RFC1179 Protocol</A> for details.
202	The client authenticator program will open and transfer
203	the contents of <CODE>tempfile</CODE> to the server authenticator,
204	using FD 0
205	and a format compatible with the underlying authentication mechanism.
206	<P>If the transfer fails the client
207	authenticator will log error information on FD 2 and then exit
208	with error code JFAIL.
209	<P>The server will send the client authentication program
210	any error or logging information over the FD 0 connection,
211	in a form appropriate to the authentication operation.
212	The client authenticator will write this information to FD 1.
213	If data transfer or authentication fails, the authenticator
214	will write an error message to FD 2 and exit with error code
215	JFAIL.
216	<P>If no error has occured the client authenticator will
217	then exit with error code JSUCC.
218	<P>
219	<H2><A NAME="authforwardfilter"></A> <A NAME="authreceivefilter"></A> <A NAME="ss16.5">16.5 Server Operations for Client To lpd Server Authentication</A>
220	</H2>
221
222	<P>Options used:
223	<UL>
224	<LI> <CODE>auth_receive_filter=</CODE><EM>Server (lpd) authentication program</EM></LI>
225	<LI> <CODE>auth_server_id=</CODE><EM>Server identification</EM></LI>
226	</UL>
227	<P>When an authentication command arrives at the server,
228	it has the following form:
229	<BLOCKQUOTE><CODE>
230	<PRE>
231	\008printer C userid auth\n - for commands
232	\008printer C userid auth jobsize\n - for print jobs
233	</PRE>
234	</CODE></BLOCKQUOTE>
235	<P>The server will attempt to find the printcap for the specified printer.
236	For some operations this printer will be a dummy entry;
237	this will simply cause the following operations to use the default
238	information in the <CODE>lpd</CODE> configuration.
239	<P>If a print job is being performed and the spool queue does not exist,
240	then the job will be rejected.
241	A non-zero error code will be written to the connection and the operation
242	will terminate.
243	<P>The <CODE>auth</CODE> value is used to set the
244	AUTHTYPE permission checking value.
245	If the AUTHTYPE is not built in,
246	and the <CODE>auth</CODE> value does not match the
247	printcap or configuration
248	<CODE>auth</CODE> option value then authentication will fail.
249	An error message will be logged to the server log file,
250	and a non-zero error code and message will be written to the connection
251	to the remote client program.
252	<P>Many authentication programs require that the
253	users provide some form of key or identification.
254	The <CODE>auth_server_id</CODE> option is used for this purpose.
255	<P>The server will start the server authenticator program and provide the
256	following open file descriptors for it. The program
257	will run as the same UID as the <CODE>lpd</CODE> server.
258	If this is a print job transfer,
259	the current directory will be the spool directory of the print queue.
260	<BLOCKQUOTE><CODE>
261	<PRE>
262	FD Options Purpose
263	0 R/W socket connection to remote host (R/W)
264	1 W pipe or file descriptor, for information for server
265	2 W error log
266	3 R pipe or file descriptor, for responses to client
267	</PRE>
268	</CODE></BLOCKQUOTE>
269	<P>Command line arguments:
270	<BLOCKQUOTE><CODE>
271	<PRE>
272	program -S -PPRINTER -nUSER -aAUTHTYPE -Rauth_server_id -Ttempfile
273	</PRE>
274	</CODE></BLOCKQUOTE>
275	<P>The
276	<CODE>PRINTER</CODE>,
277	<CODE>USER</CODE>,
278	and
279	<CODE>AUTHTYPE</CODE>,
280	are obtained from the original command.
281	<P>The authentication filter will read the file transferred by the
282	client authenticator,
283	decrypt it,
284	and place the decrypted values in the tempfile.
285	It will then write
286	a
287	<CODE>from_id</CODE>
288	string to FD 1,
289	which will be read by the LPD server
290	and used as the identification of the originating end of the connection.
291	<P>If the originating program is an LPRng client,
292	then the <CODE>from_id</CODE> value will be the user identification for the authentication protocol;
293	if the originating program is an LPRng server,
294	this value will be the server identificatio for the authentication protocol.
295	<P>After writing this value,
296	the transfer program will close FD 1.
297	At this point the LPD server will use the contents of the tempfile to perform
298	the various requested actions.
299	<P>If the transfer step or authentication fails, then the server
300	authenticator
301	will write an error message to FD 2 and exit with error code
302	JFAIL.
303	<P>The <CODE>lpd</CODE> server will record the
304	authentication information returned by the server in the
305	AUTHUSER permissions key.
306	<P>The <CODE>lpd</CODE> server will perform the usual permissions checks,
307	with the addition of the indicated permission keys and associated values.
308	During this process,
309	any error messages or logging information normally returned to client
310	programs will be written to the authentication program FD 3.
311	<P>The <CODE>lpd</CODE> server will carry out either the commands or
312	print job specified in the temporary file.
313	During this process,
314	any error messages or logging information normally returned to client
315	programs will be written to the authentication program FD 3.
316	<P>At the end of the operations,
317	the FD 3 file descriptor will be closed and the <CODE>lpd</CODE> server
318	will wait for the authentication process to exit.
319	<P>The server authentication process will read
320	input from FD 3 until the end of input,
321	and then transfer the received information to the client
322	side authenticator.
323	It may use the tempfile to hold the information during the
324	reading and transfer process.
325	<P>If the transfer of the logging information fails,
326	then the authenticator process will exit with
327	error code JFAIL, otherwise it will exit with error code JSUCC.
328	<H2><A NAME="authforward"></A> <A NAME="authforwardid"></A> <A NAME="ss16.6">16.6 lpd Server to Server Authentication</A>
329	</H2>
330
331	<P>Options used:
332	<UL>
333	<LI> <CODE>auth_forward=</CODE><EM>Server to server authentication type</EM></LI>
334	<LI> <CODE>auth_forward_id=</CODE><EM>Destination server authentication id</EM></LI>
335	</UL>
336	<P>The Server to Server authentication procedure is used by one server
337	to forward jobs or commands to another server. It should be noted
338	that this forwarding operation puts an implicit trust in the security
339	of the client to server to server chain.
340	The <CODE>lpd</CODE> server will perform an authenticated transfer to
341	another server when it either needs to transfer a job to a remote printer
342	or when it needs to propagate a
343	<CODE>lpq</CODE>,
344	<CODE>lprm</CODE>,
345	or
346	<CODE>lprc</CODE> operation.
347	<P>The procedure used to by the server to send commands and/or jobs
348	is identical to that used by a client,
349	with the minor modification that the server is identified as the
350	originating endpoint of the connection,
351	and the client authentication information is transferred in the file.
352	<P>When propagating a command,
353	the server uses the authentication information provided for the remote
354	user by the client to server authentication program.
355	When propagating or forwarding a job,
356	the server will use the authentication information stored in the job
357	control or hold file.
358	This information will be represented as AUTHUSER in the following discussion.
359	<P>The
360	<CODE>auth_forward</CODE> option value specifies the type of authentication
361	to be used to forward authentication,
362	and the sending server uses the <CODE>auth_server_id</CODE> as its identification,
363	and the <CODE>auth_forward_id</CODE> as the identification of the remote server.
364	If there is no user authentication information,
365	then a normal, non-authenticated transfer will be done.
366	<P>The <CODE>auth_forward_filter</CODE> will be used for the forwarding
367	operation.
368	<P>The sending server takes the part of the client, and will
369	transfer a job acting similar to a client. The initial information
370	transfer from the sending server will have the format:
371	<BLOCKQUOTE><CODE>
372	<PRE>
373	\008printer F server_user authtype \n - for commands
374	\008printer F server_user authtype controlfilename\n - for print jobs
375	</PRE>
376	</CODE></BLOCKQUOTE>
377	<P>The sending server will invoke its authenticator with the arguments:
378	<BLOCKQUOTE><CODE>
379	<PRE>
380	auth_forward_filter -F -Pprinter -nserver_user -aauthtype \
381	-Rremote_user -Ttempfile
382	</PRE>
383	</CODE></BLOCKQUOTE>
384	<P>The tempfile containing the job or command information to be sent
385	will have the form:
386	<BLOCKQUOTE><CODE>
387	<PRE>
388	user_authentication_info\n
389	\n
390	<normal file contents>
391	</PRE>
392	</CODE></BLOCKQUOTE>
393
394	That is,
395	the user authentication information is place in the tempfile.
396	<P>The tempfile will be transferred to the remote server in the same fashion
397	as for a user job.
398	Any error or logging information returned will either be written to the
399	<CODE>lpd</CODE> log file or to the previous <CODE>lpd</CODE> process in
400	the transfer chain.
401	<P>On the destination server the same operations
402	for receiving an authentication request from a client
403	is performed.
404	The AUTHUSER, AUTHFROM, and AUTHTYPE values will be the derived from the
405	authentication request as for the client.
406	The AUTHSAMEUSER will compare the remote client authentication
407	information and the authentication information used to create the job.
408	<P>When the remote server receives the authentication request,
409	it will carry out the same actions as for a client to server transfer,
410	modified as follows:
411	<OL>
412	<LI>The <CODE>lpd</CODE> server will remove the first line of the transferred file,
413	which contains the user authentication information,
414	and set
415	AUTHUSER to this value.</LI>
416	<LI>Authentication is performed using the indicated values.</LI>
417	<LI>If authentication succeeds,
418	then the command line or print job control file is processed
419	in the normal manner.
420	This might now add more permissions values to tags,
421	but the authentication information will not be changed.</LI>
422	</OL>
423	<H2><A NAME="ss16.7">16.7 Permission Checking</A>
424	</H2>
425
426	<P>The following patterns and values can be used
427	to check that a particular type of authentication
428	has been used,
429	and what the authenticated user information is.
430	<UL>
431	<LI>AUTH - authentication is used</LI>
432	<LI>AUTHTYPE=globmatch<BR>
433	<P>This matches the type of authentication request.
434	Built in values include
435	<CODE>kerberos4</CODE>,
436	<CODE>kerberos5</CODE>,
437	and
438	<CODE>pgp</CODE>.
439	</LI>
440	<LI>AUTHUSER=globmatch<BR>
441	<P>The originating auth_user_id value.
442	</LI>
443	<LI>AUTHFROM=globmatch<BR>
444	<P>When a command received from a server (i.e.- forwarded by a server),
445	the value is the the forwarding servers authentication information,
446	otherwise it is NULL.
447	</LI>
448	<LI>AUTHSAMEUSER<BR>
449	<P>The originating auth_user_id value is compared to the value
450	used to create the job.
451	If they are identical, the match succeeds.
452	</LI>
453	</UL>
454	<P>For example, to reject non-authenticated operations, the following
455	line could be put in the permissions file.
456	<BLOCKQUOTE><CODE>
457	<PRE>
458	REJECT NOT AUTH
459	</PRE>
460	</CODE></BLOCKQUOTE>
461	<P>To reject server forwarded authentication as well, we use the following.
462	Note that the <CODE>?</CODE> forces a value to be present.
463	<BLOCKQUOTE><CODE>
464	<PRE>
465	REJECT AUTH AUTHFROM=?*
466	</PRE>
467	</CODE></BLOCKQUOTE>
468	<P>If a remote server has id information FFEDBEEFDEAF, then the
469	following will accept only forwarded jobs from this server. Note
470	that AUTHFROM will only match on authenticated transfers;
471	FWDUSER will only match on forwarded transfers.
472	<BLOCKQUOTE><CODE>
473	<PRE>
474	ACCEPT AUTH AUTHFROM=FFEDBEEFDEAF
475	REJECT AUTH
476	REJECT NOT AUTH
477	</PRE>
478	</CODE></BLOCKQUOTE>
479	<P>To allow only authenticated users to remove jobs you can use:
480	<BLOCKQUOTE><CODE>
481	<PRE>
482	ACCEPT AUTH SERVICE=R,M,L,P AUTHSAMEUSER
483	REJECT AUTH
484	REJECT NOT AUTH
485	</PRE>
486	</CODE></BLOCKQUOTE>
487	<H2><A NAME="ss16.8">16.8 Using PGP for Authentication</A>
488	</H2>
489
490	<P>PGP is a well known encryption and authentication program.
491	For more details see the web site
492	<A HREF="http://www.pgp.net">http://www.pgp.net</A>
493	or the ftp site
494	<A HREF="ftp://ftp.pgp.net">ftp://ftp.pgp.net</A>.
495	<P>LPRng has greatly simplified the use of PGP for authentication
496	by building in support as follows.
497	<P>The LPD server usually runs as user <CODE>daemon</CODE>,
498	and opens files as
499	<CODE>daemon</CODE>.
500	The system administrator should establish a home directory for daemon,
501	and use the PGP key generation facility to create a public and private key
502	for the <CODE>daemon</CODE> user.
503	By default,
504	the PGP program puts the public and secret key rings in the
505	<CODE>$HOME/.pgp/</CODE> directory,
506	and sets them to be readable only by the user.
507	You should log in temporarily as
508	<CODE>daemon</CODE>,
509	run the
510	<CODE>pgp -kg</CODE>
511	command,
512	and then disable logins for <CODE>daemon</CODE>.
513	<P>The user id chosen for the LPD server should be easily used to identify
514	the server.
515	For example,
516	<CODE>lpr@hostname</CODE>,
517	where hostname is the fully qualified domain name of the server is userful.
518	<P>The next step is to place the passphrase in a file that is only readable by
519	<CODE>daemon</CODE>,
520	say
521	<CODE>~daemon/.pgp/serverkey</CODE>,
522	with owned by <CODE>daemon</CODE>,
523	and with <CODE>600</CODE> permissions (read/write only by <CODE>daemon</CODE>).
524	This is extremely important,
525	as if any other users can read this file then security will be severely compromised.
526	<P>The next step is to distribute the <CODE>lpr@hostname</CODE> public key to all users of the
527	LPRng server,
528	and to place the public keys of LPRng users in the <CODE>daemon</CODE> public key ring.
529	This can be done using:
530	<BLOCKQUOTE><CODE>
531	<PRE>
532	pgp -kxa userid destfile keyfile
533
534	Example:
535	> pgp -kxa lpr@astart /tmp/lprkey ~daemon/.pgp/pubring.pgp
536	Key for user ID: lpr@astart
537	512-bit key, key ID BB261B89, created 1999/01/01
538
539	Transport armor file: /tmp/lprkey.asc
540	Key extracted to file '/tmp/lprkey.asc'.
541	</PRE>
542	</CODE></BLOCKQUOTE>
543	<P>User can add the <CODE>lpr@astart</CODE> key to their public key rings using:
544	<BLOCKQUOTE><CODE>
545	<PRE>
546	pgp -ka /tmp/lprkey.asc
547	</PRE>
548	</CODE></BLOCKQUOTE>
549	<P>Finally, the administrator will need to add users public keys to the
550	<CODE>daemon</CODE> users public key ring. This can most easily be done by
551	copying all the keys (in ASCII text form) to a single file
552	(<CODE>/tmp/keyfile</CODE>)and using:
553	<BLOCKQUOTE><CODE>
554	<PRE>
555	pgp -ka /tmp/keyfile ~daemon/.pgp/pubring.pgp
556	</PRE>
557	</CODE></BLOCKQUOTE>
558	<H3><A NAME="pgpserverkey"></A> <A NAME="pgppassphrase"></A> <A NAME="pgppath"></A> PGP Configuration</H3>
559
560	<P>Options used:
561	<UL>
562	<LI><CODE>pgp_path=</CODE><EM>path to PGP program</EM></LI>
563	<LI><CODE>pgp_server_key=</CODE><EM>path to server passphrase file</EM></LI>
564	<LI><CODE>pgp_passphrase=</CODE><EM>user passphrase file in PGPPATH or $HOME/.pgp</EM></LI>
565	</UL>
566	<P>The <CODE>pgp_path</CODE> option is the path to the PGP program.
567	<P>The <CODE>pgp_server_key</CODE> is the path to the file containing the server passphrase.
568	This file will be read by <CODE>lpd</CODE> to get the passphrase to unlock the server's
569	keyring.
570	<P>The LPRng client software will check to see if the
571	<CODE>pgp_passphrase</CODE> value (default <CODE>clientkey</CODE>) file in
572	<CODE>$PGPPATH</CODE>, and if not present,
573	then in <CODE>$HOME/.pgp</CODE>.
574	By default, the <CODE>pass_env</CODE> option is <CODE>pass_env=PGPPASS,PGPPATH,PGPPASSFD</CODE>
575	and will pass the values of the PGPPATH, PGPPASS,
576	and PGPPASSFD environment variables. See below for a method to use these.
577	<P>Example printcap entry:
578	<BLOCKQUOTE><CODE>
579	<PRE>
580	pr:
581	:lp=pr@wayoff
582	:auth=pgp
583	:auth_server_id=lpr@wayoff.com
584	:pgp_path=/usr/local/bin/pgp
585	:pgp_passphrase=.mypass
586	</PRE>
587	</CODE></BLOCKQUOTE>
588	<P>One problem with using PGP is the need to have users input their
589	passphrases.
590	If the user is daring, then the pass phrase can be put in the file:
591	<CODE> ~/.pgp/clientkey </CODE>. This file will be read by the
592	LPRng client program the contents passed to PGP as the passphrase.
593	This file MUST have 0400 permissions (read only by user)
594	and MUST owned by the user.
595	<P>A more subtle solution is to use the <CODE>PGPPASSFD</CODE> environment variable
596	facility.
597	This causes PGP to read the passphrase from a file descriptor.
598	If the user puts his passphrase in a file, say
599	<CODE>$(HOME)/.pgp/.hidden</CODE>,
600	then the following shell script can be used.
601	<BLOCKQUOTE><CODE>
602	<PRE>
603	#!/bin/sh
604	# /usr/local/bin/pgplpr script - passphrase in $(HOME)/.pgp/.hidden
605	#
606	PGPASSFD=3 3<$(HOME)/.pgp/.hidden lpr "$@"
607	</PRE>
608	</CODE></BLOCKQUOTE>
609	<H3>Permissions</H3>
610
611	<P>If you wish to enforce the use of authentication, then you
612	should modify the lpd.perms file. Here are some examples.
613	<BLOCKQUOTE><CODE>
614	<PRE>
615	# force authentication
616	REJECT NO AUTH
617	REJECT NO AUTHTYPE=pgp
618	</PRE>
619	</CODE></BLOCKQUOTE>
620	<H3>Client Configuration</H3>
621
622	<P>One problem with using PGP is the need to have users input their
623	passphrases.
624	If the user is daring, then the pass phrase can be put in the file:
625	<CODE> ~/.pgp/clientkey </CODE>. This file will be read by the
626	LPRng client program the contents passed to PGP as the passphrase.
627	This file MUST have 0400 permissions (read only by user)
628	and MUST owned by the user.
629	<P>A more subtle solution is to use the <CODE>PGPPASSFD</CODE> environment variable
630	facility.
631	This causes PGP to read the passphrase from a file descriptor.
632	If the user puts his passphrase in a file, say
633	<CODE>$(HOME)/.pgp/.hidden</CODE>,
634	then the following shell script can be used.
635	<BLOCKQUOTE><CODE>
636	<PRE>
637	#!/bin/sh
638	# /usr/local/bin/pgplpr script - passphrase in $(HOME)/.pgp/.hidden
639	#
640	PGPASSFD=3 3<$(HOME)/.pgp/.hidden lpr "$@"
641	</PRE>
642	</CODE></BLOCKQUOTE>
643	<P>By using the -V (verbose) flag, users can see the results of the
644	PGP interaction.
645	<H2><A NAME="ss16.9">16.9 Using Kerberos 5 for Authentication</A>
646	</H2>
647
648	<P>LPRng Kerberos 5 authentication is
649	based on the
650	Kerberos5-1.0.5 release as of March 28, 1999. This was obtained
651	from MIT:
652	<OL>
653	<LI> ftp to ATHENA-DIST.MIT.EDU (18.159.0.42), login anonymous, password
654	your_email_address</LI>
655	<LI> Change into the directory '/pub/kerberos/</LI>
656	<LI> Get the README files and look at the details of using FTP to get
657	the distribution. Note that there are also patches available
658	which you might want to use.</LI>
659	</OL>
660	<P>Note that the distribution has only the most superficial documentation.
661	There are no man pages for any of the support libraries, etc. etc.
662	<H3><A NAME="kerberosforwardprincipal"></A> <A NAME="kerberosserverprincipal"></A> <A NAME="kerberosservice"></A> <A NAME="kerberosrenew"></A> <A NAME="kerberoslife"></A> <A NAME="kerberoskeytab"></A> Kerberos Installation Procedure</H3>
663
664	<P>
665	<OL>
666	<LI> Get the Kerberos 5 distribution.</LI>
667	<LI> Compile and install the distribution.</LI>
668	<LI> Create the /etc/krb5.conf, /usr/local/var/krb5kdc/kdc.conf
669	files using templates from the src/conf-files subdirectory.
670	See the Installation notes and the System Administrators Guide.</LI>
671	<LI> Don't forget to create the /usr/local/var/krb5kdc/kdc.acl file;
672	I did and it took me HOURS to figure out what was wrong...</LI>
673	<LI> Start up the KDC and KADMIN servers - you might want to put
674	the following in your rc.local or equivalent file:
675	<BLOCKQUOTE><CODE>
676	<PRE>
677	if [ -f /etc/krb5.conf -a -f /usr/local/var/krb5kdc/kdc.conf ]; then
678	echo -n ' krb5kdc '; /usr/local/sbin/krb5kdc;
679	echo -n ' kadmind '; /usr/local/sbin/kadmind;
680	fi
681	</PRE>
682	</CODE></BLOCKQUOTE>
683	</LI>
684	<LI> use kadmin (or kadmin.local) to create principals for your users.</LI>
685	<LI> Now you need to create principals for the lprng servers. I have been
686	using
687	<CODE>lpr/hostname.REALM</CODE>
688	as a template-
689	i.e.
690	<CODE>lpr/astart1.astart.com@ASTART.COM</CODE>
691	for an example.
692	<P>Do this for all the servers. You should use fully qualified domain names
693	for the principals.
694	</LI>
695	<LI> Now you need to extract the keytab for each of the servers:
696	<BLOCKQUOTE><CODE>
697	<PRE>
698	kadmin ...
699	ktadd -k file_for_host lpr/hostname.REALM
700	</PRE>
701	</CODE></BLOCKQUOTE>
702
703	<P>The 'file_for_host' contains the keytab information, which is the
704	equivalent information for the server.
705	</LI>
706	<LI> Copy the 'file_for_host' to the server (you might want to encrypt
707	or use a secure transfer for this). You need to put this in
708	<CODE>/etc/lpd.keytab</CODE>.
709	Make sure that this file is readable only by user <CODE>daemon</CODE>,
710	as it will try to read the file to get its server key.
711	<BLOCKQUOTE><CODE>
712	<PRE>
713	#> ls -l /etc/lpd.keytab
714	-rw------- 1 daemon wheel 128 Jan 16 11:06 /etc/lpd.keytab
715	</PRE>
716	</CODE></BLOCKQUOTE>
717	</LI>
718	<LI> Modify (uncomment) the following entries in <CODE>/etc/lpd.conf</CODE>:
719	<BLOCKQUOTE><CODE>
720	<PRE>
721	auth=kerberos5
722	kerberos_keytab=/etc/lpd.keytab
723	kerberos_service=lpr
724	# optional - explicit prinipal name for server, used by clients
725	#kerberos_server_principal=lpr/hostname@REALM
726	# optional - forwarding to another server with authentication
727	# kerberos_forward_principal=lpr/hostname@REALM
728	</PRE>
729	</CODE></BLOCKQUOTE>
730
731	<P>The
732	<CODE>kerberos_keytab</CODE>
733	entry is the location of the keytab file;
734	kerberos_service is the service that will be used to generate
735	a server principal name.
736	This is the
737	<CODE>lpr</CODE>
738	used in the above key generation operations.
739	<P>kerberos_life and kerberos_renew determine the lifetime and renewability
740	of Kerberos tickets. The lifetime defaults to 10
741	hours, and the ticket will be refreshed when it expires
742	if necessary.
743	</LI>
744	<LI>You might like to check out the authentication using the sclient and
745	sserver test programs. These link in the kerberos authentication and
746	allow you to test it without all of LPD being involved.
747	<BLOCKQUOTE><CODE>
748	<PRE>
749	cd LPRng/src; make sserver sclient
750	usage: sserver [-D] [-p port] [-s service] [-S keytab] file
751	-D turns debugging on
752	1. opens TCP port 'port' (default 1234)
753	2. waits for a connection
754	3. when a connection comes in, uses 'service' to get the principal
755	name of the server, and looks up the key in keytab file.
756	4. Goes through the kerberos authentication.
757	5. Copies the input from remote server to 'file'
758	6. exits.
759	usage: sclient [-D] [-p port] [-s service] host file
760	-D turns debugging on
761	1. opens a connection to port on host (i.e. - host%port)
762	2. does the authentication. You must have done kinit to get
763	for your ticket to be valid.
764	3. sends the file to remote host.
765	</PRE>
766	</CODE></BLOCKQUOTE>
767
768	<P>To test this, start up sserver on one host/window, then run sclient.
769	The error messages are pretty straight forward,
770	and when in doubt,
771	look at the source code which has more than sufficient information.
772	</LI>
773	</OL>
774	<H3>Testing Transfers</H3>
775
776	<P>Restart the server,
777	and then try getting information using LPQ.
778	<P>You can turn on tracing at LPQ to see if authentication is being used
779	and is working:
780	<BLOCKQUOTE><CODE>
781	<PRE>
782	lpq -Dnetwork,database
783	</PRE>
784	</CODE></BLOCKQUOTE>
785	<P>If the lpq works,
786	then try send a job and see if the transfer is successful.
787	<H3>Explicit Server Principal Name</H3>
788
789	<P>If you are using printers in different domains, then you can
790	put the explicit principal name of the server in the printcap file,
791	using the server_principal entry. For example:
792	<BLOCKQUOTE><CODE>
793	<PRE>
794	lp_offsite
795	:lp=printer@erehwon.org
796	:auth=kerberos5
797	:auth_server_id=lpr/erehwon.org@BLUESKY.ORG
798	</PRE>
799	</CODE></BLOCKQUOTE>
800	<H2><A NAME="ss16.10">16.10 Using Kerberos 4 for Authentication</A>
801	</H2>
802
803	<P>LPRng has built-in support for the Project Athena extensions to the
804	RFC1179 protocol.
805	These provide an extremely simple authentication protocol
806	using an initial credential exchange.
807	After the initial exchange the usual RFC1179 protocol is used.
808	<P>To enable Kerberos 4 support,
809	you must modify the <CODE>LPRng/src/Makefile</CODE> and recompile
810	the LPRng code.
811	You should be aware that this is not a supported extension,
812	and is provided as a courtesy to MIT and Project Athena.
813	<HR>
814	<A HREF="LPRng-HOWTO-17.html">Next</A>
815	<A HREF="LPRng-HOWTO-15.html">Previous</A>
816	<A HREF="LPRng-HOWTO.html#toc16">Contents</A>
817	</BODY>
818	</HTML>

Note: See TracBrowser for help on using the repository browser.

Download in other formats: