Carl-Uno
--Daniel Manchala Xerox Corporation John Wenn Xerox Corporation
September 4, 1998 Expires April 4, 1999
Internet Printing Protocol Scheme/0.9: Security
Status of this memo
This document is an Internet-Draft. 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The full set of IPP documents includes:
Internet Printing Protocol/1.0: Design Goals Internet Printing Protocol/1.0: Rational for Structure and Model Internet Printing Protocol/1.0: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Encoding and Transport
This document deals with the security considerations for IPP.
1.0 Introduction
It is required that the Internet Printing Protocol be able to operate within a secure environment. Wherever possible, IPP will make use of existing security protocols and services. IPP will not invent new security features when the requirements described in this document can be met by existing protocols and services. Examples of such services include Secure Sockets (SSL) [SSL3], Digest Access Authentication in HTTP, and the Content MD-5 Header Field in MIME. Although this document talks about SSL3, SSL3 is not a standard.
IPP [IPP-PRO, IPP-MOD, IPP-REQ] makes use of the "ipp:" URL scheme with HTTP 1.1 as a transport protocol, in which URL path names and MIME types are used to encode IPP from the HTTP protocol data stream. Security attributes like the mechanism used (TLS[TLS], SSL, DAA, etc) are specified as parameters as part of the ipp URL.
2.0 IPP Scheme Syntax and Security Parameters
The syntax for the IPP scheme is identical to the existing "http" scheme except for the scheme name, security attributes and different default port. This syntax could also be used for later versions of HTTP [HTTP] protocol that could specify the security attributes as part of the http:// URL.
IPP syntax:
ipp://host[:port]/<IPP-specific-abs-path> [";" parameters] parameters := "AUTH=" secure-protocol *["," secure-protocol] secure-protocol := "TLS" | "SSL3" | "DAA"
In the future other protocols like IPV6 could also be used as the secure protocol.
Multiple security protocols can be listed, but not all combinations make sense (e.g "AUTH=TLS,SSL3"). While other combinations can be commonly used (e.g. "AUTH=TLS,DAA"). The order of the protocols are irrelevant. The IPP client must be prepared to accept the appropriate response for any of the security protocols listed. An IPP client should not make a request for a security protocol it can not handle. The client and the server should be configurable for security protocol specific paramters (e.g. algorithms, key length, etc.)
3.0 Translation of IPP Scheme into HTTP Scheme
Translation of the ipp scheme into http depends upon whether proxy servers, tunnels or gateways are used. Parameters are translated into header fields in the HTTP protocol. Section 4.5 of RFC 2068 describes the general header fields used.
Associated with this IPP scheme is an IANA-assigned TCP port number, 631, which is the default port number used by clients to contact IPP servers that are represented by IPP URLs. If another port number is explitly specified, that port will be used by the client.
The IPP scheme implies all of the same protocol semantics as that of the HTTP [HTTP] scheme, except that, by default, the port number used by clients to connect to the server is port 631. The semantics for clients configured for proxy access is different as described below.
The implementation impact of using the new scheme on the existing specifications is mainly in the HTTP headers area. The IPP scheme URI is explicitly stored in the application/ipp MIME object.
3.1 Protocol specific considerations
TLS security method in IPP follows the standard of negotiating TLS over the same port [TLS-HTTP]. This involves sending a HTTP header "Upgrade: TLS/1.0" with the original request. The server is not required to upgrade to TLS, but if it accepts a TLS upgrade it will respond with status "101 Switching Protocols" at which point the TLS handshaking begins. After the TLS connection is established, the orginal operation is completed. A server that requires a TLS connection will respond with a status "418: Upgrade Required" when contacted without a TLS connection. Since communications are not protected until the TLS connection is established, an IPP client may want to use an innocuous method (e.g. Get-Printer-Attributes, Validate-Job) to establish a secure connection before sending any data. - Note, since the [TLS-HTTP] document is still incomplete, this document may copy the relevent text of the prelimary draft to keep this draft from being held up in the standards process.
SSL3 security method in IPP follows the existing practice of a separate security port with a https method [HTTPS].
DAA security method in IPP is used as specified in the standard [DAA]. The URI parameter is the URI generated on the request line, in accordance with the rules specified below.
When DAA is used with SSL3 or TLS, the server should first establish secure communications (SSL3 or TLS) before doing client authentication (DAA).
The IPP client has certain security expectations, as encoded in the security parameters of the IPP URI. If the server fails to meet these expectations (e.g. not upgrading to TLS), the client may terminate the connection.
3.2 HTTP Header Usage
When an IPP client obtains an IPP URL, the interpretation (translation) of this URL by the client can take one of two forms, depending upon whether the client is configured to use an HTTP 1.1 proxy server.
3.2.1 IPP Client Configured with no proxy server
When an IPP client (no proxy configured) obtains an "ipp:" URL such as "ipp://myhost.com/myprinter/myqueue;AUTH=TLS", it MUST open an TCP connection to port 631 on myhost.com, with the following example headers:
POST /myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Upgrade: TLS/1.0 Content-type: application/ipp Transfer-Encoding: chunked ...
In the above example, the client indicates that it wants to communicate using the TLS protocol using RSA for encryption and 40 bit export variety key, no signature and a message digest using MD5 one-way hash function.
3.2.2 IPP Client Configured for Proxy Service
When an IPP client that uses a proxy named "myproxy.com" obtains the URL "ipp://myhost.com/myprinter/myqueue;AUTH=TLS", it MUST open a TCP connection to myproxy.com with the following example headers:
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 Host: myhost.com:631 Upgrade: TLS/1.0 Content-type: application/ipp Transfer-Encoding: chunked ...
3.3 SERVER GENERATED URIs:
At the server, a job URI is generated in response to a client's request. This URI will use the IPP method with IPP security parameters. The client will then use this URI for their specific needs. The security protocol must match the security protocol used by the client request that created the job URI. The server should also store the security used in creating a job URI and enforce that level of security on subsequent operations on that job URI.
4.0 References
[DAA] J, Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart, An Extension to HTTP: Digest Access Authentication, RFC 2069, January 1997
[HTTPS] E. Rescorla, "HTTP Over TLS", draft-ietf-tls-https-01.txt
[IPP-MOD] Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P. "Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp-mod-10.txt, June, 1998.
[IPP-PRO] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt, June, 1998.
[IPP-REQ] Wright, D., "Design Goals for an Internet Printing Protocol", draft-ietf-ipp-req-02.txt, June, 1998.
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.
[TLS] Dirks, T., and Allan, C., "The TLS Protocol", draft-ietf-tls-protocol-05.txt
[TLS-HTTP] R. Khare, "Upgrading to TLS within HTTP", draft in progress
5.0 Author's Address
Daniel Manchala Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
John Wenn Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245
10.0 Other Contributors
Carl-Uno Manros
---Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com
Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com