Below follows a text proposal from John Wenn and Daniel Manchala which
captures the discussions from the IETF42 in Chicago. I have asked Bob
Herriot to include the text in our next draft of the IPP Scheme document. If
you have comments at this stage, please send them to the DL which now seems
to be working again.
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 at cp10.es.xerox.com