Internet Draft Ryan Troll Document: draft-troll-cmu-lpr-extensions-00b.txt Carnegie Mellon Expires August 6, 1999 February 1, 1999 CMU LPR Extensions: Capabilities, Authentication, and TLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract The printing protocol documented in [LPR] describes a mechanism by which a client may transfer a job to a spooler, as well as a collection of queue management commands. LPR implementations actually implement more queue management commands, but these extra commands are only able to be run on the spooler machine. In addition, the existing LPR protocol does not perform authentication of any sort. The identity associated with a job is a text field in the control file, and this identity is only used when performing basic queue operations. Queue access is not limited by this in any way. Any new printing protocol will deal with these issues, as well as issues of printer characteristic determination, etc. Until then, we must support the growing number of hosts on the internet that wish to print to networked printers. This document describes the additions to LPR being made by Carnegie Mellon in order to better handle a distributed computing environment. Expires August 6, 1999 Troll [Page 1] Internet Draft CMU LPR Extensions February 1, 1999 Table of Contents Status of this Memo Abstract 1. Introduction 1.1. Conventions Used in the Document 1.2. Terminology 2. Command Overview 2.1. Command Codes 2.2. Acknowledgements 3. New Commands 3.1. Fetch Queue Capabilities 3.1.1. Usage Example 3.2. Authenticate 3.2.1. Usage Example 3.2.2. Existing LPR Command Augmentation 3.3. Start TLS 3.3.1. Processing After the STARTTLS Command 3.3.2. Result of the STARTTLS Command 3.3.3. Usage Example 4. Reserved Command Codes 4.1. 06: Remote LPC (LPRng Compatibility) 4.2. 07: Block Transfer (LPRng Compatibility) 4.3. 08: Secure Transfer (LPRng Compatibility) 5. Error Codes 6. Security Considerations 7. Copyright 8. References 9. Author's Address Expires August 6, 1999 Troll [Page 2] Internet Draft CMU LPR Extensions February 1, 1999 1. Introduction In order to handle the distributed computing environment present at Carnegie Mellon, a printing system must not be bound to any one operating system, it must be able to handle jobs of arbitrary content (PostScript, PCL, text, etc.), and it must allow printer owners to limit who has access to what printers. To help with these requirements, the Andrew Systems Group at Carnegie Mellon is adding a few new commands to the BSD LPD spoolers in use. These commands will be fully backwards compatible, and not interfere with any existing LPR spoolers or clients. The changes being made allow a client to determine what LPR extensions the spooler can handle, allow a client to authenticate to the spooler, and allow end-to-end encryption to be used on the entire transaction. The LPR software being modified is the LPRng [LPRNG] suite. This software package is very portable, modular, and provides functionality above and beyond that of a stock BSD system. Some of these functions are described within this document as possible extensions. 1.1. Conventions Used in the Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 1.2. Terminology An LPR client is an Internet host using LPR to contact a spooler in order to transfer a file, obtain queue information, or perform queue management commands. An LPR spooler is an Internet host that hosts one or more queues. An LPR queue is a virtual entity that accepts commands or jobs from LPR clients. Queues then pass these jobs on to other queues, or directly to the printers. 2. Command Overview In order to be interoperable with the existing LPR specification, all commands MUST follow the same command submission / acknowledgement mechanisms. This will ensure that new clients will not trick an older queue into expecting something it shouldn't. Expires August 6, 1999 Troll [Page 3] Internet Draft CMU LPR Extensions February 1, 1999 The first new command (Capabilities) MUST be the first extension command issued. If a client receives an error when sending this command, it MUST assume the queue will NOT accept any extension commands. If the job request requires LPR extensions be used, the client MUST act as if the queue is unavailable. If possible, the client SHOULD report this error to the user if at all possible. If a queue receives a request that requires a prior LPR extension which was not used (IE: Authenticate), and it has not received any LPR extensions yet, it MUST assume the client is an older LPR client, and MUST report an error to the client. If the queue requires an LPR extension be used, and the client has used some extensions other than the one in question, the queue MAY report what is necessary to the client. Regardless of whether or not this report occured, the queue MUST close the connection. 2.1. Command Codes All command codes MUST be one byte, followed by any arguments necessary for the command, followed by a LF: +---+------+----+ | C | Args | LF | +---+------+----+ C: Command Code Args: Arguments for the command LF: Trailing LF The command codes \001 through \005 MUST be used as described in [LPR]. These functions may be modified by the LPR extensions. However, the client MUST only expect these modifications if it has previously initiated an LPR extension command. 2.2. Acknowledgements Following all commands, and acknowledgement byte MUST be read to determine whether or not the command succeeded. Successful acknowledgements are defined as \000, and error acknowledgements are any other value. All error values defined in this document are listed at the end of this document. 3. New Commands The CMU LPR Extensions are: Expires August 6, 1999 Troll [Page 4] Internet Draft CMU LPR Extensions February 1, 1999 3.1. Fetch Queue Capabilities The queue capability extension allows a client to determine what LPR extensions the queue supports. This MUST be the first LPR extension used by the client when interracting with the queue, as it allows the client to determine what else it may do. +---+-------+----+ | C | Queue | LF | +---+-------+----+ Command code - C (103) Operand - Printer queue name When a queue receives this command, it MUST acknowledge the request by returning one byte: \000. Clients MUST consider any other response as an indication that the queue does not support any LPR extensions. After sending a successful ACK, the queue will send the list of capabilities in the following format: +-----+------+ | len | data | +-----+------+ len - 4 byte integer in network byte order data - ASCII string of the queue's capabilities Len is the length of the string, not counting any trailing NULL. The string contains a list of the queue's capabilities, separated by spaces. The exact capability names will be defined within each extension. If the queue's capability string is successfully received, the client MUST respond with a successful ACK. If there is an error, the client MUST respond with a non-zero acknowledgement, and then close the connection. After sending this, the queue MUST read an ACK byte, to see if it was successfully received. At this time, this response is ignored, but is present to conform with the rest of the protocol. The returned capabilities string contains the list of LPR extensions this queue supports. Some of the entries are queue specific, while others apply to the spooler hosting the queue. Clients MUST not care about this, and assume that all of the listed extensions are Expires August 6, 1999 Troll [Page 5] Internet Draft CMU LPR Extensions February 1, 1999 only for the requested queue. If one of the extensions affects interractions with other queues, the extension definition will clearly state this. If the queue does not support any LPR extensions besides this one, the return string is of length 0. 3.1.1. Usage Example To determine the capabilities of the queue for printer "waldec": S: C: C: Cwaldec S: \000 S: [nnnn]AUTH=KERBEROS_V4 STARTTLS AUTH=ANONYMOUS C: \000 C: . . . 3.2. Authenticate The authenticate command allows the client to prove it's identity to the queue. Queues may use this to determine who can use it, for accounting, etc. This may also be necessary to begin encrypting the stream. +---+-------+----+-----------+----+ | A | Queue | SP | Mechanism | LF | +---+-------+----+-----------+----+ Command code - A Operand 1 - Printer queue name Operand 2 - SASL Mechanism to use Capability entries: AUTH={mech}, based on queue supported mechanisms. If the queue supports mechanisms "foo", "bar", and "baz", the capability string would contain "AUTH=foo AUTH=bar AUTH=baz". This begins a SASL [SASL] authentication transaction with the queue. The client sends this, and the queue responds with a 1-byte ACK. If the ACK is NOT \\000, the queue does NOT support this transaction, and it MUST NOT be continued. If the ACK is successful, the client MUST begin the SASL negotiation by sending the first transaction. A transaction is defined as: Expires August 6, 1999 Troll [Page 6] Internet Draft CMU LPR Extensions February 1, 1999 * Client sends the next authentication step * Queue ACKs * Queue responds to the authentication step * Client ACKs The client and queue authentication steps are encoded as follows: +-----+------+ | len | data | +-----+------+ len - 4 byte integer in network byte order data - (len) bytes of (possibly binary) data for this transaction. If an ACK indicates failure, the authentication attempt MUST be stopped immediately, and both the client and queue MUST assume a failure. The next command MUST be sent by the client. The number of transactions will be based upon the authentication mechanism that is being used. Once all are done, the client and queue MUST assume that the connection is authenticated based on the results of the final negotiation. Any negotiated security layer will begin with the client command sent immediately following the completion of the authentication negotiation. 3.2.1. Usage Example The following illustrates the use of the Authenticate command: S: C: C: Cwaldec S: \000 S: [nnnn]AUTH=KERBEROS_V4 STARTTLS AUTH=ANONYMOUS C: \000 C: Awaldec KERBEROS_V4 S: \000 C: [nnnn]{..........} S: \000 S: [nnnn]{..........} C: \000 C: . . . Expires August 6, 1999 Troll [Page 7] Internet Draft CMU LPR Extensions February 1, 1999 3.2.2. Existing LPR Command Augmentation When a client determines that the spooler is supporting this authentication mechanism via the capabilities command, it MUST assume the following changes to the standard LPR command responses. The error codes for command 02 (Receive a printer job) and its subcommands will be defined as: -- Error 00: Success -- Error 101: Queue requires authentication (User has not performed command 'A') -- Error 102: Authenticated user does not have access to this queue 3.3. Start TLS The Start TLS command allows a client to initiate a TLS [TLS] handshake with the spooler. +---+----+ | T | LF | +---+----+ Command code - T Capability Entry: STARTTLS This command lets the client tell the spooler to begin a TLS negotiation. Once completed, all future communication between the client and the spooler will take place over a TLS encrypted link. After sending this command, the client must read an acknowledgement from the spooler. The spooler may respond with one of the following values: -- Error 000: Ready to start TLS -- Error 050: Syntax error (no parameters allowed) -- Error 110: TLS not available due to temporary reason Spoolers may choose to require TLS connections to a queue. If this is the case, the spooler SHOULD return the error code: -- Error 111: Must issue a STARTTLS command first to every command other than AUTH and STARTTLS. After receiving a successful acknowledgement to the STARTTLS command, the client SHOULD start the TLS negotiation before giving Expires August 6, 1999 Troll [Page 8] Internet Draft CMU LPR Extensions February 1, 1999 any other LPR commands. 3.3.1. Processing After the STARTTLS Command After the TLS handshake ha been completed, both parties MUST immediately decide whether or not to continue based on the authentication and privacy achieved. The LPR client and spooler may decide to move ahead even if the TLS negotiation ended with no authentication and/or no privacy. However, some LPR clients or spoolers may want to continue only if a particular level of authentication and/or privacy was achieved. If the LPR client decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD close the connection after the TLS negotiation is complete. If the spooler decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD reply to every command from the client with the following error code: -- Error 112: Command refused due to lack of security 3.3.2. Result of the STARTTLS Command Upon completion of the TLS handshake, the LPR protocol is reset to the initial state (the state of the server when the connection was first established). The spooler MUST discard any knowledge obtained from the client, which was not obtained from the TLS negotiation itself. The client MUST discard any knowledge obtained from the spooler, such as the list of Authentication mechanisms. The client SHOULD send a Capabilities command as the first command after a successful TLS negotiation. The list of LPR capabilities returned in response to the Capabilities command after a successful TLS handshake MAY be different than the list returned before the TLS handshake. For example, a LPR spooler might not want to advertise support for a particular SASL mechanism unless a client has sent an appropriate client certificate during a TLS handshake. Both the client and the spooler MUST know if there is a TLS session active. A client MUST NOT attempt to start a TLS session if a TLS session is already active. A server MUST NOT return the STARTTLS capability in the capability list after a TLS handshake has completed. Expires August 6, 1999 Troll [Page 9] Internet Draft CMU LPR Extensions February 1, 1999 3.3.3. Usage Example The following dialog illustrates how a client and spooler can start a TLS session: S: C: C: Cwaldec S: \000 S: [nnnn]AUTH=KERBEROS_V4 STARTTLS AUTH=ANONYMOUS C: \000 C: T S: \000 C: C & S: C & S: C: 4. Reserved Command Codes The following command codes are reserved, as they are currently in use by other currently undocumented extensions. 4.1. \006: Remote LPC (LPRng Compatibility) +------+-------+----+----+------+----+---------+----+---------+----+ | \006 | Queue | SP | user | SP | command | SP | options | LF | +------+-------+----+----+------+----+---------+----+---------+----+ Command code - \\006 Capability Entry: REMOTELPC XXX Insert how it works. What is the user data? Example: C: \006waldec ryan@andrew.cmu.edu topq 13 S: \000 4.2. \007: Block Transfer (LPRng Compatibility) Send a chunk of compressed data? XXXXX Expires August 6, 1999 Troll [Page 10] Internet Draft CMU LPR Extensions February 1, 1999 4.3. \008: Secure Transfer (LPRng Compatibility) Send a file securely? XXXXX 5. Error Codes This list contains all of the error codes defined in this document. Not all error codes may be returned by all commands. For a full description of what error codes may be returned by which commands, consult the error code definition earlier in this document. All error codes are represented as a one-byte value. These codes are only used by LPR extension-enhanced spoolers. If a spooler does not support these extensions, the only error code that MUST be used by the spooler is error 000: success. Any other error code MUST be interpreted as an error. 000: Success 050: Syntax error 101: Queue requires authentication (User has not performed command 'A') 102: Authenticated user does not have access to this queue 110: TLS not available due to a temporary reason 111: Must issue a STARTTLS command first 112: Command refused due to lack of security 6. Security Considerations LPR protocol transactions, including all document content, are sent in the clear over the network unless privacy protection is negotiated in the AUTH or STARTTLS commands. A server error message for an AUTH command which fails due to invalid credentials SHOULD NOT detail why the credentials are invalid. 7. Copyright Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing Expires August 6, 1999 Troll [Page 11] Internet Draft CMU LPR Extensions February 1, 1999 the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [LPR] L. McLaughlin III, "Line Printer Daemon Protocol", RFC 1179, August 1990 [SASL] J. Myers, "Simple Authentication and Security Layer", RFC 2222, October 1997 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999 LPRNG XXXXX 9. Author's Address Ryan Troll Network Development Expires August 6, 1999 Troll [Page 12] Internet Draft CMU LPR Extensions February 1, 1999 Carnegie Mellon 5000 Forbes Avenue Pittsburgh, PA 15213 Phone: (412) 268-8691 EMail: ryan@andrew.cmu.edu Expires August 6, 1999 Troll [Page 13]