John Wenn and Daniel Manchala have worked on coming up with a proposal on
how to add security paameters to the "ipp" scheme, to meet another
requirement from our Area Director Keith Moore. This text was not deemed
suitable for inclusion in the just circulated draft on the Internet
Printing Protocol Scheme, as it has not yet been reviewed in the WG, but
you should view this as complementary to scheme draft.
I would expect us to discuss this proposal on the DL and in the Toronto
meeting.
Carl-Uno
------
1.0 Introduction
It is required that the Internet Printing Protocol be able to
operate within a secure environment. Wherever possible, IPP
ought to 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) [SSL2, SSL3], Digest Access Authentication in HTTP
[HTTP], and the Content MD-5[MD5] Header Field in MIME.
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[SSL2, SSL3], DAA, etc), type and strength
of encryption, signature and integrity algorithms used (e.g:
RSA - 40 [RSA], MD5[MD5], etc.,) are specified as parameters as
part of the ipp URL.
IPP Scheme Syntax and Security Parameters
------------------------------------------------------
The syntax for the IPP [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 can be specified as follows:
AUTH = secure-protocol [ ":" protocol optional parameters]
where
secure-protocol := "TLS" | "SSL3" | "SSL2" | "DAA"
TLS parameters := [ key-exchange "-" strength ";"
encryption-algorithm "-" strength ";"
hash-function "-" strength].
SSL3 parameters := [ key-exchange "-" strength ";"
encryption-algorithm "-" strength ";"
hash-function "-" strength].
DAA parameters := [hash-function "-" strength].
If optional parameters are not supplied, standard default
parameters will be used.
In the future other protocols like IPV6 could also be used as
the secure protocol.
key exchange is the specific algorithm used to securely
exchange public keys between the client and server. The exact
values are specified by the specific protocol. For example,
TLS specifies allowed key exchange values in Appendix C of the
standard. Examples of key exchange algorithms include RSA, DH
and variants.
encryption algorithm is the specific algortithm used to
achieve confidentiality. Like key exchange, the exact values
are specified by the specific protocol. Examples of such
algorithms include 3DES[3DES], RC4 and IDEA. Encryption
algorithm always should be specified with the strength of
encryption key in bits.
hash-function is the specific algorithm used to perform a
message digest on the data being sent. Like key exchange, the
exact values are specified by the specific protocol. Example
of a hash-function could be MD5[MD5]. Strength could be the bit
value of the resulting hash.
For the case of TLS[TLS] and SSL[SSL2, SSL3], the client
presents a list of acceptable parameters to the server, and the
server chooses one among the specified list. In this scheme, if
a parameter is specified, it is the preferred value for the
parameter. Other values may be configured. For SSL, the client
translates the URI into a https URI. For TLS, the client
translates the URI into a TLS compatible URI. {This
compatiblity is still not finalized by the TLS standard
group}.
In the case of DAA[DAA], the URI is used as a security input.
In this scheme, the translated URI (http method) is used as the
input.
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. It is
proposed to add a security-protocol protocol that corresponds
to the AUTH parameter of the ipp protocol. In order not to
confuse with the WWW-Authenticate response header that a server
sends to the client when it wants to be authenticated, we use
the general header field security-protocol to specify that the
client requests a connection of type specified in the
security-protocol. The AUTH parameter directly translates into
the HTTP [HTTP] security-protocol header as follows:
security-protocol = protocol [
":" encryption-algorithm "-" strength ";"
signature-algorithm "-" strength ";"
hash-function "-" strength]
where protocol specifies the protocol used for security e.g:
TLS, SSL3, SSL2, DAA, etc.
Associated with this IPP scheme is an IANA-assigned TCP [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.
------------------------------------------------------
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. In both cases, the security
parameters are passed as part of the HTTP headers to the
server. This ensures that the IPP scheme's security parameters
are received by the server, and the server can reconstruct the
ipp URI at it's end.
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;RSA-EXPORT40;NULL;MD5",
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
Security-Protocol: TLS; RSA-EXPORT40; NULL; MD5
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.
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;RSA-EXPORT40;NULL;MD5",
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: myproxy.com:8080
Security-Protocol: TLS; RSA-EXPORT40; NULL; MD5
Content-type: application/ipp
Transfer-Encoding: chunked
...
Note that the virtual host problem is still being debated in
the TLS working group, and the above translation for proxy
service may have to be changed.
SERVER GENERATED URIs:
-----------------------------------------
At the server end several URIs are generated in response to a
client's request (job query, job cancel, etc.). These URIs will
use the IPP method with IPP security parameters. The client
will then use these URIs for their specific needs. The
security protocol must match the security protocol used
initially by the client to communicate with the server. The
individual security parameters must match the security
parameters actually used. Note that these parameters may differ
from the parameters specified in the original IPP URI.
------
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