August 7, 1998 Daniel Manchala Xerox Corporation John Wenn Xerox Corporation Proposed Security Parameters for the IPP Scheme ----------------------------------------------- 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]//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. ------