IPP> SEC - Security parameters for IPP scheme

IPP> SEC - Security parameters for IPP scheme

IPP> SEC - Security parameters for IPP scheme

Paul Moore paulmo at microsoft.com
Fri Aug 7 14:21:36 EDT 1998


What is the requirement from Keith?

> -----Original Message-----
> From:	Carl-Uno Manros [SMTP:manros at cp10.es.xerox.com]
> Sent:	Friday, August 07, 1998 10:31 AM
> To:	ipp at 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 at cp10.es.xerox.com



More information about the Ipp mailing list