Subject: IPP> SEC - Security parameters for IPP scheme

From: "Manros, Carl-Uno B" <[email-masked]>
Date: Thu, 10 Sep 1998 13:41:15 PDT

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: [email-masked]