> -----Original Message-----
> From: Carl-Uno Manros [SMTP:manros@cp10.es.xerox.com]
> Sent: Friday, August 07, 1998 10:31 AM
> To: ipp@pwg.org
> Subject: IPP> SEC - Security parameters for IPP scheme
>
> All,
>
> 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