IPP> SEC - Security parameters for IPP scheme

IPP> SEC - Security parameters for IPP scheme

Carl-Uno Manros manros at cp10.es.xerox.com
Fri Aug 7 13:31:21 EDT 1998


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