INTERNET-DRAFT

<draft-ietf-ipp-ipp-scheme-01.txt>

Robert Herriot

Sun Microsystems

Daniel Manchala

Xerox Corporation

Carl-Uno Manros

Xerox Corporation

John Wenn

Xerox Corporation

Sepember 22, 1998

Note: this document is still needs work, including wordsmithing. It is intended to provide direction for discussion at the September 30, 1998 meeting. The Security section is new, but is not shown with change bars in order to make reading easier. The security section was written by Daniel Manchala and John Wenn.

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

IPP is an application level protocol that can be used for distributed printing on the Internet. Related IPP documents:

This document decribes a possible solution to an IESG request for a separate naming scheme for IPP. This is for further discussion, no consensus is yet reached on this in the IPP WG.

The quick summary is thatThis document proposed that IPP should must support a new scheme 'ipp', which clients and servers use in IPP attributes. Such attributes are in a message body whose Content-Type is application/ipp. A client maps 'ipp' URLs to 'http' URLs, and then follows the HTTP/1.1 rules for constructing a Request-Line and HTTP headers. The IPP document will not prohibit implementations from supporting other schemes in IPP attributes, but such support is not defined by this document.

A client and an IPP object (i.e. the server) SHOULD MUST support the 'ipp' scheme in the following IPP attributes. Each of these attributes identifies a printer or job object. The 'ipp' scheme is not intended for use in 'uri' valued attributes not in this list.

job attributes -

job-uri

job-printer-uri

printer attributes -

printer-uri-supported

operation attributes -

job-uri

printer-uri

If the scheme of the target URL in a request (i.e. the value of "printer-uri" or "job-uri" operation attribute) is some scheme 'x', other than 'ipp', the behavior of the IPP object is not defined by this document. However, it is RECOMMENDED that if an operation on an IPP object creates a new value for any of the above attributes, that attribute has the same scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the seven attributes above in the response, that the IPP object returns those URL values as is, regardless of the scheme of the target URL.

If the client obtains a target URL from a directory service, the scheme of the target URL SHOULD be 'ipp'. If the scheme is not 'ipp', the behavior of the client is not defined by this document, but it is RECOMMENDED that the client use the URL as is as the target URL.

Although user interfaces are beyond the scope of this document, it is RECOMMENDED that if software exposes the URL values of any of the above seven attributes to a human user, that the human see the URL as is.

When a client sends a request, it MUST convert an 'ipp' target URL to an 'http' target URL for use in the HTTP Request-Line and HTTP headers as specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the value of the "printer-uri" or "job-uri" attribute in the message body. If the scheme of the target URL is not 'ipp', the behavior of the client is not defined by this document, but it is RECOMMENDED that the client use the target URL as is in the Request-Line and HTTP headers.

A client converts an 'ipp' URL to an 'http' URL by

1) replacing the 'ipp' scheme by 'http'

2) adding an explicit port 631 if the URL does not contain an explicit port.

When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL such as "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to

some port (this example uses the IPP default port 631) on some host ("myhost.com" in this example) with the following headers:

POST /myprinter/myqueue HTTP/1.1

Host: myhost.com:631

Content-type: application/ipp

Transfer-Encoding: chunked

...

"printer-uri" "ipp://myhost.com/myprinter/myqueue"

...

When an IPP client sends a request via a proxy, such as "myproxy.com", to an ‘ipp’ URL, such as "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to some port (8080 in this example) on some proxy ("myproxy.com" in this example) with the following headers:

POST http://myhost.com:631/myprinter/myqueue HTTP/1.1

Host: myproxy.com:8080

Content-type: application/ipp

Transfer-Encoding: chunked

...

"printer-uri" "ipp://myhost.com/myprinter/myqueue"

...

The proxy then connects to the IPP origin server with headers that are the same as the "no-proxy" example above.

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 existing protocols and services can meet the requirements described in this document. 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, Note that SSL3 is not an IETF 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.

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:

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 "AUTHSECURITY=TLS,SSL3"). While other combinations can be commonly used (e.g. "SECURITY AUTH=TLS,DAA"). The order of the protocols are is 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 parameters (e.g. algorithms, key length, etc.)

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

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 original 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 relevant text of the preliminary 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.

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.

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:

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.

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:

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.

[IPP-MOD]

[IPP-PRO]

[IPP-REQ]

[DAA]

[HTTPS]

[SSL3]

[TLS]

[TLS-HTTP]

Robert Herriot

Sun Microsystems

17 Network Circle

Menlo Park, CA 94025

robert.herriot@eng.sun.com

Carl-Uno Manros

Xerox Corporation

701 Aviation Blvd.

El Segundo, CA 90245

manros@cp10.es.xerox.com

Daniel Manchala

Xerox Corporation

701 Aviation Blvd.

El Segundo, CA 90245

John Wenn

Xerox Corporation

701 Aviation Blvd.

El Segundo, CA 90245